SoylentNews is people
SoylentNews
Sysadmins are making mistakes configuring and managing DNSSec, and it's leaving systems that should be secure open to exploitation in DNS reflection attacks.
That's the conclusion of Neustar, in a study released here and which found that of more than 1,300 DNSSec-protected domains tested 80 per cent could be used in an attack.
The domains in question had DNSSec deployed, and also responded to the DNS “ANY” query. The ANY request asks the responder to provide all information about a domain – the MX (mail server) records, IP addresses, and so on. An ANY request therefore returns a lot more information than a simple request for the domain's IP address.
[...] Neustar reckons on average, the poorly-configured DNSSec servers could amplify an attacker's traffic by 28.9 times; they turned an 80 byte query into a 2,313 response; and the biggest response they received from one of the protected servers was 17,377 bytes, 217 times the size of the query.
Unfortunately, all of this isn't a bug, it's a feature: even with DNSSec, the purpose of the system is to answer queries – so it's not a matter of applying a patch; it's about taking care of systems.
(Score: 3, Informative) by NCommander on Thursday August 18 2016, @07:25PM
This is a "new" variation on a very old attack. DNS has always been vulnerable to reflection attacks and anytime you have a large record on a server anywhere, you can forge a UDP packet, and get it to blast another server without too much pain. Even without DNSSEC, having open AXFR (which happens) can do pretty much the same thing. Any protocol that's UDP based is vulnerable to this type of attack; I believe STUN is for instance. DNSSEC makes the problem somewhat worse because the amount of data generated for a single packet is much much higher than most other protocols. I first remember hearing about abusing DNSSEC like this nearly ten years ago when it was still being drafted and worked on.
A lot of the problem is ISPs generally don't filter bogus outbound UDP traffic. If I'm sending a bogus UDP packet from my network that couldn't orientate from my network, it should be dropped, not sent on its merry way.
Still always moving
(Score: 2) by gnampff on Thursday August 18 2016, @08:22PM
So assuming that the outbound filtering will never be a thing for the whole net, what would the downside(s) of having a DNS2 based on a TCP connection be?
With my limited network admin knowledge I cannot think of any except maybe some keepalive spam.
Although I cannot see much use in the ANY query that is causing the problem either. I usually want information about a specific service after all.
(Score: 2) by Fnord666 on Thursday August 18 2016, @09:02PM
So assuming that the outbound filtering will never be a thing for the whole net, what would the downside(s) of having a DNS2 based on a TCP connection be?
The overhead of setting up a full TCP connection is a lot for what are otherwise very lightweight protocols. It also consumes a lot of resources on the server waiting to see if someone is going to reuse the socket, etc.
(Score: 2) by maxwell demon on Friday August 19 2016, @05:08PM
What about having a data size limit for UDP responses, and if the response would be larger, send a "retry by TCP" error message instead?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Thursday August 18 2016, @09:15PM
There is no technical reason that DNS couldn't use either TCP or UDP. In fact, my local router supports either. However, UDP is much lower overhead than TCP in that it requires one datagram for a request and one for the response. With TCP, you have the opening handshake (3) the request/response (2) and the closing handshake (4), and rather than generating a response and then dropping it, the server has to hold resources for the entire handshake or the requisite time out occurs. Until DNS responses or requests get large enough to require multiple packets, it just won't be worth it, especially in our speed-obsessed Internet. Just look how they are cutting steps out of the TLS handshake to make everything faster and then ask yourself if they are really going to add time for the extra steps in DNS lookup .
(Score: 3, Informative) by NCommander on Thursday August 18 2016, @10:13PM
DNS already supports TCP based connections, specifically for things like zone transfer. Its just a little hit or miss on router support but I've seen both Windows and Linux do it. The major headache is TCP connections have a very long setup and teardown time (maybe 100-200 ms under ideal conditions), plus additional latency since its a positive acknowledgement system.
Theoretically, this attack could be mitigated by simply refusing to serve DNSSEC records over UDP. DNSSEC (by design) doesn't protect the last mile, your computer isn't asking for RRSIG records, it trusts its resolvers are validating and checking that info on its behalf.
Ultimately, the problem is not with DNS, its the fact that you can use UDP to mount a reflection attack trivially if you have raw socket access to forge headers. Windows blissfully didn't have SOCK_RAW out of the box for many many years until Windows 2000, and then removed it in XP SP 2 which makes it harder for botnets to spoof UDP traffic without installing a NDIS driver which is much much harder to do.
Still always moving
(Score: 0) by Anonymous Coward on Friday August 19 2016, @12:20AM
On top of that. If you are running a DNS server you should only serve your site. Letting others reflect off you may seem like a 'nice thing to do' but in the end just helps people who want to do nefarious things. Unfortunately its not the early 90s anymore :(. So the rule of thumb is if you are setting up a DNS server make sure reflection is on your side of the firewall. Then be sure you really want to do it. I set it up in my local network that way because I want caching and proxy server stuff. Having a local DNS server that caches helps speed things up decently.
(Score: 3, Informative) by NotSanguine on Friday August 19 2016, @12:39AM
On top of that. If you are running a DNS server you should only serve your site.
This assumes that you are not authoritative for a DNS domain. If your DNS server is authoritative for a zone that's exposed to the Internet, not allowing queries will certainly bock any reflection attacks using your DNS server, but it will also have the added beneficial effect of making the servers in your domain unresolvable. Good times!
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0) by Anonymous Coward on Friday August 19 2016, @03:03AM
If the connection is TCP, serve up the data.
Else, if the data is smallish important stuff, serve up the data.
Else, if the amplification factor would be low (the request is large, possibly padded to make it large), serve up the data.
Else, if polite rejection would not amplify much, send a polite rejection.
Else, rudely ignore the request.