DNS Security Risks: If Your DNS is Down, Everything is Down.

In my previous blog post, I brought up a subject many of us would just as soon not think about: how easily a privileged user can totally hose your Active Directory. I described one method there (changing deny logon rights) and promised two more. Ready for the second one? Here it is: If a privileged user deletes all the DNS entries on just one of your domain controllers, it could bring your business to a standstill.

To understand how this can happen, let’s take a little tour of some not-too-distant history that admittedly feels much older.

DNS: the origin story

Back when the internet was still in its infancy — and we’re talking the 1970s here, not the Renaissance — if you wanted to visit a website, you had to know its IP address. Although computers really dig numbers (to use the appropriate slang), remembering even a single IP address like “209.191.122.70” is difficult for most mere mortals. Clearly, this was not a scalable approach as the internet grew. To help, Stanford Research Institute manually maintained a text file that mapped the cryptic IP addresses of ARPANET member organizations to human-friendly hostnames, and shared the file with those organizations.

Yeah, still not a scalable approach! So in the early 1980s, Paul Mockapetris came up with a system that automatically maps cryptic IP addresses to human-readable domain names (like www.quest.com). This Domain Name System, or DNS, is still the phonebook of the internet. The information is stored on servers distributed all around the world. Mappings you’ve used recently are also cached on your local device for fast reference.

How deleting DNS entries can hose your AD

What does this have to do with your organization’s internal operations and Active Directory security? Well, it turns out that DNS is not just for the internet: Active Directory uses DNS as its mechanism for locating domain controllers (DCs). Specifically, every Active Directory domain has a DNS domain name, and every computer has a DNS name. (Caveat: I’m assuming Windows Server 2003 or later here.)

So, to hose your Active Directory, all a privileged user has to do is delete all of the DNS entries on one DC. Those changes will soon be replicated to all the other DCs. Soon after that, their local DNS caches will time out, and suddenly nobody will be able to find anything. In particular, workstations won’t be able to find domain controllers.

This will quickly bring your business operations to a standstill: Users won’t be able to log on, and users who are already logged on won’t be able to access the resources they need to do their jobs. And you, the IT pro who gets the blame, might well be facing the same three R’s I discussed before: Reboot, Restore, and then Resign.

Don’t let this happen to you! Read our ebook: “Three ways a privileged user can hose your Active Directory” to learn about eight AD security best practices that will help you reduce the risk that privileged accounts will be misused, either deliberately or accidentally, and help ensure that you can recover quickly if those preventative measures fail. And stay tuned for my next blog post, where I’ll tell you a true story about one accidental change that brought down a company’s entire Active Directory.

Download the E-Book

Related Content