Re: Announce: FLoP-1.0 --- Fast Logging Project for snort

[Dirk Geschke <Dirk_Geschke () genua de>]

Hi Frank,

> That sounds very similar to DistributedSnort, which I still have on the
> drawing board. My goal was to decouple the output plugins from Snort for
> the same reason as your project does -- faster logging and
> centralization. My goal was to have the remote sensor to sniff the
> packets, run it through the mill, and then output it to locally
> configured output plugins as well as to a remote Snort box. That remote
> Snort box does not sniff traffic, but instead receive it and pipe it
> back through it's configured output plugins.
>
> The advantage is that all output plugins are supported. And as new ones
> are added, they are immediately available. D-Snort would just provide an
> input/output layer into Snort. The remote Snort box is a normal Snort
> with the special output plugin added. The central Snort is a normal
> Snort with a special command line argument which causes it to not sniff
> packets, but instead wait for remote alerts. 
>
> Input/output was handled with buffer queues in separate threads.
>
> Since it sounds like there are a lot of common features, are you
> interested in collaborating? I can send you my architecture plans and
> what I planned (I just never got around to writing it....)

the idea is not bad but I think it is too difficult to implement.
The advantage of your idea is to keep all output plugins of snort
working. But is this really desired?

The snort part you need on the sensor side is nearly the same as
used in FLoP: You write the alerts and payload to an unix domain
socket and snort can go on sniffing. This will not block for
any reason, snort can go on to sniff.

This alerts will be send to a central server. This is also identical.
But here you want to insert this data back in a snort process to 
use only the output plugins.

So far: Why start snort on the central machine if you only need
the output? This sounds like a lot of overhead.

Further you need a way to identify which sensor reports this alert.
This must be inserted in the snort output process. Actually this
is not part of the most output plugins. (The database plugin looks
for the IP address snort is running on: this would result in the
address of the central machine and this for all sensors, not a good
idea...)

And what output plugins do you really need? The ASCII output of
serveral remote sensors is not really good parseable. So at least
it would be good to store them in a database. But this is already
done with FLoP and we only need to modify snort slightly. Your
approach would require large changes to snort. This could result
in an headache with every new release of the orginial snort package.

Indeed one nice thing would be to change the database. Actually
FLoP works with the "normal" snort database which works well (or
not) with ACID. But it maybe better to change this database at
least to store the whole pcap packet of the alert. This way you
could rebuild the original network packet and pipe it to something
like ethereal for further analysis. (Note: The payload stored in
the actual database is really the payload of the higher protocol,
TCP, UDP or ICMP. You loose both headers of these protocols.)

With ethreal you can use the built-in protocol analyzer for higher
protocols like for example DNS. (Did you ever try to analyze the
payload of a DNS packet with ACID?).

But this is not implemented in FLoP yet but I think it can be
easily done.

Also adding thread functionality to snort is not as 
easy at it seems to look like. (It would be nice to get the
whole snort program to use threads so you can monitor more
than one network interface. But this will not work with libpcap,
this library is not reentrant.)

Finally: You have to run the snort process(es) on the central
machine with the same configuration file as the remote sensors,
including all rules...

So I think the FLoP approach is much easy to use and modify
as your idea although it is a nice idea...

Best regards

Dirk

FLoP: http://www.geschke-online.de/FLoP
--
+-------------------------------------------------------------+
| Dr. Dirk Geschke            | E-mail: geschke () genua de      |
| Gesellschaft fuer Netzwerk  | Tel.  : +49-(0)-89-991950-131 |
| und Unix Administration mbH | Fax   : +49-(0)-89-991950-999 |
| 85551 Kirchheim / Germany   | Domagkstrasse 7               |
+-------------------------------------------------------------+




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users