DHCP is a protocol used nearly everywhere to configure network parameters of host devices automatically. A DHCP server located on a LAN segment (or elsewhere and reached via DHCP relay) will typically send parameters for the following:
Client IP Address
Default Gateway
Subnet Mask
DNS Servers
A rogue DHCP server will configure hosts with bad information for various reasons. It may simply be a rogue residential router connected to the network backwards. Or it could be a villain intentionally redirecting host traffic to a man-in-the-middle to gather information, disrupt critical business traffic, or other nefarious reasons. Rogue DHCP servers will cause problems that are frustrating at best, and a critical security hazard at worst.
The good news is that they are fairly easy to detect with a packet capture if you are connected to the LAN in question. However, sometimes I have a need to shut these down from a distance and that’s where the packet capture functionality of a Cisco ASA comes in handy.
First, login to the ASA and get to the Privileged EXEC (#) prompt. Run the following command:
Cisco-ASA# capture $CAPTURE-NAME interface $IF-NAME match udp any eq bootps any
Note:
$CAPTURE-NAME = whatever you want to call this packet capture.
$IF-NAME = the interface that you want to capture packets through.
This will match on any source address UDP port 67, which is the port that a DHCP server will use.
Let this run for a bit and try to generate some DHCP traffic (bounce a port if you can).
Use the command ‘show capture’ to see currently active captures and see if any data has been captured.
Cisco-ASA# show capture
capture TEST-CAPTURE type raw-data interface INSIDE [Capturing – 2058 bytes]
match udp any eq bootps any
Now that we know data has been captured, let’s take a closer look.
Cisco-ASA# show capture TEST-CAPTURE
7 packets captured
1: 3:45:22.542727 802.1Q vlan#10 P0 0.0.0.0.68 > 255.255.255.255.67: udp 300
2: 3:45:22.565934 802.1Q vlan#10 P0 192.168.1.1.67 > 255.255.255.255.68: udp 548
3: 3:45:22.728508 802.1Q vlan#10 P0 0.0.0.0.68 > 255.255.255.255.67: udp 300
4: 3:45:22.786443 802.1Q vlan#10 P6 172.16.31.1.67 > 255.255.255.255.68: udp 300
5: 3:45:22.786519 802.1Q vlan#10 P6 172.16.31.1.67 > 255.255.255.255.68: udp 300
6: 3:45:23.823504 802.1Q vlan#10 P0 0.0.0.0.68 > 255.255.255.255.67: udp 300
7: 3:45:23.888702 802.1Q vlan#10 P6 172.16.31.1.67 > 255.255.255.255.68: udp 300
7 packets shown
In this example, 172.16.31.1 is a valid DHCP server. 192.168.1.1 however is not! That addressing scheme sounds like an out-of-the-box consumer-grade Netgear router. We can get more information by appending the word ‘detailed’ to the previous command.
Cisco-ASA# show capture TEST-CAPTURE detail
7 packets captured
1: 3:45:22.542727 e0c7.677a.a13c ffff.ffff.ffff 0x8100 Length: 346
802.1Q vlan#10 P0 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] udp 300 [tos 0x18] (ttl 255, id 10635)
2: 3:45:22.565934 b039.56ab.32ea ffff.ffff.ffff 0x8100 Length: 594
802.1Q vlan#10 P0 192.168.1.1.67 > 255.255.255.255.68: [udp sum ok] udp 548 (ttl 64, id 0)
3: 3:45:22.728508 e0c7.677a.a13c ffff.ffff.ffff 0x8100 Length: 346
802.1Q vlan#10 P0 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] udp 300 [tos 0x18] (ttl 255, id 10636)
4: 3:45:22.786443 40a6.7713.afb1 ffff.ffff.ffff 0x8100 Length: 346
802.1Q vlan#10 P6 172.16.31.1.67 > 255.255.255.255.68: [udp sum ok] udp 300 [ttl 1] (id 47344)
5: 3:45:22.786519 40a6.7713.afb1 ffff.ffff.ffff 0x8100 Length: 346
802.1Q vlan#10 P6 172.16.31.1.67 > 255.255.255.255.68: [udp sum ok] udp 300 [ttl 1] (id 47345)
6: 3:45:23.823504 e0c7.677a.a13c ffff.ffff.ffff 0x8100 Length: 346
802.1Q vlan#10 P0 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] udp 300 [tos 0x18] (ttl 255, id 10637)
7: 3:45:23.888702 40a6.7713.afb1 ffff.ffff.ffff 0x8100 Length: 346
802.1Q vlan#10 P6 172.16.31.1.67 > 255.255.255.255.68: [udp sum ok] udp 300 [ttl 1] (id 47348)
7 packets shown
This shows us that the MAC address of the 192.168.1.1 host (aka villainous rogue DHCP server) is b039.56ab.32ea. We can enter the OIU (first 6 characters of a MAC address) into a tool like the Wireshark OUI Lookup Tools and discover that this is a Netgear device. Tracking it on the LAN is easy and out of the scope of this post.
Of course, none of this would be required if you have properly configured features like DHCP snooping or 802.1X port authentication. I hope this helps you save some time troubleshooting in the future.