Re: Apache Killer

["-= Glowing Sex =-" <doomxd () gmail com>]

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 () gmail 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 () bluemoon 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 () gmail 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 () myproxylists 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 () sansz 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 () moritz-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/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/