International Defense Security & Technology Your trusted Source for News, Research and Analysis
The Domain Name System (DNS) is central to the operation of modern networks, translating human-readable domain names into machine-usable Internet Protocol (IP) addresses. Email services, chat services and even social networks rely on DNS to work 24 hours a day, 7 days a week resolving IP addresses into hostnames. DNS makes navigating to a website, sending an email, or making a secure shell connection easier, and is a key component of the Internet’s resilience. As with many Internet protocols, DNS was not built to withstand abuse from bad actors intent on causing harm.
DNS attacks
DNS is a critical attack vector. It’s often found without proper protections, outdated or completely vulnerable to many types of attacks.
Domain hijacking
One of the attacks is Domain hijacking, a type of attack that involve changes in your DNS servers and domain registrar that can direct your traffic away from the original servers to new destinations. Domain hijacking is often caused by a lot of factors related to exploiting a vulnerability in the domain name registrar’s system, but can also be achieved at the DNS level when attackers take control of your DNS records.
Once the bad guys have hijacked your domain name, it will probably be used to launch malicious activities such as setting up a fake page of payment systems like PayPal, Visa or bank institutions. Attackers will create an identical copy of the real website that records critical personal information such as email addresses, usernames, and passwords.
DNS flood attack
This is one of the most basic types of DNS attack. In this Distributed Denial of Service (DDoS), the attacker will hit your DNS servers. The main goal of this kind of DNS flood is to simply overload your server so it cannot continue serving DNS requests, because the resolution of resource records is affected by all the hosted DNS zones. This kind of attack is mitigated easily as the source often comes from one single IP. However, it can get difficult when it becomes a DDoS (Distributed Denial of Service) where hundred or thousand hosts are involved.
In October 2016, hackers used malware known as Mirai to create a botnet consisting of hundreds of thousands of Internet-connected devices. They then launched the biggest distributed denial of service (DDoS) attack to date – at times reaching a staggering 1.2 terabytes per second – against a New Hampshire-based company called Dyn, now part of Oracle Corp.
Under normal circumstances, the result would have been that Dyn’s servers would have been unreachable, and the company’s Internet-facing activities would have ground to a halt. But Dyn was responsible for a lot more than just one company’s websites. That’s because it provides managed DNS services to many of the world’s best known websites, including BBC, CNN, Comcast, and Spotify. With their DNS services blocked by the attack, these websites went dark to vast areas of North America and Europe.
The attack shows the truth of the old mantra that cybersecurity is only as strong as the weakest link in the security chain. In this case the weakest link was the DNS system, and specifically a part that was outside the control of many of the companies that were affected by the DDoS attack.
Distributed Reflection Denial of Service (DRDoS)
While a simple DDoS is the act of making any target unavailable by denying their online services with flood requests, the DRDoS is a little bit different, and often more effective. A DRDoS attack will try to send requests from its own servers, and the trick lies in spoofing the source address that will be set to that of the targeted victim, which will cause all machines to reply back and flood the target. This kind of attack often involves and is generated by botnets that run compromised systems or services that will be ultimately used to create the amplification effect and attack the target, as seen when KrebsOnSecurity was hit by DRDoS in 2016.
Cache poisoning
DNS cache poisoning, also known as DNS spoofing, is one of the most common DNS attacks that happen every day. The trick in this kind of attack is pretty easy to understand. By exploiting system vulnerabilities, attackers will try to inject malicious data into your DNS resolvers’ cache. This is an attack technique often used to redirect victims to another remote server. Once the cache poisoning attack is live and working, attackers will receive all the legitimate traffic in their own servers, that are often used to show phishing-based pages to steal personal information from visitors.
Most of the time it’s caused by vulnerable systems; opening spam emails containing malicious links can expose you to a system compromise, and ultimately get your DNS resolver cache modified to finally lead you to malicious websites — in order to steal your personal information or infect you with spyware, adware, viruses, etc.
DNS Security
Keep your resolver private and protected. If you operate your own resolver, its usage should be restricted to users on your network to help prevent its cache being poisoned by hackers outside your organization. It should not be open to external users.
Configure it to be as secure as possible against cache poisoning. Protections built into DNS software to protect against cache poisoning include adding variability to outgoing requests, to make it harder for a hacker to get a bogus response accepted. The underlying problem is one of DNS server configuration. “DNS servers tend to be forgotten about, and their default configuration is not necessarily secure,” warns Chris Brenton, a fellow of the SANS Institute and director of security at Dyn. Before looking at configuration and other changes that can be made to keep DNS secure, let’s look at some ways that DNS can be compromised.
Possible ways of doing this include:
using a random source port (instead of UDP port 53)
randomizing the query ID
randomizing the case of the letters of the domain names that are sent out to be resolved. (That’s because name servers will treat example.com and ExaMPle.com the same when it comes to resolving the IP address, but it will reply using the same case as the original query.)
Manage your DNS servers securely. When it comes to your authoritative servers, you need to decide whether to host them yourself or have them hosted at a service provider or domain registrar. “No one cares about your security as much as you do, so we advise hosting and managing yourself – if you have the skills to do so,” says Brenton. “If you don’t have those skills, then of course it is better to get someone else to do it for you. It’s not just a matter of expertise, but also of scale because many organizations need to have DNS servers in three or four places around the world.”
Don’t get caught by known vulnerabilities. If you run your own name servers (probably BIND or Microsoft DNS), then it’s vital to keep them (and the operating system on which they run) patched and up-to-date to prevent them being exploited by known vulnerabilities. A patch management system is a pretty critical security tool in general.
Another reason to keep them updated is to help prevent your name servers from being used in reflection attacks on third parties. In these types of attacks, a hacker can send DNS requests with spoofed sources to your servers, resulting in your servers responding by sending unwanted traffic to the spoofed source. Since the replies are often much larger than the original requests, the result is that the attack is amplified by going through your servers. Newer versions of DNS software use a technique called Response Rate Limiting (RRL) to prevent them from sending responses multiple times to the same spoofed source in a short period of time.
If You Use A Domain Name Registrar
If your domain name servers are managed by a registrar or other third party, it’s important to satisfy yourself that their operations and security measures are up to scratch.
Two-factor authentication. If an administrator can be social engineered or phished into giving up your DNS account details, your account may still be safe if access depends on a second authentication factor such as a security dongle or one-time password delivered to a mobile phone.
DNS change locking. Some registrars offer specific security processes that have to be carried out before changes can be made to DNS settings.
IP-dependent log in. Some registrars allow you to specify a single or range of IP addresses from which you can log in to their systems. This won’t protect against insider threats, but it can help keep you safe from external hackers.
DNSSEC. DNSSEC technology allows DNS information to be digitally signed so that a hacker can’t forge it.
Due to the centrality of DNS for cybersecurity, the Department of Defense (DoD) included DNS filtering as a requirement in its Cybersecurity Maturity Model Certification (CMMC) standard (SC.3.192). The Cybersecurity and Infrastructure Security Agency issued a memo and directive requiring U.S. government organizations to take steps to mitigate related DNS issues. Additionally, the National Security Agency has published guidance documents on defending DNS.
Protective DNS
Widely implemented DNS security enhancements – that address the integrity and authenticity of DNS records (e.g., DNS Security Extensions, or DNSSEC) or that support the privacy and integrity of client DNS queries and responses (e.g., DNS over Transport Layer Security [DoT], and DNS over HTTPS [DoH]) – do not address the trustworthiness of upstream DNS infrastructure that may be compromised or DNS registrations that may be maliciously provisioned.
“Protective DNS” (PDNS) is different from earlier security-related changes to DNS in that it is envisioned as a security service – not a protocol – that analyzes DNS queries and takes action to mitigate threats, leveraging the existing DNS protocol and architecture.
Protecting users’ DNS queries is a key defense because cyber threat actors use domain names across the network exploitation lifecycle: users frequently mistype domain names while attempting to navigate to a known-good website and unintentionally go to a malicious one instead ; threat actors lace phishing emails with malicious links ; a compromised device may seek commands from a remote command and control server ; a threat actor may exfiltrate data from a compromised device to a remote host . The domain names associated with malicious content are often known or knowable, and preventing their resolution protects individual users and the enterprise.
To address this shortcoming, PDNS uses a policy-implementing DNS resolver that returns answers based on policy criteria. This is often called Response Policy Zone (RPZ) functionality in DNS documentation. The resolver usually checks both the domain name queries and the returned IP addresses against threat intelligence, and then prevents connections to known or suspected malicious sites. PDNS can also protect a user by redirecting the requesting application to a non malicious site or returning a response that indicates no IP address was found for the domain queried. In addition, many enterprise DNS resolvers still do not validate DNSSEC or support DoH/DoT, but many PDNS providers add these DNS security enhancements as well.
A key benefit of PDNS is that it can be set up in a simple deployment just by changing an organization’s recursive resolver to use the PDNS
provider’s DNS server. More complex and secure deployments of PDNS may involve software changes on hosts. This may include lightweight
DNS clients or virtualized applications that can keep the protections working in a variety of environments and enable a faster response to incidents. Additionally, enterprises should take measures to limit the use of alternative DNS resolvers, e.g., by configuring firewalls to block unauthorized DNS ports or DoH servers. PDNS systems may also support multiple policies for different groups, users, and/or devices.
Domain classification
A core capability of PDNS is the ability to categorize domain names based on threat intelligence. PDNS services typically leverage open source, commercial, and governmental information feeds of known malicious domains. These feeds enable coverage of domain names found at numerous points of the network exploitation lifecycle. Some solutions may also detect novel malicious domains based on pattern recognition. The types of domains typically addressed by a PDNS system include the following:
Phishing: Sites known to host applications that maliciously collect personal or organizational information, including credential harvesting scams. These domains may include typosquats – or close lookalikes of common domains. PDNS can protect users from accidentally connecting to a potentially malicious link.
Malware distribution and command and control: Sites known to serve malicious content or used by threat actors to command and control malware. For example, these may include sites hosting malicious JavaScript®2 files or domains that host advertisements that collect information for undesired profiling. PDNS can block and alert on known malicious connection attempts.
Domain generation algorithms: Sites with programmatically generated domain names that are used by malware to circumvent static blocking. Advanced malware – including some botnets – depend on the ability to communicate with command and control (C2) infrastructure. Cyber threat actors use domain generation algorithms (DGAs) for malware to circumvent static blocking – either by domain name or IP – through programmatically generating domain names according to a pre-set seed. PDNS can offer protection from malware
DGAs by analyzing every domain’s textual attributes and tagging those associated with known DGA attributes, such as high entropy.
Content filtering: Sites whose content is in certain categories that are against an organization’s access policies. Although an ancillary benefit to malware protection, PDNS can use a categorization of various domains’ use cases (e.g., “gambling”) and warn or block on those that are deemed a risk for a given environment.
Response to identified domain names
A PDNS service may take several actions to respond to a malicious or suspicious domain name query. Of the protective actions, PDNS may restrict communication with a domain by returning an NXDOMAIN response, which means that there is no IP address answer for the domain name query. PDNS may also prevent the connection by redirecting to a block page, possibly offering a reason for the block to the user. It may also “sinkhole” the domain and provide a custom response. These responses delay or prevent further malicious actions – such as cryptolocking by ransomware or the use of command and control protocols – enabling an organization to conduct an investigation into a domain’s provenance or initiate follow-on infection hunting.
It should be noted that one inherent constraint of PDNS is that it is bypassed by any traffic using IP addresses directly without doing DNS lookups. For this reason, customers should not rely on it alone to detect and prevent malicious traffic. Some PDNS services may provide additional non-DNS related capabilities or integration with other security capabilities as well.
Cybersecurity best practices and PDNS
The following best practices address only the use of DNS resolver services. They do not address the management of an organization’s own authoritative DNS zone(s) and related attributes – including availability, reliability, security, and performance.
Use a PDNS provider
Select and use a PDNS system as part of a layered defense-in-depth strategy. See below for some options for these services. Additionally, due to DNS being foundational to most online activity, ensure that PDNS is provided as a high availability service. Because an organization’s PDNS provider can view their DNS queries, selecting a provider has privacy and security impacts. Obtain an understanding of how the service provider may use the organization’s generated PDNS data –especially whether the provider will use the data for any non-security purposes.
Block unauthorized DNS queries
Unless required for operations, take measures to harden internal DNS resolution to prevent bypass. These measures
should include blocking outbound port 53 (DNS) and port 853 (DoT) to thwart malware’s potential use of DNS services,
circumventing PDNS. In addition, block traffic to unauthorized DoH servers. Also, configure client applications – especially
web browsers – with enterprise policies that configure DoH solely for designated resolvers, or disable DoH entirely. See
NSA’s Adopting Encrypted DNS in Enterprise Environments for more information.
Account for hybrid enterprise architectures
Classes of users may require different PDNS policies depending on their environments, and the prevalence of mobile and home network use can create additional challenges to PDNS implementations. One PDNS policy will not often fit the entire enterprise. Ensure that the chosen PDNS solution is flexible enough to adapt to your architectural and mission requirements. Deployment flexibility is typically achieved through the provider’s implementation of a lightweight or “roaming” DNS client.
References and Resources also include:
https://media.defense.gov/2021/Mar/03/2002593055/-1/-1/0/CSI_PROTECTIVE%20DNS_UOO117652-21.PDF
https://securitytrails.com/blog/most-popular-types-dns-attacks
https://www.esecurityplanet.com/networks/how-to-prevent-dns-attacks/
