search for: slowloris

Hi list! We tested mod_antiloris 0.4 and found it quite efficient, but before putting it in production, we would like to hear some feedback from freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is anyone using it? Do you have any other way to patch against Slowloris other than putting a proxy in front or using the HTTP accept filter? Thanks for your feedback, Martin

Hi, Those who are interested in anti Sloworis solution. I have built and packed mod_antiloris for C4/5. Packages are to be found at: http://fs12.vsb.cz/hrb33/el5/hrb/stable/i386/repoview/mod_antiloris.html http://fs12.vsb.cz/hrb33/el5/hrb/stable/x86_64/repoview/mod_antiloris.html http://fs12.vsb.cz/hrb33/el4/hrb/stable/i386/repoview/mod_antiloris.html

You may have heard of Slowloris and Nkiller2 (if not check them out), but there is also david: http://git.bogomips.org/cgit/david.git I wasn''t comfortable with announcing this two years ago when I wrote it. I''m OK now since Slowloris and Nkiller2 are similar (ok, Nkiller2 is lower-level and meaner) and attac...

...unknown AssignedTo: laforge at netfilter.org ReportedBy: urykhy at gmail.com i need to limit number of simultaneous connections to httpd: on server: iptables -A INPUT -p tcp -m connlimit --connlimit-above 5 --dport 80 -j DROP (there is onle one rule in firewall ) on client i run slowloris.. on the server under attack netstat -nta | grep :80 | grep ESTABLISHED | wc -l 180 as i understand 'iptables -L -n -v' - my rule never hits, existing behavior: on server under attack a lot of simultaneous connection from single ip. expected behavior: server should have only 5 connectio...

Hi, about an hour ago two web-serving VMs died at the same time with the following error on the console: INFO: task httpd:4304 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. httpd D 00af1f714d1112e2 0 4304 22471 4305 4303 (NOTLB) ffff88006574bdc8 0000000000000282 00000000000041f8

Hi, This morning, while checking for a correct deployment, we found out that the Unicorns we are using were sending 500 Internal errors very frequently to the HAProxy that sits in front of them. After some investigation, It turned out that HAProxy checks the backend by opening and closing a connection to the unicorn. Unfortunately the Unicorns we use ( v 0.990.0 ) will try to reply to this probe