DHCP Server DetectorWhat happens if your user brings home a new router and plugs the LAN side into your WAN by mistake? Disaster - unless you run Rogue Detect! |
Documentation
Rogue Detect DHCP Server Detection The library and simple script included are made possible by Oregon State University Open Minds. Open Doors. Open Source. http://oregonstate.edu Written by Alex Schumann for the OSU ResNet, fall 2003 ---- Quick and Easy ---- REQUIREMENTS You'll need some CPAN stuff to make this work. * Carp * Net::RawIP * Data::Dumper * FileHandle * POSIX (to do fork() stuff) * Net::SMTP (to send email) I've only tested this with the one box I wrote it on at this point, its Debian Linux (woody -- though with some sid/unstable packages installed) I don't see any reason it wouldn't work elsewhere though. INSTALL * Unpack the DHCPDetect.pm and dhcpdetector.pl files somewhere * Install required perl libraries (www.cpan.org) (in debian try 'perl -MCPAN -eshell') * Edit dhcpdetector.pl - add your DHCP server's IP addresses, your email address, and edit the defaults to your taste. * set dhcpdetect.pl executable (chmod u+x dhcpdetect.pl) * run dhcpdetect as root: ./dhcpdetect.pl ------------------------- ---- Details ---- dhcpdetect has two modes available: continuous scan mode, and single scan mode (default). * Single Scan mode (default) will send a single DHCPDISCOVER packet to the network and wait a configurable number of seconds for unauthorized servers. * Continuous mode will continue to run, sending DHCPDISCOVER packets everyminutes, sending out alerts etc. Single Scan mode is good for running from the commandline periotically or from a cron script, while Continuous mode is good for letting the detector run indefinately. SYNTAX: dhcpdetect.pl --continuous [--freq=x] [--iface=interface] [--nodaemon] [--verbose] [--debug=x] OR dhcpdetect.pl [--waitfor=x] [--iface=interface] [--verbose] [--debug=x] --continuous Cause the program to run in a loop, sending DHCPDISCOVER occationally and listning for replies --nocontinuous (default) Send only one DHCPDISCOVER and wait only long enough for a response. Then quit. (for commandline or crontab use) --freq=x In continuous mode only: how long between DHCPDISCOVER packets --waitfor=x In normal (non-continuous) mode only: how long to wait after sending a DHCPDISCOVER for replies. --iface=interface Network interface to use (eg eth0). Unfortunately only one can be done at a time (sorry) run multiple copies for now. --daemon/--nodaemon in continuous mode only: wether or not the program should fork and go into the background. Default is yes. --verbose Give details -- currently not well supported. use debug=1 --debug=x Debug level. 1-5 supported. 1 is good for info. higher levels give more information. -- Bugs -- * Continuous mode could have memory leaks. I havnt' checked (yet) -- Notes -- Sending a DHCPDISCOVER packet causes any DHCPSERVERS listning to allocate an IP address for a few seconds, while they wait for the detector to ACK their offer. Since we never do send an ACK, the IP is not allocated to us. Hence, it should be ok to run this on the network.. but do so at your OWN RISK!! This package is nice in that you do not have to have a clear view of the network to run it (ie, it works behind a switch). You DO have to be within broadcast range, which usually means on the same subnet as the DHCP server. In some cases scaning port 68 (67?) on every machine may be the better answer to finding dhcp servers, but with this program, as apposed to a passive one like snort, you do not have to be able to see traffic not destined for you. Our resnet has 4 subnets, so I use a linux box with 4 pro100b's in addition to its onboard network. Each pro100b is plugged into one subnet. In linux they are eth1, eth2, eth3, and eth4, so I must run 4 copies of dhcpdetect.pl, one for each interface. This project is extremely hastilly done, as the students are comming soon and we needed something working, but many other urgent projects (such as protecting ourselves from the mountan of RPC vulnerability exploiting worms) will keep us from doing much more with it in the near term. (ie, dont look at the code and scold me, i know its ugly :) If you have questions please contact me alex.schu__NOSPAM__REMOVE__mann@oregonstate.edu Enjoy
Last modified
2006-01-20 12:47 PM