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
0 komentar:
Posting Komentar