Apache HTTP DoS tool released • Hacker News Board

Re: Apache HTTP DoS tool released

#21

Post by rbanffy » Sat, Jun 20, 2009, 11:44 AM UTC

jsn wrote: post #19

Locke1689 wrote: post #17

Earlier quoted context omitted.

It's also not that difficult to counter. The easiest way is to just do packet inspection - if something looks wrong (repeated bad/incomplete headers), just blacklist the IP for however many minutes. Repeat ad nauseam. Any IDS worth its salt shouldn't even hiccup at this.

It's trivial to counter indeed; you don't need any packet inspection for that. The main anomaly is not in the header structure, it's in the number of sessions opened simultaneously by one host. This particular tool uses broken headers for some reasons; other ones don't. But they all open sessions excessively. So you just use iptables connlimit match block the clients with more than e.g. 10 connections.

Actually, just blocking originating IPs would not stop a DDoS based on this. The simplest approach would be to timeout the connection if a credible set of headers is not received within a certain time.

This attack is based on the idea the attacker commands more resources than the target server. It doesn't fly very well.

Re: Apache HTTP DoS tool released

#22

Post by pibefision » Sat, Jun 20, 2009, 1:36 PM UTC

what if we use NGINX as a reverse proxy in front of apache? could this be a good workaround?

Re: Apache HTTP DoS tool released

#23

Post by jsn » Sat, Jun 20, 2009, 2:10 PM UTC

rbanffy wrote: post #21

jsn wrote: post #19

Earlier quoted context omitted.

It's trivial to counter indeed; you don't need any packet inspection for that. The main anomaly is not in the header structure, it's in the number of sessions opened simultaneously by one host. This particular tool uses broken headers for some reasons; other ones don't. But they all open sessions excessively. So you just use iptables connlimit match block the clients with more than e.g. 10 connections.

Actually, just blocking originating IPs would not stop a DDoS based on this. The simplest approach would be to timeout the connection if a credible set of headers is not received within a certain time. This attack is based on the idea the attacker commands more resources than the target server. It doesn't fly very well.

Sorry, most of that is wrong :)

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]

Re: Apache HTTP DoS tool released

#24

Post by rbanffy » Sat, Jun 20, 2009, 2:52 PM UTC

jsn wrote: post #23

rbanffy wrote: post #21

Earlier quoted context omitted.

Actually, just blocking originating IPs would not stop a DDoS based on this. The simplest approach would be to timeout the connection if a credible set of headers is not received within a certain time. This attack is based on the idea the attacker commands more resources than the target server. It doesn't fly very well.

Sorry, most of that is wrong :) 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 ti…

1. I don't think the client can acknowledge one byte per minute - I think the minimum would be one network packet. Anyway, the whole response would timeout. Apache has a config setting for that, does it (I have been using mod_proxy a lot and mod_proxy does timeout)? Perhaps, there should be a minimum bandwidth threshold that forces the connection to abort. I see your point, however. Even sending a real complete header should not prevent the request from being treated as hostile.

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.

Re: Apache HTTP DoS tool released

#25

Post by jsn » Sat, Jun 20, 2009, 3:35 PM UTC

rbanffy wrote: post #24

jsn wrote: post #23

Earlier quoted context omitted.

Sorry, most of that is wrong :) 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 ti…

1. I don't think the client can acknowledge one byte per minute - I think the minimum would be one network packet. Anyway, the whole response would timeout. Apache has a config setting for that, does it (I have been using mod_proxy a lot and mod_proxy does timeout)? Perhaps, there should be a minimum bandwidth threshold that forces the connection to abort. I see your point, however. Even sending a real complete heade…

1. You're wrong, see rfc793. TCP flow control acknowledges streamed bytes, not packets.

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.

Re: Apache HTTP DoS tool released

#26

Post by rbanffy » Sat, Jun 20, 2009, 3:49 PM UTC

jsn wrote: post #25

rbanffy wrote: post #24

Earlier quoted context omitted.

1. I don't think the client can acknowledge one byte per minute - I think the minimum would be one network packet. Anyway, the whole response would timeout. Apache has a config setting for that, does it (I have been using mod_proxy a lot and mod_proxy does timeout)? Perhaps, there should be a minimum bandwidth threshold that forces the connection to abort. I see your point, however. Even sending a real complete heade…

1. You're wrong, see rfc793. TCP flow control acknowledges streamed bytes, not packets. 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…

Interesting. Acknowledging receival on two layers (packets and butes) makes little sense. Wonder why such decision was made.

About 4, are the DDoS aimed at your servers or at your office infrastructure?

Re: Apache HTTP DoS tool released

#27

Post by jsn » Sat, Jun 20, 2009, 4:03 PM UTC

rbanffy wrote: post #26

jsn wrote: post #25

Earlier quoted context omitted.

1. You're wrong, see rfc793. TCP flow control acknowledges streamed bytes, not packets. 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…

Interesting. Acknowledging receival on two layers (packets and butes) makes little sense. Wonder why such decision was made. About 4, are the DDoS aimed at your servers or at your office infrastructure?

They don't acknowledge packets, just bytes. It's pretty reasonable for a reliable streaming protocol.

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.

Re: Apache HTTP DoS tool released

#28

Post by rbanffy » Sat, Jun 20, 2009, 7:37 PM UTC

jsn wrote: post #27

rbanffy wrote: post #26

Earlier quoted context omitted.

Interesting. Acknowledging receival on two layers (packets and butes) makes little sense. Wonder why such decision was made. About 4, are the DDoS aimed at your servers or at your office infrastructure?

They don't acknowledge packets, just bytes. It's pretty reasonable for a reliable streaming protocol. 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.

Still, the overhead is large if it employs single byte confirmations. It turns symmetrical what could be an asymmetrical communication.

Re: Apache HTTP DoS tool released

#29

Post by jsn » Sat, Jun 20, 2009, 7:59 PM UTC

rbanffy wrote: post #28

jsn wrote: post #27

Earlier quoted context omitted.

They don't acknowledge packets, just bytes. It's pretty reasonable for a reliable streaming protocol. 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.

Still, the overhead is large if it employs single byte confirmations. It turns symmetrical what could be an asymmetrical communication.

Sorry, wrong again. Stream byte acks are way more effective than packet ones. Tcp endpoint can receive several packets of data and then send just one very small ack packet (you only have to send the byte stream position after the last received packet). I'm not sure what you mean by "asymmetrical", but that's probably as asymmetrical as it gets.

It's called "delayed ack" or something. Iirc, it's all described in rfc793.

Re: Apache HTTP DoS tool released

#30

Post by e4m » Sat, Jun 20, 2009, 10:00 PM UTC

jsn wrote: post #19

Locke1689 wrote: post #17

Earlier quoted context omitted.

It's also not that difficult to counter. The easiest way is to just do packet inspection - if something looks wrong (repeated bad/incomplete headers), just blacklist the IP for however many minutes. Repeat ad nauseam. Any IDS worth its salt shouldn't even hiccup at this.

It's trivial to counter indeed; you don't need any packet inspection for that. The main anomaly is not in the header structure, it's in the number of sessions opened simultaneously by one host. This particular tool uses broken headers for some reasons; other ones don't. But they all open sessions excessively. So you just use iptables connlimit match block the clients with more than e.g. 10 connections.

Clients? You mean IP. NAT anyone?