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 every  minutes,
  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