[Snort-devel] Re: [Snort-users] Distributed Snort

Federico Barbieri fede at ...1683...
Thu Nov 14 11:40:05 EST 2002

Paul Poh wrote:

> Hi Frank,
> I had email to the list in July about a new output plugin that I was 
> planning to write. I've actually just finished the first pass about 
> two weeks or so ago. It works fine for my needs and it's been tested 
> in my environment (ie Linux on x86 only).
> The plugin does what you described. The data format is based on the 
> existing unified snort format. It does use SSL as the transport so 
> OpenSSL is required.

Seems the right place for this question.
Did you see the work of the Intrusion Detection Working Group (IETF) 
http://www.ietf.org/html.charters/idwg-charter.html ?
If so could you give me your opinion about it. I think it's unusable but 
let's see what people more knowlegeable than me thinks...



P.S. I'ven't been throught the list archive so forgive me if this is 
already been discussed.

> Are you interested in collaborating on this? The one thing that I did 
> not write is a client for the output-plugin. We use a proprietary 
> database interface and schema so I don't have client that I can release.
> I keep meaning to submit diffs but I was waiting for the 1.9.1 of 
> snort to be released first. I will provide diffs to the list in in a 
> few days against 1.9.0 if that's okay. One problem is that I also made 
> changes to snort to reduce it's disk footprint. I submitted some diffs 
> for those changes a while back. If you don't mind those other changes, 
> then I would like to submit a single diff.
> Regards,
> Paul Poh
> Frank Knobbe wrote:
>> While planning a large Snort roll-out with centralized logging, I'm
>> starting to see some problem withs having the sensors log directly to a
>> database. My main gripe is performance and reliability. Barnyard can
>> help in the performance area, but one seems to be limited to to MySQL on
>> the back end. Also, the database plugins doesn't seem to check for and
>> handle error conditions very well. What does a sensor do when the link
>> to the database is temporarily down?
>> I'm considering writing an output and input plugin for Snort that could
>> alleviate these problems. I'm posting here a) for a sanity check, and b)
>> if there is an interest in this setup (in which case I will program so
>> that the code can be easily shared and integrated in other setups).
>> My plans is this: A custom output plugin in Snort (decoupled in a
>> thread, or a socket), and also in Barnyard, will send event and packet
>> data via TCP to a remote Snort sensor (instead of a database). The
>> decoupled output plugin would realize a lost connection and reconnect
>> after a short waiting period. At the same time, Snort is still running,
>> catching alerts, and queueing alert and logging data to this plugin.
>> [This Snort box sniffs packets from the network, runs it through the
>> preprocessors and detection engine, and then queues and transmits the
>> alert and log output].
>> On the receiving end I envision a normal Snort installation, except that
>> it is started with a new command line parameter which will cause Snort
>> not to read packets from the network as it usually does, but instead
>> accept the TCP connection from the remote Snort sensor. It will then use
>> the received information to call its output plugins as usual. [This
>> Snort box reads the event and otn data from the TCP session, and only
>> calls the log and alert plugins, bypassing preprocessors and detection
>> engine].
>> With this setup it should be possible to have several sensors do the
>> detection, pass the data to a central Snort instance which will make use
>> of the already existing plugins, including Postgres, tcpdump, ascii,
>> etc.
>> In addition, the receiving Snort box can in turn forward the data to yet
>> another Snort instance, mainly for redundancy. The remote sensor can
>> connect to the receiving pair in a round robin fashion, the the
>> receiving box can log to it's database, forward it to its Snort mirror
>> which will log it into another database. Or forward to a final tcpdump
>> archival sensor.
>> Unless you can convince me that this is a bad idea, I will start coding.
>> If there is an interest in such a distributed Snort setup, please let me
>> know and I plan accordingly, although the addins shouldn't be very
>> invasive.
>> Regards,
>> Frank
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel

More information about the Snort-devel mailing list