The Twelve Days of Crisis – A Retrospective on Linode’s Holiday DDoS Attacks
blog.linode.com
blog.linode.com
I really wish people would start taking DDoS more seriously. It's really not something we can just null route servers for anymore. It's becoming a very serious problem. It's not going away, it's amplifying and getting far worse.
I'm also not sure how effective it would be, but it would be nice to see the FBI, NSA or whomever spend at least as much time fighting these DDoS warlords as they did persecuting whistleblowers and trying to shove backdoors into cryptography.
Don't buy CloudFlare for just DDoS protection, their pricing and products are far from competitive.
OVH for example
https://www.ovh.com/us/news/articles/a1171.protection-anti-d...
I used OVH in the past and they rely on TCP resets/disconnects for large syn floods, making your servers pretty much unusable while being attacked.
I found it better to hide the server behind Sucuri or Incapsula if you are worried about ddos.
IMO there should be significant penalties for network operators who do not drop obviously I forged traffic. How long has that rfc been around now and how little adoption has it seen?
The importance of spoofed traffic to attackers is greatly exaggerated, I could personally easily send 500+ Gbit (probably terabit) sized attacks by spending a couple of weeks building a router botnet. No need to spoof IPs and at that point diminishing returns would make amplification attacks useless. Not only that, but most amplified attacks are particularly inexpensive to filter.
>IMO there should be significant penalties for network operators who do not drop obviously I forged traffic. How long has that rfc been around now and how little adoption has it seen?
Who would penalize them? Why?
And I'm not entirely sure if you understand what RFCs are, that RFC (which hasn't even been around for very long) is - most other RFCs - completely meaningless.
Getting rid of UDP amplification reflection attacks will get rid of 90% of volumetric attacks.
And you simply cannot solve IP spoofing without rebuilding the entire internet, not to mention the fact that it does have legitimate use cases.
Also, if IP spoofing is making filtering difficult for you then you're doing filtering wrong.
Botnets have far surpassed amplification attacks at this point.
>This is why filtering is desirable.
Come up with a way to implement it that actually works and doesn't break legitimate use cases. spamsolutions.txt is starting to seem relevant here.
>they are leading mitigation provider to the banks and schools
:)
https://sucuri.net/website-firewall/
Both a lot cheaper and do a great job protecting against ddos.
http://i.imgur.com/NUnQqlS.jpg
My site was DDoS'd for 2 Gbps, according to Incapsula's charts. Incapsula demanded me sign up for a $15.6k annual contract.
Cloudflare got back to me in 15 minutes and told me they will gladly host me on their $20/mo plan, which includes 'light DDoS protection'. 2 Gbps is light for cloudflare.
Also, for the love of god don't use sucuri. They've had a plenty of opportunities to fully ditch linode but apparently still haven't.
Fundamentally, layer 3/4 are usually amplification. Those are still effective, and very efficient for the attacker, but they will someday (5y? 10y?) be blocked by closing up sources amplification. Address spoofing address at layer 3/4 might get addressed by BCP 38, Vixie's good fight, etc., but not holding my breath.
By the time all that happens, attackers will have moved on to layer 7 attacks. Those can target the weakest parts of your stack, and with a large botnet, even the act of blocking the IPs in the wrong place can add enough overhead to hurt. With a huge botnet of hijacked browsers, blocking everyone affected becomes a DoS vector in itself, since some of those are your own legitimate attacks.
The big problem for DDoS mitigation is that this requires much deeper knowledge of the protected application. It's hard to just put a box inline, or an unmodified cloud service, and have it block the attacks. There's both good science and great engineering to be done, by developers, platform vendors, and specialty anti-DDoS providers, to block this emerging kind of attack.
Maybe 10 years ago.
>Fundamentally, layer 3/4 are usually amplification. Those are still effective, and very efficient for the attacker, but they will someday (5y? 10y?) be blocked by closing up sources amplification. Address spoofing address at layer 3/4 might get addressed by BCP 38, Vixie's good fight, etc., but not holding my breath.
Sending "raw" UDP floods from bots still has several benefits over amplification attacks provided you can amass enough bandwidth, which isn't that difficult these days.
>By the time all that happens, attackers will have moved on to layer 7 attacks. Those can target the weakest parts of your stack, and with a large botnet, even the act of blocking the IPs in the wrong place can add enough overhead to hurt. With a huge botnet of hijacked browsers, blocking everyone affected becomes a DoS vector in itself, since some of those are your own legitimate attacks.
Unlikely, it'll take a fundamental change on how networks work for network layer attacks to become irrelevant. Especially considering volumetric attacks have the added benefit of potentially getting your target kicked off by their hosts and causing added damage in BW bills. And as internet connections become faster, DDoS attacks become bigger.
If you did a watering hole attack, doing JS injection on a really popular "show HN" post on HN, against HN, you'd be effective in getting HN to block the IPs of a large percentage of real users, which would hurt, even if HN could repel the attack entirely. Blocking 50k random botnet IPs wouldn't really affect many regular HN readers.
But the "great cannon attack" was absolutely minuscule compared to the stuff that happens every day, attacks of similar sizes were already reasonably common years ago (See: http://i.imgur.com/0quYBdV.png a graph of an attack on reddit, from 2013).
Today we're talking about Mrps, not Krps.
>If you did a watering hole attack, doing JS injection on a really popular "show HN" post on HN, against HN, you'd be effective in getting HN to block the IPs of a large percentage of real users, which would hurt, even if HN could repel the attack entirely. Blocking 50k random botnet IPs wouldn't really affect many regular HN readers.
That'd just be sloppy filtering, there's no need to drop L7 attacks on IP basis.
I'm personally happy with Linode. They have a seriously tough technical issue to deal with —as much working out what's happening as how to stop it— and they seem to be doing a fairly top job at staying afloat. My servers haven't gone down. Any downtime in the last four years has been my fault.
So even if they are targets of some ludicrously powerful botnet, I'd rather stay with them than let the bastards doing this win. The attack isn't hurting my business or my clients and each incident we go through, the lower the chances of it ever being a problem in the future.
On a more serious note, governments keep moaning on about encryption but botnets are still a much greater direct threat to national security.
Even once growth really took off and revenue started making these big shifts in strategy viable, the mindset was still to be lean and scrappy. The minimal capital expenditure strategy had benefits early on and allowed Linode to maintain an incredible margin and support explosive growth, but they were too slow to start thinking like a grown-up company when it started to matter, and it's coming back to bite both on security (with almost zero investment; just enough to pass PCI-DSS) and things like this.
When I heard they bought the Philadelphia building, for example, I was very surprised because that's not the Chris I knew. We lobbied for a Philadelphia office for years. Could be a good sign regarding decision-making culture for the future, but hard to say.
Don't read me as bad blood or anything, as I wish Linode no ill will (I actually hope they can turn this perceived slump around), it's just educational to see the consequences of choices and mindset catch up with a company. I learned a lot about management style while working there and contrasting with subsequent employers.
nope, the only way Linode "pass" now is being below the self-assessment questionnaire threshold. Once they have to move to an actual external audit they are fucked.
I have direct experience with Linode staff breakdowns in communication because of a security problem before the December attacks.
The problem affected many Linode customers and included risks to confidential information such as billing.
The Linode staff communication was terrible. The problem was severe and ended up with Linode on a blacklist of companies that are not suitable for hosting.
I have to agree with tptacek: do not use Linode for anything, and if you do now, make plans to switch to a new provider.
To end on a happy note, I migrated the project to Rackspace, and the Rackspace staff communication is excellent.
I really wonder what that is supposed to mean, Linode has mentioned it multiple times but not elaborated on what sort of an attack this is.
I personally haven't ever head of a "400 bad request"-attack.
Edit: Yeah, I know what Layer 7 floods are :), but I'm pretty sure "400 bad request" floods are something Linode came up with, so that could use some elaboration by them.
OSI Layer 7 would actually refer to all "applications", but the mention of "400 Bad Request" implies specifically web applications were affected.
My guess is strategies like this but it isn't clear. [e.g. Requests designed to slow/increase the processing per-request to create a log jam at the web application level ]
A request like that would never hit the web application as the server wouldn't know what to do with it.
see:
echo ":P"|nc linode.com 80
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>Just flooding someone with ":P" shouldn't take them down.
For instance, if they had a web service to reboot a server that takes a numerical ID for an argument, but somebody passed in something other than digits – it's valid HTTP, so it would get past the HTTP level and into the application code.
Presumably the attackers found areas that cause very expensive 400 failures for Linode at the application level. If I remember correctly, their web infrastructure is currently legacy Coldfusion and in the process of being rewritten. They might not have the agility/human resources to patch up these kinds of problems quickly, given the ongoing transition.
Please don't use Linode. If you are using it now, make immediate plans to switch. If you have friends who have things built on Linode servers, tell them to switch.
I'm using it right now, works great
Was working fine for few years before this happened.
We've been happy Linode customers for a while now, and definitely prefer Linode to where we were before (Rackspace, via the Slicehost acquisition). I'm not opposed to moving to something like DigitalOcean or other but right now I'm seeing any compelling reason to make a move.
Would it be that much harder to say "Don't use Linode, they have a bad history security-wise and just got hacked again"?
Then there's the whole lying to cover up hacks, not investigating clear compromises when reported by customers and generally just avoiding any kind of negative press at all costs.
Hell, I know some in 2016 that are plain text offenders still.
You get what you pay for, and unless you pay about double what Linode charges...you don't get much in the way of added security or protection.
I do know who you are and I do have respect for your contributions, but my friend, it's seems like you're flaunting a sense of superiority when you issue a drive-by decree. It's only made worse when you choose to take the time you could have spent helping the readers whose opinions you're hoping to sway, and piss it away with grammar/spelling corrections and sarcasm. We routinely call out people in other public forums who give blatant non-answers, don't we?
I thought your comment was helpful. Until you decided that only those who would take it on faith or on fallible googling would be worthy of your help.
I'm not sure if tptacek implied the claim requires substantiation, but IMO naming and shaming is just the ethical thing to do when someone is covering up hacks.
FWIW, I am aware of the past issues Linode has had, and hope they do get their act together.
But in all seriousness, I don't know a single provider that sells cheap VPSs [e.g. At Linode's price point] and actually has something resembling security.
>Yes, but not if you found out such from confidential information you agreed to keep confidential.
Debatable.
Its roughly the same as DO, etc. Yes, its more expensive than buying a dedicated server.
I define anything cheaper than AWS/Google Cloud/Azure/etc. as "cheap". I am assuming you are using a reasonable level of bandwidth [e.g. 100GB+] when making such statements.
Really the only places you can find even cheaper VMs is sites like lowendtalk.com and you really don't want to go that cheap if you can avoid it.
> Debatable
Let me put it this way, "contractually obligated to".
Anyway, if anyone is going to make a blanket statement like "Don't use X", there's no harm in providing at least a high level explanation of why you're saying that. One shouldn't assume other people keep up with the exact same news that they do.
I do agree that some level of explanation would definitely be useful, but this comes up so often that I really don't find it surprising that people are too lazy to explain such statements.
There are times I am comfortable broadcasting clear, direct advice that might hurt some entity's feelings.
There aren't many times when I am comfortable doing both at the same time.
> Linode has had enough security issues that I wouldn't trust them with my servers.
All told, it took a few minutes one evening.
Feel how dickish this sounds without giving any reason whatsoever?
Please explain why.
Saying that would make you a dick.
The linode comment doesn't make tptacek a dick.
Why?
Because it's trivial to figure out why he's saying that by simply typing "linode" into google, but as of right now googling starfighter doesn't immediately bring up any reasons to avoid them.
Edit: Didn't mean to imply that parent was a dick.
If he argumented the reasons before he could had just put a link. Sincerely, it's too much to ask?
(2) I'm comfortable with the fact that my suggestion sounded "dickish" to you, whatever that means. It is meant seriously, though.
At this point, I am bored of people asking for citations on hacker news for things that are should be part of our tribal knowledge.
https://www.google.com/search?q=linode+hacks&ie=utf-8&oe=utf... About 2,810 results (0.34 seconds)
I definitely agree that there is a huge amount of that type of thinking on HN (of course), reading the amount of people who used github but didnt know the different between it and git and were commenting today was a personal education.
Of course, you can judge it differently, but following that link convinced me that the claims are probably not "baseless smearing", that it's a well-intentioned advice. Just from the link itself I wouldn't know on what grounds tptacek came to his conclusion, and I wouldn't heed his advice without further research, BUT I'm 99% sure that if I researched I'd find many well-documented arguments in favour of tptacek opinion/advice. I'd even bet on this: you say it's baseless, I say I can easily find the reasoning and arguments behind what tptacek said. Want to bet?
Oh, by the way:
> Sincerely, it's too much to ask?
Let's turn it around: a person with a lot of experience offers an advice on the matter he's experienced with. Is it too much to ask the readers to first, at least, google a bit before commenting? Why do you think you are entitled to receive even more of that person's attention and time?
If you can't even manage one small teensy link, what respect does that show for your audience?
The only value comes from the ptacek brand, and the trust I have in him through context. But that's generally not a strong foundation to build an argument on.
To be clear: I trust him, but it's not his best post. And op was not out of line for speaking up.
Edit: sorry ryanlol I didnt mean you, but tptacek. It was perhaps too strongly worded. Didn't mean to attack anyone, just wanted to show support for yomism's point.
I consider myself a HN regular, but I dont read everything. Linode posts I subconsciously skip, as they don't interest me. This was honestly news to me. "Incomplete information", I believe that's called ;)
(2) Nobody is entitled to detailed comments from anyone on HN, and keeping comments terse simply isn't disrespectful.
I appreciate that it is annoying to have to make decisions with incomplete information, but that's life.
http://www.urbandictionary.com/define.php?term=dickish
I have read the horror stories thanks to ryanlol's posts but next time please post a link if you don't want to waste time re-explaining. Let's use the HTML powers!
There's links elsewhere on this thread and Linodes security fuckups are a recurring subject of discussion on HN
This doesn't mean anything. I could get horror stories about any cloud service provider via Google yet we're only being told not to use Linode. Providing some context makes all the difference.
Anyway, personally, I choose to still stick to Linode because their customer support is extraordinarily good. I'm speaking about my experiences in the last 5 years.
Concerning their handling of ddos attacks - I think with this changes made things should be much better.
I think you should ask HD and Fyodor again what they think about Linode in 2016.
I really think that if it was some other VPS, they could not have done much better. You remember the outages that Amazon had? It's just a matter of fact the way I see it, these attacks happen. We learn from it, resilience is built. Until a new type of attack takes place, and then the process repeats. I understand that uptime can't be 100% all the time -- the 1 or 2 days it was down in 2015 was an inconvenience, but not totally unacceptable. I also understand that if you're against very determined attackers, it's pretty tough. How will any of the other VPSs fare when the attacker happens to have an 0day or something?
By the way, I noticed a few years ago that bitcoin-related startups were likely to use Linode. That makes linode a huuuuuuge target. I really don't think that if it was some other VPS in the crosshairs, these determined attackers could have been stopped 3 or 4 years ago with the ferocity and resourcefulness they seemed to be equipped with.
You know what makes it even tougher? Using COLDFUSION in 2016.
Please don't say AWS, I have no interest in learning that overcomplicated mess.
Every company around that price point has these problems [and if they don't, they are either burning VC money or lying].
They mention segregating their customers into separate /24s, and consequently having to assign an IP from every one of these subnets to the router for use by the customer as a gateway.
Is there any reason why they couldn't get rid of these by having customers set up a static route to the "primary" IP of the router (migration / configuration issues aside)?
For example, if I have IP 192.168.0.2/24 assigned to eth0, my routing table will have:
192.168.0.2/24 dev eth0 proto static scope link
I'm free to add a local route to a device outside 192.168.0.2/24 though: 192.168.10.1 dev eth0 proto static scope link
This just indicates that I should be able to resolve the MAC address associated with 192.168.10.1 through an ARP query,
same as other devices on my subnet.Not sure why you'd choose a budget provider for production infra anyway.
This, don't do it, far better to not get DDoSd ;-)
How? I thought CloudFlare only protected HTTP? Can you have it reverse proxy a DNS server or is Linode using CloudFlare as the host for ns1.linode.com now?
(email me if you want more info; it's not really ideal for small sites, it's better to just use cf for hosted DNS then, since it's free, but we're happy to do vDNS for people who can't do hosted. Mainly providers, but also some enterprise customers with special DNS needs. It's a pretty cool technology.)
Care to elaborate why it took them so long to ack? And name them so I know who to avoid in the future (or route around)!
Is it really $100bn+ ? If so we could do with some government funded research / countermeasures.
There is something very ironic about this. They have a policy which instead of addressing the problem actively assists anyone wanting to attack their customers. No surprise that these customers have been complaining about this practice for a long time. But until now it was Somebody Else's Problem so they didn't bother figuring out some proper (or at least less terrible) solution. Now this lack of preparedness bit them in the ass...
Contrary to popular opinion, if you're getting DoS attacked, you're either (a) popular enough to start thinking about adult-size pants for your transit strategy or (b) inviting the attention by your choice of content or activities. In years of hosting, I started to know the targets of DoS attacks by name. You have to own at least a little bit of responsibility, and mitigate on your own end if you're going to be inviting that kind of attention; IRC and controversial blogs are the usual suspects here, but that's probably changed recently as I've been out of the hosting game for a while.
Linode has few options for reacting other than the one they use. I know that sucks, but it's how it is.
> why should a network you're paying $20-$100 do everything they can to keep a target online and threaten other customers?
I am not a network engineer and I know that this is a very difficult problem. But when the provider doesn't even _seem_ to try, it only encourages further attacks.
(email me if you'd like more detail; you seem smart/interesting but don't have email in your hn profile)
Can do it with peering with CloudFlare directly, or even if that is not possible MPLS on the backend to direct the traffic to where it needs to go.