DrDoS cyberattacks based on the DNS protocol

After the preliminary study denial of service (DoS) cyberattacks alongside any of their variants set out in the article “DrDoS: characteristics and operation”, characteristics and operation,” this new article is going to address how the DNS protocol is used as a tool to develop a DrDoS variant of a DoS cyberattack.

DNS

The domain name system (DNS), the basis of how the Internet works and, more and more, of how the intranet functions, allows users to access websites and applications by means of names that are easier to interpret without the need to know their respective IP address.

DNS servers operate in a hierarchical system in which a server, besides making iterative queries, can carry out other, recursive ones in name resolution for other domains and thus deal with the queries addressed to it, even if it is not for the domain it manages directly. On the other hand, despite the fact it supports the TCP protocol in the transport layer, it typically works with UDP, through port 53, since it is quicker.

- Figure 1. DNS operation diagram. -

Attack vector

The attack occurs when a botnet carries out massive name resolution queries on public DNS servers. In these queries, there is IP spoofing in which the source IP is replaced by the IP pf the victim machine. This is possible due to the characteristics of the UDP transport protocol. Thus, the DNS servers respond to legitimate requests, reflecting the attack and saturating the processing capacity of the victim machine given the excessive number of response packages.

On the other hand, that excessive number of packages has added to it the possible increase in their size in the event of specific queries made by the cyber attackers, which achieve the “amplifying” effect, since the victim machine has to spend more time and resources processing the packages received. The specific queries may include:

• EDNS0 queries in which the extent of the size is determined. It changes from the conventional RFC 2871 standard format to RFC 2673 or RFC 6891.
• Queries with DNS security extensions (DNSSEC) according to standard RFC 4033, in which encryption is added to the package, increasing its size.
• “ANY”-type queries according to standard RFC 2871, which cause the resolution of all he names registered in a DNS area in a single response.

These queries can be combined with each other to increase even further the size of the packages, for example, it is possible to make an “ANY”-type request according to standard RFC 6891 to obtain an expanded-size response and, moreover, require that it be encrypted with DNSSEC Thus, the data package may become between 70 and 130 times larger than the conventional DNS source package.

- Figure 2. DNS DrDoS attack diagram. -

In the event of DrDoS attacks, the DNS servers may also be affected and collapse due to the high number of queries they may receive from the botnet.

Prevention

Firstly, to verify whether a DNS is vulnerable to this type of attacks, the dig command can be used in any Linux device to make a zone request:

dig AXFR [requested zone] [DNS server to which the request is made]

If the response to this request is a list with all the domains contained in the requested area, the server would be returning a response of a much greater size to the request and it would therefore be vulnerable.

Even if an own server were vulnerable, it is possible to prevent it from being to be used to participate involuntarily in a DrDoS attack. The following measures are listed for this purpose:

• Set out an action protocol in the event of DrDoS DNS attack incidents. It is necessary to consider and set out how to act in the event of a DoS attack affecting the DNS servers themselves, adapting it to the characteristics of the organisation to provide a quick and effective response that minimises adverse effects should they arise. This procedure must set out how to identify these attacks.
• Ask the internet service provider (ISP) for anti-spoofing filters. These providers may reject DNS traffic with spoofed addresses, which are not accessible through the actual path of the package. This will prevent the own DNS server from receiving and dealing with queries that are liable to be a DrDoS.
• Deploy the DNS servers behind firewalls. The firewall must be configured with rules to detect and filter UDP-directed requests to port 53 on the DNS server and which have had the source IP addresses spoofed.
• Disable recursive requests to global DNS servers. The configuration of the DNS server, which depends upon its software, makes it possible to deactivate the recursive queries. As standard, it is possible to disable this function by modifying the “named.conf” configuration file, by modifying or adding the line “recursion no;”. In DNS servers based on Microsoft Windows, it can be done from the DNS management console, by accessing the “advanced options of the server’s properties.
• Delete A and AAAA records from the “db.root” file. This modification does not affect the operation of the DNS server, since, internally, it has a list of root DNS servers. What it does do is to prevent the server from automatically updating its list of reference name servers and the addresses of the root DNS servers. It is also recommendable to delete the references to the “.” root zone in the “named.conf” file.
• Limit the number of responses from the DNS server. Through the “rate response limit” parameter of the “named.conf” file, it is possible to limit the number of responses that can be obtained per second from the DNS server.
• Change network configuration in client machine. In all current machines, it is possible to establish more than one name resolution server, hence it is recommended that the internal DNS server be established as the principal one and a reliable public DNS server as a secondary server. This setting may be set manually or automatically by DHCP.
• Deploy intrusion detection and prevention systems (IDS/IPS). So that they monitor the connections and give an alert in the event of unusual traffic detection on DNS-associated protocols.
• Deploy systems to monitor the health of systems. To monitor isolated resource. network, processor, and RAM-intensive situations, such as signs of overloading caused by a DoS attack.
• Implement high-availability and load-balancing. To reduce the impact on the most exposed systems, it is recommendable to double the number of DNS servers and implement balancers that distribute the traffic among various servers.

Detection and evidence

The signs that an own DNS server is participating in an amplified denial-of-service attack are rooted in its activity. Intensive and unusual activity related to the UDP traffic in port 53 must set off all the alerts in this regard. The analysis of the traffic with respect to the source address of the queries that are received, the same in all the packages or with clear signs of having been falsified, confirm the participation in the reflected attack.

In the DNS server activity log, it is also possible to find traces of the incident in the event that it has gone unnoticed when the attack occurred and there are suspicions that it is occurring. The logs associated with the DNS daemon, BIND are accessible, hence you must refer to the manufacturer’s documentation to see exactly how these audit logs are stored.

Response and recommendations

If you are a victim of a distributed denial of service attack through name server amplification, or an own name server is unavailable due to its having been used as a means of amplification, it is recommended that the following actions be taken:

• Review the origin of source and destination IP addresses for packages, destination ports, and DNS query URLs. Bring together all the information deemed useful for report it to the Internet service provider to block it.
• Modify DNS settings to maintain the users’ activity. If the affected DNS server is used for internal resolutions, disconnect the server with the network from which the query flood takes place. The DNS server will thus continue to respond to the requests for other sub-networks for internal use and the only segment that will be affect is the one where the attack originates. When the affected DNS server carries out the name resolution for the exterior, the Internet, modify the DNS settings of the machines that use it as a reference so they use a secondary DNS, which may be public, always ensuring it is reliable.
• Establish contacts with the Internet or hosting provider. To report the event to it and give it the information necessary so it can apply the traffic filtering measures necessary to stop the attack.
• Obtain technical assistance. Either with the IT technical service providers they may have contracted or through the leading public computer emergency response teams (CERT), such as INCIBE-CERT.

Likewise, regardless of how it may have affected or the impact the attack may have caused, it is recommended that the authorities be informed and that an analysis of it be undertaken, so it can be investigated and prosecuted.