[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:22:08 EDT 2012


On Fri, Jun 8, 2012 at 1:17 PM, Gerard Beekmans <gerard at ...3293...>wrote:

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

It could be the cause of the resets.

>
> Gerard
>
> On Fri, Jun 8, 2012 at 12:02 PM, Russ Combs <rcombs at ...402...> 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 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!
>>>
>>
>>
>
>
> --
> Gerard Beekmans
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20120608/8e09ea2a/attachment.html>


More information about the Snort-devel mailing list