Re: [Full-disclosure] Apache Killer

[nix@xxxxxxxxxxxxxxxx]

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


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/