Re: Base Barnyard and Unified Logs

[Dirk Geschke <Dirk_Geschke () genua de>]

Hi Wes,

> These hacks all are great in theory...i'd rather just rip out the CID 
> in the signature table.
>   I really like populating the sig table pre-emptively, that I might do 
> reguardless, but software  ppl need to revolve their "viewing" software
> around the sid. I think the PK that originally was in place (cid or 
> whatever) was before SID's were even involved and everything was just
> PK'd on the msg... (hense making the CID important in the DB schema, 
> but not in real life. If you re-vamp the output plugin along with the
> schema to reflect everything being key'd on the sid, the system would scale
> much higher when you start incorporating more databases with teh 
> product (i have about 4 diff db's that rely on the one snort_log
> alone, not to mention the snort_alerts, all work well untill I have to 
> clear one of them, i clear one, 2 of them have to be flushed and
> re-init'd as well because of the stupid CID auto-increment stuff, and 
> no, aanval (atleast the older version) isn't totally exempt
> from this problem either). If they were all SID based, the joins would 
> be fine reguardless of what i flush.
>
> Actually the db plugin doesn't really have to be re-written come to 
> think of it, just rip out the CID and base your software on the SID.
> IMO that key shouldn't even be there.

I think you missed something. Of course it is a headache to have combined
PK's, but the SID is the sensor ID and the CID is the counter of alerts 
for each separate sensor.

The only thing you could do is to use a global counter as a PK and add
a further table separating the global counter ID back to a SID/CID
combination. (Maybe you can live with holes and skip the CID but you 
still need a reference from which sensor the alarm was reported. Of
course if you only have one snort sensor sniffing then you don't need
this but this is not likely to happen for most people.)

Thus coming up: You reduce the combined key and have to introduce a
new table for the sensor mapping? And how about all the tools out there
like ACID/BASE?

The best solution would be a redesign of the database AND the viewing
software like ACID/BASE. I think a group in switzerland is just starting
such a project...

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