Topic: Automated Killing of a Rouge DHCP

[RuwanJ]

Hi all,

I am trying to implement "hostname"  based lpr/LPD printing on our system. This is where one could set-up a printer by using a room number instead of using an ip address for the print server. Here is my problem: If someone sets up a rouge DHCP server and passes out an incorrect DNS address the whole system could grind to a halt.

So, Here is what I would like to do..

1. Stop or suspend the DHCP server periodically (5mins?)
2. Scan the internal network for a DHCP server
3. If none found restore DHCP service
4. If one responds,
4a. Find the MAC addr of the offending IP
4b. Start an IP alias on the internal interface to block that address
5.  Send an eMAIL/Page a designated person  

Can this be done within/less-than the timeout period before a client shows an error?

-R

[Bill Talcott]

RuwanJ wrote:
>
> Can this be done within/less-than the timeout period before a
> client shows an error?

Depends on the client. Win9x will only complain if you try to renew the lease while it's down. Win2k (and possibly XP) seems to "check" the network quite frequently. It seems to revert to an automatic IP almost instantly when it loses contact with the DHCP server.

[Bill Talcott]

Also, it seems like it'd be easier to exclude the valid DHCP server from the scan, than to shut it down and then scan for anything. I'm not an expert on the technical details of DHCP broadcasts though...

[David Lovitch]

Simple answer:

This shouldn't take longer than a minute, and all clients *should* only check for DHCP status after 1/2 their lease time is up.  If you have a lease time of 1 day, clients check DHCP servers to renew after 12 hours.  The only problem would be in clients booting up and/or restarting.  They would be stuck on an automatically assigned IP.  This goes for Windows machines, not entirely sure how Macs work, though if they go with the DCHP spec, they should also only renew after 12 hours (assuming a 1 day lease time).

Also: because of the likelyhood of a machine booting/rebooting every 5 minutes, you probably shouldn't scan every 5 minutes.  Perhaps every hour would be more logical unless you are actually having problems and need to track down a malicious user.

http://www.dhcp-handbook.com/dhcp_faq.html under "What are the Gotcha's?" is also a good resource.


Longer more involved junk if you feel like reading:

I'm curious... how do you plan on "scanning" for DHCP?  

I believe it runs on UDP ports 67/68.  If you could use that, perhaps something could be written to check every IP on your network for hosts that respond on those ports.  But then again, how do you determine which IP ranges to check?

It's too bad we can't somehow use information from the switches.  Perhaps then we could get a list of MACs from the switches and then query those MACs to determine who responds on ports 67/68.  But then we also have to figure out what IP each MAC corresponds to.  That would really cut down on the number of IPs to check though, as we would only check MACs/IPs that currently existed on our network.

Once found, how do you intend to prevent new clients from using it?  You mention an IP alias on the internal interface... but which internal inferface is that and how does it help new clients not use it?  Seems like your email/page seems possible and makes sense, but it also seems like it doesn't help at all unless you can, again, interface with the e-rate switches... then you could write some sort of script which connects to the switch and shuts down the offending port, then sends and email/page to the admin/responsible person listing which switch and which port are the problem..... perl + regular expressions could become really handy .

All this could be done without taking down the DHCP servers at all

[RuwanJ]

>Once found, how do you intend to prevent new clients from using it? You mention an IP alias on the internal interface...

I assumed that if an alias can be created on any interface to take on whatever IP the rouge is using, that a conflict will occur and thereby disable the device from the network. Not having tried it, I dont know for sure..

>But then again, how do you determine which IP ranges to check?

Arpwatch might be a good bet to find all the active devices..

This could actually do checking on the fly as devices are detected.

-R