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).
DHCP Snooping Configuration:
Dynamic ARP inspection (DAI)
Configuration:
IP Source Guard
Configuration:
or
Rate Limiting Incoming ARP Packets
Configuration
Caveats and Comments on Layer 2 Network Protections
|
Rob VandenBrink 579 Posts ISC Handler Nov 11th 2009 |
||||||||||||||||||||
Thread locked Subscribe |
Nov 11th 2009 1 decade ago |
||||||||||||||||||||
A really simple effective protection is to set a static ARP entry on administrator's computers to their default gateway. This does have the disadvantage that if the MAC of the default gateway changes connectivity breaks, or if the desktop is replaced the protection is lost. But it's very effective.
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. |
Anonymous |
||||||||||||||||||||
Quote |
Nov 11th 2009 1 decade ago |
||||||||||||||||||||
Thanks for the comment RJ. A great illustration of what basic protections will buy you in an audit or pentest.
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 ! |
Rob VandenBrink 579 Posts ISC Handler |
||||||||||||||||||||
Quote |
Nov 11th 2009 1 decade ago |
||||||||||||||||||||
Caveat - Cisco Switch IOS 12.1 only supports DHCP Spoofing, 12.2 supports all features listed in the article
|
Rob VandenBrink 5 Posts |
||||||||||||||||||||
Quote |
Nov 12th 2009 1 decade ago |
||||||||||||||||||||
Good catch !
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 ... |
Rob VandenBrink 579 Posts ISC Handler |
||||||||||||||||||||
Quote |
Nov 12th 2009 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!