[Snort-devel] Snort.org Blog: Snort's output methods

Joel Esler jesler at ...402...
Mon Jun 27 14:13:03 EDT 2011


Phil,

Good to hear from you, and your opinions. I think that what you say holds merit. 

Thanks. 

-- 
Sent from my iPad
Please excuse the brevity

On Jun 27, 2011, at 12:55 PM, Phillip Deneault <deneault at ...2240...> wrote:

> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel




More information about the Snort-devel mailing list