Re: *very* many snort installations..

["Shane Smith" <shane () crownbank com>]

In most successful IDS setups, there is already a snort box behind your
firewall, configured on the switch to be a "mirror port" for all traffic.
Simply putting Snort boxes in front of your firewall's isn't enough, as you
won't know exactly what gets through.  A setup with both and inside and
outside sensor, will show you both attempted intrusions and actual
intrusions respectively.  Also, an internal sensor can be used for policy
management and compliance, such as making sure no p2p traffic is flowing
inside your network.

As far as installing Snort on *every* workstation, that seems very
redundant.  You should only need one sensor on any physical segment, since
all the workstations would be watching the same traffic.  This could cause
several hundred alerts to be triggered, even for just one bogus packet.

For management, I've had success with oinkmaster
(http://oinkmaster.sourceforge.net/)  auto-updating the rule sets.  While I
haven't run into problems yet, I loath the day a bad rule sneaks it's way
into an update, and snort doesn't start back up.  I use BigBrother
(http://bb4.com) to watch all my sensors, and make sure the snort service is
running.

In the scenario you describe, it would almost be worthwhile to have a
separate BB4 installation just to monitor all your Snort sensors.  You can
also use BB4 to watch a logstream, or in my case a MySQL db with all your
alerts.  External alerts (attempted intrusions) don't raise any alarms until
traffic becomes excessive, but any alert on an internal sensor (potentially
an intrusion) causes the bells and whistles to go off.

The thing to remember with Oinkmaster is that once implemented, you do most
of your ruleset configuration there, instead of in snort, otherwise changes
you make will be overwritten during any update.  If you script this, you can
do like I do, and have the script retrieve an updated ruleset config file
prior to any update from a central location.  Doing this, will cause all
your sensors to have the same, current rules, and you only need modify one
file.  The previous ruleset used is stored "just in case" I need to
rollback.  On a large deployment, needing to role back could be a real pain,
and you don't want to be left snortless until you do.  I suggest additional
scripting, and possibly having your oinkmaster script check your central
repository for updates frequently.  Then if you need to role back, if you
scripted and configured everything correctly, you could simply change your
central ruleset again, and wait for that update to propagate, and snort to
start back up.

So yes, you can *fake* central management of Snort via scripting on your
sensors, and watch them all via BigBrother.  It may be a pita to get there,
but you'll be very happy when you do.

That's my story....
-Shane


----- Original Message ----- 
From: "Mokum" <snort () meij net>
To: <snort-users () lists sourceforge net>
Sent: Wednesday, November 26, 2003 8:45 AM
Subject: [Snort-users] *very* many snort installations..


Greetings,

I was requested to look into the possibility to install snort as a
service on 'all' [XP only] workstations [*way* over 10.000] of a very
large, very global organization.

The goal is to have a better insight in the 'known bad' data flows
though out the network. Of course, the main parts of the network are
already IDS'ed so the workstation installation would be a sort of
extended sensorium to make sure we see things behind the routers,
switches, nat'ing devices & firewalls that normally go undetected untill
things go really really wrong.

The well known pitfalls of rollouts like these that I am aware of are:
- the managebility:
       - collection of events
       - the number of the events

- the QA
       - snort.exe
             - stability of the service
             - resources needed
       - quality of the rules implemented

Not my problem is:
- the installation & distribution of the service, this is done for about
1000 other applications too.
- the updating of the rules [is part of the distribution]

My question is if anybody on the list has expirience [good or bad] with
a concept like this? Any pointers?

Cheers,
mokum




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
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





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
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