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

[Gerard Beekmans <gerard () beekmansworld com>]

Hi guys,

The subject of this email might not be entirely accurate but it was the
best way I could describe it.

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 and
I'm having trouble keeping up with the ever changing IP addresses so I
wanted to look at Snort to automate it).

What I'm seeing happen is once a "drop" rule is triggered something goes
haywire and cause a flood of network traffic outbound to the host who
triggered it as well as it keep triggering that same rule and the
/var/log/snort/alert file grows with alerts.

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 2000 -j NFQUEUE --queue-num 1

Snort test rule:
alert tcp any any -> $HOME_NET 2000 (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 server"

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:

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 as there's no session established to my actual
computer for it to pass onto.

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 alert file with the same message as shown above and my local
firewall is showing the same numbers.

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-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!