Ask HN: Who is responsible for fending off DoS attacks?
3 comments
That depends on the scope and size of the attack.
If the attack is small, which the vast majority of attacks are, (either in bandwidth, packets per second, or both) then the responsibility is on the dedicated server owner to fix it via a software fix. (iptables with perl scripts to ban offending ips, etc..). If you have a managed host, they will obviously help with that.
If the attack is larger than that, but still not epic (say, 2gbps attack) then the responsibility is on the host/datacenter, who will most likely null route your server. What that means, is they will tell their upstream providers not to send any more traffic to your IP address and NOBODY will be able to access your site. This is done until the attack ends. If they dont null route your server, they will attempt to filter the traffic coming in themselves through a in house solution.
If the attack is of epic scale, it becomes less of a issue for the datacenter you are hosted in and more of a issue for the upstream providers to filter it on their end. A average datacenter can only do so much when 50gbps is coming in when they normally only see 10.
If the attack is small, which the vast majority of attacks are, (either in bandwidth, packets per second, or both) then the responsibility is on the dedicated server owner to fix it via a software fix. (iptables with perl scripts to ban offending ips, etc..). If you have a managed host, they will obviously help with that.
If the attack is larger than that, but still not epic (say, 2gbps attack) then the responsibility is on the host/datacenter, who will most likely null route your server. What that means, is they will tell their upstream providers not to send any more traffic to your IP address and NOBODY will be able to access your site. This is done until the attack ends. If they dont null route your server, they will attempt to filter the traffic coming in themselves through a in house solution.
If the attack is of epic scale, it becomes less of a issue for the datacenter you are hosted in and more of a issue for the upstream providers to filter it on their end. A average datacenter can only do so much when 50gbps is coming in when they normally only see 10.
the hosting company is the only one /able/ to respond, (well, depending on the attack type. the nastier attack types fill your pipe and/or overwhelm your router's pps capacity... your upstream is the only one who /can/ address that.)
however, standard practice in the hosting industry is to disconnect the target, temporarily or permanently.
the thing is, cleaning up this shit gets expensive fast. And there is plenty of 'splash damage' to your fellow customers.
I was taken out a few months back by a DDos. Fourteen thousand dollars in SLA credits I paid out. The customer? was paying me one hundred fifty a month, and this was the second time he got hit with a major attack. I asked him to leave or help me pay for the damage. Obviously, he picked the former option.
but yeah. my upstreams wanted me to get rid of the guy after the first attack. 'finishing the job' really is standard practice, if the attack is sufficiently large.
Personally, I think this fact is one of the reasons why the problem isn't going away. Service providers, the only people who /can/ do anything about it, well, they can spend a whole lot of time and effort tracking down the source (being as most DDos traffic is spoofed, this is quite difficult) or alternately, we can just take the target offline.
the economics of the situation are all wrong... but I don't know how to fix it.
however, standard practice in the hosting industry is to disconnect the target, temporarily or permanently.
the thing is, cleaning up this shit gets expensive fast. And there is plenty of 'splash damage' to your fellow customers.
I was taken out a few months back by a DDos. Fourteen thousand dollars in SLA credits I paid out. The customer? was paying me one hundred fifty a month, and this was the second time he got hit with a major attack. I asked him to leave or help me pay for the damage. Obviously, he picked the former option.
but yeah. my upstreams wanted me to get rid of the guy after the first attack. 'finishing the job' really is standard practice, if the attack is sufficiently large.
Personally, I think this fact is one of the reasons why the problem isn't going away. Service providers, the only people who /can/ do anything about it, well, they can spend a whole lot of time and effort tracking down the source (being as most DDos traffic is spoofed, this is quite difficult) or alternately, we can just take the target offline.
the economics of the situation are all wrong... but I don't know how to fix it.
It has to be a combined effort. The hosting company is like the fire department - when your house is on fire they come through with axes and hoses because their focus is saving lives, not property. When your site is being attacked, the hosting company focuses on stopping the attack, but you'll end up fixing a lot of security holes and patching code afterwards.
For example, when I worked at Internet Brands, when several of our sites were attacked last year, our hosting company installed a Palo Alto firewall in front of our load balancer. It stopped the attacks overnight, but some sites became unbearably slow or unresponsive. It turns out that it was blocking some legitimate traffic (e.g. requests for RSS feeds for vBulletin forums, curl API requests). We had to go through hundreds of sites to look for things like this to patch.
For example, when I worked at Internet Brands, when several of our sites were attacked last year, our hosting company installed a Palo Alto firewall in front of our load balancer. It stopped the attacks overnight, but some sites became unbearably slow or unresponsive. It turns out that it was blocking some legitimate traffic (e.g. requests for RSS feeds for vBulletin forums, curl API requests). We had to go through hundreds of sites to look for things like this to patch.
In a situation like this, who is responsible for fixing/addressing/getting sites back up? I'd imagine it would be the host but I'm curious as to the work done by Posterous.