Open recursive DNS server. Part 2



    Almost 4 months ago I opened my recursive DNS server for all Internet users (see the previous article ). The accumulated amount of data at the first stage of the test was large enough, for its visualization I drove the data into the database and built dynamic changing graphs and a map. The recorded video can be viewed under the cut. The result was quite interesting, so I did not completely close the DNS server, but limited myself to including zones (used for attacks) in RPZ lists (what RPZ can be found in this article) Having “relaxed” on “small” attacks (no more than 100 requests per second), I did not block the answers in the two DNS zones and received the first abuse report. The Abuse report was sent to the data center of my provider from the "robot". The load on his network from my server was small and periodically reached 100 requests per second. Given that millions of open resolvers could be used, the maximum load on his network could be significant. Abuse-report and motivated me to go to the second part of the test. Disabling open recursive DNS and continued to monitor the behavior of attackers.

    Visualization of the attack described in the first article :



    Description of the test environment

    When writing the last article, all data was collected and processed almost manually. It was long, tedious, and sometimes the results had to be double-checked. Since I’m quite lazy, I like to automate processes and analyze data, I was prompted by the conclusion to create a small system for reporting and analyzing incoming logs from a DNS server in a mode close to real time (if it’s interesting, I can describe it in a separate article). All graphs and tables used in this article were generated using jqPlot, jqGrid and the Google Maps service. I use the Infoblox virtual device as the DNS server, but its syslog message format is similar to bind.

    Attacks

    During testing, my server was used to conduct DrDoS attacks (Amplification + Reflection), and attempts were also made to poison the cache. For some requests, it was clear that the DGA (Domain Generation Algorithm) mechanism was used, possibly for cache poisoning, possibly for communication with control centers (since these domains were used only for attacks) or for attacks with phantom domains.

    After turning off the recursive server, the parasitic load decreased, but did not disappear at all.

    Peak load on an “open” server reached 3 thousand requests per second and kept on average about 100 requests per second, on a closed server the maximum load decreased to 20 requests per second with rare peaks up to 100 requests (rate limit configured to 300 requests per minute with the possibility of growth up to 1000).



    As you can see in the graph below, companies in the United States suffered most from the actions of attackers.



    An analysis of the number of requests sent to each company’s network can indirectly help identify victims and possible infected networks. For example, the China Telecom network is likely to be infected, and the client of Rostelecom was attacked. The table below shows information for organizations, the number of IP addresses and the number of requests processed. Company data was obtained using the whois service.

    The countryCompanyNumber of requestsNumber of IP
    United statesSoftLayer Technologies Inc.396520236
    United statesSingleHop, Inc.261798727
    United statesPSINet, Inc.199446122
    FranceOVH SAS1051080304
    United kingdomHosting Services Inc9383674
    Germany1 & 1 Internet AG76102012
    United statesPrivateSystems Networks7486414
    Russian FederationOJSC Rostelecom Ticket 09-39331, RISS 15440, UrF6870281
    United statesTime Warner Cable Internet LLC6712111568
    CanadaOVH Hosting, Inc.592920213
    United statesAkamai Technologies, Inc.1763274410
    ChinaChina Telecom51565207
    United statesAT&T Internet Services 27502854


    DrDOS attack

    For the attack, the domains listed in the table below were used. The domain freeinfosys.com appeared after the "closure" of the recursive server. Which may mean that someone uses outdated databases that are rarely checked.
        To determine that your server is being attacked or used to carry out attacks, it is enough to analyze which domains and how often the request “ANY + E” was addressed.

    DomainInquiry FlagNumber of requests
    webpanel.skANY+ E14962032
    oggr.ruANY+ E8300693
    energystar.govANY+ E6676350
    doleta.govANY+ E6326853
    067.czANY+ E2463053
    sema.czANY+ E1251206
    GUESSINFOSYS.COMANY+ E690320
    jerusalem.netfirms.comANY+ E587534
    paypal.deANY+ E454756
    nlhosting.nlANY+ E414113
    freeinfosys.comANY+ E352233
    krasti.usANY+ E333806
    doc.govANY+ E259248
    svist21.czANY+ E231946
    wradish.comANY+ E117294


    When using “ANY + E”, all information on the zone is requested and the EDNS functionality is activated in order to obtain the maximum possible UDP packet size. A list of the 10 most common queries and their flags is shown in the table below.

    InquiryFlagsNumber of requests
    ANY+ E43500439
    A-ED17339
    ANY+11932
    A-9853
    A-EDC8956
    AAAA-EDC4749
    AAAA-ED4467
    ANY-2289
    A+ E1899
    Rrsig+ E1124


    Cache Poisoning, Random domain attack and DGA

    During the operation of the DNS server, a small number of cache poisoning attacks were detected. In the statistics of the Infoblox DNS server, it was indicated that answers with the wrong ports and query ID were received, but, unfortunately, the log files for analysis were not saved.

    In addition, suspicious queries of the form were found:
    • ndnaplaaaaeml0000dgaaabbaaabgnli.energystar.gov;
    • mmokojaaaaeml0000dgaaabbaaabgclm.doleta.gov;
    • oaanjeaaaaesc0000deaaabbaaabicoc.webpanel.sk;
    • cnklipaaaaesh0000claaabbaaabfgoa;
    • 2d852aba-7d5f-11e4-b763-d89d67232680.ipvm.biz.


    It is entirely possible that these entries partially relate to identified attempts to poison the cache, attempt to carry out an attack using phantom domains (the authoritative server does not respond and the outgoing connection pool gets clogged) or the work of “unknown animals” (malware) trying to contact the control center.

    conclusions

    • Any DNS server is a wonderful source of information about the behavior of ordinary users and malware;
    • Log analysis will help improve the quality of DNS;
    • A large number of “ANY + E” requests indicates that your server is located or is participating in an attack;
    • To conduct DrDOS attacks, malware used a small number of domains (no more than 3x4-4 at a time);
    • Blocking such suspicious domains (for example, on RPZ) will reduce the load on the server and network;
    • Too long DNS names (as in the example above) are the reason for a close examination of the client's behavior (the host is infected or someone uses DNS tunnels).

    Also popular now: