[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Apache Killer
- To: Levente Peres <sheridan@xxxxxxxxx>
- Subject: Re: [Full-disclosure] Apache Killer
- From: "-= Glowing Sex =-" <doomxd@xxxxxxxxx>
- Date: Wed, 24 Aug 2011 08:30:29 +1000
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 <sheridan@xxxxxxxxx> 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<security@xxxxxxxxxxxxxxxxxx>:
> >> 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/