Misconfigured Open DNS Resolvers Key To Massive DDoS Attacks 179
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.
First post (Score:5, Funny)
In before the fight between those two guys and their walls of text...
Re:First post (Score:5, Funny)
Re: (Score:3)
Bloody hell, I'm on the wrong thread.
Re: (Score:2)
Likewise- I'm not in favor of it, but this is the first workable proposal I've ever seen.
Re: (Score:2, Offtopic)
In before the fight between those two guys and their walls of text...
I've begun to think it is actually just one guy just trolling (poorly) for all they are worth. Either that or it has turned into a meme that encourages the the likes of 4chan /b/tards to, in their own way, declare I am Spartacus(APK), just for the lolz...
Re: (Score:3)
it's a meme.
the sign of a meme is that discussion about it fills first few posts even if the actual subject of the meme is nowhere to be seen.
and spamhauscraft confirms: gnaa is dead.
but why is such source address spoofing still such a problem? ironically this ties in to dozens of post-packages signed apk.
and the hosts file approach isn't that bad way to filter bunch of ads. it works...
Re: (Score:2)
... Either that or it has turned into a meme that encourages the the likes of 4chan /b/tards to, in their own way, declare I am Spartacus(APK), just for the lolz...
More like Spamtacus.
Re: (Score:2)
Accidentally, or not? (Score:4, Interesting)
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.
Re: (Score:2)
It might also be an old DNS server no one is using or remembers they have up.
Re: (Score:2)
Which is just a different form of administrative incompetence.
Proposals have been forwarded to use open DNS resolvers to DDoS open DNS resolvers to force their admins to fix their problems. Which is probably not going to help much where the actual problem is simple ignorance. If the person doing the "administration" of a system doesn't even know what DNS resolution is, then blowing them away for running an open resolver isn't actu
Re:Accidentally, or not? (Score:5, Insightful)
Isn't the real problem the originating ISPs for allowing spoofed packets to be sent in the first place? Is it really correct to be blaming the DNS resolver that it's responding to packets it has no way to authenticate? If the original ISP dropped a packet it shouldn't be routing, the whole problem would go awa.
Re:Accidentally, or not? (Score:5, Informative)
Yep. Had BCP38 (Best Current Practice No. 38) [ietf.org] been in effect at those ISP's, this attack would not have occurred.
Re: (Score:2)
Let's say I'm an ISP, Acme Internet. I purchase bandwidth from AT&T and Cogent and SWIP some address space from ARIN and get myself a portable AS. Now I peer via BGP with AT&T and Cogent and announce my new address space and AS. No
Filtering UDP works fine - uRPF is IP layer (Score:2)
An ISP can filter out spoofed UDP packets just as easily as spoofed TCP packets - the filtering happens at the IP layer in the router, not at the transport or application layer. Unfortunately, as another Anonymous Coward points out, it has to be done at/near the ISP where the spoofed packets originated, and that ISP may be spammer-friendly and have an upstream that's not enforcing anti-spam policies or using strict-mode uRPF (because that's something that normally you don't do except on leaf nodes.)
An auth
Re: (Score:2)
Re:Accidentally, or not? (Score:4, Informative)
A DNS server has no way of verifying whether the source address is valid. Only the ISP who provides access to the originator of the traffic can do that.
So what are the defaults? (Score:2)
Also, one has to wonder if it's negligence by the person installing the resolver, or by the person distributing the resolver.
What are the default values for source address verification and rate limiting? If having them both disabled is a problem, at least ONE of them should be on by default, requiring it
Re: (Score:2)
This has to do with not good thought out default settings of the various DNS servers out there, but also has to do with people running too old DNS servers.
You can restrict recursing resolve based on source IP, groups of IP or subnets.
First I do is define an internal mode and an external mode where external mode only sees an authoritive server and the internal mode can do recursed resolving.
Re: (Score:2)
Many deliberately don't restrict recursive lookup as a service to anyone who needs it. The fault lies with ISPs that allow their customers to source packets with addresses they haven't been assigned.
Re: (Score:2)
Things that used to not be threats (Score:2)
DNS used to not be a threat; that's been changing. Rate limiting wasn't an issue. Source address verification was a problem for ISP routers (to prevent address spoofing), but it wasn't a problem for recursive DNS servers (who were willing to serve anybody, not just their own customers), and it especially wasn't a problem for authoritative DNS servers, because they're supposed to tell anybody the address for www.yourdomain.com, and aren't in the right part of the network to verify whether a UDP DNS request
Re: (Score:2)
Re: (Score:3, Insightful)
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?
Re: (Score:2, Informative)
Re: (Score:2)
You can validate it after the fact. If you receive an ICMP error it was not legitimate. If you can get it to connect over TCP by sending a truncated reply, it was legitimate.
This is unrealistic. If you want to design a secure system, you are better off designing it under the assumption, that anybody can spoof source IP addresses. Filtering pack
Re: (Score:3)
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 the
Re: (Score:2)
It could be delivered through a different path. For example you might have redundant internet connections through different providers. It could also be that one of the two paths is using VPN and the other is not.
There are also special addresses, which are valid as source address, even if they are not assigned to you specifically. For example,
Re: (Score:2)
I know lots of people block ICMP packets to "protect" their network. Maybe these misguided attempts at protecting networks will stop, if sending those ICMP errors would actually reduce the incoming flow of attack traffic. If it was common practice among DNS servers to take countermeasures, once they receive ICMP errors, then this thread would have looked differently. In that case, it would have started out with explanations about how incompetent
Re: (Score:2)
Somebody did already, they just didn't do a very good job at it. EDNS made this sort of attack 8 times more effective than it was before EDNS was introduced.
That is a very sensible approach. It does however require a little bit more management fo
Re: (Score:3)
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
Re: (Score:2)
If there exists a better solution, I'd like to hear about it.
BCP 38, which does the source address checking where it can be done-- at the first hop controlled by the provider and router of the IP address, the ISP. They know what IPs should be coming in from which ports, since they provide the ports and IP addresses (port in this case meaning PoP / physical connection).
Re: (Score:2)
Great. I am going to configure that on my bind based DNS server right away.
Re:By Design (Score:4, Interesting)
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.
Re: (Score:3)
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 b
Re: (Score:2)
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.
Re: (Score:2)
IIRC MicrosoftDNS is slightly modified version of bind 4.
Re: (Score:2)
Suggestion: collect a list of all the IP-addresses that send queries for a few months and then enable the ACL.
When the next DNS amplification DDoS attack comes in a few months you won't be part of it and you don't need to handle that traffic.
Why are people not being alerted? (Score:3)
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.
Re: (Score:2)
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.
I agree, something proactive needs to be done. The question I have is: whose job is it to do something proactive in these instances? Does anyone do these sorts of things?
According to the article, there are ~27 million open DNS resolvers. That might take some time. I suppose it could be automated, though, with a "Dear [admin and/or technical contact], your DNS located at [ip address] is breaking the internet. Love, Some people you have never heard of. Click here for more information." I wonder how many of th
Re: (Score:2)
That might take some time. I suppose it could be automated, though, with a "Dear [admin and/or technical contact],
Are you joking? What if they don't read English? The most open-server dense netblock is .tw. Pakistan is also high on the list of offender IPs.
Re: (Score:2)
There are over 25 million known open DNS resolvers [openresolverproject.org] that can be used in DNS amplification attacks. Directly contacting the administrators of all the servers used in the attack is not a tractable problem. The same is true of pretty much any DDOS attach vector; there are too many broken machines to deal with them directly.
Re:Why are people not being alerted? (Score:5, Funny)
There are over 25 million known open DNS resolvers [openresolverproject.org] that can be used in DNS amplification attacks. Directly contacting the administrators of all the servers used in the attack is not a tractable problem
It sounds like the solution is to send out a huge amount of unsolicited email.
Oh, wait ...
Re:Why are people not being alerted? (Score:5, Funny)
There are over 25 million known open DNS resolvers [openresolverproject.org] that can be used in DNS amplification attacks. Directly contacting the administrators of all the servers used in the attack is not a tractable problem
It sounds like the solution is to send out a huge amount of unsolicited email.
Oh, wait ...
Well we could do a kickstarter, and hire our friends at Cyberbunker to host the email sending...
Re:Why are people not being alerted? (Score:4, Informative)
Because the DNS servers are doing nothing wrong.
The problem is that people can spoof source addresses (because ISPs arent stopping it). Fix this issue, and youll still have to worry about any of a million other scenarios where a small request gets a lot of data back.
All you have to do is make sure source addresses are filtered when they hit the ISP, and the huge majority of these issues (as well as being able to cloak where an attack came from) go away.
Re:Why are people not being alerted? (Score:4, Informative)
Because the DNS servers are doing nothing wrong.
The problem is that people can spoof source addresses (because ISPs arent stopping it). Fix this issue, and youll still have to worry about any of a million other scenarios where a small request gets a lot of data back.
All you have to do is make sure source addresses are filtered when they hit the ISP, and the huge majority of these issues (as well as being able to cloak where an attack came from) go away.
Actually, they are. The feature being leveraged here is that the servers are performing recursive lookups for domains that they do not control for the open Internet; BIND turns this off, by default, starting with version 9.4. The problem is that a lot of 9.3.X and older DNS servers are still out there, as well as a lot of bad network architecture jobs. The servers should only handle recursion for IP addresses that are on the inside. And as for the spoofing? Well, ingress filtering is trivial to do at the border. And these two things in concert shut this problem down entirely.
Re: (Score:2)
Actually, they are not, or this wouldn't be happening. The attack involves sending DNS requests to an open resolver with your target's source address. If your ISP was doing the right thing, those packets would never get to the open net at all.
I know that any time I've set up a dual homed network, the upstream providers have wanted evidence that I had a right to use the addresses I told them I would be originating. Until I provided that and a complete list of those addresses, the packets would not go out. Th
Re: (Score:2)
Because the DNS servers are doing nothing wrong.
The problem is that people can spoof source addresses (because ISPs arent stopping it). Fix this issue, and youll still have to worry about any of a million other scenarios where a small request gets a lot of data back.
All you have to do is make sure source addresses are filtered when they hit the ISP, and the huge majority of these issues (as well as being able to cloak where an attack came from) go away.
Actually, they are. The feature being leveraged here is that the servers are performing recursive lookups for domains that they do not control for the open Internet; BIND turns this off, by default, starting with version 9.4. The problem is that a lot of 9.3.X and older DNS servers are still out there, as well as a lot of bad network architecture jobs. The servers should only handle recursion for IP addresses that are on the inside. And as for the spoofing? Well, ingress filtering is trivial to do at the border. And these two things in concert shut this problem down entirely.
If my DNS is doing recursive lookups on spoofed packets, and I turned off recursion, wouldn't the attackers then send spoofed packets to, say, Google's DNS, causing the same havok?
Sure it would be easier for Google to implement rate limiting through IP tables or whatever, but they wouldn't be able to recognise spoofed packets either.
So I don't see how recursion is the issue versus ISPs blocking spoofed packets leaving their own networks.
Am I wrong here, and if so, how?
Re: (Score:2)
The problem is that people can spoof source addresses (because ISPs arent stopping it).
Bingo.
I wrote a paper about a similar attack (called a reflection DDoS attack back in the days) in 2002. Mine didn't use DNS, but a different service, but same principle - massive amplification.
I'm honestly surprised that IP spoofing is still possible today. Have ISPs been asleep for the past decade? The number of legitimate use cases for source spoofing across a WAN (there are a number in LAN) can probably be enumerated in a very short list. I personally can think of... one: Testing if your ISP is stupid.
Re: (Score:2)
Trust me...it's not that simple. For one, there usually isn't an email to send to...there may be one listed somewhere, but it may not be real or nobody may read it. But on top of that, who is this "they" you are referring to...Spamhaus? So, Spamhaus should do a lookup on every single DNS server that is hammering them during the largest DDoS in history, find the abuse email address for each of them, and send them an email? All while getting hit with the biggest DDoS ever?
To get a sense of why abuse email
Re: (Score:2)
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.
Cause "fixing" them solves nothing?
Re: (Score:2)
Article is garbage (Score:5, Insightful)
It claims that the problem is DNS resolvers that don't authenticate the sender's IP address using BCP38 [ietf.org]. 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.
Re: (Score:2)
This. Rate-limiting can help...I'm quite sure Google has rate-limiting in place on 8.8.8.8 for instance. But for those who don't have Google's budget, it's a challenge. There are not currently any sufficiently tested and stable DNS rate-limiting features in any of the top 3 resolvers out there. The problem here is networks letting spoofed packets out of their nets, not DNS servers performing correctly.
Re: (Score:2)
There is a rate limiting patch for BIND. The BIND package in RHEL/CentOS has it now:
https://bugzilla.redhat.com/show_bug.cgi?id=873624 [redhat.com]
A person has also attached a graph showing its effect on that bug page. I know of some other places which are using this patch.
(Disclaimer: I work for the organization that produces BIND.)
Re: (Score:2)
There is a rate limiting patch for BIND. The BIND package in RHEL/CentOS has it now:
If you really want to solve the problem then implement DNS cookies.
Please think about what your doing. Rate limiting solves nothing. Once this is deployed the attacker will simply alter the contents of their queries rather than resending the same tired request such that it now becomes indistinguishable from background with much the same results. At that point any additional rate limiting hurts legitimate users just as much as attackers.
This is your typical spam fighting downward spiral. You see a proble
Re: (Score:2)
Re: (Score:2)
ISPs could very easily drop packets with fake source IPs at their borders. They know what IP addresses they own, and it's not resource intensive to check it. It would stop a whole host of problems if all ISPs did this.
Then again... are smartphones and tablets using a mobile-ip protocol that would get screwed up by this? If so, good! Maybe those damn kids will stop staring at their phones to two seconds and get the hell off my lawn!
Re: (Score:3)
If so, good! Maybe those damn kids will stop staring at their phones to two seconds and get the hell off my lawn!
Now will you believe that there are good reasons to not open your WiFi?
!!! You've got kids from the whole neighborhood just hanging out on your lawn, leeching your WiFi. Think of all the pheromones coming from all those kids wishing that cute thing a few steps over would look up from the phone and talk to them. All of those awkward glances and giggles.
At this point, the last thing you need is one of them downloading a nude picture of one of their classmates (which will happen several times a week...). Can
Re: (Score:2)
Youre not understanding how the spoofing works, and "the way out being clogged" is irrelevant when youre getting 100-1 amplification off of large numbers of bots.
The attacking computers are claiming that their source address is that of the person they want to attack; they request a large DNS file; the DNS server sends its gigantic response to the victim (who has been impersonated).
The DNS server CANNOT realize that the source IP was forged without sending additional traffic. The ISP however CAN, since they
Re: (Score:2)
Right, the post I was talking about was saying that the traffic should be filtered at the edge of the network, my point is that wouldn't do anything.
I meant...
There's no point to filtering out spoofed IP addresses
w proper sentence structure lol.
AC didn't specific which network the ISP's or spamhaus. I agree the ISP can fix it though, getting them to do so carries its own set of challenges.
Here's a good read for anybody still confused: http://arstechnica.com/security/2013/03/spamhaus-ddos-grows-to-internet-threatening-size/ [arstechnica.com]
Basically restates the above post +
Re: (Score:2)
Except for the fact that some DNS servers do not have rate limiting nor the funds to implement rate limiting (it's non-trivial to implement), you're right.
In my case, without EDNS support, the highest amplification factor my DNS server has is 23x (as opposed to the 100x+ EDNS servers have). Also: My server doesn't have open recursion enabled by default.
Hoax? (Score:5, Interesting)
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 [gizmodo.com]
Re: (Score:2)
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 [gizmodo.com]
WHOA WHOA WHOA. No.
This 'thing' is definitely real. It's happening. That's not in question. What ISN'T real, however, is CloudFlare's assertion that it's "jamming crucial infrastructure around the world".
Re: (Score:2)
dunno, it is real if you define spamhaus as crucial infrastructure.
it isn't though..
Re: (Score:2)
gizmodo and "evidence" are an oxymoron aren't they? Anything under Gawker is suspect, and giz has always been gutter level.
If I hadn't just posted twice, I would mod this up in agreement. Gizmodo is a blog that posts gadget-related rumors and the like...and even then they suck up the snake oil like Robert Evans snorts cocaine.
I'm not quite sure how you're supposed to do it? (Score:2)
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
Re: (Score:3)
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.
Re: (Score:2)
Two other different things...
1) ISPs could drop out-going tcp and udp packets on port 53 from all their IP address except their own DNS servers. That would stop their customers from using public DNS server outside their networks. But it would also stop this kind of attack.
2) Drop all outgoing traffic that has a spoofed source IP address. This is a very simple bit mask operation. Yes, it requires more compute power than not doing it, but not very much. The ISPs know what IP addresses they own, they can
Re: (Score:3)
#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.
Re: (Score:2)
1) would be REALLY bad, and I hate anyone who would even consider such a solution.
2) I can't imagine why every ISP and transit provider doesn't already do this. This has been a known problem for over a decade, deal with it already!
Re: (Score:3)
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: (Score:2)
Two other different things...
1) ISPs could drop out-going tcp and udp packets on port 53 from all their IP address except their own DNS servers. That would stop their customers from using public DNS server outside their networks. But it would also stop this kind of attack.
It would also have a high collateral cost: diagnosing many DNS issues becomes impossible when you can only work with one recursive resolver (which may be what is causing the DNS issues!) It is necessary to access legitimate open resolvers and authoritative servers on any kind of Internet connection, even residential broadband (don't think of grandma but think of the tech helping grandma).
In short, we *need* TCP and UDP port 53 traffic unfiltered.
2) Drop all outgoing traffic that has a spoofed source IP address. This is a very simple bit mask operation. Yes, it requires more compute power than not doing it, but not very much. The ISPs know what IP addresses they own, they can very easily prevent spoofed traffic from leaving their networks, effectively stopping this kind of attack, as well as other types of hacking. At the same time, it would still allow legitimate use of public DNS servers.
This is what we need more of. Provided, of course, that it isn
Re: (Score:2)
You simply configure your DNS server properly, including setting the networks it's allowed to resolve for. A nameserver can be both authoritative for certain domains globally, and also be recursive for specific hosts.
Of course, there's also the problem of DNS amplification using source address spoofing by requesting authoritative DNS records, but simply doing the above greatly mitigates the effectiveness of the attack.
Re: (Score:2)
To reply myself... no it can't, it's non..recursive..
Um, not exactly... You an have an authoritative non-recursive DNS server that gives large responses to questions used in an amplification attack...
'dig a www.authoritative.domain @authortative.domain.ip'
RESPONSE = 1000+ bytes follows...
Re: (Score:2)
Sure it could. If it is (mis)configured to allow a zone transfer, you could have a bot net send it zone transfer requests for your own domain with the source ip address spoofed to be your target. A little more complex setup than a recursive request, but you still some get good amplification. Do that on thousands or millions of DNS servers that aren't recursive, but allow zone transfers, and you still get a DDOS attack with very little input traffic. You could also do it on root servers (or any recursive
Re: (Score:2)
Sure it could. If it is (mis)configured to allow a zone transfer, you could have a bot net send it zone transfer requests for your own domain with the source ip address spoofed to be your target. A little more complex setup than a recursive request, but you still some get good amplification.
You're less likely to do this by accident. Besides, a spoofed zone transfer will almost always fail on the TCP three-way handshake step.
Re: (Score:2)
Why not? sure, it would be more difficult as each request would have to be tailored to the DNS server it's using, but the same principle should apply, spoof the source address, request information (in this case something within the domain being hosted) and let the larger reply go to the spoofed (victim's) address.
The only thing preventing this is that it's more work than the easier current method of being able to send the same request to every name server, but there's no reason it couldn't still be done.
Re: (Score:2)
It could, but only if they knew what domain your server was authoritative for when they picked your DNS server at random.
Your server would also have to be able to cough up a pretty big response to make it worthwhile.
Re: (Score:2)
Or am I completely missing the point to this article?
Yes.
It's talking about spoofed requests - much like if someone sent a request for more information to a Scientology center, and they put your return address on the form. Suddenly you're getting very creepy mail from the Scientologists and you have no idea where it came from. If they do it enough times to enough organizations, and your mailbox is full, and your Netflix Blu-ray of Tootsie is deferred until you can clean out your mailbox.
Re: (Score:2)
You're confirming that I understood the article perfectly. The problem is in their choice of solution.
It seems there are 2 possible solutions.
1) get ISPs and transit providers to actually start blocking IP spoofing (something they all should have been doing years ago)
2) break the internet by banning all public resolvers.
Unfortunately the article seems to me to be advocating for number 2, which would harm many people, and just cause the attackers to continue to use IP spoofing on different services or protoc
Re: (Score:2)
The problem is that almost no one actually needs to run a public resolver.
Your ISP provides a DNS server to you that is recursive (usually), so they can use ACLs to make sure only their clients are using them.
Domain owners provide DNS servers that are authoritative, but only for their own domain, so it limits the scope of the problem as well.
The problem is when domain owners provide DNS servers authoritative for their domain, but -also- allowing other people to use them as public recursive servers. There's
Re: (Score:2)
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?
The problem is one of degree. The theory is if you don't offer a recursive resolver to the public amount of amplified output you get for your input is diminished over running a resolver that would respond to just whatever your authoratitive for.
Personally I don't buy much into this theory. There are enough ways to request an earfull from enough properly configured servers we can find much more effective things to be doing with our Internet fixing time.
Re: (Score:2)
1. Recursive resolver - this is a nameserver that you can ask to resolve any domain name and it'll do just that. If it isn't authoritative for it (meaning you RUN the zone and it's in a config file locally) it will go through the recursive resolution process for you. It will look at it's root hints, talk to the root
Re: (Score:2)
Actaully, I wasn't confusing the 2 at all. But I don't think that we should be banning public resolvers and forcing people to use the resolver operated by their ISP when those resolvers have frequently been messed with for profit by the companies running them. The article would propose killing OpenDNS, Google DNS, and many, many more.
The correct solution is not to break the internet by banning a harmless and very useful feature, but to fix the internet by blocking IP spoofing. Why on earth are there any ISP
Re: (Score:2)
With that said, there are ways to provide recursive DNS resolution to clients openly, but without being used as an attack vector. Specifically by rate limiting the requests.
The reason ISPs are allowing spoofed traffic is simply one of two things: ignorance or laziness. It's very easy to write an ACL that mirrors your BGP announcements then apply that as an outbound filter at your
these people are worse (Score:2)
than the users that get their computers infected with botnets and spew spam. These people are supposed to know what they're doing.
Take away their Geek Card, and then suspend their internet license ;)
Re: (Score:2)
If you've got a fat enough pipe to do damage from someone abusing your system, and are running an externally-facing service like DNS, that is KNOWN to be an attack vector, then YES, I can, and WILL expect you to know what you're doing, so you're not a danger to others, or ME. You've gone to the trouble of taking off the training wheels, and with power comes responsibility.
As it is now, the i
Re: (Score:2)
Mitigation while it still happens? (Score:2)
How to do rate limiting? (Score:2)
Let's say I want to run a public DNS recursive server, that is, I want to allow anyone to issue a handful of queries for any arbitrary DNS records, and in addition to just serving up my own, I want to also service requests for whatever arbitrary thing they requested. Is there an easy way to rate limit these queries based on source IP address, to prevent abuse of this service I've chosen to offer?
How should one set that up?
Scapegoating open resolvers resolves nothing (Score:3)
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 [ietf.org]
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.
Re: (Score:2)
I believe any server it lists is part of the problem.
Servers that are not part of the problem should not be listed at all.
Re: (Score:2)
Well, that makes sense: the Google Public DNS servers are indeed open resolvers but they have all sorts of mechanisms in place to prevent their being abused.
Re: (Score:2)
Have the SWAT team bust down their door and hall their asses to jail.
Smart! Leave nobody to switch off the botnet!
Re: (Score:2)
>Have the SWAT team bust down their door and hall their asses to jail.
Cannot tell if serious...
If you read the cyberbunkers website, that happened once. Dutch swat showed up.. Looked at gigantic steel doors for a nuclear bunker... Left.
Re: (Score:2)
of course the classic way of solving the this sort of problem was done at Eben-Emael forts in WW2 was to use shaped charges to blow a hole.
Re: (Score:2)
Re: (Score:2)
MaraDNS 1 and Deadwood do not support a technology called "EDNS" that allows for large DNS packets
Sounds like a side effect of a deficiency (read: less than complete DNS protocol support); lack of EDNS support is a potential problem, as it impacts IPv6+DNSSEC, where large legitimate responses may be more frequent. DNSSEC support is critical, as is the ability to resolve such zones without falling back to TCP.
BIND has max-udp-size and edns-udp-size parameters. As do other DNS resolvers.
One feature
Re: (Score:2)
TL;DR The grandparent complained about MaraDNS not having more features. He responded to my "show me the money" reply by saying "why should anyone pay you if you don't have more features". My reply: "Because DNS shouldn't be a monoculture".
(As an aside, I actually somewhat respect the parent poster because he does a reasonable job of articulating his points. His thinking is a little rigid and absolute "this is how it must be done" for my tastes, but he at least has clue, something becoming rarer an