Re: Bug in ACID? archive problem: "Ignored XXX Duplicate Events" on a rchive

["Roman Danyliw" <roman () danyliw com>]

> The sid and cid are the same, but these are clearly two totally
> different events, as evidenced by the other fields.  My suspicion is that
> ACID uses the {sid,cid} combination as a unique identifier, and when it
> tries to move this event from snort to snort_archive and sees the {sid,cid}
> combination already there, it thinks it's a duplicate.  

You are exactly correct.  This is the expected behavior.  After events are
deleted, snort will reuse the CID.  Thus, if an event is archived with a given
CID, deleted from the primary DB, then re-used again,  any attempt to archive
this new event (with the re-used CID) will result in a "duplicate event" error
message.

A couple of days ago a fix was commited to snort CVS (for v1.9) introducing
schema v106.  This change will prevent the reuse of CIDs whereby eliminating
this duplicate event issue.

Roman


On Thu, 29 Aug 2002 16:23:49 -0400, "Cloppert, Michael"
<Michael.Cloppert () 53 com> wrote :

> Background:
> ===========
> I'm not sure if this is the correct forum for this sort of thing, but I've
> tried the snort-users list and gotten virtually no feedback.  This is a VERY
> big problem given the way our company has decided our IDS deployment is
> going to work, so I am in dire need of some help before management decides
> it's not worth the problems and ditches our Snort pilot project.
>
> The problem:
> ============
> When I select "Archive Events (move)" or "Archive Events (copy)", ACID
> returns "Ignored XXX Duplicate Events", where XXX=<number of events selected
> for archival> on a number of occasions.  These events *do not* already exist
> in the archive database, and I *do* have acid_conf.php configured properly
> to archive to "snort_archive" as opposed to the default database "snort".
> I've put ACID in debug mode, and I don't see any discernable errors.
>
> My data:
> ========
> My first thought was database size.  I ran:
> echo "show table status;" |mysql -u root -p snort
> to see what my database tables looked like, but to be honest with you I
> don't really know what I'm looking at.  The only thing I noticed that
> *might* be a problem was that "Data_Free" for "acid_ag_alert" was 0.  Like I
> said, I really don't know what most of that means, however.
>
> My second thought was "screw ACID, I'll do the queries myself!"  I took a
> particular event that was generating this error (sid 1, cid 6382), and ran:
> "SELECT timestamp, ip_src, ip_dst, layer4_sport, layer4_dport, sig_name FROM
> acid_event WHERE (acid_event.cid LIKE '6382');"
> on both my snort and snort_archive databases.  My results were (apologies
> for the wrapping):
>
> database snort_archive:
> mysql> SELECT timestamp, ip_src, layer4_sport, layer4_dport, sid, cid,
> sig_name FROM acid_event WHERE (acid_event.cid LIKE '6382');
> +---------------------+------------+--------------+--------------+-----+----
> --+---------------------------------+
> | timestamp           | ip_src     | layer4_sport | layer4_dport | sid | cid
> | sig_name                        |
> +---------------------+------------+--------------+--------------+-----+----
> --+---------------------------------+
> | 2002-07-29 05:42:58 | 2340570399 |         2440 |           80 |   1 |
> 6382 | WEB-IIS multiple decode attempt |
> +---------------------+------------+--------------+--------------+-----+----
> --+---------------------------------+
> 1 row in set (0.00 sec)
>
> database snort:
> mysql> SELECT timestamp, ip_src, layer4_sport, layer4_dport, sid, cid,
> sig_name FROM acid_event WHERE (acid_event.cid LIKE '6382');
> +---------------------+------------+--------------+--------------+-----+----
> --+------------------------------------------+
> | timestamp           | ip_src     | layer4_sport | layer4_dport | sid | cid
> | sig_name                                 |
> +---------------------+------------+--------------+--------------+-----+----
> --+------------------------------------------+
> | 2002-08-27 16:39:23 | 3265189952 |         3012 |           80 |   1 |
> 6382 | WEB-IIS view source via translate header |
> +---------------------+------------+--------------+--------------+-----+----
> --+------------------------------------------+
> 1 row in set (0.10 sec)
>
> Aha!  The sid and cid are the same, but these are clearly two totally
> different events, as evidenced by the other fields.  My suspicion is that
> ACID uses the {sid,cid} combination as a unique identifier, and when it
> tries to move this event from snort to snort_archive and sees the {sid,cid}
> combination already there, it thinks it's a duplicate.  For some reason,
> ACID is re-assigning this combination!  Either this needs to be prevented,
> or ACID needs a new way of uniquely identifying events.  I could be totally
> off-base here, but this is the best I can come up with.
>
> I did some googling (of course) and found one or two other people with this
> problem, but no resolutions.  If anyone can point me in the right direction
> (or to a different forum), I would be GREATLY appreciative. 
>
> The vitals:
> ===========
> RHL 7.3
> MySQL 3.23.49
> ACID 0.9.6b21
> Snort 1.8.7
>
> Thanks in advance,
> Mike Cloppert


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
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