Bugtraq mailing list archives
Re: Apache memory/process management.
From: dgaudet () ARCTIC ORG (Dean Gaudet)
Date: Wed, 31 Dec 1997 12:36:39 -0800
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime () docserver cac washington edu for more info. ------=_NextPart_000_0088_01BD160F.5B0AD900 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-2 Content-ID: <Pine.LNX.3.95dg3.971231120623.26261F () twinlark arctic org> I really doubt that bugtraq is the place to continue this discussion. I suggest that you move it to the Apache development mailing list new-httpd () apache org, subscribe via majordomo () apache org (it's a reply-to style list so it's not useful for discussion with folks who are off the list). This is documented in the ABOUT_APACHE file. We also have a bug reporting system through which you can report these bugs. Remember we're free software, and if you can help constructively it's appreciated. I sent this to you in private mail, but I'll post it again here. I said something like this in my post that contained a patch for your first problem but that post never seemed to make it to bugtraq. Apache, like every other network service I'm aware of, is subject to DoS attacks that consume resources. That's it, period. We can't guarantee we'll catch every one of them. I really don't think posting them one-by-one to bugtraq is going to help anything. Perhaps you'd be better spending your time working on a more generic solution than forcing us to tweak one problem at a time. Folks can see some of my thoughts on a related issue, and see yet another DoS attack, by visiting <http://bugs.apache.org/index/full/1028>. That is specific to memory consumption. But there's obviously more we can do in a similar vein using resource limits. Doing all of this comes at a performance penalty. I don't think I have to explain examples of DoS attacks against all web servers, or against smtp daemons, or IRC servers, or any number of networked services. They exist in all of them. Creating generic workarounds is an effort much more well spent than poking away at the problems one by one as they're discovered. Performance problems like the first beck patch are things that we will notice as we profile the server. Until recently most of my effort on tuning Apache's performance has been in the syscall area. However in 1.3 there are other changes to how directories are handled that could have an impact on your beck2 attack. I know for certain that your beck2 attack is affected by the performance tuning guidelines at <http://www.apache.org/docs/misc/perf-tuning.html>. Specifically the sections mentioning lstat() and stat(). But the easiest way to fix beck2 is to use mod_rewrite to lift this problem out of the filesystem. Add these to your config: RewriteEngine on RewriteRule /+[^/]+/+[^/]+/+ /yeah-whatever.html Add any number more slashes as are appropriate for your system. This is not a decision that Apache can make, slashes do not necessarily have to have filesystem semantics. Dean ------=_NextPart_000_0088_01BD160F.5B0AD900--
Current thread:
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Steve Bellovin (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Crispin Cowan (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Kragen (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Tim Newsham (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Crispin Cowan (Dec 19)
- Linux vsyslog() overflow Solar Designer (Dec 20)
- Re: Linux vsyslog() overflow Dann Lunsford (Dec 22)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Mark Whitis (Dec 30)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Ranaur the Elven Warlock (Dec 30)
- Apache memory/process management. MichaĆ Zalewski (Dec 31)
- Re: Apache memory/process management. Dean Gaudet (Dec 31)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Crispin Cowan (Dec 19)