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

Russ Combs rcombs at ...402...
Fri Jun 8 13:02:42 EDT 2012


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 at ...3293...>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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20120608/0180353b/attachment.html>


More information about the Snort-devel mailing list