[Snort-users] Performance again
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
> 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
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
>I will probably come up with few new questions later on. Have to think
>about it a bit now... ;)
More information about the Snort-users