Abstract
DNS Tunnels are built through proper tools that allow embedding data on DNS queries and response. Each tool has its own approach to the building tunnels in DNS that differently affects the network performance. In this paper, we propose a brief architectural analysis of the current state-of-the-art of DNS Tunneling tools. Then, we propose the first comparative analysis of such tools in term of performance, as a first step towards the possibility to relate each tool with a proper behavior of DNS traffic. To this aim, we define an assessment of the tools in three different network configurations with three different performance metrics. We finally summarize the most interesting results and provide some considerations on the performance of each tool.
Introduction
In the last years, Internet has grown so much that any organization from single restaurant and hotels to big companies are connected to it. In the same years, the evolution from early Web to Web 2.0 has seamlessly increased the number of applications available on the network. Both these aspects have indirectly taken organizations to the adoption of mechanisms (e.g. firewalls, captive portals) aimed at controlling the access to Internet. The reasons can be very different, from censorship in some countries to the selling of Internet connectivity. In general, such mechanisms acts as filters for proper network protocols (e.g. HTTP, FTP) while they often allow the transit of service protocols (DNS, ICMP) and they can’t appropriately filter ciphered ones (e.g. HTTPS, Skype). Thus, many attempts have been made aimed at exploiting these latter protocols in order to hide information and build a communication channel to another system on Internet, avoiding the restrictions of firewalls. To this regard, many research activities [1] [2] [3] have been focused on hiding data into various network protocols like IPv4, IPv6, TCP ICMP, HTTP and HTTPS, just to cite some.
At present, a particularly interesting covert channel is the DNS tunnel, since DNS protocol is less filtered by security mechanisms of organizations. For instance, when dealing with captive portals, if an unauthenticated user tries to connect to a given site, the captive portal solves the DNS query before requesting credentials to the user. Thus, this means that each user within the network can produce DNS traffic to reach a destination over the Internet, independently from the identity of the requestor.
Fig. 1. Entities involved in a DNS Tunnel
The potential use of DNS queries as covert channels had taken to the development of proper DNS Tunneling tools aimed at hiding information inside the DNS requests/responses, using a customized client on the user machine and a colluded DNS server outside the organization, in the destination domain. A DNS Tunneling tool embeds data in DNS queries and delivers DNS requests and responses between the tunneled client and a rogue server, exchanging information in proper fields of DNS packets. The rogue server can then forward the received data to another destination client.
Each DNS Tunneling tool adopts its own strategies for building tunnels between the client and the rogue server, resulting in covert channels that show different characteristics. However, DNS covert channels (and tools) can be divided into two classes: (1) IP over DNS where IP packets are embedded and delivered through the tunnel, and (2) TCP over DNS that embeds one or more TCP-like communication channels, allowing the establishment of an SSH connection (or any kind of TCP connection) in the tunnel. Currently, there exist only few working and reliable DNS Tunneling tools, in particular for the second category. Each tool shows a unique strategy that has different aftermaths and backlashes on the legal DNS servers and network traffic. Thus, the possibility to relate some specific performance patterns to a proper DNS tool would be useful for a detection system to recognize the presence of a DNS tunnel.
To the best of our knowledge, a comprehensive and deep performance evaluation of all the current state-of-the-art in DNS tunneling tools has not been made yet. Thus, the aim of this paper is to provide a first attempt to compare distinct DNS Tunneling tools by characterizing their performance and the impact they have on the network.
The paper is organized as follows: Section 2 points out the related works on convert channels and, in particular, on DNS tunnels; Section 3 provides an introduction to current DNS Tunneling Tools. Section 4 introduces the testing network architecture, the network scenarios (i.e. proper configurations of the general architecture) and the metrics we used in our tests. Section 5 provides an analysis of the results and a characterization of each tool in term of network performance. Finally, Section 6 concludes the paper.
Related Works
Due to the growing proliferation of covert channels, many research activities have been focused on recognize unexpected patterns [7] or hidden information in plain and ciphered network protocols. Plain protocols (e.g. http) can be exploited to build covert channels. In particular, SSH can use HTTP to force the restriction of a firewall. In [4], HTTP traffic is analyzed in order to recognize covert channels built by Skype protocols. The proposed solution is feasible for real-time Skype detection over HTTP, providing a very low percentage of false positive.
On ciphered networks, many activities are focused in categorizing communication patterns of ciphered traffic by evaluating only features and metrics that are not affected by encryption. For instance, in [8] a methodology for recognizing application level protocols embedded on ciphered TCP channels is presented. Similarly, in [5] two traffic analysis techniques based on classification algorithms are used for retrieving web sites identities in ciphered HTTPS traffic.
In general, the information leakage in ciphered protocols is a sensitive problem: in [6], authors investigate how the behavior of anonymity systems (e.g. Tor) could take to an unwanted reduction of the real level of anonymity, allowing an attacker to discover information on the network location of a client.
DNS protocol has been deeply investigated in order to monitor and detect attack to single DNS servers and to the network of servers. In [9] monitoring algorithms are proposed for detecting attacks to DNS servers (e.g. cache poisoning). In the same article, a methodology for detecting DNS Tunneling is provided. To this regard, in [10] a statistical approach based on the analysis of the frequencies of characters in DNS request is provided: the idea is that characters in DNS tunnels have an evenly distributed frequency while in normal language (and so, real DNS query), the frequency follows the Zipf’s law.
However, previous studies do not consider variation of performance due to the existence of DNS Tunneling in comparison to DNS traffic without tunnels. However, some early studies have been made under this perspective. In [11] the impact of DNS Tunnels on network performance is investigated. However, the study is limited to DNS tunnels built with DNSCat and on a network scenario distributed over Internet.
DNS Tunneling Tools
Existing DNS Tunneling Tools can be divided into two classes, depending on the abstraction layer at which the information is encapsulated. Each tool requires a real DNS server to administer the tunneling domain.
IP over DNS Tunnels
The main part of DNS Tunneling tools are aimed at building IP over DNS tunnels, namely encapsulating IP packets inside DNS queries:
• NSTX [13] has been the first tool to realize IP over DNS. To encode data into queries, it uses a non-compliant Base64 encoding (adding the character "_" to the 63 characters allowed by the DNS RFC). Tunnels are realized on the tun0 interface and replies are encoded into TXT records. NTSX requires a rogue server running the NSTX tool. It also requires the client and server to have special kernel configurations.
• DNS Cat [14] consists of two small programs, a server and client, written in Java. It is a fast, efficient and highly configurable cross platform. The tunnel is made through the interface ppp0 and data in replies are encapsulated in the CNAME record. In comparison to NTSX, it does not require special kernel configuration. Thus, DNS Cat is more flexible than NTSX.
• Iodine [15] is a more recent project. It uses either Base32 or a non-compliant Base64 encoding to encode the data (the choice is configurable). Replies are sent using NULL records. NULL records are described in RFC 1035 [5] section 3.3.10 as a container for any data, up to 65535 bytes long. It is used as a placeholder in some experimental DNS extensions. Additionally, Iodine uses EDNS0, a DNS extension that allows using DNS packets longer than the 512-byte asoriginally pro-posed in RFC 1035. Both NSTX and Iodine split IP packets into several DNS packets and send them separately. Thus they reassemble the IP packets at the end-point (in a way similar to IP fragmentation).
• TUNS [12] isa new-coming tool. It works exclusively onUNIX-like sys-tems(clients and servers) and encapsulates data in CNAME field. In comparison to NSTX and Iodine it does not split IP packets in smaller DNS packets. TUNS client polls periodically the rogue server with short queries. TUNS avoids duplicated queries made by DNS servers by using a cache. TUNS has been demonstrated to work on a wide range of networks.
TCP over DNS Tunnels
In TCP over DNS tunnels, only packets that use TCP as transport protocol are encapsulated in the tunnel. There are two tools that allow building TCP over DNS tunnels:
• Dns2TCP [16] is composed by a server-side and a client-side part. The server has a list of resources, each of whom is a local or remote service listening for TCP connection. The client listens on a predefined TCP port and relays each incoming connection to the final service using DNS. Information is encapsulated in the TXT field. Differently from the IP-over-DNS tools, there is not a periodic polling activity from the client side
• Ozy Man DNS [17] is based on four Perl scripts. Two of them allow users to upload and download files using DNS. The other two form a server client pair. The server imitates a DNS server and listens on port 53 for incoming DNS requests. The client converts input to DNS requests, which are then sent to a given domain. These two scripts can be used in conjunction with SSH to create a tunnel. Users will then have to manually map ports to pass traffic through the resulting tunnel. Their use is transparent for applications.
Testing Environment
The previous tools have been tested on three different scenarios on the same network architecture at IEIIT-CNR (National Research Council in Genoa, Italy).
The network architecture is represented in Fig. 2. It is made by 4 networks connected by a Juniper Router with firewall. Each subnet contains a single participant in the DNS Tunneling. This choice allowed us to better isolate and analyze the traffic flow during the testing phase. Network 1 contains the DNS Tunnel client, where DNS Tunnel client of each tool is executed. Network 2contains the local DNS server only, which is authoritative for the domain of the client. Network 3 is made by a DNS rogue server, namely running the server part of the DNS Tunneling tool. Finally, Network 4 contains a further machine, recipient for the tunneled data.
Fig. 2. IEIIT-CNR Testing architecture
We tested the tool suite using three different configurations. In each configuration, only some networks are involved:
• Direct: It involves the Network 1 and 3. The aim is to evaluate the performance of different tools, without taking into account the overheads of the network. To this aim, the DNS client is directly connected to the fake DNS server, without querying the local DNS. In the most part of real scenario this configuration is unfeasible, since DNS traffic is typically allowed only towards the local DNS or outer trusted DNS servers. However, this configuration allows each tool to build the tunnel independently from typical restriction of DNS server (e.g. filtering on DNS records like NULL, TXT, EDNS0 extension) in order to evaluate the behavior of tools in an ideal environment.
• IEIIT: It involves the first three networks. The DNS client connects to the local DNS server. The local server forwards the queries to the fake server. In this case, tools have to adapt their behavior depending on the restrictions settled by the local DNS server. A sensitive reduction of the performance of the tools is expected due to (1) server restriction and (2) traffic congestion. The comparison between Direct and IEIIT configurations allows characterizing the effects of local DNS on tunnels. IEIIT configuration is closed to a real use of DNS Tunneling. Indeed, in an organization all the DNS traffic must pass through the local DNS server in order to be forwarded to an outer DNS server. However, the fake DNS server is in general used as bridge for a remote machine that is waiting for data (i.e. it does not work as the destination of the tunneled data). This configuration does not take care of this final step to the remote machine.
• NAT: This configuration is similar to the previous one but the fake DNS decodes the request, extracts data and deliver them to a destination machine through a third external server (all networks are involved).
Performance Metrics
We defined three metrics in order to evaluate the performance of tools in the three configurations.
• Throughput. It assesses the bandwidth availability through the tunnel. This value measures the efficiency of the DNS tunneling tool implementation and allows understanding which kind of data (and, consequently, kinds of applications) can be embedded on a tunnel. For instance, low throughput tools can be used for short data transfers but are unsuitable for applications with time constraints (i.e. VOIP). We measured throughput in different time instants through the Iperf[18] tool. Real payloads have been used as tunneled data, in order to increase the realism of simulation and to avoid data compression.
• Round Trip Time (RTT). In our context, RTT measures the time elapsed between the sending of a packet to a destination and the receipt of the same packet from the source. The destination is forced to send back the received packet at once, in order to assess RTT. Latency has been measured through hping3 [19] using different packet sizes from 16 to 1024 byte each. Also in this case, packets have been filled with real data.Since ping is not realizable in TCP over DNS tools, we built a proper tunneling interface for managing ICMP packets. In particular, we define a fake interface by customizing an SSH client and serverin order to avoid ciphering that would increase overhead.!
• Overhead. It measures the number of packets generated by tools that are not directly related to the transport of tunneled data. This includes, for instance, packets for polling the rouge DNS server. The overhead of each tool has been measured by calculating the number of packets in a tunnel in a ping session, and thus comparing it with the amount of packets in a ping session without tunneling. The amount of packets has been calculated through the tshark tool, synchronized with the ping session.
Testing and Analysis of Results
We tested all network configurations in terms of all metrics. Each test has been repeated several times.Due to the lack of space,we provide a summary with a global evaluation of the performance of each tool, without detailing the test results. The comparative analysis of performance has been made both analytically (making investigation at a granularity of single packets with Wireshark [20]) and graphically, by comparing the trend of single metrics among the different tools (e.g. Fig. 3).
The previous tests allow recognizing a unique set of characteristics for each tool in term of performance:
• Dns2Tcp. The TCP-over-Tunnel built with Dns2Tcp shows a higher throughput in comparison to the IP-over-DNS solutions and the RTT is low. However, a tunnel made through Dns2Tcp is easily recognizable by the high amount of packet overhead (around 1500%), which significantly lowers the global network performance.
• NSTX. It shows the lower RTT in all IP-over-DNS tools but it has globally a low throughput. Moreover, since NSTX is not configurable, it cannot be customized to different scenarios and, thus, the throughput cannot be raised. A high throughput has been measured only in the Direct configuration, that is, as remarked, an unrealistic case.
• DnsCat. It has an acceptable level of throughput and RTT, making it suitable for Internet surfing without sensitive delays. However, it is characterized by a non-regular trend and high overhead. Differently from NSTX, it is a highly configurable tool, so the overhead can potentially be reduced by properly customizing the tool if the network configuration is known.
• Iodine. Iodine is the only tool showing a linear behavior in all metrics and all configurations. Notwithstanding the average throughput, Iodine shows the lower overhead and a low RTT value. Since it is particularly configurable, it is suitable for almost all network scenarios.
• TUNS. It shows the lower performance in all configurations. Throughput and RTT are too low and too high, respectively, making hard its use for building channels exploitable by real applications. However, it shows a good overhead value and, differently from the other tools, its performance and design characteristics make it particularly reliable in choke networks.
• OzyManDNS. We were not able to assess the performance of OzyManDNS since it has revealed to be too buggy for an exhaustive evaluation. In particular, each test had crashed after few seconds. Thus, we argue that this tool is too unstable to be effectively used in real scenarios.
Fig. 3. A throughput test in the NAT configuration
Conclusions and Future Works
In this paper we have comparatively analyzed the characteristics of the current state-of-the-art in DNS Tunneling tools, providing both a testing environment and a brief and global analysis of the whole set of results. Such analysis allowed us to relate a relationship among values of the test metrics to a proper tool. Further work will regard the exhaustive and detailed analysis of the results and a behavioral analysis of the tools for intrusion detection and security purposes.
