Multiple Snort DBs consolidated into a single DB

[Ken Bell <kbell () austin sl slb com>]

Hi

If you guys have found a way to consolidate multiple snort DBs into a
central Snort DB, I would be greatly interested.

> From my experience, the remote DBs all set their SID to 1, which causes a
great collision when the data gets to the central DB. Has someone found a
way around this who is willing to share his experience?

Rgds,

Ken Bell CISSP, CISA






Message: 1
Date: Tue, 25 Mar 2003 15:53:12 -0500 (EST)
From: JP Vossen <vossenjp () netaxs com>
To: snort-users () lists sourceforge net
Subject: Re: [Snort-users] uses of multiple sensors

> 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..."

Ken Bell
Schlumberger Limited
Information Security
--------------------
Classification: Public



-------------------------------------------------------
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