Problem with 2 barnyards in the same box logging to DB

[João Mota <joao () 3gnt net>]

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