Snort mailing list archives
Re: Snort.org Blog: Snort's output methods
From: Phillip Deneault <deneault () WPI EDU>
Date: Mon, 27 Jun 2011 12:55:27 -0400
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
Current thread:
- Snort.org Blog: Snort's output methods Joel Esler (Jun 27)
- Re: Snort.org Blog: Snort's output methods Phillip Deneault (Jun 27)
- Re: Snort.org Blog: Snort's output methods Joel Esler (Jun 27)
- Re: Snort.org Blog: Snort's output methods L0rd Ch0de1m0rt (Jun 27)
- Re: [Snort-sigs] Snort.org Blog: Snort's output methods Steven Sturges (Jun 27)
- Re: [Snort-sigs] Snort.org Blog: Snort's output methods Joel Esler (Jun 27)
- Re: Snort.org Blog: Snort's output methods Martin Roesch (Jun 28)
- Re: [Snort-sigs] Snort.org Blog: Snort's output methods Steven Sturges (Jun 27)
- Re: Snort.org Blog: Snort's output methods Phillip Deneault (Jun 27)