TCP/IP Weapons School Part 1 Wrap-Up

I'd like to address a few issues that arose during class Sunday and Monday.

First, someone asked about interoperability between the various Ethernet frame types. Page 75 of the excellent Troubleshooting Campus Networks states

Two stations cannot communicate unless they share a common frame format, which is sometimes beneficial. For example, if you have two networks on a physical medium that you wish to keep separate for security reasons, you can configure the networks for different frame types and they won't communicate with each other.

I don't agree with the "security" aspect, since the a station on a SPAN port can still see the traffic through promiscuous sniffing. Still, now you know that a host using Ethernet II framing can't talk to one using 802.3 LLC SNAP, for example.

One of you asked how a host knows the length of an Ethernet II frame if the frame doesn't carry a length filed like 802.3. This FAQ claims:

How is the length of an Ethernet II frame calculated?

The length of an Ethernet II frame is not present in the frame itself. It depends on the Ethernet network interface used. When the interface sends a frame to the network device driver, it supplies the length of the received frame.

The IP header length only specifies the length of the IP header. TCP contains an offset to application data which helps us know the length of the TCP header. UDP has a length header.

One of you asked how multicast traffic is handled by switches. According to page 97:

Bridges and switches forward broadcast and multicast frames out all ports, unless configured to do otherwise. The forwarding of broadcast and multicast frames can result in performance problems in large, flat (switched or bridged) networks.

Cisco deals with multicast using CGMP and IGMP Snooping:

Multicast traffic becomes flooded because a switch usually learns MAC addresses by looking into the source address field of all the frames it receives. A multicast MAC address is never used as source address for a packet. Such addresses do not appear in the MAC address table, and the switch has no method for learning them.

The first solution to this issue is to configure static MAC addresses for each group and each client. This solution works well, however, it is neither scalable nor dynamic....

The second solution is to use CGMP, which is a Cisco proprietary protocol that runs between the multicast router and the switch. CGMP enables the Cisco multicast router to understand IGMP messages sent by hosts, and informs the switch about the information contained in the IGMP packet.

The last (and most efficient) solution is to use IGMP snooping. With IGMP snooping, the switch intercepts IGMP messages from the host itself and updates its MAC table accordingly. Advanced hardware is required to support IGMP snooping.

One of you asked about multicast MAC addresses. Cisco says:

Multicast IP addresses are Class D IP addresses. Therefore, all IP addresses from 224.0.0.0 to 239.255.255.255 are multicast IP addresses. They are also referred to as Group Destination Addresses (GDA).

For each GDA there is an associated MAC address. This MAC address is formed by 01-00-5e, followed by the last 23 bits of the GDA translated into hex, as shown below.

- 230.20.20.20 corresponds to MAC 01-00-5e-14-14-14.
- 224.10.10.10 corresponds to MAC 01-00-5e-0a-0a-0a.

Consequently, this is not a one-to-one mapping, but a one-to-many mapping, as shown below.

- 224.10.10.10 corresponds to MAC 01-00-5e-0a-0a-0a.
- 226.10.10.10 corresponds to MAC 01-00-5e-0a-0a-0a as well.

Someone asked about detecting ARP poisoning with Snort. The snort.conf includes the following:

# arpspoof
#----------------------------------------
# Experimental ARP detection code from Jeff Nathan, detects ARP attacks,
# unicast ARP requests, and specific ARP mapping monitoring.  To make use of
# this preprocessor you must specify the IP and hardware address of hosts on
# the same layer 2 segment as you.  Specify one host IP MAC combo per line.
# Also takes a "-unicast" option to turn on unicast ARP request detection. 
# Arpspoof uses Generator ID 112 and uses the following SIDS for that GID:

#  SID     Event description
# -----   -------------------
#   1       Unicast ARP request
#   2       Etherframe ARP mismatch (src)
#   3       Etherframe ARP mismatch (dst)
#   4       ARP cache overwrite attack

#preprocessor arpspoof
#preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00

I've never tried it, but I might now.

If you have any other questions, please post them as comments here. Thank you.

I still have a few open seats left for part 2 of the course on Saturday 9 Dec 06 and Sunday 10 Dec 06, which covers the topics addressed in this class outline. We will cover layers 4 through 7. The registration form is here. Part 2 is held at the Marriot Wardman Park Hotel as well, in the Harding Room. Students who are already registered will be hearing from me shortly. Basically you'll need Ethereal or Wireshark to decode the traces we'll examine.

Copyright 2006 Richard Bejtlich

Comments

Anonymous said…
The more i see your notes on the weapons school the more I wish I could attend.

Have you thought of writing a book on this stuff? The outline could be a decent table of contents. I don't think there's much competition in the field of network analysis from a security/defense standpoint.

On a similar note I've finally scored Laura Chappell's master library CD's which is fantastic. http://www.packet-level.com/library.htm. But it's a bit expensive (and massive) for most.
1:29 PM
Richard Bejtlich said…
Hello,

I am considering writing a book called Hacking TCP/IP Illustrated based on my TCP/IP Weapons School class.
1:45 PM
C.S.Lee said…
Hello Rich,

I have seen some switches using broadcast storm control to prevent speed degradation. 3com is just one of them.

I hope to get my book signed by the way :(
1:33 AM
Anonymous said…
This comment has been removed by a blog administrator.
1:26 AM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more