FLoP - Fast Logging Project for Snort

Actual version: 1.6.1


Lastest version of FLoP

Patch for snort-

FLoP - Mailing list

Changes in version 1.6.1

Changes in version 1.6.0

Changes in version 1.5.1

Changes in version 1.5.0

Changes in version 1.4.1

Changes in 1.4.0 since version 1.3.0

Changes between 1.0 and 1.2.3:

Readme files

There are now a lot of README files available regarding several aspects of the project:

Survey of the project

This project uses a modified unix domain socket output plugin of the network intrusion detection system snort. The alerts generated by snort are read from the unix domain socket by another process called sockserv. This process reads from a socket and sends the alerts via TCP to a central server. On the central server a program called servsock reads these data and writes them via an unix domain socket to a database.

So this project is developed for environments with several remote sensors and one central server gathering the informations. With the normal database output plugin there would be several SELECT and INSERT statements via the network which would slow down the INSERT rate. Additionally in this scheme snort is blocked until all data is spooled to the database. The only reason why you will not loose traffic in between is the buffering in the kernel and/or libpcap. If this results in a buffer overrun in the kernel buffer you will not even notice it. In contrast the libpcap will report the dropped packets if it drops them. (With Linux you should use the libpcap version of Phil Woods at http://public.lanl.gov/cpw/ to get useful statistics.)

The advantage of this method is the complete decoupling of the output processing from snort. The programs sockserv and servsock buffer all alerts in cases of a slow network or a slow database access (or a heavy attack is going on generating a lot of alerts in a very short period). Both programs use two threads, one to receive data and one to forward this data either to the central server or to the database.

In addition to avoid an overrun of the internal buffer of the programs there exists a drop feature. Herein the alerts were dropped before they were forwarded to the central server (sockserv) or the database (servsock). A short description of each dropped alert can be e-mailed to a list of recipients.

Finally there is an alert feature which is able to send alerts as e-mails if the priority reaches a given level. This feature is intended to inform an admin on a high level alert. (There is still a problem in the definition of a high level: Is this a high priority value or a low one? This seemed to be changed sometimes between snort-1.8 and snort-2.0.)

Two further programs/features were added:


There exist some extended documentation.

There are also some manual pages available (also part of the documentation).


You can download the actual sources here: FLoP-1.6.0

Maybe I will create some binary packages in the future...

Linux (x86) binaries are no longer available. The reason is the usage of the glibc-2.3:

warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

The reason seems to be that the glibc still needs the dynamic library to use dlopen. But this is needed at least for host name resolving which can use DNS, files, NIS or something else for name resolution. But these methods are defined on startup and not during compilation.

So maybe I will create statically linked files again...

It will run fine on Linux and Solaris. *BSD (except BSD/OS from WindRiver) should work but I did not find the time to test it in detail. Note: Signals are mainly used for statistics and for a clean exit. Here a clean exit means that all buffered alerts are processed before the program exits.

All other operating systems may work as long as they run a unix system.

Problems will arise on a mixture of 32 bit and 64 bit systems. (One reason is the different size of time_t which is used in the pcap format.)

Problems will arise on a mixture of big and little endian systems. Maybe this will be fixed in the future but actually I have neither the time nor do I have any need for this... Starting with version 1.0.1 any connection from a remote sensor with a different endianess as the central server is now rejected.


Advantages of FLoP are:

   instead of processing the output.

There are also some limitations/disadvantages:


The project is set under the GPL Version 2:

Copyright (C) 2002,2003,2004,2005,2006 Dirk Geschke

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.



If you have any suggestions, comments, errors,...: Feel free to send me an E-Mail: Dirk

This document was generated using AFT v5.096