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

        Since January, many providers in the Russian Federation have undergone / are undergoing 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. 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). At the same time, someone simply confirmed the existence of such problems, and someone provided the recorded traffic to the DNS server for analysis (below I will talk about how the analysis was performed). A lot has been written about Amplification / Reflection attacks, so we will focus only on attack with random / phantom domains.

    Random and Phantom Domains

        The essence of the attack is 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 and DNS servers under attack by NXDOMAIN can be used, in which case our caching DNS is also involved in the attack. By default, bind is configured with the maximum number of outgoing recursive queries: 1000 (recursive-clients parameter) and 10 seconds wait time (resolver-query-timeout parameter). Thus, only a constant load of 100 requests per second to such domains will completely block outgoing DNS server connections, which will lead to cache obsolescence and a partial denial of service.

        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 sample queries for 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 wrong thing is to rely on users and wait until they identify the problem (although some users may disconnect;
    • An indirect sign of poor DNS performance is reduced user traffic;
    • The monitoring system can track the correct translation 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 protection systems.

        The most correct and simple (if we do not have DNS protection systems) is the analysis of log files. Using bind as an example, consider messages that may be useful in 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 entry "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) the lie.zz85.com domain requested;
    • the record "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 DNS -Name and passed to the client SERVFAIL;
    • the entry “client 192.168.XY.11 # 1567: no more recursive clients: quota reached” reports that the user 192.168.XY.11 was denied access because the server reached the maximum possible number of recursive sessions. That is, the attack has achieved 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, Query Type / Unknow packet type and Class / Unknown parameters).

        I conducted an analysis of the recorded traffic on the Infoblox Advanced DNS Protection device (implemented the DNS protection against attacks functionality) and DNS Firewall (checking DNS queries against a list of malicious sites and IP addresses). Checking traffic was carried out quite simply using tcprewrite and tcpreplay, packets were sent to the Infoblox device. For such a check in one case, only 13 seconds were enough (with a load of about 30 thousand DNS queries per second). In addition to attacks based on random and phantom domains, there were recorded: amplification, protocol anomalies (see Wireshark above), TCP / UDP flood, cache poisoning attempts (traffic may not have been completely cleaned), and DNS tunnels.

        Additionally, it was discovered:
    • clients that attacked DNS also accessed malicious domains / IPs recorded in the DNS Firewall;
    • attacking requests came from a small number of ports. Same as on my open recursive server (in previous articles there is no analysis on outgoing ports).

    Attack Countermeasures

         You can suggest the following methods to counter attack with random / phantom domains:
    • increase the maximum number of recursive sessions - it will help only if the value is now very low and there is enough memory on the server (bind uses about 20KB of memory for each recursive session);
    • set the parameters for monitoring and blocking non-responding domains at the DNS level (for bind: clients-per-query, max-clients-per-query) - only helps if part of the domains / requests is repeated;
    • configure response rate limit - will help with a large number of requests from multiple addresses;
    • to cut off attack requests to the firewall, either by the domain name (iptables can do this) or by the IP address / port pair;
    • create RPZ or direct zones into which to enter the second level domains;
    • Use specialized AO or software to automatically repel attacks.

    PS So far I have access to the test equipment Infoblox ADP. If you record and provide me with traffic, then I can drive it 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 running the recorded traffic). You can download the DNS Firewall package here (registration required; installed on VmWare ESXi and vCenter required).

    Also popular now: