| |||||||||||||
Apache attacked by a "slow loris"Apache attacked by a "slow loris"Posted Jun 25, 2009 4:29 UTC (Thu) by quotemstr (subscriber, #45331)In reply to: Apache attacked by a "slow loris" by michaeljt Parent article: Apache attacked by a "slow loris" So you're talking about having Apache implement TCP in userspace? That makes no technical sense whatsoever. The kernel implementation is thoroughly debugged, mature, patched regularly, and faster to boot. Apache will have to maintain just as much state as it does today, and moving TCP to userspace solves nothing. A "socket" is just a handle to a tiny bit of state information describing the connection, and of course it's the right abstraction. It's what the protocol is specified to use, and in-order, streamed delivery is the perfect medium for HTTP anyway. The real problem here is what Apache does after it reads data from a socket. Recall that both lighttpd and IIS use sockets (just like every other network daemon on Earth), and they are not vulnerable to this attack. The counter to this attack is simple, really, and it's conceptually the same as a counter to a SYN flood: only commit your resources when the remote party has committed his own. The problem here is how to shoehorn that idea into Apache's model, which commits resources (in this case, processes) very early.
Here's one uninformed idea: accept connections and read HTTP requests in one master process, asynchronously. Only when a complete request has been read send the file descriptor of the connection to a worker; the actual handoff can be achieved using a
(Log in to post comments)
Apache attacked by a "slow loris" Posted Jun 27, 2009 15:06 UTC (Sat) by dmag (subscriber, #17775) [Link]
> So you're talking about having Apache implement TCP in userspace?
No, having a generic library for TCP in user space.
> That makes no technical sense whatsoever.
Please read the linked article. http://lwn.net/Articles/169961/
> The kernel implementation is thoroughly debugged, mature, patched regularly,
Agreed.
> and faster to boot.
No. Right now, the driver gets the packet, later the kernel gets around to looking at it (maybe doing checksums, etc), and then much later userspace requests it. If each of these happen on a different CPU, you will waste thousands (ten thousands?) of instructions because of CPU caches and data locking issues.
To become a better programmer, read this: http://lwn.net/Articles/250967/
> The real problem here is what Apache does after it reads data from a socket.
Agreed. TCP sockets is icing on the cake once you've solved the current bottleneck.
> Here's one uninformed idea: accept connections and read HTTP requests in one master process, asynchronously.
But why does that process *have* to be Apache? Just put another web server in front of it (Nginx,Varnish, etc.). Apaches is really a "big and expensive" single-threaded application server (mod_php, mod_passenger, mod_perl, etc). In fact, Apache isn't especially good at serving static files either. I have to admit, Nginx has the best architecture, (but consider Varnish if caching is a big win).
It's like when you go to the big warehouse stores, and before you get to the front of the line, some guy with a scanner has already scanned your cart, and all you do is pay at the register without waiting.
|
|||||||||||||