Can you imagine a search engine that deliberately returned bogus addresses? Instead
of receiving the list of wineries that you expected from your search on href="http://www.amazon.com/exec/obidos/ASIN/B00004YLJF/itworldcom">cabernet
sauvignon, suppose the search engine returned a list of sites that appeared
valid, but didn't exist -- when you clicked on the links the only response you got was
the dreaded "404 Not Found." I suspect that you would be pretty irritated.

That's pretty much the situation we recently found ourselves in at Duke University.
It seems that the latest hobby among our student population is the creation of bogus
dynamic host configuration protocol (DHCP) servers, which are making it impossible for
some students to get to network resources.

DHCP allows network administrators to assign IP addresses automatically. DHCP is a
direct descendant of the boot protocol, or BOOTP. DHCP improves dramatically on BOOTP
by providing a method to reclaim unused addresses, adding mobility, and, most
importantly, offering promiscuous addressing, which is the ability of the
server to provide an IP address to a machine it doesn't have in its address table.

By using promiscuous addressing, we're able to serve up more than 6,000 IP addresses
to our students with zero hassle. We configure the server to hand out addresses each
time it sees a request and tell the students to set their machines to use DHCP. Boot
the machine, get an address -- it's that simple.

So what's the big problem? Anybody can bring up a DHCP server and offer addresses,
and those addresses don't have to be valid for the network segment they're being used
on. Giving a host on network 152.16.3.0 an address of 10.0.1.99 is a guaranteed method
of making sure that the host can't communicate. And around exam time, it's a sure way
of really annoying students trying to get last-minute work done.

The worst outbreak of false addresses we've seen recently took us almost a week to
resolve. We began getting complaints from our help desk about network problems on
ResNet, the campus residential network. When we spoke with the students who were having
difficulties, we discovered that their IP addresses had changed from the proper
network -- 152.16.x.x -- to a private network number, such as 10.0.1.35. Somewhere out
on ResNet a rogue DHCP server was handing out bogus addresses. And because the rogue
server was on the same side of a router as the clients requesting addresses, it usually
beat our enterprise DHCP server to the punch.

We evaluated the situation and decided that the best way to track down the bogus
DHCP server was to take advantage of the intrusion detection systems we built a few
months ago. I'm a big believer in building multipurpose tools and, as it seemed likely
that more stray DHCP servers would pop up, we wanted to put a system in place that
would continuously monitor for them.

In my next column, I'll describe what we put in place, show you how we configured
it, and give you pointers on setting up a similar installation. Until then, check out
these resources:

• DHCP
• Snort
• Snortsnarf

» posted by abennett

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine