[Snort-devel] Re: last_cid in new database scheme v106

Dirk Geschke Dirk_Geschke at ...802...
Fri Sep 13 13:51:06 EDT 2002

Hi Roman,

> Indeed, there is definitely overhead with this addition.
> One possible optimization which should provide identical performance
> characteristics as schema v105 would involve reading the sensor.last_cid
> field at snort start-up, but not updating this field until snort is
> shutdown.  Should snort crash, the existence of alerts after the last_cid
> would be lost.  However, on restart, this condition could be detected and
> addressed.

this should be easily to achieve. In DatabaseInit() we can ask for both,
the MAX(cid) and last_cid and take the largest one. If MAX(cid) is
larger than last_cid than UPDATE last_cid, otherwise it should be ok.

This would only happen on startup of snort.

Additionally we have to UPDATE last_cid with the actual cid value
at the normal exit/restart of snort. This can easily be added in
SpoDatabaseCleanExitFunction() and SpoDatabaseRestartFunction().

With this solution we can omit the UPDATE call on each new alert.

> > Wouldn't it be much smarter to take care of not to (re-)move the last
> > cid of the database?
> Keeping a sentinel value would add additional complexity to the
> applications processing the database.

Not, really. All you have to care of is not to remove MAX(cid) out
of the database. But of course the first solution would be smarter.

> > Additionally as last mentioned it would be much faster if we can trust  
> > that each rule set is already part of the database. This would remove
> > a lot of query/insert statements and should result in a much faster
> > database logging.
> Perhaps a configuration option could be added.  However, this would also
> require indexing the signatures by their snort sid.

Yes, to have only INSERTs and no SELECTs or UPDATEs would greatly
improve the performance of the database (especially if you use MySQL).

One problem with this idea is that you have to ensure that all
signatures are part of the database. This can be done once and
then for every new rule again. One problem to take special care
of is if a rule changes (compare sig_id with sig_sid in the 
signature table). But this problem exists with the actual code.
If someone changes the priority of a rule and does not change
sig_rev or sig_sid then this change will not be inserted or
updated within the database.

But in principal it should be possible.

Best regards

| Dr. Dirk Geschke            | E-mail: geschke at ...802...     |
| Gesellschaft fuer Netzwerk  | Tel.  : +49-(0)-89-991950-31 |
| und Unix Administration mbH | Fax   : +49-(0)-89-991950-99 |
| 85551 Kirchheim / Germany   | Raeter Stra/3e 26            |

More information about the Snort-devel mailing list