[Snort-devel] Snort.org Blog: Snort's output methods
jesler at ...402...
Mon Jun 27 14:13:03 EDT 2011
Good to hear from you, and your opinions. I think that what you say holds merit.
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.
> 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.
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
More information about the Snort-devel