|
|
|
|
Snort Forums Archive
Archive Home » Snort Development » Problems with last_cid and archive databases
Please note that the categories listed below represent an archived version of our forums pages. To view the current version and be able to post and reply to threads, please register and login here to go to the full forums pages.
[ Notice: Full Version of This Topic ]
Problems with last_cid and archive databases
Posted by bitstream on January 25, 2006 07:01:07
I apologize if this exists as a thread somewhere in the group; I searched for it but could not find it.
There seems to be a long standing issue with the snort database plugin and third party products such as BASE that manage databases that results in collisions of CIDs.
http://www.networksecurityarchive.org/html/Snort-Users/2005-04/msg00277.html
http://sourceforge.net/tracker/index.php?func=detail&aid=1163758&group_id=103348&atid=635582
Though it seems well known, I can't find any indication that anyone was working on resolving it.
After studying spo_database.c on my own, it seems to me that snort manipulates the last_cid value in the sensor_table but it doesn't actually ever use the value that's in it. Inside function DatabaseInit(), the last_cid value is retrieved from the sensor table and compared against the MAX(cid) in the event table. If the MAX(cid) is greater, the sensor table is updated, but in either case the MAX(cid) value is used.
If snort is the only thing using the database then this is probably a safe way to go, but it seems that this is an errant assumption. It is likely that users of snort are using a third party database tool (BASE, e.g.) and wish to maintain the SID/CID pair uniqueness across multiple databases. The only way to do this without extensive changes to the design is for snort to honor that last_cid value.
If snort did start using last_cid then the burden for properly maintaining it could be shifted to the third party application. The error check in the spo_database plugin is still relevant (we still want to make sure that MAX(cid) isn't larger than last_cid), but making sure that last_cid is set appropriately for archive databases can be left to the third party application.
To do this in snort seems straightforward; we just use whichever value is larger to set the initial cid for snort. I've gone one extra step and added some error checking to make sure that last_cid isn't approaching MAXINT. You may have a better way to do this.
$ diff -uN spo_database.c.dist spo_database.c > /tmp/spo_database.patch
$ cat /tmp/spo_database.patch
--- spo_database.c.dist 2006-01-25 11:12:36.000000000 -0500
+++ spo_database.c 2006-01-25 11:25:36.000000000 -0500
@@ -62,6 +62,7 @@
#include "parser.h"
#include "debug.h"
#include "util.h"
+#include "values.h" /* get MAXINT */
#include "snort.h"
#include "inline.h"
@@ -555,10 +556,15 @@
data->shared->sid);
ErrorMessage(" Recovering by rolling forward the cid=%u\n",
event_cid);
+ data->shared->cid = event_cid;
+ } else {
+ data->shared->cid = sensor_cid;
}
- data->shared->cid = event_cid;
++(data->shared->cid);
+ if (data->shared->cid >= (MAXINT*.9)) { /* 90% of MAXINT */
+ ErrorMessage("database: warning: last_cid is approaching MAXINT\n");
+ }
}
else
{
When it comes to those third party applications, it seems that the right thing to do when creating an ARCHIVE database is NOT to preserve the SID/CID pair, but rather to compact CID values to the smallest possible range. Otherwise, a really bad day on the farm will generate a really high cid count for a sensor, and a few really bad days (weeks) will put us up near MAXINT. Even with CID compaction strategies, we still need snort to honor the last_cid value otherwise the whole thing is mute.
If/when this patch (or a variant thereof) gets accepted into snort, it should be relatively easy to produce patches for the third party applications archiving routines to properly set last_cid. Cid compaction is trickier, but if you aren't having bad days on the farm, it's also not a burning issue. If you have no third party application than my patch does no harm (you're counting towards MAXINT anyway). The MAXINT error warning is probably a good idea for spo_database anyway, as it currently has no detection for it.
From reading the posts above, it seems that the non-code patch workaround is to leave an alert in the database with sufficiently high cid to avoid the conflict, but this just seems hokey and makes things like "delete all" problematic to use.
Thanks for your consideration. |
|
Posted by DG on January 26, 2006 23:40:51
Yes, this is an old bug in spo_database.c and no one really ever tried to fix it. Although it would
be very simple, all you have to to is to either set the cid to last_cid or simply add last_cid
to cid on each INSERT.
But I think the database ouput plugin should not be used at all. If the database is slow than snort
would be slowed down, too. If the databas connection get lost, then there is no reconnect mechanism..
You can go and use the unified output plugin. But this has same problem, last_cid is only actualized
but not really used.
If you are working with unix systems then you may take a look at FLoP. Here the last_cid is used
in the correct way...
|
|
|
|
|
|
