How to Mock a Bear: Honeypot, Honeynet, Honeywall & Honeytoken:

A Survey

Paul Lackner

Institute of IT Security Research, St. P

olten University of Applied Sciences, Austria

Keywords:

Honeypot, Honeynet, Honeywall, Honeytoken, Survey.

Abstract:

In a digitized world even critical infrastructure relies on computers controlled via networks. Attacking these

sensitive infrastructures is highly attractive for intruders, who are frequently a step ahead of defenders. Honey

systems (honeypots, honeynets, honeywalls, and honeytoken) seek to counterbalance this situation. Honey

systems trap attackers by generating phoney services, nets, or data, thereby preventing them from doing dam-

age to production systems and enable defenders to study attackers without letting intruders initially notice.

This paper provides an overview of existing technologies, their use cases, and pitfalls to bear in mind by

illustrating various examples. Furthermore, it shows the recent efforts made in the ﬁeld and examines the

challenges that still need to be solved.

1 INTRODUCTION

Due to continuously improving endpoint protection

and network protection, attacks against computer sys-

tems are becoming more complex. Various new attack

vectors are found continuously and multiple system

components, hosts, and services in combination are

necessary to successfully attack a system (Simmons

et al., 2014) (Papp et al., 2015). Automated attacks

based in machine learning are increasing, which re-

veals the need for adjusted defense methods (Bland

et al., 2020) (Cui et al., 2020). To learn new tech-

niques from attackers, honeypots are one of many

tools to implement (Spitzner, 2002), especially in

Supervisory Control and Data Acquisition (SCADA)

networks, as there is little to no human interaction re-

quired to manage the networks (Disso et al., 2013).

This survey paper offers an introduction to the

respective purposes of honeypots, honeynets, honey-

walls, and honeytokens and shows the beneﬁts of im-

plementing them. These four systems study attackers

by generating fake networks, hosts, services, and data.

The motivation to write this survey was to create

a new collection of relevant literature and a structured

overview to get more insight in this already estab-

lished, but still promising topic. This survey is in-

tended to give a brief introduction into the topic and

to show what has already been done with honey sys-

tems to see the variability of them and attract more

attention to this topic.

This paper is structured as follows: First, section 2

explains the differences between the honey tools. The

following sections describe the properties of the dif-

ferent honey tools and illustrate some use cases as

well as implementation considerations. Furthermore,

section 5 describes monitoring, detection and hiding

methods followed by a standardised threat informa-

tion exchange approach. Finally, legal aspects are de-

scribed and a list of some implementations and hon-

eypot tools ﬁnalises the paper. Further research that

needs to be done concludes the paper.

2 TERMINOLOGY

Honeypots, honeynets, honeywalls, and honeytoken

all serve the same purpose, namely to detect intruders

and analyse their intrusive behaviour. No legitimate

user would ever access a honey system (Petruni

2015), even a connection attempt is considered an at-

tack (Provos, 2003).

Invented in the 1990s, a honeypot is the best

known application of the honey systems (Cheswick,

1992). It is a single host, network device or dae-

mon (Provos, 2003) luring potential attackers to dis-

tract them from valuable network ressources (Pouget

et al., 2013). “A honeypot is a security resource

whose value lies in being probed, attacked, or com-

promised.” (Spitzner, 2002). “A honeypot is a re-

Lackner, P.

How to Mock a Bear: Honeypot, Honeynet, Honeywall Honeytoken: A Survey.

DOI: 10.5220/0010400001810188

In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 2, pages 181-188

ISBN: 978-989-758-509-8

181

Figure 1: A honeynet, which consists of honeypots, du-

plicating the production system and being separated by a

honeywall. The honeywall routes legimite users to the pro-

duction network (white hosts) and attackers to the honeynet

(yellow hosts).

source which pretends to be a real target.” (Provos,

2003). A honeypot itself is not a security ﬁx but

helps ﬁxing issues by gaining information about at-

tacks. “The main goals are the distraction of an at-

tacker and the gain of information about an attack and

the attacker” (Baumann and Plattner, 2002).

A honeynet is a network of multiple honey-

pots (Project, 2002; Project, 2001). Analogous to

honeypots, the entire network is to be attacked. The

honeynet is not emulated and therefore can be a copy

of the production system (Spitzner, 2003a). “Hon-

eynets represent the extreme of research honeypots.

They are high interaction honeypots, which allow

learning a great deal; however they also have the high-

est level of risk. Their primary value lies in research

and gaining information on threats that exist in the

Internet community today. Little or no modiﬁcations

are made to the honeypots of the honeynet to provide

a plausible copy of the production net. This gives the

attackers a full range of systems, applications, and

functionality to attack. From this it can be learnt a

great deal, not only their tools and tactics, but also

their methods of communication, group organization,

and motives” (Project, 2002). Low and high inter-

action honeypots are further explained in section 3.

Figure 1 shows an example of a honeynet.

As also visualised in Figure 1, a honeywall is

the perimeter border between honeynets and pro-

ductive systems, although the term honeywall is not

clearly deﬁned. Some literature describe it as a gate-

way (Spitzner, 2003a), some describe it as a layer-2

or layer-3 ﬁltering bridge ﬁrewall/Network Intrusion

Detection System (NIDS) (Dittrich, 2004). It is also

not clear whether the term “honeywall” refers to the

product name of The Honeynet Project or the basic

functioning in honey environments itself. The prod-

uct honeywall is based on iptables rules, Snort, and

Snort-inline (Dittrich, 2004). Other implementation

use similar tools. In this paper, the term honeywall

refers to a general implementation. Honeywalls sup-

port interception of SSL connections and decide if in-

coming trafﬁc is malicious and therefore needs to be

redirected to a honeynet, or if it is valid and therefore

redirected to the productive system.

Unlike honeypots or honeynets, honeytokens are

just data in the form of ﬁles, entries within ﬁles, or

special strings (Spitzner, 2003a) (Malin, 2017). The

data looks valid even though it is ﬁctional and does

not have any production use. The ﬁles are monitored

in case of their modiﬁcation. Data and strings are

monitored as well, e.g. via Google Alerts. Google

Alerts, a web service, notiﬁes a user if a string ap-

pears in Googles search. Therefore, when a user is

notiﬁed about a published honeytoken, it is likely that

this honeytoken has been stolen and a successful in-

trusion occurred. A paper deﬁnes the following hon-

eytoken properties (Bowen et al., 2009):

• Believable: A honeytoken looks like valid data.

• Enticing: A honeytoken lures an attacker.

• Conspicuous: A honeytoken is easily found.

• Detectable: Interacting with a honeytoken gener-

ates an alert.

• Variability: Various honeytoken do not contain

the same information that create a connection be-

tween them.

• Non-interference: A Honeytoken does not inter-

fere with desired data or system interactions.

• Differentiable: A legitimate user can differentiate

between a honeytoken and actual data while an

intruder cannot.

3 PROPERTIES OF HONEYPOTS

Another survey (Mokube and Adams, 2007) deﬁnes

honeypots as devices which distract attackers from

valuable machines, provide early warnings about at-

tacks and allow in-depth examination of adversaries

during and after the exploitation. To this end, it is

in the interest of a defender that an attacker interacts

with the honeypot over an extended period of time,

while being closely monitored. There are several

types (Spitzner, 2002) and several use cases (Mokube

and Adams, 2007) of honeypots. While each type can

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

182

be used in each use case, there are different advan-

tages and disadvantages for each honeypot conﬁgura-

tion.

3.1 Types

A low interaction honeypot has a very limited set

of commands available for an attacker. While there

is not much information one can obtain about at-

tackers, the risk of damaged production systems due

to a successful attack through that honeypot is also

low (Mairh et al., 2011).

A high interaction honeypot has the goal to obtain

a maximum amount of information about the attacker.

The honeypot allows itself to be used, tampered with,

or even be damaged. High interaction honeypots of-

ten are a clone of a production server. The goal is

mainly to learn about novel attack techniques (Mairh

et al., 2011). When deploying a high interaction

honeypot, considerations about an extremely resilient

monitoring system have to be made, to obtain authen-

tic information of a partially compromised honeypot.

A medium interaction honeypot is in between of

a low and a high interaction honeypot. While a low

interaction honeypot only provides a limited set of

commands and a high interaction honeypot grants

access to the operating system (OS) of the honey-

pot, a medium interaction honeypot emulates a ser-

vice (Mokube and Adams, 2007).

3.2 Use Cases

Widely known literature regards two use cases; re-

search and production. This paper introduces a third

use case: vulnerability scan.

The idea of a research honeypot is to provoke an

attack and learn about the attacker. The purpose of

a research honeypot is to learn about new techniques

and tools of attackers. It also serves to learn about

new combinations of tools attackers use to tamper

with systems. There is no intention to defend the sys-

tem against attackers (Mairh et al., 2011).

A production honeypot is only used in productive

networks to obtain information about attackers invad-

ing the productive network. The purpose is not to gain

maximum intel about the attacker but to detect the in-

terest of the attacker. Spitzner and Schneider deﬁned

three interest groups within security issues: Detec-

tion, Prevention and Response (Mairh et al., 2011).

A honeypot can provide value to Detection and Re-

sponse.

HosTaGe constitutes a further use case, the non

intrusive vulnerability scan (Vasilomanolakis et al.,

2014). HosTaGe is a honeypot for mobile phones

which scans public wireless networks. It detects mal-

ware spreading from devices within the same network

and checks the basic security of public networks. It

is considered to be a honeypot-to-go. HosTaGe also

supports Industrial control system (ICS) protocols,

making it relevant for industrial companies (Vasilo-

manolakis et al., 2015).

When implementing a honeypot, several problems

should be considered (Mokube and Adams, 2007):

• Data Types: Data provided should look authentic

to gain the attention of an attacker but it should not

be possible to harm the company with this data.

• Uplink Liability: Honeypots can and will get

compromised, which enables an attacker to attack

other systems with it. Considerations about plac-

ing a honeypot in separate networks, maybe even

a different public IP range than the production net-

work of the enterprise have to be made (see more

in section 6).

• Build Your Own Honeypot?: Most of the hon-

eypot frameworks are open source and therefore

customisable. The established honeypots profes-

sionally emulate the services they offer, when

conﬁgured correctly. Additional services have to

be programmed by the respective end-users them-

selves.

• Hiding: A honeypot should not obviously appear

as a honeypot (see subsection 5.3).

Some researcher created a method to evaluate the po-

tency of a honeynet which can be deployed to any

honeynet (Ren et al., 2020).

3.3 Advantages and Disadvantages of

Honeypots

Honeypots have particular advantages over traditional

NIDS and network security approaches (Mokube and

Adams, 2007):

• Small data sets: Only trafﬁc addressing the hon-

eypot is being observed. This can also be a disad-

vantage however.

• Minimal resources: Only attackers access a hon-

eypot; normal users have no intention of using it.

There is not always the need to use state-of-the-

art hardware as the system does not have to carry

normal production trafﬁc and interactions.

• Simplicity: Honeypots, especially low interaction

honeypots, are “simple and ﬂexible”. They fea-

ture easy deployment and update routines as they

do not offer the whole functionality of the original

service.

How to Mock a Bear: Honeypot, Honeynet, Honeywall Honeytoken: A Survey

183

• Discovery: Honeypots can help discover new tac-

tics and tools directed at them.

Naturally, honeypots also have some disadvantages.

To decide if a honeypot is the right device to moni-

tor one’s network, one has to consider the following

points (Mokube and Adams, 2007):

• Limited Vision: Only the trafﬁc that hits the target

is visible and analysed. Trafﬁc that does not target

the honeypot in any way will not be detected. This

can also be an advantage.

• Discovery and Fingerprinting: Honeypots can ei-

ther emulate a service or provide the service itself.

All services have different ﬁngerprints in terms

of reaction time and properties when using differ-

ent network stacks, operating systems, and hard-

ware. Nevertheless some ﬁngerprints can reveal

the implementation of a service. If a service is

emulated, the ﬁngerprint can reveal the emulating

service (e.g.: honeypot tool). It might be possible

to distinguish a real service from a honeypot from

network meta data.

• Risk of Takeover: A honeypot may be used as an

attacking device if it is taken over. So a honey-

pot should be monitored to determine, if it is still

working as intended or already got compromised.

4 IMPLEMENTATION

EXAMPLES OF VARIOUS

HONEY SYSTEMS

Honey systems are used in various ways with various

goals to achieve. The following subsections enumer-

ate some examples of the possibilities.

4.1 Honeynets as a NIDS

A Network Intrusion Detection System is a system

which detects known attacks (Karen A. Scarfone, Pe-

ter M. Mell, 2007) and warns administrators mostly

through a Security Information and Event Manage-

ment (SIEM) tool about incidents. During a project

a honey net was created through container orchestra-

tion and Conpot as a honeypot backend (Wang et al.,

2019). They deﬁne three modules to achieve an easy-

to-work-with honeynet: the deployment module de-

ploys a honeypot as a container with the desired prop-

erties. The management module manages the de-

ployed container in terms of power management and

honeypot properties. The intrusion detection module

is the brain of this system. It processes trafﬁc pro-

vided by the honeypots, trying to ﬁnd attack patterns.

Using a Support-Vector-Machine (SVM) algorithm

the trafﬁc data, especially the meta data (connection

duration, protocol type, number of source bytes, num-

ber of destination bytes, whether it comes from the

same host, the number of wrong segments, the num-

ber of urgent packets, etc.) is used to train a model,

which was initally trained with the KDDCUP99

data

set (a data set from 1999). The intrusion detection

module uses this model to create alerts. They argue,

since every connection to a honeypot is an attack per

deﬁnition (Provos, 2003), this is a way to determine

whether an attack is just random noise or a targeted at-

tack against the system and to achieve a better detec-

tion rate with a lower amount of false positives (Wang

et al., 2019). The detection rate of 89% still remains

low compared to common detection rates using the

SVM algorithm. A newer approach describes a simi-

lar concept (Fan et al., 2019).

A different approach describes a honeynet out of high

interaction honeypots to detect a botnet in its cre-

ation phase using machine learning to detect hidden

patterns (Mart

ınez Garre et al., 2020). Furthermore,

honeypots can organize themselves with a (private)

blockchain to act and save data distributed and be

more resistant to takedowns (Shi et al., 2019).

4.2 Honeywall

As seen in Figure 1, a honeywall is the perimeter bor-

der between a honeynet, a possible production net,

and the internet. Its three main goals are: data capture,

data control, and automated alerting. This is achieved

by combining a layered ﬁrewall with NIDS/IPS and

a monitoring tool. The honeywall decides if trafﬁc is

malicious or valid, and helps to correlate trafﬁc from

or to various honeypots in the honeynet (Chamales,

2004). A problem is the generation of good train-

ing material. To generate malware trafﬁc signatures

which let the honeywall decide if trafﬁc is valid or ma-

licious, malware trafﬁc needs to be routed to the hon-

eynet by the honeywall. Obviously, this is a chicken-

and-egg problem, which can be mitigated by revers-

ing the function of a NIDS. While a NIDS usually

works by block-listing malicious trafﬁc (Karen A.

Scarfone, Peter M. Mell, 2007) it can also pass-lists

legitimate trafﬁc: All known legitimate trafﬁc is sent

to the productive network, everything else to the hon-

eynet.

4.3 Honeytokens as an Active Defense

Honeytokens could be used as an active de-

fense (Petruni

c, 2015).

http://kdd.ics.uci.edu/databases/kddcup99/kddcup99

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

184

Zone 0: acts as the perimeter zone and may contain

a ﬁrewall (honeywall), NIDS, and Web Application

Firewall (WAF). Honeytokens are not placed there,

because they are meant to address attackers who are

able to circumvent these defense technologies. Al-

though, on the perimeter border, an IDS rule can de-

tect the usage of a honeytoken (Qassrawi and Hongli,

2010).

Zone 2: represents the web application. Honeyto-

kens are placed here as they enable the application

to react just-in-time to an attack. A URL parameter

(https://example.com/site.php?admin=false) is an ex-

ample of how applications react to the usage of hon-

eytokens. When accessing the site with the parameter

admin=true, the application knows to call a speciﬁc

function defending against an attack. A further im-

plementation is a web application honeypot to track

bot crawls on a website (Lewandowski et al., 2020).

Zone 1 and 3: represent the web server and pos-

sible databases. These zones contain classic ﬁle or

database-entry tokens to collect as much data as pos-

sible about the attacker if zone 2 is compromised. A

webserver for example, storing honeytokens as ﬁles,

can monitor them through the meta data. An exﬁl-

tration of these honeytokens is noticed by monitoring

the ﬁle metadata, or by creating a trigger for the usage

of a query for these honeytoken database entries.

The higher the zone number, the further an attacker

has advanced into a system.

An example of the usage of honey token and the

reaction of webservers follows: (Petruni

c, 2015):

• Session Manipulation: If an attacker accesses a

honeytoken, the session in use may be terminated

or isolated into a sandbox mode. Also, every or

randomly chosen requests may be answered with

a HTTP 200 OK status code to feed the attacker

with false information. A request rate limiting or

intentional connection timeouts may further slow

down the attacker.

• Generated Vulnerabilities: Once the system de-

tects attackers it dynamically generates vulnera-

bilities to “keep the attackers happy” and to gain

more time to study the attackers.

• Attack the Attacker: The generated vulnerabilities

can deface attackers and reveal their identity by

forcing them to establish a direct communication

channel (Djanali et al., 2014) (Petruni

c, 2015).

• robots.txt: Fake URLs and entries in the robots.txt

help to identify attackers and malicious web spi-

ders. robots.txt deﬁnes whether a web spider is

allowed to index an URL or is not. When one of

the fake URLs in robots.txt is accessed by either

an attacker or malicious web spider, a speciﬁc re-

action may get triggered.

Honeytokens are either handcrafted or generated

through a tool like HoneyGen (Bercovitch et al.,

2011). Like honeypots, honeytokens slow down at-

tackers (Sandescu et al., 2017), and feed them with

false information

4.4 Real World Implementations

Honey systems are already used by different compa-

nies with different implementations. While compa-

nies usually do not publish their use of honey systems,

some are well known to use them and even openly ad-

mit to use honey systems. Nevertheless, enterprises

do not publish the exact implementation and version

of their honey system. Many telecom providers, as

well as security enterprises (ﬁrewall/NIDS manufac-

turers, antivirus/HIDS manufacturers, etc.) sustain

many honeypots in a honeynet. They are distributed

worldwide and create threat information and an attack

map, among other things. Associations hide their crit-

ical infrastructure with honey systems and improve

security efforts with the obtained information. Also,

hospitals and medical facilities test the integrity of

their personnel with a bogus patient record, for exam-

ple a honeytoken called “John F. Kennedy” (Spitzner,

2003b).

5 MOCK THE BEAR,

MANIPULATE THE HONEY

When operating any honey system there is always the

risk of a compromised system as well as a defaced

honey system. Either way, a honey system should

work as intended. Monitoring and logging tools must

be resistant to attacks to still record trustworthy in-

formation about an attack and an attacker. Also, at-

tackers are capable to detect honey systems with var-

ious methods. This demands various hiding meth-

ods. The following paragraphs explain monitoring

and logging methods, ways to distinguish honey sys-

tems from productive systems, and methods to miti-

gate a detection and to hide honey systems.

5.1 Find the Bear, Monitor the Honey

Various ways of monitoring honeypots exists. When

honeypots became popular, SEBEK was a popular

https://arstechnica.com/information-technology/2017/

05/macron-campaign-team-used-honeypot-accounts-to-

fake-out-fancy-bear/

How to Mock a Bear: Honeypot, Honeynet, Honeywall Honeytoken: A Survey

185

monitoring tool, superseded by XEBEK, a SEBEK-

like tool optimised for virtual machines. These are

data/trafﬁc capture kernel modules which send data

to a central logging server to monitor and visualise

events (Quynh and Takefuji, 2006). Nowadays, stan-

dard tools like syslog and Trusted Automated eX-

change of Indicator Information (TAXII) in combina-

tion with a central monitoring server are more com-

mon (Wagner, 2019). Since a honeypot is accessed

by an attacker, there has to be a focus on log authen-

ticity. Sending logs immediately to a remote logging

station and not storing them locally on a compromised

honeypot is part of a good log handling.

5.2 Detect the Honey

A recent paper describes a method to monitor and

analyse botnets with honeynets (Bajto

s et al., 2018).

To get authentic results, considerations must be made

on the fact, that many different ways of detecting hon-

eypots have been developed by attackers to avoid hon-

eypots. A quite old paper describes a way to detect

honeypots in a botnet (Zou and Cunningham, 2006).

The underlying problem is still present: “Should a

honeypot attack other systems to look authentic?” A

botnet is a network of infected machines controlled

by a bot controller (Puri, 2003). A bot controller com-

mands a new bot to attack a list of hosts. This list of

hosts or addresses include sensors, controlled by the

attacker, which report every attempt to contact them

to the bot controller. When the bot controller receives

an IP address, to which the controller commanded an

attack before, it is assumed a valid bot, otherwise it

might be a honeypot trying to sanitize its outgoing

trafﬁc to not attack others (Wang et al., 2010). This

introduces the dilemma of sanitising outgoing trafﬁc

due to legal affairs and getting authentic results.

5.3 Hide the Honey

Honeypots, honeynets, honeywalls, and honeytokens

need to be concealed from the attackers. The ﬁrst

step to hide them is to determine the type of attacker

they are hidden from. Usually, “attacker” means ev-

erything outside of an organisation or company. To

hide a honeypot from the outside, it should behave

like the emulated service in terms of user interaction.

This means that the front-end and user responses, es-

pecially the reaction time of the service, remain the

same as the original service (Litchﬁeld et al., 2016).

The back-end can be adjusted to the operators’ needs.

In the best case, an attacker does not know about the

structural design of an organisation, so little to no

management effort is required to hide honey systems.

The emulation of several things, including the net-

work stack and processing must be authentic to the

real service to disguise the honeypot (Litchﬁeld et al.,

2016). Network scanning tools like nmap

look

for protocol quirks to identify the exact implementa-

tion. Depending on the purpose, honeypots should or

should not emulate the exact quirks. Various methods

to properly emulate services are suggested (Qassrawi

and Hongli, 2010):

• Vulnerability Emulation: Only the vulnerable part

of a service or OS is emulated. PHP.HoP (Qass-

rawi and Hongli, 2010) uses this technique. This

obviously works only for already known vulnera-

bilities!

• Connection Tarpitting: Tarpitting in terms of hon-

eypots means delaying network trafﬁc and ser-

vice responses. Network trafﬁc may be delayed

by manipulation of the window ﬂag in Transmis-

sion Control Protocol (TCP/IP) packets. Service

responses may be delayed deliberately by wait-

ing milliseconds before sending them. Appropri-

ate waiting times might help to make a honey-

pot more authentic; e.g. sending a command to

a machine via a controller implies waiting for a

response from a controller which waits for the re-

sponse of the machine, which takes time. Imme-

diately sending a response likely unmasks a hon-

eypot.

• Trafﬁc Redirection: Suspicious trafﬁc gets redi-

rected to a honeypot. For example, a connection

establishment to an unused IP or suspicious traf-

ﬁc, detected with help of a NIDS, can be redi-

rected to a honeypot. However, a NIDS only de-

tects already known attack vectors and needs to

know the network topology or at least the used IP

addresses to detect unused IP addresses.

The techniques described here hide a honey system

from an external attacker. Hiding honey systems from

personnel or speciﬁc groups of personnel of an organ-

isation or company was not found in literature.

6 LEGAL AFFAIRS AND

PRIVACY

When operating a honeypot one has to consider sev-

eral legal aspects.

Liability is an important factor to consider. Ac-

tivity and trafﬁc from the honeypot is linked to the

organisation hosting the honeypot. If a honeypot is

compromised and attacks other systems or acts as an

https://nmap.org/

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

186

illegal market place for example, there are legal con-

sequences for the organisation. Especially neglected

honeypots, which are not monitored regularly, are a

popular target. To prevent consequences, aside from

the technical aspects, the goal and methods of a hon-

eypot should be documented in detail (Mokube and

Adams, 2007).

The right to monitor is competitive to the right of

privacy. As this tension is part of the daily life of

an IT-security engineer, this applies to honey systems

as well. Most countries already passed laws regard-

ing privacy matters, such as the Fourth Amendment,

the Wiretap Act, the Patriot Act, and the Freedom

Act in the USA and the GDPR in the EU. A deci-

sion, whether and how information can be logged,

is made regarding these laws (Mokube and Adams,

2007). A profound analysis of privacy matters, con-

cerning honey systems, has already been done based

on EU laws, already including GDPR, in 2017 (Sokol

et al., 2017).

7 CONCLUSION

This paper describes the different types of honeypots,

honeynets, honeywalls, and honeytoken. It explaines

the terminology and properties of the honey systems

and describes the ﬁelds where the systems are de-

ployed. Additionally, advantages and disadvantages

are discussed. Implementation thoughts, including

legal aspects and different techniques to detect and

hide honey systems, are given as well as techniques

to transmit threat information. As the purpose of hon-

eypots is to communicate with an attacker they are

at risk of being compromised. Therefore, a honey

system should always be operated with a NIDS and

should never be left unmonitored. Also, any logging

data should be transferred to a safe place immediately.

Honey systems are not a new ﬁeld in computer sci-

ence anymore. New insights into the topic based on

public research are limited, even though a lot of im-

plementation methods and tools have been developed.

Further research needs to be done to evaluate the hon-

eypot implementation of new services and protocols.

Recent papers combine honeysystems with modern

technologies like blockchains and machine learning

to mitigate honeysystem detection methods and to in-

crease malware detection rates. Although the meth-

ods are new, the data used to train systems is either

old (Wang et al., 2019) and is not comparable to mod-

ern internet trafﬁc or not described (Mart

ınez Garre

et al., 2020). The main challenge in upcoming honey

system development will be trusted, automated, dy-

namic attack pattern matching. Unfortunately, no so-

lution to hide a honey system from employees and ad-

ministrators in the same company has been developed

so far which is why further research into the matter is

necessary.

ACKNOWLEDGEMENT

This work has been supported by the Austrian State

Printing House. Furthermore, I would like to thank

Martin Pirker and Patrick Kochberger for giving help-

ful feedback about this paper.

REFERENCES

Bajto

s, T., Sokol, P., and M

eze

sov

a, T. (2018). Virtual hon-

eypots and detection of telnet botnets. In Proceed-

ings of the Central European Cybersecurity Confer-

ence 2018, CECC.

Baumann, R. and Plattner, C. (2002). Honeypots. Master’s

thesis, ETH Z

urich.

Bercovitch, M., Renford, M., Hasson, L., Shabtai, A.,

Rokach, L., and Elovici, Y. (2011). Honeygen: An

automated honeytokens generator. In Proceedings of

2011 IEEE International Conference on Intelligence

and Security Informatics. IEEE ITSS.

Bland, J. A., Petty, M. D., Whitaker, T. S., Maxwell, K. P.,

and Cantrell, W. A. (2020). Machine learning cyber-

attack and defense strategies. Computers & Security.

Bowen, B., Hershkoop, S., Keromytis, A., and Stolfo, S. J.

(2009). Baiting Inside Attackers Using Decoy Docu-

ments. In International Conference an Security and

Privacy in Communication Systems. SecureComm,

Springer.

Chamales, G. (2004). The honeywall cd-rom. IEEE Secu-

rity Privacy.

Cheswick, B. (1992). An evening with Berferd in which

a cracker is lured, endured and studied. In In Proc.

Winter USENIX Conference. USENIX.

Cui, M., Wang, J., and Chen, B. (2020). Flexible machine

learning-based cyberattack detection using spatiotem-

poral patterns for distribution systems. IEEE Transac-

tions on Smart Grid.

Disso, J. P., Jones, K., and Bailey, S. (2013). A plausi-

ble solution to SCADA security honeypot systems. In

2013 Eighth International Conference on Broadband

and Wireless Computing, Communication and Appli-

cations.

Dittrich, D. (2004). Customizing ISOs and the Honeynet

Project’s Honeywall.

Djanali, S., Arunanto, F. X., Pratomo, B. A., Baihaqi, A.,

Studiawan, H., and Shiddiqi, A. M. (2014). Aggres-

sive web application honeypot for exposing attacker’s

identity. In 2014 The 1st International Conference

on Information Technology, Computer, and Electrical

Engineering. ICITACEE.

How to Mock a Bear: Honeypot, Honeynet, Honeywall Honeytoken: A Survey

187

Fan, W., Du, Z., Smith-Creasey, M., and Fern

andez, D.

(2019). Honeydoc: An efﬁcient honeypot architecture

enabling all-round design. IEEE Journal on Selected

Areas in Communications.

Karen A. Scarfone, Peter M. Mell (2007). Guide to Intru-

sion Detection and Prevention Systems (IDPS). Tech-

nical report, NIST.

Lewandowski, P., Janiszewski, M., and Felkner, A. (2020).

Spidertrap - an innovative approach to analyze activity

of internet bots on a website. IEEE Access.

Litchﬁeld, S., Formby, D., Rogers, J., Meliopoulos, S., and

Beyah, R. (2016). Rethinking the honeypot for cyber-

physical systems. IEEE Internet Computing.

Mairh, A., Barik, D., Verma, K., and Jena, D. (2011). Hon-

eypot in network security: A survey. In Proceedings

of the 2011 International Conference on Communica-

tion, Computing & Security. ICCCS, ACM.

Malin, C. (2017). LureBox - Using Honeytokens for De-

tecting Cyberattacks. Master’s thesis, UAS St. P

olten.

Mart

ınez Garre, J. T., Gil P

erez, M., and Ruiz-Mart

ınez, A.

(2020). A novel machine learning-based approach for

the detection of ssh botnet infection. Future Genera-

tion Computer Systems.

Mokube, I. and Adams, M. (2007). Honeypots: Concepts,

approaches, and challenges. In Proceedings of the

45th Annual Southeast Regional Conference. ACM-

SE.

Papp, D., Ma, Z., and Buttyan, L. (2015). Embedded sys-

tems security: Threats, vulnerabilities, and attack tax-

onomy. In 2015 13th Annual Conference on Privacy,

Security and Trust (PST).

Petruni

c, R. (2015). Honeytokens as active defense. In

2015 38th International Convention on Information

and Communication Technology, Electronics and Mi-

croelectronics (MIPRO). MIPRO.

Pouget, F., Dacier, M., and Debar, H. (2013). Honeypot,

Honeynet, Honeytoken: Terminological issues. Insti-

tut Eur

ecom (EURECOM), Sophia Antipolis, France,

Research Report RR-03-081.

Project, T. H. (2001). Know Your Enemy: Honeynets.

Project, T. H. (2002). Know Your Enemy: Deﬁning Virtual

Honeynets.

Provos, N. (2003). HoneyD: A Virtual Honeypot Daemon.

Puri, R. (2003). Bots & botnet: An overview.

Qassrawi, M. T. and Hongli, Z. (2010). Deception method-

ology in virtual honeypots. In 2010 Second Inter-

national Conference on Networks Security, Wireless

Communications and Trusted Computing. NSWCTC.

Quynh, N. A. and Takefuji, Y. (2006). Towards an invisible

honeypot monitoring system. In Australasian Confer-

ence on Information Security and Privacy. ACISP.

Ren, J., Zhang, C., and Hao, Q. (2020). A theoretical

method to evaluate honeynet potency. Future Gen-

eration Computer Systems.

Sandescu, C., Rughinis, R., and Octavian, G. (2017). Hunt:

Using honeytokens to understand and inﬂuence the

execution of an attack. In Proceedings of the 13th

International Scientiﬁc Conference ”eLearning and

Software for Education”. eLSE.

Shi, L., Li, Y., Liu, T., Liu, J., Shan, B., and Chen,

H. (2019). Dynamic distributed honeypot based on

blockchain. IEEE Access.

Simmons, C., Ellis, C., Shiva, S., Dasgupta, D., and Wu, Q.

(2014). Avoidit: A cyber attack taxonomy. In 9th An-

nual Symposium on Information Assurance (ASIA’14).

ASIA.

Sokol, P., M

sek, J., and Hus

ak, M. (2017). Honeypots and

honeynets: issues of privacy. EURASIP Journal on

Information Security.

Spitzner, L. (2002). Honeypots: Tracking Hackers. Addison

Wesley.

Spitzner, L. (2003a). Honeypots: Catching the Insider

Threat. In 19th Annual Computer Security Applica-

tions Conference, 2003. Proceedings. IEEE.

Spitzner, L. (2003b). Honeytokens: The other honeypot. In

Endpoint Protection. Broadcom.

Vasilomanolakis, E., Karuppayah, S., M

uhlh

auser, M., and

Fischer, M. (2014). Hostage - a mobile honeypot for

collaborative defense. In Proceedings of the 7th Inter-

national Conference on Security of Information and

Networks. SIN.

Vasilomanolakis, E., Srinivasa, S., and M

uhlh

auser, M.

(2015). Did you really hack a nuclear power plant?

an industrial control mobile honeypot. In 2015 IEEE

Conference on Communications and Network Security

(CNS).

Wagner, T. D. (2019). Cyber threat intelligence for

“things”. In 2019 International Conference on Cy-

ber Situational Awareness, Data Analytics And As-

sessment (Cyber SA).

Wang, P., Wu, L., Cunningham, R., and Zou, C. C. (2010).

Honeypot detection in advanced botnet attacks. Int. J.

Inf. Comput. Secur.

Wang, Z., Li, G., Chi, Y., Zhang, J., Liu, Q., Yang, T., and

Zhou, W. (2019). Honeynet construction based on in-

trusion detection. In Proceedings of the 3rd Interna-

tional Conference on Computer Science and Applica-

tion Engineering, CSAE 2019. CSAE.

Zou, C. C. and Cunningham, R. (2006). Honeypot-aware

advanced botnet construction and maintenance. In In-

ternational Conference on Dependable Systems and

Networks (DSN’06). DSN.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

188