Honeypot part 1: Setting up Cowrie and Dionaea


Honeypots are a great way to learn more information about how different services are being exploited, to monitor malicious activity in an isolated environment and to gather information about subjects such as usernames, passwords, shell commands, etc. Some honeypots are also equipped with the ability to capture binaries transferred to the server, and further analysis of these can reveal undetected malware.

In this tutorial we will go over the installation and configuration of Cowrie and Dionaea – two powerful honeypots that complements each other nicely. Dionaea is a honeypot designed to emulate vulnerable services ranging from the network file sharing protocol for Windows (SMB) to SQL servers. Cowrie is designed to emulate a vulnerable SSH and Telnet server. Both of these honeypots are designed to capture the behavior of the attacker and to collect binaries transferred to the server by intruders.

Our goal

The goal of this tutorial is to set up a honeypot server that can capture the behavior of an attacker as well as binaries such as ransomware worms. The setup will consist of the following two components:

  1. Dionaea: A honeypot designed to capture malware.
  2. Cowrie: A SSH and Telnet honeypot designed to log brute force attempts and the behavior of an attacker.


To complete this tutorial you are going to need root access to an Ubuntu 14.04 server, whose sole purpose is to be utilized as a honeypot. Both Cowrie and Dionaea are fairly safe to run, but they do not come with any guarantees – storing any sensitive information on the honeypot is therefore not advised.

The author of this tutorial utilizes a virtual server rented from DigitalOcean that has 1 CPU and 512MB memory, which only costs $5/month to operate.

Installing and configuring Dionaea

SSH into your honeypot and begin with the following two commands to ensure that the distribution is up-to-date:

$ sudo apt-get update
$ sudo apt-get dist-upgrade

Make sure that the necessary tools are available in order to easily manage Personal Package Archive (PPA) resources:

$ sudo apt-get install software-properties-common

Now add the PPA which Dionaea resides in and update the cache of the package manager:

$ sudo add-apt-repository ppa:honeynet/nightly
$ sudo apt-get update

You should now be able to install Dionaea through the package manager:

$ sudo apt-get install dionaea

Once Dionaea is installed, change directory to the Dionaea configuration directory and list the contents of it:

$ cd /opt/dionaea/etc/dionaea
$ ls

You will now be presented the following file and directories:

  • dionaea.cfg
  • ihandlers-available
  • ihandlers-enabled
  • services-available
  • services-enabled

The dionaea.cfg file holds general configuration about the honeypot, such as which modules the honeypot will make use of and details about the raw log files. The raw log file of Dionaea can accumulate to a size in the name of gigabytes within weeks, so consider disabling it by commenting it out, unless you need it for debugging:



In the ihandlers-available directory, you will find tools Dionaea can make use of in order to process binaries or to log incidents. In the ihandlers-enabled directory, you will find those already enabled. If you want to enable an ihandler, you will have to make a symbolic link in the ihandlers-enabled directory that points to the ihandler you want to enable. Some ihandlers require configuration, so you should read about the specific ihandler in the official Dionaea documentation before enabling it.

The services are protocols such as SMB, FTP and MySQL that the honeypot mimics. These are enabled by using the same method as the ihandlers. By default, all available services are enabled. If you would like to disable a service, simply delete the symbolic link from the services-enabled directory.

This tutorial would like to make use of Dionaea’s ihandler for processing captured binaries with VirusTotal, if you would like this too you will need to register an account at virustotal.com, if you have not already got one. Once you have registered the account, sign in to it and head to the settings page. In the settings page you will be able to obtain a public API key, which Dionaea will use to communicate directly with VirusTotal.

First we need to edit the configuration file of the ihandler, which is the ihandler itself. Paste your API key between the empty quotes (you should still be in the /opt/dionaea/etc/dionaea directory):

$ sudo nano ihandlers-available/virustotal.yaml

Exit the file. We now need to enable the ihandler by creating a symbolic link to it from the ihandlers-enabled directory:

$ sudo ln -s ../ihandlers-available/virustotal.yaml ihandlers-enabled/virustotal.yaml

Dionaea will by default listen on the port 23 (Telnet) with its black hole service, which means it will open a connection when an entity tries to connect to the port, but it will not respond to it. This tutorial will utilize Cowrie for Telnet, this means we will have to remove port 23 from the black hole service of Dionaea:

$ sudo nano services-available/blackhole.yaml

Comment out the configuration of port 23 by putting a # in front of it, like so:

- name: blackhole
      # Telnet
      #- port: 23
      # protocol: tcp

After you have decided on a configuration, you may start the honeypot:

$ sudo service dionaea start

Note: A simple Nmap scan of the server will reveal that it is running a Dionaea honeypot. Most of the attacks against Dionaea are automated, so this won’t matter. However, if you would like for the Dionaea honeypot to evade Nmap detection, check out the following tutorial:

Installing and configuring Cowrie

You are most likely logged into the server through SSH, which is the service Cowrie is designed to emulate. SSH runs by default on port 22, we need to change the original SSH service to listen to another port so Cowrie can make use of port 22:

$ sudo nano /etc/ssh/sshd_config

Remove the # from the following line and change the 22 to something else, like 2122.

# Port 22

Restart the SSH service (remember to use the new port next time you connect!):

$ sudo service ssh restart

We can now prepare to install Cowrie by installing some dependencies:

$ sudo apt-get install git python-virtualenv libssl-dev libffi-dev build-essential libpython-dev python2.7-minimal authbind

Create a new user responsible for running the cowrie honeypot (use default settings):

$ sudo adduser cowrie

Now we need to delete the password for the user. This way nobody will be able to sign into the user, but we can still switch to the user with the su command:

$ sudo passwd -d cowrie

Switch user to the newly created cowrie user and change directory to the its home folder:

$ sudo su cowrie
$ cd

Clone the Cowrie honeypot from Github and change directory to it:

$ git clone http://github.com/micheloosterhof/cowrie
$ cd cowrie

Make sure you are working from the directory /home/cowrie/cowrie:

$ pwd

Create a virtual environment for the Cowrie honeypot:

$ virtualenv cowrie-env

Activate the virtual environment:

$ source cowrie-env/bin/activate

Install some required python packages to the virtual environment:

(cowrie-env)$ pip install --upgrade pip
(cowrie-env)$ pip install --upgrade -r requirements.txt

Exit from the virtual environment:

(cowrie-env)$ deactivate

Generate a backup SSH key in case the python package Twisted is not compatible:

$ cd data
$ ssh-keygen -t dsa -b 1024 -f ssh_host_dsa_key
$ cd ..

Ensure that Twisted is able to reach the startup file for Cowrie sufficiently:

$ export PYTHONPATH=/home/cowrie/cowrie

There are ways an attacker may use to figure out that they are inside a Cowrie honeypot. The most notable sign is that there is only one directory under /home, which is named richard. Another sign is the that the server is using the hostname srv04.

The developers of Cowrie have included a tool that lets us rebuild the fictive filesystem, but offers little documentation as to how it works. It might be easier to just edit a few files in order to fix this.

First we need to change the hostname, this is done in the configuration file of Cowrie. By default, Cowrie comes with a configuration file that may be overwritten when performing upgrades to the it. Let’s make sure that Cowrie does not overwrite our configurations by making a second configuration file. Cowrie will read both configuration files, but configurations made in cowrie.cfg will take precedence:

$ cp cowrie.cfg.dist cowrie.cfg
$ nano cowrie.cfg

Remove the # from the following line and change “srv04” into something else:

# hostname = srv04

While we are in the config file, we can also update Cowrie to listen to port 22 directly. Remove the # from the following line and change 2222 to 22:

# listen_port = 2222

Go down to the following line, and do the same – change 2222 to 22:

listen_endpoints = tcp:2222:interface=

In the same config file, enable telnet by replacing false with true in the following line:


# Enable Telnet support, disabled by default
enabled = false

Make Cowrie listen to the correct port of Telnet, which is 23. Remove the hashtag and edit 2223 to 23:

#listen_port = 2223

Almost done, change 2223 in the following line to 23:

listen_endpoints = tcp:2223:interface=

Save and exit. Now we can start fixing the richard-issue, edit the following file:

$ nano data/fs.pickle

Now we need to define which fictive user the filesystem is going to use. Find the following line and change “richard” into something else, like “admin” or “supervisor” (Hint: use ctrl+w to search for richard inside the file):


Exit and save the file, now edit the following file:

$ nano honeyfs/etc/passwd

Find the following line and change it according to the user that you defined above:

richard:x:1000:1000:Richard Texas,,,:/home/richard:/bin/bash

Exit and save, now edit the following file:

$ nano honeyfs/etc/group

Change the group name from richard to the previously defined user:


Save and exit, now for the next file:

$ nano honeyfs/etc/shadow

Swap “richard” with the new username:


Save and exit.

Excellent! We have now changed the username and hostname, now we need to administrate which passwords to accept:

$ nano data/userdb.txt

By default, Cowrie will allow any password except “root” and “123456”:


This tutorial recommends to only allow one, slightly common, password for each user – this way you will gather more information about popular passwords. It is all about finding a balance between a not-so-common password and a not-so-obscure password – you will probably want to gather information from successful logins as well. Replace the above configuration with the one below:


Consult the following Top 10 000 password list if you need inspiration. Experiment with the results by moving from a top 100 password to a top 1 500 password and find what result suits you best:

Exit the from the user cowrie:

$ exit

We have configured Cowrie to listen on port 22 and 23. However, this collides with two security issues: 1) Only privileged users may listen on ports below 1024 and 2) The Cowrie honeypot should not be executed by a privileged user.

The solution to this dilemma is Authbind, which lets us override the first rule in order to let our unprivileged cowrie user listen on port 22 and port 23 directly:

$ sudo apt-get install authbind
$ sudo touch /etc/authbind/byport/22
$ sudo chown cowrie:cowrie /etc/authbind/byport/22
$ sudo chmod 770 /etc/authbind/byport/22

$ sudo touch /etc/authbind/byport/23
$ sudo chown cowrie:cowrie /etc/authbind/byport/23
$ sudo chmod 770 /etc/authbind/byport/23

Change the execution file of Cowrie to reflect that it is going to use Authbind:

$ sudo nano /home/cowrie/cowrie/bin/cowrie

Change the following from “no” to “yes”:


Switch back into the user cowrie again, because root should not start cowrie:

$ su cowrie

Start Cowrie and exit back to the original user:

$ /home/cowrie/cowrie/bin/cowrie start
$ exit

Some useful places to know about

Logs: /opt/dionaea/var/dionaea
Captured binaries: /opt/dionaea/var/dionaea/binaries
Session transcripts: /opt/dionaea/var/dionaea/bistreams/YYYY-MM-DD

Logs: /home/cowrie/cowrie/log
Captured binaries: /home/cowrie/cowrie/dl
Playback files: /home/cowrie/cowrie/log/tty


In this tutorial we have configured a server to run the honeypots Cowrie and Dionaea. Together they are emulating vulnerabilities on the following services:

Protocol Port(s) Honeypot
SSH 22 Cowrie
Telnet 23 Cowrie
FTP 21 Dionaea
TFTP 69 Dionaea
Memcached 11211 Dionaea
MongoDB 27017 Dionaea
Microsoft SQL Server 1433 Dionaea
MySQL 3306 Dionaea
SMB 445 Dionaea
UPNP 1900 Dionaea
MQTT 1883 Dionaea
Microsoft EPMAP (aka. DCE/RPC) 135 Dionaea
SIP 5060, 5061 Dionaea
PPTP 1723 Dionaea
HTTP 80, 443 Dionaea
Nameserver 42 Dionaea
DNS 53 Dionaea (black hole)
NTP 123 Dionaea (black hole)

The information about the behavior of the attackers are currently residing in logs, which can be painful to sift through. In the next part of this tutorial, we will look at how we can visualize this data by utilizing the ELK stack.

Next tutorial: Visualizing the logs using the ELK stack

Sources used

Execute Malware – Honeypots Revisited (March 21, 2017):

The official documents of Dionaea and Cowrie.

Read more

The official documentation of Dionaea:

The official Github page of Cowrie:


6 thoughts on “Honeypot part 1: Setting up Cowrie and Dionaea

    • You may experience thousands of login attempts a day on your Cowrie honeypot, so I would not advice you to do this. You should check out the ELK stack, and how you can use Beats to ship the logs of Cowrie to their visualization platform. This way you could easily monitor failed and successful login attempts.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s