Given that you usually hit DNS before you get anywhere near TCP/IP, it seems like a good idea that you can actually trust DNS records. Also, many of our security features require DNS - think about things like SPF and DMARC, and emerging protocol DANE.
It turns out, as with most Internet security, that this was an afterthought.
Read on to see how you can secure your DNS resolvers against DNS cracks...
As you may have heard, DNS is subject to a number of vulnerabilities that allow crafty attackers to redirect your users (or customers) to the wrong place.
Of course, the Internet community has long been thinking about weaknesses in DNS, and they have come up with DNSSEC. In particular, it protects against DNS Spoofing, cache poisoning and the like by making it very difficult to "forge" DNS records without being caught out.
As usual with this sort of thing, it's a variant of public key cryptography, and, as you'd perhaps expect from your knowledge of PKI and DNS, it's hierarchical, starting from the root DNS servers.
You may have read my recent post about securing email, where I hinted that without secure DNS records, your other DNS-based security mechanisms are pretty much potentially pwnable. At some stage, I hope to address what you can do to make your own DNS records DNSSEC compliant.
However, this post is about your site being able to assess whether or not the "rest of the internet" is giving you the correct records. This of course involves getting your DNS resolvers (which most people just call "DNS servers", but of course there is another class of DNS server - authoritative DNS servers) to authenticate DNS records when those records are secured by DNSSEC.
Test if you already have DNSSEC recursion enabled
First of all, check whether or not your DNS servers are already "doing" DNSSEC recursion.Try one of these sites to see if they tell your DNSSEC is enabled:
If they fail, read on - if they pass, well done, you're probably secure, as are others on your LAN.
Do you block outgoing client DNS?
It's worth (if you don't already) blocking outgoing DNS requests at your border firewall (except, obviously, for your DNS resolvers...!). Force your LAN clients to use your in-house DNS servers - it's more efficient, and gives you control (not least of which you ought to trust your own servers more than others, and if you need to, you can hack records to fix things that are "broken" or not optimal [like forcing clients to use local NTP servers or preferred CDN endpoints for various services]). In particular, it allows you to know that your clients are resolving in a DNSSEC-aware manner. Your firewall logs ought to let you know what devices are trying to use 3rd party servers you don't want used - and if people have hard-coded random DNS servers into their devices, they'll soon come and see you with a device where "the internet is broken"!Enabling DNSSEC-aware recursion - Microsoft Server 2012r2
If you're not using DNSSEC aware resolvers, you should get to it!In Microsoft, it's pretty much a single PowerShell command and a few clicks away.
In PowerShell (obviously with administrative privileges) on each of your Microsoft resolving DNS servers, execute:
Dnscmd.exe /RetrieveRootTrustAnchorssay Y to the confirmation that pops up:
Are you sure you want to Retrieve and add root trust anchors (activating DNSSEC validation)? (y/n) yIt will then inform you that:
The root trust anchors were successfully retrieved and added as DS trust anchors.Note the line about needing an "active refresh".
They will become effective when the server is able to convert them to DNSKEY
trust anchors during an active refresh.
Command completed successfully.
Right click on your DNS server in the DNS management widget, and click Refresh.
 |
| Refesh your DNS servers to retrieve the trust anchors |
dnscmd /ActiveRefreshAllTrustPoints
Go to trust points and check to see they've been installed.
dnscmd /EnumTrustAnchors
dnscmd /EnumTrustPointsto do so; it should look something like:
Make sure that DNSSEC validation is enabled:
You should almost certainly check the Public Key carefully to ensure that you didn't get pwned in the process (it's very unlikely - but paranoia whilst building security architecture is, well, a good idea). This is unlikely, but IANA do publish these widely; in an ideal world, you should verify these "out of band". They also have a "get trust anchor" python tool on github. The canonical source, of course, is the Attested output of the Key Signing Ceremony, but that will only give you the digest (not the full key).
Be wary of things on the Internet, but the KSK-2010 I have, and which seems to agree with that widely available, is:
Finally, be aware that if you're pointing your in-house resolvers at someone else's, you may be breaking the "chain of trust" - think about if this is a good idea (or not) - it may possibly also break your DNS resolution in unpredictable ways if the remote server is not DNSSEC aware. Obviously, if you don't yet have root hints, you better get some (IANA)! You can also use the "Copy from Server" function, if you have a DNS server you can trust.AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 |
| No Root DNS? No Forwarders? Internet breaks. Make sure you have root hints! |
You should perhaps also considering flushing DNS Caches on your resolvers (and possibly your client).
If you want to secure your home DNS services, Google's public resolvers do DNSSEC resolution by default (since 2013) - but OpenDNS don't, in part because they're choosing a non-standard protocol for now (useful if your ISP's don't, and you don't want to run your own resolver). This is a shame, because OpenDNS FamilyShield is such a nice tool. Cue a Betamax/VHS war for more secure DNS records...
Now go and test to see if DNSSEC aware recursion is working for you (use the test links earlier in the post)! If not, re-read these instructions and/or hit The Google to work out why it may be broken.
You're typically going to find dig much more useful than nslookup (you do have a Linux box lying around, right?).
But I don't use Microsoft DNS...
Then Google the name of your DNS server software and enabling DNSSEC recursion - many help articles will show up.Here are some shortcuts for common DNS servers:
- Bind 9.x / Unbound / Microsoft (PDF - very thorough discussion)
- Unbound
- Bind
- On Ubuntu, I believe the default resolver is dnsmasq. You can persuade it to use DNSSEC, but you'd probably be better off using something with more features (Bind or Unbound). You'll need to check the manpage, enable dnssec recursion and trust anchors. This post also looks like it might be useful.
It's time!
Note that DNSSEC, like many modern security protocols, is fussy about time. If you're running a Windows domain, chances are because of Kerberos requirements, you've got (reasonably) accurate time. If not, get your machines to use accurate time - particularly your servers; it's quite useful to have logs in sync across your organisation to within a millisecond anyway!Cryptographic Keys Must Change (Periodically)
As you probably know, the longer you use a cryptographic key for, the more likely it is to get (or have been) pwned. The Root Zone Key Signing Key (which secures the entire DNSSEC architecture) will eventually be rolled over to a new one - you should be aware of this - and plan for it. If you think about it, pwning a private key that effectively secures the entire Internet DNS architecture is quite attractive to people who like to get up to no good.And they're only 1024 bits long....
You can think of this a little like a root CA in PKI (like SSL certificates) rolling over its root CA certificates from time to time; we're used to browsers and OS patches automagically fixing these things for us.
You should certainly be ready by October 2017, and by the end of March 2018, the old one (from 2010) will be gone (timeline document). RFC5011 is intended to make this easier in the long run. This is likely to happen at least every 5 years, and may be triggered earlier if a compromise comes to light.
In theory, Microsoft Windows server 2012r2 (and presumably later) support RFC5011, so it should "just work". From July 11 2017, "in band" publication of the new KSK should happen - i.e. a new trust anchor will propagate through DNS. If you want to test before that, try IANA's tool below; if not, see what happens after that date!
If you look carefully, you'll see there is a "DS Pending" status Delegation Signer - this is the pre-published KSK-2017 certificate key, ready to roll under Trust Points>.(root).
IANA provide a testbed to make sure you're ready.
Oh, wait, there's some debate here...
Reasons DNSSEC is horrible - against DNSSEC
Reasons DNSSEC is necessary - for DNSSEC, more or less rebutting the above point by point.
Until something better comes along (that is as widely supported as DNSSEC is likely to be in the near future), I'm on the side of "DNSSEC is a good thing". Certainly, deploying DNSSEC to secure your own DNS records is hard, but it's pretty easy on resolvers to check other people's DNSSEC records.
As usual, it's your network...! :)
No comments:
Post a Comment