DNS Security Solutions
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 DNS security Cisco such as Cisco Umbrella DNS. Like many Internet protocols, the DNS system was designed without security in mind and contained several security limitations regarding privacy, integrity and authenticity. 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 an excellent avenue for bad actors to operate when penetrating networks and exfiltrating data.
DNS Security Cisco
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 188.8.131.52 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 greatly. If DNS queries are not private, it becomes easier for governments to censor the Internet and for bad acts to lurk on users’ online behaviour 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 are interested 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 actual 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 help 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 until now. At that time, around a hundred hosts around the USA communicated with each other. Some of these communication protocols include FTP and SMNP. Back then, you still needed to find the IP, 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. And this was when the Domain Name System was created. So we have delegation with hierarchy instead of a host file that needed to 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 than the other. Except there is 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 abused 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. 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 greatest tool for carrying out attacks and causing damage. The combination of security teams failing to secure their DNS traffic and the ubiquity of DNS makes it a bad actor’s most powerful 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. They are not designed to inspect DNS traffic. As result, techniques such as DNS tunneling go unnoticed.
In most instances, DNS packets – typically including IP address information – enter networks via unblocked ports without first being inspected by security systems. Again, DNS activity in a network is rarely monitored. This makes the DNS layer the flawless 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 is little trust, and complexity is high. Bad actors take advantage of 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 tunnelling.
Unless you have DNS-layer security, the DNS packets typically used to communicate IP addresses won’t even be inspected as they move through your network. Additionally, most security solutions don’t even register anomalous DNS activity – like DNS tunneling, which is 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, also known as 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 than, 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 incorrect response, it will return it to anyone who asks.
This so-called “DNS poisoning” attack could allow random attackers to deceive DNS and redirect web browsers to false servers, permitting them to hijack traffic. 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 you 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 wifi networks.
So we have similar DNS spoofing and DNS poisoning attacks, but they have distinguishable characteristics from one another. Both of these 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. Also known as DNS flood. A bad actor exploits vulnerabilities to originally 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. The source IP of the fake 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 phoney requests and cannot respond to legitimate queries. These attacks are also referred to as 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, 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
So 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, prevents 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 that encompasses 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 that are 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 normal 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, 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 very first things we started to implement, and it is a lot 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 allows 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 secured DNS resolvers are free to use.