Hello Snorters,
In my first multi-sensor snort deploy I ran into a problem. All sensor
were in the border firewalls and when a packet crossed a firewall
(entered the internal network) two alerts were fired. So far so good.
I'm logging to a DB using Barnyard and when this happens and a new
signature is involved, although the alerts have the same GID and SID,
two entries are created in the signature table.
This happens because Barnyard follows this steps (the names of the
functions/procedures aren't real but similar):
if (!signature_exist(GID,SID))
insert_signature(GID,SID)
sig_id=get_signature_id(GID,SID)
insert_alert_data(DATA,sid_id)
Well... if you have 2 (or more) Barnyards doing this, exactly at the
same time, a race condition is created. They both see that the signature
isn't yet recorded in the DB and insert it. After this, all other alerts
with this GID/SID are entered using the first sig_id that was created.
This isn't good because when I'm using BASE there will be an alert
"loose" from all the other alerts with the same GID/SID (sig_id).
I've altered Barnyard to include a waiting period before entering the
new signature. So, I inserted this before the code writen above:
if (!signature_exist(GID,SID))
sleep (sensor_id*TIME_INTERVAL_CONSTANT)
Actually I didn't use sensor_id but instead the remainder of the
division by 10 because I've the sensors divided by departments using
diferent sets of ten. For example, department number one has the sensors
11,12,13,... , department number 5 has the sensors 51,52,...
This waiting, as you might know, doesn't temper the alert's time info
because a timestamp is included and this is the value used when
inserting the alert to the DB.
Nevertheless, this isn't a good strategy, because if you have a sensor
witch has low bandwith to the DB, eventually the problem will still
happen unless the TIME_INTERVAL_CONSTANT is very high.
The correct strategy would be table locking, right?
Does anyone have this problem? Any hints or other ideas?
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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
