[Snort-users] How snort handles several copies of the same packet?

Joel Esler jesler at ...1935...
Wed Oct 24 10:44:25 EDT 2012


Are you talking about Open Source Snort?  Or Sourcefire product?

Do you have a global threshold in place?


On Oct 24, 2012, at 10:42 AM, elof at ...6680... wrote:

> 
> Yes, there's an performance impact. That is expected.
> 
> But what about the alerting? Somewhere snort must be filtering/aggregating the packets, understanding that the "duplicates" are actually the same packet, and only generate ONE alert for its bad payload data.
> I'm asking for a description of this part.
> 
> How does snort detect and filter out these "duplicates"?
> Which packets are disregarded and which are kept?
> 
> Like if the packet in my example contain malicious code, will the logged packet be
> 
> routing)
> The first packet with TTL 60?
> 
> retransmission)
> The first packet with ipid 3333?
> 
> duplicate SPAN)
> Simply the first packet?
> Another question: Are true duplicates seen as retransmissions and processed as such?
> 
> 
> 
> Perhaps the answer is that the logging system simply detects that the next received, analyzed and logged packet is the same as the one just logged, and silently supresses it.
> I don't think this filtering/aggregation happen this late in the process though.
> Some clarification of how this works would be appreciated.
> 
> /Elof
> 
> 
> On Wed, 24 Oct 2012, Joel Esler wrote:
> 
>> On Oct 24, 2012, at 4:48 AM, elof at ...6680... wrote:
>>> I know that snort only generates ONE alert even if the mirrored traffic
>>> see the same packet twice or more:
>>> 
>>> ...like before and after a router:
>>> x:x:x:x:x:x y:y:y:y:y:y 1.1.1.1:1234 -> 2.2.2.2:80 ipid 3333, TTL 60
>>> y:y:y:y:y:y z:z:z:z:z:z 1.1.1.1:1234 -> 2.2.2.2:80 ipid 3333, TTL 59
>>> ^^^^^^^^^^^^^^^^^^^^^^^                                           ^^
>>> 
>>> ...or tcp retransmissions:
>>> x:x:x:x:x:x y:y:y:y:y:y 1.1.1.1:1234 -> 2.2.2.2:80 ipid 3333, TTL 60
>>> x:x:x:x:x:x y:y:y:y:y:y 1.1.1.1:1234 -> 2.2.2.2:80 ipid 3334, TTL 60
>>> x:x:x:x:x:x y:y:y:y:y:y 1.1.1.1:1234 -> 2.2.2.2:80 ipid 3335, TTL 60
>>>                                                        ^^^^
>>> 
>>> ...or two *exact* duplicates of every packet due to faulty SPAN:
>>> x:x:x:x:x:x y:y:y:y:y:y 1.1.1.1:1234 -> 2.2.2.2:80 ipid 3333, TTL 60
>>> x:x:x:x:x:x y:y:y:y:y:y 1.1.1.1:1234 -> 2.2.2.2:80 ipid 3333, TTL 60
>>> 
>>> 
>>> Only having one alert in the above cases is really nice, but I wonder:
>>> 
>>> Can someone describe how this is done and what is happening in snort, both
>>> on the individual packet level, and in stream5?
>>> 
>>> How does snort detect and filter out these "duplicates"?
>>> Which packets are disregarded and which are kept?
>> 
>> Everything is analyzed independently.  I've seen the problem commonly at many sites.  Filtering out the duplicate traffic on a span is important for optimum performance.
>> 
>> --
>> Joel Esler
>> Senior Research Engineer, VRT
>> OpenSource Community Manager
>> Sourcefire





More information about the Snort-users mailing list