Re: Snort multiple sensor configuration

["Matt Olney" <molney () sourcefire com>]

Stephen,

As an aside, since you're using (I'm assuming SPAN or RSPAN) sessions on the
Cisco switches, make sure that you aren't dropping any packets at the swtich
port.  I've seen installations where they have oversubscribed their SPAN
ports and have lost packets there, rather than on the interface to the Snort
box.

Matt

On Thu, Oct 9, 2008 at 11:15 AM, Stephen Reese <rsreese () gmail com> wrote:

> > 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.
>
> I don't think I'm doing do bad in regards to the packet loss, the
> links to the internet and branch networks are not very fast the the
> machine is decent, 3.2 intel with 4 gigs of ram on a 64 debian OS.
>
> Oct  9 06:55:05 atlas snort[5260]: Packet Wire Totals:
> Oct  9 06:55:05 atlas snort[5260]:    Received:      5100680
> Oct  9 06:55:05 atlas snort[5260]:    Analyzed:      5099871 (99.984%)
> Oct  9 06:55:05 atlas snort[5260]:     Dropped:          808 (0.016%)
> Oct  9 06:55:05 atlas snort[5260]: Outstanding:            1 (0.000%)
>
> Oct  9 06:56:31 atlas snort[5257]: Packet Wire Totals:
> Oct  9 06:56:31 atlas snort[5257]:    Received:      1855372
> Oct  9 06:56:31 atlas snort[5257]:    Analyzed:      1855129 (99.987%)
> Oct  9 06:56:31 atlas snort[5257]:     Dropped:          242 (0.013%)
> Oct  9 06:56:31 atlas snort[5257]: Outstanding:            1 (0.000%)
>
> Oct  9 06:57:08 atlas snort[5254]: Packet Wire Totals:
> Oct  9 06:57:08 atlas snort[5254]:    Received:      1989644
> Oct  9 06:57:08 atlas snort[5254]:    Analyzed:      1989643 (100.000%)
> Oct  9 06:57:08 atlas snort[5254]:     Dropped:            0 (0.000%)
> Oct  9 06:57:08 atlas snort[5254]: Outstanding:            1 (0.000%)
>
> > 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.
>
> I understand this, I'm probably just reading in to some of the
> examples I've seen floating around. The firewall is a new Cisco ASA
> model which is nice but only so nice as it's configuration, hmm, now
> that I think about it maybe it has a method to monitor traffic on it's
> interfaces.
>
> > 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.  ;)
>
> mmm, charts, base :-) anyhow thank you for your insight, I'll keep
> hammering away and see if I can get some useful information out of
> this.
>
> -------------------------------------------------------------------------
> 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<https://lists.sourceforge.net/lists/listinfo/snort-usersSnort-users>list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
-------------------------------------------------------------------------
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