=Paper=
{{Paper
|id=Vol-2424/paper7
|storemode=property
|title=Domain Name System (DNS) Tunneling Detection using Structured Occurrence Nets (SONs)
|pdfUrl=https://ceur-ws.org/Vol-2424/paper7.pdf
|volume=Vol-2424
|authors=Talal Alharbi,Maciej Koutny
|dblpUrl=https://dblp.org/rec/conf/apn/AlharbiK19
}}
==Domain Name System (DNS) Tunneling Detection using Structured Occurrence Nets (SONs)==
https://ceur-ws.org/Vol-2424/paper7.pdf
Domain Name System (DNS) Tunnelling
Detection using Structured Occurrence Nets
(SONs)
Talal Alharbi1,2[0000 0001 8252 9271] and Maciej Koutny1[0000 0003 4563 1378]
1
School of Computing, Newcastle University, Newcastle upon Tyne, UK
2
Faculty of Computer Science and Engineering, University of Hai’l,
Hai’l, Saudi Arabia
{talal.alharbi,maciej.koutny}@ncl.ac.uk
Abstract. Today, serious warnings regarding the increasing number of
DNS tunnelling methods are on the rise. Attackers have used such tech-
niques to steal data from millions of accounts. The existing literature
has thoroughly demonstrated the extent of the damage which DNS tun-
nelling can achieve on any given DNS server. However, through SONs
- Petri net-based formalisms which portray the behaviour of complex
evolving systems, such threats can be alleviated. As a concept, SONs
are originally grounded in Occurrence Nets (ONs) and already yielded
results in terms of successful cybercrime analysis. For instance, adding of
alternates to SONs initially used in [10] was extended to in [15] in order
to model and analyse system activities such as cybercrime or accidents,
which may show contradictory or uncertain evidence in terms of actual
activity. The current paper proposes the use of SON features with the
purpose of detecting DNS tunnelling, in the event of an actual attack.
Keywords: DNS tunnelling , Structured Occurrence Nets , Detection
of DNS Attacks
1 Introduction
In the last decades, internet usage and spread has grown dramatically, expand-
ing to include everything and anything, from small, online businesses, to large
company websites. As a consequence, what was initially “the Web” became “Web
2.0”, considering the number of applications which has been developed, based on
the internet. It is the Domain Name System or DNS, which allows applications
to use names instead of numbers (IP addresses), which are considerably more
difficult to deal with. There are several works [4,5,9,12] warning of the increasing
number of DNS tunnelling methods, and attackers have used these techniques
to compromise millions of accounts [6]. The existing literature has demonstrated
the damage which DNS tunnelling can make on any deployed DNS server. DNS
tunnelling allows hackers to transfer data in a way which violates established
system security policies [4]. The danger which such an attack brings is that it
94 PNSE’19 – Petri Nets and Software Engineering
can occur without triggering any alarms. It is actually shown as a legitimate
activity, because it uses a DNS protocol to transmit information in the orig-
inal way, instead of focusing on DNS vulnerabilities or abusing or exploiting
the system. The reason behind using SONs to record DNS traffic are the differ-
ent features that SONs provide. For example, a SON combines multiple related
ONS by using various formal relationships in particular, for communication. For
instance, SON events can be used to model various types of packets, such as
sending a query, receiving a query, sending a response and receiving a response,
as well as asynchronous communication. By means of these features, a SON is
able to depict and analyse a DNS case. SONs [6] are a Petri net-based formalism
which portray the behaviour of complex evolving systems. Their concept is orig-
inally grounded in Occurrence Nets (ONs) and already yielded results in terms
of successful cybercrime analysis. The approach which we propose is to use SON
features to detect DNS tunnelling in the event of a real attack.
DNS Tunnelling DNS tunnelling is a covert communication channel, which al-
lows encapsulating the traffic of other protocols (E.g.: HTTP, Telnet, FTP, SSH,
etc.) within DNS packets. This results in concealing the real protocol by making
the traffic look like ordinary DNS traffic. DNS tunnelling is very suitable to be
used for malicious activities such as data exfiltration as well as command and
control call-backs from within restricted internal networks. Different from other
tunnelling methods such as SSH Tunnelling, a distinctive property of DNS Tun-
nelling is that, it uses the legitimate DNS servers of the internal network to hop
its packet through, to reach the final destination, which is the attacker-controlled
server DNS Tunnelling encapsulates the data in DNS queries and responses. In
this way, the outer protocol remains as DNS; however, the encapsulated data
payload belongs to another protocol. [14]. Figure 3 explains how DNS tunnelling
is performed. The powerful advantage of DNS tunnelling is that, if a compro-
mised computer is trying to send “secret” data to the attacker-controlled server
on the external network (the Internet), even if such direct communications get
blocked by the network firewall, DNS Tunnelling would bypass this restriction.
The compromised computer would send the secret data within a Base64-encoded
message, for example “c2VJcmV0”. It will send the query to the internal DNS
server, to ask the corresponding IP address, in the form of a basic DNS query
for c2VJcmV0.talalncl.com. The internal DNS server would forward this DNS
query to the authoritative DNS server for the DNS Zone “talalncl.com”. Since
the authoritative DNS server is actually the attacker-controlled external server,
the message gets delivered to its destination. The talalncl.com DNS server will
then respond and return a dummy answer, such as 127.0.0.1. Afterwards, the
talalncl.com DNS server will analyse the query as follows:
Step 1: c2VjcmV0.talalncl.com,
Step 2: Base64Decode,
Step 3: c2VjcmV0 -> secret
which means the data extracted from within the DNS query. Finally, a single
message within DNS tunnelling looks normal. This message may look exactly
Alharbi et.al.: Domain Name System (DNS) Tunneling Detection using SONs 95
Fig. 1: DNS Tunnelling
like a normal DNS query. This is actually the weakness of DNS Tunnelling:
although a single packet may look like a normal DNS query, thousands of queries
for sub-domains within the same domain will help to detect the DNS tunnel.
Within the next section (section 5), the novel approach which we propose is
discussed (i.e., a novel way through which such types of attacks are detected).
In addition, an algorithm and its implementation are also discussed. The paper
is organised as follows: Section 1 focuses on introduction Section 2 describes
the basic features of SONs, as well as background research concerning DNS and
the DNS tunnelling phenomenon. Within Section 3 the related work discussed.
Section 4 describes DNS experimentation and data preprocessing. Within Section
5 describes the novel solution used to detect DNS tunnelling. Section 6 focuses
on the implementation of the solution, as well as on the results and a critical
assessment of our algorithm. Section 7 provides concluding remarks.
Terminologies
Table 1: Terminologies
No. Term Description
1 SONs Structured Occurrence Nets
2 ONs Occurrence Nets
3 DNS Domain Name System
4 HTTP HyperText Transfer Protocol
5 FTP File Transfer Protocol
6 SSH Secure Shell
7 IP Internet Protocol
8 iodine Software that lets you tunnel IPv4 data through a DNS server
96 PNSE’19 – Petri Nets and Software Engineering
2 Background
2.1 Structured occurrence nets (SONs).
The SONs [6,11] concept is originally grounded in occurrence nets (ONs), which
are directed acyclic graphs which show causality and concurrency of information
concerning a single execution of a system [6,11]. Figure 2 (a) shows an occurrence
net (ON). A SON consists of multiple ONs which are associated with each other
through various types of formal relationships. SONs are used for recording infor-
mation concerning the actual behaviour of a complex system, and any particular
evidence which can be collected in terms of analysing its past behaviour [4]. The
most useful way to use SONs is within a detailed analytical investigation, al-
though there is still a lack of investigation support systems which rely on SONs.
The significance of SONs results from the fact that their structuring reduces
complexity compared to that of any equivalent representation, and they provide
a direct means of modelling evolving systems.
Fig. 2: a. Occurrence net. b. Communication Structured Net.
2.2 Communication in (SONs).
Communication in SONs is of two types: asynchronous and synchronous [8, 11].
Figure 2 (b) shows a communication structured occurrence net (C-SON) which
consists of two occurrence nets, namely ON 1 and ON 2. Figure 2 (b) depicts
asynchronous communication which is represented through the dashed arc be-
tween two events in different ONs, e.g., (e0) and (e2). The second type of com-
munication within SONs is synchronous communication which is represented
by the two arcs between events (e1, e3) via the two arcs via channel place (q1
and q2) [8, 11]. Thus, in any execution consistent with the causal relationships
captured by (C-SON), (e0) will never be executed after (e2), although the two
events can be executed simultaneously, whereas (e1) and (e3) will always be
executed simultaneously. SONs are underpinned by causal structures which ex-
tend causal partial orders with additional ordering, called weak causality. Two
Alharbi et.al.: Domain Name System (DNS) Tunneling Detection using SONs 97
events ordered in this way can be executed in the order given or simultaneously.
Moreover, if two events are weakly ordered in both directions(this means, in
particular, that weak causality is not assumed to be acyclic), then they can only
be executed simultaneously. In SONs, weak causality results from passing tokens
through channel places, whereas the non-channel places introduce the standard
causality, as in ONs. In Figure 2 (b), (e0) weakly causes (e2), and the events
(e1) and (e3) form a weak causality cycle.
2.3 Domain Name System (DNS)
A DNS or Domain Name System assigns domain names and then maps each of
them in accordance with the existing name servers, which host each respective
domain [13]. At the same time, due to various reasons, network administrators
are allowed to delegate authority over some sub-domains of a given name space
to other name servers. This permission was given so that the existence of a sin-
gle, large, centralised database would not occur; at the same time, the resulting
services are fault-tolerant [13]. Additionally, DNS also defines the technical pa-
rameters of each database service which is situated at its core. These parameters
are part of what is known as the DNS protocol, meaning a detailed specification
of both the data structures within the DNS, as well as communication between
these various structures. Both these elements make up the Internet Protocol
Suite. As a broad rule, two main name spaces are maintained across the inter-
net, namely name hierarchy [13] and IP or Internet Protocol address spaces. DNS
accomplishes two tasks: on one hand, it ensures the domain name hierarchy is
kept, while providing translation services between it and a given address space,
on the other hand. To function properly, DNS relies on multiple servers as well
as on a communication protocol. Records for a specific domain are stored on a
particular type of DNS server called a DNS name server; it answers to queries
addressed to databases within it. Once a user types in any web address in the
browser, for instance www.google.com, the current, local DNS server (resolver)
will check whether or not the address is stored within it and then sends a re-
sponse to the user, with the IP address of that particular website. However, if
the resolver does not recognise that domain, it will send the query to the DNS
root name server. As a result, the DNS root server will send a response back
to the resolver, telling it the domain name (google.com) belongs to name server
for .com LTD. Afterwards, the resolver will send the query to the DNS server
google.com, asking about the IP address of www.google.com. As a result, the
.com name server will respond with an IP address for google and the resolver
will receive it and open the website for the user [6, 13]. Figure 3 illustrates this
process.
Name servers The maintenance of Domain Name Systems is ensured through
distributed database systems, which use client - server models. In this cases,
database nodes consist of name servers. At the same time, for each existing
domain, one or more given DNS servers provide data concerning the respective
98 PNSE’19 – Petri Nets and Software Engineering
Fig. 3: How DNS Resolves Names and IP Address. (The labels on arcs indicate
the steps of DNS protocol)
domain and the servers of domains which are subsequent to that respective
domain. At the top of this hierarchy, we find root name servers, which typically
receive queries when a TLD must be solved [6, 13].
Location transparency Location transparency helps to identify existing net-
work resources, through names, rather than through location [6,13]. For instance,
a user gains access through a unique file; however, actual data is reserved in sec-
tors which are dispersed either across an network or within a local computer.
Within such a system, the actual location of a file is not relevant to the user;
however, a distributed system is required, so as to ensure a naming scheme for
the available resources. One of the essential gains of using location transparency
is that location is indeed irrelevant. Considering the given network setup, a user
can obtain files from any computer connected to the network. As such, the ac-
tual location of a given resource does not matter anymore, thus creating the
impression that the whole ensemble is accessible from any computer terminal,
further boosting software upgrades [13]. Using location transparency also pro-
vides considerable versatility. This means system resources can be shifted from
one computer to another, within the network, without disrupting the network.
DNS records The DNS protocol typically uses multiple record types for various
purposes. The most common type of such records is A, which essentially switches
domain names into IP addresses. For example, AAAA records accomplish a
similar role for IPv6 protocols. Other record types, such as CNAME, are known
as aliases. This type of record directs towards another defined domain name,
but never towards an IP address. At the same time, one IP address can have
several domain names or aliases. NS stands for NameServer; it keeps the address
of the authoritative NameServer which can resolve any sub-domains for that
Alharbi et.al.: Domain Name System (DNS) Tunneling Detection using SONs 99
respective domain. At the same time, TXT records link any given text with a
specified domain name, while MX records provide information regarding mail
servers.
3 Related work
The review of the existing literature concerning DNS tunnelling led us to con-
clude that there are two main types of analyses when it comes to this phe-
nomenon: traffic analysis and payload analysis. The focus of our research per-
tains to the former.
3.1 Traffic Analysis
DNS traffic volume per IP address Traffic analysis detects attacks by mon-
itoring traffic generated by specific IP addresses (Pietraszek, 2004). The idea is
simple: each tunnelled data request takes up to 512 bytes, a complete commu-
nication will imply sending many requests (Van Horenbeeck, 2006). As such, a
server will continuously send the request, provided the client polls the server [5].
DNS traffic volume per domain The other fundamental method for detect-
ing DNS tunnelling involves analysing the amount of traffic to a particular do-
main. Since utilities are designed to tunnel data through specific domain names,
this method can assess the possibility of DNS tunnelling (Butler, 2011), unless
the attack is configured through multiple domain names [5].
Number of Hostnames per Domain Guy (2009) suggests the number of
hostnames per domain may indicate the possibility of DNS tunnelling. In such
an event, each request has a unique hostname, meaning there are far more host-
names as compared to a legitimate domain name. This method can be tailored
to determine an optimal threshold, since various tunnelling methods use various
numbers of hostnames [5]. However, our approach is to check each domain and
sub-domain, thus identifying the optimal threshold, both through logistic recog-
nition, as well as through a powerful SON feature which optimises causality and
communication features.
Domain history Domain history can help detect DNS tunnelling, as it raises
suspicions about DNS traffic. It is used to detect tunnelling by determining
when A or NS records were added, since a given domain may have recently
been acquired for DNS tunnelling purposes, meaning its NS was recently added
(Zrdnja, 2007). This method is used to detect domains involved in malicious
activities.
Visualisation Visualisation can also be used to detect DNS tunnelling (Guy,
2009). It involves interactive, analyst driven work [5]. By contrast, our SON-
based visualisation approach illustrates results automatically [3].
100 PNSE’19 – Petri Nets and Software Engineering
4 Preprocessing Datasets
4.1 Data collection
Data collection constitutes the initial stage of our work. The first step consists of
discovering how DNS packets work, how they behave and what their structure is.
This step actually consists of two stages which have been conducted in parallel:
first, the extensive studying of literature pertaining to the subject and second,
capturing real data from a local DNS server. Initially, we captured normal DNS
packets. Afterwards, we modelled the normal packet in our model SON. Table 2
illustrates the DNS packet and Figure 4 shows the result. This type of data can
Fig. 4: Normal DNS packet SON model
be modelled in SONs; however, the “Info” field has various information which
must actually be split into different fields. The reason behind this split is to
distinguish whether the data packet is either query or response. Additionally,
this split serves to distinguish the domain names, but also to determine the
packet’s id (0x81fe), since it is this ID which is our indicator, namely the one
which links each packet (query) with its response. For instance, row 26 is the
query and it is linked with row 29, which is the response for the ID packet in
question (0x81fe).
Table 2: DNS Packets
No. Source Destination Info
26 172.20.10.2 172.20.10.1 query 0x81fe A google.com
29 172.20.10.1 172.20.10.2 response 0x81fe A google.com
We developed a python script [2] to deal with this particular scenario. The
main idea of this script is to split the “Info” field into 3 subfields, namely oper-
ation (which is either query or response), “PacketID” and finally, “Domain”, as
shown in the table 3. Afterwards, we modelled the last result of a normal packet,
to ensure how it will be represented within the SON, as shown in Figure 4.
Alharbi et.al.: Domain Name System (DNS) Tunneling Detection using SONs 101
Table 3
No. Source Destination Operation PacketID Domain
1 172.20.10.2 172.20.10.1 query 0x81fe google.com
2 172.20.10.1 172.20.10.2 response 0x81fe google.com
Moreover, during the experiments, we collected attack packets, the result
of DNS tunnelling attempts. This was, in fact, the second challenge which we
discovered and treated. Table 4 represents one such attack packet. As noticeable,
if we attempt to model this packet, it will look the same as the normal packet,
described above. Due to this, the point of the research is to discover an idea
or algorithm which allows the clear distinguishing between normal packets and
attack packets. The idea is one must examine each particular domain and its
sub-domains, with the purpose of discovering whether or not a specific packet is
an attack packet or not.
Table 4
No. Source Destination Operation PacketID Domain
1 172.20.10.2 146.185.138.197 query 0xc7cb paaac5ay.tunnel.carn.us.to
2 146.185.138.197 172.20.10.2 response 0xc7cb paaac5ay.tunnel.carn.us.to
As such, the python script was updated to split the fields with which we are
dealing with, in this case. The main idea for the updated script version is that it
loops on each domain field and links it by a unique ID. It is called GroupID. As a
result, afterwards, we can identify each chunk of the domain and its sub-domains
by that GroupID, as Table 5 illustrates.
Table 5
No. Source Destination Operation GroupID Domain
1 172.20.10.2 172.20.10.1 query 001 google.com
2 172.20.10.1 172.20.10.2 response 001 google.com
216.58.206.206
3 172.20.10.2 172.20.10.1 query 001 maps.google.com
4 172.20.10.1 172.20.10.2 response 001 maps.google.com
5 172.20.10.2 146.185.138.197 query 002 paaac5ay.tunnel.carn.us.to
6 146.185.138.197 172.20.10.2 response 002 paaac5ay.tunnel.carn.us.to
7 172.20.10.2 146.185.138.197 query 002 paaydani.tunnel.carn.us.to
8 146.185.138.197 172.20.10.2 response 002 paaydani.tunnel.carn.us.to
Table 5 illustrates the link between the “Google” domain and its subdomains.
For instance, we assume “google.com” and “maps.google.com” have the same
group id, namely “001”. However, subdomains (paaac5ay) and (paaydani) have
been grouped to ”.us.to” via group id, which is actually “002”. So, the idea is
to initially identify the domain, i.e. “google” and loop to find any particular
sub-domain of “google” and link it with a unique group id.
102 PNSE’19 – Petri Nets and Software Engineering
4.2 Mixing data
In order to simulate a real scenario of DNS server behaviour, the collected data
consisted of two main parts. The first part included the data collected during
the attack experiment. The second part includes normal data, collected from the
university. For this data to make sense, and in order to simulate a real scenario
example, we created python script [1] mixing these two kinds of data. This data
mix will be evaluated in different stages in the evaluation section.
5 Proposed Solutions
5.1 Detection DNS Tunnelling using (SONs)
The main idea of our algorithm to detect DNS tunnelling is to model DNS data
i.e., each particular transaction and the way it will communicate with the local
DNS server. We assume that each packet is a unique ON. And the local DNS
server is one ON. Each packet (ON) communicates with the local DNS server
by channel place (thick circle) via events (Send query and receive query),
as shown in figure 4 . The client (ONc) sends a query to local DNS server
(ONserver), and then DNS server responds to the client as shown in Figure 4.
This is the normal packet. When we were to model the attack packet, we found
it is the same as the normal one in terms of communication and behaviour. The
reason is that we examined each packet as a separate one. However, to detect
an attack we need to examine each domain and its sub-domains in order to
examine wither we see normal or abnormal packets. For instance, if google.com,
map.google.com and developers.google.com are involved, then we need to deal
with all google domains and its sub-domains, and model them as one of chunk of
domain packets. So, we group each domain and its sub-domains with unique ID
as in prepossessing section above. The result is seen in Figure 5, where we can
distinguish between normal and abnormal packets (we displayed the attack ON
very small to fit the width of the text; however, the ON transaction is actually
bigger).
Fig. 5: Normal and Abnormal ONs
Alharbi et.al.: Domain Name System (DNS) Tunneling Detection using SONs 103
5.2 Detection DNS Tunnelling algorithm
The main idea behind the algorithm is first to detect any ON input, whether it
is a normal input or an ON representing a DNS attack. Before going more in
depth, it should be mentioned that ONs refer to DNS packets. Furthermore, we
assume the local DNS local server to be another ON. It does not matter whether
inputs are normal or representing a DNS attack. We examine each ON input and
count its events which communicate with the DNS Server ON. If the number
of those ON events is less than threshold value, we flag it as a normal ON.
Otherwise, we flag it as an abnormal ON. Then, we check whether or not we had
abnormal ONs; if so, then we know a DNS attack has occurred. Finally, we should
mention that the aforementioned threshold was identified via logistic regression,
a widely used statistics model. The idea behind this binomial model resides in
properly estimating the parameters of the logistics model. From a mathematical
standpoint, the model relies on variables with two possible values, for instance
“win” or “lose” or “pass” or “fail”. As such, we applied logistic recognition to
available data in order to estimate the threshold, and estimate how many events
within a particular GroupID could be suspicious.
The calculated threshold It is at the core of the logistic regression model.
From a mathematical standpoint, logistic regression performs multiple linear re-
gression functions of the required feature, such as the number of events. These
functions are based on the dependent, dichotomous variable, i.e. “attack” or “no
attack”. The aforementioned functions produce a threshold by using the logit
equation. Finally, this threshold can be used in our algorithm. The mathemati-
cal aim of linear regression functions is to build an equation with the following
coefficients: (a) and (c), as follows: y = ax + c, where (y) represents the probabil-
ity of an attack and (x) is the number of events. Afterwards, the values for both
the number of events and the dependent variable, namely “attack” or “not at-
tack”, will be inserted; this will allow us to perform regression analysis, meaning
we will be able to calculate the values of (a) and (c), which in turn will increase
the likelihood of (y) conforming to ground truth values. Once these values are
known, they can be used to calculate the threshold.
104 PNSE’19 – Petri Nets and Software Engineering
Algorithm 1: Detection DNS Tunnelling algorithm using SON (Part1)
Input: set_of_ons : Set of All Ons
dns_server_on : DNS Server ON
attack_max_events : DNS Server threshold to interpret an
attack
Output: set_of_normal_ons = Set of normal ONs, not presenting a
potential attack.
set_of_abnormal_ons = Set of abnormal ONs, presenting a
potential attack.
1 Interpretation:
if size of (set_of_abnormal_ons) > 0 then
2 DNS Attack;
3 else
4 No DNS Attack;
5 end
6 Start ;
7 array set_of_normal_ons = [] ;
8 array set_of_abnormal_ons = [] ;
9 integer set_of_normal_ons_index = 0 ;
10 integer set_of_abnormal_ons_index = 0 ;
11 integer connected_events = 0 ;
12 for (count_event(current_on)) < attack_max_events)) do
13 connected_events_count = 0;
14 if (count_event(current_on)) < attack_max_events)) then
15 set_of_normal_ons[set_of_normal_ons_index] = current_on;
16 set_of_normal_ons_index = set_of_normal_ons_index + 1;
17 continue;
18 else
19 for (Event current_event in current_on’s events) do
20 if (current_event is connected to dns_server_on) then
21 connected_events_count = connected_events_count +1;
22 end
23 end
24 if (connected_events_count >= attack_max_events) then
25 set_of_abnormal_ons[set_of_abnormal_ons_index] =
current_on; set_of_abnormal_ons_index =
set_of_abnormal_ons_index + 1;
26 else
27 set_of_normal_ons[set_of_normal_ons_index] = current_on;
set_of_normal_ons_index = set_of_normal_ons_index + 1;
28 end
29 end
30 end
Alharbi et.al.: Domain Name System (DNS) Tunneling Detection using SONs 105
Algorithm 1: Detection DNS Tunnelling algorithm using SON (Part2)
31 return structure : {set_of_normal_ons , set_of_abnormal_ons} ;
32 count_event(ON on) function :;
Input: on : ON
Output: events_count : number of events of ON.;
33 Start ;
34 integer vents_count = 0 ;
35 for (Event current_event in current_on’s events) do
36 events_count = events_count + 1; ;
37 end
38 return events_count ;
39 End ;
6 Result Testing and Evaluation
We considered the following proportions of attacking packets (as percentage of
the total packets):
0%, 1%, 5%, 10%, 20%, 40%, 60%, 80%, 90%, 95%, 99% and 100%.
In addition, we used the sensitivity and specificity methods [7], developed to
evaluate a system of computer-assisted diagnosis. Hence we used a tried and
tested method, with the only change being made to the terminology, as follows:
First, True positive (TP) result: attack transactions were correctly identi-
fied as attacks.Then, False positive (FP) result: normal transactions were incor-
rectly identified attacks.And, True negative result (TN) : normal transactions
were identified as normal transactions.Finally, False negative (FN) result: attack
transactions were incorrectly identified as normal transactions. In terms of the
data mix (of normal and attack packets), we created a Python script [1]. The
idea behind the script was to mix the two data sets, namely: the normal and
attack packets. Each time we ran the script, we asked the script to mix the data,
relying on the percentage from each file, such as 10% normal and 90% attack;
as a result, we obtained one file with mixed data. The main data sets for each
packet type, i.e., normal or attack packets, were collected during a five-minute
time span. The data for both sets consisted of roughly 700 DNS packets. Af-
ter running the algorithm, we checked the sensitivity and specificity through an
evaluation method, obtaining the following results. As evident in (1) in Table
6, in True Positives and False Negatives, we assumed that there was no result
because this data set had no attack packets.
However, in (2) in Table 6, when the data set had 1% attack and 99% normal
packets, we got a 0% True Positive, which means there were no attacked packets
detected as attack packets, although we had 1% attack data. This is because
the number of packets in this data set was less than the threshold. Regarding
False Negatives, we also got 0% because there were no attack packets detected as
normal packets. Likewise, in (3) in Table 6, the same situation applied. However,
in (4) in Table 6, the algorithm detected 7.1% from a total of 10% of the attack
data; however, it failed to detect 2.9% of the attack packets. After we checked
106 PNSE’19 – Petri Nets and Software Engineering
the data sets manually, we found that most of these packets were only request
queries to the DNS server, to which the DNS server did not respond, so our al-
gorithm skipped them. However, from this 2.9%, the algorithm did not attacked
them, although they have query and response packets. In future research, we will
further investigate this issue in order to discover why this happened. Another
interesting point is that, in (4) in Table 6, there is a False Positive, which means
the algorithm detected 9.4% of the normal packets as attack packets; after inves-
tigating this, we found that Google had sent many requests to the DNS server
as unusual requests, and these request events were above our threshold. When
we rerun the experiment, we did not face this issue. Moreover, as evident in (7)
in Table 6, no normal packets were detected as attack packets (False Positives).
Finally, in (15) in Table 6, the False Positives and True Negatives were “N/A”;
this was because, in these data sets, there were no normal packets at all.
Table 6: Table results
No. % normal and abnormal packets TP FP TN FN
1 0% attack, 100 normal N/A 9.7% 90.92% N/A
2 1% attack, 99 normal 0% 9.77% 90.92% 0%
3 5% attack, 95 normal 0% 8.9% 91.1% 0%
4 10% attack, 90 normal 7.1% 9.4% 90.6% 2.9%
5 20% attack, 80 normal 82.9% 5.3% 94.7% 17.1%
6 30% attack, 70 normal 86.7% 5.3% 94.7% 13.3%
7 40% attack, 60 normal 88.5% 0% 100% 11.5%
8 50% attack, 50 normal 90.9% 0% 100% 9.1%
9 60% attack, 40 normal 91.5% 0% 100% 8.5%
10 70% attack, 30 normal 91.1% 0% 100% 8.9%
11 80% attack, 20 normal 91.5% 0% 100% 8.5%
12 90% attack, 10 normal 91.8% 0% 100% 8.2%
13 95% attack, 5 normal 92% 0% 100% 8%
14 99% attack, 1 normal 92.3% 0% 100% 7.7%
15 100% attack, 0 normal 92.5% N/A N/A 7.5%
7 Concluding remarks
The paper proposes a novel solution to DNS tunnelling detection based on SONs.
An detection algorithm has been designed and implemented. Also, data prepro-
cessing and a set of experiments have been discussed. Further work will focus
on improving the current algorithm, aiming at allowing it to work automati-
cally in terms of reading with packets in real-time scenarios. In addition, we will
model and develop algorithms dealing with more than one DNS server at a time,
including all user packets. In addition, we will use other DNS tunnelling tools,
instead of “iodine”, in order to compare various attack behaviours and check how
the algorithm deals with these types of attacks.
Alharbi et.al.: Domain Name System (DNS) Tunneling Detection using SONs 107
Acknowledgements
The authors would like to thank the reviewers for their comments on the paper.
References
1. Alharbi, T.: mix packets script. https://github.com/talalsm/mix/ (May 2019)
2. Alharbi, T.: split packets script. https://github.com/talalsm/mix/ (May 2019)
3. Alharbi, T., Koutny, M.: Visualising data sets in structured occurrence nets. PNSE
2018 (2018)
4. Born, K., Gustafson, D.: Detecting dns tunnels using character frequency analysis.
arXiv preprint arXiv:1004.4358 (2010)
5. Farnham, G., Atlasis, A.: Detecting dns tunneling. SANS Institute InfoSec Reading
Room 9, 1–32 (2013)
6. Jung, J., Sit, E., Balakrishnan, H., Morris, R.: Dns performance and the effective-
ness of caching. IEEE/ACM Transactions on networking 10(5), 589–603 (2002)
7. Kapp, E.A., Schütz, F., Connolly, L.M., Chakel, J.A., Meza, J.E., Miller, C.A.,
Fenyo, D., Eng, J.K., Adkins, J.N., Omenn, G.S., et al.: An evaluation, comparison,
and accurate benchmarking of several publicly available ms/ms search algorithms:
sensitivity and specificity analysis. Proteomics 5(13), 3475–3490 (2005)
8. Koutny, M., Randell, B.: Structured occurrence nets: A formalism for aiding system
failure prevention and analysis techniques. Fundamenta Informaticae 97(1-2), 41–
91 (2009)
9. van Leijenhorst, T., Chin, K.W., Lowe, D.: On the viability and performance of dns
tunneling. International Conference on Information Technology and Applications
(2008)
10. Li, B., Randell, B., Bhattacharyya, A., Alharbi, T., Koutny, M.: Soncraft: A tool
for construction, simulation, and analysis of structured occurrence nets. In: 2018
18th International Conference on Application of Concurrency to System Design
(ACSD). pp. 70–74. IEEE (2018)
11. Li, B., Randell, B., Bhattacharyya, A., Alharbi, T., Koutny, M.: Soncraft: A tool
for construction, simulation, and analysis of structured occurrence nets. In: 2018
18th International Conference on Application of Concurrency to System Design
(ACSD). pp. 70–74. IEEE (2018)
12. Merlo, A., Papaleo, G., Veneziano, S., Aiello, M.: A comparative performance eval-
uation of dns tunneling tools. In: Computational Intelligence in Security for Infor-
mation Systems, pp. 84–91. Springer (2011)
13. Paul, M., Dunlap, K.J.: Development of the domain name system. ACM 18(4)
(1988)
14. Qi, C., Chen, X., Xu, C., Shi, J., Liu, P.: A bigram based real time dns tunnel
detection approach. Procedia Computer Science 17, 852–860 (2013)
15. Randell, B.: Occurrence nets then and now: The path to structured occurrence
nets. In: Kristensen, L.M., Petrucci, L. (eds.) Applications and Theory of Petri
Nets. pp. 1–16. Springer Berlin Heidelberg, Berlin, Heidelberg (2011)
108 PNSE’19 – Petri Nets and Software Engineering