How to Avoid Being a DNS Hijack Victim
There are a lot of bad guys out there, and many of them know that the Domain Name System represents both a viable attack vector and, in terms of control over a domain name, an opportunity to grab a highly valuable prize. On many networks, DNS can be a bottleneck for denial of service attacks or a single point of failure ripe for social engineering. Attackers know that if they can control or impair their target’s DNS, they achieve absolute leverage over their victim.
No organization is too big to avoid becoming the victim of an attack against their DNS or domain name, whether it be a cache poisoning attack along the lines of the Kaminsky bug, a socially engineered hijacking of name server records, or a straightforward brute-force DDoS (Distributed Denial of Service). For example, Twitter, with its 100 million users, was taken offline by a gang calling itself the Iranian Cyber Army last December, after the attackers somehow managed to take over the microblogging site’s DNS records and point twitter.com to an IP address they controlled.
Some major domain name registrars have also been subject to claims of lapses in security, with poor authentication practices allowing criminals to hijack high-profile domains. In addition, DDoS attacks against registrars’ name server infrastructures have, in recent years, caused poor performance or downtime for millions of website owners.
There are many ways DNS can be vulnerable, but there are also many ways enterprises can reinforce their DNS architecture to make it more resilient against both brute force attacks and fraud. Below, I’ve prescribed a just a few things that your organization can do to ensure that you have a better defense prepared for your DNS.
Deploy DNSSEC
DNS cache poisoning is among the most disturbing forms of network attack, undermining the very foundation of trust upon which the Internet is built. By injecting false addressing data into DNS resolvers, attackers can siphon user traffic away from legitimate websites and e-mail inboxes to their own servers. What’s worse, a well-executed cache poisoning attack would leave few clues to its existence. While the victim might notice a lack of traffic, end users would carry on believing they were reaching their intended destination, and disclose sensitive information such as passwords. The potential for criminal abuse is staggering.
Domain Name System Security Extensions (DNSSEC), the security standard for DNS, substantially mitigates the risk of successful cache poisoning attacks. The standard enables domain name owners to cryptographically sign their domains’ zones, giving resolvers the ability to validate that the DNS answers they receive come from the authoritative sources and have not been manipulated in transit.
In 2010, DNSSEC has finally arrived, after years of development. Just last week, ICANN, VeriSign, and the NTIA completed the signing of the DNS root zone. Today, anyone with a .org domain is able to start using DNSSEC through participating domain name registrars such as Go Daddy or NamesBeyond. And by early next year, enterprises may be able to sign their .com and .net zones.
DNSSEC is no longer something your organization will hear about as a “future initiative.” It is now baked into the very infrastructure of the Internet and available for you to use today to improve the security of your domain names and your interactions with customers across the Web.
Make your DNS infrastructure more resilient
Many organizations are well aware of the need to provision their website infrastructure for performance and reliability in the face of the risk of DDoS attacks. Many deploy mirror websites in multiple locations or offload some of the heavy lifting to content delivery networks. Unfortunately, the need for equally reliable DNS is sometimes overlooked, even though it is the sole mechanism by which users access Web resources and, often times, represents a single point of failure on your network.
Set a service-level agreement for your DNS resolution, even if you manage it in-house, and lower the risk of downtime by introducing more diversity into the architecture of your DNS. DNS should never be the weak link in your security chain, so reduce its exposure to DDoS attacks and zero-day vulnerability exploitation by distributing resolvers to multiple networks, on multiple power grids, using diverse hardware and software. Ensure that your DNS providers have enough capacity to withstand the largest DDoS attacks (recently >49 Gbps), and make sure you know who to call if you do come under attack.
Monitoring your DNS traffic is also vital. You cannot defend against an attack you know nothing about, so it’s crucial to implement systems or subscribe to services that send alerts when unusual DNS activity is detected. If your network does come under a DDoS attack, you’ll want to know about it as soon as possible in order to quickly work with your upstream providers to have the malicious traffic blocked or sink-holed as close to the source as possible.
Demand strong password and user role management
As Twitter discovered to its detriment, a simple username and password can be the difference between Web users seeing your site, or the site of an attacker. If a password is all that is required to access your DNS management interface, it’s advisable to have strong password management policies and to use providers that can help to enforce them. It’s better to ensure that access to your DNS management is behind IP restrictions and that you vary permissions of your user accounts so more than one person is required to suspend or remove compromised accounts.
Everybody knows that passwords should be long and diverse enough to withstand guesswork and dictionary attacks. If possible, seek providers that offer multi-factor authentication, offer one-time password tokens, and have lock-out systems in place to prevent script attacks. It should go without saying that passwords should never be stored in clear text, either in the enterprise or with your provider.
It may seem trivial, but DNS administrators should never use an e-mail address provided by a third-party webmail service such as Hotmail or GMail for their important, corporate login and contact details. These types of service are under constant attack by criminals and their integrity is beyond your control. If an attacker can take over a webmail account used in managing DNS, the domains themselves are as good as compromised.
Indeed, it is also unwise to entrust DNS management functions to a single individual. There’s nothing quite as dangerous to a company’s IT infrastructure as a disgruntled former employee with root administrator or superuser passwords. Access to your DNS management interface should be considered as important as a root password on a mission-critical server, and administrator privileges should be safeguarded accordingly.
In short, a domain name that consistently and reliably resolves to the correct address is a cornerstone of your organization’s online identity and, in many cases, revenue. While there are many ways that reliability can be compromised, it is your responsibility to treat your DNS systems as you would any other major piece of your corporate infrastructure. These tips above give you a good starting point to creat your DNS security policies and deploy best practices.
