Address unknown, part 2

ITworld.com –

In our last column we talked about the problems we faced when a rogue DHCP server came to life on our residential network. In this installment we'll show you how to use Snort, the lightweight intrusion detection software, to grab the beast by the throat and put an end to its bad behavior.

Taking advantage of the flexible rules language of snort, we quickly cranked out a DHCP server detection rule set. Our generic rule looked like this:

    alert udp !$RES_NET 67 -> any 68 (msg: "Rogue DHCP server...");

This rule tells snort to generate an alert if it sees a udp packet originating from a network other than the home network -- in this example our residential network -- with a source port of 67 (DHCP server) destined for port 68 (DHCP client) on any host.

The rule worked fine. In fact, it worked too well. Snort was detecting our enterprise DHCP servers and generating tremendous amounts of logging data. We needed a way to eliminate the valid traffic while still detecting rogue servers. Snort's pass alert mechanism did the trick:

    pass udp 152.3.250.1 67 -> any 68;

    pass udp 152.3.250.2 67 -> any 68;

    pass udp 152.16.2.250 67 -> any 68;

    alert udp !$RES_NET 67 -> any 68 (msg: "Rogue DHCP server...");

The new rule set should have done the trick. But it didn't. We were still seeing traffic from the hosts we had told snort to ignore. What was going on?

Digging through the snort documentation we discovered that snort reads in all the rules at execution time. The rules aren't evaluated in the order they are written. By default snort reads rules in the following order: alert, log, pass. Evaluating the rules in this sequence prevents a bad pass rule from defeating fifty valid alert rules.

Fortunately for us snort provides a means to reverse the order of evaluation: the --o command line option. Once we kicked off snort with the --o option our rule set worked perfectly. Traffic from our enterprise servers was ignored and snort concentrated on looking for rogue servers. And it didn't take long to find our problem:

    Xxxxx xxxxx xxxxxx 169.x.x.x.-> 10.0.1.35 .xxxx Rogue DHCP server...

It turned out that student had installed an Apple Airport wireless hub in his dorm room. He hadn't changed the default settings on the Airport and it was happily acting as a DHCP server and handing out addresses in the 10.0.1.0 private network space. We tracked the MAC address of the Airport hub to a dorm room and deactivated the port. A quick phone call to the student and the mystery was solved.

We've left the DHCP server detection rules in place and have picked up several other rogue servers. We use snortsnarf, a perl application mentioned in Part 2 of our IDS series, to parse the snort alert files and generate HTML pages that we check once or twice a day. Using snortsnarf is much easier than trying to go through snort's voluminous alert files by hand.

DHCP's biggest asset -- promiscuity -- is also its biggest problem. Using defined address tables isn't an option when you're serving up 6,000 addresses. Until we're able to authenticate and encrypt the traffic between our enterprise DHCP servers and their clients we'll be forced to hunt down and exterminate the rogue servers on a case-by-case basis. We desperately need authenticated DHCP. DHCP working group, are you listening?

Top 10 Hot Internet of Things Startups
Join the discussion
Be the first to comment on this article. Our Commenting Policies