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
