[Snort-users] Base Barnyard and Unified Logs

Wes Young wcyoung at ...12754...
Wed Mar 30 07:30:55 EST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ahhhh.... pardon my ignorance... i understand now...

thanks for the insight. :-)

Dirk Geschke wrote:
| Hi Wes,
|
|
|>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.
|
|
| once more: Even this view is not correct at all...
|
| The SIG_ID and SIG_SID are not the same. The big difference is that
| you may have the same signature ID with different revisions. Hence
| the keyword "rev". But you also get a new SIG_ID if you change the
| classification and more worse the priority.
|
| If you use several snort sensors it may be a good idea to use even
| several priorities. A web attack in front of a mail server would
| get a minor priority than against a webserver.
|
| So, there is a good reason for this. And I don't think that this
| design is the bottleneck of the database.
|
| This is more the combination of the sensor ID and the counter per
| sensor, hence the SID/CID pair.
|
| 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)

iD8DBQFCSsXF1M5o0FsrrbERAmCzAJ0UqRXU2OULJONcYCAP5RbHCWjYVgCeLUUI
uEdJIZ3vT/nwO8XIvI7ReiU=
=uo9r
-----END PGP SIGNATURE-----




More information about the Snort-users mailing list