[Snort-devel] Plugin API Feature Request

Eric Lauzon eric.lauzon at ...1967...
Mon Feb 13 09:23:04 EST 2006

> Yes, I was not very clear in my last mail, sorry for that.
> I will try to be clearer in this mail even if this means that 
> the mail will get long.
> I agree that it is not very optimal to break the pcap loop 
> for performance reasons, but I am not sure how one could 
> address the issues in another way. That is why I wanted to 
> start a discussion. I think the best way currently is to have 
> two version of the main loop:
> - one with pcap_dispatch if there is a plug-in loaded who 
> benefits from it
> - one with pcap_loop for those who only need the speed.
> Maybe I should first tell you something about the context. We 
> are trying to build a new and highly experimental output 
> plug-in for snort. The idea is to fork a child process or 
> second thread depending on platform which handles the 
> output-plugin so that the snort decoder is not blocked by the 
> output. The goal is to reduce sensor deployment complexity.

If we talk about blocking , spo_unified does not block and it is
probably the 
most efficient way to log alerts you can find, from there i guess
you can implement any fantasies you want to output it anywhere
aka barnyard.

> While working on this plug-in, I found these issues with the 
> current snort plug-in API:
> (issue 1 : callbacks in signal handler context)
> CleanExit() callback is currently called from a signal 
> handler context.
> On many platforms this means that it is not safe to call any 
> libc function that is not known to be re-entrant 
> (thread-safe). This can lead worst case to a segfault killing 
> snort. The problem is, that CleanExit() is also called when 
> snort receives a SIGHUP - to reload its configuration.

> We wanted to log the reload / shutdown of snort in the 
> database as a kind of meta-alarm, but I cannot execute an SQL 
> statement in my
> CleanExit() callback, because it is called asynchronously to 
> the packet logging. It is therefore quite probable that the 
> database connection is midway in the execution of another 
> statement from the packet processing callbacks, and logging 
> the reload/shutdown event will result in desynchronizing the 
> db connection instead of logging anything.
> Also, if I start threads or child processes from my output 
> plug-in in order to decouple logging from the detection 
> engine of snort (i.e. see prelude plug-in), then I cannot 
> cleanly shutdown these threads / childs because any call to 
> libc is dangerous, and could kill snort when reloading the config.

For child/thread awareness for thread and signal , you could register 
a thread list [pid list] and exit in the signal handler you can check
[pid check]
for thread presence and exit and let only 1 calle to do the exit hence ,
the parent.

This simple signal check will avoid to call unsafe context
in CleanExit to avoid to change CleanExit global purpose.

> Currently the prelude plug-in is suffering from this as well. 
> If you have prelude logging enabled and signal SIGHUP to 
> snort, you will end up with zombie processes.
> This is fixable by a pcap_dispatch instead of pcap_loop in 
> the main loop. The signal handler would just set a global 
> variable which is queried to exit the main loop. After this 
> the CleanExit() handlers can be called.
> This might however have an impact on performance.

And in the context your exposing , what i might see being dangerous
is that your highly new output module is using direct database
connection [or seem to],
in this case you expose your IDS to severe dependancy , even if you use
shared memory or named pipe to pass information from the "IDS
to the "logging thread/process" you might experience blocking,buffer
that might be caused by the database end , and probably thats not what
you want to happen.

> Steven Sturges [steve.sturges at ...402...] wrote on 
> 09.02.06 14:52 CET
> > We are already working on rearranging the main loop and using pcap 
> > dispatch.  We are also addressing the non-reentrant nature of the
> 2.4.x 
> > signal handlers along with this set of changes.
> I was very glad to hear that. So hopefully, the next snort 
> release will already have solved the CleanExit() issues.
> (issue 2 : no regular callback for heartbeat functionality available) 

> It was also one of the goals to have a kind of heartbeat from 
> the sensors. Every N seconds, it should send a heartbeat to 
> the database, saying that it is up and running, and also 
> giving some status about the system (i.e. total number of 
> pakets, number of dropped packets and CPU
> usage) It is important to get this heartbeat from the 
> detection thread / process, because then we can supervise the 
> whole logging path, from the detector, via logging thread to 
> the database.

> I can currently do this in the packet processing callbacks 
> and check each time if I should send the next heartbeat. But 
> what if no packet arrives for more than N seconds? At the 
> moment I can't tell a dead sensor from a sensor without 
> traffic, which somehow makes the whole heartbeat idea somehow useless.

> It would also be interesting to use heartbeat callback to 
> feed commands to a sensor via the database, i.e. the 
> heartbeat callback could poll for a pending command. (i.e 
> reload,stop,...)

I guess "heartbeat" like implementation should be left to the users to
as long as you implement it in a way that you can process it there is
way where you can plug your heartbeat code.

In out case , it is implemented as a preprocessor for quick changes in
What you might want to see as a problem is that there is no heartbeat if
there is no packets.

Well it seem like the pcap_dispatch() approach changes suggests could be
in part a work arround for this
but still you want to know when there is no packet on your network ,
hence a special heartbeat type
that inform you that after N pcap_dispatch call you still dont have
packet on your interface 
[somemone accidently pulled the plug on your tap?]. But before
implementing our pcap_dispatch()
behavior we will wait to see if sourcefire will tend to use this , but
for some reasons i have 
a feeling about some wrong uses of the code that could be putted out of
the pcap_dispatch() call that
could bring to some overhead where if they dont use buffered libpcap ,
might start to drop packets out
of the buffer. Anyhow we have seen the issue arise from its self since
it has been implemented where
somtimes the network is just slient, but in most of those cases , there
was something wrong on the wire.

> Jeff Nathan [jeff at ...835...] wrote on 13.02.06 13:03
> I am not sure I understand your solution correctly. I think 
> you are calling libevent's event_loop() whenever there is an 
> alert to be logged.
> But when there is no alert for a long period of time, and a 
> heartbeat should be sent, how (from where ?) is the callback 
> then called ? This is the part that I don't understand... I 
> think it has to be called form an alarm handler, and then I 
> have the same issues as in (1).
> If snort will change in the near future to a pcap_dispatch 
> main loop exit the packet handling from time to time (i.e. 
> once a second) to handle signals, there is another way to add 
> heartbeats to snort.
> time_t last_heartbeat;
> time_t between_heartbeats;
> while(running) {
>    // ... snort main loop ...
>    if (last_hearbeat + between_hearbeats < time()) {
>      call_plugins()
>    }
>    // ... snort main loop ...
>    pcap_dispatch(...);
>    // ... snort main loop ...
> }

> (issue 3 : callbacks at end of initialisation )
> This is a just a minor issue. We wanted to be able to save 
> the whole ruleset of snort at startup to the database, 
> instead of checking for each alert if the corresponding 
> signature was already saved in the database as the current 
> spo_database.c does it. But the problem is that at 

spo_database ...wrong :/

Couldn't sourcefire clearly inform userbase about some of the issues
spo_database has?
I know they recommend spo_unified but seem like an spo_database removal
could help people
to see it differently.

Hope to feed the discussion.

Have a nice day.


Le present message est a l'usage exclusif du ou des destinataires mentionnes ci-dessus. Son contenu est confidentiel et peut etre assujetti au secret professionnel. Si vous avez recu le present message par erreur, veuillez nous en aviser immediatement et le detruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.


This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and may contain privileged information. If you have received this communication by error, please notify the sender and delete the message without copying or disclosing it.

More information about the Snort-devel mailing list