Apache HTTP DoS tool released
isc.sans.org
isc.sans.org
In response, you block/throttle origin IPs, and decrease timeouts so zombie connections are dropped more quickly, and increase the capacity to serve or shake-off troublesome connections without locking out legitimate traffic. An inbound reverse proxy, as joshu suggests, often makes this easier -- and keeps such enforcement cruft from complicating the primary server.
* The idea is to trick the web server into keeping a connection open and waiting for data, e.g. by keeping on sending pointless headers, not sending enough (< content-length bytes of) data in the body, etc. Unlike a SYN flood or so, this doesn't require much traffic from the attacker.
* The reason this works is that apache has a limit of one thread or process per active connection, and there is typically an upper bound on
* The way to fix this once and for all in apache et al would be to handle socket I/O asynchronously, thus lifting the 1:1 ratio of connections to threads/processes.
Is that accurate? I'm mostly curious so that I can try to avoid any such pitfalls in any server software I might write.
One way to fix this in apache without breaking too many existing modules and extensions might be to use fibers to hide the asynchronicity and schedule them in the "blocking" I/O functions which would actually use non-blocking I/O underneath. (I don't actually know the apache architecture, so I might be wrong about the blocking I/O)
If you start a thread for each connection, you're doing it wrong.
So you just use iptables connlimit match block the clients with more than e.g. 10 connections.
This attack is based on the idea the attacker commands more resources than the target server. It doesn't fly very well.
1. No, it's not the simplest approach. The attacker can trivially send perfectly credible set of headers, then start receiving the response, acknowledging 1 byte per 30 minutes. It's routinely seen in the wild, too. Header-based approach completely misses the point of anomaly.
2. Blocking originating IPs is perfectly effective as soon as all existing connections from the blocked IPs time out. Which is fairly soon.
3. connlimit approach doesn't just block originating IPs, it prevents anyone from opening a lot of connections.
4. In any real DDOS scenario attacker does command an order of magnitude more resources than the target servers.
[edit: formatting]
2. I am not sure I got what you say. In a real DDoS attack, there should be a lot of different IP addresses and blocking thousands of them (many of whom would reset connection and come back with a different IP) would make the life of the firewall very uncomfortable.
3. I know this has problems with proxies and firewalls with large number of computers behind them. I don't remember proposing this idea.
4. It all depends on what is being attacked and how. I don't think any serious DDoS attacker would use this approach.
2. I just tell you what works in real life. Blocking 500 supernodes (out of 5000 machines botnet) is basically a non-issue for linux iptables on usual modern processes. Other 4500 are usually pretty tame in terms of firewall processing power.
3. You didn't propose that, it's what we do (and what works best for these attacks). Its rate of false positives is sufficiently low. Folks behind NATs don't use sustained 4 connections per user, so it's usually a non-issue either.
4. Well, you're wrong if you don't think so. Mitigating DDOS-es is one of the things i do for living [i'm in charge of web infrastructure of certain political opposition websites in Russia, if it rings any bells]. The scenarios i described is what actually happens.
About 4, are the DDoS aimed at your servers or at your office infrastructure?
Their DDOS attacks target our servers. For example, Russia has some issues with Estonia, opposition sites post some independent statements and news on that. Then comes DDOS.
It's called "delayed ack" or something. Iirc, it's all described in rfc793.