Digging into IP Flow Records with a Visual Kernel Method - Computational Intelligence in Security for Information Systems - page 87

• 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 ex-
tension that allows using DNS packets longer than the 512-byte asoriginallypro-
posed in RFC 1035. Both NSTX and Iodine split IP packets into several DNS
packets and send them separately. Thusthey 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.

3.2 TCP over DNS Tunnels

In TCP over DNS tunnels, only packets that use TCP as transport protocol are encap-
sulated in the tunnel. There are two tools that allowbuilding 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 activ-
ity from the client side

• OzyManDNS [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.

4 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 con-
nected 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.