[Snort-devel] A "drop" rule using inline mode and NFQ mode causes an outbound network flood

Gerard Beekmans gerard at ...3293...
Fri Jun 8 12:06:39 EDT 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20120608/cf34ff4b/attachment.html>


More information about the Snort-devel mailing list