Re: uses of multiple sensors

[JP Vossen <vossenjp () netaxs com>]

> Message: 6
> From: "Cloppert, Michael" <Michael.Cloppert () 53 com>
> To: snort-users () lists sourceforge net
> Date: Tue, 25 Mar 2003 10:52:06 -0500
> Subject: [Snort-users] uses of multiple sensors - reply & follow-up question

<snip>

> My follow-up question is this:
> Does anyone have a good solution in place for multiple, physically separated
> snort boxes (up to 6 is what I'm thinking)?  My options, as I see them, are
> the following:
>
> 1) Configure snort to pump data to a mySQL instance on a separate system.
> The problem with doing this is that if a network segment goes down (think:
> DoS) then suddenly I lose all forensic data to that portion of the network.
> Easy cover-up for an attack (combine DoS & exploits, run free).
> 2) A different instance of mySQL on each system.  Obviously this is terribly
> unwieldy, especially from an analysis perspective (6 web browsers up looking
> at 6 different ACID screens?  ACK!)
> 3) Different instance of MySQL on each sensor, and also a central mySQL
> instance.  Configure snort with 2 output databases: the local mySQL instance
> and the central database.  Analysts look at events via ACID from the central
> database.  This fixes the problems with (1) and (2), but couldn't this get
> terribly CPU-intensive?  I've heard multiple output plugins can REALLY kill
> snort's capacity.
> 4) Different instance of MySQL on each sensor, and also a central mySQL
> database.  Configure snort to output only to the local database, and on a
> short schedule (say every 5 mins) pump new events to the central mySQL
> database via fun scripts & such.  Analysts look at events via ACID from the
> central database.  This fixes the problem in (3) but creates two more: a)
> pain in the butt scripting it all up, and making sure there are no duplicate
> sid/cid pairs on the central database; b) the central database, which is
> what analysts will see, is only as up-to-date as my replicate schedule from
> the remote sensors.
>
> Anyone with experience in multiple-sensor environments - if you have
> comments or recommendations, by all means let us know!!!


(Sorry about the long quote above, but I couldn't see what to cut and still
keep coherent context.)


I have not implemented multiple sensors in practice, but it seems to me that
the following would address all of your concerns.

Give each Snort sensor 2 NICs.  The first would preferably be unnumbered, the
second on an isolated management network (ideally phsically isolated, if
possible).  The unnumbered interface sniffs the monitored segment, the other
is the reporting and management interface, which logs/alerts to the central
DB.  If that segment is isolated properly, there is little chance of a DoS
killing it.

But just in case, have Snort log to a tcpdump file locally on each sensor.
That is relativly fast from what I understand, and I'd think you could later
re-read it using a command line Snort to import any missed data into the
central DB.  You'd need to take care to purge these files regularly to avoid
filling up the sensor disk space of course, so there is some scripting
involved.  But I'd think it'd be easier than the DB merges you describe above,
and it gives you very handy tcpdump files to play with (lots of info on the
'Net about dissecting those.  See The Honeynet Project for starters).

The central DB server should probably have 2 NICs also, 1 to get the traffic
from the isolated network the sensors report on, and the other on the
"regular" LAN so people could web browse to it to view events.  That server
would then also be the staging point for access to the sensors for management
and updates.

My $0.02,
JP
------------------------------|:::======|--------------------------------
JP Vossen, CISSP              |:::======|                jp () jpsdomain org
My Account, My Opinions       |=========|       http://www.jpsdomain.org/
------------------------------|=========|--------------------------------
"The software said it requires Windows 98 or better, so I installed
Linux..."



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
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