[Snort-devel] RFE: improving generation of event_ref

Martin Roesch roesch at ...402...
Thu Oct 7 11:30:32 EDT 2004

I thought about having a packet serial that was something like

typedef struct _PktSerial
	u_int8_t  if_mac[6];
	time_t start_time;
          u_int32_t pkt_id;
} PktSerial;

This would let us have a unique collection interface identifier, start 
time reference and an instance count for every packet and event.  I 
proposed this a few months ago and as I recall Frank Knobbe thought 
that tying the serial to the MAC was bad because interfaces can be 
changed on devices and for one other reason that I'm not remembering 
right now.  I contend that the MAC doesn't really matter except to give 
us a unique hardware identifier that can be referenced to identify 
Snort runs, but I'm not married to it or anything.  I think using the 
IP address of the interface instead wouldn't be particularly useful 
since IP addresses are much easier and more frequently changed as well 
as the fact that stealthed interfaces don't have IP addresses.

The other problem with what I've described above is that using a 
u_int32_t for pkt_id might be too small for some Snort runs, in theory 
you can run thru 4 billion packets in about an hour on a gigabit 
network (although that would be next to impossible in practice).  I'm a 
little leery of using a u_int64_t since it doesn't fit in 32-bit 
registers on x86 machines easily and would represent a minor 
performance impact.  Maybe we could do another u_int32_t that indicates 
the "series" of a packet (how many times we've wrapped the 32-bit 
pkt_id number).

Just my thoughts on the topic.


On Oct 7, 2004, at 8:59 AM, Alex Butcher, ISC/ISYS wrote:

> Hi -
> Has anyone had any thoughts on improving the 'randomness' of the 
> event_ref field used to associate tagged packets with their parent 
> alert?
> I ask, because if snort is restarted, the event_ref counter resets, 
> and tagged packets that were associated with an alert raised in a 
> previous instance of snort may have the same event_ref as alerts 
> raised by the current run.
> Could event_ref be a hash of the parent alert's 4-tuple (i.e. src 
> addr, dst addr, sport, dport) or something? Combining a timestamp into 
> the hash might be a good idea, too.
> Best Regards,
> Alex.
> -- 
> Alex Butcher: Security & Integrity, Personal Computer Systems Group
> Information Systems and Computing             GPG Key ID: F9B27DC9
> GPG Fingerprint: D62A DD83 A0B8 D174 49C4 2849 832D 6C72 F9B2 7DC9
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
Sourcefire - Discover.  Determine.  Defend.
roesch at ...402... - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org

More information about the Snort-devel mailing list