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: