Thursday, December 20, 2007

Generic Snort Advice:

I got an email about the Snort User Group that I had run in the past. Local interest waned, and I got a new job. Once in a while I get a contact via email. Here's my recent response:

I don't know your setup or the threats you face, but my generic advice is to place Snort on a separate box inside the firewall, so it doesn't have to analyze traffic the firewall will block. The general consensus is that there's too much scanning, worm attacks, etc. for the data outside the firewall to be any use. There won't be much stuff where you'll say, "Aha! I gotta do something about that!" There will be enough stuff inside the firewall to worry about. The firewall logs will give you that data if you have the cycles to do something with it.

One reason to use a separate box: a problem with Snort won't sever your internet connection. There are always problems with host management, like running out of disk space or hardware failure, and Snort has had a few problems itself.

Other generic advice: I found the major problem with doing Intrusion Detection was efficiently processing alerts. For my money, nothing beats the sguil console. It's awesome, and it's free. I would not bother with Arcsight, or Cisco's SIM console even if they were free. Sguil puts all the things you need to see over and over right on one page. And when you need to go deeper, you have the whole tcpdump. When you need to see what else might have happened, you have all the session data. Easy asci protocol decodes so you can see the http sessions. There's an IRC channel for it on Freenode, #snort-gui. The primary developer is on there most days, and is incredibly tolerant of n00bs. Martin Roesch and Richard Bejtlich are among the other notables who can be found there. There are VMware appliances available to try it out. Setup is a little daunting, but if you stick it out you'll be really glad you did. http://sguil.sourceforge.net

Another issue is tuning Snort, which is an ongoing maintenance issue. Shutting off noisy sources of false-positives is a big job, and you don't want to start over every time you update the ruleset. There's a script called Oinkmaster which makes it a lot easier. Make your changes to the oinkmaster file, and apply it to each new ruleset. Suppression directives are another supplemental approach; they let you ignore results for particular hosts for particular rules, while leaving the rule in force for everything else.

There's a lot of information out there. Let me know if you have questions and I'll try to point you to some of it.

0 Comments:

Post a Comment

<< Home