There’s a lot of buzz lately about DNS Security, with different vendors promoting their particular solutions as the cure for attacks such as cache poisoning, amplification for DDoS, and others. We’ll get into those in a bit, but first:
- What is DNS?
- How Does DNS work?
- How to configure and secure DNS
What is DNS?
The most common Domain Name Service/System is the Berkeley Internet Name Daemon, more currently referred to as the Berkeley Internet Name Domain, or BIND. DNS is a critical service; without it, the Internet goes down insofar as trying to browse to a web site such as google.com.
When you type google.com into your browser’s URL bar, the first thing that must happen is that your PC needs to be informed of an IP address that corresponds to that URL.
- Your PC is configured to use specific DNS servers for this task. In Windows, it’s in the NIC configuration dialogue; for Linux, it’s servers listed in /etc/resolv.conf; with Mac, it’s in the Network configuration dialogue.
- Your PC sends a query to those DNS servers, asking “what is the IP address for google.com”?
- If the DNS has the resolution for google.com in its cache, it simply replies with the result. Otherwise, it consults a root level server, which informs the DNS what server(s) to consult for the .com domain – these are Top Level Domain, or TLD, resolvers.
- The TLD server informs your DNS what DNS is authoritative for google.com.
- Your DNS queries a google.com DNS, then holding the results in its cache for a period of time specified by the Google DNS (typically 24 hours), then replying to your PC with the results.
This type of DNS resolution is, for your DNS server, called a recursive resolution, as it had to consult several external servers to get the information it needed. The root level and TLD servers performed an iterative resolution, in that they reported what they had in their databases; the google.com DNS also performed an iterative resolution. The configuration of recursion is of interest in configuring your DNS server, as we’ll discuss shortly.
Interested in setting up a DNS security consultation? Our experts are here to answer your questions.
How Does DNS Work?
Companies these days tend to use a third party, such as their domain registrar or a service such as Dyn or MarkMonitor. The biggest reason for using a third party is that contrary to 20 years ago when being a Unix or Linux admin meant intimate familiarity with all Internet Services (inetd, anyone?) DNS Administration has become something that not that many admins know how to do. Providers like those mentioned are expert not only in DNS administration but DNS security.
A typical corporate DNS setup will have at least three geographically dispersed servers, such as in DMZs in the US, another in the UK, and another in India. One is designated as primary, while the others are secondary. Secondaries sync to configuration changes on the primary automatically, using values that are contained in the primary’s SOA, or System Of Authority, record, contained in zone files. Zone files correspond to domain names: example.com would have a zone file, and subdomains such as area1.example.com are customarily designated their own zone file. Values contained in the SOA are:
- A serial number, most commonly a number tracked in a date format of YYYYMMDDXX, with XX being a two digit number that increments upward, as in 2017100101, 2017100102, etc. Secondaries look at the serial number to see if it has incremented upward since the last time it checked; this is a cue to perform a zone transfer, i.e., sync with changes made to the primary.
- A time in seconds for Refresh, instructing secondary servers how often to check the primary for updates
- A time in seconds for Retry, in case the secondary fails to contact the primary
- A time in seconds for TTL, or minimum – how long DNS throughout the world should hold resolutions from our servers in their cache before purge and lookup the next time a query asks them for an IP address from our domain
Other records types that are used to configure DNS zones:
- “A” records, Address mapping for resolution of machine name to IP address
- “CNAME” records, aliases or Canonical Names for machine names, also resulting in the resolution of an IP address
- “PTR” records, which do reverse lookups – resolving a machine name from an IP address
- “TXT” records, used to configure DNS services such as Sender Policy Framework (SPF)
- “AAAA” records for IPV.6 resolutions
- “HINFO” records for Host Information – not typically used for security reasons, such as why disclose information such as OS and CPU if it’s not needed
- “MX” records for Mail Exchangers – these servers need to have an A record too
- “NS” records for Name Servers – these also need to have an A record
Other files used by DNS are root.hints, containing a list of root-level servers to consult when looking up a resolution for domains not resolved within the DNS itself, and named.conf, which defines how the DNS operates and specifies domain names and network ranges it performs iterative resolutions for.
How to configure and secure DNS?
Chroot
The idea is to try and minimize the impact of an intruder successfully breaking in via the DNS service.If they do break in and all of named’s directory space is in a chroot (change root) “jail”, they won’t have any directory visibility outside that structure – no other executables will be seen, and no other data. Create the directory structure and list it as named’s home directory in /etc/passwd. Also, set named’s shell to /bin/false in /etc/passwd – don’t allow the possibility of an attacker having a readily available shell within which to type commands.
Limit Recursion
Ten years or so ago it became common for threat actors to induce “Amplification Attacks,” a form of DoS. The attacker would send a tiny query, such as “dig -t ANY example.com” or “dig -x 25.250.250.0”, which results in pulling entire zone files out of DNS. The attacker would spoof his source IP address as being that of an intended victim, to which the dig command results would be sent – for a TCP session they never started. Conducted by a botnet, this kind of DDoS results in a flood of traffic to the victim’s IP address(es).
But you can limit such recursive access to your DNS to only the address space you expect your users to be on, and for anyone else, only to iterative resolutions of the information in your own zones. The way to do that is to put this at the top of your named.conf file, making and using an Access Control List:
// we’ll use this one to define who can have zone transfers
acl “zone-xfer” {
!192.169.1.1/28; // denies the first 16 IPs
192.168.1/24; // allows the rest of the subnet
Localnets; // allows the subnet we’re on
};
// and we’ll use this one to define who can get recursive resolutions
acl “allowed-to-recurse” {
192.168.1/24; // an internal address space
192.168.2/24; // another internal address space
}
// now add this to your options section:
Options {
allow-transfer {“zone-xfer”};
allow-recursion {“allowed-to-recurse”};
};
It’s a simple way to ensure that you won’t be used as an attack vector for a DNS Amplification attack.
Rate Limiting
Another handy configuration method to remediate against being used in an amplification attack is a feature added to BIND in version 9.10: Resolution Rate Limiting. If the server sees a lot of requests coming from the same source IP – even if that source IP is forged – Rate Limiting allows those results to be suppressed, thus reducing the attack.
rate-limit{
responses-per-second 5;
errors-per-second 3;
window 5;
log-only false;
exempt-clients {[another_acl_name]};
max-table-size 10000;
min-table-size 1000;
}
These are configuration steps that every DNS administrator should configure into their systems. They limit what an attacker can do to weaponize your DNS. There are some other malicious uses for DNS:
- Cache Poisoning: a DNS is compromised and setup to give out the IP address of the threat actor’s choice; that IP address winds up in other DNS caches worldwide as resolutions of the URL are performed. Cache Poisoning is used to present fake web sites, requesting credentials and PII. The Great Firewall in China operates much like this, an intentional cache poisoning that redirects resolution queries for sites that the Chinese government forbids.
- Command and Control: if a user gets infected with malware or clicks a phishing link, your DNS is used to lookup the IP address of a C&C server. A typical solution for this would be IPS and/or SIEM rules, auto-updated with Threat Intelligence, to block the connection.
There’s also DNSSEC, or DNS Security Extensions, that brings cryptography and authenticated resolutions into the mix. This can go a long ways toward avoidance of cache poisoning, as the server giving an authoritative resolution must prove it’s genuine – but DNSSEC is thought by some to be too burdensome to deal with. It’s an active debate even today.
Many consider running their own DNS to be an unnecessary hassle, but there are still use cases today to consider in favor of doing so. Consider that one may have a production environment, with a maintenance window involving re-numbering of IP address space. They may desire an extremely short TTL be configured so that when DNS is changed to the new number, propagation is nearly immediate since other DNS servers won’t hold a resolution in the cache for more than, for instance, 5 seconds. This creates more network traffic to perform referrals and resolutions, but your production needs are covered. One may also wish to have the freedom to avoid administrative turnaround times that can be incurred with 3rd party providers. What’s more, providers like Dyn demonstrate that people with a grudge against them can suffer a DDoS on the DNS Service, effectively shutting down traffic to their clients – and Dyn’s clients are a gold star list.
The choice is yours! If you’d like to consult with security experts about this or any other strategic or tactical topic, contact CIPHER.
Dave Rickard is the Technical Director for CIPHER US.
.jpg)
0 Comments