Random and phantom domains (random subdomain, phantom domain), DDoS attack on caching DNS

Since January, many providers in the Russian Federation have undergone / undergoes attacks on the DNS infrastructure, in addition to the Amplification / Reflection attacks, the Random subdomain / Phantom Domain attack (attack by random or phantom domains) was actively used / used. Information on the attacks was received by me from several providers in the European part of Russia and in western Siberia (large regional and Moscow providers). In this case, someone just confirmed the existence of such problems, and someone provided recorded traffic to the DNS server for analysis (below I will tell you how the analysis was performed). About Amplification / Reflection attacks is written quite a lot, so we will only focus on the attack of random / phantom domains.

Random and phantom domains

The essence of the attack lies in the fact that the caching DNS server receives a large number of requests for domains of the third and / or fourth level, while the DNS servers that serve the second level zone do not respond or respond with a long delay. Both specially prepared DNS zones / servers can be used, as well as DNS servers under attack by NXDOMAIN, in which case our caching DNS is also involved in the attack. By default, bind is configured with the maximum number of outgoing recursive requests: 1000 (recursive-clients parameter) and a wait time of 10 seconds (resolver-query-timeout parameter). Thus, only a constant load of 100 requests per second to such domains will allow you to completely block outgoing connections of the DNS server, which will lead to obsolescence of the cache and partial denial of service. Increasing the number of requests can completely block the operation of a caching DNS.

On the networks of providers, this attack was carried out using the following second-level domains:

• ludashi123.com, ludashi12345.com, ludashi258.com, ludashi360.com, ludashi456.com, ludashi789.com;
• 8333hh.com, 8777hh.com, 9111hh.com, 9222hh.com, 9333hh.com, 9555hh.com, 9666hh.com, 9777hh.com, 9888hh.com;
• 115seo.com.

Here are some examples of queries to these domains:

• cvrwuco.www.9555hh.com;
• fqtwikq.www.9666hh.com;
• epwvczehmdmxepwx.www.9777hh.com;
• yrad.list.115seo.co;
• xnhrw.www.ludashi789.com;
• g.www.ludashi456.com.

')

How to diagnose

There are several possibilities, both direct and indirect, to analyze and determine that your DNS server has been attacked:

• The simplest and most incorrect is to rely on users and wait until they identify a problem (although some users may disconnect;
• An indirect sign of poor DNS performance is a decrease in user traffic;
• The monitoring system can track the correctness of the conversion of the most popular DNS names with a minimum TTL. For example, the TTL for an A-record www.facebook.com is only 60 seconds;
• Analyze log files and DNS statistics;
• Periodically record traffic to / from the DNS server and analyze requests / responses (in automatic mode);
• Use automatic DNS server security systems.

The most correct and simple (if we do not have DNS security systems) is the analysis of log files. Using bind as an example, consider messages that may be useful in the analysis.

client 192.168.XY.137 # 57717 (lie.zz85.com): query: lie.zz85.com IN A + (192.168.XY.139)
client 192.168.XY.137 # 57717 (lie.zz85.com): query failed (SERVFAIL) for lie.zz85.com/IN/A at query.c: 7553
client 192.168.XY.11 # 1567: no more recursive clients: quota reached

The listing above shows 3 types of useful events:

• the record "client 192.168.XY.137 # 57717 (lie.zz85.com): query: lie.zz85.com IN A + (192.168.XY.139)" tells us which user (192.168.XY.137) and with which port (57717) requested lie.zz85.com domain;
• the entry "client 192.168.XY.137 # 57717 (lie.zz85.com): query failed (SERVFAIL) for lie.zz85.com/IN/A at query.c: 7553" reports that the DNS server could not resolve the DNS -name and transferred to the client SERVFAIL;
• the entry “client 192.168.XY.11 # 1567: no more recursive clients: quota reached” reports that user 192.168.XY.11 was denied access because the server had reached the maximum possible number of recursive sessions. That is, the attack has reached a result, and your DNS has ceased to serve legitimate clients.

If there is recorded traffic, additional information on attacks can be obtained using the Statistics / DNS tool in Wireshark (rcode / Server Failure parameters, Query Type / Unknow packet type and Class / Unknown).

I analyzed the recorded traffic on the Infoblox Advanced DNS Protection device (DNS protection against attacks was implemented) and DNS Firewall (checking DNS queries against the list of malicious sites and IP addresses). Checking traffic was quite simple using tcprewrite and tcpreplay, packets were sent to the Infoblox device. For a similar check in one case, it took only 13 seconds (at a load of about 30 thousand DNS requests per second). In addition to attacks based on random and phantom domains, there were recorded: amplification, protocol anomalies (see above about Wireshark), TCP / UDP flood, attempts to cache poisoning (perhaps, the traffic was not completely cleared) and DNS tunnels.

Additionally, it was discovered:

• Clients who attacked DNS also accessed malicious domains / IPs recorded in the DNS Firewall;
• attacking requests came from a small number of ports. Just as in my open recursive server (in previous articles on outgoing ports there is no analysis).

Anti-Attack Techniques

The following methods can be offered to counter attack with random / phantom domains:

• increase the maximum number of recursive sessions - it will help only if a very low value is now set and there is enough memory on the server (the bind for each recursive session uses about 20K of memory);
• setting parameters for tracking and blocking non-responding domains at the DNS level (for bind: clients-per-query, max-clients-per-query) - will help only if some of the domains / queries are repeated;
• set up a response rate limit - will help with a large number of requests from multiple addresses;
• cut off attacking requests to the firewall, either by domain name (iptables can do this), or by a pair of IP address / port;
• create RPZ or direct zones in which to enter second-level domains;
• use specialized AO or software to automatically repel attacks.

PS As long as I have access to the Infoblox ADP test equipment. If you record and give me traffic, I will be able to drive him away for attacks. You can test the traffic for access to malicious sites (DNS Firewall) yourself (by connecting the device to the span port or by driving out the recorded traffic). You can download the DNS Firewall package here (registration is required; it is installed on VmWare ESXi and vCenter is required).