Martin Turgeon a écrit :
Thomas Rasmussen a écrit :
Martin Turgeon wrote:
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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to
"freebsd-security-unsubscr...@freebsd.org"
Hello,
I am using it succesfully although not under any serious load, same
Apache and FreeBSD versions. I found it easy (compared to the
alternatives) and efficient, and no I don't know of any other ways of
blocking the attack, short of using Varnish or similar. However,
accf_http doesn't help at all, since HTTP POST requests bypass the
filter. HTTP POST can be enabled by passing the -httpready switch to
Slowloris.
Please report back with your findings, I've been wondering how it
would perform under load.
Best of luck with it,
Thomas Rasmussen
Hi everyone,
We haven't put mod_antiloris in production yet, but I wrote this
little shell script to protect us against distributed attack. It's
running every minutes in crontab. It checks for any IP with more than
100 connections in FIN_WAIT_2 state and block those IP in PF.
#!/bin/sh
/usr/bin/netstat -nfinet | grep FIN_WAIT_2 > netstat.out
/usr/local/sbin/expiretable -t 300 slowloris
for ip in `awk '{print $5}' netstat.out | awk -F. '{print
$1"."$2"."$3"."$4}' | sort | uniq` ; do
if [ `grep -c $ip netstat.out` -gt 100 ] ; then
pfctl -t slowloris -Ta $ip 2> /dev/null
fi
done
Did anyone have any comments on the script itself or the method used
to detect the attackers?
Thanks for your input,
Martin
Sorry for replying to my own post, but I have new informations to share.
We putted in production mod_antiloris and my script yesterday night. No
problem yet with the module but I got a few false positive with my
script. It seems that there are a few IP that got more than 100
simultaneous connections in FIN_WAIT_2 state. We noticed that a lot of
the FIN_WAIT_2 connections were related to a jail running Lighttpd
(immune to slowloris, which IP is 127.0.0.25) so I modified the initial
netstat so it looks like that:
/usr/bin/netstat -nfinet | grep -v 127.0.0.25 | grep FIN_WAIT_2 >
netstat.out
We didn't get any false positive since then but I'm wondering how a
client can have so many unclosed connections? To get in FIN_WAIT state,
it's the server that closed the connections but the client never closed
it's side of the connections. Does anyone have an idea how this can
happen? Is this because of a bad browser, a bad OS/TCP stack or
something else?
Thanks for taking the time to shed some light on this,
Martin
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
