The DDoS that almost broke the Internet
blog.cloudflare.com
blog.cloudflare.com
But the key here is the source. And this from the article:
"The attackers were able to generate more than 300Gbps of traffic likely with a network of their own that only had access 1/100th of that amount of traffic themselves."
And this is key, so we could hunt them at their source if there was a way of deducing their launch points (it may be a botnet but it may also just be some random server farm)
I've got log records of the form:
Mar 27 09:19:21 www named[295]: denied recursion for query from [212.199.180.105].61604 for incap-dns-server.anycast-any2.incapsula.us IN
Which suggests that 212.199.180.105 is somehow being used, and according my latest GeoIP database that is an IP address in Tel Aviv. $VAR1 = {
'longitude' => '34.7667',
'city' => 'Tel Aviv',
'latitude' => '32.0667',
'country_code' => 'IL',
'region' => '05',
'isp_org' => 'Golden Lines Cable'
};
So can we create a service where the recurse requests send the IP trying to do the recursion to a service which then inverts the botnet/privatenet? Everytime this level of co-ordination is undertaken it potentially shines a bright light on the part of the Internet that is compromised/bad.Besides closing down open resolvers, the real solution to this particular DDoS lies in the DNS protocol. The attack's practicality comes from RFC 2671. If that were amended to either return the maximum size of a packet to 512 bytes for UDP packets (but allow TCP packets to be any size), there would be no benefit at all to this attack. For existing resolvers this would require either DNS services being upgraded or firewall rules being put in place to limit UDP packets on port 53 to 512 bytes.
Shutting down open resolvers is about as much work, but unfortunately still leaves the attack possible because it's inherent to the protocol.
I personally think that the focus on open recursive resolvers is misplaced. All authoritative nameservers have to be "open" to queries for the domains they serve. So instead of the amplifying by doing: $ host -t any random-site.com. ns1.example.org. you can just as well do: $ host -t any example.org. ns1.example.org. Even if all nameservers supported good per-IP throttling (far from the case), there are still enough valid nameservers on the internet to stage a decent amplification I think. So once all of the open resolvers are shut down, the DDoS pricks will just target more important infrastructure to accomplish the same goal.
It might be that we'll have to switch all authoritative DNS requests to be TCP-only but I can't imagine what a pain that transition will be.
The worse news is that egress filtering has been something we've clearly needed for 15+ years and it doesn't seem we've gotten very far. Part of the problem is that these amplification attacks usually don't cause much pain to the real source of the attack. Plus since it's very hard to tell where the true source is, they don't even get publicly shamed for it. It's so much easier to point a finger at the middle man in this case.
For egress filtering to be effective protection, it needs to cover nearly all of the network. As long as a botnet can get their hands on a decent amount of unfiltered bandwidth to amplify it's game on.
I'm not optimistic.
The question is can it be done without the ISP's co-operation. For example, I've got transit service from XO (a Tier-2 provider) and they could conceivably port-mirror the inbound side from my connection, do a source IP check on packets, (even statistical would be fine) and then raise a flag if anything came out smelly.
Since we're comparing a 32 bit number, and we can construct a logic gate which defines 'legal' values for that number, even a modest FPGA implementation could just sink (equivalent to /dev/null) all traffic and generate a pulse when the match failed. Its been a while since I was in a company building DSLAMs and edge gear but up to a 10Gbit pipe that isn't a killer problem.
Once you move further towards the core, the problem becomes exponentially more complex. Asymmetric routes are common, so it's not weird at all to get a packet handed to you from a different ISP than you would reply to it. Any filtering there would break a large percentage of valid traffic.
The problem is that there are a hell of a lot of "edges", you need nearly all of them to be fixed, and they don't have the motivation to do much about the problem.
The solutions are clear. They happen to be doing the laziest of them which is close the open resolvers.
I've had attacks come from Asia and Russia and none of the hosts respond. I've also tried contacting their upstream providers.
The DNS system needs to be changed.
It needs to change, but I highly doubt it will for at least a few decades. Too many things rely on it, and it would require way too many resources and a miserably long time to change everything to the new thing.
The amplification part of the attack comes from the fact that they aks for zone transfers, and zone transfer replies are much larger than the requests.
If they were just doing normal DNS lookups for records you wouldn't have an amplification factor.
[1] http://blog.cloudflare.com/why-google-went-offline-today-and...
I really can't figure out from their writing whether this is altruism accidentally leading to great PR or phenomenal PR leading to the appearance of altruism.
But your point certainly holds: while there is a category of marketing that utilizes a great product and honest communication, it is not the only way to successfully market. In fact, it may not even be the most effective way to market (though I would argue it is the most effective way with a technical audience).
In contrast, a friend of mine was ordered by his fiance that she would only accept a ring costing thousands of pounds. It didn't work out. Lucky escape in my opinion (especially as she stopped him drinking beer too).
Is this their product [which they charge for and you are championing] the one that can mitigate DDoS attacks but failed to do so?
Cloudflare got caught out offering something they cannot guarantee and failed to deliver - they are now currently blaming the 'Internet' - very sad...sorry it is late but the 'Internet' did not slow down today or almost break [as the title of this post would suggest] because Cloudflare and Spamhaus had a bad day...
> This allowed us to mitigate the attack without it affecting Spamhaus or any of our other customers. The attackers ceased their attack against the Spamhaus website four hours after it started.
Yes I did - and still Cloudflare can claim to be able to defend against these 'attacks'?
If they were being 'honest' they would come out and say they cannot defend themselves against the 'Internet'
Edit: This allowed us to mitigate the attack without it affecting Spamhaus or any of our other customers
So did the Internet slow down or break? Is this news?
"The attacks have already stopped because CloudFlare worked themselves into the middle of an attack and tried to turn it into a PR stunt for themselves which kind of like backfired because CloudFlare couldn’t handle the attack." http://rt.com/news/spamhaus-threat-cyberbunker-ddos-attack-9...
Suck to be CyberBunker though, they got spamhaused and couldn't even retaliate by launching the biggest DDOS attack ever. And they're still getting spamhaused.
Or they could be bought from a botnet for a handful amount of cash. 500 machines, even if it would mean 500 new machines each hour, is still pocket cash. Either the Internet is very weak and will break because of 500 machines, or this attack is not worthy a title of "The DDoS that almost broke the Internet".
To say 300GBs can slow the Internet down and almost break it is laughable, sensationalist FUD and spun by Cloudflare.
Cloudflare have zero control over what comes out of ISPs networks, in the end it was down to the ISPs to mitigate these attacks.
I think it's a little of both, they also have great write ups when they screw up (rare, but it happens).
They also, of course, don't write blog posts for every single incident (as I point out in that previous post), but they do acknowledge incidents on their status pages, and they don't seem to filter their postmortems based on "can I turn this into a PR event" as CloudFlare does; in the example situation I provided that CloudFlare carefully ignored, Amazon would have posted something, even though it only would not have let them come off sounding like heroes.
CloudFlare simply should not be getting happy hacker credit for these exaggerated tales of valor... this is just marketing copy, not a postmortem, and it isn't even clear that we should be believing any of the statements they have made. I mean, can you even imagine an Amazon postmortem requiring a rebuttle by gizmodo, as we see for this CloudFlare article? http://gizmodo.com/5992652
I cannot find a single action mentioned in the entire post of something that CloudFlare actually did to help mitigate the attack. Basically, it seems that the Internet network community at large scrambled to deal with the problems, and CloudFlare is taking credit for it.
This is true - if the Internet network community didn't identify this issue and see how they could mitigate it Cloudflare would have been toast. And now this blog post is number 1 on Hacker News...
What more could they do?
That said it's pretty interesting if you ignore the bits that sound like hype.
I've a smallish home network, 5 machines, one of them running handful of VMs, some devices (printer, scanner).
I wanted to have a local DNS server to name all these things, but mostly to learn about DNS and how to set up Bind.
So i installed bind on a Debian machine, set up a local domain, promptly named .fia.intra. As an added benefit, I now had a local DNS caching server too, and since my machines use this as their primary DNS server, it needs to be recursive and not just respond to queries for my internal fia.intra. network.
Now, all this is running on an internal 192.168.1.0 network, and bind is set up to only respond to queries from 192.168.1.0/24, and I'm behind an ADSL NAT gateway, so noone from outside should be able to query my internal DNS server.
I ignorantly assumed that the ADSL modem wasn't completely broken and having a moronic way of operating.
Now, I've not set a port forwarding rule in the modem that forwards port 53 to my internal DNS server, the only port forwarding rule I have is one for SSH.
However, I have this setting on the ADSL modem: http://i.imgur.com/dlL9LKV.png
The ADSL modem as shipped from the ISP acts as DHCP server on the LAN side, as most modems would do, and by default the DHCP server hands out a DNS server that is my ISPs DNS server. I changed that to my internal DNS server, 192.168.1.20.
In the image you will see the DHCP server isn't even enabled, I moved that to my same Debian machine and turned it off on the ADSL modem, but didn't erase the DNS settings.
As it turns out, because of that setting the ADSL modem listens on port 53 on the WAN interface(which has a routable IP address), and forwards/reverse-NATs queries to my DNS server at 192.168.1.20. I'd never guessed it to do that.
I did a "dig google.com @<my.public.ip>" from an EC2 instance I have, and indeed it responded nicely..
I've now changed the setting to read "Primary DNS Server= 0.0.0.0" and have verified I no longer respond to DNS queries from the WAN side.
Stuff sucks.
Which is bad, because DNSSEC dramatically increases the amplification effect you get from bouncing queries off open resolvers (the DNSSEC RRs are Big).
Adam Langley notes on Twitter that Cloudflare reports 3k DNS responses, apparently containing the zone contents of RIPE.NET; I guess these were EDNS0 UDP AXFR requests? That's worse than DNSSEC.
This has been one of Daniel Bernstein's big critiques of DNSSEC. It's not one of mine, but I'm still happy to see his argument validated.
† (at a tier 1 Cloudflare doesn't have a business relationship with, which makes this kind of a "my cousin's best friend told me" number, but still)
It's like: Do you want to be shot with 50 bullets or 100 bullets. DNSSEC is 100 bullets, regular DNS might be 50 bullets. Either way, you're going to die.
I don't like DNSSEC, but amplification isn't my argument against it. The fact that it doesn't provide encryption, puts keys in the wrong hands, and is bizarrely complex for reasons that don't fit with the model of DNS is why I don't like DNSSEC.
Substitute 'routers' for 'resolvers' to see how this only plays into the hands of those who don't like the openness of the internet.
[1]: http://en.wikipedia.org/wiki/CyberBunker
[2]: http://translate.google.com/translate?sl=nl&tl=en&js...
Obviously this is probably illegal, but there would definitely be a beautiful irony to it. :)
They do not need to be taken down; they need to be reconfigured. An open DNS resolver is (arguably) misconfigured, not malicious.
http://openresolverproject.org/search.cgi?mode=search4&s...
This range has a description of "Static IP Pool for xDSL End Users", so is it also home users who have open resolvers?
Your ISP could terminate the contract with those 3 customers, but they won't - they're customers. They could block inbound trafic on port 25 to those 3 customers (if they knew about it), but they have no incentive to. Or they could block all inbound traffic on port 25, which will likely break DNS for a lot of customers.
I think the RCODE is important. I also checked 8.8.8.8 but got a result I wasn't expecting.
Whether you like it or not society tends to react like high-school - when enough people abuse a privilege eventually that privilege gets taken away. You can argue that a free Internet is a right (as some do) but you won't win that argument in the public sphere if that right is used to stop everyone else from getting done what they want to do online.
We really need places like cyberbunker to keep internet free and open.
The day the the last piece of w4r3z, pr0n and other 1337 stuff is taken away from the internet the infrastructure would have to be in place to pretty much remove anything you want at will.
I wonder what will be next thing to get removed after that?
"First they came..."
I don't see where the internet is becoming less free and/or open.
I dread the sterile showroom that some wish the internet to become. But at the same time, there's a difference between objectionable content being available on the internet to those looking for it, and people flooding communication channels with unsolicited and possibly objectionable content, in the hope of making a quick buck.
I support pull-freedom, not push-freedom. The recipient should be the one deciding what they do and don't want to read/be exposed to.
Would you support someone DDoSing the maintainers of the EasyList for AdBlockPlus because their ad-serving domain was added to it?
If SpamHaus had the power to remove CyberBunker from the internet, this would be a different story, and I'd support CyberBunker. But SpamHaus only says "There's lots of spam originating from there". Which is a fact. I don't think they should be punished for stating the truth. A list of suspected spammers has just as much of a place on the free internet as the w4r3z and pr0n we all love so much.
I was, however, interested to see no mention whatsoever of cloudflare in other reports of this[1]. Is this something that bothers you?
My favorite part of a Cloudflare post.
If a DNS server doesn't perform lookups for any outside server it isnt very useful.
If you think about a web host, with X number of servers that host websites, these are considered the Master DNS servers when the physical domains being hosted reside on those servers.
The public listed DNS servers on your domain WHOIS records are actually the Secondary DNS servers, and these perform the DNS lookups when someone accesses the hosted website on your Master server.
If the Secondary server accepts requests from anyone, even domains it isn't explicitly responsible for, then it is performing recursive lookups.
A more secure configuration is for the Secondary servers to only accept lookups for its own Master servers.
That makes them work like Smurf ampliefiers (http://en.wikipedia.org/wiki/Smurf_attack) in the past.
I'd speculate the most common reason for using DNS recursion is to allow a non-authoritative name server to return results for any query. This non-authoritative name server usually sits on a network that serves clients with low latency and high bandwidth, like a LAN. The network is typically private, but private is not always the same as secure/closed. Some benefits of running your own DNS are:
* The ability to cache DNS lookup results (speed increase)
* Placing the name server closer to clients (speed increase)
* The ability to blacklist certain zones (security)
And many more, most of which relate to control, speed, and security.
The thing is, none of these advantages are related to running an "open" DNS with recursive queries enabled. I think the core problem is twofold:
1) Many amateur sysadmins don't recognize that running a name server with recursive queries enabled is a security issue.
2) Enabling recursion doesn't automatically require any configuration to secure the client-trust relationship.
Unfortunately, I'm not really smart enough to propose any changes that would help the situation, but I think this represents a high-level overview of the most common problem scenario.
EDIT: It's also worth noting that some DNS servers enable recursive queries by default. Anyone running their own DNS for their zone, but who don't have knowledge of the issues related to recursive DNS will likely be running an open DNS recursor as well. These are commonly servers at web hosts, which have much faster internet connections as well. So it's a matter of getting everyone on board for changing defaults.
I don't understand why anyone puts up with them. I suspect because they have the word "Open" in their name.
Note my example with MSDN took place a while ago so it might be replicable today.
Additionally OpenDNS has some behaviors that network admins aren't crazy about. OpenDNS will return an answer for queries with no authoritative match. For example, if you query `dig noexist.example.com @208.67.222.222` (that's an OpenDNS resolver IP), you'll get answer: 1 and an IP address. This is considered a "feature" by OpenDNS, but from a purist's perspective, it is a breakage.
We do not run our own DNS server for client name-resolution, because we don't have any need for the control it provides. I acknowledge that some people do, however.
http://en.wikipedia.org/wiki/Name_server#Recursive_query
Thanks in advance!
Honestly, your best bet is to firewall off UDP port 53 to all hosts except ones that are using it as a DNS server.
There were 14 open resolvers. Prodding a bit around at them , many of them are just linux machines people in my area put on the internet, and have just installed a DNS server on it, likely for caching purposes, but it isn't set up properly.
Ofcourse these are DSL connections, so the upload rate is likely just 512kbit, but all you need is enough of them.
On a side note, I think that especially in times where messing with DNS is used as a censorship tool by a lot of governments and regulators, there is some value in being able to ask someone else's DNS for any domain, but that's a different issue.
* Attacker sends (small) query to a lot of resolvers, spoofing the source adress to be the IP of the target
* Each NS replies with a (large) response, thus flooding the target with a lot of data
As long as there is no rate limiting in the nameservers used for the attack, this would work regardless of whether the answer is authoritative or not.
How is 300GBPS a lot? If we take London which has 8million and say roughly half of them are on the internet (4million). Wouldn't that mean that if everyone was using 78kbps we would reach 300 gbps(roughly)?
I just don't understand how a tier1 or internet exchange router can only handle 100gbps. That seems extremely low to me considering I have like 1mbps for just my house?
Pretty much, 100Gbps is about 100 thousand times your internet connection. So, a single 100Gbps line could handle 100 thousand people like you requesting a 1mb file at the EXACT same moment. Spread that out by even a few seconds and that router can handle way more people than that 100 thousand.
This is a GROSS oversimplification, but the idea stands.
This diagram from wikipedia shows some of the sorts of alternate routes that might be used: http://en.wikipedia.org/wiki/File:Internet_Connectivity_Dist...
As an aside: does anyone know of a good resource that gives an example of the rough percentage of traffic that would be handled in each of the various ways?
How exactly do we combat this?
Incompetence? More likely.
Incompetence due to having 45 #1 priorities and developing a deep understanding of secure configurations is a #3 priority? Most likely.
Governments have recognized the need to defend against direct attacks on their networks and develop their own offensive attack capabilities from a national security perspective but I haven't seen the same level or response to these sorts of events.
When the damage spills over to impacting services that tens of millions of people rely on and cause economic damage, should we treat this as the same as an attack on our critical infrastructure (electricity, water, etc.) like an act of terrorism? If that becomes the case, would it warrant the use of deadly force against the attackers?
I really admire what cloudflare did, and help the not too tech guys to understand how this things works, if cloudflare were promoting himself with this posts well they need to eat and educate their children is normal their behavior.
Are there any recommended books on learning about the Internet/DNS on a global scale?
There are always the standards texts, Computer Networks by Tannenbaum and Internetworking by Radia Perlman for the theory.
Surely if random people can't connect to DNS resolvers and get information, they can't surf the net either? Someone has to resolve DNS for people for the internet to function, don't they?
Hence, some DNS servers have to be open. By saying it's openness that's the problem, we're blaming the victims, rather than the issue, which is that DNS is flawed. Simply moving to TCP would be better, surely?
Closing open DNS servers isn't a real fix. The people who need to fix it are the lest likely to have a clue there is a problem in the first place.
Do you have any details on how google or opendns solve the problem? I'm particularly interested in why their servers can't be used for reflection, because if there's an easy way, shouldn't we be asking the owners of open servers to do that rather than limiting IP access?
In case this comes across as argumentative, please let me say that I am actually interested in this and am asking for information, not trying to make a point here. I really would like to understand the issue.
I think your point about trying to find a way for the open DNS resolvers to be protected but still open is moot, because there's really no reason for servers to be open to everyone (except for Google or OpenDNS who know what they're doing), these are just misconfigured servers of people who have no idea they can be abused. In my opinion the solution is for ISPs to actively block such open resolvers among their clients.
Eg https://en.wikipedia.org/wiki/DNS_blocking#Criticism
http://torrentfreak.com/how-to-unblock-the-pirate-bay-111004...
One of the big advantages of DNS at the moment, surely, is its ability to be run by anyone?
Hm, as opposed to normal days, when our Internet is just normal sluggish. Not that fond of that phrasing. And I must be bored to even comment on that.
Hope that kind of pubic outcry and media visibility will get the networks and governments to take notice and fix the core Internet infrastructure of the known vulnerabilities
It doesn't have to be mean and destroy data, just incapacitate the machines and force the users to upgrade.
Besides, if this hypothetical "anti-malware" actually incapacitated machines, it would be highly illegal itself.
"We're proud of how our network held up under such a massive attack."
wat?!
But a case can be made that large requests should be TCP only.
Not if you simply keep a TCP connection open and use SYN cookies on the servers. Many DNS servers already support TCP (though I'm pretty sure you need a new connection for every request).
They point out, for example, that the IX's in question routinely see 2.0+Tbps peaks, so a 0.3Tbps attack would not be likely to shake a single IX, little like "the internet" itself.
Interesting rebuttal, although certainly not comprehensive.
If they really know how the Internet works they shouldn't make claims like this.....
They are crafting the stories methodically (and successfully I'd say, given the number of times we all talk about CloudFlare on HN) to drive more exposure to their brand. It's too optimistic and hyperbolic sometimes, but no really different than any product announcement from Apple or Facebook.
In all fairness to them, a positive side effect is that we're all discussing now how to solve the root cause of this decades-old - but still threatening - problem (open networks and dns attacks). I guess it will really take an apocalyptic event to convince millions of operators to configure better their own networks.
This is not the first time CloudFlare uses hyperbolic headlines. Case in point: "Why Google Went Offline Today and a Bit about How the Internet Works" https://news.ycombinator.com/item?id=4747910
Article: "Looking at peering maps, I'd estimate the outage impacted around 3–5% of the Internet's population."
The truth is in the middle.
There were repercussions in Denver/Colorado with a Tier 1 network provider, mainly in the form of greatly increased latency. This impacted downstream providers, as well as a couple of my clients in Colorado. I informed those clients yesterday my opinion was the issue was either a network engineering/backhoe issue, or there was a major concerted cyber attack targeting the Denver area.
The reality? There was an attack. It was measurable. It did have a noticeable impact. But it was far more annoying and irritating than the headline "Internet killed. Film at 11." would lead one to believe.
Here is a nice collection for the interested readers: https://www.euro-ix.net/resources-list-of-ixps