Final Report

GRADUATION PROJECT 2
By:
Meshal AL-Matairi 201311172
A Graduation Project submitted in partial fulfillment of the

requirements for the degree of
Bachelor of Computer and Information Systems
(Network Engineering and Security)
College of Computer and Information System
1
ABSTRACT
DNS tunneling is a method to bypass security controls and exfiltration data from a
targeted organization. Logging DNS transactions from different sources such as
network taps and the DNS servers themselves can generate large volumes of data to
investigate. Using Detection system can help ingest the large volume of log data and
mine the information to determine what malicious actors may be using DNS tunneling
techniques on the target organizations network. This report presents the problem we
want to study in my project, which is to analyze, design and implement a traffic
analysis system to detect and stop the DNS tunnels. It also present a review of the
relevant literature and the proposed project plan.
2
ACKNOWLEDGMENT
This project had toke a lot of effort in searching and writing. However, it would not
have been easy to complete this project without any help from Dr Issam, we would
like to thank him for guidelines and feedback thats given to us. Finally, we owe our
deepest gratitude to our family for helping and supporting us.
3
TABLE OF CONTENTS
ABSTRACT .....................................................................................................................
ACKNOWLEDGMENT..................................................................................................
TABLE OF CONTENTS .................................................................................................
LIST OF FIGURES .........................................................................................................
LIST OF TABLES ...........................................................................................................
LIST OF ABBREVIATION ............................................................................................
Chapter 1. INTRODUCTION ..........................................................................................
1.1 BACKGROUND ....................................................................................................
1.2 PROBLEM STATEMENT .....................................................................................
1.3 PROJECT OBJECTIVES .......................................................................................
1.4 PROJECT SCOPE ..................................................................................................
1.5 SIGNIFICANT OF THE PROJECT.......................................................................
1.6 LIMITATION OF THE PROJECT ........................................................................
1.7 PROJECT ORGANIZATION ................................................................................
Chapter 2. LITRATURE REVIEW .................................................................................
2.1 DNS SERVICE .......................................................................................................
2.1.1 Significance of the DNS Service .........................................................................
2.1.2 Types of DNS Servers .........................................................................................
2.1.2.1 Root and TLD Servers ......................................................................................
2.1.2.2 Recursive DNS servers .....................................................................................
2.1.2.3 Caching DNS servers ........................................................................................
2.1.2.4 Authoritative-Only DNS Servers ......................................................................
2.1.3 Types of DNS Record .........................................................................................
2.1.4 DNS Server implementations ..............................................................................
2.1.4.1 AnswerX ...........................................................................................................
2.1.4.2 BIND .................................................................................................................
2.1.4.3 PowerDNS ........................................................................................................
2.1.4.4 Microsoft DNS ..................................................................................................
2.1.4.5 Simple DNS Plus ..............................................................................................
2.1.4.6 YADIFA ...........................................................................................................
2.2 DNS TUNNELING TOOLS......................................................................................
2.2.1 OzymanDNS .......................................................................................................
4
2.2.2 DNScapy .............................................................................................................

2.2.3 Heyoka ................................................................................................................
2.2.4 Iodine...................................................................................................................
2.2.5 DNS2tcp ..............................................................................................................
2.2.6 DNScat2 ..............................................................................................................
CHAPTER 3: PROJECT ANALYSIS ............................................................................
3.1 Existing similar systems .........................................................................................
3.1.1 Packetbeat and Watcher ......................................................................................
3.1.2 SNORT ................................................................................................................
3.1.3 Splunk..................................................................................................................
3.2 METHODOLOGY .................................................................................................
3.3 APPLICATION REQUIREMENTS .....................................................................
3.3.1 Users of the System .............................................................................................
3.3.2 Functional and Non-Functional Requirements ...................................................
3.3.2.1 Functional Requirements .................................................................................
3.3.2.2 Non-Functional Requirements .........................................................................
3.4 DNS TUNNELING MITIGATION TECHNIQUES ............................................
3.3.1 Payload Analysis .................................................................................................
3.3.1.1 Unauthorized DNS Servers ..............................................................................
3.3.1.2 Statistical Analysis ...........................................................................................
3.3.1.3 Infrequent Record Types..................................................................................
3.3.1.4 Host Name Entropy..........................................................................................
3.3.2 Traffic Analysis ...................................................................................................
3.3.2.1 Volume of DNS Requests .................................................................................
3.3.2.2 Geographic Location .........................................................................................
Chapter 4. PROJECT DESIGN .......................................................................................
4.1 COMPARISON OF DNS IMPLEMENTAIONS ...................................................
4.1.1 BIND DNS Software ...........................................................................................
4.1.1.1 Domain Name Resolver ....................................................................................
4.1.1.2 Domain Name Authority Server .......................................................................
4.2 CHOSSEN DNS TUNNELING TOOL..................................................................
4.3 CHOSSEN DNS TUNNELING METIGATION TECHNIQUES .........................
4.3.1 Hostname Entropy calculation ............................................................................
5
4.4 SYSTEM DIAGRAMS ..........................................................................................

4.4.1 System Black Box ...............................................................................................
4.4.2 Use Case Diagram ...............................................................................................
4.4.3 Data flow Diagram ..............................................................................................
Chapter 5. PROJECT Implementation .............................................................................
5.1 DNS Tunnels Detector System Tasks ................................................................. 48
5.2 DNS Tunnels Detector System Phases ............................................................... 49
5.2.1 Packet Capturing Phase ................................................................................... 49
5.2.2 Tunneling Analyzing and Detecting Phase ..................................................... 49
5.2.2.1 Entropy of Hostname calculation.................................................................. 50
5.2.2.2 Analyzing TTL Field .................................................................................... 50
5.2.2.3 TXT Type monitoring ................................................................................... 51
5.2.3 Tunneling Prevention ....................................................................................... 51
5.3 System Implementation tools.............................................................................. 51
5.3.1 C# .................................................................................................................... 51
5.3.2 C# and .Net ...................................................................................................... 52
5.3.3 VS2015 IDE .................................................................................................... 54
5.3.4 PcapDotNet Library ........................................................................................ 54
5.4 System Implementation ...................................................................................... 56
5.4.1 WinPcap and pcapdotnet installation .............................................................. 56
5.4.2PcapDotNet packets capturing and analyzing .................................................. 59
5.5 System GUI ......................................................................................................... 62
1) Network Adapter .................................................................................................. 62
2) Start Listening ...................................................................................................... 63
3) Captured DNS packets Table ............................................................................... 63
4) DNS packet Details .............................................................................................. 64
5) Clear Table ........................................................................................................... 65
6) Save Capture ........................................................................................................ 65
7) Suspected Tunnels IPs ......................................................................................... 67
8) IP with DNS Tunnels ........................................................................................... 68
9) Block/Unblock Button ......................................................................................... 69
10) File Menu ........................................................................................................... 70
11) Help Menu ......................................................................................................... 71
6
Chapter 6. Tests ........................................................................................................... 72

6.1 Used Resources ................................................................................................... 72
6.2 Tests .................................................................................................................... 73
6.2.1 First Test .......................................................................................................... 73
6.2.1.1 Environment Setup .73
6.2.1.2 DNS Shield (Start Capturing) ....................................................................... 79
6.2.2 Second Test ..................................................................................................... 85
6.2.2.1 Virtual Machine Setup .86
6.2.2.2 The program Run 87
6.2.2.3 Tunnel Creation ..89
6.2.2.4 DNS Shield (Start Capturing) ....................................................................... 90
6.3 Test in real networks ........................................................................................... 92
Chapter 7. CONCLUSION AND FUTURE RECOMMENDATIONS ...................... 94
7.1 SUGGESTION ................................................................................................... 94
7.2 CONCLUSION ................................................................................................... 94
BIBLIOGRAPHY 95
7
LIST OF FIGURES
Figure 1 Project Gantt Chart ............................................................................................

Figure 2 DNS Hierarchical Design ..................................................................................
Figure 3 Recursive DNS process .....................................................................................
Figure 4 Ozyman DNS Request .......................................................................................
Figure 5 Ozyman DNS Response ....................................................................................
Figure6 DNScat2 Request...............................................................................................
Figure 7 DNScat2 Records Type .....................................................................................
Figure 8 DNScat2 Fixed TTL ..........................................................................................
Figure9 Location of Packetbeat Tool ..............................................................................
Figure 10 Waterfall model ...............................................................................................
Figure 11 DNS Tunneling Throughput ............................................................................
Figure 12 DNS Tunnel Attack Scenario ..........................................................................
Figure 13 DNS Tunnel Mitigation Scenario ....................................................................
Figure 14 Use Case Diagram ...........................................................................................
Figure15 Data Flow Diagram .........................................................................................
Figure 16 .Net Framework ........................................................................................... 53
Figure 17 Add a Reference .......................................................................................... 56
Figure 18 Add PcapDotNet files .................................................................................. 57
Figure19 PcapDotNet Files ......................................................................................... 58
Figure20 using PcapDotNet Library ........................................................................... 58
Figure 21 System GUI ................................................................................................. 62
Figure 22 Network Adapter List .................................................................................. 62
Figure 23 Start Listening ............................................................................................. 63
Figure 24 Stop Listening .............................................................................................. 63
Figure 25 Capture DNS Packets .................................................................................. 63
Figure26 DNS packets Details .................................................................................... 64
Figure 27 Clear Table .................................................................................................. 65
Figure 28 Save Capture ................................................................................................ 65
Figure 29 save Capture Window.................................................................................. 66
Figure30 Save Capture File ........................................................................................ 66
Figure31 Suspected Tunnels IPs ................................................................................. 67
Figure32 Detect a Tunnel Example ............................................................................ 67
Figure33 IP with DNS Tunnels Table ........................................................................ 68
Figure34 Block IP ....................................................................................................... 68
Figure35 Unblock IP ................................................................................................... 68
Figure36 Firewall Rule ............................................................................................... 69
Figure37 Firewall Rule Proporties .............................................................................. 70
Figure 38 File Menu..................................................................................................... 70
Figure39 Save Capture Dialogue ................................................................................ 71
Figure40 Help Menu ................................................................................................... 71
Figure41 About Message ............................................................................................ 71
8
Figure 42 First Scenario ............................................................................................... 73

Figure43 Tunnel Server Start ...................................................................................... 75
Figure44 VM1 Configuration ..................................................................................... 77
Figure45 VM1 IP ........................................................................................................ 78
Figure46 VM1 Ping .................................................................................................... 78
Figure47 Client Session establishment ....................................................................... 79
Figure 48 start Capturing Scenario .............................................................................. 79
Figure49 DNS Shield Listening on Tunnel ................................................................ 80
Figure50 DNS Shield Listening on Tunnel Details .................................................... 80
Figure51 Entropy violation ......................................................................................... 81
Figure52 IP Tunnel Detection ..................................................................................... 81
Figure53 Block the IP tunnel ...................................................................................... 82
Figure54 unblock the IP tunnel ................................................................................... 82
Figure55 Add the Firewall Rule ................................................................................. 82
Figure 56 Firewall proproties....................................................................................... 83
Figure57 Firewall rule poroporties ............................................................................. 84
Figure58 Client Blocked ............................................................................................. 84
Figure 59 Tunnel blocked ............................................................................................ 85
Figure 60 Second Test Scenario .................................................................................. 85
Figure 61 Test Files ..................................................................................................... 86
Figure 62 Text File Content ......................................................................................... 87
Figure63 DNSTester Run ........................................................................................... 88
Figure64 DNSTester Running .................................................................................... 88
Figure65 Capturing Normal Packets ........................................................................... 89
Figure66 New Tunnel Creation .................................................................................. 89
Figure67 Capturing Normal and Tunnel Packets........................................................ 90
Figure68 Find the Tunnel............................................................................................ 91
Figure 69 Tunnel Stop ................................................................................................. 92
Figure 70 Real Network Test ....................................................................................... 93
9
LIST OF TABLES
Table 1 Project Organization Table ............................................................................. 15

Table 2 DNS Records Type ......................................................................................... 22
Table 3 DNS Implementation Comparison......................................................................
Table 4 Hostname Entropy values ...................................................................................
LIST OF ABBREVIATION
DNS Domain Name System
IP Internet Protocol
TLD Top Level Domain
BIND Berkeley Internet Name Domain
YADIFA Yet Another DNS Implementation For All
NIDS Network-based Intrusion Detection System
SDLC Systems Development Life Cycle
FQDN Fully Qualified Domain Name
10
Chapter 1. INTRODUCTION
1.1BACKGROUND
In computer networks, a tunneling protocol allows a network user to access or provide
a network service that the underlying network does not support or provide directly. One
important use of a tunneling protocol is to allow a foreign protocol to run over a network
that does not support that particular protocol; for example, running IPv6 over IPv4.
Another important use is to provide services that are impractical or unsafe to be offered
using only the underlying network services, but sometimes the intruders take advantage
of the tunneling and that is the case in DNS tunneling,
DNS is a foundational protocol which enables applications such as web browsers to
function based on domain names. DNS is not intended for a command channel or
general purpose tunneling. However, several utilities have been developed to enable
tunneling over DNS. Because it is not intended for general data transfer, DNS often has
less attention in terms of security monitoring than other protocols such as web traffic.
If DNS tunneling goes undetected, it represents a significant risk to an organization.
This study will talk about DNS service different implementations, comparing different
DNS tunneling tools and analyzing DNS tunneling mitigation techniques, which solve
the problem and many things, by giving a detailed analysis and design study and
propose a prototype of the system that detect and stop these tunnels.
11
1.2PROBLEM STATEMENT
DNS is one of the major and important services on any network, so that the security
devices (such as firewalls) allow the DNS traffic to pass to any device in the network,
which some intruders take advantage of it and build tunnels to pass the firewalls and all
the security rules.
A large number of DNS Tunneling utilities exist with a wide range of capabilities. They
provide a covert channel for malicious activities which represent a significant threat to
organizations, DNS tunneling poses a significant threat and there are methods to detect
it. In this phase we want to study, design a traffic analysis system over an IPv4 based
network to detect and stop this utilities.
1.3PROJECT OBJECTIVES
The purpose of this project is to study, design and implement a traffic analysis system
to detect and stop the DNS tunnels over an IPv4 based network, to solve any security
problem we should choose suitable and efficient tools including detecting and
preventing ones. To achieve this aim we need to obtain the following:
Study the DNS service and protocol in details
Study the DNS Tunneling, with DNS tunneling
Study the different DNS Tunneling tools and techniques
Study the DNS Tunneling mitigation techniques.
Study the alternatives to implement the DNS Tunneling mitigation techniques
Implement the DNS Tunneling mitigation techniques.
12
1.4PROJECT SCOPE
The definition of the scope of this project states that the idea of the project is to explore
the vulnerabilities of the Internet's domain name tunnels system that might serve the
intruders, and to explain the dangerous effects of it. How can the attack be done to make
it possible to provide secure data for the intruder? What are the tools the intruder use
and what are the mitigation techniques we can use to prevent this type of tunneling.
1.5SIGNIFICANCE OF THE PROJECT
According to [14], for DNS threats, most enterprises are wide-open to real attacks via
this little-known vector; many organizations have little or no monitoring for DNS.
Instead, they focus resources on web or email traffic where attacks often take place
while DNS tunneling goes undetected, it might represents a significant risk to an
organization.
Because DNS tunneling attacks can be seen in many real-life attacks, there is an
underlying assumption that working in this project is very important in the field of IT
and the project will be a valuable addition to this field and in computer science in
general.
1.6 LIMITATION OF THE PROJECT
In this project, we will not study the tunneling attacks other than DNS tunneling because
we need a separate different project to study, design and implement the mitigation
techniques for each kind of tunneling attacks. In addition, we cannot test our project by
experiencing a real test of it on a real network, because we do not have an authority to
a real one, an alternative solution is to simulate a network using Virtual machines.
13
1.7 PROJECT ORGANIZATION
In Figure1 below, we have illustrated Gantt graph for the first part (Analysis and
Design) of our project and for the second part of our project (Implementation), as
illustrated in the figure below we notice that the first part will be completed over one
month (from 4/12/2016 to 2/1/2017) and the second part will be completed over three
months (from 16/1/2017 to 18/4/2017), it is divided into twelve main time phases:
Figure 1 Project Gantt Chart
The first part of the project is schedule from 12/4/2016 to 1/2/2017, the available time
is approximately 30 days and the second part of the project is schedule from
16/1/2017 to 18/4/2017, the available time is approximately 120 days, which will be
divided as the following:
14
Task Name Start End Duration

(days)
The First Draft of the Proposal 30/10/2016 20/11/2016 21
The Final Draft of the Proposal 25/11/2016 1/12/2016 6
Study the DNS service and 4/12/2016 10/12/2016 6

protocol
Study the DNS Tunneling and 11/12/2016 17/12/2016 6

its Tools
Study the DNS Tunneling 18/12/2016 24/12/2016 6

mitigation techniques
The First Draft of Theoretical 25/12/2016 31/12/2016 6

Study Report
The Final Draft of Theoretical 2/1/2017 15/1/2017 13

Study Report
Study the alternatives to 16/1/2017 1/22017 16

implement the DNS Tunneling
Implement the DNS Tunneling 2/2/2017 17/3/2017 43

Build a virtual network with a 18/3/2017 25/3/2017 7

firewall.
Implement the communication 26/3/2017 2/4/2017 7

between the program and the
firewall
The Final Report 3/4/2017 18/4/2017 15
Table 1 Project Organization Table
15
Chapter 2. LITRATURE REVIEW
2.1 DNS SERVICE
2.1.1 Significance of the DNS Service
DNS, or the Domain Name System, is an integral part of how systems connect with
each other to communicate on the internet. Without DNS, computers, and the people
who use them, would be required to connect using only numerical addresses known as
IP addresses.
Besides the obvious problem of having to remember a large number of complex
numbers for simple tasks, communicating through IP addresses also causes some
additional problems. Moving a website to a different hosting provider or moving
servers to different locations would require us to inform every client of the new
location.
DNS servers, the computers that together form the system that allow us to use names
instead of addresses, can server many different functions, each of which can contribute
to the ability to accessing servers by name.
2.1.2 Types of DNS Servers
Some of the differences between DNS servers are purely functional. Most servers that
are involved with implementing DNS are specialized for certain functions. The type
of DNS server we want to choose will largely depend on our needs and the type of our
problem.
16
2.1.2.1 Root and TLD Servers
Figure 2 is a tree showing, as an example, the different levels of the domain name
system. The top level, or root level, are the main record keepers for the internet. The
root servers keep records related to the level directly below them (.com, .net, etc). Each
level keeps records for the level directly below them. In addition, these are the most
important records for the DNS to work in a proper way [4].
17
Figure 2 DNS Hierarchical Design
2.1.2.2 Recursive DNS servers
When a client program wants to access a server by its domain name, it must find out
how to translate the domain name into an actual routable address that it can use to
communicate. It needs to know this information in order to get or send information to
the server.
Some applications, including most web browsers, maintain an internal cache of recent
queries. This is the first place the application will check, if it has this capability, in
order to find the IP address of the domain in question. If it does not find the answer to
its question here, it then asks the system resolver to find out what the address of the
domain name is.
A resolver in general is any component that acts as a client-side participant in a DNS
query. The system resolver is the resolving library that your operating system uses to
seek out the answer for DNS queries.
So generally, a query goes from the client application to the system resolver, where
it is then passed to a DNS server that it has the address for. This DNS server is called
a recursive DNS server [1]. A recursive server is a DNS server that is configured to
query other DNS servers until it finds the answer to the question. It will either return
the answer or an error message to the client (the system resolver in this case, which
will, in turn, pass it to the client application), Figure 3 show how the recursive DNS
servers work.
18
Figure 3 Recursive DNS process
The steps of DNS recursive query are [1]:
1: The Client asks the local DNS Server (which is a Recursive DNS server) for the
record associated with www.university.com
2: The Recursive DNS server querys the Root DNS servers, asking for the DNS
server records for the .com TLD.
3: The root DNS server responds with information for the .com DNS servers.
4: The Recursive DNS server querys the .com DNS servers, asking for the DNS
server records for the university.com domain.
5: The .com DNS server responds with information for the university.com DNS
servers.
6: The Recursive DNS server querys the university.com DNS servers, asking for
the specified (A, AAAA, MX, etc.) record for www.university.com.
7: The university.com DNS server responds with the requested value for
www.university.com
19
8: The Recursive DNS server responds to the clients original request with the
necessary information
9: The client can actually access the requested website!
2.1.2.3 Caching DNS servers
The caching DNS servers generally maintain a cache to save information about old
queries, so before sending any new query the server will check this cache first to see
if it already has the answer to the query. If it does not, it will see if it has the address
to any of the servers that control the upper level domain components. So if the request
is for www.university.com and it cannot find that host address in its cache, it will see
if it has the address of the name servers for university.com and if necessary, com. It
will then send a query to the name server of most specific domain component it can
find in order to query for more information.
In the example in the Figure 3 above, the root server and the com (second level servers)
are caching servers, the local DNS server (which is a recursive DNS Server) might be
a caching server as well according to its implementation.
2.1.2.4 Authoritative-Only DNS Servers
An authoritative-only DNS server is a server that only concerns itself with answering
the queries for the zones that it is responsible for. Since it does not help resolve queries
for outside zones, it is generally very fast and can handle many requests efficiently.
Authoritative-only servers have the following properties:
20
Very fast at responding to queries for zones it controls. An authoritative-only
server will have all of the information about the domain it is responsible for, or
referral information for zones within the domain that have been delegated out to
other name servers.
Will not respond to recursive queries. The very definition of an authoritative-
only server is one that does not handle recursive requests. This makes it a server
only and never a client in the DNS system. Any request reaching an authoritative-
only server will generally be coming from a resolver that has received a referral to
it, meaning that the authoritative-only server will either have the full answer, or
will be able to pass a new referral to the name server that it has delegated
responsibility to.
Does not cache query results? Since an authoritative-only server never queries
other servers for information to resolve a request, it never has the opportunity to
cache results. All of the information it knows is already in its system.
In the example in the Figure 3 above, the university.com server is an authoritative-only
DNS server.
2.1.3 Types of DNS Record
DNS server database consist of a collection of resource records and each of the records
provides information about a specific object. A list of most common records is
provided in the Following Table:
21
The Record The Purpose
Address Mapping The record A specifies IP address (IPv4) for given host. A
records (A) records are used for conversion of domain names to
corresponding IP addresses.
IP Version 6 Address The record AAAA (also quad-A record) specifies IPv6 address
records (AAAA) for given host. So it works the same way as the A record and the
difference is the type of IP address.
Canonical Name The CNAME record specifies a domain name that has to be
records (CNAME) queried in order to resolve the original DNS query. Therefore
CNAME records are used for creating aliases of domain names.
CNAME records are truly useful when we want to alias our
domain to an external domain. In other cases we can remove
CNAME records and replace them with A records and even
decrease performance overhead.
Host Information HINFO records are used to acquire general information about a
records (HINFO) host. The record specifies type of CPU and OS. The HINFO
record data provides the possibility to use operating system
specific protocols when two hosts want to communicate. For
security reasons the HINFO records are not typically used on
public servers.
Mail exchanger record The MX resource record specifies a mail exchange server for a
(MX) DNS domain name. The information is used by Simple Mail
Transfer Protocol (SMTP) to route emails to proper hosts.
Typically, there are more than one mail exchange server for a
DNS domain and each of them have set priority.
Name Server records The NS record specifies an authoritative name server for given
(NS) host.
Reverse-lookup As opposed to forward DNS resolution (A and AAAA DNS

Pointer records (PTR) records), the PTR record is used to look up domain names based
on an IP address.
Text records (TXT) The text record can hold arbitrary non-formatted text string.
Typically, the record is used by Sender Policy Framework
(SPF) to prevent fake emails to appear to be sent by us.
Table 2 DNS Records Type
22
2.1.4 DNS Server implementations
This section presents a comparison of the features, platform support, and packaging of
independent implementations of Domain Name System (DNS) name server different
implementation.
As we mentioned before, there are multiple types of DNS servers. The two principal
roles are recursive DNS servers and authoritative DNS Servers, which may be
implemented either uniquely or combined in a given implementation of the DNS
server.
There are many DNS server implementations, like AnswerX, BIND, PowerDNS,
Microsoft DNS, Simple DNS Plus and YADIFA.
2.1.4.1 AnswerX
AnswerX is Akamais recursive DNS resolver (rDNS). AnswerX is a modern resolver,
supporting IPv6. It can be used for DNS firewall functionality, extensive logging, and
a platform for service creation [1]. AnswerX is sold as software working on common
servers. The software is built to process millions of transactions per second on standard
hardware.
2.1.4.2 BIND
BIND is open source software that implements the Domain Name System (DNS)
protocols for the Internet. It is a reference implementation of those protocols, but it is
also production-grade software, suitable for use in high-volume and high-reliability
applications [2]. The name BIND stands for Berkeley Internet Name Domain,
because the software originated in the early 1980s at the University of California at
23
Berkeley.
2.1.4.3 PowerDNS
PowerDNS is a DNS server, written in C++ and licensed under the GPL. It runs on
most UNIX derivatives. PowerDNS features a large number of different backend
ranging from simple BIND style zone files to relational databases and load
balancing/failover algorithms[3].
2.1.4.4 Microsoft DNS
Microsoft DNS is the name given to the implementation of domain name system
services provided in Microsoft Windows operating systems.
Recently Windows Server provides several enhancements to the DNS Server service,
like DNSSEC, DNS and DHCP integration and DNS integration with Active Directory
is the same in Windows Server [4].
2.1.4.5 Simple DNS Plus
Simple DNS Plus [5] is a DNS server software product that runs on x86 and x64
editions of Windows operating system.
All options and settings are available directly from a Windows user interface. It
provides wizards for common tasks such as setting up new zones, importing data,
making bulk updates, etc.
2.1.4.6 YADIFA
YADIFA [6] is a lightweight authoritative Name Server, written in C (programming
24
language), with DNSSEC capabilities. Developed by the passionate people behind the
.eu top-level domain, YADIFA has been built from scratch to face todays DNS
challenges, with no compromise on security, speed and stability, to offer a better and
safer Internet experience.
YADIFA has a simple configuration syntax and can handle more queries per second
while maintaining one of the lowest memory footprints in the industry. YADIFA has
one of the fastest zone file load times ever recorded on a name server.
2.2 DNS TUNNELING TOOLS
There are a lot of DNS Tunneling Tools which aim to bypass the firewall using the
allowed DNS messages to gain unauthorized access to a network or to a host, in this
section we will provide a detailed study about some of the most famous tools like
OzymanDNS, DNScapy, Heyoka, Iodine, DNScat2 and dns2tcp.
2.2.1 OzymanDNS
The Ozyman DNS tool [15] is one of the DNS tunneling tool that works on Windows,
MAC and Linux operating systems, it is used to build SSH tunnels over DNS using
the TXT record type, it is build using Perl programming language, and Ozyman DNS
is breakdown into 4 Perl scripts. The server script is named nomde.pl which listen on
a privileged port, the Ozyman Client is used to encode/decode and send response back
to the server using SSH, the used encoding will be Base32, and Figure 4 is what an
example request could look like
25
Figure 4 Ozyman DNS Request

The response comes as a DNS TXT record, which can hold arbitrary ASCII data (so
the response come encoded with Base64), as illustrated in Figure 5 a response might
look like this
Figure 5 Ozyman DNS Response

However Ozyman DNS tool has revealed to be too buggy and unreliable at the current
state of development [16].
2.2.2 DNScapy
DNScapy [17] is a DNS tunneling tool that works on Windows, MAC and Linux
operating systems. The code is very light and written in Python. It includes a server
and a client. The server can handle multiple clients, DNScapy creates a SSH tunnel
through DNS packets. SSH connection, SCP and proxy socks (SSH -D) are supported.
We can use CNAME records or TXT records for the tunnel. The default mode is
RAND, which uses randomly both CNAME and TXT. DNScapy uses Scapy [18] for
DNS packet forging.
26
2.2.3 Heyoka
Heyoka [19] is a Proof of Concept of an exfiltration tool which uses spoofed DNS
requests to create a bidirectional tunnel. It aims to achieve both performance and
stealth, and is released under the GPLv2.
The tunnel is up to 60% faster compared to existing tools [19], thats because of the
different encoding that is used in the packets. Heyoka is 100% written in C, which
means that it runs natively without the need of interpreters installed on the machine,
which is extremely useful in a penetration testing scenario.
2.2.4 Iodine
Ioadine [20] is DNS tunneling tool that works on Windows, MAC and Linux operating
systems. Ioadine is a piece of software that lets us tunnel IPv4 data through a DNS
server. Erik Ekman and Bjorn Andersson maintain the Iodine application. Iodine is
similar to a client-server application. There is the server executable iodined and the
client executable iodine.
Iodine creates tunnel interfaces on the client and server. Any traffic can be sent over
the tunnel and can be initiated from the client or server.
2.2.5 DNS2tcp
Dns2tcp [22] is a network tool designed to relay TCP connections through DNS traffic
that works on Windows and Linux operating systems. Encapsulation is done on the
TCP level, thus no specific driver is needed Dns2tcp client does not need to be run
with specific privileges.
Dns2tcp is composed of two parts: a server-side tool and a client-side tool. The server
27
has a list of resources specified in a configuration file. Each resource is a local or
remote service listening for TCP connections. The client listen on a predefined TCP
port and relays each incoming connection through DNS to the final service
2.2.6 DNScat2
DNScat2 [21] Tool that works on Windows, MAC and Linux operating systems. It
provides a bi-directional communication through DNS servers, and in conjunction
with PPP, can be used to set up a virtual private network (VPN). DNScat, can be used
for a variety of purposes, including:
Penetration testing of networks behind firewalls
Sending messages though firewalled networks
Setting up a VPN though firewalled networks
Learning how to detect covert channels through DNS servers
The idea of DNScat was started by NSTX, which performs IP tunneling over DNS.
The functions of the above programs are similar, although they differ in many design
and implementation issues.
DNScat is a small program, written in the spirit of UNIX tools: small, command line,
flexible, highly configurable and thus powerful. On the other hand, DNScat is written
in Java and uses several open-source libraries, thanks to which DNScat has extremely
small footprint and its source code is easy to understand.
There is a DNScat2 Server program which listen to the requests from the DNScat2
Clients, when a new request arrived, a tunnel will be built between the client and the
server, then using this tunnel the client send DNS request to the victim client with the
28
wanted command, the DNS request that will be sent using this tunnel with the
following characteristics:
A lot of request will be send with unknown domain name like
dnscat.025b017e020c936a600a02004031c2c1b5
Figure 6 DNScat2 Request

DNS Requests of the types: CNAME, MX or TXT, which is not, used a lot in
the normal networks.
Figure 6 DNScat2 Records Type

Fixed TTL Field.
Figure 7 DNScat2 Fixed TTL
29
CHAPTER 3: PROJECT ANALYSIS
3.1 Existing similar systems
3.1.1 Packetbeat and Watcher
Elastic search is a highly scalable open-source full-text search and analytics engine. It
allows us to store, search, and analyze big volumes of data quickly and in near real
time. It is generally used as the underlying engine/technology that powers applications
that have complex search features and requirements [7].
Packetbeat is an open source packet analyzer. It monitors the traffic on the network
and indexes the DNS requests and responses into Elasticsearch where aggregations can
be used to help make sense of the data
Watcher is a plugin for Elasticsearch that provides alerting and notifications based on
changes in the data.
There are many use cases for alerting on data collected by Packetbeat such as alerting
when the response times for web requests are above a threshold or when there is spike
in HTTP errors returned by the web servers. Moreover, alerting about applications in
detecting DNS tunnels.
Using Packetbeat, there are many different techniques that can be employed for
detecting such traffic. DNS tunneling utilities must use a new hostname for each
request that leads to a much higher number of hostnames present for the malicious
domains in comparison to legitimate domains, the Figure 9 below show the location
of Packetbeat tool.
30
Figure8 Location of Packetbeat Tool
Then the watcher is used, using Elastic search watcher plugin we can create a watch
file that has a set of aggregations to be used as the input to the watch. For example, we
can find the cardinality of the hostnames associated with each second-level domain
(e.g. university.com.).
3.1.2 SNORT
Snort is an open-source, free and lightweight network intrusion detection system
(NIDS) software for Linux and Windows to detect emerging threats. Snort has the
ability to perform real-time traffic analysis and packet logging on Internet Protocol
(IP) networks. Snort performs protocol analysis, content searching and matching.
These basic services have many purposes including application-aware triggered
quality of service, to de-prioritize bulk traffic when latency-sensitive applications are
in use [8].
The program can also be used to detect probes or attacks, including, but not limited to,
operating system fingerprinting attempts, common gateway interface, buffer
overflows, server message block probes, and stealth port scans [9].
According to [10] snort signatures can be created to alert when large number of TXT
DNS requests occurs over a short period of time and also give alerts on multiple large
31
DNS requests, or large number of DNS requests going to a single domain. He also
suggests that organizations should implement split DNS. This is where the client side
systems cannot be able to resolve external domains and instead web proxies are used
resolve external domains for web browsing. This is because it prevents external DNS
requests from exiting the internal network.
3.1.3 Splunk
DNS Tunnels will generate thousands upon thousands of requests to a specific domain,
use uncommon recorded types, send keep-alives, or have very long host names.
A tool such as Splunk can help capture and analyze all the DNS data generated by an
organization. Splunk is commercial software used to consume large datasets and
provide keyword searching capabilities, dashboarding, reporting, and statistical
analysis.
Splunks search speed is based on MapReduce developed at Google in 2004 [11].
Splunk can consume almost any type of data. Splunk has many built in field extractions
for common data such as Windows event logs and Apache web logs. A field extraction
is simply a way of normalizing data into common fields, making it easier to analyze.
Example field extractions are time, hostname, IP address, destination, etc. If a prebuilt
field extraction does not exist, the Splunk administrator can write their own. Field
extraction is important because it provides context for an event. One of the most
important field extractions is time. The organization needs to find when an event
occurred. Another important field extraction is the IP address. With Splunk, the
administrator can query the index for X IP addressed during Y timeframe. Field
extractions also make it easier for the analyst to perform statistical analysis on the data.
Splunk offers a Free Enterprise version with a 500-megabyte data limit every 24 hours.
32
Some limits of the free license version are no login credentials and real-time alerts.
There are no restrictions on collecting different types of data. Splunk Enterprise has
no operational restrictions and is licensed by how much data is collected in a 24-hour
period. The license size can be as small as one gigabyte and as large as multiple
terabytes.
Splunk by itself is an extremely powerful platform, and by using Splunk apps, Splunk
can be even more powerful. In Splunk, the name app is short for application. A Splunk
app is a prebuilt package for specific functions or a defined data set. For example, a
firewall vendor develops a Splunk App for their firewall platform. The app may
contain prebuilt field extractions, dashboards, reports, lookup tables, and alerts [12].
The Splunk analyst saves time by not having to create the vendor specific elements
themselves. Apps also allow analysts who are not Splunk experts to start extracting
value from the data.
Sometimes there is not a way to retrieve data from an endpoint and send to Splunk. It
could be due to a technical, political, or security issue. Splunk has developed an app
called Splunk Stream. The app collects data directly off the network wire and decodes
it. In the case of analyzing DNS packets, Splunk stream can use a mirror port and
collect all DNS transactions off the network wire. The analyst can then query the data
looking for specific events and then alert or report on them. Stream installs on a Splunk
server and universal forwarder. The universal forwarder is installed as a data collection
agent on servers and does more than just run the Stream app. The universal forwarder
uses the stream technology add-on app, which collects and forwards the data to the
Splunk server. Think of using the universal forward agent as sensors around the
network. The Stream app for the Splunk server contains a collector and dashboards
displaying network metrics.
33
3.2 METHODOLOGY
Because we want to build a professional software, it is so important to use a SDLC
model (Software Development Lifecycle), because it breaks down the development
process into a sequence of phases or stages that make it easier to us as developers to
manage.
There are many different SDLC models and methodologies such as Waterfall model,
In the Waterfall model, the whole process of software development is divided into
separate phases. In the Waterfall model, typically, the outcome of one phase acts as
the input for the next phase sequentially, the Waterfall model is a good choice to
develop software and we will use it in our project.
Figure 9 Waterfall model
34
As shown in Figure 10, the Waterfall Model is consist of the following phases:
Requirements gathering: all requirements of the system to be developed are
captured in this phase.
Analysis: during this phase , we must respond to such questions:
o Who uses system?
o What will it do?
o Where and when the system work.
Design: describes how the proposed system is to be built. The design is specific
to the technical requirements the system will be required to operate in and the
tools used in building the system.
Development: in this step, the system is created. To create the system,
programming can be done in the traditional manner of writing lines of code or
accelerated by the use of tools and templates.
Testing: during this phase all aspects of the system are tested for functionality
and performance.
Maintenance: Once the system is put into place, maintenance is required to
ensure satisfactory operation.
3.3 APPLICATION REQUIREMENTS
3.3.1 Users of the System
In our system, we only have one type of users who is the Administrator of the system
who can view and maintain the warnings about DNS tunnels.
3.3.2 Functional and Non-Functional Requirements
35
3.3.2.1 Functional Requirements
The System shall be able to detect the DNS tunnels.
1. The system shall be managed only by authorized admins.
2. The Admin of the System shall be able to show the source of the detected DNS
tunnels.
3. The Admin of the System shall be able to stop the DNS tunnels.
4. The Admin of the System shall be able to choose any Network card of the
machine.
5. The Admin of the System shall be able to view statistics about DNS normal
messages and DNS detected tunnels.
6. The Admin of the System shall be able to save the DNS traffic at any time.
3.3.2.2 Non-Functional Requirements
1. The System shall be able to run continually
2. The System shall be fault tolerant (recover from system crashes and
initializations).
3. The System shall be able to resist subversion and to be immune to general
attacks.
4. The System shall be able to impose a minimal overhead on the system where
it is running.
5. The System shall be able to detect and prevent a large number of DNS tunnels
3.3 DNS TUNNELING MITIGATION TECHNIQUES
There are multiple detection techniques to find DNS tunnels. The two main detection
techniques are payload analysis and traffic analysis. Payload analysis comprises of
36
various techniques such as the size of a DNS request and response, the entropy of the
Fully Qualified Domain Name (FQDN), statistical analysis, infrequent record types,
and unauthorized DNS servers. Traffic analysis encompasses analyzing volumes of
DNS requests by IP address, domain, or hostname. Other traffic analysis techniques
include geographic locations of DNS servers, in this section we will provides a more
thorough understanding of how this mitigation techniques works
3.3.1 Payload Analysis
3.3.1.1 Unauthorized DNS Servers
One of easiest ways to detect DNS tunneling is to determine which systems are valid
DNS servers and block any other DNS service. The organizations security policy
should dictate what DNS servers are accessible to the hosts on the local network.
Forcing all clients to use a restricted set of DNS servers helps narrow where DNS
traffic is inspected and analyzed.
3.3.1.2 Statistical Analysis
A company offering services on the Internet wants to make it easy for consumers to
access their services. It makes sense that companies will use a DNS name that is easy
to remember and as short as possible. Analyzing the length of the FQDN can help
determine which domains are malicious. There could be millions if not billions of DNS
requests to analyze on an organizations network, DNS tunnels are detected by
calculating the standard deviation. [13]. the standard deviation formula can show what
DNS requests are not normal on the organizations network.
3.3.1.3 Infrequent Record Types
The most common record types for DNS are A, PTR, MX, CNAME, TXT, NS, and
SOA records. Infrequent record types are AAAA, AXFR, and DNSKEY. The Sender
37
Policy Framework (SPF) relies on TXT record types to reduce email spam. TXT record
requests should only be coming from network hosts that require this type of lookup. If
TXT records are increasing and not coming from a valid source such as a mail gateway,
this is a red flag. The analyst should investigate the event further.
3.3.1.4 Host Name Entropy
Entropy describes the randomness of a string. In the case of DNS names, Domain
Generating Algorithms create random hostnames such as
asasdlfkjasdflwerjka.t1.security.local.
The more randomness in the string creates a higher the entropy. The less randomness,
such as www.sans.org, the lower the entropy score.
There are different formulas for entropy. The most common entropy formula for this
use case is related to computer science and was developed by Claude Shannon [24].
3.3.2 Traffic Analysis
3.3.2.1 Volume of DNS Requests
Similar to finding rare record types such as Null and SRV, just performing a simple
count of top domains can detect a tunnel. Parsing out the hostname and subdomains
from the FQDN allows the analyst to perform additional metrics. The newly parsed
fields could be the hostname, subdomain name, the domain name, or the top level
domain. Since a tunnel will create a tremendous amount of DNS requests when
transferring a file, one can assume a simple count may result in outliers.
38
3.3.2.2 Geographic Location
Another way to detect unwanted DNS requests is to see where in the world the requests
are forwarding. The analyst should investigate DNS requests resolving to DNS servers
outside the organizations geographic area. If the organization does not conduct
business in X country, does it make sense for DNS requests to be going there?
39
Chapter 4. PROJECT DESIGN
4.1 COMPARISON OF DNS IMPLEMENTAIONS
In this section we provide the following table which compare this implementations
according to the authoritative type support, recursive type support, caching, IPv6
support, used Interface, whether it is free or not and supported operating systems.
Implementation Authoritative Recursive Caching IPv6 Free Interface OSs
AnswerX No Yes Yes Yes No Command Linux
Line, API
BIND Yes Yes Yes Yes Yes Command Linux,
Line, Web Windows
, MAC
PowerDNS Yes Yes Yes Yes Yes Command Linux,
Line, Web MAC
Microsoft DNS Yes Yes Yes Yes No Command Window
Line, Web, s
GUI
Simple DNS Plus Yes Yes Yes Yes No Command Window
Line, Web, s
GUI
YADIFA Yes No Yes Yes Yes Command Linux,
Line MAC
Table 3 DNS Implementation Comparison
40
In our project, we want to run a DNS implementation on several DNS server, which
we need it to support authoritative type, caching and recursive type and we want to run
it on a Linux machine, BIND is by far the most widely used DNS software on the
Internet, providing a robust and stable platform on top of which organizations can build
distributed computing systems with the knowledge that those systems are fully
compliant with published DNS standards [2].
BIND is transparent open source. Which has evolved to be a very flexible, full-featured
DNS system. Whatever the application is, BIND most likely has the features required,
so we will use BIND as the DNS Server implementation in our project.
4.1.1 BIND DNS Software
4.1.1.1 Domain Name Resolver
A resolver is a program that resolves questions about names by sending those
questions to appropriate servers and responding appropriately to the servers replies.
In the most common application, a web browser uses a local stub resolver library on
the same computer to look up names in the DNS. That stub resolver is part of the
operating system. (Many operating system distributions use the BIND resolver
library.) The stub resolver usually will forward queries to a caching resolver, a server
or group of servers on the network dedicated to DNS services. Those resolvers will
send queries to one or multiple authoritative servers in order to find the IP address for
that DNS name.
41
4.1.1.2 Domain Name Authority Server
An authoritative DNS server answers requests from resolvers, using information
about the domain names it is authoritative for. We can provide DNS services on the
Internet by installing BIND software on a server and giving it information about
domain names.
4.2 CHOSEN DNS TUNNELING TOOL
The research in [23] tested all network configurations in terms of all metrics. Each test
has been repeated several times. Due to the lack of space, it 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
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.
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.
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, it is a highly configurable tool, so the
42
overhead can potentially be reduced by properly customizing the tool if the
network configuration is known.
Figure 11 [23] shows the average throughput in direct configuration, thus evaluating
the performance of the implementation of tools, independently from architectural
issues and network configuration.
Figure 10 DNS Tunneling Throughput
Iodine and Dnscat2. Both tunnel applications can bypass upstream DNS servers for
data transfer if the organizations perimeter allows unrestricted IP address access
outbound. By not having to send requests through the DNS infrastructure, data transfer
rates are even faster, because of its popularity and the easiness of install and maintain
we choose the DNScat2 as the DNS Tunneling tool we want to use in our project.
43
4.3 CHOSEN DNS TUNNELING METIGATION TECHNIQUES
After the Analysis study of DNS tunnels mitigation techniques, we decided to use the
following three to detect any DNS tunnel
1. Calculation of Hostname Entropy.
2. The numbers of packets with TXT record type.
3. The number of packets with Fixed TTL value.
4.3.1 Hostname Entropy calculation
The entropy can be calculated as a measure of randomness of DNS domain name, in
many cases the domain name are logical and make sense, while the encoded hostnames
that are generated by DNS tunneling tools are random so the entropy value of it will
be bigger than the entropy value of the normal domain name, the normal entropy of
the hostname should be between 2.0 and 4.0 [25], we can use Shannon Entropy
Algorithm to calculate this value which we will see in the implementation phase, The
Following table show some examples of some hostname and its entropy values:
Domain Name Entropy Value
www.google.com 2.84237
www.svuonline.org 3.45482
www.yahoo.com 2.81507
www.microsoft.com/en-us/windows 3.78114
www.apple.com/mac-mini/macos/ 3.65041
www.ghftyha76fdhkp76t319jajk.com 4.20281
Dnscat.54fghy67ujhg67865fh87 4.01219
Table 4 Hostname Entropy values
44
As shown in table 4 the entropy value of normal domain name such as
www.google.com is 2.84237, while the entropy value of the domain name that is
generated from DNScat tool Dnscat.54fghy67ujhg67865fh87 is 4.01219 [25].
4.4 SYSTEM DIAGRAMS
4.4.1 System Black Box
Figure 12 below show the attack scenario:
5) The Victim receive the message

and execute the command
4) The firewall let the message pass (DNS message)
3) Send through Internet
2) The DNS send the message to Firewall
DNS Server
1) The Attacker send a command to DNS Sever
Figure 11 DNS Tunnel Attack Scenario
45
Figure 13 below shows the system to detect this type of attacks and to prevent them
like the following:
5) Detect the DNS tunnel
8) The Client is Save
4) The firewall let the message pass (DNS message)

7) Block the Traffic
Our System
6) send a warning to Firewall
3) Send through Internet
2) The DNS send the message to Firewall
DNS Server
1) The Attacker send a command to DNS Sever
Figure 12 DNS Tunnel Mitigation Scenario
4.4.2 Use Case Diagram
This use case diagram describe DNS Tunneling Detection and Prevention system,
these are the primary function of the system for the Administrator, the person
who wants to monitor the DNS tunnels
46
Figure 13 Use Case Diagram

4.4.3 Data flow Diagram
The diagram in Figure 15 show us the flow of data in our program, first the data is
captured from the Network adapter, then we only take the DNS packets, Analyze the
packets using the mitigation techniques and detect the suspected tunnels and show it
to the admin who can block the source IP of the tunnel.
Figure 15 Data Flow Diagram

47
Chapter 5. PROJECT IMPLEMENTATION
5.1 DNS Tunnels Detector System Tasks
The tasks of the system can be summarized to 3 major points
1. Listening: Capturing all the packets that transfer from and to a specific network
adapter and filtering the DNS ones.
2. Analyzing: The program must be capable of analyze and show the captured
packets using the main GUI interface and to detect the IP source of the tunnel.
The Analyzing of the packets should use the DNS packet fields:
a. Source IP
b. Source Port
c. Destination IP
d. Destination Port
e. Length
f. Query Domain Name
g. Query DNS Type.
h. Answer IP
i. Answer DNS Type
j. Query TTL
k. Answer TTL
l. Entropy of Domain Name
3. Tunnel Prevention: communicate with the firewall to stop the tunnel using the
detected IP address and the Block Rule.
48
5.2DNS Tunnels Detector System Phases
The system GUI have to be clear and easy to use and which have this specification
The user shall be able to select any network adapter of its machine.
The program should show the captured DNS packets with its information
(Length, Source IP, Destination IP, Queries and Responses).
The program should alert the user of any detected tunnel.
The user shall be able to permit or prevent the packets of certain IP.
The ability of packets save in an external file.
As we mentioned before, the major phases of the DNS Detector system are:
1. Packet Capturing Phase
2. Tunnels Analyzing and Detecting Phase.
3. Tunnels Prevention Part.
5.2.1 Packet Capturing Phase
The capturing part is the most important part of the system. After the selection of the
network card the capture will be started between the host and the network connected
to it. We need to filter those packets and only capture the transmitted and received
DNS packets, which are the UDP packets with the port 53.
The system should show this packets to the user and should also start of captured
packets analysis, in this phase we will use the PcapDotNet library.
5.2.2 Tunneling Analyzing and Detecting Phase
The next phase is to analyze the captured packets in the previous phase in order to
detect any DNS Tunnel, as we mentioned in the analysis phase we will depend on 3
ways to detect a DNS Tunnel, which are Entropy of Hostname calculation, Analyzing
TTL Field and TXT Type monitoring
49
5.2.2.1 Entropy of Hostname calculation
By using an appropriate algorithm we will calculate the Entropy of the hostname in
each of the captured packets and define a threshold of this value. We choose the 4.0
value as the highest value of the host entropy. And we will alert the user when the
entropy of the hostname is bigger than 4 and we decided to use Shannon Entropy
algorithm, the following code is a c# code of this algorithm
public static double Calculate_Entropy(string s)

{
var map = new Dictionary<char, int>();
foreach (char c in s)
{
if (!map.ContainsKey(c))
map.Add(c, 1);
else
map[c] += 1;
}
double result = 0.0;
int len = s.Length;
foreach (var item in map)
{
var frequencey = (double)item.Value / len;
result -= frequencey * (Math.Log(frequencey) / Math.Log(2));
}
return Math.Round(result,5); //Rounding the Entropy to 5 decimal places
}
5.2.2.2 Analyzing TTL Field
The Analysis phase showed that the DNS tunnels tools like DNSCat use the TTL value
64, so we will monitor the TTL Field and alert the user about the number of DNS
packets with the 64 TTL value.

50
5.2.2.3 TXT Type monitoring
The Analysis phase showed that the DNS tunnels tools like DNSCat use the DNS
types: TXT, CNAME and MX, and Especially the TXT type, which isn't normally
used so we will monitor the TXT type and alert the user about the number of DNS
packets with the TXT type.
The System should apply each of the three rules to detect every tunnel and show the
list of detected tunnel to the user.
5.2.3 Tunneling Prevention
After DNS tunnel detecting, we show the source IP of the tunnel and provide the user
with the ability of forbid or permit this tunnel. By communicating with the Windows
Firewall.
5.3 System Implementation tools
With the increasing advanced in the technology world, especially in the IT and
programming area, we have a lot of programming languages, tools and environments
which can be used in the implementation phase of our system.
One of the best examples is C# programming language and its .Net Framework
5.3.1 C#
C# syntax is highly expressive, yet it is also simple and easy to learn. The curly-brace
syntax of C# will be instantly recognizable to anyone familiar with C, C++ or Java.
Developers who know any of these languages are typically able to begin to work
productively in C# within a very short time.
As an object-oriented language, C# supports the concepts of encapsulation,
inheritance, and polymorphism. All variables and methods, including the Main
method, the application's entry point, are encapsulated within class definitions. A class
51
may inherit directly from one parent class, but it may implement any number of
interfaces.
The C# build process is simple compared to C and C++ and more flexible than in Java.
There are no separate header files, and no requirement that methods and types be
declared in a particular order. A C# source file may define any number of classes,
structs, interfaces, and events.
Finally by using C# language, we can implement a large efficient software in many
computer science approaches such as networking, security, image processing and more
using an already build reliable classes and functions located in available libraries
without reinventing the wheel.
5.3.2 C# and .Net
C# programs run on the .NET Framework, an integral component of Windows that
includes a virtual execution system called the common language runtime (CLR) and a
unified set of class libraries. The CLR is the commercial implementation by Microsoft
of the common language infrastructure (CLI), an international standard that is the basis
for creating execution and development environments in which languages and libraries
work together seamlessly.
Source code written in C# is compiled into an intermediate language (IL) that conforms
to the CLI specification. The IL code and resources, such as bitmaps and strings, are
stored on disk in an executable file called an assembly, typically with an extension of
.exe or .dll. An assembly contains a manifest that provides information about the
assembly's types, version, culture, and security requirements.
When the C# program is executed, the assembly is loaded into the CLR, which might
take various actions based on the information in the manifest. Then, if the security
requirements are met, the CLR performs just in time (JIT) compilation to convert the
52
IL code to native machine instructions. The CLR also provides other services related
to automatic garbage collection, exception handling, and resource management. Code
that is executed by the CLR is sometimes referred to as "managed code," in contrast
to "unmanaged code" which is compiled into native machine language that targets a
specific system. The following diagram illustrates the compile-time and run-time
relationships of C# source code files, the .NET Framework class libraries, assemblies,
and the CLR.
Figure 14 .Net Framework
Language interoperability is a key feature of the .NET Framework. Because the IL
code produced by the C# compiler conforms to the Common Type Specification
(CTS), IL code generated from C# can interact with code that was generated from the
.NET versions of Visual Basic, Visual C++, or any of more than 20 other CTS-
compliant languages. A single assembly may contain multiple modules written in
different .NET languages, and the types can reference each other just as if they were
written in the same language.
In addition to the run time services, the .NET Framework also includes an extensive
library of over 4000 classes organized into namespaces that provide a wide variety of
useful functionality for everything from file input and output to string manipulation to
XML parsing, to Windows Forms controls. The typical C# application uses the .NET
53
Framework class library extensively to handle common "plumbing" chores.
Finally as a result we notice that: C# is a programming language, .NET is the
framework that the language is built on.
5.3.3 VS2015 IDE
Microsoft Visual Studio is an integrated development environment (IDE) from
Microsoft. It is used to develop computer programs for Microsoft Windows, as well as
web sites, web applications and web services. Visual Studio uses Microsoft software
development platforms such as Windows API, Windows Forms, Windows
Presentation Foundation, Windows Store and Microsoft Silverlight. It can produce
both native code and managed code.
Our project classified as networking project, so we need to use some special C#
networking libraries like PcapDotNet Library.
5.3.4 PcapDotNet Library
PcapDotNet Library is a .NET wrapper for WinPcap written in C++/CLI and C#,
which features almost all WinPcap features and includes a packet interpretation
framework.
Packet capturing (or packet sniffing) is the process of collecting all packets of data that
pass through a given network interface. Capturing network packets in our applications
is a powerful capability which lets us write network monitoring, packet analyzers and
security tools. The libpcap library for UNIX based systems and WinPcap for Windows
are the most widely used packet capture drivers that provide API for low-level network
monitoring. Among the applications that use libpcap/WinPcap as its packet capture
subsystem are the famous tcpdump and Wireshark.
As an example a Pcap.Net-based application can get a list of attached network
adapters. Pcap.Net provide the LivePacketDevice.AllLocalMachine static property for
54
this purpose: this property returns a collection of LivePacketDevice instances, each of
which contains comprehensive information about an attached adapter. In particular,
the fields name and description contain the name and a human readable description of
the device.
The following code retrieves the adapter list and shows it on the screen, printing an
error if no adapters are found.
using System;
using System.Collections.Generic;
using PcapDotNet.Core;
namespace ObtainingTheDeviceList
{
class Program
{
static void Main(string[] args)
{
// Retrieve the device list from the local machine
IList<LivePacketDevice> allDevices =
LivePacketDevice.AllLocalMachine;
if (allDevices.Count == 0)
{
Console.WriteLine("No interfaces found! Make sure WinPcap is
installed.");
return;
}
// Print the list

for (int i = 0; i != allDevices.Count; ++i)
{
LivePacketDevice device = allDevices[i];
Console.Write((i + 1) + ". " + device.Name);
if (device.Description != null)
Console.WriteLine(" (" + device.Description + ")");
else
Console.WriteLine(" (No description available)");
}
}
}
}
55
First of all, LivePacketDevice.AllLocalMachine, like other Pcap.Net methods, can
throw an exception with a description of the error if something goes wrong.
Second, not all the OSes supported by libpcap provide a description of the network
interfaces, therefore we must consider the case in which description is null: we print
the string "No description available" in that situation.
5.4 System Implementation
We used this techniques to build our application:
Programming Language: C# language.
Environment: .NET Framework 4.5.
Developing Tool: VS2015 IDE.
5.4.1 WinPcap and pcapdotnet installation
First of all, for our program to work on any computer, we should install WinPcap
environment, which is used to capture the packets.
After the installation process we should add the pcapdotnet dll files to the references
of our project, first of all we press the right button of mouse on references and get the
following list
Figure 15 Add a Reference
56
We choose "Add Reference" and get the following window
Figure 16 Add PcapDotNet files
We add the following dll files
PcapDotNet.Analysis.dll
PcapDotNet.Base.dll
PcapDotNet.Core.dll
PcapDotNet.Packets.dll
57
Figure17 PcapDotNet Files
Now we can use the library using "using"
Figure18 using PcapDotNet Library
58
5.4.2 PcapDotNet packets capturing and analyzing
Using PcapDotNet, we can open an adapter and capture the traffic.
The function that opens a capture device is Open(). The parameters are
snapshotLength, attributes and readTimeout.
snapshotLength specifies the portion of the packet to capture. On some
OSes (like xBSD and Win32), the packet driver can be configured to
capture only the initial part of any packet: this decreases the amount of data
to copy to the application and therefore improves the efficiency of the
capture. In this case we use the value 65536 which is higher than the
greatest MTU that we could encounter. In this manner we ensure that the
application will always receive the whole packet.
attributes: the most important flag is the one that indicates if the adapter
will be put in promiscuous mode. In normal operation, an adapter only
captures packets from the network that are destined to it; the packets
exchanged by other hosts are therefore ignored. Instead, when the adapter
is in promiscuous mode it captures all packets whether they are destined to
it or not. This means that on shared media (like non-switched Ethernet),
Pcap.Net will be able to capture the packets of other hosts. Promiscuous
mode is the default for most capture applications, so we enable it in our
project.
readTimeout specifies the read timeout, in milliseconds. A read on the
adapter (for example, with ReceiveSomePackets() or ReceivePacket()) will
always return after readTimeout milliseconds, even if no packets are
available from the network. readTimeout also defines the interval between
59
statistical reports if the adapter is in statistical mode. Setting readTimeout
to 0 means no timeout, a read on the adapter never returns if no packets
arrive. A -1 timeout on the other side causes a read on the adapter to always
return immediately.
Using PcapDotNet, we will capture the UDP packets with the port 53 (DNS packets)
on a specific Network Adapter, by defining a Packet Handler which capture and
process the packets like the following:
Defining Strings that defines DNS protocols Fields.
View this Fields and its value to the user in a table.
Define counters that monitor the tunnel
o int Entropy_limit = 20;
o int Ttl_limit = 20;
o int Txt_DNSType_limit = 20;
When we have packets from the same source (source IP address) and match
one of the previous condition and Exceed 20 packets, the user will be alerted
about a possible tunnel
We define three types of datagrams: IP, UDP and DNS to analyze the packets
deeply, which has the strings:
a. Source IP
b. Source Port
c. Destination IP
d. Destination Port
e. Length
f. Query Domain Name
g. Query DNS Type.
60
h. Answer IP
i. Answer DNS Type
j. Query TTL
k. Answer TTL
l. Entropy of Domain Name
We define the function that calculate the entropy of the function using
Shannon Entropy algorithm
Public static double Calculate_Entropy(string s)

{
var map = newDictionary<char, int>();
foreach (char c in s) {
if (!map.ContainsKey(c))
map.Add(c, 1);
else
map[c] += 1; }
double result = 0.0;

int len = s.Length;
foreach (var item in map)
{
var frequencey = (double)item.Value / len;
result -= frequencey *
(Math.Log(frequencey) / Math.Log(2));
}
returnMath.Round(result,5); //Rounding the
Entropy to 5 decimal places
}
61
5.5 System GUI
Figure 19 System GUI
1) Network Adapter
Figure 20 Network Adapter List
The program read the Network Adapters of the host and add it to the Adapters_List
List and then show it to the user.
An error message will appear if:
62
There isn't WinPcap environment installed on the host.
There aren't any active Network Adapter.
2) Start Listening
Figure 21 Start Listening
The user can click on the "Start" button, then the program will start the listening phase,
and the button label will be changed to "Stop".
Figure 22 Stop Listening
An error message will appear if, the user didn't choose any network Adapter.
3) Captured DNS packets Table
Figure 23 Capture DNS Packets
63
This table show the following field to the user:
Length: the packet length.
Source: Source IP Address.
Destination: Destination IP Address.
Queries: The Domain Name of the Query.
Answers: The Domain Name of the Answer.
4) DNS packet Details
Figure24 DNS packets Details
This box show the following packet details to the user:
Source Port
Destination Port.
Query Type.
Answer Type.
Query TTL.
Answer TTL.
Hostname Entropy.
64
5) Clear Table
Clear all the table Data
Figure 25 Clear Table
6) Save Capture
Figure 26 Save Capture
The user can click on the "Save Capture" button, then the program will call
SaveCapture() function which save the packets in a csv (comma separated value) file.
A window appear to the user to choose an appropriate save path.
65
Figure 27 save Capture Window
The file will be something like this.
Figure28 Save Capture File
66
7) Suspected Tunnels IPs
This table show the Suspected Tunnel IP to the user with the exceeded thresholds.
Figure29 Suspected Tunnels IPs
Example after creation of tunnel between 192.168.1.114 and 192.168.1.112
Figure30 Detect a Tunnel Example
67
8) IP with DNS Tunnels
This table show the Suspected Tunnel IP with its status:
Blocked: The IP is blocked.
Open: The IP is not blocked.
Figure31 IP with DNS Tunnels Table
Figure32 Block IP
Figure33 Unblock IP
68
9) Block/Unblock Button
The user can click on the "Block" button, then the program will create a Firewall Rule
on the host with the specification:
Outbound Rule.
Protocol: UDP.
Port: 53.
Action: Block
Rule Name: TunnelBlock-IP.
Which block the DNS traffic (port 53) from the specified IP.
Block Command:
netsh advfirewall firewall add rule name=\TunnelBlock-{0}\
dir=out interface=any protocol=udp remoteport=53 action=block
remoteip={0}, IP
Unblock Command:
netsh advfirewall firewall delete rule name=\TunnelBlock-{0}\,IP
An error message will appear if, the user didn't choose any IP from the table.
Figure34 Firewall Rule
69
Figure35 Firewall Rule Proporties
10) File Menu
Figure 36 File Menu
70
The File menu provide the User with three different options
New: Close the current Window and open a new Window, a message to save
the capture will be appeared too.
Figure37 Save Capture Dialogue
Save Capture: Save the capture of the current session.

Exit: Close the program.
11) Help Menu
About: Show information about the program
Figure38 Help Menu
Figure39 About Message
71
Chapter 6. TESTING
6.1 Used Resources
To apply the needed test, we used the following resources:
PC1, which have windows Operating System.
VMWare program installed on the PC1.
Virtual Machine VM1, hosted in the PC1 and has Windows 7 operating
System.
VM1 machine will have the DNS tunnel client
Virtual Machine VM2, hosted in the PC1 and has Linux Ubuntu operating
System.
VM2 machine will have the DNS tunnel Server.
A LAN to connect the different machines with each other.
DNSCat2 program to create the DNS Tunnel.
Windows Firewall program is hosted on the PC1.
Our Program "DNS Shield" is hosted on PC1.
"DNS Shield" is used to capture the traffic and detect the tunnel.
72
6.2 Tests
6.2.1 First Test
In this test we want to evaluate the ability of our program to detect a DNS Tunnel, we
have the PC1, which is located between VM1 which have the DNSCat2 Client and
DNScat2 Server.
Figure 40 First Scenario
1. Environment Setup
1) VM2 (DNS Tunnel Server) Setup
VM2 is a PC with Ubuntu 16.04 operating system. Which is setup to create
DNS Tunnels using the following steps
1. From Terminal using root privileges we execute the following command
(from https://zeltser.com/c2-dns-tunneling/).
apt-get update
apt-get -y install ruby-dev git make g++
gem install bundler
73
git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server
bundle install
2. In case we don't have the latest package of rubygems on the operating
system, we execute the following command to update it
gem install rubyems-update
update _rubygems
gem update --system
The previous commands will install DNSCat2 Server on the machine.
3. To create the DNS Tunnel, we execute the following command using root
privileges
ruby ./dnscat2.rb
4. After that the Server will start listening to the port of DNS (53) and wait
for the clients to open the connection with it.
74
Figure41 Tunnel Server Start
5. After any client open a new connection with the server, the latter will open
a new window like the following
And a random text will appear at the server side and the client side.
6. In case of an error message that show that the port is taken when we are
trying to create the tunnel
75
This means that we have an old process that is listening on the port 53 and we
should search about process ID (PID) and end this process, to find the process
ID we use the following command:
Netstat lnp
And to end the process we use the following command
Kill -9 12362
76
2) VM1 (DNS Tunnel Client) Setup
VM1 is a PC with Window 7 operating system. Which is setup to create DNS
Tunnel Client using the following steps
1. Setup the networking configuration
Figure42 VM1 Configuration
The type of the host is "NAT", and the IP Address is generated automatically from the
DHCP Server, "NAT" means that the IP of the host will be translated to the IP of the
PC when we want to connect to the Internet.
As show in the figure below, the VM1 host get the IP address 192.168.50.10 with the
mask 255.255.255.0 and the gateway 192.168.50.2.
77
Figure43 VM1 IP
Now we can ping any outside IP as Example we ping the well-known IP the DNS
Server of Google Company (8.8.8.8)
Figure44 VM1 Ping
2. Download and Install the DNSCat2 Client program " dnscat2-v0.07-
client-win32" from https://downloads.skullsecurity.org/dnscat2/
3. Now we want to connect with the DNSCat2 Server that installed on
the machine (VM2) using this commands in the cmd
cd desktop
dnscat.exe --dns server=192.168.1.104port=53
When the 192.168.1.104 is the IP address of the server.
78
Figure45 Client Session establishment
The connection now is established and we notice that the same random text is
generated at the client machine, which use the port 53 and the IP 192.168.1.104 using
the TXT, CNAME and MX DNS Types as DNS Query Types.
6.2.1.2 DNS Shield (Start Capturing)
After the two previous steps, the DNS Tunnel will be established, in this step
we want to capture the DNS Tunnel traffic in order to detect it
Figure 46 start Capturing Scenario
79
We run our program "DNS Shield" and start listening on Wireless Network Adapter
Figure47 DNS Shield Listening on Tunnel
The network of the host is Natted, so the send and received packets will be have the IP
192.168.1.103, the figure above show that we have some packets that are transmitted
between PC1 and PC2 (192.168.1.104) with random domain names in the Queries and
in the responses and we have a lot of TXT DNS Type messages and we also have the
Entropy values bigger than the normal value which is 4.0.
Figure48 DNS Shield Listening on Tunnel Details
80
Figure49 Entropy violation

When any condition is broken (some values became bigger than the defined threshold),
The IP of the DNS Tunnel will appear.
Figure50 IP Tunnel Detection
The program can distinguish between the client and the server because the server send
answers to the client as responses to the queries.
When the IP Address of the tunnels appears, the user could block this IP
81
Figure51 Block the IP tunnel
The block process will add a new Firewall Rule to stop all the packets from the server
with this IP from the port 53
Figure52 unblock the IP tunnel
Block
Figure53 Add the Firewall Rule

82
Firewall properties
The IP
Address of
the Server
Figure 54 Firewall proproties
83
UDP 53
Figure55 Firewall rule poroporties
When we block the IP, the client will retry to connect to the server but the server won't
answer it so the client will close the Connection.
Figure56 Client Blocked
In this way our program manage to detect and prevent the DNS Tunnel
84
Figure 57 Tunnel blocked
The user can unblock the IP after blocking it by clicking on the "unblock" button which
will delete the rule from the Firewall.
6.2.2 Second Test
The purpose of this test is to simulate a real network, which will have PCs that generate
normal DNS Requests (without any tunnel) and the PC which will generate the tunnel.
Figure 58 Second Test Scenario
85
6.2.2.1 Virtual Machine Setup
The virtual machine of Normal DNS requests is installed with Ubuntu operating
system, which its purpose is to send a lot of DNS Request.
To implement this mission we write the DNSTester program which read the
Domain Names from a text file (domains.txt) and execute the "nslookup" for each
domain one after another in an infinite loop.
Figure 59 Test Files
namespace DNSTester
{
class Program
{
public static int interval = 1;
[STAThread]
static void Main(string[] args)
{
Begin:
Console.WriteLine("Enter interval in seconds");
try { interval = Convert.ToInt32(Console.ReadLine()); }
catch { goto Begin; }
Console.WriteLine("Would you like to repeat when all hosts were
checked? (y/n)");
bool repeat = Console.ReadLine().ToLower() == "y" ? true :
false;
OpenFileDialog fd = new OpenFileDialog();
//fd.ShowDialog();
if (fd.ShowDialog() == DialogResult.OK) {
Loop:
foreach (var line in File.ReadAllLines(fd.FileName)) {
Console.WriteLine(line + " => " +
Dns.GetHostAddresses(line)[0].ToString());
Thread.Sleep(interval * 1000); }
if (repeat)
goto Loop; }
}
}
}
86
this is the content of the Text file
Figure 60 Text File Content
To use this program we had to install the Mono package
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys
3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee
/etc/apt/sources.list.d/mono-xamarin.list
sudo apt-get update
6.2.2.2 The program Run
We will use the command "mono DNSTester.exe ", which give the user the choice
of the time interval between two different queries and the choice of repetition and
ask the user about the text file that have the domain names.
87
Figure61 DNSTester Run
Then the program will be running
Figure62 DNSTester Running
88
By using our program DNS Shield on the PC1 to capture the traffic of the program
Figure63 Capturing Normal Packets
6.2.2.3 Tunnel Creation
After we run the DNSTester program, we run the tunnel like the previous test
Figure64 New Tunnel Creation
89
6.2.2.4 DNS Shield (Start Capturing)
The program start listening on the Wireless Network Adapter, we notice the DNS
Tunnel packets alongside the normal DNS Requests
Figure65 Capturing Normal and Tunnel Packets
The program find the source of the tunnel
90
Figure66 Find the Tunnel
91
After we block the source of the tunnel (192.168.1.104), it will stop the packets from
the source while we still have the packets from the Normal source
So our program could find and stop the up normal tunnel while he allow the normal
action (normal DNS queries).
Figure 67 Tunnel Stop
6.3 Test in real networks
In the ISPs, the Telecommunication companies, banks and any big company, there are
a lot of users, so we need to use a firewall to separate the users of the company from
the internet and to organize the transmission of data between them.
As Example we have the IPtables firewall in the Linux based operating system and the
Microsoft Internet Security & Acceleration Server in the Windows based operating
system.
92
As Example we have ISA Server which is located between the users and the Internet
and which control the access to the internet from the inside of the network and the
access to the inside of the network from the Internet by defining the suitable rules and
it also help us with the Bandwidth usage control.
ISA Server can host a program like our program "DNS Shield" which can run as we
see in the previous section.
Figure 68 Real Network Test
93
Chapter 7. CONCLUSION AND SUGGESTION
7.1 SUGGESTION
The suggestions to this project are to make an update, to add something new or avoid
the unwanted malicious attacks or avoid the hackers from destroying, stealing my
informations. Taking feedback from project administrator. See what other tunneling
attacks work and improve our application to detect and prevent them as well.
7.2 CONCLUSION
In this report, we introduced the project backgrounds, project goals and project
organization, a literature review of the DNS service and DNS tunneling tools, project
analysis and project design which will be properly used to implement the project in the
Implementation phase.
94
BIBLIOGRAPHY
[1] Akamai Technologies, Inc. (2015, July), Carrier-Grade Advanced Recursive DNS,
AKAMAI WHITE PAPER [Online]. Available:
https://www.akamai.com/us/en/multimedia/documents /white-paper/akamai-carrier-
grade-advanced-recursive-dns-white-paper.pdf
[2] Internet Systems Consortium (2013), BIND 9 Administrator Reference Manual
[Online]. Available: https://www.isc.org/downloads/bind/doc/bind-9-9/
[3] PowerDNS.COM (2014) PowerDNS documentation [Online]. Available:
https://doc. powerdns.com/md/
[4] Microsoft.COM (2014, July 3), Domain Name System (DNS) Overview [Online].
Available: https://technet.microsoft.com/en-us/network/bb629410.aspx
[5] Simple DNS PLUS (2013), Simple DNS PLUS help overview [Online]. Available:
http://www.simpledns.com/help/v52/
[6] YADIFA official Website (2016), YADIFA Reference manual version 2.2.1
[Online]. Available: http://www.yadifa.eu/documentation
[7] Elasticsearch Inc. (2016), Elasticsearch Reference [5.0] Getting started [Online].
Available: https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-
started.html
[8] SNORT Users Manual 2.9.8.2 (March 18, 2016), the Snort Project [Online].
Available: https://s3.amazonaws.com/snort-org-
site/production/document_files/files/000/000/100/
original/snort_manual.pdf?AWSAccessKeyId=AKIAIXACIED2SPMSC7GA&Expir
es=1481074039&Signature=UCgwFPIssHYFGirFDyWi4EzMyCM%3D.
95
[9] Mohan Krishnamurthy; et al. (2008). "4. Introducing Intrusion Detection and
Snort". How to Cheat at Securing Linux. Burlington, MA: Syngress Publishing Inc.
Retrieved 2010-06-24.
[10] Miller, T. (2005). Reverse DNS Tunneling Staged Loading Shellcode. [Online].
Available:
www.blackhat.com/presentations/bh-usa-
08/Miller/BH_US_08_Ty_Miller_Reverse_DNS _Tunneling_Shellcode.pd
[11] Sorkin, S. (2011). Splunk Technical Paper: Large-Scale, Unstructured Data
Retrieval and Analysis [Online]. Available:
https://www.splunk.com/web_assets/pdfs/secure/Splunk_and_ MapReduce.pdf
[12] Splunk. (n.d.). Build Splunk apps. Retrieved May 14, 2016, from dev.splunk.com:
http://dev.splunk.com/view/get-started/SP-CAAAESC
[13] Brant, S., & Kovar, R. (2015). Detecting DNS Spoofing, DNS Tunneling, DNS
Exfiltration. Retrieved April 30, 2016, from github.com:
https://github.com/rkovar/dns_detection/blob/ master/known_unknown_DNS.pdf
[14] Rasmussen, R. (2012, April 03). Do you know what your DNS resolver is doing
right now? [Online]. Available: http://www.securityweek.com/do-you-know-
whatyour-dns-resolver-doing-right-now
[15] Dan Kaminsky (2004, July 29). OzymanDNS Tool release [online]. Available:
https://dankaminsky.com/?s=ozymanDNS
[16] IVC Wiki (2009, September 16). Socks via SSH over DNS [Online]. Available:
http://beta.ivc.no/wiki/index.php/DNS_Tunneling
96
[17] Scenario Development Environment (SDE), dnscapy utility [Online]. Available:
http://www.itec-sde.net/en/applications/dnscapy
[18] Security Power Tools (2007, August). Scapy Tool overview [Online]. Available:
[http://www.secdev.org/projects/scapy/
[19] Heyoka official website. Heyoka overview [Online]. Available:
http://heyoka.sourceforge.net/#documentation
[20] Ekman, E., & Andersson, B. (2014, June). Manpage of Iodine [Online]. Available:
http://code.kryo.se/iodine/iodine_manpage.html#index
[21] Ron Bowes (2004), DNScat Utility official documentation [Online]. Available:
http://tadek.pietraszek.org/projects/DNScat/
[22] Herve shauer. dns2tcp utility [Online]. Available:
http://www.hsc.fr/ressources/outils/ dns2tcp/index.html.en
[23] A. Merlo, G. Papaleo, S. Veneziano and M. Aiello, "A Comparative Performance
Evaluation of DNS Tunneling Tools", Computational Intelligence in Security for
Information Systems, pp. 84-91, 2011.
[24] Kovar, R. (2015, October 1). Blogs: Security Random Words on Entropy and DNS.
[Online]. Available: http://blogs.splunk.com/2015/10/01/random-words-on-entropy-
and-dns/
[25] SANS ISC InfoSec Forums, Detecting Random - Finding Algorithmically chosen
DNS names (DGA). [Online].
Available:https://isc.sans.edu/forums/diary/Detecting+Random+Finding+
Algorithmically+chosen+DNS+names+DGA/19893/
97

Final Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Report

Uploaded by

Copyright:

Available Formats

GRADUATION PROJECT 2

A Graduation Project submitted in partial fulfillment of the

College of Computer and Information System

targeted organization. Logging DNS transactions from different sources such as

want to study in my project, which is to analyze, design and implement a traffic

relevant literature and the proposed project plan.

deepest gratitude to our family for helping and supporting us.

2.2.2 DNScapy .............................................................................................................

4.4 SYSTEM DIAGRAMS ..........................................................................................

Chapter 6. Tests ........................................................................................................... 72

Figure 1 Project Gantt Chart ............................................................................................

Figure 42 First Scenario ............................................................................................... 73

Table 1 Project Organization Table ............................................................................. 15

DNS Domain Name System

TLD Top Level Domain

BIND Berkeley Internet Name Domain

YADIFA Yet Another DNS Implementation For All

NIDS Network-based Intrusion Detection System

SDLC Systems Development Life Cycle

FQDN Fully Qualified Domain Name

In computer networks, a tunneling protocol allows a network user to access or provide

of the tunneling and that is the case in DNS tunneling,

DNS is a foundational protocol which enables applications such as web browsers to

If DNS tunneling goes undetected, it represents a significant risk to an organization.

the security rules.

network to detect and stop this utilities.

preventing ones. To achieve this aim we need to obtain the following:

Study the DNS service and protocol in details

Study the DNS Tunneling, with DNS tunneling

Study the different DNS Tunneling tools and techniques

Study the DNS Tunneling mitigation techniques.

Study the alternatives to implement the DNS Tunneling mitigation techniques

Implement the DNS Tunneling mitigation techniques.

1.5SIGNIFICANCE OF THE PROJECT

while DNS tunneling goes undetected, it might represents a significant risk to an

1.6 LIMITATION OF THE PROJECT

experiencing a real test of it on a real network, because we do not have an authority to

a real one, an alternative solution is to simulate a network using Virtual machines.

1.7 PROJECT ORGANIZATION

Figure 1 Project Gantt Chart

divided as the following:

Task Name Start End Duration

The First Draft of the Proposal 30/10/2016 20/11/2016 21

The Final Draft of the Proposal 25/11/2016 1/12/2016 6

Study the DNS service and 4/12/2016 10/12/2016 6

Study the DNS Tunneling and 11/12/2016 17/12/2016 6

Study the DNS Tunneling 18/12/2016 24/12/2016 6

The First Draft of Theoretical 25/12/2016 31/12/2016 6

The Final Draft of Theoretical 2/1/2017 15/1/2017 13

Study the alternatives to 16/1/2017 1/22017 16

Implement the DNS Tunneling 2/2/2017 17/3/2017 43

Build a virtual network with a 18/3/2017 25/3/2017 7

Implement the communication 26/3/2017 2/4/2017 7

The Final Report 3/4/2017 18/4/2017 15

Table 1 Project Organization Table

Chapter 2. LITRATURE REVIEW

2.1 DNS SERVICE

2.1.1 Significance of the DNS Service

Besides the obvious problem of having to remember a large number of complex

additional problems. Moving a website to a different hosting provider or moving

to the ability to accessing servers by name.

2.1.2 Types of DNS Servers

2.1.2.1 Root and TLD Servers

important records for the DNS to work in a proper way [4].