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

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.

Configuration:

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.

Configuration:

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.

Configuration:

or

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)

Configuration

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.