Snort mailing list archives

Re: ACID Alert Cache Empty


From: "Imran William Smith" <iwsmith () mimos my>
Date: Mon, 22 Jul 2002 07:49:30 +0800

RE: [Snort-users] ACID Alert Cache EmptyIT's not a single function, it's about 5 inserts, 1 for TCP, 1 for UDP, etc.
I think it's acid_cache.inc

You'll still need to implement something similar to the below algorithm if you
want it to run exactly how acid does it at the moment.  Or at least, make sure
you do it sensor by sensor.

I'd be grateful if you let me know what the cause was...

Imran

--
Imran William Smith
Security Products Development
Mimos Bhd, Malaysia



  ----- Original Message ----- 
  From: Kevin Brown 
  To: 'Imran William Smith ' ; 'Kevin Brown ' 
  Cc: 'Snort-users ' 
  Sent: Friday, July 19, 2002 11:23 PM
  Subject: RE: [Snort-users] ACID Alert Cache Empty


  Sorry, should have been more clear.  I dropped the ACID cache and event tables from the mysql command prompt (drop 
table <table name>), then went to the PHP frontend and it remade the tables from the script that came with ACID 
(create_acid_tbls_mysql.sql).  Still no data is being propogated from the event table (which has continued to grow) to 
the acid_event table.  I guess I'll try to find the function in ACID that updates the ACID cache tables and see if I 
can run it from the mysql prompt on the server.

  -----Original Message----- 
  From: Imran William Smith 
  To: Kevin Brown 
  Cc: Snort-users 
  Sent: 7/18/02 6:15 PM 
  Subject: Re: [Snort-users] ACID Alert Cache Empty 

  The algorithm acid uses is something like 
    
  for each sensor 
      get highest sid in acid_event table     -> (call it 
  acid_event_max_sid) 
    
      for all rows in event where event.sid > acid_event_max_sid 
          insert corresponding rows into acid_event 
      end for 
  end for 
    
  This all has to happen this way, because MySQL does not handle the 
  where not exists (subquery) structure, which would mean the whole thing 
  could 
  be done in a single query. 
    
    
  So my guess is some auto-increment problem is stopping the insert 
  happening, 
  Acid somehow thinks acid_event is already full.  You could try dropping 
  and recreate the 
  acid_event table.  That might probably solve it.  Because when you 
  say 'rebuilding', I presume you mean 'rebuilding' in the frontend, 
  rather than a 
  drop ; create operation.  So you've totally reset the snort schema, but 
  not the acid 
  schema. 
    
    
    
  -- 
  Imran William Smith 
  Security Products Development 
  Mimos Bhd, Malaysia 
    
    
    

  ----- Original Message ----- 
  From: Kevin  <mailto:Kevin.M.Brown () asu edu> Brown 
  To: 'snort-users () lists sourceforge net' 
  <mailto:'snort-users () lists sourceforge net'>  
  Sent: Friday, July 19, 2002 12:57 AM 
  Subject: [Snort-users] ACID Alert Cache Empty 



  An issue seems to have popped up this week with Snort (1.9-dev from CVS) 
  and ACID (0.9.6b22). 

  MySQL Server setup: 
  ACID 0.9.6b22 
  MySQL 3.23.51 
  Schema 105 
  ADODB 2.12 

  Last week worked fine.  Snort was logging to the MySQL server and ACID 
  would properly update the cache with the new events.  This week it is 
  properly logging to the db, but ACID won't update the cache of events. 

  What happens (and this has been working for almost a year) is that on 
  Sunday night the old database is moved to a new folder and a new snort 
  database (completely empty) is put into place by rerunning the db schema 
  creation script (create_mysql). 

  I have tried deleting the ACID cache tables and rebuilding them, but it 
  still didn't update the chache with the now over 700,000 alerts.  I can 
  go to the "Cache and Status" page and see that the database has has a 
  large number of alerts, but it shows 0 for the cached events.  Hit 
  update alert cache and it adds 0 alerts to the cache.  Repair tables 
  doesn't seem to do anything, nor does Rebuild Alert Cache from the same 
  page. 

  No software has been changed while I was gone. 

  Any other suggestions? 


Current thread: