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
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/
