Date: Wed, 24 Aug 2011 11:03:30 +1000
From: "-= Glowing Sex =-" <doomxd@...il.com>
To: Nam Nguyen <namn@...emoon.com.vn>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Killer

oops.. forgot to cc the list :P wuld maybe help...

Yes, i still think a nice .sh/.patch for this would be great for things like
productuion boxes wich run 400 or so sites and need a fast fix b4 things
start to crumble :s.. in my case, it is one box out of 10 wich is being the
pain, and, i dont want to reinstall even if i can avoid it.


On 24 August 2011 11:01, -= Glowing Sex =- <doomxd@...il.com> wrote:

> Hello,
>     Thanks, I will try this, and also disabling gzip compression, i dont
> have mod_deflate on this particular 8.0 bsd production box, so i will run
> with the gzip and, try to add this into the headers module.. i am sure there
> should be something made, like a small bash script, to patch any apache
> against this.. need to find a universal patch instead of, having to
> reinstall/reconfigure things, and a patch wich would not render componentry
> useless... i hope this is what happens... a solid .patch or unified diff
> file would be perfect but, the version on Amazon VPS service is completely
> immune to this, and they would be running alot of devel stuff.. Well in
> theyre free section... I have a vps thru theyre free service,and it is
> immune,but how to make something wich is a patch.sh / patch.patch and make
> it workable for production boxes wich should not be offline for even
> 10minutes really.
> cheers,
> xd
>
>
> On 24 August 2011 10:54, Nam Nguyen <namn@...emoon.com.vn> wrote:
>
>> Disabling Partial Content would be workable.
>>
>> 1. Load up headers_module.
>>
>> 2. Add this line: RequestHeader unset Range.
>>
>> I hope that helps.
>> --
>> Nam Nguyen, CISA, CISSP, CSSLP
>> Blue Moon Consulting Co., Ltd
>> http://www.bluemoon.com.vn
>>
>>
>> On Wed, 24 Aug 2011 08:54:53 +1000
>> "-= Glowing Sex =-" <doomxd@...il.com> wrote:
>>
>> > Yea, i think only way to get around it is to upgrade httpd versions.. I
>> > tried it on freeBSD8.2 standard default settings and httpd devel and
>> that
>> > seems fine, even standard httpd alone on another box, again running 8.2,
>> is
>> > fine.
>> > Some boxes also seem to only consume ram, when it is swap that is the
>> real
>> > killer... it also is not possible to b stopped with apache commands,
>> once
>> > the box starts tipping, you must killall -9 httpd , just to stop the box
>> > from tipping over, this is when the script is execd against it in
>> testing,
>> > we were able to only stop it that way, on a badly affected httpd.
>> > I still wish apache.org would at the least release some form of
>> advisory for
>> > this and help for some people who dislike upgrades :s like bosses with
>> small
>> > pockets ;p
>> > cheers
>> > xd
>> >
>> >
>> >
>> > On 24 August 2011 08:47, <nix@...roxylists.com> wrote:
>> >
>> > > > 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@...sz.org> 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@...itz-naumann.com>:
>> > > >> >> 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/
>> > >
>> > >
>> > >
>>
>
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists