DNS Security Solutions
In today’s digital landscape, where cybersecurity threats loom large, it is crucial to fortify your online presence. DNS (Domain Name System) security is an often overlooked aspect of online security. In this blog post, we will delve into the world of DNS security solutions, exploring their significance and the measures you can take to protect your digital assets.
The Domain Name System is the backbone of the internet and is responsible for translating user-friendly domain names into IP addresses that computers can understand. However, this critical function also makes DNS vulnerable to cyberattacks. This section will discuss the potential risks and consequences of DNS attacks, highlighting the need for robust security measures.
Highlights: DNS Security Solutions
- No Security By Default
This post will outline the domain name system: the DNS structure, the vulnerabilities and abuses of DNS security designs, and guidance on implementing DNS protection with examples of DNS security solutions with Cisco, like Cisco Umbrella DNS. Unfortunately, like many Internet protocols, the DNS system was designed without security in mind and contained several security limitations regarding privacy, integrity, and authenticity.
- Constant Security Threats
These security constraints, combined with bad actors’ technological advances, make DNS servers vulnerable to a broad spectrum of attacking DNS vectors, including DNS Reflection attack, DNS tunneling, DoS (Denial of Service), or the interception of private personal information via means of data exfiltration via the DNS protocol. As you can presume, this causes the DNS layer to be an excellent avenue for bad actors to operate when penetrating networks and exfiltrating data.
For pre-information, you will find the following posts helpful:
DNS Security Cisco
Back to basics with DNS Security Solutions
The whole resolution process may be more transparent. However, it’s usually relatively fast. One of the features that speed it up considerably is caching. A nameserver processing a recursive query may have to send out several queries to find an answer. However, it discovers a lot of information about the domain namespace as it does so.
Each time it refers to another list of nameservers, it learns that those nameservers are authoritative for some zone, and it knows the addresses of those servers. At the end of the resolution process, when it finally finds the data the original querier sought, it can also store it for future reference.
Types of DNS Attacks
DNS attacks come in various forms, each with modus operandi and potential damage. From DDoS attacks that flood servers to cache poisoning that redirects users to malicious websites, understanding these attack vectors is crucial for implementing adequate security strategies. This section will shed light on some common types of DNS attacks.
DNS Security Solutions
Thankfully, several DNS security solutions are available to safeguard your online presence. This section will explore some of the most effective and widely used security measures. From implementing DNSSEC (DNS Security Extensions) to deploying firewalls and intrusion detection systems, we will discuss how these solutions can help mitigate DNS-related threats.
Best Practices for DNS Security
While deploying DNS security solutions is essential, following best practices to enhance your overall security posture is equally important. This section will outline some key best practices for DNS security, including regular patching and updates, monitoring DNS traffic, and employing multi-factor authentication. By adopting these practices, you can bolster your defenses against potential threats.
DNS Layer Security: Decentralized but not secure
The DNS protocol was developed to be decentralized and hierarchical, though not secure. Almost since its inception, there have been exploits. We must protect this critical network service. Several technologies have been implemented for DNS protection. These security technologies can be implemented with secure access service edge (SASE) products such as DNS security Cisco with the Cisco Umbrella DNS product. Cisco Umbrella DNS stops threats such as Malware before the initial connection.
DNS Protection: Are DNS inquiries encrypted?
DNS queries are not encrypted. Even if users use a DNS resolver like 184.108.40.206 that does not track their activities, DNS queries travel over the Internet in plaintext. Anyone who intercepts the query can see which websites the user is visiting. This absence of privacy impacts security significantly. If DNS queries are not private, it becomes easier for governments to censor the Internet and for bad acts to lurk on users’ online behavior unknowingly.
DNS Protection with Privacy, Integrity, and Authenticity
So, with DNS, the primary thing we care about with security is not there. In security, we care about privacy, integrity, and authenticity. However, with DNS left to its defaults, with privacy, you can see all the DNS queries in plain text. Then, for integrity, we want to know if someone has made changes between the query and response DNS stages. Finally, for authenticity, we have yet to learn if the DNS server that responded is the server we want to talk to, not some man-in-the-middle snooping and intercepting the DNS queries and forging responses, leading users to malicious websites.
These concerns have directed us to introduce technologies for DNS protection. Some DNS protection technologies include the DNS firewall, DNS as a security tool with DNS reputation and inspection, and secure the channel with DNS over TLS (DoT) and DoH (DNS over HTTPS), and security protocol implementations with DNSSEC. When implemented correctly, all of this helps restore the privacy, integrity, and authenticity security issues we have with the current implementation of the DNS protocol.
DNS Protection: Lack of DNS Security Solutions
Early days of DNS
In the early 1980s, the network was much smaller, with fewer relatively well-known and trusted participants. However, as the network scaled, DNS remained an insecure and unauthenticated protocol, even though the networks grew to have many relatively unknown and untrusted participants.
Since 1980, we have been stuck with this protocol. At that time, around a hundred hosts around the USA communicated with each other. Some of these communication protocols include FTP and SMNP. You still needed to find the IP back then, so you had to look it up in a host file. Then, if you wanted to be put into this host file, you would have to call Stanford and request it literally, and they wrote it manually for you.
Before you can scale, we need to create something to replace the host file. This was when the Domain Name System was designed. So, we have delegation with hierarchy instead of a host file that must be manually edited for new hosts.
With the Domain Name System, we have the concept of hierarchy. There is a Root at the very top, which is responsible for the IP for the servers for the TLDs, which are the .com and .org; there are thousands of them now, and they are responsible for the domains that are in them and not any other domains that not part of that TLD.
DNS protection: DNS creates blind spots
Organizations widely trust DNS. Similar to the concept of trust of public and private IP addresses, they boil down to binary numbers and have nothing to do with one being more trustworthy. Except there is the excessive trust placed on private IP ranges.
DNS traffic is typically permitted to pass freely through network firewalls and other security infrastructure. However, it is attacked and abused by bad actors with malicious intent. Because of this, DNS traffic can be manipulated through techniques such as DNS tunneling and DNS poisoning. All of which create blind spots in your security posture.
The issue with UDP
Let us start with the basics; clients can ask for DNS if they want to connect to an address such as ‘www.network-insight.com’ and need to know which IP address corresponds to it. Typically, all DNS messages are sent over UDP. This is where the problems start.
The first issue is that UDP is a stateless protocol and that source IP addresses are blindly trusted, similar to how everyone would trust a private IP address over a public one. Therefore, each request and response described here is a single UDP request containing to and from IP addresses.
Any host can forge the source address on a UDP message, making it look like it came from the expected source. Therefore, a bad actor sitting on a network that does not filter outbound packets can construct a UDP message that says it’s from the authoritative server and send it to the recursive resolver.
DNS Security Cisco with DNS Security Solutions:
Neglected attack surface
Today’s bad actors use DNS’s often neglected attack surface – to steal data, spread malware, perform data exfiltration, command, and control network surveillance, along with the capabilities to perform social engineering.
DNS is a bi-directional and Internet-facing protocol that carries a tremendous amount of data, making it an adversary’s most excellent tool for carrying out attacks and causing damage. In addition, the combination of security teams failing to secure their DNS traffic and the ubiquity of DNS makes it a bad actor’s most potent yet unforgotten tool.
While they have solutions that inspect and secure areas like their network with a stateful firewall and web traffic with Secure Web Gateways (SWG) and even some of the newer zero trust technologies, these solutions cannot perform a deep inspection of their DNS traffic, leaving them vulnerable to the many threats today that abuse DNS. This is because they are not designed to inspect DNS traffic. As a result, techniques such as DNS tunneling should be noticed.
In most instances, DNS packets – typically including IP address information – enter networks via unblocked ports without first being inspected by security systems. So, again, DNS activity in a network is rarely monitored. This makes the DNS layer the perfect blind spot for bad actors to manipulate.
Many of today’s sophisticated attacks depend on DNS activity. In addition, there is a rise in Malware; ransomware binaries, once executed, are quick to encrypt, and you can’t trust that your employee won’t click on a phishing email. As a result, there needs to be more trust, and complexity is high.
Bad actors use this and manipulate DNS to stage the internet infrastructure to fully support each attack stage to execute their kill chain. In many of today’s more sophisticated ransomware attacks, for example, bad actors will use DNS packets to upload Malware to a device.
Introduction to attacking DNS
The vulnerability and abuses of this protocol are comprehensive, and there are several methods of attacking DNS. We have, for example, DNS poisoning, denial of service, spoofing/hijacking, and DNS tunneling.
Unless you have DNS-layer security, the DNS packets typically used to communicate IP addresses will only be inspected as they move through your network. Additionally, most security solutions don’t even register anomalous DNS activity – like DNS tunneling- a sure sign of an in-progress attack. DNS tunneling uses the DNS protocol to communicate non-DNS traffic over port 53. It sends HTTP(s) and additional protocol traffic over DNS.
DNS tunneling establishes DNS tunnels between their servers and victims’ machines. This connection between attacker and victim allows for the exfiltration of sensitive data and the execution of command and control operations.
DNS Poisoning, or DNS cache poisoning, is where forged DNS data is submitted into a DNS resolver’s cache. This results in the resolver returning an incorrect IP address for a domain. Therefore, rather than going to the indented website unknown to the user, their traffic can be redirected to a malicious machine. More often, this will be a replica of the original site used for malicious purposes, such as distributing Malware or collecting login information.
DNS poisoning was first uncovered in 1998. Where a recursive server sends a query out to the Root. As we are using UDP, there is no connection, and the only thing back then to identify the query as it came back as a response was simply a Query ID. That was a little short. Now, there was the possibility to trick a DNS recursive resolver into storing incorrect DNS records. Once the nameserver has stored the wrong response, it will return it to anyone who asks.
This “DNS poisoning” attack could allow random attackers to deceive DNS and redirect web browsers to false servers, permitting them to hijack traffic. Furthermore, the incorrect stored entry will remain until the cache entry expires, down to the TTL, which could lead to weeks of compromise.
So if you brute force the server with forged responses for a domain and tried to brute force the Query ID that was not very long back then, you could eventually guess it and insert your response into that recursive server cache.
And if you set the TTL for a low time, such as a week, then everyone that queries that recursive server will get your chosen IP address for this domain name. Today, there have been changes to mitigate DNS poisoning. They have made the Query string very long and hard to guess, so it is hard to do, but it can still happen.
Then we have DNS Spoofing, or hijacking is very easy to do and difficult to detect. For example, let’s say you type the incurred domain name. So you try to go somewhere that does not exist and are returned to a search page with many ads. This is the ISP that is hijacking NX domain responses. So when you try to query for a name that does not exist, your ISP sees this, crafts its response, and sends you to a search page to sell you ads. This commonly happens on public Wi-Fi networks.
So, we have similar DNS spoofing and DNS poisoning attacks, but they have distinguishable characteristics. Both DNS attacks attempt to trick users into revealing sensitive data and could result in a targeted user installing malicious software that can be used later in the kill chain. Poisoning DNS cache changes entries on DNS resolvers or servers where IP addresses are stored.
DNS Amplification Attack (DNS Flood)
Then, we have the DNS amplification style of DNS attack. They are also known as DNS floods. A bad actor exploits vulnerabilities to initially turn small queries into much larger payloads, which are used to bring down the victim’s hosts.
So, we know that DNS uses UDP for transport, meaning a bad actor can spoof the source address of a DNS request and send the response to any IP address of their choosing. In this case, they can amplify DDoS attacks using DNS responses larger than the initial query packet. For example, fake DNS lookups to open recursive servers can achieve a 25x to 40x amplification factor. This is because the source IP of the bogus lookups is the victim’s website, which becomes overwhelming.
DNS Flood Attack
DNS flood targets one or more DNS servers belonging to a given zone, attempting to impede the resolution of resource records of that zone and its sub-zones. This attack overwhelms the network capacity that connects authoritative servers to the Internet.
Once the bandwidth becomes depleted with malicious traffic, the legitimate traffic carrying DNS queries from legitimate sources cannot contact the authoritative servers. DNS flood attacks vary from DNS amplification attacks. Unlike DNS floods, DNS amplification attacks reflect and amplify traffic off unsecured DNS servers to hide the attack’s origin and increase its effectiveness.
Random Subdomain Attack
Random Subdomain DDoS attacks are becoming popular in recent attacks, such as in the Mirai attack on Dyn. In these DNS attacks, many queries are sent for a single or a few target domains, yet they include highly varying nonexistent subdomains generated randomly.
This denial of service attack hits a domain’s authoritative name servers with multiple requests for random, nonexistent subdomains. The name servers become bogged down when replying to these phony requests and need help to respond to legitimate queries. These attacks are also called NXDomain attacks; they can result in denial of service at the recursive resolver level.
Then, we have DNS tunneling, which we briefly mentioned. DNS tunneling is frequently used to deliver payloads encoded in DNS queries and responses, exfiltrate data, and execute command and control attacks as the attackers use SSH, TCP, or HTTP to pass, for example, Malware or stolen information into DNS queries undetected.
This allows the bad actor to exfiltrate sensitive data in small chunks within DNS requests to bypass security. With the amount of DNS traffic and requests a network typically sees, attackers can hide data theft easily.
The bad actor can use standard protocols like TCP or SSH, encoded within DNS protocol requests. At the same time, it is not an attack on DNS. This form of malicious activity can use DNS to exfiltrate data.
DNS Security Cisco
Cisco Umbrella DNS: The DNS Firewall
There are several ways these attacks can be prevented. Firstly, the DNS firewall enables DNS layer security. DNS-layer security effectively prevents malicious activity at the earliest possible point and, in the case of Malware, contains callbacks to attackers. DNS security solutions can be accomplished with products such as Cisco Umbrella DNS.
DNS Security Cisco with DNS-layer security
Cisco Umbrella DNS uses DNS-layer security encompassing the Internet’s infrastructure to block malicious and unwanted domains before a connection is established as part of recursive DNS resolution. In addition, it utilizes a technology known as selective cloud provide that redirects specific requests noted as risky for a deeper and more thorough inspection.
Cisco Umbrella DNS accomplishes this process transparently through the DNS response without adding latency or degrading performance. Just as a standard firewall watches incoming and outgoing web traffic and blocks unsafe connections, a DNS firewall works the same way. The distinction is that DNS firewalls analyze and filter queries based on threat feeds and threat intelligence. There are two kinds of DNS Firewalls: those for recursive servers and those for authoritative servers.
A DNS firewall provides several security services for DNS servers. A DNS firewall sits between a user’s recursive resolver and the authoritative nameserver of the website or service they are trying to reach. This can help with reputation filtering and domain reputation.
Cisco Umbrella DNS: Secure the channel
We have DNS over TLS and DNS over HTTPS, two standards for encrypting DNS queries to prevent external parties from being able to read them. DNS over TLS (DoT) and DoH (DNS over HTTPS) add a secure layer to an insecure protocol. By using DoH and DoT, users can ensure the privacy of DNS responses and block eavesdropping on their DNS requests (which reveals the sites they are visiting).
Cisco Umbrella DNS: Secure the protocol
Application layers use security protocols such as HTTPS, DMARC, etc. So, the DNS protocol should be no exception. DNS Security Extensions (DNSSEC) is a security protocol that defends against attacks by digitally signing data to help guarantee its validity. The signing must happen at every level in the DNS lookup process. That can make it a complicated setup.
DNSSEC was one of the first things we started implementing, which is much older than many assume. The first talks about DNSEEC were in the early 1990s. It is a way to ensure that you know that a record you get back has not been tampered with and that the server you are talking to is the server you intend to talk to. All of this is done with PKI.
Public Key Infrastructure (PKI)
The server has a public and private key pair. So we have the public key, and they can sign the record. However, as we maintain a distributed hierarchy in DNS, we must guarantee that these are signed up to the Root. DNSSEC implements a hierarchical digital signing policy across all layers of DNS.
For example, in the case of a ‘google.com’ lookup, a root DNS server would sign a key for the.COM nameserver, and the.COM nameserver would then sign a key for google.com’s authoritative nameserver. DNSSEC not only allows a DNS server to verify the authenticity of the records it returns. It furthermore enables the assertion of the “non-existence of records.”
DNS resolvers can also be configured to provide security solutions. For example, some DNS resolvers provide content filtering, which can stop sites known to distribute Malware and spam, and botnet protection, which blocks communication with known botnets. Many of these secure DNS resolvers are free to use.