Not Just Theory
Consider Example 2-6. A switch (6K-4-S2) has just been MAC attacked. Its bridging table is full. The switch has a routed interface in VLAN 20. Pings to 10.20.20.1 (a remote router) are successful. The Address Resolution Protocol (ARP) table reveals that the MAC address associated to 10.20.20.1 is 0000.0020.0000. However, no entry for that address exists in the bridging table! This means that all traffic destined to 0000.0020.0000 is flooded to all ports that are members of VLAN 20.
Example 2-6 Revealing the Effects of a MAC Spoofing Attack
6K-4-S2# show mac-address-table count
MAC Entries for all vlans :
Dynamic Address Count: 131028
Static Address (User-defined) Count: 27
Total MAC Addresses In Use: 131055
Total MAC Addresses Available: 131072
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms 6K-4-S2# show ip arp 10.20.20.1
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.20.20.1 4 0000.0020.0000 ARPA Vlan20
6K-4-S2# show mac-add address 0000.0020.0000 Legend: * - primary entry vlan mac address type learn ports
No entries present.
If the host who started the MAC flooding attack now runs a packet analyzer, the contents of a conversation between 6K-4K-S2 (10.20.20.2) and a remote host (10.20.20.1) can be intercepted as shown in Example 2-7.
Example 2-7 Intercepting a Remote Conversation
[[email protected] root]# ifconfig eth1 | grep inet inet addr:10.21.21.100 Bcast:10.21.21.255 Mask:255.255.255.0 inet6 addr: fe80::200:caff:fefe:0/64 Scope:Link [[email protected] root]# tcpdump -i eth1 tcp port 23 -vne tcpdump: listening on eth1
21:17:03.056077 0:0:65:4:0:0 0:0:0:20:0:0 ip 60: 10.20.20.2.48643 > 10.20.20.1.telnet: S [tcp sum ok] 3116159553:3116159553(0) win 4128 <mss 1460> [tos 0xc0] (ttl 255, id 0, len 44)
continues
Example 2-7 Intercepting a Remote Conversation (Continued)
21:17:03.057055 0:0:65:4:0:0 0:0:0:20:0:0 ip 60: 10.20.20.2.48643 > 10.20.20.1.telnet: . [tcp sum ok] ack 321387993 win 4128 [tos 0xc0] (ttl 255, id 1, len 40)
21:17:03.057232 0:0:65:4:0:0 0:0:0:20:0:0 ip 72: 10.20.20.2.48643 > 10.20.20.1.telnet: P [tcp sum ok] 0:18(18) ack 1 win 4128 [telnet DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL SEND LOCATION, WILL TSPEED, WILL NAWS, WILL LFLOW] [tos 0xc0] (ttl 255, id 2, len 58) [etc.]
Even though the host has nothing to do with 10.20.20.x, it can see all traffic between 10.20.20.1 and .2 thanks to the MAC flooding attack.
Continue reading here: Unknown Unicast Flooding Protection
Was this article helpful?