Address unknown, part 2
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
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?