3 ms·

This is not as dangerous as the authors make it sound like. Just limit the maximum connections per IP (e.g. via mod_evasive in Lighty or firewall like iptables)

by eis 16y ago

This is not as dangerous as the authors make it sound like. Just limit the maximum connections per IP (e.g. via mod_evasive in Lighty or firewall like iptables) and voila - attack voided. This is very similar to what Slowloris does but Slowloris is much more intelligent because it slows the connection down before it all request headers are sent and therefor many modules will not execute their limit checks just yet. "What’s special about this denial of service attack is that it’s very hard to fix" "Therefore, to properly fix it would mean to break the protocol" Not at all as outlined above. From the paper: "In HTTP/1.1 where chunked encoding is supported and there is no “Content-Length” HTTP header, the lethality is amplified." No, it changes exactly nothing regarding this attack. Why would it? I do not know why these guys make such a fuss about something so trivial and obvious to anyone dealing with HTTP servers. But sadly this is quite common in the security industry.

dangrossman 16y ago
All they need is a botnet of at least 256 computers, which can be rented for a small fee off any number of shady forums. Now what are you going to do? A much better solution is to put a proxy in front that can hold lots of connections very cheaply. nginx and other evented servers can hold 10,000 trickling connections without using significant resources.
- eis 16y ago
  If you have a botnet attacking you, then it's a whole different story anyways. Those can get your services down easily regardless of what attack they use or what protocol is in play (HTTP,FTP,SMTP, you name it) so the botnet argument does not really hold here. A proxy in front does not help if it does not limit per IP connections as an attacker can just use up all filedescriptors or connection slots. It just ups the ante a bit but not much. 10k connections can very easily be created from any DSL/cable connection let alone a server in a datacenter.
  - btilly 16y ago
    For most websites, sure. But the big boys have to deal with botnets all the time, and (mostly) manage to remain up. They need to figure this sort of thing out.
    - eis 16y ago
      It still is not specific to this attack.
      - btilly 16y ago
        Their problem is still not specific to this attack. But they need to figure out how to handle every kind of attack that will come, including this one.
jws 16y ago
They do mention botnets deploying the attack, the "connections per IP" filtering will not help there. I agree the chunked encoding statement makes no sense, nor does the "break the protocol" statement. Some rough calculations (a simpler attack, with this timeout byte trickling isn't required): Given: 200 bytes of header/transport can get a POST started and down to its content. Given: A legitimate customer on a shabby, long latency link might take 5 seconds to get his POST request and data sent. Compute: With a 5 second timeout, a bad person can hold a resource for 40 bytes/second of bandwidth. Compute: 256[1] resource limit takes only 80kbps. Compute: 20000 resource limit takes 6Mbps. Still, you are right, the sky isn't falling: • identify and throttle bad actors • throttle single IPs (be careful about your giant corporate customer that NATs everyone) • reduce the cost of the resource. Don't start a process until you have all the POST data. I would leave the data in the kernel until I had all the POST data or a lot of data (MSG_PEEK is your friend. 'real' requests will all come in the first datagram anyway) (Yes, kernel memory is special, but I sure don't want these attackers to cause swapping, so bytes are bytes and a billion of them are cheap.) Ultimately the TCP connection count will be the expensive resource. Google your way past the 64k limit. • data tricklers are probably easy to see if you are watching the size of your read()s. • crazy over the top solution: use a separate IP address on a virtual mac address in your linux box without a kernel IP stack on it. Do your own TCP blending the TCP state machine with your own HTTP request decoding state machine. (Actually, if you have slots, maybe just use another physical controller, it will be faster and you won't shoot your own leg off by accidentally engaging the kernel TCP stack. When you see a spurious RST in response to a SYN, look for that leg.) EOM [1] random self discovery of the day: I consider 256 to be one significant digit.

by eis 16y ago

dangrossman 16y ago

All they need is a botnet of at least 256 computers, which can be rented for a small fee off any number of shady forums. Now what are you going to do? A much better solution is to put a proxy in front that can hold lots of connections very cheaply. nginx and other evented servers can hold 10,000 trickling connections without using significant resources.

eis 16y ago
If you have a botnet attacking you, then it's a whole different story anyways. Those can get your services down easily regardless of what attack they use or what protocol is in play (HTTP,FTP,SMTP, you name it) so the botnet argument does not really hold here. A proxy in front does not help if it does not limit per IP connections as an attacker can just use up all filedescriptors or connection slots. It just ups the ante a bit but not much. 10k connections can very easily be created from any DSL/cable connection let alone a server in a datacenter.
- btilly 16y ago
  For most websites, sure. But the big boys have to deal with botnets all the time, and (mostly) manage to remain up. They need to figure this sort of thing out.
  - eis 16y ago
    It still is not specific to this attack.
    - btilly 16y ago
      Their problem is still not specific to this attack. But they need to figure out how to handle every kind of attack that will come, including this one.

jws 16y ago

They do mention botnets deploying the attack, the "connections per IP" filtering will not help there. I agree the chunked encoding statement makes no sense, nor does the "break the protocol" statement. Some rough calculations (a simpler attack, with this timeout byte trickling isn't required): Given: 200 bytes of header/transport can get a POST started and down to its content. Given: A legitimate customer on a shabby, long latency link might take 5 seconds to get his POST request and data sent. Compute: With a 5 second timeout, a bad person can hold a resource for 40 bytes/second of bandwidth. Compute: 256[1] resource limit takes only 80kbps. Compute: 20000 resource limit takes 6Mbps. Still, you are right, the sky isn't falling: • identify and throttle bad actors • throttle single IPs (be careful about your giant corporate customer that NATs everyone) • reduce the cost of the resource. Don't start a process until you have all the POST data. I would leave the data in the kernel until I had all the POST data or a lot of data (MSG_PEEK is your friend. 'real' requests will all come in the first datagram anyway) (Yes, kernel memory is special, but I sure don't want these attackers to cause swapping, so bytes are bytes and a billion of them are cheap.) Ultimately the TCP connection count will be the expensive resource. Google your way past the 64k limit. • data tricklers are probably easy to see if you are watching the size of your read()s. • crazy over the top solution: use a separate IP address on a virtual mac address in your linux box without a kernel IP stack on it. Do your own TCP blending the TCP state machine with your own HTTP request decoding state machine. (Actually, if you have slots, maybe just use another physical controller, it will be faster and you won't shoot your own leg off by accidentally engaging the kernel TCP stack. When you see a spurious RST in response to a SYN, look for that leg.) EOM [1] random self discovery of the day: I consider 256 to be one significant digit.