Hi Russ,<div><br></div><div>stream5_global is configured in snort.conf as follows:</div><div><br></div><div><div>preprocessor stream5_global: track_tcp yes, \</div><div>   track_udp yes, \</div><div>   track_icmp no, \</div>
<div>   max_tcp 262144, \</div><div>   max_udp 131072, \</div><div>   max_active_responses 2, \</div><div>   min_response_seconds 5</div><div><br></div><div>Would removing the max_active_responses make a difference? It doesn't seem to be set incorrectly. I'll give it a try regardless.</div>
<div><br></div><div>Gerard</div><br><div class="gmail_quote">On Fri, Jun 8, 2012 at 12:02 PM, Russ Combs <span dir="ltr"><<a href="mailto:rcombs@...402..." target="_blank">rcombs@...402...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You've got a bunch or TCP resets there ( "[R]" ) so check stream5_global: max_active_responses.  You might need to disable (delete) that.<br>
<br><div class="gmail_quote"><div><div class="h5">On Fri, Jun 8, 2012 at 12:06 PM, Gerard Beekmans <span dir="ltr"><<a href="mailto:gerard@...3293..." target="_blank">gerard@...3293...</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><span>Hi guys,</span><div><br></div><div>(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).</div>

<div><br></div>
<div>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).</div>
<div><br></div><div>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.</div>



<div><br></div><div>Here's my setup and config:</div><div><br></div><div>Linux distribution: Ubuntu 11.10</div><div>Snort version: 2.9.2.3</div><div>DAQ version: 0.6.2</div><div>
<br></div><div>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).</div>



<div><br></div><div>I kept all the default settings during "configure" stages and installed the free signatures for registered users.</div><div><br></div><div>I run snort with:</div><div>
    snort -c snort.conf -Q --daq nfq --daq-var queue=1</div><div><br></div><div>iptables rule for testing:</div><div>    iptables -A INPUT -p tcp --dport 2222 -j NFQUEUE --queue-num 1</div><div><br>
</div><div>Snort test rule:</div><div>alert tcp any any -> $HOME_NET 2222 (msg:"Port 2222 Test"; detection_filter:track by_src, count 20, seconds 10; sid:1000002; rev:1;)</div><div><br></div>
<div>HOME_NET is defined in snort.conf as:</div><div>ipvar HOME_NET public_ip1/32,public_ip2/32,internal_ip/24</div><div><br></div><div>An ssh server runs on port 2222 so the test is simply "ssh -p 2222 remote_ip"</div>



<div><br></div><div>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:</div><div><br></div><div><div>[**] [1:1000002:1] Port 2222 Test [**]</div>



<div>[Priority: 0]</div><div>06/07-15:12:47.471858 <LOCAL_IP>:65187 -> <REMOTE_IP>:2222</div><div>TCP TTL:115 TOS:0x0 ID:27388 IpLen:20 DgmLen:56 DF</div><div>***AP*** Seq: 0x50B79AD1  Ack: 0x384CA760  Win: 0x3ED2  TcpLen: 20</div>



</div><div><br></div><div>I get that alert a few times in a row, one for each rule match after the initial conditions is met.</div><div><br></div><div>Now I change the rule from "alert" to "drop" and restart snort. I don't change anything else:</div>



<div><br></div><div>drop tcp any any -> $HOME_NET 2222 (msg:"Port 2222 Test"; detection_filter:track by_src, count 20, seconds 10; sid:1000002; rev:1;)</div><div><br></div><div>Using iptables -Z I zero the INPUT chain and fire up ssh again twice in a row.</div>



<div><br></div><div>The alerts flood in never ending like this:</div><div><br></div><div><div>[**] [1:1000002:1] Port 2222 Test [**]</div><div>[Priority: 0]</div><div>06/07-15:20:53.375879 <CLIENT_IP>:36590 -> <SERVER_IP>:2222</div>



<div>TCP TTL:115 TOS:0x0 ID:27116 IpLen:20 DgmLen:40</div><div>***A*R** Seq: 0xF6193288  Ack: 0x12F26B14  Win: 0x0  TcpLen: 20</div><div><br></div><div>[**] [1:1000002:1] Port 2222 Test [**]</div><div>[Priority: 0]</div>


<div>
06/07-15:20:53.375918 <CLIENT_IP>:36590 -> <SERVER_IP>:2222</div><div>TCP TTL:115 TOS:0x0 ID:28731 IpLen:20 DgmLen:40</div><div>***A*R** Seq: 0xF6193288  Ack: 0x12F26B14  Win: 0x0  TcpLen: 20</div><div><br>



</div><div>[**] [1:1000002:1] Port 2222 Test [**]</div><div>[Priority: 0]</div><div>06/07-15:20:53.376045 <CLIENT_IP>:36590 -> <SERVER_IP>:2222</div><div>TCP TTL:115 TOS:0x0 ID:8801 IpLen:20 DgmLen:40</div>



<div>***A*R** Seq: 0xF6193288  Ack: 0x12F26B14  Win: 0x0  TcpLen: 20</div></div><div><br></div><div>tcpdump shows traffic like this:</div><div><br></div><div># tcpdump -n -i eth0 'port 2222'</div>
<div><div>15:20:53.506938 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq 896, ack 1294, win 0, length 0</div><div>15:20:53.506945 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq 896, ack 1294, win 0, length 0</div>



<div>15:20:53.506946 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq 896, ack 1294, win 0, length 0</div><div>15:20:53.506947 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq 896, ack 1294, win 0, length 0</div>



<div>15:20:53.506948 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq 896, ack 1294, win 0, length 0</div><div>15:20:53.506949 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq 896, ack 1294, win 0, length 0</div>



<div>15:20:53.506949 IP <SERVER_IP>.2222 > <CLIENT_IP>.36590: Flags [R.], seq 896, ack 1294, win 0, length 0</div></div><div><br></div><div>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.</div>



<div><br></div><div>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.</div>



<div><br></div><div>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.</div>



<div><br></div><div>Something's obviously setup wrong. Do any of you have any suggestions what to look at?</div><div><br>Thanks,</div><div>Gerard Beekmans</div><br>
<div><br></div>
<br></div></div>------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>_______________________________________________<br>
Snort-devel mailing list<br>
<a href="mailto:Snort-devel@lists.sourceforge.net" target="_blank">Snort-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/snort-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-devel</a><br>
<br>
Please visit <a href="http://blog.snort.org" target="_blank">http://blog.snort.org</a> for the latest news about Snort!<br></blockquote></div><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Gerard Beekmans</div><div><br></div><br>
</div>