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

thanks

fede

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