Virustracker · 2015/03/25 fool

from:http://securityintelligence.com/analyzing-queries-on-a-honeypot-name-server-for-better-dns-log-quality/

0x00 Network noise

“Honeypot” is a common method to count “network noise”, and it is relatively simple. The better you know about “network noise,” the better you can do security analysis. I wonder what traffic the NS honeypot can receive on the public cloud; My research is as follows:

0x01 Set the NS Honeypot

The server runs Ubuntu 14.04.1 LTS in default Settings, hosted by Frankfurt Amazon Cloud, and is configured with an IPv4 address (I didn’t check the IPv6 data). Since the server’s IP address and DNS service are not publicly available on public channels, any request to this server can be treated as a suspicious request. Currently, I haven’t investigated the impact of cloud providers reusing IP addresses.

The server also has the following honeypots installed: Dionaea, Glastopf, Conpot, SNMP, NTP, and Kippo. Kippo is an SSH honeypot designed to attract the attention of hackers and improve security. Kippo Settings and data collection are available (via ELK) in a repository on Github.

I have used one of the most popular NS software -BIND. Most of these Settings are default. I disabled recursion, IPv6, and forwarders, enabled logging, and customized the server version to include a zone file in the server. Zone files contain mappings between IP addresses and domain names, and available subdomains. The Zone file contains a record that points to the same host. So, anyone who queries this NS honeypot (” A.B.C.D “) will get a reply containing the IP address of the honeypot server.

0 x02 Bind configuration

options { directory "/var/cache/bind"; dnssec-validation auto; recursion no; allow-transfer { none; }; auth-nxdomain no; # conform to RFC1035 // listen-on-v6 { any; }; statistics-file "/var/log/named/named_stats.txt"; memstatistics-file "/var/log/named/named_mem_stats.txt"; The version "9.9.1 - P2"; }; logging{ channel query_log { file "/var/log/named/query.log"; severity info; print-time yes; print-severity yes; print-category yes; }; category queries { query_log; }; };Copy the code


$TTL 10<br/>@ IN SOA localhost. root.localhost. (<br/> 1 ; Serial<br/> 10 ; Refresh<br/> 10 ; Retry<br/> 10 ; Expire<br/> 10 ) ; Negative Cache TTL<br/>; <br/><br/> IN NS localhost<br/>* IN A a.b.c.dCopy the code

0x03 Statistics

The first set of statistics represents raw data discovered from log files.

0x04 Time range

If we map queries against this data, we see a spike in queries on January 15 and January 20, and late January and early February.

Upon further investigation, we found that these queries were all caused by a single IP address; The IP address belongs to ruhr University Bochum in Germany. The Ruhr University bochum website describes the “Amplification DDos Tracker Project.” The site alerts network owners to possible problems by capturing scan data. We found that these scans were performed on two IP addresses: one belonging to ruhr University Bochum in Germany and the other to Saarland University in Germany.

We later discovered that the open Resolver project was querying the honeypot DNS, which resulted in a large number of queries.

0x05 Where do these queries come from?

I extracted the IP addresses from the logs and then used Team Cymru’s ASN to get the corresponding countries of these IP addresses. Autonomous systems (AS) can tell us which network segment an IP address belongs to. The script is also available on Github.

The scans came mainly from Germany, the United States and China. Among them, DFN (Germany) and Hunan Chinanet received more inquiries. More than half of the inquiries came from Europe (RIPE). Given the large number of requests coming from Ruhr University in Germany, this is not surprising.

0x06 What are they Looking for?

Most queries are for A records for domain names, and more than 18% of queries are for ANY records for domain names. The TXT request is mainly for obtaining the version of the DNS server.

These queries are for getting the IP addresses of Google and Shadowsever, or the version of Bind NS. Not surprisingly, the most common TLDS are.com and.org. Choose your domain name and TLD carefully when starting your business. The most interesting part of this data is the percentage of the two TLD’s, ru and cn.

0x07 Open Resolver Scan

As mentioned above, the Open Resolver project resulted in a large number of requests. In fact, approximately 56% of queries come from organizations that participate in Open Resolver.

Although the number of such queries is large, they can be easily identified in the logs.

Queries: info: client X.X.X.X #34341 (dnsscan.shadowserver.org): query: IN A + (X.X.X.X)02-Feb-2015 19:15:44.507 Queries: info: Client X.X.X.X #41248 (www.goOGLe.co.in): query: www.goOGLe.co.in IN A + (X.X.X.X)07-Jan-2015 06:36:04.149 Queries: info: client x.x.x.x#33481 (7f14f6df.openresolvertest.net): query: 7 f14f6df.openresolvertest.net IN A + (X.X.X.X) 11 - Jan - 2015 14:54:03. 692 queries: the info: Client X.X.X.X #43656 (openresolver.com): Query: Openresolver.com IN A +E (X.X.X.X)01-Feb-2015 06:42:54.797 queries: info: client x.x.x.x#46018 (7f14f6df.openresolverproject.org): query: 7 f14f6df.openresolverproject.org IN A + (X.X.X.X) 08 - Feb - 2015 04:12:45. 562 queries: the info: client x.x.x.x#28207 (9h2y.96bf5d36.wc.syssec-research.mmci.uni-saarland.de): query: 9h2y.96bf5d36.wc.syssec-research.mmci.uni-saarland.de IN A + (x.x.x.x)<br/>Copy the code

These queries are annoying, and there are a lot of them. If you don’t filter these out in your log monitoring system, it will be hard to detect truly malicious requests. If you want to keep an eye on the DNS server, all you have to do is apply a proper filter to block such requests or ask them to stop scanning you before processing the logs. This can also increase the results you can get from logging monitoring or SIEM solutions.

Such scans can also have legal implications. While most requests for Open Resolver projects are usually not malicious, it’s not hard to imagine that someone unfamiliar with these organizations might think these scans are malicious. In his paper scanning for Vulnerabilities: Is It Legal? “Explains certain legal issues.

0x08 Filtering Result of scanning an Open Resolver

After filtering the Open resolver query, the following results are obtained:

There was no significant spike in these time horizons. Most of the queries came from the US and China. The query distribution between RISs Ripe, Arin and Apnic is also roughly equal.

In this category, the request type is either A record query or ANY resource query. Most of them are Google domain queries.

After removing the interference from the Open Resolver, the data set revealed the behavior of two particular hosts: one from China (AS 63835) and the other from Russia (AS 2848).

Chinese hosts only query the version of Bind NS periodically, and then look for the A record of www.google.it and www.google.com:

Queries: info: client X.X.X.X #56334 (version.bind): query: VERSION.BIND CH TXT + (X.X.X.X)06-Feb-2015 01:19:13.674 Queries: info: client X.X.X.X #39664 (www.google.it): query: www.google.it IN A + (X.X.X.X)06-Feb-2015 16:49:14.384 Queries: info: client X.X.X.X #51102 (www.google.com): query: www.google.com IN A + (X.X.X.X)07-Feb-2015 01:57:22.995 Queries: info: client X.X.X.X #45938 (version.bind): query: Queries: info: client X.X.X.X #41664 (www.google.it): query: X.X.X.X #41664 (www.google.it): query: www.google.it IN A + (X.X.X.X)07-Feb-2015 23:00:43.537 queries: info: client X.X.X.X #49252 (www.google.com): query: www.google.com IN A + (X.X.X.X)08-Feb-2015 13:27:10.678 queries: info: client X.X.X.X #34047 (version.bind): query: VERSION.BIND CH TXT + (x.x.x.x)<br/>Copy the code

Russian hosts only query com periodically:

06-feb-2015 08:45:17.256 queries: info: client X.X.X.X #42795 (com): query: Com IN ANY +E (X.X.X.X) 08-FeB-2015 15:44:01.787 Queries: info: client X.X.X.X #33207 (com): query: com IN ANY +E (x.x.x.x)<br/>Copy the code

0x09 What happened to the ‘ANY’ request?

About half of the requests are “ANY” requests,

Queries: info: client X.X.X.X #32767 (isc.org): query: isc.org IN ANY +ED (X.X.X.X)Copy the code

Typically, this is a DNS amplification attack using bogus queries. All of these queries have a recursive () setting flag indicating that the query is from a client or a server-forwarded request. Only a very small number of hosts require () support for DNSSEC in replies.

In addition to Google and ISC domains, we also found many more “foreign” domains; Using these domains, the attackers tested the possibility of DNS amplification attacks. These domains were found in previous attacks:

  • globe.gov
  • ohhr.ru
  • Egransy.com
  • uzuzuu.ru
  • sema.cz
  • vlch.net

DNS amplification Attack watchers know the domain names used in the attack, and can also provide an IP form rule set to “blacklist” these domain names.

But why would anyone use these requests? These requests cannot be explained by normal network behavior. However, if you look at the responses returned by certain requests, the picture becomes clear. You can use the following command to test:

Dig -t ANY @8.8.8.8 mydomainCopy the code

Some responses exceed 6,000 bytes in size.

;; MSG SIZE rcvd: 6800;; MSG SIZE rcvd: 6584
Copy the code

For general use (except zone transport), DNS uses the UDP protocol on port 53 to transport packets. This approach requires a relatively small DNS packet size (512 bytes, regardless of the different table headers). Note that DNSSEC typically requires larger packets. DNS uses EDNS0 to handle larger packets. However, using EDNS0 still limits the size of packets (perhaps because the server does not support EDNS0), so TCP is again used to handle DNS requests for these large packets. The output shows:

;; Truncated, retrying in TCP mode.
Copy the code

In short, a small request over a simple protocol that consumes fewer resources becomes a large response over a complex protocol that consumes a lot of resources.

The difference between UDP and TCP is that UDP does not have a handshake process. You send the request, it’s over; This is a “stateless” protocol. TCP, on the other hand, has a “handshake process” that requires more resources. In addition, under this protocol, it is also easy to impersonate the source of the IP address.

Combined with the above two points, amplification attack has a good attack vector.

The OpenDNS folks describe how these DNS attacks work. CloudFlare has observed the same pattern.

Defending against this type of attack requires efforts on multiple levels. DNS administrators need to ensure that their recursive NS is not an open parser by limiting the clients on the list that can perform recursive queries. For authorized NS, the administrator should set the response frequency limit (RRL). Network administrators can allow only known network prefixes to leave their networks (perform BCP 38). This defends against all DDoS amplification attacks (DNS, SNMP, NTP, etc.) based on UDP.

0 x10 conclusion

If a random DNS server quickly receives a large number of requests for open parser tests, these network noises can contaminate the log; This makes it harder to detect attacks on DNS servers.

You can use a DNS server “honeypot” to catch these network noises.

With just a few scripts, you can easily filter out the primary scanner based on the information provided by the honeypot dataset. You can then use this whitelist to remove them from the real DNS logs and make your log monitoring or SIEM solution more valuable. However, manually setting up whitelist authentication is necessary if you want to prevent some advanced hackers from accessing your whitelist.