[Snort-users] Database Logging with redundency

Erik Fichtner emf at ...367...
Tue Aug 29 12:52:08 EDT 2000


On Tue, Aug 29, 2000 at 11:04:09AM -0500, Steve Halligan wrote:
> Ok...here is the situation.  Multiple remote machines running snort all
> logging to a central mysql database.  What if the central database
> server goes down?  Is there any way to build some sort of redundency
> into this system?  

Likewise, another thing I've been thinking about is how do I upgrade my 
database without having to touch a bunch of sensors?    

I'm actually thinking that I need to redesign the architecture and use more
db hosts and then have the master correlation engine reference multiple
database systems instead of just one, but that can get messy and I'm not
really looking forward to it.   Your idea of dumping the database and inserting
it into a larger master database might come in handy, though. 

> I know it would be better to have the remote machines log to a
> local mysql and then have cron do a mysql dump and send the file over to
> the central database server, but then I would not have real time access
> to the data at my central mysql server. 

Well, "real time" is relative anyway.  Most of the really interesting stuff
can't be done in "real time" because you have to grovel over the data for a
couple hours looking for patterns.  

Sure, i know you want minimal time between picking up something like a
peice of shellcode flying over the wire and it actually alerting you on
the console.

you can probably get away with 5 to 15 minute db inserts.   If you have 
specific needs for absolute instantaneous notification (eg, shellcode spotted)
then having another sensor dedicated to spotting that sort of thing is 
probably the way to go.

> What to do here?  Can I run
> snort twice with one logging to local mysql and one to remote?  

Another thing to worry about here is the additional load on the system from
having multiple sniffers running.  You don't want to lose packets.  (although,
i've found that current systems have entirely way too much CPU and this is
becoming less and less of an issue.)   

-- 
Erik Fichtner
Security Administrator, ServerVault, Inc.



More information about the Snort-users mailing list