Preventing Your DNS Server From Becoming a DDoS Attack Source

A misconfigured Domain Name System (DNS) server can be used to take part in distributed denial of service (DDoS) attacks. In what is termed as a DNS amplification attack, publicly accessible DNS servers are used by cybercriminals to overwhelm a target entity’s system with DNS response traffic.

DNS amplification is a popular DDoS technique mostly because with little effort, a cybercriminal can cause such a big impact. It usually starts with the attacker sending a DNS lookup request to an open DNS server with the source address spoofed to be the target’s address. When the DNS server sends the DNS record response, it is sent instead to the targeted system. US-CERT has observed the following details regarding DNS amplification attacks:

…attackers typically submit a request for as much zone information as possible to maximize the amplification effect. The spoofed queries sent by the attacker are of the type, “ANY,” which returns all known information about a DNS zone in a single request. Because the size of the response is considerably larger than the request, the attacker is able to increase the amount of traffic directed at the victim. By leveraging a botnet to produce a large number of spoofed DNS queries, an attacker can create an immense amount of traffic[…]

 It is also important to note that since the responses are legitimate data coming from valid servers, it is very difficult to prevent this kind of attack. The best that network administrators, like you, can do is to configure your system to mitigate these attacks from happening.

Securing Your DNS Server

You need to implement your own secure DNS server instance, which serves your domain zone (example.com) data to everyone in your network. Most of the domain registrars require a zone to be served by at least two DNS servers, with IP addresses from at least two distinct /24 IPv4 prefixes.

As an example for this article, we will use the addresses 192.168.0.1 in the primary server and 192.168.1.1 in the secondary server. We will also assume that they are from a publicly reachable network. Additionally, we assume that our hosts use the primary and secondary servers as common DNS resolvers. We will then configure the BIND server (www.isc.org/downloads/bind/) daemon. Note that any other DNS server should have the same options we will be presenting below.

  1. Define the networks that should have access to the different services within your name server:
    • acl “ournet” { /* Hosts from our networks  */

192.168.0.0/23;
192.168.10.0/24;
fc00::/15;
};

    • acl “transfer” { /* Our secondary name server (primary name server configuration)  */

192.168.1.1;
fc01::1/128;
};

  1. Define the options that will allow or disable the different services based on a request sender’s source IP address:
    • allow-query { any; };  /* We allow everyone on the Internet to query our servers for names from within our domain  zones */
    • recursion yes; /*  Allow recursion in common – answering to queries for any name from any domain zone available on the Internet  */
    • allow-recursion { “ournet”; }; /*  Limit the above instruction in a way that our server would reply with useful info only to hosts from our network */
    • allow-transfer { “transfer”; }; /* Allow transferring all our domain zone info at once to our secondary server only */

With these configurations, an attacker will have to use your domain name zone in his request/s to cause an amplification effect. With the extra effort needed, an attacker will not usually bother to further his request as it is much easier to use one domain zone queries for all DNS servers.

  1. You can also implement stricter rules with your firewall. Add the following rules to your DNS server host configuration and restart your firewall:

/etc/sysconfig/iptables (for CentOS, RHEL-based Linux)

-A INPUT -m state –state NEW -m udp -p udp –dport 53 -m hashlimit –hashlimit-upto 200/second –hashlimit-burst 225 –hashlimit-mode srcip –hashlimit-srcmask 32 –hashlimit-name dnsudplimit -j ACCEPT

-A INPUT -m state –state NEW -m udp -p udp –dport 53 -m hashlimit –hashlimit-above 200/second –hashlimit-burst 225 –hashlimit-mode srcip –hashlimit-srcmask 32 –hashlimit-name dnsudplimit -j DROP

/etc/sysconfig/ip6tables (for CentOS, RHEL-based Linux)

 -A INPUT -m state –state NEW -m udp -p udp –dport 53 -m hashlimit –hashlimit-upto 200/second –hashlimit-burst 225 –hashlimit-mode srcip –hashlimit-srcmask 128 –hashlimit-name dnsudplimit -j ACCEPT

-A INPUT -m state –state NEW -m udp -p udp –dport 53 -m hashlimit –hashlimit-above 200/second –hashlimit-burst 225 –hashlimit-mode srcip –hashlimit-srcmask 128 –hashlimit-name dnsudplimit -j DROP

This will limit passing requests and outgoing responses to and from your DNS server daemon to 200 requests per second, with burst of up to 225 per second for any source address. Higher rate packets will be discarded.

Remember to periodically check the status of these firewall rules as you may drop legitimate traffic when your DNS server becomes more popular. So that the limit imposed by the abovementioned rules will not affect your machines, you can also consider adding the basic rules below prior to setting the strict firewall rules to let all incoming UDP port 53-traffic from your network pass:

 -A INPUT -m state –state NEW -m udp -p udp -s 192.168.0.0/23,192.168.10.0/24 –dport 53 -j ACCEPT

 It is a good idea to log the requests that are exceeding the rate limit:

 -A INPUT -m state –state NEW -m udp -p udp –dport 53 -m hashlimit –hashlimit-upto 200/second –hashlimit-burst 225 –hashlimit-mode srcip –hashlimit-srcmask 32 –hashlimit-name dnsudplimit -j ACCEPT

-A INPUT -m state –state NEW -m udp -p udp –dport 53 -m hashlimit –hashlimit-above 200/second –hashlimit-burst 225 –hashlimit-mode srcip –hashlimit-srcmask 32 –hashlimit-name dnsudplimit -j LOG

-A INPUT -m state –state NEW -m udp -p udp –dport 53 -m hashlimit –hashlimit-above 200/second –hashlimit-burst 225 –hashlimit-mode srcip –hashlimit-srcmask 32 –hashlimit-name dnsudplimit -j DROP

You can check if your server could be used in a DNS amplification attack at http://openresolver.com.

Attackers can use your server to attack another server so do read our article of “How to Protect Your Network from IP Spoofing” to learn on how your can further secure your network.

See our Knowledgebase for more How-To articles.

Comments are closed.