Snort mailing list archives
Multiple Snort DBs consolidated into a single DB
From: Ken Bell <kbell () austin sl slb com>
Date: Wed, 26 Mar 2003 13:06:03 -0600
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
Current thread:
- Multiple Snort DBs consolidated into a single DB Ken Bell (Mar 26)