[Snort-users] Snort multiple sensor configuration
pepperjack at ...14319...
Thu Oct 9 09:34:08 EDT 2008
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
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 at ...11827...>:
> I've recently setup a Debian host running snort 188.8.131.52. 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
> 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
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> Snort-users list archive:
Framework? I don't need no stinking framework!
@fferent Security Labs: Isolate/Insulate/Innovate
More information about the Snort-users