DHCP Snooping, Dynamic ARP Inspection and IP Source Guard

With a client going for an ISO standard which dictates stringent controls over both the external and the internal network resources I decided to put in some additional controls to ensure confidentiality, integrity and availability of the internal network. As the client uses Cisco hardware on premise, this consisted of a trio of additional measures over and above the standard VLAN’ing, firewalling and ACLs – DHCP Snooping, Dynamic ARP Inspection (DAI) and IP Source Guard – to cover the bases. I’ve labbed up these features for the purposes of this post and the topology used is in the image below. I’m running this on a pair of Cisco 3560G switches with a Microsoft 2012 Server dishing out DHCP addresses.

2017-06-28 18_53_19-Photos

First up, DHCP Snooping. This provides protection against rogue DHCP servers and therefore Man-In-The-Middle (MITM) attacks whereby a rogue agent could redirect internal traffic via a compromised gateway. Additionally, the rate of DHCP requests from a port can be restricted to prevent DHCP starvation attacks. This is possible because the switch can observe the DHCP “DORA” (Discover, Offer, Request, Acknowledgement) transaction process and has defined trusted ports for trunk ports or ports connected to the trusted DHCP server. Cisco’s implementation will simply not forward the Discover packet out of an untrusted port, thereby ensuring an offer is not made by a rogue DHCP server while other vendors may filter out only the Offers. An added benefit of this feature is that the switch can build up a database of valid DHCP messages that have went through the full “DORA” process to bind the MAC address, IP address, VLAN and switch port as an entry in the database which can then be used by two other Cisco features, IP Source Guard and Dynamic ARP Inspection (DAI). In the absence of the DHCP DORA process, perhaps for a static IP’d device, then static entries can also be added. One issue that could arise however is that the switch reboots and loses the DHCP bindings that were learned – this can be mitigated by having a remote database that is periodically written to in order to tolerate such a failure. Below are the commands used in my lab that enabled the feature:

Command Notes
ip dhcp snooping Turns on the DHCP Snooping feature
ip dhcp snooping vlan 20,30,40 Enables DHCP snooping for particular VLANs
ip dhcp snooping database tftp://172.16.0.20/DHCP_Bindings_SW1.dhcp Ensures the switch copies the binding table periodically to a remote database
ip dhcp snooping trust Configures an interface or trunk/uplink as a trusted interface that you’d expect to see DHCP offers on
ip dhcp snooping database tftp://172.16.0.20/DHCP_Bindings_SW1.dhcp Ensures the switch copies the binding table periodically to a remote database
ip source binding aa11.bb22.cc33 vlan 30 172.16.1.1 interface g0/1 Adds a static binding for devices which do not receive their address from DHCP

IP Source Guard essentially ensures that the IP address being used by a client is valid, i.e. don’t allow an attacker duplicating the IP address of a genuine workstation or server. As a packet enters an interface (which has been configured with the “ip verify source” command) the IP address is checked against the DHCP snooping binding table and if no entry exists for that IP on that interface then the packet is dropped, therefore you’d not want to run this command against trunk / uplink ports (in fact you can’t). This feature is turned on at just the interface level with the “IP source verify” command, however one big caveat would be to wait or force the DHCP leases for clients to be renewed, or manually add bindings into the snooping database, before you go ahead and turn on this feature. A few comments have been that this is similar to port-security with sticky MAC addresses etc. however this does differ slightly in that we’re looking one OSI layer above to prevent the spoofing of illegitimate source IP addresses that don’t belong to the host.

Command Notes
ip verify source port-security Turns on the IP source guard feature for a particular interface

Dynamic ARP Inspection (DAI) is a feature which operates at layer 2 and prevents invalid ARP messages which do not have a valid IP to MAC binding. For example, an attacker could in theory send fake ARP responses to legitimate ARP queries telling the switch that the attacker itself is the correct device and therefore perform a Man-In-The-Middle (MITM) attack.  With DAI turned on, any message that is an ARP response must originate from a device with a valid IP and MAC binding otherwise it is dropped. It is also possible to limit the rate of the ARP packets to prevent a DoS attack, which by default is set to 15 packets per second. Again, below is the config I’ve used to set this up in my lab:

Command Notes
ip arp inspection vlan Global command to enable ARP inspection for a VLAN
ip arp inspection trust Configure this on uplink ports or ports where you are happy not to run DAI

Some of the interesting things I’ve noted while playing around and researching these features are:

  1. Must have correct clock time on the switch to ensure the DHCP expiry times can be recognised. For this I set the switch to match the DHCP servers’ NTP settings.
  2. A blank DHCP snooping binding database file must exist before it can be written to by the switch – it does not create its own file.
  3. One DHCP snooping database file must exist for every switch.
  4. Turning on DAI caused the switch to freeze up momentarily dropping pings over the trunks.
  5. A static IP’d device with a static snooping binding which then wants to get a DHCP address is able to do so, however an updated entry for the DHCP address is not entered into the binding table thereby stopping communications from that device until either the static IP is reverted to or the static binding is removed.
  6. IP Source Guard can be used on ports that have a voice VLAN configured without issue, so long as the voice VLAN is not in scope of the DHCP snooping global command.
  7. For DAI, ensure uplink ports are trusted before turning on globally or risk restricting traffic over the links and potentially locking yourself out of the SSH session.
  8. Static IP snooping bindings MUST have an interface set against the entry – this prevents portability of the client with a static IP around the office (rare but could happen).
  9. While IP Source Verify can’t be uses on trunk ports the command can still be issued on a port that has neither been set with switchport mode access or switchport mode trunk  or switchport nonegotiate commands allowing an attacker to use DTP to negotiate themselves as a trunk port with the switch and therefore bypassing the IP source verify feature for their port.
  10. Information Option 82 can cause some headaches for DHCP snooping. You may need to add an additional commands as per this link to get your setup working

Some further reading:

http://www.netcontractor.pl/blog/?tag=ip-dhcp-snooping

https://blog.michaelfmcnamara.com/2013/01/dhcp-snooping-arp-inspection-ip-source-guard/

Advertisements

One thought on “DHCP Snooping, Dynamic ARP Inspection and IP Source Guard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s