Layer 2 Network Protections against Man in the Middle Attacks
Last Updated: 2009-11-11 03:59:37 UTC
by Rob VandenBrink (Version: 1)
Last month (Day 9 of Cyber Security Awareness Month) we discussed a Man in the Middle (MITM) attack against RDP (Microsoft’s Remote Desktop Protocol), along with Man in the Middle protections for RDP services. The article and video illustrate the just how easy it is to mount a man in the middle attack using ARP cache poisoning. We've also recently covered recent research in SSL Man in the Middle vulnerabilities and this month's issues concerning MITM attacks against TLS renegotiation . Today's entry discusses network protections that provide mitigation for all services against such attacks (not just a specific protocol or vulnerability). We’ll be discussing mitigations that can be applied in most corporate settings (Private VLANs aren’t covered).
Just a quick recap - Layer 2 MITM attacks are often based on ARP poisoning, and the mitigation against this is what we’ll be discussing today. ARP poisoning consists of an attacker sending a gratuitous ARP packet (an unsolicited ARP reply) to the target hosts, so that the target client and server both think that the attacker is the host at the other end of the conversation. After this is accomplished, the attacker will now intercept all traffic between the hosts, which can be simply recorded and forwarded on, or modified before forwarding. A more complete explanation of the mechanics can be found in last month’s entry (check the video for the details)
The configuration commands shown in this article are for Cisco IOS, but equivalent commands are available on Brocade, HP and most other managed switches on the market today. We’ll be covering DHCP Snooping, Dynamic ARP inspection, IP Source Guard, and Rate Limiting of ARP packets.
DHCP Snooping intercepts all DHCP traffic, and maintains a table of MAC addresses to IP Addresses called a DHCP Snooping binding database. This sounds a lot like an ARP table, but is used instead to validate ARP traffic to protect against Man in the Middle Attacks which might poison the ARP table.
DHCP Snooping by default blocks all DHCP offer packets inbound to the switch port, which means that if a DHCP server is on that port, the DHCP requests will reach the server, but the addresses will never reach the DHCP client. So after enabling DHCP snooping, configure any ports that have DHCP servers attached, or uplink to switches with DHCP servers as “trusted”.
It makes good sense to periodically store your DHCP Snooping database to flash memory or a tftp or (preferably) an scp server. Without this, if a switch is rebooted, clients on untrusted ports will not have connectivity until they renegotiate a DHCP lease.
Anyone who has ever had a home router (with its DHCP server) appear on their corporate network knows how disruptive this can be, and can attest to just how valuable these DHCP snooping functions can be just to mitigate that one situation.
|Switch(config)# ip dhcp snooping
||Enables DHCP snooping globally.|
|Switch(config)# ip dhcp snooping vlan 1,2,6||Enables DHCP snooping on VLANs 1, 2 and 6 (this of course will be unique for each site)|
|Switch(config)# int g0/7
Switch(config-if)# ip dhcp snooping trust
|On the port with the DHCP server (gig 0/7 in this example), enable dhcp snooping trust|
|Switch(config)# ip dhcp snooping database tftp://192.168.10.50/dbfile||On bootup, read the dhcp snooping database from a tftp server|
Dynamic ARP inspection (DAI)
This feature uses the table created by the DHCP Snooping feature to validate all ARP responses that arrive inbound to switch ports. Gratuitious ARPs are integral to all Man in the Middle attacks that use ARP Cache poisoning. What DAI does is simply drop all ARP replies that do not have corresponding entries in the DHCP Snooping binding database. ARP reply packets where the MAC address in the body of the packet do not match the MAC address in the Ethernet header are also dropped.
In non DHCP environments, DAI can operate against a statically defined ARP ACL.
Ports that have multiple MAC addresses, such as uplink to physical or virtual switches, should be configured as “trusted”, this bypasses all DAI functions.
|Switch(config)# ip arp inspection vlan 1||Turn on arp inspection for vlan 1|
|Switch(config)# int g0/8
Switch(config-if)# ip arp inspection trust
trust int g0/8 to have multiple arp entries - for instance, uplinks to
IP Source Guard
This feature uses the DHCP Snooping database as well, but takes things one step further. When a client host powers on, IP Source Guard will filter all traffic to and from that port except for the DHCP request and reply traffic. Once the address is assigned and the DHCP Snooping entry is populated for the port, any traffic received from that port from a different ip address is filtered.
|Switch(config)# Int g0/8
Switch(config-if)# ip verify source
|Enable ip source guard on one interface|
|Switch(config)# int g0/8
Switch(config-if)# ip verify source vlan dhcp-snooping
|Enable ip source guard for all vlans defined on this interface|
Rate Limiting Incoming ARP Packets
Many tools that perform Man in the Middle attacks based on ARP poisoning will generate large volumes of ARP reply packets (Gratuitous ARPs). Switches can generally be configured to Rate Limit these packets, and in many cases can be configured to either alert if a threshold is exceeded, or to place any ports that exceed a configured threshold in an error state, either for a configured period of time or until manually reset.
By default, when dynamic ARP inspection is configured, ARP packets are rate limited to some default value (15 per second on cisco platforms, but this may vary on other switches)
|Switch(config-if)# ip arp inspection limit rate 20||
configure arp inspection for 20 packets
|Switch(config-if)# errdisable recovery cause arp-inspection interval 240||re-enable the errdisable'd port after
Caveats and Comments on Layer 2 Network Protections
Many network components require on changing MAC addresses, so care should be taken when defining protections against ARP poisoning. These features should be disabled on interfaces that have components that have:
- Standby features such as vrrp, vrrp-e, hsrp and similar router or firewall clustering applications
- load balancers, or hosts configured with load balancing solutions such as Microsoft NLB
- Any clustering application such as microsoft, linux, solaris or other clustering solutions
- Ports that connect to Vmware ESX vswitch uplink ports, as a vmotion involves a virtual server mac migrating from one physical switch port to another with a corresponding RARP packet after completion.
- Switch ports that connect to ESX uplink ports that support load balanced or failover configurations for the ESX Service Console or vmkernel ports.
Features such as rate limiting of ARP packets, Storm control and port security (these 2 aren't covered in this post) can simply disable ports if their function is triggered. Unless configured for recovery, disabled ports remain in an Error Disabled state until manually re-enabled. Needless to say, this can cause major service disruptions unless implemented carefully.
While there are certainly some things to watch out for in implementing these features, the benefits of configuring the protections we've discussed almost always outweigh the risks (by a country mile). Most enterprises should really consider implementing at the very least DHCP Snooping and Dynamic ARP Inspection.
Assuming Windows is in use, ping the default gateway and then use "arp -a" to get its MAC address. Copy it to the clipboard and then issue this command "arp -s 192.168.45.12 00-aa-00-62-c6-09" (using the clipboard contents, naturally).
Do another "arp -a" and make sure it now shows as static instead of dynamic.
We just had a PCI internal pen test and they tried to ARP spoof our desktops. The ones that did NOT have a static ARP entry showed absolutely no issues but the testers grabbed all of their traffic. The administrator desktops with a static ARP entry immediately lost all connectivity to the LAN until the attack stopped, so it was picked up instantly.
The same thing can be done by making an entry on the associated switch, which is also inexpensive. My opinion is that 100% of all servers should have their switch port locked to their MAC address. This eliminates confusion on the part of admins as to whether a particular server is locked down, because they all are. It also keeps people from just plugging devices into server switches because unused ports are either disabled or locked o a non-existent MAC address. If you have this kind of problem, it brings a lot of discipline to the process of adding or moving servers.
Nov 11th 2009
1 decade ago
I've used static ARP entries on hosts in the past as well, but find that over time they are harder to maintain, especially in a large environment where you might have dozens (or hundreds) of servers, which might then see frequent maintenance, and perhaps move between vlans. This also means that adding one server means making static changes on all the other pre-existing servers.
I've used static MAC entries (referenced in the article in the DAI section) as well. I find this has the same limitation as the static host entries, with the possible advantage that all the static entries are in one place.
Both static approaches have the same issue in production environments - if they cause any problems, they'll tend to get overlooked unless you pull a real expert into the solution process.
The DAI approach I find tends to scale really well - in a recent project we implemented most of the above protections for a 5000+ user network. After some initial planning, the implementation was done in an afternoon.
Personally, I prefer a dynamic approach, which blocks the attackers' behaviour rather than using static entries. However, different protection mechanisms will work better in different environments, and static entries are very much required in some shops.
Thanks again for the discussion and interest !
Nov 11th 2009
1 decade ago
Nov 12th 2009
1 decade ago
I'd generally recommend that you run the latest code, but on some hardware 12.1 *is* the latest, and even if you can upgrade to 12.2, that may involve an upgrade cost, which can be a whole other issue ...
Nov 12th 2009
1 decade ago