Re: Unified2 Record Order

[Steven Sturges <ssturges () sourcefire com>]

This is already there within the unified2 packet event structure.
There are fields for the event_id and both the seconds from the
origianal event, as well as the packet timestamp.

typedef struct _Serial_Unified2Packet
{
     uint32_t sensor_id;
     uint32_t event_id;
     uint32_t event_second;
     uint32_t packet_second;
     uint32_t packet_microsecond;
     uint32_t linktype;
     uint32_t packet_length;
     uint8_t packet_data[4];
} Serial_Unified2Packet;

So, packet records will have both the event ID (the 32 bit value that
you indicate could wrap -- split by 16bits with -G), and the 
event_second field from the original event.

On 6/4/11 6:04 PM, beenph wrote:
> On Sat, Jun 4, 2011 at 12:08 PM, beenph<beenph () gmail com>  wrote:
> > On Sat, Jun 4, 2011 at 11:44 AM, Steven Sturges<ssturges () sourcefire com>  wrote:
> > > Yes, this is possible... When tagging packets associated with
> > > events, subsequent packets are logged as they arrive, and could
> > > be interspersed with other events and packets.
> >
> > > Within the unified2 structure, there is an event ID, and all
> > > data associated with a unique event are logged with that event ID.
> > >
> > > That includes the event itself, any associated packets, as well
> > > as extra data events (eg, X-Forwarded-For data from HTTP that was
> > > added in 2.9.0).
> > >
> > > Hope this helps.
> > >
> > > Cheers.
> > > -steve
>
> I was reading back my i self and i think i was not clear enough in
> want i wanted to express,
> sorry i shouldn't have posted that quickly apologies for the polution :).
>
> The following is an analysis i have done, and i could be wrong, please
> correct me if it is the case.
>
> I think the main concern was that it is that its possible for unified2
> file to contain packets that are related to an event that would occur
> after an event.
>
> I agree with this, especially with tagged packets and possibly with
> some preprocessor.
>
> If we can agree on this, the other issue could be how do we correlate
> those packets with the original event.
>
>
> The only "MAIN" "reference point" is the event_id which is an unsigned
> 32 bit integer,
> reference time (ref_time) in the Event structure also exist as a
> reference but as soon as CallLogFuncs() is called this get
> overwritten.
>
> That 32 bit integer  event_id can also be OR'ed with a 16 bit integer
> if the snort -G flag is specified: Ref : ScEventLogId() in snort.h.
>
> Now if you have a snort process running for a while or logging ALOT,
> its feasable and possible that event_id would wrap, and there is no
> way (outside) the snort
> process that i am aware of that would tell you that event X would not
> trigger anymore or event that the event_id counter is wrapped.
>
> if( (event_id + 1) == 0)
> {
>       /* lets us know your wrapping ....*/
> }
>
>
> So if you cache event X in a process reading unified2 file, its
> possible that you could encounter event_id X again in the future
> and that reference to event_id X(1) is not the same event as event_id X(2).
>
>
> This drill down to correlation, since you would like to be able to
> associate tagged packets to the original alerting
> Event. But what happen if your event_id wrap up (Either full 32bit or
> splited 16 bit event_id).
>
> If CheckTagList() find a matching event for the packet, it will create
> a new event and
> return to his caller CheckTagging(), CheckTagging() will then call
> CallLogFuncs().
>
> CallLogFuncs() will set ref time sec and u_sec to the time of the
> logging packet.
> Thus the information that was previously set to The triggering event
> packet time information from CheckTagList()is now overwritten.
> The only reference to the trigerring event is the event_id, but what
> happend if you had an event_id wrap arround?
>
> This is where i have a tendancy to not rely on event_id generated from
> snort but to rely mainly on
> association with SIP/DIP/SPORT/DPORT for tagged packets. But if you
> have multiple instance of a tagging rule,
> its hard to find which packets where part of context 1 and context 2
> with this key since the event could have an
> overlaping key.
>
> (A possibility if alot of events are being logged).
>
>
> Mabey there should be an other information stored in the Event structure
> for tagged packets in particular that would withold the reference time
> of the original trigerring
> packets that could be passed to unified2 and that could be use to
> clearly identify references that could
> be passed to a backend store for clear indentification/correlation.
>
> And thus allow a safe use of snort internal event_id reference with
> this information in combinaison.
> (The idea of keeping the original event time is quite good, but if it
> gets overwritten in the process its quite useless IMHO).
>
>
> Hopefully i have expressed my self better this time.
>
>
> -elz

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel