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 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 188.8.131.52 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: