Rogue DHCP Server Viruses
peiffer at umn.edu
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
Network Support Engineer
Office of Information Technology
University of Minnesota / NorthernLights GigaPOP
More information about the dhcp-users