[Snort-devel] odd problems with 2.3rc2

Joel Esler joel.esler at ...2021...
Mon Jan 24 07:06:35 EST 2005


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





More information about the Snort-devel mailing list