PQ> I think it is slightly deceptive to say 2.1.3-beta doesn't handle a PQ> DDoS attack very well -- 1.3.x or 2.0.x would not do any better.
I agree, that pre-forked model would have been hopeless. PQ> > * Apache2 can handle 16000 active open connections on a reasonable sized PQ> > box, at least if they are all bogus and going to be rejected, without PQ> > recompilation of glibc. PQ> 16,000 isn't a problem, if you have more RAM. (2gb won't cut it, I PQ> think). I'm not sure why this should be. What is the usage per active connection, especially when the connections are trivial and going to be terminated before actually doing anything. The irc control machines that control botnets can cope with this many clients without issue or this much memory usage. But you also suggest that it may have been a memory leak, so it is hard to know what the answer is here. I'll grab that memory leak patch anyway. PQ> > * A flag for rejecting slow writers or peculiar ones (malformed garbage PQ> > gets you kicked sooner). PQ> > PQ> Sometimes it is hard to decide. Is it a DDoS client, or just a user on PQ> a 14.4 modem? I believe even the slowest modem will not spoon feed request characters one packet for one character .. this is a very peculiar thing to do. When I watch our normal traffic I never see 1-byte PUSH packets on request phase, despite the entire range of traffic from broadband to modems to overseas users to local ones. Certainly some kind of unusual request phase early detection option would be nice - such as aforementioned garbage characters, dribbling, or whatever. PQ> > * Graceful non-crashing behavior when thread resources of one kind or PQ> > another are exceeded. PQ> I don't believe there is a 'graceful' way to handle Out-Of-Memory PQ> conditions. Suggestions are welcome. Well, I don't understand something then. The OOM was not out of box memory: it was some other resource limit. Max number of threads per child? stack space? something else? The errors happened on apr_thread_create then there was still plenty of memory available on the box. Should apache start up when the config implies it is possible to create more threads than there is (whatever resource is being consumed)? If you unexpectedly can't start a new thread, the server should drop the request, not segv .. just my opinion though. I'd test more of this but the existing flood tools cannot generate this kind of DDOS and unfortunately it has gone away after we found and killed the control machine for the zombie army! -Justin
