[Snort-users] central logging and buffering
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