Thu Nov 23 16:36:19 EST 2017
great collision when the data gets to the central DB. Has someone found a
way around this who is willing to share his experience?
Ken Bell CISSP, CISA
Date: Tue, 25 Mar 2003 15:53:12 -0500 (EST)
From: JP Vossen <vossenjp at ...8683...>
To: snort-users at lists.sourceforge.net
Subject: Re: [Snort-users] uses of multiple sensors
> Message: 6
> From: "Cloppert, Michael" <Michael.Cloppert at ...5884...>
> To: snort-users at lists.sourceforge.net
> Date: Tue, 25 Mar 2003 10:52:06 -0500
> Subject: [Snort-users] uses of multiple sensors - reply & follow-up
> My follow-up question is this:
> Does anyone have a good solution in place for multiple, physically
> snort boxes (up to 6 is what I'm thinking)? My options, as I see them,
> 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
> Easy cover-up for an attack (combine DoS & exploits, run free).
> 2) A different instance of mySQL on each system. Obviously this is
> unwieldy, especially from an analysis perspective (6 web browsers up
> 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
> and the central database. Analysts look at events via ACID from the
> 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
> 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
> 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
> 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
> 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,
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
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
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
JP Vossen, CISSP |:::======| jp at ...8684...
My Account, My Opinions |=========| http://www.jpsdomain.org/
"The software said it requires Windows 98 or better, so I installed
More information about the Snort-users