[Snort-devel] A "drop" rule using inline mode and NFQ mode causes an outbound network flood

Russ Combs rcombs at ...402...
Fri Jun 8 14:06:36 EDT 2012

I'm not sure why you see the flood.  It seems like the resets are causing
resets, which the code looks out for.

Can you send a pcap of the onset of the flood?

On Fri, Jun 8, 2012 at 1:32 PM, Gerard Beekmans <gerard at ...3293...>wrote:

> preprocessor stream5_global: track_tcp yes, \
>>>    track_udp yes, \
>>>    track_icmp no, \
>>>    max_tcp 262144, \
>>>    max_udp 131072, \
>>>    max_active_responses 2, \
>>>    min_response_seconds 5
>>> Would removing the max_active_responses make a difference? It doesn't
>>> seem to be set incorrectly. I'll give it a try regardless.
>> It could be the cause of the resets.
> Confirmed. Removing the option made the problem go away. The drop rule
> still works as planned. I get occasional F flags being sent out now (Fin -
> end of data) after the rule triggered but nothing to yet worry about.
> Now the question remains: why would that config option cause the flood and
> how can it be fixed? From what I understand of it, it's a feature that
> could be helpful in some situations.
> Thanks for the help Russ.
> Gerard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20120608/ea465dd7/attachment.html>

More information about the Snort-devel mailing list