Snort mailing list archives
Re: Base Barnyard and Unified Logs
From: Wes Young <wcyoung () buffalo edu>
Date: Wed, 30 Mar 2005 09:01:09 -0500
-----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
Current thread:
- Re: Base Barnyard and Unified Logs, (continued)
- 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)