Snort mailing list archives
Re: Snort multiple sensor configuration
From: Jack Pepper <pepperjack () afferentsecurity com>
Date: Thu, 09 Oct 2008 08:34:08 -0500
This topic creates strong opinions. So here is *my* opinion. - opinion follows - opinion follows - opinion follows in a multi-nic deployment dropped packets are the biggest concern. Watch the dropped packet counts closely. more than 5% means you're wasting your time. Sniffing outside of a properly configured firewall is wasteful. Do you really need an IDS to tell you that the firewall is blocking lots of bad traffic? It's a firewall! That's what it does! Make sure it's configured correctly, make sure it's a quality firewall, then let it do it's job. If you don't trust your firewall, solve that before deploying an IDS. Crappy firewalls are a curse because once it's installed you're usually stuck with it. Most IT organizations cannot politically repace a "working" firewall with a "good quality" firewall. It's usually not about money, it's usually about brand loyalty, training curves, fancy reporting tools, and religion. Once you trust the firewall, you can stop trying to process packets that are never going to reach your network anyway. You can't defend a network that does not have rock-solid firewall protection. Don't load up "all the rules". If you load up too many rules, you will be dropping packets. If you can keep the dropped packet counts down (<5%), your IDS will function very nicely. When the IDS is new, you need to find out what's "normal" for your network and tune the sensor to understand "normal". Start by unloading application exploit rules and loading up "equipment misconfiguration" rules. Load up rules that indicate heretofore unknown problem areas, like clear text passwords and devices sending out TFTP broadcast requests. Misconfigured devices, leaking firewalls. Solve all those problems first. You can't defend a jacked-up network. Once all those rules go quiet, load up the malware and spyware rules. Fix those problems. At this point you will observe that you need a black-hole DNS server. Once all *those* rules go quiet, you can really run a tight defense against the remaining problems as they come up. Or you can just make pretty charts all day and possibly get a pay raise and a promotion. ;) - end opinion - end opinion Quoting Stephen Reese <rsreese () gmail com>:
I've recently setup a Debian host running snort 2.8.3.1. There are four nic's in the machine, one is a management interface and the other three connect to various network points. Internet (sensor) <firewall> (sensor) main network (sensor) <router> branch networks The first IP is the Internet so we may see everything coming at it. The first network is the "main network", we want to see everything the firewall misses or if any of our hosts are being naughty so there is a sensor on that side of the firewall. The other networks that follow are all branch networks connect via T1 we want to make sure that the main network isn't sending out or receiving anything naughty. I'm using sessions on three Cisco switches to create the taps. I'm currently running a process for each sensor 1-3: $ sudo /usr/local/bin/snort -c /etc/snort/snort.conf -i eth1 -D The basic network configuration is my question. I'm currently using the same configuration file for all three processes. var HOME_NET [66.15.39.1,172.31.1.0/24,172.31.2.0/24,172.31.3.0/24,172.31.4.0/24,172.31.5.0/24] var EXTERNAL_NET !$HOME_NET I've got the ruleset wide open so there is all kinds of alerts at this point and I know I have to cut them back after we figure out what's useful, but are my definitions accurate for the network layout or is there a better method I should be following. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
-- Framework? I don't need no stinking framework! ---------------------------------------------------------------- @fferent Security Labs: Isolate/Insulate/Innovate http://www.afferentsecurity.com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- Snort multiple sensor configuration Stephen Reese (Oct 08)
- Re: Snort multiple sensor configuration Jack Pepper (Oct 09)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Message not available
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Message not available
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Re: Snort multiple sensor configuration Joel Esler (Oct 10)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 10)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Re: Snort multiple sensor configuration Jack Pepper (Oct 09)
- Re: Snort multiple sensor configuration Matt Olney (Oct 09)
- Re: Snort multiple sensor configuration Jack Pepper (Oct 09)
- Re: Snort multiple sensor configuration Stephen Reese (Oct 09)
- Re: Snort multiple sensor configuration Matt Olney (Oct 09)