[Snort-users] central logging and buffering

Jason Haar Jason.Haar at ...294...
Thu May 22 04:08:07 EDT 2003

I think a lot of people have missed a point made by the original poster. 
If you have multiple IDS systems, and try to have them logging to any 
central SQL server, then you have a problem with a link outage occurs.

Snorts SQL schema (I'm getting out of my depth here - so no flaming - be 
gentle!) obviously creates situations where IDS-1 wants to create a new 
alert type - which involves updating a table so that "name" => next_sid. 
If IDS-1 has lost access to the central server, then it can't do that 
operation (whether directly or by replication), and so the next 100 
alerts coming in about that alert type can't be finished (started?) 
until the central server is available again.

I've run MySQL in simple master-slave mode with two SQL servers - and it 
worked 100%. I have no idea what could handle the n-master model needed 
in this situation... (i.e. every slave server needs to be able to update 
the central server, and every slave server has to listen to the changes 
made on the central server)

That's why if you check the archives, I've previously asked if anyone 
had written some post-parser that could take the SQL databases from 'n' 
systems, and massage them all together into one big meta-database. e.g 
just so you can do a one-off monthly summary for upper management. I 
have even tried doing it myself. It's doable, but quite a bit of work 
(I've put it on the backburner).

Someone would make a lot of people happy if they could manage it. 
Currently I'm relying on alerting to local SQL AND syslog - and the 
syslog is centralized. That doesn't have any of the complexities of SQL 
and works well - you just don't get the packet dumps basically.


PS: How does Sourcefire handle this with their commercial system?

More information about the Snort-users mailing list