[Snort-devel] odd problems with 2.3rc2

Martin Roesch roesch at ...402...
Mon Jan 24 08:02:34 EST 2005


If you want to have the data for associating tagged packets with the 
originating event right now, it's available from Barnyard.  Does BASE 
have a Barnyard output plugin?

       -Marty


On Jan 24, 2005, at 6:24 AM, Joel Esler wrote:

> It would be handy, that way we could code something into BASE (as well 
> as other tools) that will "reconstruct" the session.
>
> Joel
>
> Martin Roesch wrote:
>
>> Hi Russell,
>>
>> I can't answer why the rule is firing without looking into it a lot 
>> more but I can tell you what's happening with the tagged packets.  If 
>> Snort is using unified logging, instead of logging the pseudopacket 
>> generated by stream4 it will instead log the original packets that 
>> constituted the stream that was used to generate the pseudopacket in 
>> the first place.  This is so that you can see what was on the wire 
>> originally instead of getting the pseudopacket which tends to mess up 
>> analysts who want to know what the original TTL/TOS/etc were.  The 
>> unified header contains reference info that will let you see which 
>> trigger packet (the first in the segment queue) the tagged packets 
>> are associated with.
>>
>> Hope this clears things up.
>>
>> BTW, the reference field isn't all that great, because it is just a 
>> counter of the number of events since startup.  I floated the idea of 
>> having a "packet serial number" structure that could be used to 
>> uniquely identify a sensor, instance and event id that would be 
>> attached to each unified event and associated tagged packets.
>>
>>      -Marty
>>
>>
>> On Jan 10, 2005, at 4:13 PM, Russell Fulton wrote:
>>
>>> On Mon, 2005-01-10 at 17:19 +0100, Dirk Geschke wrote:
>>>
>>>>>
>>>>> I've just installed RC2 and I have observed a couple of problems:
>>>>>      1. a few rules are triggering when there does not appear to 
>>>>> be any
>>>>>         reason.  One rule is triggering often, for no apparent 
>>>>> reason:
>>>>
>>>>
>>>> maybe you are using the unified output plugin?
>>>
>>>
>>> I am.
>>>
>>>>  In this case it
>>>> is possible that the rules fires on a stream4 rebuild packet.
>>>> This packet is stored in the original parts and only the first
>>>> one gets the signature message. All further packets are "Tagged
>>>> Packet"s and are stored in the log facility.
>>>
>>>
>>> That explains part of the problem (the tagged packets) but not why 
>>> the
>>> rules are triggering in the first place.
>>>
>>> Thanks, Russell
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> The SF.Net email is sponsored by: Beat the post-holiday blues
>>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>>> _______________________________________________
>>> 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