[Snort-devel] Plugin API Feature Request

Eric Lauzon eric.lauzon at ...1967...
Mon Feb 13 10:36:01 EST 2006


> -----Original Message-----
> From: snort-devel-admin at lists.sourceforge.net 
> [mailto:snort-devel-admin at lists.sourceforge.net] On Behalf Of 
> Thomas.Seiler at ...2736...
> Sent: 13 février 2006 13:21
> To: snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] Plugin API Feature Request
> 
> 
> 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.
> 

Well personaly i am still sold to the idea that on the long run
if snort current become threaded , single binary implementation 
is the ways to go , but as of the ways it is designed right now 
i am not sure that the output_pluggin should handle its own threading.

Still thats a choice of implementation that can be discusses forever and
the choice you are making are probably driven by your own requirement.

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

Well signal handling design should be considered as an HALT operation , so 
you will certanly loose current inprocess information , unless you want to handle
SIGHUP so you reload other type of information as configuration /rule thus you can
continue to process the information in queue but thats again a design choice.


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

Sure nothing prevent that, still you have a single process where everything might fail.
As of issues with installation/maintenance having one binary dosent solve all your problems.
Still again implementation choices.

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

Well there is way to implement real heartbeat. But still thats up to you
to do it your way i guess. And i guess you have to come with your own API,
unless sourcefire design DEFACTO heartbea , where i could see that you still
could implement it the way you want.

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

hehe im not the traveling one :)

-elz

AVERTISSEMENT CONCERNANT LA CONFIDENTIALITÉ 

Le présent message est à l'usage exclusif du ou des destinataires mentionnés ci-dessus. Son contenu est confidentiel et peut être assujetti au secret professionnel. Si vous avez reçu le présent message par erreur, veuillez nous en aviser immédiatement et le détruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.

CONFIDENTIALITY NOTICE

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