[Snort-devel] Unified2 Record Order
ssturges at ...402...
Mon Jun 6 10:43:02 EDT 2011
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
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 at ...2499...> wrote:
>> On Sat, Jun 4, 2011 at 11:44 AM, Steven Sturges<ssturges at ...402...> 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.
> 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
> 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() 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.
More information about the Snort-devel