Securing infrastructure and data from DNS-based threats

DNS, or Domain Name System, is the protocol used for converting fully qualified domain names (FQDNs) like www.google.com into machine-usable IP addresses that computers use to communicate with each other. Without a working DNS protocol, it would be almost impossible to have an Internet of Things that communicate with each other and organizations would not have a cyber-presence. In short, the internet as we know it would not exist without a robust DNS infrastructure, writes Cherif Sleiman, General Manager, Middle East at Infoblox.

Given that DNS servers are mission-critical infrastructure, it is crucial that they continue to respond to queries even when they are under attack. When designing a DNS infrastructure, it is important to build an environment that is not only sufficient for current needs, but also provides room for future growth. In addition, while architecting the DNS, it is also important to understand the security threats the DNS might be vulnerable to.

Securing the DNS platform against hacking

Hacking of DNS servers is becoming more prevalent every day. Conventional DNS servers have multiple attack surfaces and extraneous ports such as port 80 and port 25 that are open for attack. Hackers can use these ports to access the operating system (OS) and hack the servers. If an enterprises’ DNS servers don’t support tiered security privileges, any user could potentially gain access to OS-level account privileges and cause configuration changes that could make the servers vulnerable to hacks.

In order to protect DNS services from various hacks, DNS servers should be secured in the following ways:

• Hardened appliance with minimal attack surface – The infrastructure should not have any extra or unused ports to access server or power external devices (e.g. Wi-Fi) and no root login access within operating system. It should have role-based access to maintain overall control
• Secured access methods – There should be two-factor authentication for secured login access, web and API access should use encryption to secure communication and DNS TSIG keys should be used for strong authentication of DNS updates
• High availability and disaster recovery – Simple, configurable fail-over and fail-back to ensure service availability
• Simple, unified updates for OS and applications – Updates for both the OS and applications should be accomplished in a single process to reduce downtime and risk of incompatibility
• Security certification by an accepted industry organisation – External validation of security measures must be taken on hardware, applications/OS, and manufacturing process. The bar should be set at a minimum of Common Criteria EAL2 certification which covers verification of hardware, software and manufacturing processes
• Simple DNSSEC implementation – DNSSEC reduces the risk of attacks like cache poisoning. It should be simple to implement and self-manage the updating of encryption keys between servers
• Secure Forwarder Configuration – Restrict queries to DNS Forwarder servers to those sent by authorized addresses
• Detailed audit logging – This enables compliance and control over server configurations and operations

Defending against DNS attacks

Another consideration is the protection of the DNS infrastructure from external attacks. Authoritative DNS servers are reachable from the internet. Even though the server sits behind a firewall, most of these attacks cannot be mitigated by typical firewalls. Firewalls are ill-prepared to protect DNS against application-layer attacks. The ones that do, the so-called NextGen firewalls, tend to have very little coverage for DNS protocols. These solutions typically spread their security policies across a large number of protocols and sacrifice depth for breadth of coverage.

There are a whole spectrum of attacks that can target DNS:

• Dos/DDoS – Send 10s or 100s of thousands of queries per second to the DNS server in order to exhause resources on the server and cause a service outage
• DNS reflection/DrDoS – Use 3rdparty DNS servers (open resolvers) to propagate DDoS attacks
• DNS amplification – Use specially crafted queries to amplify response and congest bandwidth
• DNS-based exploits – Attacks that exploit vulnerabilities in the DNS software
• TCP/UDP/ICMP floods – Flood a victim’s network on Layer 3 with large amounts of traffic
• DNS cache poisoning – Corrupt the DNS cache data with a rogue address
• Protocol anomalies – Cause the server to crash by sending malformed packets and queries
• Reconnaissance – Attempts by hackers to get information on the network before launching attacks
• DNS tunnelling – Tunnelling of another protocol through DNS for data exfiltration

Protection from these attacks should be done at the DNS level. The DNS appliance should have:

• Intelligent detection and mitigation – It should detect and drop the attack queries before they reach the core DNS server. The DNS server should not spend valuable CPU and memory resources to process these requests. This can be achieved by offloading the threat protection to built-in dedicated compute
• Automatic threat updates – It should stay up-to-date with new and evolving threats automatically. There should be no need for writing scripts or manually applying new protection rules to the DNS server every time a new threat is detected
• Fine-tuning of protection – DNS traffic patterns and attacks might not be the same for each organisation and customisation of protection is necessary to minimise false positives. It should allow for adjusting of parameters for each rule and customise them for the environment
• Centralized visibility of attacks – Centralized reporting capability is important to provide visibility into the load on the system, diagnose problems, and identify attacks that are happening across the network
• Secure Authoritative Name Servers – External authoritative name servers should have recursion disabled. Inbound/outbound zone transfers should be disabled or secured with TSIG to prevent resource exhaustion attacks

Preventing Malware and APTs from Using DNS

Data breaches are growing at a staggering pace. Investing in next-generation firewalls or Intrusion Prevention Systems (IPSs) can stop some Malware from entering the network, but not all. Trends like Bring Your Own Device (BYOD) complicate the situation further and provide new avenues for Malware to enter and go undetected for longer periods of time.

Malware and APTs evade traditional defences by using DNS to find and communicate with botnets and command-and-control servers. Botnets and command-and-control servers hide behind constantly changing combinations of domains and IP addresses. Once internal machines connect to these devices, additional malicious software is downloaded or sensitive company data is infiltrated.

Sometimes Malware and APT attacks are hidden or disguised by external attacks on networks. During an external attack, IT staff are distracted in protecting the network and might miss alerts or warning logs about Malware and APT activity within the network.

In order for DNS to detect and block queries for malicious domains and networks, a Response Policy Zone (RPZ) must be configured and implemented. At a very minimum the RPZ must have the following capabilities:

• Configurable RPZ policy – RPZ should be configured to apply either Pass-through, Block, NXDOMAIN or Substitute policies to malicious traffic
• Up-to-date threat data – The threat data should come either from Generic malware or targeted APT (though ideally, it would come from both)
• Timely visibility on malicious DNS queries and infected devices – data should include the number of attempts to reach malicious domains, the names of the malicious domains and the date/time.

Security built in is better than security bolted on

Many IT organisations today are using load-balancers, IPS and firewall devices, generic DDoS protection solutions and cloud-based solutions to try and counter DNS-based attacks. All of these solutions are limited in what they can and cannot protect. Most of them are external solutions that are “bolted on” rather than built from the ground up to secure enterprises’ DNS against attacks. None of them can compare to the effectiveness of a purpose-built, DNS-specific defence solution.