Re: Base Barnyard and Unified Logs

[Dirk Geschke <dirk () geschke-online de>]

Hi Jerry,

> Just saw the discussion about barnyard and DB's.  Here is some info 
> I gained in having to deal with consolidating data from two snort 
> DB's in to a single application.
>
> Now that generators have been assigned to various parts of snort, 
> they need to be employed in the DB schema (generator:sid:rev) as 
> a key to a signature.  The generator-id is needed since the
> pre-processors usually start the SIDS=1!  The problem becomes more 
> complicated in that the signature, sensor, reference, and 
> classification tables are built on the fly by the DB-plugins.  The
> plugins first try to grab the signature from the DB using msg 
> (sig_name), Rev (sig_rev) and SID (sig_sid). If found then use 
> the assigned (via MySql auto-increment) sig_id.  If not, create the
> record.  Note that the generator-id is never mentioned in the DB.
>
> The signature, sensor, reference and classification tables are 
> "normalized" tables created on-the-fly by the database plugin.  Their
> ordinal (created by the order of insertion) is used in the
> other tables (eg. event) to save time and space.
> If you are only using a single DB, there isn't any problem, except as
> Joel wrote below, if you have to clean the DB, your mapping between 
> SID ->(sig_name,sig_sid,sig_rev) is lost.  If you are combining the 
> two DB's, for example an inside and an outside, into a single 
> application/DB like we are, you run in to data collisions and race
> conditions.
>
>
> To solve these issues, I ended up writing scripts to insert (read 
> preload) the following tables:
>       .signature, from all of the rules
>       .sensor (including the 'read from file' entries)
>       .reference (reference.config), and
>       .classification (classification.config)
> The input to the scripts will never shrink.  Thus I will maintain 
> the mapping.

a similar script exists as part of FLoP: rules.pl. It inserts all
rules of the signature files to the database. This would also speed
up insertiion of alerts since the signature is already part of the
database.

To solve the generator-id problem we use a hack, if the alert is
not created by a "normal" rule, e.g created by a pre-processor
then we insert the generator id in the field sig_rev since the
revision is neither defined for preprocessors nor would there
be any change within it. The big problem is that the generator
id was never thought of as the database design was made. And
more complicated, ACID/BASE won't use it...

To learn more about FLoP take a look at

  http://www.geschke-online.de/FLoP/

Maybe you can use some of the tools which are part of the project
or you can use it at all...

Best regards

Dirk


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users