[Snort-devel] Plugin API Feature Request

Dirk Geschke dirk at ...972...
Mon Feb 13 10:14:01 EST 2006


Hi Thomas,

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

this is not a good idea at all, either forking is ressource consuming
even with copy-on-write. And threads are not available (or different
available) on different plattforms.

And there are already good projects which decouple the ouput from
snort.

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

This are two bad ideas. First, any use of database connections within
snort is a bad idea. You have to think about disconnects, reconnects,
slow databases and so on. Secondly, you should be more interested
in irregular shutdowns like based on SIGSEGV's. So I think process
monitoring is the better solution...

> (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 think this is not really necessary, there are better solutions. How
about writing a special rule and triggering this alert from extern?
Thus snort will sniff the packet, generate an alert which should 
finally make his way to the database. So create every N seconds 
such an alert and verify that it arrives in a given range at the
database.

This way it would be of more value than a periodic callback function
will give you. 

[...]

> 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 initialization time, the plugin might not see the whole
> configuration. The order at which plugins are initialized / rules are
> parsed depends on the order in which they are in the config file. If the
> plugin gets loaded before any rules, it will see nothing.
> 
> So we had to wait for the first packet before we could synchronize the
> signatures with the database. The question was, if there is a way to be
> called after all rules are parsed, so that the plug-in can have a look
> at the rules.

Ok, there are already solutions available to this problem. Part of
FLoP (http://www.geschke-online.de/FLoP/) is a perl script which
stores all signatures in the database.

If FLoP finds an alert which is not part of the database then this
alert is simply added, if it is already part of the database this 
is used.

To avoid blocking output plugins FLoP uses a unix domain socket
for forwarding the alerts to a separate decoupled process. I guess
only shared memory would be faster...

These are just my thoughts on this topic....

Best regards

Dirk




More information about the Snort-devel mailing list