VISVESVARAYA TECHNOLOGICAL UNIVERSITY

“Jnana Sangama”, Belgaum-590014, Karnataka

TECHNICAL SEMINAR REPORT ON

EFFICIENCY AND SECURITY OF DOCKER

BASED HONEYPOT SYSTEM
Submitted in partial fulfillment of requirement for the award of degree of

BACHELOR OF ENGINEERING
IN
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

By:

TEJASWINI(1AH16CS059)

Under the guidance of

Kavitha K.Patil
Associate professor, CSE
Department of CSE

Department of Computer Engineering

ACS COLLEGE OF ENGINEERING
#74, KAMBIPURA, MYSORE ROAD, BANGLORE-74

Year 2019-2020
 ACS COLLEGE OF ENGINEERING
#74, KAMBIPURA, MYSORE ROAD, BANGLORE-74

Department of Computer Science and Engineering

CERTIFICATE
This is to certify that the Technical Seminar Report entitled “Efficiency and Security
of Docker based Honeypot System” has been presented by Tejaswini(1AH16CS059), a
bonafide student of ACS College of engineering affiliated to Visvesvaraya Technological
University, Belgaum during the year 2019-2020. It is certified that all the
corrections/suggestions indicated for internal assessment have been incorporated in the report
deposited in the departmental library. The seminar Report has been approved as it satisfies the
academic requirements in respect of seminar prescribed for the said degree.

………………………… ………………………… …………………………

Signature of the Guide Signature of the Coordinator Signature of HOD
Kavitha K.Patil Dr C S Pillai Dr V. Mareeswari
Asso Prof., CSE Associate Professor Associate Professor & HOD
Dept. of CSE, ACSCE Dept. of CSE, ACSCE Dept. of CSE, ACSCE

SI. NO Name of the examiners Signature with date

1.
2.
 ACKNOWLEDGEMENT

The satisfaction and euphoria that accompany the successful completion of any task would
be incomplete without mention of the people who made it possible, whose constant
guidance and encouragement crowned our effort with success.

I express my sincere gratitude to our management, ACS College of Engineering,

Bangalore for their timely help and inspiration during the tenure of the course.

I express my sincere gratitude to our principal Dr. M. S. Murali, Principal, ACS

College of Engineering, Bangalore, for his timely help and inspiration during the tenure of
the course.

I wish to place on record my grateful thanks to Dr. V. Mareeswari Prasanna,

Professor and HOD, Computer Science and Engineering, ACS College of Engineering,
Bangalore, for the encouragement and guidance.

I would also like to thank my guide, Mrs. Kavitha K Patil, Asst.Professor of

Computer Science and Engineering, for timely inspection and guidance me throughout the
process. I consider it my cardinal duty to express the deepest sense of gratitude for the
invaluable guidance extended at every stage in every possible way.

I hereby like to thank Dr. C S Pillai, Associate Professor, Dept. of Computer

Science and Engineering, for his periodic inspection, time to time evaluation of the seminar
and help to bring the seminar to the present form.

Also I thank the members of the faculty of Computer Science and Engineering
Dept. whose suggestions enabled me to surpass many of the seemingly impossible hurdles.
I also thank my guide and lastly I thank everybody who has directly or indirectly helped
me in the course of this seminar.

Tejaswini
(1AH16CS059)
 TABLE OF CONTENTS

CHAPTER NO TITLE PAGE NO

ABSTRACT

1. INTRODUCTION 1

2. LITERATURE SURVERY 3

2.1 HoneyLab: Large-scale Honeypot Deployment and Resource Sharing 3

2.2 Honey@home: A New Approach to Large-Scale Threat Monitoring 3

2.3 Dynamic & Hybrid Honeypot Model for Scalable Network Monitoring 4

2.4 Enhancing Security of Docker using Linux hardening techniques 4

3. METHODOLOGY

3.1 Honeypot Implementation 5

3.2 Honeynet Model 5

3.3 Information Capturing Mechanisms 6

3.4 Information Analysis Mechanisms 8

4. EXPERTIMENT AND RESULTS

4.1 Implementation Efficiency 11

4.1.1 Implementation Efficiency for Physical Computers

4.1.2 Implementation Efficiency for Virtualised Systems

4.1.3 Implementation Efficiency of Containers

4.2 DOCKER CONTAINER SECURITY MECHANISMS

4.2.1 Namespaces 13

4.2.2 CGroups 13

4.2.3 Capabilities 13

4.3 SECURITY ANALYSIS 14

 9.1 Denial of service 14

9.2 Host Comparison 16

9.3 Compromising the neighbouring containers 17

CONCLUSION AND FUTURE SCOPE 19

BIBLIOGRAPHY 20
 ABSTRACT

Honeypot is a computer, a group of computers, an application or just a single

service with the main task of attracting malicious agents. It is actually bait, used to detect
or mitigate attacks or simply to divert the attacker from the real services. The challenge in
creating honeypots is how to create an agile and flexible. Honeypot infrastructure. In this
paper we assert that, as regards to efficiency, containers are more suitable for this kind of
task compared to other technologies. However, we analyse the security of Honeypot
implementations inside of containers based on Docker, which is the de facto standard for
containers and a widely used implementation.
Efficiency and Security of Docker based Honeypot System

CHAPTER 1

INTRODUCTION

Scientists and experts in the field of computer security often use Honeypots in their work,
using it with high or low degree of interaction. Honeypots have a unique characteristic, which
deems any interaction as an illegal action, as it does not contain any actual services. Honeypot is
actually nothing but a "fake" service, acting as a bait with the aim of attracting a malicious
attacker, gathering as much data as possible about malicious actions and potentially activating a
predefined action. However, setting up just one Honeypot is often not enough to attract an
attacker, so usually a network of Honeypots is used, often distributed geographically.

However, some challenges are then encountered, which need to be taken into account.

• Security

• Flexibility

• Limited number of IP addresses

Another frequent issue is that the potential attackers recognise the nature of the Honeypot
and avoid it. This paper will use an analysis to show the security deficiencies of Docker
containers on which such Honeypots are based.

What is a Honeypot?

A Honeypot can be characterized as a closely monitored network decoy serving several

purposes. Honeypots can be set up to run any type of operating system and any number of
services. The value of a Honeypot is directly proportional to the amount and type of information
we can successfully obtain from it. Aside from information gathering, a Honeypot has the
capabilities of distracting adversaries from more valuable machines on a network, and can
provide early warning signs about a new type of attack or exploitation trends, and allows in-
depth examination of adversaries during or after exploitation of a host. Another function that a

Department of CSE, ACSCE Page 1

Efficiency and Security of Docker based Honeypot System

Honeypot allows is the capturing the keystrokes typed by an adversary attempting to

compromise the Honeypot this provides particularly interesting insight if an intruder uses the
compromised host as an IRC chat server. Two levels of Honeypots are described as low
interaction and high-interaction. Their currently exist two types of Honeypots: a physical
Honeypot which is a real machine with its own IP address, and a virtual Honeypot which is
simulated by another machine that responds to network traffic. Physical Honeypots are often
labeled as high interaction because the system can be completely compromised and are resource
expensive to install and maintain. For example - if you wanted to implement physical Honeypots
for a certain range of IPs on your LAN you would have to build a separate instance of a
Honeypot for each physical IP address. Virtual Honeypots are often labeled as low interaction
because of the low implementation and maintenance costs. A virtual Honeypot can simulate
multiple Operating Systems, services and a separate TCP/IP stack for each instance of a
Honeypot on that one machine. Honey is an example of a virtual honeypot service; simulating
the TCP/IP stack of multiple target operating systems in order to fool TCP/IP stack
fingerprinting by tools like Nmap and Xprobe. Virtual Honeypots are used more often than
physical Honeypots because they require fewer computer systems, which in turn reduces
maintenance costs, and also allows for a greater variety of hosts to be deployed and observed.

Problem domain:

Nowadays micro services and its implementation in containers especially, has begun to
be a mainstream architecture and technology for modern IT infrastructures. It brings many
advantages in difference to traditional physical or virtualized servers but also brings new risks.
So we are facing a question, are container based systems secure enough to be used for the
construction of honeypots that will be used against highly motivated and sophisticated malicious
actors.

Department of CSE, ACSCE Page 2

Efficiency and Security of Docker based Honeypot System

CHAPTER 2

LITERATURE SURVEY

2.1 Honey Lab: Large-scale Honeypot Deployment and Resource Sharing

W. Y. Chin, Evangelos P. Markatos, Spiros Antonatos, Sotiris Ioannidis

In this paper, We have designed and proposed honey-Lab: an overlay and distributed
architecture for deploying and monitoring honey pots. By sharing address space and computing
resources, Honey Lab allows security researchers and experts to implement honeypot services
around the world without the need to set up their own physical networks. Thus, deployment time
and cost are significantly reduced. Honey Lab promotes efficient sharing of address space by
permitting users to share IP address as well as passive monitoring among fellow researchers.
Unlike other honeypot infrastructures, Honey Lab allows security arms and security researchers
to deploy their own honeypot services, instrumentation code and detection algorithms,
dispensing the need for setting up a separate honeypot infrastructure whenever a new attack
detection method needs to be deployed or tested. We have successfully developed and tested an
implementation of Honey Lab. The initial evaluation is encouraging. We will further improve on
the design to make it more robust and transparent to the users. We hope it is useful to the security
community in detecting modern worms and attacks.

2.2 Honey@home: A New Approach to Large-Scale Threat Monitoring

S. Antonatos, M. Athanatos, G. Kondaxis, J. Velegrakis, N. Hatzibodozis, S. Ioannidis and E. P.
Markatos

We have explored the design of Honey@home, a lightweight tool that enables users
without expertise in honeypot technologies to contribute the fight against cyber-attacks.
Honey@home claims unused IP addresses and ports,either dynamically or statically, and
forwards all traffic directed to them to a centralized core of honeypots. The core consists of
honeydinstances as low-interaction honeypots and Argos systems as high-interaction ones. As
Honey@home can be used by anyone, including attackers, three major challenges need to be
addressed: hide the identity of users, hide the identity of honeypots and prevent automatic
installations. By using Tor, a well-known and deployed anonymization network used by

Department of CSE, ACSCE Page 3

Efficiency and Security of Docker based Honeypot System

thousands of users, we can hide the identity of both clients and honeypots. To prevent automatic
installations, each client needs to be registered through the official website, where CAPTCHA
techniques are used similar to many popular large-scale services. Overall, Honey@home enables
the creation of a distributed infrastructure with little effort and aimstoward a scalable solution
that overcomes the problem of classic honeypots, that is monitoring a small portion of unused IP
address space.

2.3 Dynamic & Hybrid Honeypot Model for Scalable Network Monitoring
Mr. Kartik Chawda, Mr. Ankit D. Patel

In this paper we have presented a novel Dynamic & Hybrid model for characterizing
and tracking Internet threats such as worms or automated attacks & proposed design
implementing such system. Our design includes a dynamic & hybrid honeypot engine that
integrates data collected from passive fingerprinting tools such as POf and active probing tools
such as Nmap to dynamically configure Honeyds. This dynamic & hybrid system is scalable and
is capable of providing fine grain detail about threats. Scale is achieved by a distributed
collection of lightweight network sensors which filter the interactions to highinteraction backend.

2.4 Enhancing Security of Docker using Linux hardening techniques

Amith Raj MP, Sahithya J Pai, Ashok Kumar, Ashika Gopal

This research has shown that by investing in the security of containers enhance the
security of Docker. This can be achieved by integrating any one of the LSM’s using suitable
profiles for on- premise secure cloud orchestration and deployments. The observations from this
paper is that some of the security risks vector can be mitigated. The future work of this research
would be implementing any one of the cloud orchestration tools like Ansible, Puppet, Chef for
secure, faster and easy way of deploying containers on cloud at high scale.

Department of CSE, ACSCE Page 4

Efficiency and Security of Docker based Honeypot System

CHAPTER 3

METHODOLOGY

3.1 HONEYPOT IMPLEMENTATION

Honeypots as independent systems are implemented either as physical computers or

physical devices. They usually have greater bandwidth, but are more difficult to maintain and the
services are not agile enough. Virtual Honeypots are implemented as virtual instances, whether
as virtual computers or lately as micro services, the so-called containers.

Figure 1: Honeypot Implementation

3.2 HONEYNET MODEL

To keep Honeypots from being isolated units, they are organized into clusters, called Honeynets.

The advantages of such setups are:

• Single point of sensor control.

• Central storage of event information.

Department of CSE, ACSCE Page 5

Efficiency and Security of Docker based Honeypot System

• Ability to correlate events on sensors in real time.

However, such a distributed architecture also has some disadvantages, which need to be taken
into account:

• Infrastructure complexity.

• Higher security risk.

• Problem of efficient management.

Figure 2: Honeynet Model

3.3 INFORMATION CAPTURING MECHANISMS

Capturing data on a system designed for compromise must be done in a fashion that
allows for significant analysis of activity, yet is un-obtrusive and transparent to the individual(s)
who are compromising the Honeypot. Data can be captured at three distinct points, all offering
their own benefits and drawbacks:

Department of CSE, ACSCE Page 6

Efficiency and Security of Docker based Honeypot System

3.3.1 Host-based:

Data capture on the compromised host allows the greatest potential to log incoming and
outgoing connections, commands entered on the host via the command line, and snapshots of
running processes. Unfortunately, this method also presents the greatest risk. An intruder will
often look for any logs and/or security tools, and attempt to disable them in order to conceal their
presence. This being the case, data capture could be halted or modified, thus tainting the results
of our experiment. Examples of tools used to log activity on a Honeypot are the operating
system’s system log (typically the first target of an intruder), any intrusion detection system with
packet capture ability, such as Snort, or a packet capture and analysis tool such as Ethereal, both
discussed below.

3.3.2 Network-based:

A safer, but more complex solution to data capture involves the Honeypot clandestinely
logging activity and sending it to a remote server for further analysis. This solution allows us to
archive the data collected by the Honeypot on a remote machine. We assume this server to be
hardened against attack, as the intruder may notice a data stream leaving the Honeypot, and
attempt to disable the collection mechanism. Using tools such as Sebek1, we can effectively hide
a data capture service on the Honeypot, and collect data on a remote server via a UDP
connection. Sebek records the activity of the intruder and covertly sends it to a gateway, server
within the network, or server elsewhere on the internet.

3.3.3 Router/Gateway-based:

The final common method used for data collection is at the actual gateway, router or
firewall level of the network. As a gateway moves all data between the hosts on a network and
the internet, we have the opportunity to log all connections and data moving from the internet to
our Honeypot(s). This offers a slight increase in risk over the Sebek solution described above, as
a gateway is typically not hidden in a network, and itself becomes a target for attack.
Additionally, this is a more hardware intensive solution, as you require a server to act in a
gateway role. Many small-scale or home gateways do not offer significant logging capabilities,
and cannot be used in this role.

Department of CSE, ACSCE Page 7

Efficiency and Security of Docker based Honeypot System

Figure 3

3.4 INFORMATION ANALYSIS MECHANISMS

Honeypots are extremely effective at containing and capturing blackhat activity. The true
potential of a Honeypot is unfulfilled unless this data is turned into useful information. A process
for capturing the data and converting it into the tools, tactics, and motives of blackhats must be
in place. This process is called data analysis. During our Honeypot trials we have found that this
process to the most challenging and time consuming part of our project. In the next few
paragraphs I am going to review some of the successful methods and techniques that we used
and other practitioners over the years.

3.4.1 Firewall Logs

Firewalls can be useful in analyzing the incoming and outgoing connections from your
Honeypot. Any network traffic going in and coming out of your Honeypot should be labeled as
suspicious or malicious in nature. However the logged traffic from your firewall can be tedious
to parse through and gather intelligence from. Depending upon the type of firewall you may be

Department of CSE, ACSCE Page 8

Efficiency and Security of Docker based Honeypot System

using for your Honeypot project, some firewalls allow the functionality of sending alerts via
email on predefined suspicious connections from your firewall, which can decrease the amount
of data you have to parse through and make your life easier. For example you may configure
your firewall to send an alert when your Honeypot attempts to establish an outbound FTP
connection. As we know this kind of signature outbound connection is often associated with the
case that the Honeypot has been compromised and the attacker is now trying to establish an
outbound connection.

3.4.2 IDS Analysis

Intrusion Detection Systems like Snort provides its users with basic sources of
information and also depending upon the console you are using with your IDS it has the
capability grouping similar types of alerts, types of network traffic, and grouping events in
chronological order or even characterizing a group of events as unique alerts. The three basic
sources of information an IDS provides it user are the following: IDS alerts when suspicious
activity has been triggered by a signature, captures packets of the stored suspicious activity and
finally Snort logs ASCII sessions or the ASCII data detected in the packet payload. For our
Honeypot trials these three sources of information proved to be useful and were stored on our
data capture/store machine. This was accomplished by configuring the data store machine to log
any suspicious activity coming in or going out of the Honeypot. An important note when
analyzing the information provided from the Snort logs is to also compare the Snort logs against
the firewall logs to add layers of confidence from any conclusions being made from the logs. In
our case we compared our Snort logs to the logs from our router to gain intelligence on time of
possible backdoor attacks or time of compromise of the Honeypot. Generally when an attacker
compromised our Honeypot, the attacker tried to establish an outbound connection which was
easily noticed. A useful tool that can be used to capture IRC traffic is a tool called privmsg.pl .
Max Vision developed this tool that quickly and efficiently extracts critical information from
IRC chat sessions. IRC or Internet Relay Chat is often used for hackers to communicate between
one another during their attempts to compromise machines, therefore you should seriously think
about trying to log any IRC traffic that be coming in or out of your Honeypot. Although we were
not fortunate enough to log any kind of IRC traffic it is still an important piece for better
understanding attacker’s motives and next moves.

Department of CSE, ACSCE Page 9

Efficiency and Security of Docker based Honeypot System

3.4.3 System Logs

All system activity on your Honeypot is logged locally to a syslog file depending upon
the types of Operating Systems you may choose to use for your Honeypot. Systems like UNIX,
versions of Microsoft Windows, and a few other Operating Systems have the capability of
logging all system activity on the local machine remotely from another machine. This capability
is very useful when trying to find how an attacker gained access to your Honeypot, where the
attack was coming from, types of system activity that may be suspicious such as reboots,
services being stopped or started, and accounts being disabled or created. Also since this system
activity is being logged remotely we can compare the system logs of the Honeypot against the
remote server to discover if the attacker may of deleted or modified the syslog file on the local
Honeypot machine. Also as I said above the information we gather from the syslog can be used
to compare against other logged information from our Firewall and IDS.

Department of CSE, ACSCE Page 10

Efficiency and Security of Docker based Honeypot System

CHAPTER 4

EXPERIMENT AND RESULTS

4.1 IMPLEMENTATION EFFICIENCY

4.1.1 Implementation efficiency for physical computers

It is obvious that an implementation of a Honeypot agent only on physical servers is not

efficient. The reason for this is:

• Longer time required to implement the agent

• Poor flexibility of the agent

• Significant unused resources remaining after the implementation

On the other hand, from the perspective of IT security, such implementations have a high
level of security. That means that, while compromising the Honeypot agent, the attacker will
compromise only the host agent, unless the Honeypot shares the computer with actual services.

4.1.2 Implementation efficiency for virtualized systems

Having in mind the level of isolation and the fact that each virtualized machine has its
own installed operating system, such virtual machine can be considered equivalent to a physical
machine. On the other hand, precisely due to the complete operating system, the "footprint" of
the agent is relatively large.

Footprint = Operating system + Honeypot size

The flexibility of such Honeypots is greater than that of physical implementations, as the
technology provides faster growth of instances, reduction of resources or simple cloning of the
instances.

Department of CSE, ACSCE Page 11

Efficiency and Security of Docker based Honeypot System

4.1.3 Implementation efficiency of containers

Container technology is not that recent, since the popular chroot mechanism appeared in
the 70s in Unix operating systems, where it was used to restrict the scope of processes. Later
implementations that occured were FreeBSD's Jail, OpenVZ, Linux Containers LXC, and finally
Docker and Rocket, which are the most common container formats today. Compared to physical
and virtual computers, the container instances are very light, as they do not contain a complete
operating system, and they implement only those functions, i.e.services which are necessary for
the purpose of the container. Containers rely on the operating system on which the container
management system is based, i.e. all containers share the same operating system kernel.

The advantages of such implementation, compared to physical and virtual servers, are:

• High speed of infrastructure implementation

• Small footprint

• Large flexibility

• Simple orchestration

• High density

However, having in mind the sharing of the operating system, i.e. of the system calls and
other system resources, it is questionable whether the isolation level is adequate for a Honeypot
implementation.

4.2 DOCKER CONTAINER SECURITY MECHANISMS

The container security is based on three basic mechanisms:

• Namespaces

• CGroups

• Capabilities

Department of CSE, ACSCE Page 12

Efficiency and Security of Docker based Honeypot System

4.2.1 Namespace

Namespaces are the first and most important container security mechanism, which
prevent the containers to be aware of the host resources, and in particular of the other containers
processes or the host resources implementing the containers. In this regard, Docker uses different
namespaces, such as as User, Net, mnt, IPC.

4.2.2 Cgroups

Cgroups are a mechanism that provides the containers with equal use of resources (CPU,
memory, IO resources). The goal is to protect the host or other containers from the denial of
service actions caused by problematic application behaviour or malicious actionswithin any of
the compromised containers. However, it should be noted that the basic startup of publicly
available Docker images largely does not have implemented settings for Cgroups, which will be
shown in the examples from the analysis.

4.2.3 Capabilities

Capabilities mechanism enables a fine granulation of access control to the containers. It

enables performance of a predefined set of operations possible within containers, while those are
actually controlled outside of containers themselves. The goal is to enable the containers to have
only the essential capabilities, in order to reduce the footprint of attack as much as possible. For
example, NET_BIND_SERVICE capability enables the container to open a port below 1024,
which are considered privileged network ports.An additional container protection mechanisms
are MAC (Mandatory Access Control) mechanisms, such as AppArmor, as implemented in
Ubuntu, or SELinux, as implemented in RedHat. However, with all the implemented protection
measures, NIST points out that the containers share the Linux kernel, which is one of the attack
vectors on the container infrastructure, which makes them more vulnerable than the standard
hypervisor isolation. Additionally, the vulnerability of a shared Linux kernel may have a
significant impact on all containers instanced on the host node.

Department of CSE, ACSCE Page 13

Efficiency and Security of Docker based Honeypot System

4.3 SECURITY ANALYSIS

For our analysis we used a virtualised Mint 18 operating system (kernel 4.4.0.21) with the
following chracteristics:

• 2 CPUs, 2.30GHz clock

• 2GB RAM

• 30GB HDD

• 10 GB Swap (SSD)

Docker version that we used was 17.07.0. Basic Ubuntu Docker images were used:

DISTRIB_ID=Ubuntu

DISTRIB_RELEASE=16.04

DISTRIB_CODENAME=xenial

DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

NAME="Ubuntu"

VERSION="16.04.3 LTS (Xenial Xerus)"

VERSION_CODENAME=xenial

The analysis presumes that the attacker has successfully compromised the Honeypot
software and has gained root (uid=1) command line access of the container on which Honeypot
is implemented. The aim is to show some of the actions which the attacker may take and the data
to be collected for the purpose of compromising of the container, host or the neighbouring
containers.

4.3.1 Denial of service

One of the Honeypot's tasks is to record the logs of the attacker's actions. For the
Honeypot, such logs are usually stored in a permanent storage space directly accessed by the

Department of CSE, ACSCE Page 14

Efficiency and Security of Docker based Honeypot System

container, or such logs are immediately sent to the central system for processing. Therefore, the
attacker may use a known vulnerability in order to deny disk storage to other containers and thus
prevent their execution. Another reason is to prevent Honeypot to store the recorded actions and
thus simply to remove the traces of attack. Vulnerability actually lies in the fact that there is a
limited disk space available. Another type of denial of service as regards the storage space is
based on the storage layers, i.e. two containers from the same image on the host. Therefore two
containers use the same inodes within metadata, which poses a threat of denial of service in case
when the attacker generates "garbage" with the goal of using all available inodes.

Figure 5 : An example of inode index of two conatiners

The third threat is the denial of memory and processor resources. Each container user has
access to host memory status (/proc/meminfo) and processor resources (/proc/procinfo). The
basic container settings do not prevent the container to allocate all the host memory orprocessor
resources, and thus prevent running of other containers on the host. The potential vulnerability
can be shown by inspecting the htop output:

Department of CSE, ACSCE Page 15

Efficiency and Security of Docker based Honeypot System

Figure 6

Figure 7 : An example of memory status of two containers

If the host has the OOM memory protection mechanism turned on, the attacker may
theoretically monitor memory usage and keep the memory levels below the OOM cleanup
mechanism threshold, but may still use the memory of other containers on the host node.

4.3.2 Host Comparison

All Docker containers share the same host kernel, i.e. system files, with the basic service
for creating and managing the containers. This achieves a high efficiency of the system, reduces
the system elements redundancy levels and/or facilitates container management.However, with

Department of CSE, ACSCE Page 16

Efficiency and Security of Docker based Honeypot System

the appearance of vulnerabilities of the kernel or the management service, there comes a threat of
the attacker abusing the vulnerabilities of the container, and potentially harm the container host
or other containers on the same host. The kernel is mature enough to reduce the frequency of
such attacks, but the MITRE CVE (Common Vulnerabilities and Exposures) vulnerability
database analysis shows the possible vulnerabilities which may cause the host to be
compromised.

Figure 8 : An example of known vulnerabilities

4.3.3 Compromising the neighbouring containers

Basic Docker configuration achieves network communication by creating a "bridged"

network interface, and the containers' virtual network interfaces connect to such created "bridge".
However, this architecture presents a range of threats arising from such implementations. The
simplest threat is the so-called ARP cache poisoning. Upon its instancing, each container has an
empty table. However, the attacker is able to spoof his identity by using various attacks (e.g. arp
spoofing) and reroute the network traffic.

Figure 9 : Abuse of bridge implementation deficiencies

Department of CSE, ACSCE Page 17

Efficiency and Security of Docker based Honeypot System

Figure 10 : Result of bridge implementation deficiencies

Since the attacker who took over the container is able to view the CPU and memory
usage, this opens the possibility for an side channel attacks. The attacker is able to initiate the
attack using a specially crafted query sent to certain applications located within a container
located on the same host as the Honeypot. By monitoring the CPU usage, the attacker can glean
more info about other containers on the system. At the end of 2017 we were faced of processor
vulnerabilities Meltdown and Spectre (CVE-2017-5753, CVE-2017-5715,CVE-2017-5754).
Because those are vulnerabilities of processors, containers are not immune to Meltdown and
Spectre exploits. So well know vulnerabilities allows compromised containers to read memory of
other containers and all other running processes on the same host.

Department of CSE, ACSCE Page 18

Efficiency and Security of Docker based Honeypot System

CHAPTER 5

CONCLUSION AND FUTURE SCOPE

The basic container characteristics are high efficiency, small footprint and high
flexibility, which makes them suitable for creating an infrastructure which can be set up or
dismantled quickly. Although Docker containers are considered secure, the basic implementation
which comes with already prepared Dockerfile files or GitHub images does not satisfy the
security requirements for building a Honeypot infrastructure, e.g. Cowrie Dockerfile or other
available images. An additional problem is that Honeypot's purpose is to attract malicious users,
who usually have a very good knowledge of systems penetration, so it is to be expected that they
will use all the possible weaknesses of the basic container installations. Docker actually supports
powerful security mechanisms, if properly configured:Capabilities, Cgroups, MAC (AppArmor
or SeLinux) are very powerful mechanisms, but they all require knowledge for their proper
configuration. Some vulnerabilities can be resolved by using the best practices:

• Use of verified images.

• Use of minimal OSs (Atomic, CoreOS, Vmware Photon).

• Isolation at the hypervisor level.

• Immunisation of capabilities.

• Reduction of resource.

FUTURE SCOPE

1) Mobile Device Based

2) Wireless Honeypots
3) SPAM Honeypots
4) Search-Engine Honeypots

Department of CSE, ACSCE Page 19

Efficiency and Security of Docker based Honeypot System

BIBLIOGRAPHY

[1] W. Y. Chin, Evangelos P. Markatos, Spiros Antonatos, Sotiris Ioannidis, “HoneyLab: Large-
scale Honeypot Deployment and Resource Sharing”, 2009 Third International Conference on
Network and System Security, IEEE Computer Socienty, 2009, pp. 381-388.

[2] S. Antonatos, M. Athanatos, G. Kondaxis, J. Velegrakis, N. Hatzibodozis, S. Ioannidis and E.

P. Markatos, “Honey@home: A New Approach to Large-Scale Threat Monitoring”, IEEE
Computer Socienty, 2008.

[3] Mr. Kartik Chawda, Mr. Ankit D. Patel “Dynamic & Hybrid Honeypot Model for Scalable
Network Monitoring”, IEEE , 2014.

[4]Roberto Morabito, Jimmy Kjällman, and Miika Komu “Hypervisors vs. Lightweight
Virtualization: a Performance Comparison”, IEEE , 2015.

[5] Miguel G. Xavier, Marcelo V. Neves, Fabio D. Rossi, Tiago C. Ferreto, Timoteo Lange,
Cesar A. F. De Rose, Performance Evaluation of Container-based Virtualization for High
Performance Computing Environments, IEEE, 2013.

[6] Theo Combe, Telecom Paris-Tech Antony Martin and Roberto Di Pietro, Nokia Bell Labs,
To Docker or Not to Docker: A Security Perspective, IEEE Cloud Computing, 2016

[7] Amr A. Mohallel, Julian M. Bass, Ali Dehghantaha, Experimenting with Docker: Linux
Container and BaseOS Attack Surfaces, IEEE, 2016.

[8] Amith Raj MP, Sahithya J Pai, Ashok Kumar, Ashika Gopal, Enhancing Security of Docker
using Linux hardening techniques, IEEE, iCATccT.

[9] NIST 800-190, Application Container Security Guide, NIST, 2017.

[10] Yang Luo, Wu Luo, Xiaoning Sun, Qingni Shen, Anbang Ruan, Zhonghai Wu, Whispers
Between the Containers: High-capacity, Covert Channel Attacks in Docker, IEEE 2016.

[11] Docker CVE, https://www.docker.com/dockercve-database.

Department of CSE, ACSCE Page 20

Efficiency and Security of Docker based Honeypot System

[12] Yinqian Zhang University of North Carolina Chapel Hill, NC, USA yinqian@cs.unc.edu
Ari Juels Cornell Tech (Jacobs Institute) New York, NY, USA juels@cornell.edu Michael K.
Reiter University of North Carolina Chapel Hill, NC, USA reiter@cs.unc.edu Thomas Ristenpart
University of Wisconsin Madison, WI, USA rist@cs.wisc.edu, Cross-Tenant Side-Channel
Attacks in PaaS Clouds.

[13] Moritz Lipp1 , Michael Schwarz1 , Daniel Gruss , Thomas Prescher , Werner Haas , Stefan
Mangard , Paul Kocher, Daniel Genkin, Yuval Yarom, Mike Hamburg, Meltdown, 2017.

[14] Paul Kocher, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp,
Stefan Mangard, Thomas Prescher, Michael Schwarz, Yuval Yarom, Spectre Attacks: Exploiting
Speculative Execution, 2017.

[15] Stipe Kupan, Sjepan Groš, Miljenko Mikuc, An Experiment in Using IMUNES and Conpot
to Emulate Honeypot Control Networks, Mipro 2017.

Department of CSE, ACSCE Page 21