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

Gerard Beekmans gerard at ...3293...
Fri Jun 8 13:17:57 EDT 2012


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.

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/3db344a2/attachment.html>


More information about the Snort-devel mailing list