Date: Thu, 08 Oct 2009 12:19:01 -0400 From: Martin Turgeon <freebsd@optiksecurite.com> To: Thomas Rasmussen <thomas@gibfest.dk> Cc: freebsd-security@freebsd.org Subject: Re: Update on protection against slowloris Message-ID: <4ACE10F5.2000303@optiksecurite.com> In-Reply-To: <4ACB7391.5040204@optiksecurite.com> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> <4ACB7391.5040204@optiksecurite.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ACE10F5.2000303>