| Main Archive Page > Month Archives > snort-users archives |
This topic creates strong opinions. So here is *my* opinion.
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. ;)
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