Ethernet operates at Layer 2 of the OSI protocol stack. The IEEE 802.3 standard defines a basic data frame format that is required for all Ethernet implementations, plus several additional optional formats that are used to extend the protocol’s basic capability.
One of the very best references covering the gamut of ICMP reconnaissance attacks is “ICMP Usage in Scanning, Version 3.0.”4
On the defensive side, IDS and other network monitoring tools often look at various ICMP statistics as an indication of OS fingerprinting and UDP-based port scans.5 High numbers of ICMP Destination Unreachable, Port Unreachable (Type 3, Code 3) error messages may also be an indication of a worm that spreads through UDP, such as MS SQL,Slammer, or Sapphire, or a DoS attack that uses UDP packets, such as trin00/TFN.6
ICMP Destination Unreachable Header References:
1. “Top 100 Network Security Tools.”
<http://sectools.org/>
2. “Original Van Jacobson/Unix/LBL Traceroute.”
<http://kb.pert.geant2.net/PERTKB/VanJacobsonTraceroute>
3. “Nmap Network Mapper.”
<http://insecure.org/nmap/>
4. “ICMP Usage in Scanning, Version 3.0” Ofir Arkin. June 2001.
<http://www.sys-security.com/archive/papers/ICMP_Scanning_v3.0.pdf>
5. “Looking for Trouble: ICMP and IP Statistics to Watch.”
<http://www.securitypronews.com/2003/1028.html>
6. “Denial of Service Attack using the trin00 and Tribe Flood Network programs.”
<http://xforce.iss.net/xforce/alerts/id/advise40>
Table B-8 ICMP Destination Unreachable Error Message Header Fields and Their Security Implications (Continued)
Bit Offset Header Field Header Value and Description
The basic IEEE 802.3 Ethernet frame format contains seven fields, as shown in Figure B-9. The IEEE 802.3 Ethernet frame header fields shown in Figure B-9 are described in Table B-9, along with a brief description of some known modifications or spoofs to relevant header fields that have been seen used in common Ethernet attacks.
Figure B-9 IEEE 802.3 Ethernet Frame Header
Table B-9 IEEE 802.3 Ethernet Frame Header Fields and Their Security Implications
Field Length Header Field Header Value and Description
7 bytes Preamble
(PRE)
This field provides an alternating pattern of 1s and 0s (binary 10101010), indicating to receiving stations that a frame follows, and used to synchronize receiving stations with the incoming bit stream on the wire. The specific pattern varies depending upon the specific Ethernet encoding used, which is outside the scope of this book.
Security Implications: No security implications exist because this field is used solely for physical and data link layer bit and Ethernet frame synchronization. Of course, in switchless Ethernet topologies, a faulty or malicious host may continuously transmit bits on the wire, causing collisions and preventing other hosts from transmitting. This does not apply to the switched Ethernet topologies, which are most commonly deployed today.
1 byte Start of Frame Delimiter (SFD)
This field provides an alternating pattern of 1s and 0s, ending with two consecutive 1 bits (binary 10101011), indicating that the next bit is the leftmost bit in the leftmost byte of the frame’s destination address.
Security Implications:Similar to the preamble above, no security implications exist because this field is used solely for physical and data link layer bit and Ethernet frame synchronization.
7 1 6 6 2 46 to 1500
Maximum Frame Size 1518 Bytes
4
Preamble Destination
Address Payload
Frame Check Sequence Source
Address
SFD Type/Length
6 bytes Destination Address (DA)
This field identifies the Media Access Control (MAC) address of the station(s) that should receive the Ethernet frame. The leftmost bit in the DA field indicates whether the address is an individual address (indicated by a 0) or a group address (indicated by a 1). The second bit from the left indicates whether the DA is globally administered (indicated by a 0) or locally administered (indicated by a 1). The remaining 46 bits are a uniquely assigned value that identifies a single station (unicast), a defined group of stations (multicast), or all stations on the network (broadcast).
Security Implications: In the legitimate case, the IP protocol dynamically resolves IP address to MAC address bindings, and vice versa, using ARP and RARP (Reverse ARP). In the malicious case, an attacker may craft the destination address within an Ethernet frame in an attempt to launch ARP spoofing, switch spoofing, double 802.1Q encapsulation, private VLAN, and Spanning Tree Protocol (STP) attacks, as outlined in Chapter 2.
6 bytes Source Address (SA)
This field identifies the MAC address of the sending station. The SA must always be an individual (unicast) address, and the leftmost bit in the SA field is always 0.
Security Implications: In the legitimate case, the sending host inserts its MAC address in this field. In the malicious case, an attacker may craft the MAC source address within an Ethernet frame in an attempt to launch CAM table overflow and ARP spoofing attacks, as outlined in Chapter 2. Note that ARP spoofing affects both source and destination Ethernet addresses. The attacker first advertises itself as an IP host using a spoofed gratuitous ARP, at which point hosts may begin transmitting packets destined to the spoofed IP host to the attacker’s Ethernet address. For more information on ARP spoofing attacks, refer to Chapter 2.
2 bytes Type/Length This field indicates either the number of data bytes contained in the Data field of the frame (length) or the frame type ID if the frame is assembled using an optional format (Ethernet II frame). Specifically, if the Type/
Length field value is less than or equal to 1500 bytes (0x05DC), the frame is considered an IEEE 802.3 frame.
continues Table B-9 IEEE 802.3 Ethernet Frame Header Fields and Their Security Implications (Continued)
Field Length Header Field Header Value and Description
If the Type/Length field value is greater than 1536 bytes (0x0600), it is considered an Ethernet II frame. A value of 0x0800, for example, represents an Ethernet II
encapsulated TCP/IP packet. Similarly, a value of 1500 (0x05DC) represents an IEEE 802.3 frame with a total frame length of 1518 bytes, including Destination Address, Source Address, Type/Length, and FCS header fields. The IEEE 802.2 LLC/SNAP header located within the Data field is outside the scope of this book.
Security Implications: DoS attacks may use a value that does not represent the true frame length or Ethernet II subprotocol identifier. A poorly written network stack may improperly process these packets, resulting in a DoS or buffer overflow condition. Note, many Ethernet vendors have also added support for jumbo Ethernet frames to increase overall networked application throughput and to accommodate VLAN and MPLS header information.1 Jumbo frames are frames that are bigger than the standard IEEE 802.3 Ethernet frame size of 1518 bytes. Because jumbo frames are not part of the IEEE standard, the definition of jumbo frame size is vendor-dependent.
46 to 1500 bytes
Data/Payload This field carries the payload of the Ethernet frame. The Data field can be anywhere from 46 to 1500 bytes in size.
Security Implications: In the legitimate case, if the frame does not have 46 bytes’ worth of information to convey, the station pads the end of this field with 1s. Short frames (runts) are typically an indication of collisions (on old switchless topologies). In the malicious case, runts could be injected on the network artificially.
4 bytes Frame Check
Sequence (FCS)
This field contains a 32-bit cyclic redundancy check (CRC) value. The FCS is generated over the DA, SA, Type/Length, and Data fields, and excludes the Preamble and SFD.
Security Implications:The FCS is created by the source MAC and is recalculated by receiving MACs to check for damaged frames. Frames with invalid checksums are discarded silently, and hence no useful attacks seem plausible that manipulate or spoof this header field.
1. “Jumbo/Giant Frame Support on Catalyst Switches Configuration Example.” (Doc. ID: 24048.) Cisco Documentation.
http://www.cisco.com/warp/public/473/148.html.
Table B-9 IEEE 802.3 Ethernet Frame Header Fields and Their Security Implications (Continued)
Field Length Header Field Header Value and Description