-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
err not CID, sorry didn't have the table in front of me.. the sig_id.
I realize that all the other tables are involved with the sig_id
(obviously) hense the plugin re-write. Theoretically the SIG_SID and
SIG_ID are the same, just diff values. Again, this is dealing with the
SIGNATURE TABLE, everything now seems to rely on the SIG_ID instead of
the SIG_SID, that was my whole point. So instead of auto-incrementing
the SIG_ID in the table, make it equal to the SIG_ID upon insertion
until we can safely get rid of it.
Dirk Geschke wrote:
| 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
|
|
- --
Wes Young
Network Security Analyst
University at Buffalo
GPG Key: http://saxjazman9-security.blogspot.com/2005/01/gpg-key.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCSrEl1M5o0FsrrbERAjopAJ9bSygbKCr1xt4948Tl30pQrDShWACeJbAW
rwldz/yti6E6YTuQFSXFm/k=
=g/4f
-----END PGP SIGNATURE-----
-------------------------------------------------------
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
