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

[Gerard Beekmans <gerard () beekmansworld com>]

Hi Russ,

stream5_global is configured in snort.conf as follows:

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.

Gerard

On Fri, Jun 8, 2012 at 12:02 PM, Russ Combs <rcombs () sourcefire com> wrote:

> You've got a bunch or TCP resets there ( "[R]" ) so check stream5_global:
> max_active_responses.  You might need to disable (delete) that.
>
> On Fri, Jun 8, 2012 at 12:06 PM, Gerard Beekmans <gerard () beekmansworld com
> > wrote:
>
> > Hi guys,
> >
> > (I posted this message to the snort-users list yesterday as well. My
> > apologies for cross posting. I wasn't entirely sure on which list this
> > message belongs).
> >
> > I'm attempting to setup Snort with NFQ in an attempt to have it block
> > (D)DoS attacks (my server is currently under such an attack as we speak).
> >
> > In summary what happens is when a "drop" rule is triggered something goes
> > haywire and cause a flood of network traffic outbound to the host who
> > triggered it. The appears to continually trigger the rule itself as well as
> > /var/log/snort/alert file grows with that same alert over and over.
> >
> > Here's my setup and config:
> >
> > Linux distribution: Ubuntu 11.10
> > Snort version: 2.9.2.3
> > DAQ version: 0.6.2
> >
> > I compiled Snort and DAQ from source, installed other dependencies from
> > Ubuntu's repository (herein may lie a problem if this caused a version
> > problem as some of the installed packages aren't necessary the latest
> > versions).
> >
> > I kept all the default settings during "configure" stages and installed
> > the free signatures for registered users.
> >
> > I run snort with:
> >     snort -c snort.conf -Q --daq nfq --daq-var queue=1
> >
> > iptables rule for testing:
> >     iptables -A INPUT -p tcp --dport 2222 -j NFQUEUE --queue-num 1
> >
> > Snort test rule:
> > alert tcp any any -> $HOME_NET 2222 (msg:"Port 2222
> > Test"; detection_filter:track by_src, count 20, seconds 10; sid:1000002;
> > rev:1;)
> >
> > HOME_NET is defined in snort.conf as:
> > ipvar HOME_NET public_ip1/32,public_ip2/32,internal_ip/24
> >
> > An ssh server runs on port 2222 so the test is simply "ssh -p 2222
> > remote_ip"
> >
> > First ssh attempt gives me a login prompt, no alerts yet. Start a second
> > attempt right away pushes beyond the 20 matches in 10 seconds:
> >
> > [**] [1:1000002:1] Port 2222 Test [**]
> > [Priority: 0]
> > 06/07-15:12:47.471858 <LOCAL_IP>:65187 -> <REMOTE_IP>:2222
> > TCP TTL:115 TOS:0x0 ID:27388 IpLen:20 DgmLen:56 DF
> > ***AP*** Seq: 0x50B79AD1  Ack: 0x384CA760  Win: 0x3ED2  TcpLen: 20
> >
> > I get that alert a few times in a row, one for each rule match after the
> > initial conditions is met.
> >
> > Now I change the rule from "alert" to "drop" and restart snort. I don't
> > change anything else:
> >
> > drop tcp any any -> $HOME_NET 2222 (msg:"Port 2222 Test";
> > detection_filter:track by_src, count 20, seconds 10; sid:1000002; rev:1;)
> >
> > Using iptables -Z I zero the INPUT chain and fire up ssh again twice in a
> > row.
> >
> > The alerts flood in never ending like this:
> >
> > [**] [1:1000002:1] Port 2222 Test [**]
> > [Priority: 0]
> > 06/07-15:20:53.375879 <CLIENT_IP>:36590 -> <SERVER_IP>:2222
> > TCP TTL:115 TOS:0x0 ID:27116 IpLen:20 DgmLen:40
> > ***A*R** Seq: 0xF6193288  Ack: 0x12F26B14  Win: 0x0  TcpLen: 20
> >
> > [**] [1:1000002:1] Port 2222 Test [**]
> > [Priority: 0]
> >  06/07-15:20:53.375918 <CLIENT_IP>:36590 -> <SERVER_IP>:2222
> > TCP TTL:115 TOS:0x0 ID:28731 IpLen:20 DgmLen:40
> > ***A*R** Seq: 0xF6193288  Ack: 0x12F26B14  Win: 0x0  TcpLen: 20
> >
> > [**] [1:1000002:1] Port 2222 Test [**]
> > [Priority: 0]
> > 06/07-15:20:53.376045 <CLIENT_IP>:36590 -> <SERVER_IP>:2222
> > TCP TTL:115 TOS:0x0 ID:8801 IpLen:20 DgmLen:40
> > ***A*R** Seq: 0xF6193288  Ack: 0x12F26B14  Win: 0x0  TcpLen: 20
> >
> > tcpdump shows traffic like this:
> >
> > # tcpdump -n -i eth0 'port 2222'
> > 15:20:53.506938 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq
> > 896, ack 1294, win 0, length 0
> > 15:20:53.506945 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq
> > 896, ack 1294, win 0, length 0
> > 15:20:53.506946 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq
> > 896, ack 1294, win 0, length 0
> > 15:20:53.506947 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq
> > 896, ack 1294, win 0, length 0
> > 15:20:53.506948 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq
> > 896, ack 1294, win 0, length 0
> > 15:20:53.506949 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq
> > 896, ack 1294, win 0, length 0
> > 15:20:53.506949 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq
> > 896, ack 1294, win 0, length 0
> >
> > As you can see, tcpdump sees the traffic as going from server back to the
> > client (ie: me who initiated the ssh session). The snort alerts display it
> > the other way around. My local firewall sees the traffic come in as well
> > and it's dropped here.
> >
> > In the span of a couple of seconds that this went on, iptables shows to
> > have processed over 30,000 packets. There are an equal number of snort
> > entries in the /var/log/snort/alert file with the same message as shown
> > above and my local firewall is showing the same numbers of incoming packets.
> >
> > The "drop" rule does work by the way. The ssh connections don't complete
> > anymore and are dropped as they should. This flood of data, however,
> > effectively generates a DoS attack while trying to prevent one.
> >
> > Something's obviously setup wrong. Do any of you have any suggestions
> > what to look at?
> >
> > Thanks,
> > Gerard Beekmans
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > 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!


-- 
Gerard Beekmans

------------------------------------------------------------------------------
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!