Bachelor Thesis Project

Evaluation of Low-Interaction
Honeypots on the University
Network

Author: Austin Pontén

Supervisor: Ola Flygt
Examiner: Dr. Johan Hagelbäck
Semester: VT 2017
Subject: Computer Science
 Abstract
This project studies the three honeypot solutions Honeyd, Dionaea, and Kippo. Eval-
uating the solutions themselves, and observing their implementation into the univer-
sity campus network. The investigation begins with the understanding of how a
honeypot works and is useful as an extra security layer, following with an imple-
mentation of said three honeypot solutions and the results that follow after a period
of days. After the data has been collected, it shows that the majority of malicious
activity surrounded communication services, and an evaluation of the three honeypot
solutions showed Honeyd as the best with its scalability and reconfigurability.

i
Acknowledgements:
First, I would like to thank Ola Flygt for being my supervisor and advising me on my
thesis in both writing and content. Second, I would like to thank the IT department and
especially Marcus Westin for his aid in procuring the resources needed to complete this
project, and his insight on certain results. Finally, I’d like to thank Josef Rudberg for
reading through my project and correcting it for grammar mistakes, my girlfriend Josie
for her encouragement and support, and to my family back home who has helped me get
to this point and supported me over the past three years.

ii
Contents
List of Figures v

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Previous Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Scope/Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Method 4
2.1 Scientific Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Method Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Background & Theory 5

3.1 Honeypot History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Honeypot Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Research Honeypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Production Honeypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4.1 Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4.2 Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4.3 Reaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Honeypot Interaction Levels . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5.1 High-Interaction Honeypot . . . . . . . . . . . . . . . . . . . . . 7
3.5.2 Medium-Interaction Honeypot . . . . . . . . . . . . . . . . . . . 8
3.5.3 Low-Interaction Honeypot . . . . . . . . . . . . . . . . . . . . . 8
3.6 Honeypots and the Law . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7 Entrapment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8 Invasion of privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8.1 Wiretap Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8.2 Pen Register, Trap, and Trace Devices Statute . . . . . . . . . . . 9
3.8.3 Electronic Communications Privacy Act (ECPA) . . . . . . . . . 10
3.9 Third-party liability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9.1 Negligence and Downstream Liability . . . . . . . . . . . . . . . 10
3.9.2 Possession of Contraband Material . . . . . . . . . . . . . . . . . 10
3.9.3 Failure to report crimes . . . . . . . . . . . . . . . . . . . . . . . 10
3.10 Advantages of a Honeypot . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.10.1 Data Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10.2 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10.4 Return of Investment . . . . . . . . . . . . . . . . . . . . . . . . 11
3.11 Disadvantages of a Honeypot . . . . . . . . . . . . . . . . . . . . . . . . 12
3.11.1 Narrow Field of View . . . . . . . . . . . . . . . . . . . . . . . . 12
3.11.2 Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.11.3 Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

iii
4 Implementation 14
4.1 Selection of Honeypot Solutions . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Honeyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Honeyd Download . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 Honeyd Configuration File . . . . . . . . . . . . . . . . . . . . . 16
4.2.3 Honeyd Log File . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.4 Honeyd Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Kippo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1 Kippo functionality . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2 Kippo Download and Setup . . . . . . . . . . . . . . . . . . . . 19
4.4 Dinonaea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1 Dionaea Functionality . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 Dionaea Download and Setup . . . . . . . . . . . . . . . . . . . 20

5 Results From Honeypot Data 21

5.1 Honeyd Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 TCP connection analysis . . . . . . . . . . . . . . . . . . . . . . 22
5.1.2 UDP connection analysis . . . . . . . . . . . . . . . . . . . . . . 24
5.1.3 ICMP connection analysis . . . . . . . . . . . . . . . . . . . . . 25
5.1.4 Honeyd connection origin . . . . . . . . . . . . . . . . . . . . . 26
5.2 Kippo Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1 Kippo Input Results . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2 Kippo Geo Input . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Dionaea Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.1 Dionaea Connection Analysis . . . . . . . . . . . . . . . . . . . 37
5.4 Which Honeypot Solution is the Best? . . . . . . . . . . . . . . . . . . . 40
5.4.1 Dionaea Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4.2 Kippo Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4.3 Honeyd Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Discussion 42

7 Conclusion 44

References 45

A Appendix A 47

B Appendix B 52

C Appendix C 54

iv
List of Figures
4.1 Network design for Honeypots . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 A sample of linux machine fingerprints from the file nmap.prints . . . . . 15
4.3 Sample of the configuration for a Windows XP computer . . . . . . . . . 16
5.4 Pie chart displaying the connections made to the honeypots. All 194.
addresses are the honeypots (removed for security reasons) . . . . . . . . 21
5.5 Bar chart displaying the different types of connections made . . . . . . . 22
5.6 Pie chart displaying the different types of connections made . . . . . . . 22
5.7 Screenshot of AbuseIPDB’s analysis of IP address 116.31.116.26 . . . . . 23
5.8 Screenshot of AbuseIPDB’s analysis of IP address 59.45.175.30 . . . . . 23
5.9 Pie chart displaying the connections by the destination port . . . . . . . . 24
5.10 Bar graph displaying the number of UDP connections per unique IP . . . 24
5.11 Pie chart displaying the number of UDP connections per unique IP . . . . 25
5.12 Bar graph displaying the number of ICMP connections per unique IP . . . 26
5.13 Pie chart displaying the number of ICMP connections per unique IP . . . 26
5.14 Bar graph displaying the number of connections per unique IP . . . . . . 27
5.15 Pie chart displaying the number of connections per unique IP . . . . . . . 27
5.16 Bar graph displaying the number of successful and unsuccessful SSH lo-
gin attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.17 Bar graph displaying the top 10 SSH clients used . . . . . . . . . . . . . 28
5.18 Bar graph displaying the most probes received in the time span of one day 29
5.19 Bar graph displaying the most successful logins per day . . . . . . . . . . 29
5.20 Bar graph displaying the top 10 username and password combinations . . 30
5.21 Pie chart displaying the top 10 username and password combinations . . . 30
5.22 Bar graph displaying the top 10 usernames attempted . . . . . . . . . . . 31
5.23 Pie chart displaying the top 10 passwords attempted . . . . . . . . . . . . 31
5.24 Bar graph displaying the top 10 commands entered into the console . . . 32
5.25 Screenshot of a Kipoo TTY log replaying a live attack . . . . . . . . . . 32
5.26 Bar graph displaying the top 10 successful commands entered into the
console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.27 Bar graph displaying the top 10 unsuccessful commands entered into the
console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.28 Bar graph displaying the top 10 connections per unique IP . . . . . . . . 34
5.29 Pie chart displaying the top 10 connections per unique IP . . . . . . . . . 35
5.30 Bar graph displaying the most successful logins per unique IP . . . . . . 35
5.31 AbuseIPDB’s report on the IP address 91.197.235.11 . . . . . . . . . . . 36
5.32 Main Page of DionaeaFR . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.33 Attack map displaying connections made from around the world . . . . . 38
5.34 Pie chart displaying the the connections by the destination port . . . . . . 38
5.35 Pie chart displaying the the connections by the destination port . . . . . . 39
5.36 Pie chart displaying the the connections by the destination port . . . . . . 39

v
1 Introduction
Around the world, billions of attacks on small, medium, and large networks occur on
a daily basis [1]. State-of-the-art firewalls, Intrusion Detection Systems (IDS), and other
detection tools attempt to defend networks against these malicious attacks. Over the years,
these defense tools have been built on information from past attempts at breaking into
a system, successful attempts at breaking into a system, and from stolen data [1]. A
honeypot is designed to reduce and/or eliminate the need for a system breach in order
to learn about what the hackers are using to penetrate the network. A honeypot simply
replicates a real network with fake data that a hacker will attempt to steal from, thereby
showing how and what their intentions are. Their intentions lead to information that is
vital for constructing a better IDS, firewall, and further encrypting the data that needs to
be protected.

1.1 Background
Attackers and blackhat hackers are constantly refining and developing new ways to pen-
etrate and take control of systems around the world. With a honeypot, Threats can be
eliminated before they become serious by watching the behavior of an intrusion to deter-
mine what their mechanisms are, and with this data, further improve security. Honeypots
are described as a trap to attract attackers [1] and they (usually) take shape as a virtual
system on a network. Mimicking the functionality of a real network, a virtual honeypot
network is only a persona set to trap the hacker and gain insight into their methods and
intentions. The founder of The Honeynet Project, Lance Spitzer, described a successful
honeypot as “an information system resource, whose value lies in unauthorized or illicit
use of that resource" [2].

1.2 Previous Research

Similar research has been made in other university networks. In several master theses,
other students have investigated their university networks using low-interaction honey-
pots. In these theses they managed to locate and analyze malicious traffic originating
from around the globe directed towards their university. Although some of the experi-
ments used different honeypot solutions and methods to develop their data, their research
questions were similar. In a master thesis from Chalmers University in 2010, a student
proceeded to use several hybrid honeypots to analyze vulnerabilities in the Chalmers Uni-
versity network [3]. This student’s blend of high and low-interaction honeypots allowed
for the capture of many Secure Shell (SSH) brute-force attempts, malicious HyperText
Transfer Protocol (HTTP) activity, illicit file transfers over File Transfer Protocol (FTP),
and several other botnet-related attacks. Likewise at Halmstad University, a similar ex-
periment was made where three students observed traffic using low-interaction honeypots
[4]. The results from their experiment showed that most of their attacks were made over
port 445 using Server Message Blocks (SMB), which is a vulnerable application-layer
network protocol [5]. SMB is primarily used for offering shared access to files, printers,
serial ports, and other sorts of communications between nodes on a network [5].

1.3 Problem Formulation

Most networks are expected to be seamless, operational, and growing, without the hin-
drance of any data breach. With these expectations and the growing threat of external

1
intrusions, a honeypot can be used to discover potential threats. This data can be used by
the university’s IT department to be made aware of incoming attacks to see not only what
kind of services are the most susceptible for attacks, but possibly from which Internet
Protocol (IP) address, port, and origin. The goal of this thesis is to raise the IT depart-
ment’s awareness of current threats without harming the infrastructure with the use of a
low-interaction honeypot.

1.4 Motivation
Linnaeus University is, like any other large network, conscious of keeping its information
safe and secure from outside perpetrators. With the mass of personal information and
data that is passed internally and externally, a honeypot could help the university network
detect threats before they become serious [6]. Every network has the potential to have a
vulnerability, and the university network is not an exception. With an awareness of the
potential perpetrator’s intentions, the university may better defend their resources.

Research Questions
RQ1 Which services are the most exploited at Linnaeus University?
RQ2 How are honeypots structured and what are the characteristics of a
honeypot that attract hackers directed towards Linnaeus University?
RQ3 Where do most attacks on the university network originate?
RQ4 Which honeypot solution is the best and what criteria is used in de-
termining that?

Hypothesis
It is hypothesized that this experiment will result in a large number of intruders originating
from botnets and potential blackhat attackers attempting to find a vulnerability in the
Linnaeus network. These vulnerabilities include trying to capture shared secrets between
devices, attempting to infect the network with worms/malware, and possible rootkits.

1.5 Scope/Limitation
The honeypots that were built are specific to the Linnaeus University network. Any con-
clusions made of the data on an outside network cannot similarly be made, since the
data gathered is directly related to attacks against the university network. Furthermore,
there could be many attacks that are not recorded by the honeypots due to the nature of
the attack, or the fact that the low-interactive nature of the honeypot could make it an
un-attractive target for hackers. Another limitation is that the use of only a few honey-
pot versions might not capture every probe against the university network. There could
be other solutions that are more geared towards different vulnerabilities that the chosen
honeypots for this experiment could miss and would otherwise change the outcome of
the data. Finally, even though the nine IP addresses received from the IT department
had no filters or ports blocked on their end, the Swedish University Computer Network
(SUNET) automatically places certain firewall restrictions on these IP addresses. The fact
that these IP addresses still have some port rules (see Appendix C) attached to them, cre-
ates a limitation in some potentially malicious data packets being blocked from arriving
to the honeypots.

2
1.6 Target Group
The results from this thesis should directly impact the IT department at Linnaeus Uni-
versity, and indirectly impact university networks around the world. Since this imple-
mentation is catered towards a university network, any other large and/or related network
designs can benefit from these findings. The amount and types of attacks are always
beneficial for any network administrator to be aware of, and the results may reveal new
information about more refined attacks and threats on the web today.

1.7 Outline
Section 2 will go into detail of how each of the research questions will be answered.
Section 3 will answer RQ2 with the background of a honeypot, and the theory behind
it. In section 4 will be the description on how each honeypot solution was setup and the
configuration details. Section 5 will answer RQ1, RQ3, and RQ4, and display the results
from the honeypots and an analysis of what the data tells us. Finally in Sections 6 and 7
is a discussion on the analysis of the data, future research, and concluding remarks about
the project.

3
2 Method
This section will go into detail about how each research question will be answered. It
will also give the reasoning for why the experiment is valid and capable of solving the
research questions in the most precise way possible.

2.1 Scientific Approach

The formal research method used is the mixed-methods approach, and, more specifically,
the concurrent triangulation strategy. This methodology fits best with the research because
it will confirm, cross-validate or corroborate findings [7] from the data gathered in the
honeypot. The research will be carried out by using multiple honeypots to catch attacks
made against the university network, and with that data, show the potential vulnerabilities
and the services that are the most sought after. The data gathered will be quantitative,
meaning that there will be conclusive evidence in the form of numerical data.

2.2 Method Description

First, a study into which open source honeypots that work best with the university net-
work will be made, gathered from reading internet articles, blogs, research papers, and
consumer reviews. After choosing multiple open source solutions will be an implemen-
tation of said solutions on the university network to record attacks for a duration of two
weeks. From this data, conclusions will be drawn regarding the answers to research ques-
tions RQ1, RQ3, and RQ4. Included in the report will be a section dedicated to the theory
behind a honeypot to satisfy the answer to RQ2 and give further insight on how honeypots
can help increase network security in general.

2.3 Reliability and Validity

In order to reduce the amount of invalidity as extensively as possible, the experiment
has been alloted 2 weeks for data gathering. The more time the honeypot has to gather
data, the more reliable the results of the experiment will be. Validity issues could result
from not capturing every single attack due to honeypots’ setup or the from the blockage
of ports from SUNET. Since the experiment only deals with low-interaction honeypots,
they will not capture every single attack, but mostly port scans and botnets searching
for vulnerabilities. The data however, is reliable and conclusions can be drawn since a
honeypot’s purpose is to collect malicious data. Any connection is recorded and collected
to be reviewed to be used as empirical proof.

2.4 Ethical considerations

As mentioned later in sections 3.8, 3.9, and 3.10, there can be unethical uses of honeypots,
although rare. In this particular experiment, there is no trace of illegality since the use of
these honeypots is purely for research and the nature of the low-interactiveness of the
honeypots disallows the perpetrator to enact irreversible effects on the system. It is also
important to note that the honeypots are not forcing an attacker to interact with them, they
are merely machines emulating certain services that the attacker must choose to interact
with. Any malicious behavior found was not caused by anything else but the actions of
the attacker.

4
3 Background & Theory
In order to understand how and why honeypots are useful in testing purposes or in creat-
ing a safe environment, this section describes the history and current honeypot practices.
This section also describes the process it took to determine the honeypot solutions in the
experiment, and the function they would be serving.

3.1 Honeypot History

With the start of computer viruses and worms taking shape in the 1960s, the first hon-
eypot showed up later, around 1986 written by Clifford Stoll [2]. At this time, the term
"honeypot" was not used, but Stoll used an early version of a modern-day honeypot to
capture a West-German hacker and eventually write a book on his experience called The
Cuckoo’s Egg. The next advancement in honeypots came from a notable firewall expert
Bill Cheswick, who wrote a number of fake services, password files, and even scripts to
fake service activity in what is now looked to as a modern honeypot [2]. Finally, the first
real, palpable honeypot was created by Dr. Fred Cohen in 1997 called the Deception Tool
Kit (DTK) [2]. This kit was built with perl scripts and C executables, reacted to attacks,
and faked symptoms of a vulnerable system.
The Honeynet Project was a movement founded by Lance Spitzer in 1999. This
project was the starting grounds for honeypot research and creation. With the members
of The Honeynet Project made mostly of information security professionals, they pro-
duced several papers and designs on how to build efficient honeypots. The first design
and commercial open source project was released in 2001 called the Genl Model. Since
then, honeypot designs and other open source projects have continued to expand outside
The Honeynet Project. Today, all kinds of low, medium, and high-interaction honeypots
are sold commercially or are created open source.

3.2 Honeypot Types

Honeypots can be allocated into different types based on their purpose and the amount of
services provided. Honeypots can be used either in production or to gather research, and
as previously stated, can be either low, medium, or high-interaction in terms of level.

3.3 Research Honeypot

A research honeypot is a tool to gain insight into the blackhat community. In order to
stay one step ahead, information security experts need to know where the threat is coming
from, how the threat is attempting to steal information, and what services are under attack.
Acquiring intelligence is a billion dollar industry that most government systems spend in
order to stay on top of issues and potential threats. To defeat a threat, you have to be made
aware of it [8].
In this case, a honeypot used primarily for research purposes is the best solution since
it provides an environment that allows the study of the threat. Observing this environment,
it makes it easier to understand the way attackers think, and be able to see in action what
their intentions and methods are. Using this information, security experts can develop
new intrusion detection and prevention techniques. Research honeypots should not be a
part of the network’s main defense and should not add any direct security value to the
infrastructure [8]. The environment should be a sandbox, which means that an attacker
should not be able to reach actual network resources from the honeypot[9].

5
 The captured information can be directly relevant in the improvements to attack pre-
vention, detection, and/or reaction [8] (see sections 3.4.1 3.4.2 and 3.4.3). If an orga-
nization requires their honeypot to detect threats to improve the overall security of their
network, then instead of using a research honeypot, which has its main purpose in in-
formation gathering, they should use a production honeypot that provides direct security
features [8].

3.4 Production Honeypot

Production honeypots are used to prevent current and potential attacks [8]. This type
of honeypot is used directly alongside an organization’s security architecture and aids in
mitigation of internet threats. This type of honeypot is very specific in its emulation and
usually lures attackers based on similar operating systems and services that the organi-
zation is using. This effect allows the organization to have a more specific prevention
system based on the data gathered.
A big advantage of using production honeypots is that they can detect and log count-
less numbers of attacks that the IDS would not capably handle due to the unique nature of
the threat [8]. If the threat is new, then the IDS can be improved by registering the attack
and creating the specific parameters in the IDS to prevent future threats of a similar kind.
Production honeypots can provide security for an organization in three different ways as
stated earlier in prevention, detection, and reaction.

3.4.1 Prevention
Total and complete prevention is not probable with a honeypot, as a honeypot, in essence,
is not designed to keep attackers at bay. In fact, a poorly designed honeypot could allow
an experienced blackhat hacker to take control of the system through the services given
to them. Prevention is not the main security aspect that a honeypot will provide, but
the deterrence or distraction that a honeypot provides that prevents many attacks from
entering into real systems.
If attackers are spending time, energy, and resources focusing on breaking into the
honeypot and extracting data from it, then the less time is spent trying to break into the real
system. Again, this comes with the risk of them gaining control of the real system based
on the level of interaction associated with the honeypot, but essentially, the distraction
should provide a substantial level of prevention.
Most importantly, since most attacks are automated, coming from botnets and zombie
computers, a honeypot can be a scapegoat for these automated attacks instead of them
being pointed towards the real system. Then again, since these automated forms of attacks
are designed to affect everything with an IP stack [8], it might not be the best form of
prevention. Overall, honeypots are not the best form of prevention, and should only be
used more for detection purposes.

3.4.2 Detection
Honeypots are mostly designed for detection. Since it is difficult for many organizations
to detect attacks while distracted by the production environment, a honeypot can be used
as a detection agent that sits idle until a threat occurs [8]. For example, a system without
a honeypot could have a worm in their system with or without the IDS detecting it. How-
ever, with a strategic placement of a honeypot, it could notify the system administrator
that it has been infected and that the next course of action must be taken. Preferably, the

6
worms, viruses, and attacks should stay outside of the firewall, but in the case that some-
thing manages to slip through, it would be beneficial for a company to have a sandboxed
network that can log exactly what is happening to it, to better understand and take care of
the situation.
An IDS is seen as the main guard to a network, and is expected to maintain the security
of a network. However, with the increasing number of false positives, it becomes harder
to know whether a threat is real or not. If the IDS is constantly alarming the security
administrator of a threat that is not real, they could become callous and unsuspectingly
allow a threat that could have been otherwise prevented. If these types of misjudged
threats are not lowered, the real attacks become more powerful. A honeypot is only
successful when it has come into contact with a threat, therefore the number of false
positives with regards to a honeypot is extremely low.
Finally, the biggest risk that a honeypot can solve with regards to detection is when
a false negative occurs. If an IDS fails to detect the threat and it enters the system unin-
hibited, the last line of detection could be a honeypot. Since their primary objective is to
detect new anomalies, they will log and display the attack for the security administrator
to observe and deal with accordingly. It will be simple for the administrator, since the
honeypot does not take part in the production environment, but instead can treat every
connection as hostile [8]. Essentially, any new connections made by an internal honeypot
can be enough for an administrator to at least verify to see if there was in fact a potential
threat to the network. To summarize, honeypots should in no way replace an IDS, but
instead support it with information and its own alert system.

3.4.3 Reaction
If an organization’s data servers have been compromised in some way, and the response
team needs to identify and isolate the problem, a honeypot could provide a full forensic
search without compromising the other real production servers [8]. This, terms of reaction
and recovery, gives honeypots a unique part to offer in a security system. Especially if
the servers in question are allowing services that cannot be stopped immediately, having
access to a honeypot could be the only chance for discovering the real problem. Without
the honeypot, the recovery process would be trying to fix specific bugs without learning
what damage was done, how the attacker was able to gain access, if the attacker still has
access, or if cleanup was successful [8]. From a honeypot analysis, the response team
could determine the entry point of the attack and what the attack did. From this analysis,
a solution can be made to fix the other servers in the system, allowing the organization to
recover.

3.5 Honeypot Interaction Levels

Each honeypot solution comes with a different level of interaction. This scale of low,
medium, or high-interaction determine how much an attacker can interact with the hon-
eypot in terms of services and responses.

3.5.1 High-Interaction Honeypot

A high-interaction honeypot is a real computer system in disguise, having real services
and operating systems of the organization. Since its purpose is to catch threats, it should
not be processing real network data, but instead only be running regular daemons and

7
services that keep it functioning [2]. Every interaction made with the high-interaction
honeypot should be logged and monitored as it could be the result of a threat.
A high-interaction honeypot requires a large amount of maintenance and monitoring,
especially if the system becomes compromised. Making a full case study of the situation
could take days to understand what happened [2]. In addition, since high-interaction
honeypots can become fully compromised [2], and the fact that they interact with the real
system, the risk is greater that the hacker can gain real access. There is a trade-off: either
the attacker is fascinated with the honeypot, all of their interactions and keystrokes are
logged, and quality data of their intentions are received, or, the attacker uses the fact that
they can interact with the real system to gain access, and it compromises the production
network.

3.5.2 Medium-Interaction Honeypot

Medium-interaction honeypots attempt to combine the best from both the low and high-
interaction honeypots in the way that they handle botnet detection and malware collection,
without the risk associated. The biggest advantage of a medium-interaction honeypot
lies in its virtual application layer [10]. Since this type of honeypot is not necessarily
attempting to distinguish itself as an operational system environment, nor is it emulating
all the details of an application protocol, it finds its niche in being attractive enough for
an attacker to want to attempt to break into the system, without the risk that they would
compromise an actual production environment [10].
A medium level of interaction is enough to keep the attackers interested, and gives the
administrator the power to choose which services need to be emulated to better understand
how they can become compromised [10]. Furthermore, this level of interaction is required
if, for example, the attacker required some sort of reaction in order to download malware
onto the system. In the case of a low-interaction honeypot, there would be no response
and the malware would not be captured for later evaluation. However, in the case of
a medium-interaction honeypot, it would have just enough interaction to download the
malware and collect data surrounding it, without the risk that a high-interaction honeypot
has that the malware could potentially affect the rest of the system.

3.5.3 Low-Interaction Honeypot

Low-interaction honeypots emulate services, network stacks, or other aspects of a real
machine [2]. This type of honeypot gives the attacker just enough interaction to make
it interesting enough to attempt to steal or gain access to the system. All the while, the
honeypot will be reporting the attacker’s actions and logging them for future use. A
significant advantage of a low-interaction honeypot is that they require very little main-
tenance and setup time. The honeypot can be run on the Demilitarized Zone (DMZ) for
days, collecting mostly automated scans, spammers, or worms [2]. In most cases, if a real
attacker was trying to break into the system, they would realize that they are dealing with
a low-interaction honeypot due to the simplicity and lack of response.
The data gathered from a low-interaction honeypot can be used for statistical purposes
and determine different automated attack patterns across the web. Also, as mentioned be-
fore (see section 3.4.2), low-interaction honeypots can be used as an alarm in connection
with the IDS. If the honeypot becomes infected on the internal network, then it’s almost
guaranteed that an attack has slipped past the IDS and this situation can be used to trig-
ger an alarm. Since the nature of a low-interaction honeypot is meant for emulation only,
there is no risk involved with allowing an attacker to be on the honeypot. The environment

8
in which the attackers find themselves in is a sandbox, which as previously mentioned,
means that the attacker can abuse the honeypot as much as they want without exposing
critical systems and affecting other systems in the process [9].

3.6 Honeypots and the Law

Since the introduction of honeypots in the 1990s, their legality has been debated among
security professionals and legal officials ever since. The law becomes involved in three
different ways: entrapment, invasion of privacy, and third-party liability [11].

3.7 Entrapment
Entrapment implies that the criminal was enticed by the honeypot to commit a crime he
would not have otherwise made if it were not for the very nature of the honeypot. This
defense will not hold if, for example, the defendant was predisposed to commit the crime,
or there was any evidence of planning behind the attack [11]. Entrapment is merely a
required case to determine whether or not the criminal had the correct state of mind to
perform their actions [11].

3.8 Invasion of privacy

Invasion of privacy is the right a hacker has under certain exceptions with the precedents:
Wiretap Act, Pen Register, Trap, and Trace Devices Statute, and Electronic Communica-
tions Privacy Act (ECPA).

3.8.1 Wiretap Act

The Wiretap Act states that the courts may determine the honeypot used to sniff traffic as
a violation and view the hacker as merely a bystander [11]. Yet there is a case within the
Wiretap Act that clearly states a cause, i.e. "computer trespasser", in which the commu-
nication can be monitored lawfully [11]. In order to be monitored, several bylaws must
be met [11]:
1. The owner or operator of the honeypot authorizes the interception.

2. The law enforcement agent is engaged in a lawful investigation.

3. The law enforcement agent has reasonable grounds to believe that the contents of
the hacker’s communications will be relevant to that investigation.

4. Such interception does not acquire communications other than those transmitted
to or from the hacker (i.e. that of innocent parties). This exception is most rele-
vant when the honeypot has detected illicit activity and there is a wish to turn the
situation over to law enforcement to gather evidence for criminal prosecution.

3.8.2 Pen Register, Trap, and Trace Devices Statute

This statute applies to the collection of communicative data captured through the filtering
of data streams for metadata. This insignificant data includes the source IP or telephone
number of a user [11]. This type of data collection is against the law except if the collec-
tion is made with the same exceptions listed in section 3.8.1 that authorizes the operator
to intercept the non-content information related to hacker communications [11].

9
3.8.3 Electronic Communications Privacy Act (ECPA)
This act entitles every subscriber or user of a computer network with privacy rights with
the assumption that the interception of their traffic is a violation of their privacy. It was
decided that any "provider of electronic communication" [11] fits under the ECPA, such
as a pager service, booking system, phone service etc. The logic follows that if a honeypot
operator is operating as an electronic communication service, and a hacker is subscribed
or is a user of this service, then the hacker could sue under the clause that their communi-
cations are being monitored and it is an invasion of their privacy.

3.9 Third-party liability

A third-party liability takes form in three different laws: negligence and downstream
ability, possession of contraband material, and the failure to report crimes.

3.9.1 Negligence and Downstream Liability

If a honeypot operator is negligent in their setup of the system, and the hacker uses the
honeypot as a stepping stone to gain real access to launch an attack against a third party,
the owner of the honeypot is eligible for prosecution [11]. This term is often called "down-
stream liability" which describes the honeypot owner as allowing the hacker to flow into,
and compromise systems "downstream". Honeypot operators should be especially careful
that they do not misuse their resources and create an environment without any chance for
the attacker to gain access to the real production system.

3.9.2 Possession of Contraband Material

Possession of contraband material refers to when a honeypot operator is not aware that
a hacker has stored illegal files such as child pornography, pirated files, or other illegal
documents on their honeypot and is negligent in deleting these illegal files in a timely
manner [11]. Hackers can decide to use a honeypot to store such contraband material for
the purpose of keeping the liability separate from them and hope the operator is not regu-
larly observing changes. If the honeypot operator is seen as in possession of contraband
items, they could be legally responsible and could result in fines and even jail time [11].

3.9.3 Failure to report crimes

Just like any electronic communication service, a honeypot operator is also required to
report if a crime has occurred. It is also punishable by up to three years in prison if
the crime is not reported in a timely manner [11]. It remains to be seen that a honeypot
operator commits such a crime, yet it is completely within the scope of possibility if the
operator is negligent in their reporting obligations or insufficient monitoring tools [11].

3.10 Advantages of a Honeypot

Due to the sudden influx of both open-source and commercial solutions, it’s obvious to
see that honeypots add a unique and irreplaceable value to the network infrastructure. A
few of the advantages they give to the organization are in data value, resources, simplicity,
and a return of investment.

10
3.10.1 Data Value
With millions of logs to filter through, security experts have had a difficult time interpret-
ing the messages, alerts, and logs that their machines are giving them on a daily basis. The
advantage of a honeypot lies in its collection of data. It only collects data that is important
and needs to be observed [12]. This reduces the strain in shifting through countless logs
to determine which ones are more important and should be taken seriously.
Honeypots provide the data that the administrator requires in a quick and easy-to-
understand format [12]. With this advantage, the administrator can be informed of any
potential threats and respond at a quicker rate. This data could also show attack patterns,
new viruses, trends, and other critical information used for statistical purposes or for
individual study [2].

3.10.2 Resources
Another problem faced by security mechanisms is the depletion of resources or the limi-
tation of resources [12]. This refers to when a security mechanism can no longer function
due to the surplus of package intake. For example, if a firewall is set to block all con-
nections and eventually its connection table becomes full, it has run out of resources to
take in more connections and no longer monitors the incoming connections [12]. Even
an IDS could start dropping packets if the sensor buffers become too full without enough
resources to deal with the situation. This leads to the IDS potentially skipping and not
logging critical data packets that are attacks on the system.
Due to the fact that honeypots log and monitor less activity compared to an IDS or
firewall, they typically will not have problems of resource exhaustion [12]. Honeypots
will only capture data that is pointed directly at itself and will not capture production
information. Because of this, honeypots have fewer data to log and monitor, and therefore
fewer resources are required. In the place where an IDS sensor may stop, due to resource
exhaustion, a honeypot will continue to function [12].
Honeypots themselves require significantly less Random Access Memory (RAM),
chip speed, or large disk drives, depending on their level of interaction [12]. Leftover
computers found inside the organization or even the executive’s recently discarded laptop
can be used [12]. A honeypot is not only cost-efficient but also will not require a lot of
resources to provide a helpful tool to the organization.

3.10.3 Simplicity
Simplicity is the single biggest advantage of honeypots [12]. A honeypot does not require
many difficult algorithms, databases to maintain, or rule bases to misconfigure [12]. The
honeypot is simply placed in a strategic location onto the network and regularly checked
for anomalies or used as an alert system. Research honeypots can be more complex if
the operator wants a higher level of interaction and complicated services. However, all
honeypots share the same simple concept; to capture and record any connections made
with it. This simplicity makes honeypots more reliable and less like to be misconfigured,
break, or fail [12].

3.10.4 Return of Investment

With IDS and firewalls, it is difficult to really understand the extent of the investment. If
an organization has a successful firewall, this means that little to no attacks were launched

11
successfully against the organization. Therefore this will cause them to question the extent
of their investment. Since no major attacks or problems have been made, the organization
might not understand the extent of the investment in the firewall and think to cut back
financially. Security measures such as encryptions, strong authentication, and host-based
armoring are victims of their own success [12]. To summarize, if these mechanisms are
successful, the company might cut back on the expense of these products due to the lack
of intrusions that these mechanism provided in the first place.
For this reason, a honeypot’s value is obvious by their function. Every time they are
attacked, the organization may realize the threat is indeed present. This can justify not
only the use of a honeypot itself but also the investment into other security resources [12].
The honeypot can provide the proof that management needs to ensure that their security
mechanisms may stay.

3.11 Disadvantages of a Honeypot

Despite the aforementioned advantages, a honeypot could be seen to provide some disad-
vantages due to a few misconceptions of its functionality and improper setup techniques.

3.11.1 Narrow Field of View

A narrow field of view is when a honeypot is unaware of any activity outside of its own
resources [12]. If a network is attacked and the attackers discover a honeypot, the attackers
could choose to not direct the attack on the honeypot and it would be unaware of the
surrounding activity. This can be especially damaging if the honeypot was used as some
sort of alert system. In this case, it would be detrimental to the organization if the attackers
are able to maneuver their attack around the honeypot.

3.11.2 Fingerprinting
Fingerprinting, in both active and passive terms, refer to the capture and identification of a
system [13]. Fingerprinting can be the bane of a honeypot if an attacker recognizes certain
services from previous honeypots. For example, an attacker may be able to recognize a
honeypot by an incorrectly made web server returning an incorrect HTML value, or an
incorrect SSH server error message. Anything that an attacker could discover that is
suspicious or not normal could alert the attacker of the presence of a honeypot and create
a fingerprint of the situation. If a honeypot becomes fingerprinted, its use is nullified.
Honeypot operators should ensure that there are no stray, incorrect, or unusual services
that could raise suspicious for an attacker, especially at higher levels of interaction [12].
One particularly dangerous instance of fingerprinting could occur if the attacker uses
the honeypot to their advantage. By identifying a honeypot on the network, an attacker
can spoof production systems and attack the honeypot [12]. The alerts from this fake
attack will have management confused and in the confusion, allow the attackers to focus
on real attacks.
Lastly, fingerprinting could be the main issue with bad information coming from a
honeypot. An attacker could recognize the existence of a research honeypot and pro-
ceed to feed bad information [12]. This information could lead to an incorrect security
configuration, which could lead to security issues in the future.

12
3.11.3 Risk
As mentioned in section 3.5, a honeypot has a certain level of risk attached to the level
of interaction it has. If a honeypot is compromised and controlled by an attacker, they
can use this honeypot and its resources to further their attack. Either by furthering the
attack into the organization the honeypot is attached to, or turn the honeypot into a piece
of a bigger botnet. The general rule is that the simpler the honeypot is, the less risk is
associated with it [12]. The trade off is, however, that the honeypot might not generate as
precise and unique data as one with a more complicated level of interaction.
Because of these disadvantages, honeypots should not replace security mechanisms
like firewalls and IDS [12]. Instead, a honeypot should add to the overall security in-
frastructure with clear goals and instructions without overstepping the bounds to create a
security risk.

13
4 Implementation
In this section, a detailed description of how the honeypots were implemented will be
presented, specifically with regards to the honeypot itself, setup, configuration, and their
capturing of data. After thorough research into many open source honeypot solutions,
three different honeypot solutions were chosen: Honeyd, Kippo, and Dionaea. In this
section, each solution selection will be explained and the configuration details of each will
be included. Due to security reasons, some of the configurations cannot be released. All
of the configurations displayed in this report are the same as used in the actual experiment
excluding the subnet of IP addresses given from the IT department. The below figure is
the design of the network, which will be explained in detail later in this section.

Figure 4.1: Network design for Honeypots

14
4.1 Selection of Honeypot Solutions
When searching for a suitable honeypot solution, several pieces of influential criteria were
involved in the decision. This criteria was a incorporation of cost, level of interaction,
amount of online sources, online reviews, available documentation, reconfigurability, and
finally, ease of setup. Setup difficulty was not determined until after the experiment was
concluded and could not be factored into the selection process. Yet, without the setup dif-
ficulty, the decision to choose these honeypots solutions were based on the other qualities
listed above. Another factor that was a part of the decision making process in terms of the
level of interaction was the fact that using a high-interaction honeypot is not only expen-
sive, but it could lead to legal issues. With low-interaction honeypots, it is a lot easier to
control the network environment and deters from any serious issues with the core network
and any illegality.

4.2 Honeyd
Honeyd is a small daemon that creates virtual hosts on a network. [14]. Any of these hosts
have the ability to run and personalize most network functions and operating systems. A
single Honeyd host can claim up to 65,536 IP addresses [14], and can emulate routing and
other functions such as web servers, FTP servers, dynamic port binding, etc [14]. In order
to appear realistic, Honeyd reveals itself as a real system when either Xprobe or Nmap
(the two most common fingerprinting tools) are used to determine the operating system
of the host. In Honeyd, the virtual personality is configured using an Nmap fingerprint
found in the nmap.prints database.

Figure 4.2: A sample of linux machine fingerprints from the file nmap.prints

When this personality is configured, the virtual honeypot will react to packets using
the network stack behavior that the particular fingerprint calls for [15]. Every outgoing
packet’s protocol headers are changed to reflect the personality that they are emulating.
Nmap’s fingerprint database is used to simulate Transmission Control Protocol (TCP) and
User Datagram Protocol (UDP) network behavior, and Xprobe is used to simulate Inter-
net Control Message Protocol (ICMP) behavior [15]. The above example is a fingerprint

15
found in the file nmap.prints which specifies the network stack behavior of a Linux ma-
chine.

4.2.1 Honeyd Download

Out of the three honeypot solutions, Honeyd was by far the most difficult to set up. There
was very little documentation in regards to network configuration and about the python
and pearl scripts used to run services on the virtual honeypots. Honeyd is easily obtained
and downloaded using sudo apt-get install honeyd or it can be retrieved from Github or
from The Honeynet Project and it requires the libraries libevent for event notification,
libdnet for packet creation, libpcap for packet sniffing, and libpcre (optional perl library)
[16].

4.2.2 Honeyd Configuration File

After the correct dependencies and packages are downloaded, the next step is to write a
honeyd configuration file in which /etc/honeypot/honeyd.conf was the location of the file
used in this experiment. In this configuration file, are the details of the virtual honeypots
that Honeyd will be emulating. There is a syntax to follow when creating a virtual hon-
eypot, or personality as it is called. Unfortunately there is very little documentation on
the specifics in regards to scripts that can be used to emulate certain processes on these
virtual honeypots. Presented below is an excerpt of a Windows XP computer from the
configuration file, the entire configuration is found in Appendix A.

Figure 4.3: Sample of the configuration for a Windows XP computer

As aforementioned, the syntax for creating such personalities are difficult due to the
lack of documentation. With the help of several blog posts from the creators of Honeyd
and Nova, Honeyd’s successor, it became easier to understand how the personalities were
configured. The basics are:

1. Both a general name and personality found in nmap.prints are assigned to the virtual
honeypot.

2. The uptime field gives the option to spoof the uptime of a host, referring to the
duration of time since the system was first booted [4].

16
 3. Setting the default TCP action refers to how the virtual honeypot will handle incom-
ing TCP traffic. There are three different states that you assign to a certain action
or port on a virtual honeypot[17]:

(a) For TCP:

• filtered: ignore packets from that port.
• open: responds with SYN ACK.
• closed: responds with SYN RST.
(b) For ICMP:
• open: respond to ICMP messages.
• closed: do not respond to ICMP messages.

4. Set as many ports open, closed, or filtered (closed by default) as needed on the
virtual honeypot.

5. Lastly, python and/or pearl based scripts can be assigned that emulated different
functions onto each port.

(a) Several predefined scripts are found in /usr/share/Honeyd/scripts. There is

very little online documentation on the scripts available but some help can
be found from developers manuals, blog posts, and previous examples. The
scripts can also be written and added by the user. The more scripts there are,
the more likelihood an attacker will interact with the honeypot(s) [4].
(b) An example of adding a telnet script on port 23 on a linux machine in the
configuration file:
add LinuxComputer tcp port 23
"/usr/share/Honeyd/scripts/unix/linux/suse8.0/telnetd.sh"

4.2.3 Honeyd Log File

The next part of the process is to create a log file that will record all interactions with the
virtual honeypots. This process is as follows:

1. First, an empty file is created, which in this experiment was called /etc/log/honeyd.log.

2. Next, the file permission must be changed to 766 using sudo chmod 766 /etc/log/honeyd.log
so that the file can be read, written to, and executed by the owner, but only can be
read and written to by in group and others.

3. Finally, the Honeyd2mysql script needs to be pointed to the correct log file path,
which in this case is /etc/log/honeyd.log. This step is done in preparation for when
the log data from Honeyd will eventually be transferred into Honeyd-Viz.

4.2.4 Honeyd Startup

After the configuration file is made, and the log file is created, Honeyd can be started with
a series of startup commands, the first of which is a command that disables IP forwarding
on the Honeyd host computer. This is necessary to disable, otherwise the IP packets Hon-
eyd receives for the virtual honeypots are forwarded to other computers in the network [3].

17
The command used to disable IP forwarding is: echo 0 > /proc/sys/net/ipv4/ip_forward.
Next, the Honeyd host needs to be configured so that Address Resolution Protocol (ARP)
requests from the router about the IP addresses of the virtual honeypots are answered. In
order for this request to suffice, a tool called farpd, otherwise known as "Proxy-ARP", is
used to spoof the ARP requests. Farpd, created by Niels Povos (creator of Honeyd), lis-
tens on the host interface and responds with its own Media Access Control (MAC) address
in response to a request from the router for information from the IP of a virtual honeypot.
This allows the Honeyd host to take the responsibility in getting the information from the
internet to the virtual honeypots and back. Without this, either the router needs to have
the specific routes to the virtual honeypots in its routing table or the virtual honeypots will
be unable to interact on the internet. The command used to activate this is:
farpd (host network interface IP) -i (physical network interface)
Once IP forwarding is turned off, and farpd is turned on, Honeyd is ready to be activated.
The command used to start Honeyd is:
s u d o honeyd −d
−f / e t c / h o n e y p o t / honeyd . c o n f
− l / v a r / l o g / h o n e y p o t / honeyd . l o g
−p / e t c / h o n e y p o t / nmap . p r i n t s
−a / e t c / h o n e y p o t / nmap . a s s o c
−0 / e t c / h o n e y p o t / p f . o s
−x / e t c / h o n e y p o t / x p r o b e 2 . c o n f
−u 1000 −g 1000 − i e t h 0 1 9 2 . 1 6 8 . 1 . 1 1 − 1 9

• -d flag denotes that Honeyd will run in the foreground and not in deamon mode so
that the debug messages will be shown on the terminal.

• -f flag tells Honeyd the path to the configuration file that holds the personalities
Honeyd should launch.

• -l flag gives Honeyd where the connections should be written to in a log file.

• -p flag gives Honeyd the path to the Nmap signature database that Honeyd uses to
emulate different operating systems at the network stack [4].

• -a flag reads the file that associates Nmap style fingerprints with Xprobe style fin-
gerprints [18].

• -0 flag reads the database for passive fingerprinting. Allows for dynamic templates
[18].

• -x flag reads Xprobe style fingerprints. The content of this file will denote how
Honeyd reacts to ICMP fingerprinting tools [18].

• -u and -g flag sets the user and group ID of the process. 1000 just happens to be the
point where human user ID’s start in Ubuntu [19].

• -i flag specifies the network interface and IP address of the Honeyd host.

If the configuration file’s syntax is correct, then Honeyd will start in debug mode and
be listening promiscuously on the network interface.

18
4.3 Kippo
Kippo is a medium-interaction honeypot that emulates an SSH service. SSH is used to
connect a user securely into a device to control and change files within the system [20].

4.3.1 Kippo functionality

All activity from the attempted SSH connection to the honeypot is recorded in the Kippo
log. Working on port 22, attackers are monitored on user names, passwords used, the
origin IP address, and input if the attacker successfully logs into the honeypot. In order
to receive as many intrusions as possible, it is best to keep the user name and password
combination as easy as possible to crack. If an attacker is successfully inside the Kippo
honeypot, they will find a series of fake files that can be traversed, deleted, added to, and
manipulated in any way [20]. Since this is not connected to any real system, nothing can
be compromised with any downloads or file deletion.

4.3.2 Kippo Download and Setup

Kippo software is available on Github. The installation is an "all-in-one" package and
requires very little configuration. Kippo has the option to change which port the honeypot
will be listening on, the file system, the password file, hostname, and even the ability to
add new commands [20]. Lastly, Kippo will let the user decide which user name and
password combinations will be permitted access inside the honeypot. It’s better to choose
a user name and password combination that is easily crackable with brute force attempts
from the attacker. Simple login credentials give the user a better chance to discover what
the attackers are trying to do inside their network. For this particular experiment, the
initial configurations were left unaltered which left the Kippo honeypot with the user name
and password "root" and "123456" respectively. Once all the settings are configured, the
Kippo script is started with ./kippo.sh and the honeypot will start logging all connections,
depending on the file structure, in /kippo/log/kippo.log. These logs can be later converted
into a readable format and updated in Kippo-Graph.

4.4 Dinonaea
Dionaea, otherwise known as "the Nepenthes successor", is a malware capturing honeypot
developed in 2009 as a part of The Honeynet Project [21].

4.4.1 Dionaea Functionality

Dionaea’s aim is to advertise vulnerable services in order to be affected by malware that
will later be downloaded and stored for inspection. Dionaea has a modular architecture,
using python to write scripts that emulate different protocols that advertise to the attackers
[21]. Dionaea was an improvement to Nepenthes in terms of detection of shellcodes and
supporting protocols such as (Internet Protocol Version 6) (IPv6) and Transport Layer
Security (TLS). Due to the fact that Dionaea deals with potentially dangerous malware,
the environment is kept as a sandbox, and with no administrative privileges [21]. Dionaea
traps malware using services such as:

• Server Message Block (SMB) – Used as a popular target for worms, SMB is one of
the main protocols offered by Dionaea [21].

19
 • HyperText Transfer Protocol (HTTP) – As well as supporting traffic on port 80,
Dionaea generates a self-signed SSL certificate upon startup to include HTTPS [21].

• File Transfer Protocol (FTP) – Dionaea is susceptible all activities involving FTP
including the downloading and uploading of files plus the creation of directories
[21].

• Trivial File Transfer Protocol (TFTP) – Dionaea can serve files over port 60 on a
provided TFTP server [21].

• Microsoft SQL Server (MSSQL) – Using the Tabular Data Stream protocol, Dion-
aea Listens on port 1433 and allows logins to clients and decodes the queries made
on the database [21].

• Voice over IP (VoIP) – Dionaea is able to register and log all SIP (Session Initial
Protocol) messages, and react accordingly [21].

4.4.2 Dionaea Download and Setup

Dionaea can be directly downloaded from Github where the dependencies are also found.
Dionaea is similar to Kippo, where after the correct packages are installed, it is easy to
deploy after a few changes to the configuration file. If desired, the directory of the log
file can be changed, and even a cap on how many entries can be made. Additionally,
the path to which file the malware is downloaded can be changed, as well as a path to a
potential third-party analysis directly from the honeypot. Lastly, the IPv4 or IPv6 range
that Dionaea will listen on can be configured, or by default Dionaea will listen to all traffic.
After the configuration file is set to the correct standard, Dionaea is started by executing
the script ./runDionaea.sh. Logs from Dionaea can be stored into an SQL database, and
later be visualized with DionaeaFR.

20
5 Results From Honeypot Data
In this chapter, the results of each honeypot will be shown. Please note that some of the
data must be hidden due to security reasons, but conclusions can be drawn nevertheless.
This chapter will also answer the research questions posed at the beginning of this paper
and many references will be made back to these questions in the analysis of the honeypot
data:

• Which services are the most exploited at Linnaeus University?

• What are the characteristics of a honeypot that attract hackers directed towards Lin-
naeus University ?

• Where do most attacks on the university network originate?

The following is a graph of how many connections each honeypot received. The IP
addresses are removed for security reasons.

Figure 5.4: Pie chart displaying the connections made to the honeypots. All 194.
addresses are the honeypots (removed for security reasons)

Each virtual honeypot almost equally received the same amount of connections, which
confirms that they are individually working and are interacting with traffic across the web.

5.1 Honeyd Results

After 3 days of capturing, there were over 1.7 million connections on the virtual honeypots
generated by Honeyd. Once these connections were logged, they were converted into an
SQL database using Honeyd2MySQL, and then visualized through an open source project
called Honeyd-Viz. The following is one of the graphs generated by Honeyd-Viz and it
displays the amount of connections received and the transmission protocol type:

21
 Figure 5.5: Bar chart displaying the different types of connections made

Displayed in the graph is an influx of TCP connections. Since more TCP ports were
left open in the Honeyd virtual honeypot configurations, it make sense that the most com-
mon probed ports are over TCP. There are a few ICMP connections as well as a few GRE
tunneled connections. However, since ICMP and GRE do not have much to do with the
connections themselves, more focus will be put on the TCP and UDP connections.

5.1.1 TCP connection analysis

A deeper look into the TCP connections shows exactly what the attackers are looking for
in the honeypots and more exclusively, the university network. In the following graphs,
the top ten IP addresses associated with a TCP connection are displayed:

Figure 5.6: Pie chart displaying the different types of connections made

From the following data, IP addresses 59.45.175.30 and 116.31.116.26 were the most
active with the honeypots using TCP as a connection. An investigation into these IP ad-
dresses brings the following results from a project called AbuseIPDB which is sponsored

22
by DigitalOcean. Their goal is to help make the web safer by providing a central repos-
itory for webmasters, system administrators, and other interested parties to report and
identify IP addresses that have been associated with malicious activity online [22].

Figure 5.7: Screenshot of AbuseIPDB’s analysis of IP address 116.31.116.26

Both IP address correspond with malicious activity and both were reported with multi-
ple accounts of brute-force attempts on different connection protocols, DDoS, Port Scans,
and SSH abuse. With over 570 reports from webmasters and system administrators com-
bined, and holding the most connections on the honeypots, these two IP addresses are
therefore most likely the contributors to most of the malicious TCP activity.

Figure 5.8: Screenshot of AbuseIPDB’s analysis of IP address 59.45.175.30

23
 To understand which resources are the most probed from these IP addresses and the
other million connections, the following graph is used to cross reference the amount of
TCP connections with the number of connections per port. This helps determine what
sort of services where the most targeted on the university network.

Figure 5.9: Pie chart displaying the connections by the destination port

The conclusion made from the TCP connections made to the honeypots on the univer-
sity network shows that ports 22, 23, and even 2323 are the most perceptible to brute force
connection attempts and malicious SSH abuse. These connection attempts, as shown in
the data from AbuseIPDB originated from China.

5.1.2 UDP connection analysis

As observed in figure 5.5, the number of UDP connections are significantly less than TCP.
Still, there was over 18,000 connections originating from the following IP addresses:

Figure 5.10: Bar graph displaying the number of UDP connections per unique IP

24
 Figure 5.11: Pie chart displaying the number of UDP connections per unique IP

The top two addresses used by the honeypots are from the Domain Name Server
(DNS) addresses for Google. Unusual as it is, the conclusion made from this data might
be insignificant, but shows that these connections are Multicast Domain Name System
(MDNS) queries sent from DNS servers to detect a single host’s IP addresses because
of an absence of a central DNS [4]. This data may not show perpetrators on the vir-
tual honeypots, but it does prove that Google’s DNS treats the virtual honeypots like real
hosts, receiving those queries for host identification. The other IP addresses that con-
nected through UDP that are not DNS servers are therefore subject to more investigation.
Unfortunately, since the top ten connections were using TCP, we cannot know for sure
what sort of activity was happening over UDP (see Figure 5.9). Also, since such a small
amount of UDP traffic was captured compared to TCP traffic, no conclusion can be drawn
as to whether or not any malicious activity is happening using UDP.

5.1.3 ICMP connection analysis

ICMP is used to report errors between network devices. Any machine that operates on at
least layer 4 in the TCP/IP stack has the ability to send and receive ICMP messages [23].
ICMP is used to detect and prevent problems associated with IP packet delivery, such as
indicating if a gateway or website is up or down. It is important to note that ICMP can be
used to execute a Denial-of-Service (DoS) attack, which could be a reason to check the
honeypot for a sudden influx of pings.

25
Figure 5.12: Bar graph displaying the number of ICMP connections per unique IP

Figure 5.13: Pie chart displaying the number of ICMP connections per unique IP

Again, the top two origin IP addresses were found in AbuseIPDB’s database involv-
ing malicious activity with the top IP (221.183.16.231) being reported for hacking by 50+
webmasters and/or system administrators. Although nothing can be achieved through
2000 pings over several days, it still goes to show that the honeypots can aid in the detec-
tion of malicious networks through the use of ICMP.

5.1.4 Honeyd connection origin

As shown in figure 5.5, Honeyd received over 1.7 million total connections from all
around the world. In the answering of research question number three, i.e. where do
most connections originate, we can observe the following graph of the most common
connections by IP address:

26
 Figure 5.14: Bar graph displaying the number of connections per unique IP

Figure 5.15: Pie chart displaying the number of connections per unique IP

Out of the 1.7 million connections, about half (807,591) of them are from The People’s
Republic of China. Furthermore, from only the top ten most connections, half of them are
blacklisted in several databases that contain IP addresses of malicious servers. The results
from this data can be found in Appendix B and the conclusion can be can be drawn that
the most connections and attacks against the university network originate from China.

27
5.2 Kippo Results
Kippo gathered over 40,000 connections in about two weeks. Each time an attacker at-
tempted to login into the honeypot using SSH, Kippo recorded all the interactions from
this connection and directly uploaded this data to Kippo-Graph, where the data was vi-
sualized. The following graphs represent each connection’s attempt to gain access to the
honeypot through SSH and also which SSH client was used the most:

Figure 5.16: Bar graph displaying the number of successful and unsuccessful SSH
login attempts

Figure 5.17: Bar graph displaying the top 10 SSH clients used

Only a few number of connections were successful, regardless of the relatively simple
login credentials. It is also not surprising to see Putty listed as the top client, due to
its popularity and ease of use. These probes continuously attacked the system from 500
connections in one day to over 8000 connection attempts in one day, as shown in the
following graph:

28
Figure 5.18: Bar graph displaying the most probes received in the time span of one
day

With each connection attempt, taking into account the success rate was quite low, not
every connection was granted access. The following graph details how many successful
connections were made each day:

Figure 5.19: Bar graph displaying the most successful logins per day

As expressed in the data, the login attempts were very few, yet still present every day
on the Kippo honeypot. For every login attempt, a probe tries to establish an SSH connec-
tion by trying to login as a certain user and their password combination respectively. The
following graphs explain the different results concerning the most common combinations:

29
Figure 5.20: Bar graph displaying the top 10 username and password combinations

Figure 5.21: Pie chart displaying the top 10 username and password combinations

The attackers used similar user name and password combinations to attempts to enter
the system. Both "root" and "admin" are keywords used to try and gain a higher privilege
inside the system. The guessed passwords are most likely using a dictionary attack based
on default passwords, common phrases, and eventually random characters until the system
is broken into. Fortunately, for the attackers, the user name and password combination
was easy enough to guess. Unfortunately, for the attackers, the system was a honeypot
that was recording their every move. The following graphs can be used to show which
user name and passwords are the most used in brute forcing SSH:

30
 Figure 5.22: Bar graph displaying the top 10 usernames attempted

Figure 5.23: Pie chart displaying the top 10 passwords attempted

This data can be used to show which user names and passwords should absolutely
not be used when setting up a machine with SSH. This data can also show that one of
the criteria that a honeypot has that directs attackers towards the university network is an
open and easily crackable SSH connection. This leads to the next section explaining what
these attackers attempted to do once inside the Kippo honeypot and what commands were
executed inside it.

5.2.1 Kippo Input Results

With each successful login attempt, each attacker was presented with a fake file system
along with the ability to add and remove files that closely resembles a Debian 5.0 instal-
lation [24]. Attackers were also given the ability to ’cat’ files (especially in /etc/passwd)
and all wget downloads was saved for inspection. The following graph shows the top ten
overall input received in the Kippo honeypot:

31
 Figure 5.24: Bar graph displaying the top 10 commands entered into the console

Since these input values are the most used by attackers, it is important to understand
what each do, and by this we can draw a conclusion as to what most attackers are after.
The following screen shot is taken from a Kippo TTY log, where it shows the actual
commands typed into the terminal. While watching the video play, it is clear to see that
this is completely automated. The commands are almost instantly typed in and executed.
This particular log was from an attack from Warsaw, Poland:

Figure 5.25: Screenshot of a Kipoo TTY log replaying a live attack

With some help from the IT department, and some sources online, this is the best
guess of what was attempted within the system:
Although /gweerwe323f was the most executed command, it failed to execute any
file by the name of gweerwe323f as shown in figure 5.27. Not only did the file fail to

32
execute, it is a part of a seemingly new and unknown attack. The closest we have come to
seeing /gweerwe323f is in recent blog posts and several SSH honeypot paste bins from the
past month asking about the source, with no answers about what it is [25]. Speculations
from both online articles and the IT department say that it might be a fork of a popular
SSH bot Mirai in which the author of the malware recently released its source code on
Github earlier this year [26]. If the suspicion is correct, this means that the following code
snippets show the worm checking for different files within the system for write access and
attempting to find a part of the system open for a root exploit. In both:

• echo -e ’\x47 \x72\x6f \x70/’ > //.nippon cat //.nippon rm -f //.nippon

• echo -e ’\x47 \x72\x6f \x70/tmp’ > /tmp/.nippon cat /tmp/.nippon rm -f /tmp/.nippon

show the user trying to deposit a hidden file in file names that start with "." and in "tmp"
respectively. This is a common thing for applications to do, yet it is suspicious that there
is no chmod command to enable the user to run the original file that has been modified.
After the attacker has probed the file, the final "rm command" is used to clean up all
evidence that the attacker did anything to that file and to the system.

Figure 5.26: Bar graph displaying the top 10 successful commands entered into the
console

Using the top ten successful commands, it is clear to see which commands can directly
impact the system. If the system has been set up similarly to the production network in
any way, then this data can reveal better what an attacker can do to the production network
to be able to better defend against it. However, it is still interesting to note unsuccessful
commands to discover what they might be looking for that was not available on the Kippo
honeypot:

33
Figure 5.27: Bar graph displaying the top 10 unsuccessful commands entered into
the console

It seems that the most entered command is also the most unsuccessful. The only guess
here is that this particular attack is searching for a very specific system like an IP camera,
security mechanism, or specific operating systems that holds this file to be executed by the
worm. Due to very little information about this recent SSH input, it is currently unknown
what exactly the file is and why these attackers want it to be executed.

5.2.2 Kippo Geo Input

The 40,000+ SSH attacks received by the honeypot were made from different locations
throughout the globe. The following graphs show the representation of which countries
sent the most probes:

Figure 5.28: Bar graph displaying the top 10 connections per unique IP

34
 Figure 5.29: Pie chart displaying the top 10 connections per unique IP

As shown in the graphs, the largest number of attacks came from China. As shown in
section 5.1.4, Honeyd received the same results as Kippo when it comes to the origin of
the most attacks. Yet, interestingly enough, the most probing IP address (116.31.116.26)
only established five logins with the Kippo honeypot. This is revealed in the following
graph on successful connections per IP:

Figure 5.30: Bar graph displaying the most successful logins per unique IP

From this data, a conclusion can be made, that most of the input data seen in section
5.2.1 is coming from the IP address 91.197.235.11. The following shows the results from
this IP address in AbuseIPDB’s Database [22].

35
 Figure 5.31: AbuseIPDB’s report on the IP address 91.197.235.11

Regardless of the 10,000 connections coming from China, it is in fact the attacks that
came from this Russian IP address that should be the most scrutinized as these attacks
had the most success. The rest of the attacks were scattered around the globe and did not
have as many successful logins.

36
5.3 Dionaea Results
Dionaea, the malware capturing honeypot, proved to be almost useless of the three honey-
pot solutions. In over 40,000 connections and over 12,000 different IP addresses, Dionaea
failed to capture a single piece of malware. These results were less than satisfactory, but
from a conversation with the IT department, they speculated that "worms and malware
generally don’t ’wander around’ on the Internet, but are distributed inside one’s corpo-
rate network after one machine has been infected". This, in addition to SUNET’s port
blockage on the incoming line or even in the Dionaea configuration, could have lead to
the results received. Regardless of the lack of malware, Dionaea still managed to record
the connections made from all around the globe. These results also backup the results re-
ceived in Honeyd and Kippo in terms of connection origin and port. The following screen
shot displays the main page of DionaeaFR, a visualization program that takes the Dionaea
logs, and converts them into an easily readable format:

Figure 5.32: Main Page of DionaeaFR

5.3.1 Dionaea Connection Analysis

Dionaea exposes a number of services, and these services include [27]:

• tcp/5060 → SIP Protocol

• tcp/5061 → SIP Protocol over TLS

• tcp/135 → Remote procedure Call RPC

• tcp/3306 → MySQL Database

• tcp/42 → WINS Protocol

• tcp/21 → FTP Protocol

37
 • tcp/1433 → MSSQL

• tcp/445 → SMB over TCP

• udp/5060 → SIP Protocol

• tcp/23 → SSH Protocol

Once a connection is made asking for any of these services, Dionaea records the con-
tact and writes the information in the log file. The following figure shows an attack map
revealing the origin of all the connections asking for one of these services:

Figure 5.33: Attack map displaying connections made from around the world

Looking at the data, it is apparent that the Dionaea honeypot’s services were properly
marketed across the globe with connections from different IP addresses in different coun-
tries. The following graphs detail the majority of connections by IP address and ports to
show which service was the most targeted and from where.

Figure 5.34: Pie chart displaying the the connections by the destination port

38
 Figure 5.35: Pie chart displaying the the connections by the destination port

Looking at figure 5.34, several of the IP addresses, including the top connection
202.73.98.66 from Indonesia are listed in AbuseIPDB’s database [22]. The analysis from
the list of ports in figure 5.35 show that connections on port 23 are the most used. The
second most probed port are connections on port 5060, which uses the Session Initiation
Protocol (SIP), a signaling protocol widely used in Voice over IP (VoIP). VoIP can be
targeted and exploited to steal data, misuse calls, or even use the microphone or webcams
without approval [28]. Each individual connection is able to be analyzed on Dionaea, and
further investigated if need be. An excerpt from the analysis of the connections is shown
below which includes important information about where the connection came from, how,
and when it was received. The sensor’s IP address was edited for security reasons.

Figure 5.36: Pie chart displaying the the connections by the destination port

Overall, Dionaea was unable to capture any malware, which could be seen as either
positive for the university network in terms of knowing they have little to worry about
regarding malware, there was something wrong with the Dionaea honeypot, or the blocked
ports from SUNET prevented any malware from transmitting on the incoming line. From
the connections, it proves that there was plenty of activity regarding the outside world’s

39
ability to connect to the honeypot. The conclusion here would be that the university
network is not vulnerable to malware attacks directly from the internet, and if malware
were to enter the network, it would have to be brought on a device directly into the system.

5.4 Which Honeypot Solution is the Best?

As addressed in the section 1.4, the fourth research question about which honeypot solu-
tion is the best is answered in the following subsections. It must be noted that Honeyd,
Kippo, and Dionaea do not provide the same services, which means that even if one so-
lution is deemed "better" than the other, this does not entail that this particular solution
should be singled out for implementation on a network system. Each solution is com-
pared using the qualities listed in section 4.1 and in the below graph. From this data, and
personal review, the best solution will be determined.

Honeypot Comparison
Category Honeyd Dionaea Kippo
Cost Open Source Open Source Open Source
Level of interaction Low Low Medium
Amount of Online Sources Medium Medium High
Online Reviews High High High
Available Documentation Very Low Low Medium
Reconfigurability Very High Low Low
Setup Difficulty Very High Low Very Low

Table 5.1: Table comparing the three honeypot solutions

5.4.1 Dionaea Evaluation

Dionaea, a malware collector, ranks number three out of the three honeypot solutions.
The reason Dionaea is last stems, not only from the results in the experiment, but also
the fact that Dionaea has very little reconfigurability. This can be seen as beneficial, as
a system administrator would not have to spend hours building a configuration file or
writing scripts. However, when there is an experiment involved and also an investigation
into the code, Dionaea does not provide the malleability required to create a specific
solution for a specific environment.

5.4.2 Kippo Evaluation

Kippo, a very simple and cost-efficient SSH honeypot, ranks number two out of the three
honeypot solutions. Kippo lands in second due to the difference in online help, setup dif-
ficulty, and flawless execution. Kippo is an incredibly documented and well established
honeypot solution. The amount of resources online and the most simple of setup direc-
tions makes Kippo a very manageable honeypot. Due to the simplicity of the setup of
Kippo, it follows in the same direction of Dionaea in the fact that there is very little to
no reconfigurability. Kippo can change which port to listen on, filter out some IP ad-
dress ranges, and change the login credentials [24]. This can be seen as a considerable
advantage for network administrators who will not have to spend hours making a honey-
pot configuration, and can merely deploy Kippo in a few minutes after the download of

40
dependencies has finished. The simplicity factor, along with the vast amount of online
resources, places this honeypot solution in second place.

5.4.3 Honeyd Evaluation

Honeyd, ranking number one out of the three honeypot solutions, earned its place along
with its difficulty in configuration. Unlike Kippo and Dionaea, Honeyd requires the user
to write the configuration file and scripts that will emulate the different virtual honeypots.
On top of all that, since the latest version of Honeyd was released back in 2007, the doc-
umentation from then is outdated, and most online sources had false information when
trying to configure and start Honeyd. Despite these difficulties and the sources online not
being helpful in many ways, Honeyd’s reconfigurability was by far the most impressive.
Honeyd can emulate up to 65,536 hosts simultaneously, with the ability for each host to
be configured with different scripts, port states, and even routing information [14]. This
in itself shows the reasoning behind choosing Honeyd as the best honeypot out of the
three. The biggest criteria that proves Honeyd as the best of the solutions is the ability to
choose which machines will be emulated and how they will appear to the outside. From a
network administrator’s perspective, this could be menial work, writing pages and pages
of configuration files and researching different scripts when they might want the honey-
pots to be deployed as soon as possible. However, in the case of careful experimentation,
this is the perfect solution to test and determine exactly how the internet will interact with
the different virtual honeypots, and in turn determine how the internet will interact with
the system. Therefore, Honeyd, through its vast reconfigurability, is the best of the three
honeypot solutions.

41
6 Discussion
The purpose of this study was to evaluate several low-interaction honeypots and their
detection of potential threats in the university network. In order for this to happen, three
honeypots were deployed to capture and analyze different connections on different ports.
The selection of Kippo, Honeyd, and Dionaea as tools, as explained in section 4.1, helped
the process of capturing probes around the world to show which services are the most
threatened.
Analyzing the interaction between the honeypots, the attackers, and the overall con-
nection data in such a short span of time gives an incredible insight into how significant
honeypots can be as a security mechanism. With the simple distributions like Kippo and
Dionaea, they can add an extra layer of security to the network infrastructure without as
much configuration time. However, with Honeyd, it might be more of a complication than
an addition, but if the administrator would like to test for specific machines and network
patterns, then Honeyd provides these functions. One of the major advantages of these
low-interactive honeypots is that they can be deployed and left alone to gather data with-
out any maintenance. The only requirement is to check the logs regularly or when there
has been a breach to see exactly what kind of malicious data is currently on the internet.
Hypothesized at the beginning of this experiment was that the results would reflect a
number of botnets and blackhat hackers attempting to inflict malicious bugs and rootkits
into the university network. Although the experiment did wield a large number of probes
from what seems to be botnets around the world, the botnets did not attempt to inflict as
malicious damage as hypothesized. From the results, it shows that it was uncommon for
malware to be lingering on the internet waiting to be downloaded, and definitely not the
intruders first line of attack. Instead the results showed a majority of its intruders abusing
the services that runs on ports 22 and 23.
The results of this thesis compared similarly to the results of two master theses from
Chalmers and Halmstad University [4] [3]. In these theses, they also found botnet attacks
made on ports 22 and 23 and found a significant amount of malicious TCP traffic origi-
nating from China. However, one of the major differences found between this project and
theirs, was that port 445 was a profoundly attacked resource. As mentioned in section
1.2, port 445 uses SMB which is a vulnerable application-layer network protocol asso-
ciated with communications between Microsoft services [5]. The difference however, is
that activity over port 445 was one of the ports blocked from SUNET’s end which made
it impossible to receive connections over this port. It is suspected that these blocked ports
from SUNET disallowed Dionaea from downloading any malware that should have been
captured during the experiment.
To be able to draw conclusions from the results of the honeypot logs, specific visual-
ization tools gave the data an extremely easily readable format. The three visualization
tools were Honeyd-Viz for Honeyd, DionaeaFR for Dionaea, and Kippo-Graph for Kippo.
Dionaea, Kippo, and all the virtual honeypots from Honeyd were each given a public IP
address from the IT department with some restrictions from SUNET as previously men-
tioned. Besides this, there was nothing between the honeypots and the internet. From the
limited capture time, (two weeks for Dionaea and Kippo, three days for Honeyd) the data
gathered lead to the following conclusions:

1. The most attacked service was using SSH and Telnet on ports 22 and 23. These ports
held more than 50% of the traffic and the input from these interactions came from
many blacklisted servers. From the logs, it looks like many automated connections
are made on these ports most likely from botnets or other zombie computers.

42
 2. The characteristic of a honeypot that will attract hackers towards Linnaeus Univer-
sity are open ports. Any open ports are vulnerable for exploitation. In this particular
experiment, every port that was opened had been scanned and, in the case of ports
22 and 23, section 5.2 shows exactly what an attackers does to take advantage of
that.

3. The most attacks on the university network originate from the People’s Republic of
China. Honeyd and Kippo showed China as their most common perpetrator and
Dionaea had china in the top 10. This data is in coherence with online sources that
also acknowledge China as one of the leaders of cyber-attacks [29][30][20].

4. The best honeypot solution of the three is Honeyd due to its reconfigurability, scal-
ability, and ability to advertise services. Honeyd is able to replicate an unprece-
dented amount of services, including machines and specific scripts attached to each
port. The ability to manipulate the configuration file and decide exactly how the
honeynet, or collection of honeypots, should function gives the user the power to
decide what they want to test. For these reasons, Honeyd was the best of the three
low-interaction honeypots.

Although much of the data received in this experiment was reflected in other theses,
future research in the field of analyzing malicious traffic on a university network can
explored in three different areas:
The first area for future research would be to explore the incoming traffic without the
blocked ports from SUNET. Since this experiment’s results might be more realistic in
terms of the Internet Service Provider (ISP) blocking these ports, these rules disallowed
the entry of potentially many different malicious packets that could be analyzed to show
different results.
The second area for future research involves the implementation of several different
levels of new and upcoming honeypot solutions. Since this experiment only handled low-
interaction honeypots, it could be beneficial to analyze the data captured using the latest
honeypot technology of different levels. Using a high-interaction honeypot could give a
whole new plethora of data that could impact the university more than a low or medium-
interaction solution could.
The last area of potential future research is to go a step further and help create a
security plan regarding the data received from the honeypots. Since a honeypot’s purpose
is to research malicious data on one’s network, then this data could be used to alter the
security plan to ensure the prevention of an attack surrounding the data gathered. The
process included in discovering an abused resource, and creating a plan to counteract
these attacks, could be explored in future research.

43
7 Conclusion
The university network is under the scrutiny of the internet at all times. Aiding in the
detection and elimination of cyber attacks, a honeypot can be a valuable asset to any net-
works security plan. Although the honeypot selection process and setup can be difficult,
the eventual repercussions of a honeypot will produce valuable data to stay ahead of the
current cyber threats. This particular experiment dealt with machines that had virtually
no protection, but, it shows what could happen if the university were to leave services
open and unsecured. In doing this, it revealed exactly what attackers around the world are
capable of, only after a matter of days, which further proves how imperative it is to build
a secure infrastructure.

44
References
[1] S. Russell and P. Norvig, Virtual honeypots: from botnet tracking to intrusion detec-
tion, 3rd ed. Addison-Wesley Professional, 2007.

[2] R. A. Grimes, Honeypots for Windows. Apress, 2005. [Online]. Avail-

able: http://books.gigatux.nl/mirror/honeypot/final/ch01lev1sec2.htmgoogle.com/
books?id=uOZQAAAAMAAJ{&}pgis=1

[3] V. Aliyev, “Using honeypots to study skill level of attackers based on

the exploited vulnerabilities in the network,” 2010. [Online]. Available:
http://publications.lib.chalmers.se/records/fulltext/129915.pdf

[4] B. Alkudhir, E. Chairetakis, and P. Mystridis, “Deployment of Low Interaction

Honeypots in University Campus Network,” 2013. [Online]. Available: http:
//hh.diva-portal.org/smash/get/diva2:621481/FULLTEXT02.pdf

[5] “What is an SMB Port? What is Port 445 and Port 139
used for?” 2016. [Online]. Available: http://www.thewindowsclub.com/
smb-port-what-is-port-445-port-139-used-for

[6] T. Holtz, “How to use honeypots to improve your network security,” eWeek, 2008.

[7] S. E. J. S. M.-A. S. D. Damian, “Selecting empirical methods for software engineer-

ing research,” 2015.

[8] Lance Spitzner, “The Value of Honeypots, Part One: Definitions and Values
of Honeypots,” 2001. [Online]. Available: https://www.symantec.com/connect/
articles/value-honeypots-part-one-definitions-and-values-honeypots

[9] “What is a Sandbox (in Computer Security)? - Definition from

Techopedia.” [Online]. Available: https://www.techopedia.com/definition/27682/
sandbox-computer-security

[10] J. Bradshaw, “Does Your Honeypot Interaction Match Your Security Operations Ser-
vice Level Agreement? – TRAPX Security.” [Online]. Available: https://trapx.com/
does-your-honeypot-interaction-match-your-security-operations-service-level-agreement/

[11] B. J. Schaufenbuel, “The Legality of Honeypots.” [Online]. Available: http:

//www.jdsupra.com/legalnews/the-legality-of-honeypots-50070/

[12] L. Spitzner and A. Wesley, “Honeypots: Tracking Hackers,” 2002. [Online].

Available: http://www.it-docs.net/ddata/792.pdf

[13] D. Gibson, CompTIA Security+ get certified get ahead SYO-401 study guide.
YCDA, LLC, 2014.

[14] N. Provos, “Honeyd General Information,” 2004. [Online]. Available: http:

//www.honeyd.org/general.php

[15] ——, “A Virtual Honeypot Framework.” [Online]. Avail-

able: https://www.usenix.org/legacy/publications/library/proceedings/sec04/tech/
full_papers/provos/provos_html/honeyd.html

45
[16] ——, “Honeyd,” 2007. [Online]. Available: https://github.com/DataSoft/Honeyd

[17] “Ports not actually blocked on HoneyD,” 2013. [Online]. Available: https:
//ubuntuforums.org/showthread.php?t=2113540

[18] “Ubuntu Manpage: honeyd — Honeypot Daemon,” 2002. [Online]. Available:

http://manpages.ubuntu.com/manpages/precise/man8/honeyd.8.html

[19] “[ubuntu] uid=1000. gid=1000. why 1000?” 2011. [Online]. Available:

https://ubuntuforums.org/showthread.php?t=1740376

[20] User Super, “Deployment of Kippo SSH Honeypot on Ubuntu Linux

- LinuxConfig.org,” 2016. [Online]. Available: https://linuxconfig.org/
deployment-of-kippo-ssh-honeypot-on-ubuntu-linux

[21] E. Tan, “Dionaea – A Malware Capturing Honeypot,” 2014. [Online]. Available:

https://www.edgis-security.org/honeypot/dionaea/

[22] “AbuseIPDB - IP address abuse reports - Making the Internet safer, one IP at a
time,” 2017. [Online]. Available: https://www.abuseipdb.com/

[23] Rouse Margaret, “What is ICMP (Internet Control Message Protocol)? - Definition
from WhatIs.com,” 2015. [Online]. Available: http://searchnetworking.techtarget.
com/definition/ICMP

[24] Desaster, “Kippo,” 2012. [Online]. Available: https://github.com/desaster/kippo

[25] Joanbtl, “December 30, 2016 – HoneyPot World,” 2016. [Online]. Available:
https://honeypotworldblog.wordpress.com/2016/12/30/december-30-2016/

[26] Anna-senpai, “Mirai BotNet,” 2016. [Online]. Available: https://github.com/

jgamblin/Mirai-Source-Code

[27] Ercolino Miguel, “Honeypot Networks | IT & Security Stuffs!!!”

2015. [Online]. Available: https://itandsecuritystuffs.wordpress.com/2015/02/03/
honeypot-networks/

[28] Yonatan Reuben, “5 Signs That Your VoIP System is Hacked | GetVoIP,” 2015.
[Online]. Available: https://getvoip.com/blog/2015/03/25/signs-voip-hack/

[29] Fingas Jon, “Sit back and watch hacks around the world in real time,” 2014.
[Online]. Available: https://www.engadget.com/2014/06/24/live-hacking-map/

[30] Walker Lauren, “Real-Time Cyber-Attack Map Shows Scope of Global

Cyber War,” 2015. [Online]. Available: http://www.newsweek.com/
real-time-cyber-attack-map-shows-scope-global-cyber-war-352886

46
A Appendix A
The following IP-addresses will be hidden for security reasons, which will be marked with
an asterisk (*).
create default
set default default tcp action open
set default default udp action open
set default default icmp action open
create switch
set switch personality "Cisco Catalyst 4006 Switch running NmpSW 7.4(2)"
set switch uptime 9401532
set switch default tcp action open
add switch tcp port 22 open
add switch tcp port 23 open
set switch ethernet "64:00:6a:85:45:39"
#dhcp switch on eth0
bind 194. switch*

create router
set router personality "Cisco 1601R router running IOS 12.1(5)"
set router default tcp action open
add router tcp port 22 "/usr/share/honeyd/scripts/test.sh"
add router tcp port 23 "/usr/share/honeyd/scripts/router-telnet.pl"
set router ethernet "64:00:6a:85:45:40"
bind 194. router*
#dhcp router on eth0

create windowsNT
set windowsNT personality "Microsoft Windows NT 4.0 SP3"
set windowsNT uptime 5981234
set windowsNT default tcp action open
add windowsNT tcp port 21 open
add windowsNT tcp port 22 open
add windowsNT tcp port 23 open
add windowsNT tcp port 25 open
add windowsNT tcp port 53 open
add windowsNT tcp port 443 open
add windowsNT tcp port 110 open
add windowsNT tcp port 119"/usr/share/Honeyd/scripts/win32/win2k/exchange-nntp.sh"
add windowsNT tcp port 135 open
add windowsNT udp port 136 open
add windowsNT udp port 137 open
add windowsNT udp port 138 open
add windowsNT tcp port 139 open
add windowsNT tcp port 143 "/usr/share/Honeyd/scripts/win32/win2k/exchange-imap.sh"
add windowsNT tcp port 1433 open
add windowsNT tcp port 80 "/usr/share/Honeyd/scripts/web.sh"
add windowsNT udp port 53 open
add windowsNT tcp port 389 "/usr/share/Honeyd/scripts/win32/win2k/ldap.sh"

47
add windowsNT udp port 1434 open
add windowsNT tcp port 901 open
add windowsNT udp port 1026 open
add windowsNT tcp port 1026 open
add windowsNT tcp port 1900 open
add windowsNT tcp port 5000 open
add windowsNT udp port 3389 open
add windowsNT udp port 4899 open
add windowsNT tcp port 1080 "/usr/share/Honeyd/scripts/mydoom1.pl-l/usr/share/Honeyd/scripts/mydoom
add windowsNT tcp port 10080 "/usr/share/Honeyd/scripts/mydoom1.pl-l/usr/share/Honeyd/scripts/mydoom
add windowsNT tcp port 8080 open
add windowsNT tcp port 3128 open
add windowsNT tcp port 3410 open
add windowsNT tcp port 8866 open
add windowsNT tcp port 17300 open
add windowsNT tcp port 5554 "/usr/share/Honeyd/scripts/cmdexexp.pl-p winxp-l/usr/share/Honeyd/scripts/
add windowsNT tcp port 9898 "/usr/share/Honeyd/scripts/cmdexexp.pl-p winxp-l/usr/share/Honeyd/scripts/
add windowsNT tcp port 9996"/usr/share/Honeyd/scripts/cmdexexp.pl-pwinxp-l/usr/share/Honeyd/scripts/c
add windowsNT tcp port 1234 "/usr/share/Honeyd/scripts/win32/win2k/msftp.sh"
add windowsNT tcp port 5900 "/usr/share/Honeyd/scripts/win32/win2k/vnc.sh"
set windowsNT ethernet "64:00:6a:85:45:41"
bind 194. windowsNT*
#dhcp windowsNT on eth0

create WindowServer
set WindowServer personality "Microsoft Windows Server 2003 Standard Edition"
set WindowServer uptime 290438
set WindowServer default tcp action open
set WindowServer default udp action open
add WindowServer tcp port 21 open
add WindowServer tcp port 22 open
add WindowServer tcp port 23 open
add WindowServer tcp port 25 open
add WindowServer tcp port 53 open
add WindowServer tcp port 443 open
add WindowServer tcp port 110 "/usr/share/Honeyd/scripts/win32/win2k/exchange-pop3.sh"
add WindowServer tcp port 119 "/usr/share/Honeyd/scripts/win32/win2k/exchange-nntp.sh"
add WindowServer tcp port 135 open
add WindowServer udp port 136 open
add WindowServer udp port 137 open
add WindowServer udp port 138 open
add WindowServer tcp port 139 open
add WindowServer tcp port 143 "/usr/share/Honeyd/scripts/win32/win2k/exchange-imap.sh"
add WindowServer tcp port 1433 open
add WindowServer tcp port 80 "/usr/share/Honeyd/scripts/win32/win2k/iis.sh"
add WindowServer udp port 53 open
add WindowServer udp port 1434 open
add WindowServer tcp port 389 "/usr/share/Honeyd/scripts/win32/win2k/ldap.sh"
add WindowServer tcp port 901 open

48
add WindowServer udp port 1026 open
add WindowServer tcp port 1026 open
add WindowServer tcp port 1900 open
add WindowServer tcp port 5000 open
add WindowServer udp port 3389 open
add WindowServer udp port 4899 open
add WindowServer tcp port 1080 open
add WindowServer tcp port 3127 "/usr/share/Honeyd/scripts/mydoom1.pl-l/usr/share/Honeyd/scripts/mydoo
add WindowServer tcp port 3128 "/usr/share/Honeyd/scripts/mydoom1.pl-l/usr/share/Honeyd/scripts/mydoo
add WindowServer tcp port 8080 open
add WindowServer tcp port 3410 open
add WindowServer tcp port 8866 open
add WindowServer tcp port 17300 open
add WindowServer tcp port 4444 "/usr/share/Honeyd/scripts/cmdexe2003.pl-p win2003-
l/usr/share/Honeyd/scripts/cmdexe2003"
add WindowServer tcp port 8967 "/usr/share/Honeyd/scripts/cmdexe2003.pl-p win2003-
l/usr/share/Honeyd/scripts/cmdexe2003"
add WindowServer tcp port 9898 "/usr/share/Honeyd/scripts/cmdexe2003.pl-p win2003-
l/usr/share/Honeyd/scripts/cmdexe2003"
add WindowServer tcp port 20168 "/usr/share/Honeyd/scripts/cmdexe2003.pl-p win2003-
l/usr/share/Honeyd/scripts/cmdexe2003"
add WindowServer tcp port 1234 "/usr/share/Honeyd/scripts/win32/win2k/msftp.sh"
add WindowServer tcp port 5900 "/usr/share/Honeyd/scripts/win32/win2k/vnc.sh"
set WindowServer ethernet "64:00:6a:85:45:42"
#dhcp WindowServer on eth0
bind 194. WindowServer*

create WinXPComputer
set WinXPComputer personality "Microsoft Windows XP Professional SP1"
set WinXPComputer uptime 5981234
set WinXPComputer default tcp action open
add WinXPComputer tcp port 21 open
add WinXPComputer tcp port 22 open
add WinXPComputer tcp port 23 open
add WinXPComputer tcp port 25 open
add WinXPComputer tcp port 53 open
add WinXPComputer tcp port 443 open
add WinXPComputer tcp port 110 open
add WinXPComputer tcp port 119"/usr/share/Honeyd/scripts/win32/win2k/exchange-nntp.sh"
add WinXPComputer tcp port 135 open
add WinXPComputer udp port 136 open
add WinXPComputer udp port 137 open
add WinXPComputer udp port 138 open
add WinXPComputer tcp port 139 open
add WinXPComputer tcp port 143 "/usr/share/Honeyd/scripts/win32/win2k/exchange-imap.sh"
add WinXPComputer tcp port 1433 open
add WinXPComputer tcp port 80 "/usr/share/Honeyd/scripts/web.sh"
add WinXPComputer udp port 53 open
add WinXPComputer tcp port 389 "/usr/share/Honeyd/scripts/win32/win2k/ldap.sh"

49
add WinXPComputer udp port 1434 open
add WinXPComputer tcp port 901 open
add WinXPComputer udp port 1026 open
add WinXPComputer tcp port 1026 open
add WinXPComputer tcp port 1900 open
add WinXPComputer tcp port 5000 open
add WinXPComputer udp port 3389 open
add WinXPComputer udp port 4899 open
add WinXPComputer tcp port 1080 "/usr/share/Honeyd/scripts/mydoom1.pl-l/usr/share/Honeyd/scripts/myd
add WinXPComputer tcp port 10080 "/usr/share/Honeyd/scripts/mydoom1.pl-l/usr/share/Honeyd/scripts/my
add WinXPComputer tcp port 8080 open
add WinXPComputer tcp port 3128 open
add WinXPComputer tcp port 3410 open
add WinXPComputer tcp port 8866 open
add WinXPComputer tcp port 17300 open
add WinXPComputer tcp port 5554 "/usr/share/Honeyd/scripts/cmdexexp.pl-p winxp-l/usr/share/Honeyd/sc
add WinXPComputer tcp port 9898 "/usr/share/Honeyd/scripts/cmdexexp.pl-p winxp-l/usr/share/Honeyd/sc
add WinXPComputer tcp port 9996"/usr/share/Honeyd/scripts/cmdexexp.pl-pwinxp-l/usr/share/Honeyd/scr
add WinXPComputer tcp port 1234 "/usr/share/Honeyd/scripts/win32/win2k/msftp.sh"
add WinXPComputer tcp port 5900 "/usr/share/Honeyd/scripts/win32/win2k/vnc.sh"
set WinXPComputer ethernet "64:00:6a:85:45:43"
#dhcp WinXPComputer on eth0
bind 194. WinXPComputer*

create LinuxComputer
set LinuxComputer personality "Linux 2.0.34-38"
set LinuxComputer uptime 2903245
set LinuxComputer default tcp action open
set LinuxComputer default udp action open
add LinuxComputer tcp port 21 "/usr/share/Honeyd/scripts/unix/linux/ftp.sh"
add LinuxComputer tcp port 22 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/SSH.sh"
add LinuxComputer tcp port 23 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/telnetd.sh"
add LinuxComputer tcp port 25 open
add LinuxComputer tcp port 53 open
add LinuxComputer tcp port 110 "/usr/share/Honeyd/scripts/unix/general/pop/pop3.sh" ’
add LinuxComputer tcp port 135 open
add LinuxComputer udp port 136 open
add LinuxComputer udp port 137 open
add LinuxComputer udp port 138 open
add LinuxComputer tcp port 139 open
add LinuxComputer tcp port 143 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/cyrus-imapd.sh"
add LinuxComputer tcp port 443 open
add LinuxComputer tcp port 389 open
add LinuxComputer tcp port 465 open
add LinuxComputer tcp port 515 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/lpd.sh"
add LinuxComputer tcp port 990 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/proftpd.sh"
add LinuxComputer tcp port 993 open
add LinuxComputer tcp port 2086 open
add LinuxComputer tcp port 9080 open

50
add LinuxComputer tcp port 587 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/sendmail.sh"
add LinuxComputer tcp port 1433 open
add LinuxComputer tcp port 80 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/apache.sh"
add LinuxComputer udp port 53 open
add LinuxComputer tcp port 113 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/ident.sh"
add LinuxComputer udp port 1434 open
add LinuxComputer tcp port 901 open
add LinuxComputer udp port 1026 open
add LinuxComputer tcp port 1026 open
add LinuxComputer tcp port 1900 open
add LinuxComputer tcp port 5000 open
add LinuxComputer udp port 3389 open
add LinuxComputer udp port 4899 open
add LinuxComputer tcp port 1080 open
add LinuxComputer tcp port 8080 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/apache.sh"
add LinuxComputer tcp port 3128 open
add LinuxComputer tcp port 3410 open
add LinuxComputer tcp port 8866 open
add LinuxComputer tcp port 17300 open
set LinuxComputer ethernet "64:00:6a:85:45:44"
#dhcp LinuxComputer on eth0
bind 194. LinuxComputer*

create BSDComputer
set BSDComputer personality "OpenBSD 2.6-2.8"
set BSDComputer default tcp action open
set BSDComputer default udp action open
add BSDComputer tcp port 21 "/usr/share/Honeyd/scripts/unix/linux/ftp.sh"
add BSDComputer tcp port 22 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/SSH.sh"
add BSDComputer tcp port 23 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/telnetd.sh"
add BSDComputer tcp port 25 open
add BSDComputer tcp port 53 open
add BSDComputer tcp port 110 "/usr/share/Honeyd/scripts/unix/general/pop/pop3.sh"
add BSDComputer tcp port 135 open
add BSDComputer udp port 136 open
add BSDComputer udp port 137 open
add BSDComputer udp port 138 open
add BSDComputer tcp port 139 open
add BSDComputer tcp port 143 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/cyrus-imapd.sh"
add BSDComputer tcp port 443 open
add BSDComputer tcp port 389 open
add BSDComputer tcp port 465 open
add BSDComputer tcp port 515 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/lpd.sh"
add BSDComputer tcp port 990 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/proftpd.sh"
add BSDComputer tcp port 993 open
add BSDComputer tcp port 2086 open
add BSDComputer tcp port 9080 open
add BSDComputer tcp port 587 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/sendmail.sh"
add BSDComputer tcp port 1433 open

51
add BSDComputer tcp port 80 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/apache.sh"
add BSDComputer udp port 53 open
add BSDComputer tcp port 113 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/ident.sh"
add BSDComputer udp port 1434 open
add BSDComputer tcp port 901 open
add BSDComputer udp port 1026 open
add BSDComputer tcp port 1026 open
add BSDComputer tcp port 1900 open
add BSDComputer tcp port 5000 open
add BSDComputer udp port 3389 open
add BSDComputer udp port 4899 open
add BSDComputer tcp port 1080 open
add BSDComputer tcp port 8080 "/usr/share/Honeyd/scripts/unix/linux/suse8.0/apache.sh"
add BSDComputer tcp port 3128 open
add BSDComputer tcp port 3410 open
add BSDComputer tcp port 8866 open
add BSDComputer tcp port 17300 open
set BSDComputer ethernet "64:00:6a:85:45:45"
#dhcp BSDComputer on eth0
bind 194. BSDComputer*

B Appendix B
1. IP address: 59.45.175.30

• ISP: China Telecom Liaoning

• Organization: China Telecom Liaoning
• Connection Type: Cable/DSL
• Location: Shenyang, Liaoning China
• AbuseIPDB reports: 24
• Connections: 548,601

2. IP address: 116.31.116.26

• ISP: China Telecom Guangdong

• Organization: China Telecom Guangdong
• Connection Type: Cable/DSL
• Location: Guangzhou, Guangdong China
• AbuseIPDB reports: 553
• Connections: 258,990

3. IP address: 194.71.11.173

• ISP: SUNET Swedish University Network

• Hostname: napoleon.ftp.acc.umu.se
• Connection Type: Unknown
• Location: Umea, Sweden

52
 • AbuseIPDB reports: 0
• Connections: 10440

4. IP address: 54.243.196.213

• ISP: Amazon Technologies

• Hostname: ec2-54-243-196-213.compute-1.amazonaws.com
• Organization: Amazon.com
• Connection Type: Corporate
• Location: Ashburn, Virginia USA
• AbuseIPDB reports: 0
• Connections: 10439

5. IP address: 202.73.98.66

• ISP: PT. First Media, Tbk.

• Hostname: fm-dyn-202-73-98-66.fast.net.id
• Organization: Fastnet
• Connection Type: Cable/DSL
• Location: Indonesia
• AbuseIPDB reports: 5
• Connections: 9052

6. IP address: 91.189.88.161

• ISP: Canonical
• Hostname: keeton.canonical.com
• Organization: Canonical
• Connection Type: Unknown
• Location: United Kingdom
• AbuseIPDB reports: 27
• Connections: 8997

7. IP address: 54.243.175.138

• ISP: Amazon Technologies

• Hostname: ec2-54-243-175-138.compute-1.amazonaws.com
• Organization: Amazon.com
• Connection Type: Corporate
• Location: Ashburn, Virginia USA
• AbuseIPDB reports: 0
• Connections: 8573

8. IP address: 50.19.225.125

53
 • ISP: Amazon Technologies
• Hostname: ec2-50-19-225-125.compute-1.amazonaws.com
• Organization: Amazon.com
• Connection Type: Corporate
• Location: Ashburn, Virginia USA
• AbuseIPDB reports: 0
• Connections: 7273

9. IP address: 188.92.75.10

• ISP: Sia Nano IT

• Organization: Sia Nano IT
• Connection Type: Cable/DSL
• Location: Latvia
• AbuseIPDB reports: 48
• Connections: 6765

C Appendix C
510 deny tcp any any eq 445
520 deny tcp any any eq 42
530 deny udp any any eq bootps
540 deny udp any any eq bootpc
550 deny udp any any range 135 netbios-ss
560 deny tcp any any range 135 139
570 deny udp any any eq tftp
580 deny udp any any eq sunrpc
590 deny tcp any any eq sunrpc
600 deny tcp any any eq 161
610 deny udp any any eq snmp
620 deny tcp any any eq 162
630 deny udp any any eq snmptrap
640 deny tcp any any eq 593
645 deny tcp any any eq 4786
647 deny udp any any eq 4786
740 deny udp any any eq ntp
750 deny tcp any any eq 1433
760 deny udp any any eq 1434
770 deny tcp any any eq 1434
780 deny udp any any eq 1900
790 deny tcp any any eq 1900
800 deny tcp any any eq 2967
810 deny udp any any eq 2967
830 deny tcp any any eq 4865
840 deny tcp any any eq 17
850 deny udp any any eq 17

54
860 deny tcp any any eq chargen
870 deny udp any any eq 19

55