As someone who does not work in hosting, I am somewhat surprised that "upstream bandwidth providers" don't have mediation strategies for DDoS attacks. It is my understanding that most of the asshats out there aren't sitting on Stuxnet: they have well under a hundred machines that they are able to flood traffic at you with (which is certainly more than enough). It seems like there are network-level mechanisms you can use to just block such an attack at the ingress connections. Is anyone willing to explain more about the issues here? (I, at least, would find it fascinating.)
Dropping UDP is a start, because most of these attacks randomize the UDP source address. The real problem is AS operators who let forged UDP addresses escape their network. If your outgoing edge ACL is not dropping source addresses that do not belong to you, you are doing it wrong. Period. Full stop.
If the packets are random UDP sources, then there's not really much you can do on the receiving end except strategies that involve the destination address. There's really only one effective one: nulling it.
Okay, but then why null route the entire machine, as opposed to dropping just the UDP packets going towards it? If you already have routing infrastructure that can disseminate "attempts to access this IP address will fail" it does not seem a stretch to disseminate "attempts to access this IP address over UDP will fail; over TCP there is no issue". Are "upstream bandwidth providers" really that impotent against that kind of issue? :(
I, personally, have absolutely no need to have incoming UDP packets of any kind at all entering my network, and can not come up with a reason why any web hosting company would: it seems like it should almost be a question on your bandwidth contract "will you need UDP (recommendation: no)". (Given the simplicity of the UDP problem, I personally assumed that the complexity would come from state-ful TCP filtering issues.)
The issue with dropping UDP is that DNS uses UDP in most implementations. Unless you have no need for DNS on your network, you might want UDP packets to be not dropped completely.
Ah, that a web host might want to host their own DNS in house (maybe for ease or cost) is not something I considered (I outsource DNS as it is sufficiently performance sensitive you really want to AnyCast it against numerous networks, and there are people that specialize in that). As a client you can just use TCP for DNS. (Again: I am not a host ;P. Thanks!)
That's what most providers (certainly the one I've worked at) do, in fact, do, is null route the entire machine. Rather than leave you nulled in the router for weeks waiting for the attack to subside, eventually, they'll just cut you loose. That's the typical form these things take.
It would be tempting to blackhole UDP, but it's just as easy to flood a pipe with TCP. You don't need an established connection to get packets in the pipe, and there are many mismanaged networks on planet Earth (as I alluded to) that let just about anything exit. A small botnet of five or ten machines with gigabit uplinks on poorly-managed networks is enough to be a force to reckon with. When I was an administrator on IRC, Cisco routers themselves were common targets to exploit and use for this purpose; often, they're directly plugged into gigabit or even ten gigabit connectivity, and there are really easy ways in IOS to perform a DoS attack.
I can't speak to the decision Pastie's host made in this case, but it sounds like since Rails Machine was donating resources (and Pastie wasn't paying them), Rails Machine must act as a smart company -- certainly, any entrepreneur who enjoys Hacker News would sympathize -- and protect its income flow. Which means, you mess with my customers, I fire you.
"You mess with my customers"? So, pastie.org was asking for it by hosting a free-form data pasting site? Again, this is you acting like pastie.org is the one at fault and is responsible for a bunch of idiots deciding to saturate the line.
It seems as though you're skewing the issue here. And I think the real issue has nothing to do with whether pastie.org was a paying customer. I'd be interested to know if RM would do the same thing if there was no sponsorship arrangement and it was paying regular bills. My hypothesis is they'd throw them under that same bus -- and that's really what this comes down to. It's hard to be sympathetic with a company that gives up on its customers (paying or not) after "9 hours". Given that they had been hosted for 3 years prior, a night of DDoSing seems like a really isolated incident, and no reason to drop them permanently. Of course, we don't know if there were other DDoSes, but given that wrecked was so eager to share the piracy concerns and didn't mention any other DDoSes, I don't think there are any.
Imagine for a moment that your million-dollar app on Amazon goes down. You file a ticket. They are currently absorbing a DoS attack, but they can't tell you that due to their privacy policy with the victim. So instead they tell you they are looking into it and it appears to be some kind of network issue.
Nine hours pass. You get frustrated. You take to Twitter. Anybody else on Amazon down? you ask. You get several people to confirm that they are. You tweet that it's an Amazon issue from your company Twitter. You start Googling alternatives. You write a blog post, months later, about how incompetent Amazon must be and you're so glad that you moved your million-dollar app to Rackspace Cloud. You make the front page of Hacker News. Hundreds follow you. Amazon gains a reputation for unreliability among those that read HN. Sales start decreasing.
Or, they null the customer and none of this happens.
