After having spent several nights searching in a 1500-users network for a rogue dhcp server, coming from a “smart” user who bought a junk router for Christmas, I have decided it’s time to use our knowledge instead of using our nights to solve this issue.
How it was done:
Two different services work aggregated for this issue:
1. DHCPD ROGUE DETECTOR
it is a smart component which is able to transform any network adapter into a dhcp client adapter, for a limited amount of time. The really smart thing is that it DOES NOT interfere with the IP addresses already assigned to that specific interface, which usually works as gateway – such as during the sniff, the same interface works as gateway as previously assigned.
The component asks for an IP address and remembers the IP address and MAC Address of the DHCP server only if this one is different than that already present on the same interface. The component will NOT bind the IP address asssigned by the dhcp server to the interface, instead it will write to a log and send an email. All parameters are configurable (from, to, mail server etc) and the component is easily distributable as compiled noarch ELF on both i386 and x86_64 architectures.
2. DHCP Slapper
The first component only tells us about a rogue dhcp server in the network, but it does not interfere with it. Without the second component, the rogue dhcp server is able to do its dirty work without any problem.
This is where the dhcp slapper comes into action.
A regular DHCP traffic is as follows:
client looks for dhcp server using broadcast
DHCPDISCOVER from MACADDRESS via ethx
dhcp server offers client via broadcast an IP address
DHCPOFFER on IPADDRESS to MACADDRESS via ethx
client requests IP address via broadcast
DHCPREQUEST for IPADDRESS (DHCPIPADDRESS) from MACADDRESS via ethx
dhcp server acknowledges and lends the IP address to the client via broadcast
DHCPACK on IPADDRESS to MACADDRESS via ethx
The last message can also be the following:
dhcp server does not acknowledge the IP address to the client via broadcast because it detects an IP conflict
DHCPNACK on IPADDRESS to MACADDRESS via ethx
What did we do?
In simple terms, a broadcast is a communication between two computers using MAC addresses instead of using unicast, i.e IP Adresses
Broadcast communication may be computed by any computer in the same subnet because broadcast is essentially a “noise on the wire”. It gets in all the subnet and data is transmitted through all possible ports to all network devices, including computers.
What if we could define a dhcp server authoritative ont for an IP subnet (or several) but instead on an interface and tell this dhcp server to fight any other dhcp server it hears. Since a rogue dhcp server is using the same schematic to talk to a client, it would be enough if, after the rogue DHCP server transmits a DHCPACK signal, our DHCP server would transmit to the same client a DHCPNAK signal. DHCP theory (the RFC defining DHCP operation) states that, in this case, the client should restart all the process with DHCPDISCOVER and so on.
Practice showed that our clients will receive correct IP addresses from this DHCP server after a maximum of 3 DHCPDISCOVERs. Our DHCP server starts to answer quicker and quicker until the client will hear the authoritative DHCP server instead of the rogue one.
While this process comes with a broadcast overhead, it is not important enough as to disturb the network in such a manner as to make communications impossible. It does though kill all rogue DHCP servers, long enough to let us go on the field and disconnect physically the cable going to the rogue DHCP server (the next day) and also allows a correct operation of the clients.