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 country | Company | Number of requests | Number of IP |
United states | SoftLayer Technologies Inc. | 3965202 | 36 |
United states | SingleHop, Inc. | 2617987 | 27 |
United states | PSINet, Inc. | 1994461 | 22 |
France | OVH SAS | 1051080 | 304 |
United kingdom | Hosting Services Inc | 938367 | 4 |
Germany | 1 & 1 Internet AG | 761020 | 12 |
United states | PrivateSystems Networks | 748641 | 4 |
Russian Federation | OJSC Rostelecom Ticket 09-39331, RISS 15440, UrF | 687028 | 1 |
United states | Time Warner Cable Internet LLC | 671211 | 1568 |
Canada | OVH Hosting, Inc. | 592920 | 213 |
United states | Akamai Technologies, Inc. | 176327 | 4410 |
China | China Telecom | 51565 | 207 |
United states | AT&T Internet Services | 27502 | 854 |
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.
Domain | Inquiry | Flag | Number of requests |
webpanel.sk | ANY | + E | 14962032 |
oggr.ru | ANY | + E | 8300693 |
energystar.gov | ANY | + E | 6676350 |
doleta.gov | ANY | + E | 6326853 |
067.cz | ANY | + E | 2463053 |
sema.cz | ANY | + E | 1251206 |
GUESSINFOSYS.COM | ANY | + E | 690320 |
jerusalem.netfirms.com | ANY | + E | 587534 |
paypal.de | ANY | + E | 454756 |
nlhosting.nl | ANY | + E | 414113 |
freeinfosys.com | ANY | + E | 352233 |
krasti.us | ANY | + E | 333806 |
doc.gov | ANY | + E | 259248 |
svist21.cz | ANY | + E | 231946 |
wradish.com | ANY | + E | 117294 |
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.
Inquiry | Flags | Number of requests |
ANY | + E | 43500439 |
A | -ED | 17339 |
ANY | + | 11932 |
A | - | 9853 |
A | -EDC | 8956 |
AAAA | -EDC | 4749 |
AAAA | -ED | 4467 |
ANY | - | 2289 |
A | + E | 1899 |
Rrsig | + E | 1124 |
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).