[Snort-devel] A "drop" rule using inline mode and NFQ mode causes an outbound network flood
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel