[Snort-devel] Re: [Snort-users] Announce: FLoP-1.0 --- Fast Logging Project for snort

Dirk Geschke Dirk_Geschke at ...802...
Mon Dec 1 01:14:02 EST 2003

Hi Bamm,

> A while back (pre-barnyard) we decoupled the output process from 
> snort using unix sockets. The 'interface' that reads the socket 
> also LOADs the data into the DB. Our implementation was meant as 
> a temporary solution until a more robust capability could be developed.
> Unfortunately, our funding was pulled before that could happened
> and now I am left 'maintaining ' the current code. It all works well 
> with one exception that may be found unacceptable by various users 
> (and I assume flop would have the same problem). If the 'read' process
> dies/hangs/needs to by HUP'd or whatever, any alerts sent to the socket
> when that process is NOT listening will be gone, buh-bye, adios, etc. 
> I use daemon tools to monitor the process (as well as snort) to make sure
> both stay up. My guess is that unified out/barnyard solution was probably
> chosen by the snort team (and SourceFire) for this reason. We chose this 
> solution and accepted those risks.  I'd expect it be a lot harder to sell 
> the idea (that if the read process 'burps' alerts could be loss) to the
> masses (and SF customers). I _like_ what you've done though and plan on 
> checking it out soon.  I just thought someone had better point out that
> you don't `./snort` and `./flop` and walk away. The admin needs to pay 
> particular attention to how those processes are monitored and to ensure 
> the 'flop' proc won't be down for any measurable amount of time.

the only real problem I found is indeed if no process is reading
from the unix socket. The FLoP approach won't ever block during
a read process as long as the process (sockserv on the sensor
side) is running. The program is threaded, one thread only reads
the data from the socket and stores them in memory. A second
thread waits simply for this data and forwards them to the
central server.

So the only real problem is if the process sockserv is not
running. (But if you restart snort or snort is not running
you have the same problem of missing alerts...)

Further the output plugin of snort can recognize this problem.
So snort won't hang on this problem but for now the alerts
are lost. In principal it is no problem to write these alerts
to the disk or forward them to syslog. You only need to code

Actually snorts prints an ErrorMessage if no process is
listening on the unix socket. Here you can plugin another
output solution. But then you have to take care how to handle
these alerts. Compared with the probability that this may 
happen I simply ignored this problem up to now. 

So simply test it and tell me if this is really a problem. Then
we can think about how to solve it. But I guess that the effort
to code this and survey the problem is too high in contrast to
the probability that this scenario happens.

Best regards


More information about the Snort-devel mailing list