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

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 in-
dependently 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 organi-
zation 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).

4.2 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 un-
derstanding 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 simu-
lation and to avoid data compression.