Snort mailing list archives
Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood
From: Russ Combs <rcombs () sourcefire com>
Date: Fri, 8 Jun 2012 13:02:42 -0400
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!
------------------------------------------------------------------------------ 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!
Current thread:
- A "drop" rule using inline mode and NFQ mode causes an outbound network flood Gerard Beekmans (Jun 07)
- <Possible follow-ups>
- A "drop" rule using inline mode and NFQ mode causes an outbound network flood Gerard Beekmans (Jun 08)
- Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood Russ Combs (Jun 08)
- Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood Gerard Beekmans (Jun 08)
- Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood Russ Combs (Jun 08)
- Message not available
- Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood Russ Combs (Jun 08)
- Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood Gerard Beekmans (Jun 08)
- Re: A "drop" rule using inline mode and NFQ mode causes an outbound network flood Russ Combs (Jun 08)