Snort mailing list archives
Re: Base Barnyard and Unified Logs
From: Dirk Geschke <Dirk_Geschke () genua de>
Date: Tue, 29 Mar 2005 13:11:12 +0200
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
Current thread:
- Re: Base Barnyard and Unified Logs, (continued)
- Re: Base Barnyard and Unified Logs Esler, Joel CNTR/Sytex (Mar 14)
- Re: Base Barnyard and Unified Logs Wes Young (Mar 14)
- Re: Base Barnyard and Unified Logs Paul Schmehl (Mar 14)
- Re: Base Barnyard and Unified Logs Wes Young (Mar 14)
- RE: Base Barnyard and Unified Logs Lee Clemens (Mar 14)
- Re: Base Barnyard and Unified Logs Joel Esler (Mar 21)
- Re: Base Barnyard and Unified Logs Wes Young (Mar 14)
- Re: Base Barnyard and Unified Logs Jerry (Mar 25)
- Re: Base Barnyard and Unified Logs Dirk Geschke (Mar 26)
- Re: Base Barnyard and Unified Logs Wes Young (Mar 26)
- Re: Base Barnyard and Unified Logs Dirk Geschke (Mar 29)
- Re: Base Barnyard and Unified Logs Wes Young (Mar 31)
- Re: Base Barnyard and Unified Logs Dirk Geschke (Mar 30)
- Re: Base Barnyard and Unified Logs Wes Young (Mar 31)
- Re: Base Barnyard and Unified Logs Paul Schmehl (Mar 14)