Re: Snort.org Blog: Snort's output methods

[Phillip Deneault <deneault () WPI EDU>]

On 6/27/2011 11:16 AM, Joel Esler wrote:
> In order to provide the type of functionality we'd like to provide
> with Snort in the next few releases (more data for you!), we needed
> someone to take over the maintenance of the db schema that is shipped
> with Snort as well.   As a result of the discussion on the
> Snort-devel list, the team members over at the barnyard2 project have
> agreed to take over the maintenance of these schemas.
>
> At this point I'd like to hear from the community as well.  So please
> leave comments.

I think its great the BY2 people want to take over the current Snort DB.
 Kudos to them!

> What output plugins do you use? Will you be affected by this change
> (we hope a lot of you aren't using the spo_database method)? What
> other output plugins do you think we can "show the door"?

I wrote (write?) Placid, a very lightweight, fast, web front end for the
current SnortDB in Python (over 10 years old now!).  I know lots of
people who use the spo_database method because its easy, not because its
a good idea.  I've tried telling them not to, and I'm glad to see it go.

Having said that and having watched the back-and-forth nature of these
arguments over the years as I've maintained Placid, and struggling with
Barnyard growing pains over the years, and watching Unified2 be held up
as not only the fastest but the beastliest to implement output standard,
I've come to the following conclusions.  Take them for what they are,
merely suggestions from someone who's been around.

* Snort, as a project, should not be forced to maintain every whiz-bang
output under the sun, or be expected to even try.  All it does is upset
people when they don't get what they want, and hinder development of the
engine itself.

* Snort, as a project, should not be dictating database schema anymore.
 I 100% believe that when Snort was young and computing was what it was,
having a single schema that worked for a wide variety of situations
(MySQL/PostgreSQL/Oracle/Single DB/Multi-Master/etc etc) was important.
 It helped build the community.  Nowadays, I think it hinders
innovation, and maybe that's a functionality of the fact no one has been
supporting the schema, but regardless its been a problem.

Of ANY of the output options of Snort that could exist now or have ever
existed, I can only think of three that make sense.

1. Unified(2) - Fast, Binary, Standard.  Lots of existing tools support
them.  Good for actual network streams and automated systems where speed
is key.

2. ASCII - Slow but there is nothing better for debugging, teaching, and
understanding.  Obviously not for automated processes.

3. XML - Slower than Unified, Faster than ASCII, Textual, but
potentially standardized.  This fills a niche that is poorly occupied by
CSV.  A standardized plain-text output type would not only let people
program whatever connectors they want, but do it easily.  If people want
speedy input to their applications, let them invest the time to read and
process the Unified format.

I could even see not building XML output functionality into snort as
long as there was a barnyard-type tool to output/stream/pipe the XML
from the Unified format.  Such a tool could double as the reference
implementation for any future Unified format development too.

Thoughts?

Thanks,
Phil


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel