topics that matter; ideas worth sharing

share a tip, submit a link, add something new

Address unknown, part 2

December 11, 2000, 03:18 PM —  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 href=http://mithras.itworld.com/articles/columns/net-currier-0317.html>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?

» posted by abennett

ITworld.com

I like it!
Post a comment
The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
Resources
White Paper

Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.

Webcast

Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.

White Paper

Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.

Free stuff
Featured Sponsor

Get a broad understanding of important regulations and how you can make sure your site is in adherence.





Learn how VeriSign SGC-enabled SSL Certificates can help improve site security and customer confidence in the free white paper, "How to Offer the Strongest SSL Encryption." In this paper you will learn the differences between weak and strong encryption and what they mean for your site's performance.

Get VeriSign's free white paper: "The Latest Advancements in SSL Technology" and learn about the benefits of strong SSL encryption, Extended Validation (EV) SSL and security trust marks and what these SSL offerings can do for your site.

Now with Extended Validation (EV) SSL available from VeriSign, you can show your customers that they can trust your site. Learn about EV SSL benefits in this free VeriSign white paper.

More Resources