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 =- <[email protected]> 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 <[email protected]> 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 =-" <[email protected]> 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, <[email protected]> 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 <[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/ >> > > >> > > >> > > >> > >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
