Re: Snort.org Blog: Snort 2.9.1 beta coming soon!

[firnsy <firnsy () securixlive com>]

G'day All,

On 14/06/11 06:50, Joel Esler wrote:
> On Jun 13, 2011, at 2:16 PM, beenph wrote:
> > > On Mon, Jun 13, 2011 at 12:45 PM, Joel Esler<jesler () sourcefire com>  wrote:
> > > On Jun 13, 2011, at 12:13 PM, Russ Combs wrote:
> > > > Does the HTTP, SMTP, etc. logging take place in its own thread, or
> > > > does it block the detection thread?
> > >
> > > No - logging is in the main thread
> > >
> > > It is included in the unified2 output file, use the u2spewfoo tool included
> > > with Snort to see this.
> > > Barnyard2 developers (Snorby et all), if they want to to include this output
> > > in their tools, will have to update to handle this new output.
> > > Joel
> >
> > Barnyard2 currently do not log any of those Unified2ExtraDataHdr.
> > But it will be able to process file where Unified2ExtraDataHdr are present.

beenph is correct here, barnyard2 will process the records just fine 
once the logging requirements have been appropriately determined.

> > A consensus has to be made betwen frontend developper to determine how they
> > would like to have Unified2ExtraDataHdr data stored in their datastore.
>
>
> I'll tell you why I'm asking if there is interest in someone else maintaining the sql schema.  The original schema 
> and db output was written, literally, as a college project.  Thesis project I think.  (Along with ACID. The precursor 
> to BASE. At Carnegie Mellon.)  We agree that it's not very good (as you stated in your email).
>
> We (Sourcefire) don't have the cycles to maintain the structure, and we've been discussing EOL'ing the db output 
> method for years.  We'd like to standardize on our unified2 output structure, providing we continue to distribute 
> u2spewfoo for developers and users to dump the data directly.

Barnyard2 will continue to maintain the DB structure (aka the Snort DB 
schema) for the foreseeable future.

Slightly OT, on my roadmap there are plans to develop a contemporary 
schema that addresses a number of the shortcomings within the current 
implementation. Prior to this development the community will be engaged 
for a open discussion on the requirements.

> Of course we wouldn't do this suddenly!
>
> We'd like to keep some of of the present output modules (binary, unified2, -A (fast, cmg, full, etc) maybe a couple 
> more (I don't have the full list in front of me), but definitely EOL output modules like the DB method, and perhaps a 
> couple more.
>
> I invite our developers to chime in with their thoughts as well.
>
> What does the community think of that?

I see this change only affecting users who don't use barnyard2. For 
existing barnyard2 users, please move along nothing to see here ;)

Regards,
- firnsy



------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel