[Snort-devel] Snort.org Blog: Snort 2.9.1 beta coming soon!
firnsy at ...3030...
Tue Jun 14 06:40:29 EDT 2011
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 at ...402...> 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.
>> 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 ;)
More information about the Snort-devel