Slashdot Mirror
Misconfigured Open DNS Resolvers Key To Massive DDoS Attacks
msm1267 writes with an excerpt From Threat Post: "While the big traffic numbers and the spat between Spamhaus and illicit webhost Cyberbunker are grabbing big headlines, the underlying and percolating issue at play here has to do with the open DNS resolvers being used to DDoS the spam-fighters from Switzerland. Open resolvers do not authenticate a packet-sender's IP address before a DNS reply is sent back. Therefore, an attacker that is able to spoof a victim's IP address can have a DNS request bombard the victim with a 100-to-1 ratio of traffic coming back to them versus what was requested. DNS amplification attacks such as these have been used lately by hacktivists, extortionists and blacklisted webhosts to great success."
Running an open DNS resolver isn't itself always a problem, but it looks like people are enabling neither source address verification nor rate limiting.
In before the fight between those two guys and their walls of text...
Running an open DNS resolver isn't itself always a problem, but it looks like people are enabling neither source address verification nor rate limiting.
One has to wonder if this is caused by negligence, or if it's more a case of "oopsie, we left this door open, oh well" - which would be a great way to set up nodes around the 'net specifically to allow these types of attacks to occur.
Not saying that is right or wrong - asking a genuine question.
Peace,
Andy.
Why are they not sending out emails to the people running these things.
Check which domains these servers are authoritative for and send them a damn email.
It claims that the problem is DNS resolvers that don't authenticate the sender's IP address using BCP38. It is comparing chalk and cheese. Filtering out spoofed IP addresses is something that needs to happen at the edge of the network. It's not something that a single server on the network can do.
I know Its not the primary topic here,, but gizmodo has some evidence that the whole cyberbunker thing is a fake
http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie
If an experiment works, something has gone wrong.
Maybe this is over my head. But how would one rung a "safe" DNS server then? My interpretation of the article basically says to let only specific people use your DNS server, but then how would a company run a public resolver?
For example, Google runs open public name servers on 8.8.8.8 and 8.8.4.4, same with OpenDNS, and many, many more. What is to stop those servers from being used in this sort of attack? Is this article really advocating a situation where you MUST use only your own ISP's resolver and trust them not to do what so many of them consistently do and mess with the results?
Or am I completely missing the point to this article?
Two different things. If you are running a DNS server yourself, for your own domain then you should only respond to requests for your domain from the outside. IE - Non-recursive. The only answers you serve are for those queries you are authoritative for. You only accept recursive queries from inside your own network. Those are the recursive ones.
Public servers would use rate-limiting to to protect against being effective in spoofed attacks.
#2 is the right answer, be responsible for the traffic on your network.
#1 is the wrong answer. Too many ISPs fuck with DNS by returning IP addresses to advertizing domains instead of NXDOMAIN.
Can someone explain how a DNS server can check source address validity? Is it going to fire off more packets to that source address (worsening the DDoS) or what?
There is no way that DNS over UDP can verify a source address. The solution is that all ISPs drop traffic with invalid source addresses before it leaves their network.
DNS resolvers were originally intended to be open. There was no reason for them not to be. But furthermore, the recursive functionality of DNS made open resolvers a near requirement. This has changed a little and slowly over the years, but it's still largely the case.
[...] It's not in the spec, so why should they?
The changing environment now calls for doing things that weren't done years ago. We have already crossed this bridge with open email relays; this isn't necessarily the case here (the real problem is the lack of IP spoofing protection), but it would be nice for administrators to realize that they may have an open resolver. Many of them will decide that there is no point in offering free DNS resolution services to the whole world and take steps to restrict access. Some will decide that they want to continue offering it; more power to them.
Far from being a requirement, a DNS resolver works just fine if it isn't wide open.
This attack suggests that the spec needs refinement, but don;t go blaming people for doing what has been accepted best practice for the past 20 years or more.
I wouldn't go as far as to accuse them of malfeasance or negligence, particularly since the real problem is lack of BCP38 compliance. So lets not do that. Instead lets educate administrators and permit them to make their own decisions; in this case the decision will likely be to restrict.
Far from being a requirement, a DNS resolver works just fine if it isn't wide open.
Yes, but an authoritative DNS server does not, and authoritative DNS servers can still be used in reflection attacks.
Zone files that contain a large response for an easily found query are especially popular.
The problem to be solved is not a DNS problem, but a failure to implement BCP38 / Ingress filtering implementation problem.
Failure to implement ingress filtering is worse than open mail relay, because it allows bad actors to hide their identity.
For sake of argument assume you are able to snap your fingers and miraculously all open resolvers have been locked down. What has been accomplished?
Will anyone still be able to issue legitimate DNS queries using forged source address with impunity for which response is several times larger than request? YES.
Will DNSSEC with egregiously enormous amplification when configured entire as recommended simply go away? A man can dream. I doubt this will come to fruition.
The way I see it there are two solutions to this problem. BOTH need to be implemented.
1. Ingres filtering (AKA tools.ietf.org/html/bcp38) as TFA and many others here point out needs to be implemented with enough specificity to meaningfully raise the bar for successful source address spoofing.
2. All UDP protocols allowing amplification or resource exhaustion from spoofed source addresses need to be beaten with a clue stick for making the Internet worse than need be. There is NO EXCUSE.
It does not need to be perfect it only needs to not suck more than the underlying network.
We know how to do this. There are production protocols which get it right. The answer is stateless cookies. It might require an extra round trip once in a blue moon or a few extra CPU cycles to calculate HMACs... we can easily afford it.
In return we get UDP protocols at least as trustworthy as underlying transport. Protocols which can no longer be turned into weapons of mass deluge.
For DNS we have had reasonable solutions for years...yet we sit on our hands and nothing gets done...
http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03
This can easily be phased in conjunction with DNS query rate limiting applicable for requests without cookies.
It seems to me all the money and political interest follow fools errands like DNSSEC which paradoxically makes the Internet we actually have right now less safe from denial of service.
Since an authoritative DNS server only handles requests from recursive caching servers it can implement rate limiting, thus making reflection attacks useless.
But you're right - the failure to implement BCP38 is a bloody scandal.
Watch this Heartland Institute video
Actually, transit providers are one of the groups that can't reliably apply BCP38 or RPF. BCP38 and RPF is very easily applied at the edge, where you know specifically the IPs involved, since they're either connected or statically routed. Now, when you get into things over BGP, it gets dicey. You may see traffic over a BGP-managed link from an IP that isn't involved in the received prefixes, but yet still belong to the specific peer. Is this an error? No. Is dropping the bits on the floor because you're not seeing that prefix an error? Most definitely. Not announcing a prefix over a link is a common traffic engineering practice, so this isn't an uncommon scenario. Another option to work around that would be to have a prefix-list with all of that peer's possible prefixes and build an ACL off that, but that's also not always tenable when you're potentially dealing with 1,000s or 10s of 1,000s of prefixes for the larger networks. Nice thing is, at this level, usually you can bust out the sFlow/NetFlow-fu and find out where the spoof is coming in from, and then whack it at that point.
But looking at the OpenResolver project list, when broken out by ASN, it really looks like a huge amount of those open recursors are CPE gear with WAN-facing DNS services, just based on the ASNs. China Telecom (AS4134), Uninet (AS8151) and Turk Telecom (AS9121) accounted for 3.5 million (15%) of the recursors alone.
That's the question I wanted to ask. I can give a partial answer to the question, but no the complete solution implied to exist by the summary.
When the server sends a DNS reply back to a legitimate client, it is not supposed to receive any more packets related to that query. However, if the source address was spoofed, the receiver of the packet will send an ICMP error back indicating the port is closed, or an ICMP error indicating the port is blocked by the firewall, or an ICMP error indicating that the address is unreachable.
You can look for those ICMP errors to find out if your own DNS server is part of the attack with a tcpdump command looking for example like this:
One caveat to remember is, that the ICMP error itself could be spoofed, so some verification would be needed to validate the ICMP error. Also requests spoofing the IP address of a legitimate client of the DNS server means there could be spoofed and legitimate queries arriving from the same source IP address, and just blocking all of those, would introduce a different kind of DoS vulnerability.
So detecting the attack on the DNS server after the fact is easy in principle. But responding to it in a way that doesn't DoS the DNS server itself is tricky. The best I can come up with is force clients to switch to TCP by sending an empty reply with the truncated flag set. That would reduce the amplification factor to one or less, effectively making this DNS server of no use for the attacker. But it would severely reduce the efficiency of DNS lookups on that server, and completely break it for setups, that assumed DNS lookups were always done over UDP.
If there exists a better solution, I'd like to hear about it. Moreover the best solution I can imagine doesn't seem to be implemented by bind. The best I could come up with for bind is:
If you are sending just a single packet to the victim, and that packet is smaller than the DNS request, then the amplification factor is less than one, and the attacker would be better off attacking the target directly. But such a packet needs to be designed to trigger an appropriate response from the DNS client.
One thing you could do when receiving a DNS request from a previously unknown IP address is to always respond with a truncated reply.
All in all that results in the following simple algorithm.
As for rate limiting, I looked in the bind manual and found no mention of any way to configure rate limiting. Maybe they used another name for it.
Do you care about the security of your wireless mouse?
that anybody can spoof source IP addresses
Its absolutely realistic, and that statement is only true because ISPs are lazy.
Look, Im verizon. I know that my DHCP servers in a neighborhood are providing 98.142.30.0/24 to those folks. Hey look, a packet claiming to be sourced from 132.29.42.27, I wonder if thats legitimate or if my border routers should just drop it?
There is NO scenario where a wired internet connection should be spoofing IP addresses, because the ISP will NEVER be able to deliver return traffic to that person. I have heard that there are possible justifications for spoofing in the mobile space, but lets be realistic; 99% of bots are not mobile, they are on static lines where ingress filtering would put an immediate stop to amplification attacks.
Your idea that DNS servers now need to fire off ICMP traffic to verify source address- what happens when the IP is legitimate, its just someone else? Now on top of your large zone file that youre going to hit them with, youre dumping ICMP traffic too-- you just made the amplification attack stronger.
TCP/IP (and ethernet) operate on the assumption that nodes are not lying when they write their source MAC and IP addresses. It is technically possible for a node to do so, but guess what-- it is trivial to implement layer 2 and layer 3 ACLs to stop that crap at the first hop.