> Reagrding this bug, > The release should have also specified a bugfix / workaround, ofcourse > usually this is the case, altho the one i have seen, does not work on all > boxes. > On a BSD 8.0 box, it killed eveything, swap/ram, eveything died/needed > reboot. now, what is quite annoying, i guess is that i had someone go > thru > my setup, aswell as myself, to check for anything that could trigger it, > we > found the gzip lines, but nothing else for mod_deflate so we went ahead > and > restarted, and bang, dead again... what do we do here ? > Apache has done nothing about this, there is no UN official patching, this > is nasty... Please, any suggestions for patching this, seriously, it > should > not be that i must have to shutdown a company webserver, incase someone > should attack it. > Regards, > xd >
'perl killapache.pl mysite.com 50' said: Host does not seem vulnerable and it did exited instantly. Tested it against local linux site using Apache 2.2.19 and the remote site uses 2.2.17. > > On 21 August 2011 01:31, Levente Peres <[email protected]> wrote: > >> My findings, hope it helps... Properly configured HAProxy with queue >> management and per-server limits can dampen the effects quite >> drastically. >> >> In my testing (three low-end SunFire servers and a LB) an attack volume >> of well over a 1000 threads was necessary to notice any small speed >> degradation on the frontend - which triggeres anti DOS immediately if >> done from outside LAN. System immediately recovers fully when the attack >> stops, no coredumps, nothing, not even after half an hour of sustained >> attack. No crashing or unstability whatsoever happened on any servers, >> not even at 2000, but dared not to test further on a live system... If >> performed from multiple IPs or varied content etc however, a pattern >> recognition scheme would be necessary to block it I believe... Also >> tested it with a simple one-server setup with Squid as frontend before >> apache, it reported not vulnerable... Not tested any further yet. >> >> Done on a "barefoot" apache however, it was devastating even at 100 >> threads regardless the lots of RAM and quadcode setup :-( >> >> Levente >> >> 2011.08.20. 14:31 keltezéssel, HI-TECH . írta: >> > Disabling mod_gzip/mod_deflate is a workaround I guess. >> > >> > 2011/8/20 Moritz Naumann<[email protected]>: >> >> On 20.08.2011 00:23 HI-TECH . wrote: >> >>> (see attachment) >> >>> /Kingcope >> >> Works (too) well here. Are there any workarounds other than rate >> >> limiting or detecting + dropping the traffic IPS-wise? >> >> >> >> Moritz >> >> >> > _______________________________________________ >> > Full-Disclosure - We believe in it. >> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> > Hosted and sponsored by Secunia - http://secunia.com/ >> > >> > >> > --- >> > avast! Antivirus: Inbound message clean. >> > Virus Database (VPS): 110819-1, 2011.08.19 >> > Tested on: 2011.08.20. 14:32:33 >> > avast! - copyright (c) 1988-2011 AVAST Software. >> > http://www.avast.com >> > >> > >> > >> > >> >> _______________________________________________ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ >> > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
