Re: Run an external program

["Jack Whitsitt (jofny)" <seclists () violating us>]

> 2003-03-05T12:14:48 Jack Whitsitt (jofny):
> > If you're writing to a FIFO, snort doesnt block while waiting for the
> > listening process to read in data.
>
> I believe that is only true so long as the reader more or less keeps up
> with the writer; I'm sure FIFOs will have some limited buffering.

Actually, I've run it without the reader process even loaded, and snort
happily keeps adding to it. The way the pipe is created, it leaves it
open-ended...
As soon as I load the reading process, it empties the pipe.


> It should be less hit than writing to MySQL, but I believe direct
> database writes are the slowest snort config. High-performance
> snort->database is done using the unified logfile format and
> Barnyard, again to decouple the (slow) writing from snort.

If he is only trying to signal some reaction based on an alert, you dont
need to send more than 1-bit per alert or so down the pipe. If he needs
more information than just "go", it can be tailored to send only what's
needed vs. the entire alert.
> > If you have a listening client already loaded in memory, it can
> > act directly on the signals without spending time loading and
> > reinitializing.
>
> Yes, although the context switch can become significant (especially on
> Unixes other than Linux where context switching is more
> expensive). But the topic thread is executing an external program
> when there's an alert, and even if the program-executer is
> persistent that'll still be slower.

This is true, but I believe that the original thread also was dealing with
custom code...in which case...the whole process of loading a program for
every alert could be circumvented by just having that program listen to
snort realtime.  If that's not the case, then it still decouples snort
from the execution process.

> A loosely similar concept applies to modern syslog forwarding
> designs. Using traditional (UDP transported) syslog, you may lose
> messages during an overload, but the writer will never stall. Newer
> TCP-based syslog transports offer far better behavior in avoiding
> message loss, at the expense of putting the writer at the mercy of the
> reader.

In the case of the pipe (at least as we're using it), snort has to wait on
nothing other than sending somewhere between 1-n bits of data to a pipe.
Reading can be asynchronous and no data is lost.
Discussion beyond this gets far more into the inner workings of snort than
I feel comfortable speaking about, so I'll leave it here.
-Jack




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users