Rogue DHCP Server Viruses

Tim Peiffer peiffer at
Wed Jan 28 18:53:05 UTC 2009

> DHCP services must be secured to thwart this threat.  Anything less
> is a stopgap.  Right now that means ethernet level packet filtering,
> to suppress DHCP 'server' answers from 'client' ports.
That problem was made plain to us several years ago.  We regularly had 
issues with rogue servers popping up wherever someone decided to install 
their NAT, or wireless device, or somehow bridged their wireless port 
and LAN port.  The issues went away when we decided to filter via the 
edge access layer..  The only issues that came up afterward was 
non-centralized DHCP service for things like Disaster Recovery.. 
JumpStart, KickStart... etc.  As we started supporting those 1-off 
applications centrally, we have been able to recover the exceptions and 
improve are security posture.

The problem is not one that the DHCP servers must satisfy.. That problem 
is out of scope for the server and must be handled at the access layer.  
Now I wish I could push those people who use MAC address 
'authentication' (misnomer) out of scope as well, but that is another 

Anyway, a example edge filter config for vendor C might look like:

interface GigabitEthernet X/Y/Z
  ! you have to do this on *every* edge port
  ip access-group Access_IN in

ip access-list extended Access_IN
 remark * Standard Rogue DHCP Servers from customers filter *
 deny   udp any eq bootps any log
 remark * let any "real"  address out.
 permit ip any any

Tim Peiffer
Network Support Engineer
Office of Information Technology
University of Minnesota / NorthernLights GigaPOP

More information about the dhcp-users mailing list