Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood

[Russ Combs <rcombs () sourcefire com>]

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 () beekmansworld com>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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!