This post will deal with the problem of DHCP attacks that can occur within an enterprise and how you can quickly and easily tighten security within a network.
First off, attacks can be malicious or completely by accident without the end-user knowing what they are doing. Let’s say someone brings their home laptop to the office running Internet Connection Sharing or better yet they plug in something as simple as a Linksys router so they can get a wireless signal. These devices could theoretically hand out IP addresses to other devices on the same subnet. Workstation default gateways would change and traffic would flow through the rouge device or stop altogether. Think about this for a real-life situation… your entire call center could potentially go down and critical application cannot connect causing customer service issues! It makes for a really bad day at work.
If the attack has malicious intent, traffic could be inspected and then sent on to the destination device within the network. Even DNS could be compromised as an attacker could give workstations invalid/malicious entries directing them to false websites. With a few systems here and there dropping out of the existing DHCP pool(s), the attack could go unnoticed for long periods of time. Passwords and other sensitive information could get into the wrong hands exposing the network to future attacks. Once the attacker has this information he/she could use it to access other secured portions of the network, files, applications, email, etc.
You may ask how can you break DHCP so an attacker can get data? It’s as simple as firing up a new DHCP server and handing out addresses. An attacker could try a few tricks such as exhausting the existing DHCP pool (known as a DHCP Denial of Service attack) so it no longer hands out addresses. New requests would be directed onto the rogue device. It could also be the attacker now has a DHCP server that can respond to the broadcasts a bit faster. When DHCP requests are made, all servers handling the subnet’s scope will respond, but the real servers may not win. Take for example where a DHCP server is located across a congested WAN connection (not the best setup here, but it does happen). A new local device that is introduced will, in most cases, respond much quicker.
Cisco (and other vendors such as HP and Juniper) introduced the DHCP Snooping feature in their products. It is designed to prevent unauthorized ports from responding to DHCP requests (such as DHCPACK, DHCPNAK, DHCPOFFER or DHCPLEASEQUERY). You just tell your equipment that end-user ports cannot respond to DHCP requests and that server ports can. Unauthorized attempts are dropped. Yes, it’s that simple! DHCP snooping works with the concept of trusted and untrusted ports.
In easier terms, trusted ports are generally interfaces on your switch that are connected to things under an administrator’s control like interfaces going to corporate/authorized DHCP servers and switch uplinks/trunks. Untrusted ports are those that are typically end-user access ports and other devices that are generally not trusted. Remember that even though you may trust the user we should build network security not based on the trust of a person but on the situation and what we are wanting to potentially stop. The end-user may never do anything, but hey guess what…malware can!
Ok, I see what you are saying, but how do I set it up? Well, first we need to enable it globally (or on a per-vlan basis) on the switch. Keep in mind that this will block all DHCP requests on the switch (or VLAN) which could be a bad thing. We need to add a few more commands after this to finish the setup.
Switch(config)# ip dhcp snooping [vlan number/range]
Next, we need to tell the switch which ports are trusted so DHCP traffic works. Here you apply the trust command to ports containing valid DHCP servers and uplink ports to the rest of the network.
Switch(config-if)# ip dhcp snooping trust
The Cisco switches use a snooping database to track information from untrusted sources. The information includes the client MAC address, the DHCP assigned IP address, and VLAN. It can be used by other security features (such as Dynamic ARP Inspection and IP Source Guard) on the switch/network, but when the switch reboots this information is lost. If you are running applications where it needs to remain persistent you can save it to a file on a TFTP server. Even if you do not do this step, snooping still works and untrusted sources are still blocked. The database will just rebuild itself.
Switch(config)# ip dhcp snooping database tftp://server/file
Once configured you can use the following show commands to verify your configuration.
show ip dhcp snooping show ip dhcp snooping binding [address]
When configuring, the best place to put the entries is on the access switches that connect to end-user systems (desktops, laptops, printers, etc). Again, be sure to trust the ports that are uplinks/trunks to the rest of the network and trust the actual DHCP server ports (if configuring on server switches). In most cases, end-user systems are not directly connected or have access ports on distribution or core switches. DHCP Snooping would not be needed here.
Just as a side note, if you are messing with the configuration and trying additional DHCP Snooping options/configurations and you are running into issues, they may be related to DHCP option 82. One example of this would be when working with DHCP relay on Cisco routers. A good Cisco blog from Joe Astorino talks more about this and how to correct. If you are seeing something similar in your debug logs you may want to read it.
%DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 00e0.1e32.54a1
In my next post, we’ll focus on MAC flooding attacks. I think it is a good topic regarding security and one that users may not be aware of. The MAC flooding attack is when the switch’s CAM table becomes overwhelmed with addresses and fills to capacity. The switch will then force packets for all new flows to be flooded out all ports, thus allowing an attacker to monitor (sniff) incoming packets. Sounds interesting huh? Stay tuned for more…