Duplicates in ACID

["John Creegan" <jcreegan () questarweb com>]

Looking over the mailing list archives, I'm now quite certain (since
it's been hashed through in there a couple of years ago) that portscan
events will not appear in ACID unless you're using the alert DB output
plugin.  So, I have to use alerts.

Looking through the ACID pages, and activating the debug mode for
certain sections in "acid_cache.inc", I see that IP events are added to
the acid_event table separately from preprocessor events, such as
portscan2.  I can see how the additional data was folded in after DB
schema 100.

Looking at the queries real-time, and looking at the contents of both
the event and acid_event tables I can't see why the duplicate is
happening, but here's what I see.

Suppose that event #3 was a Large ICMP echo alert, event #4 was a
portscan reported by spp_portscan2, and event #5 was an SNMP public
access udp alert.

At the start of the acid alert cache update process, we'd see these
three reports in the snort event table, but none of them in the
acid_event table.
The main acid page refreshes, and acid_cache.inc notices that the max
CID value in the event table is larger than the max CID value in the
acid_alert table.  It knows there are alerts to add to the acid_alert
table, and figures out the delta (which alerts to add).

There are 8 INSERT INTO acid_event queries in the acid_cache.inc page,
but I don't think all 8 run.  Regardless, the process of adding new
events to the acid_event table (schemas greater >=100) seems to be
divided into 5 steps:
     1. Pre-schema 100 events, the add-ons (>= schema 100)
     2. TCP events,
     3. UDP events
     4. ICMP events
     5. Pre-processor alerts

It's the preprocessor query that's creating my problem, specifically
spp_portscan2.

Remembering the alert order above (#'s 3,4,5), 3 would be inserted by
query #4, 4 by query #5, and 5 by query #3.  In order then, acid would
update acid_alert with alert #s 5, 3, 4.  It's important to note here
that the portscan alert goes in last, because the only time I see a
duplicate warning is when adding a portscan event to the alert cache.

It's not the CID value of the portscan event itself that ACID always
complains about.  It's the CID of the first alert *already in place*
following the portscan alert just added.

I can't see anything wrong with Roman's update logic (the individual
update queries at least), and I can't find the reason why it appears to
look ahead to the next row after the update.  Since acid is doing each
event type separately, it's common that CID gaps will exist until all
events are added.  Since we're only going after specific CID's with each
event type, acid neatly fills in the gaps it creates, and all's well in
the end.

I just wish I could see why acid cares about that following alert. 
Anyone got any ideas?


This message (including any attachments) contains confidential 
information intended for a specific individual and purpose, 
and is protected by law.  If you are not the intended recipient,
you should delete this message and are hereby notified that any 
disclosure,copying, or distribution of this message, or the taking 
of any action based on it, is strictly prohibited.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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