[Snort-users] Performance again

Matt Kettler mkettler at ...4108...
Tue Dec 23 13:08:01 EST 2003


At 02:07 PM 12/23/2003, Edin Dizdarevic wrote:
>Another useful information. Snort will never drop a packet itself, it is
>always the connection BPF or LSF respectively and libpcap where packets
>are being dropped, simply due to the timeouts which the BPF device has
>bound to its buffers (which again may be influenced by the corresponding
>libpcap-app).
>
>  From my point of view, I think I am a step further now.

Good, glad I could help.

>But: If a packet is dropped from the queue that is needed for ex.
>defragmentation or in order to reassemble the TCP-stream, either I
>have to throw away the complete stream/packet or my content may feature
>some holes...

Yep.. but that will happen no matter where the drops occur, at the pcap 
layer or at the snort layer.

That also illustrates why packet drops aren't a good thing. They are 
weakness a knowing attacker can take advantage of.

And it's not just tcp streams that suffer from "holes" as a result of 
drops.. ANY packet drop constitutes a hole in the data, where an attack 
_could_ have been. This could be udp/dns just as easily as tcp/http.

AFAIK snort tries to mitigate the impact of the holes by sending down as 
much of the data as it actually got whenever stream4 flushes. The streams 
are flushed whenever data goes back over the connection, or when a timeout 
expires.


>I will probably come up with few new questions later on. Have to think
>about it a bit now... ;)

ok, enjoy. 





More information about the Snort-users mailing list