[Snort-devel] Unified2 Record Order

beenph beenph at ...2499...
Sat Jun 4 18:04:34 EDT 2011


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.
>>
>> 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




More information about the Snort-devel mailing list