Fast Logging Project for Snort 1.6.0

Fast Logging Project for Snort is designed to gather alerts with payload from distributed snort sensors on a central server and to store them in a database (MySQL and PostgreSQL are supported).
On the sensor, the output is written to a process called sockserv. This process is threaded; one thread receives and buffers the alert packets, and the other thread forwards them to a central server.
The output is decoupled from snort, which can proceed in sniffing instead of waiting for the output plugins. At the central server, a process called servsock gathers all alerts from the remote sensors and feeds them to the database.
A short description of alerts with high priority together with the database ID can be sent via email to a list of recipients.
Main features:
- Decoupling of the output from snort. Snort can work on new packets instead of processing the output.
- Buffering of alerts on the sensor. This is useful if you have a shortage on your network to the central server or the servsock process on the central server is not running (maybe it will be restarted due to a change to a newer version...)
- Buffering of alerts on the central server. It is not uncommon that the database (especially MySQL) is hanging during a high input rate or the rate is faster than the database is able to store.
- Fast writing to the database via an unix domain socket.
- E-Mail alerting on high priority alerts.
- Drop feature for the worst case. At least the basic alert informations are still available either via E-Mail or on stdout/syslog.
- Since version 1.0.6 the alerts which should be dropped on the central server if servsock exits are written to a swap file. So this data is still availabe.
- If alerts have to been dropped because the high water mark was reached then these data are not written to the swap file.
Enhancements:
- Several checks were added, the alert data from Snort got a tag, and a restart of Snort is now checked.
- getpacket now has base 64 support.
- The statistics are now generated via the control thread so some signals are no longer necessary.
- The exit handler was rewritten and a cache for signatures was added.
- This cache can accelerate the insert rate by up to a factor of two and is implemented as a red black tree.
- During runtime, the only SELECT statement is for the signature ID, and all other operations are INSERT statements.
- The idea is to cache all signatures that caused an alert.