[Snort-devel] Plugin API Feature Request

Thomas.Seiler at ...2736... Thomas.Seiler at ...2736...
Mon Feb 13 10:21:06 EST 2006


Eric Lauzon [eric.lauzon at ...1967...] wrote on 13.02.06 18:23

> 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
afterward, aka > barnyard.

I agree. But, the point of our specific plug-in is to have something
that is very easy to deploy and survey (aka one single binary, one
process to start, one single config-file) and, I don't want to discuss
the details of our specific experimental plug-in here because it is not
yet ready for prime time. Instead I want to discuss the snort plug-in
API. I was using my case as an example in the hope to show what features
could be interesting for plug-in writers.

> 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.

Nevertheless it will still not be possible to generate a "meta-alert"
that logs the shutdown / restart of the sensor, because during a call to
CleanExit() the normal alert logging may be midway inside the logging
process for the previous alert.

> 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
> thread/process" to the "logging thread/process" you might experience
> blocking,buffer congestion that might be caused by the database end ,
and
> probably thats not what you want to happen.

Nothing is preventing the forked process to read the unified file, you
can think of it as a minimal barnyard which binary is integrated into
snort as a plugin. But again we are discussing technical details of our
work which is not yet finished. What I wanted to state is that it is
currently difficult to have a snort plugin create threads or child
processes.

> I guess "heartbeat" like implementation should be left to the users to
> decide, as long as you implement it in a way that you can process it
there
> is many way where you can plug your heartbeat code.
> In out case , it is implemented as a preprocessor for quick changes in
> behavior. What you might want to see as a problem is that there is no 
> heartbeat if there is no packets.

... which is exactly what I criticized in my last mail. In order for the
user to decide, there has to be a way to implement it first, and
currently I don't see a way to implement real heartbeats, again because
of current API.

> > 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 :/

It was just used as a negative example :) We know that spo_database is
bad. That's why it is such a good bad example...

> Hope to feed the discussion.
Thanks, if you happen to visit your new outpost in Sierre, feel free to
drop by...

Best Regards,
Thomas Seiler





More information about the Snort-devel mailing list