I’ve written in previous posts about my honeypot setups and the visualization software that I use to display the data. You may also recall that I typically run my honeypots on underpowered cloud-based servers in an effort to keep costs low. This has caused a few issues at times. First of all, I’ve found that the various visualization software packages that I use tend to be sluggish when running on the same virtual server as my honeypots.
Another problem I’ve encountered occurs when an attacker figures out that my machine is a honeypot and he/she starts to DDOS me. The resultant log file growth will quickly fill your hard drive. Lastly, sometimes after your honeypots have been running for several months, you may just have collected too much data and your visualization software is behaving even more sluggishly.
Unrelated to the hardware specs of the virtual server, I’ve also had situations where the honeypot that I set up is not really capturing any useful data. I always get plenty of inquiries but sometimes I do not capture any binaries and that’s really the main thing I’m looking to do. Whatever the reason, I’ve found it to be good practice to reset my honeypots from time to time.
When I first started my honeypot journey, I would first install and configure the various honeypot software that I was using. After the honeypots were up and collecting data, I would next add the visualization software to the server. I used DionaeaFR to examine data from my Dionaea honeypot and Kippo Graph for my Cowrie honeypot.
This all worked out fairly well but setting up the visualization software was a somewhat tedious process especially if I had to rebuild my honeypot server with any regularity. Firstly, there were a lot of various dependencies that had to be installed. Secondly, and perhaps most troublesome, the visualization software is, for the most part, not being actively maintained (if it’s even maintained at all).
At first glance, this wouldn’t seem to be a big issue. After all, if the software works as expected what does it matter if it’s maintained? Problems come into play, though, because the dependencies are generally being actively updated. Because of this, every time you reinstall the visualization software, you face the possibility of there being one or more broken dependencies. You never know from one installation to the next what you might run into. At first, I tried to keep track of the versions of the various dependencies that were required to run the software but that just became too tedious.
The answer that I came up with was to split the two functions – honeypot data collection and visualization – onto two different computers. I still have my honeypots on a Digital Ocean droplet but I moved the visualization functions to a local VM on my home network (more detail on this in my next blog entry – coming soon). Now when I have to rebuild my honeypots, it’s a simple matter of creating a new droplet – which take just a minute or two – then installing the honeypots and their minimal dependencies. Here’s the procedure that I use.
Dionaea is the easiest of the two to install. Again, I should note that I’m using Digital Ocean as my cloud server provider. I’m using the least expensive droplet ($5.00 per month).
1. Create a new droplet – be sure to select Ubuntu 14.04
2. Next, change the root password (see **side note below)
3. Now SSH into your droplet and run the following commands:
apt-get install dionaea
4. Add your VirusTotal API key (if you have one) to:
5. Change to /opt/dionaea/etc/dionaea/ihandlers-enabled and use the following command to create a symbolic link to the file you just updated:
ln -s ../ihandlers-available/virustotal.yaml virustotal.yaml
6. Now start the service:
service dionaea start
That’s it. You should now have a Dionaea honeypot up and running.
Note: Unfortunately, Dionaea will not capture WannaCry or SambaCry traffic but it shouldn’t be long – see discussion here.
The Cowrie install is a little more involved but is still pretty straightforward. This procedure mostly follows the steps in Michel Oosterhof’s (Cowrie’s creator) post here.
1. Install dependencies (note: this is all one line):
sudo apt-get install git python-virtualenv libmpfr-dev libssl-dev libmpc-dev libffi-dev build-essential libpython-dev python2.7-minimal authbind
2. Change the port that’s used for connecting and administering your SSH server. To do this, modify the sshd_config file like so:
(of course, you can use your preferred text editor – I prefer nano)
When you open the file, you’ll see near the top, the port that the SSH daemon is listening on (typically, its 22). Change it to something like 8925.
Now, you’ll need to restart the SSH service with:
service ssh restart
3. Create a user account. It’s strongly recommended to install Cowrie under a dedicated non-root user account. (note: those are 2 dashes before disabled-password)
sudo adduser –disabled-password cowrie
You’ll get this response:
Adding user `cowrie’ …
Adding new group `cowrie’ (1002) …
Adding new user `cowrie’ (1002) with group `cowrie’ …
Changing the user information for cowrie
Enter the new value, or press ENTER for the default
Full Name :
Room Number :
Work Phone :
Home Phone :
Is the information correct? [Y/n]
Note, you don’t have to specify anything when the questions come up – just hit enter.
4. One problem that we’ll run into now is that you need to be root to listen on ports below 1024 and since we’re starting Cowrie as a non-root user, we’ll get an error. There are a couple of ways around this problem. We’ll use authbind to address the issue. The first part of the process is listed below. We’ll finish up the authbind setup as the Cowrie user.
chown cowrie /etc/authbind/byport/22
chmod 777 /etc/authbind/byport/22
If you are going to use Cowrie to also capture Telnet data, then you’ll want to repeat the three commands above using port 23 instead of 22.
3. Login as the cowrie user and checkout the code:
We’ll perform the remaining steps as the user we just created.
git clone http://github.com/micheloosterhof/cowrie
Cloning into ‘cowrie’…
remote: Counting objects: 2965, done.
remote: Compressing objects: 100% (1025/1025), done.
remote: Total 2965 (delta 1908), reused 2962 (delta 1905), pack-reused 0
Receiving objects: 100% (2965/2965), 3.41 MiB | 2.57 MiB/s, done.
Resolving deltas: 100% (1908/1908), done.
Checking connectivity… done.
4. Setup and Activate Virtual Environment – this allows you to keep the required dependencies where they need to be without breaking anything else that may rely on other versions of the same libraries or tools.
$ virtualenv cowrie-env
New python executable in ./cowrie/cowrie-env/bin/python
Installing setuptools, pip, wheel…done.
Activate the virtual environment and install packages:
$ source cowrie-env/bin/activate
(cowrie-env) $ pip install -r requirements.txt
5. Copy and modify the config file:
cp cowrie.cfg.dist cowrie.cfg
Now, edit the file and make a few changes:
Look for the line that reads something like:
hostname = srv04
You’ll probably want to change it to something more enticing like:
hostname = accting01
or something like that.
Now, also in the cowrie.cfg file, let’s continue addressing the authbind config. Cowrie listens on port 2222 by default but we want to change it to 22 (the standard SSH port). Scroll down and look for the line that reads:
#Port to listen for incoming SSH connections.
Below this line, add:
listen_port = 22
Note that if you’re also capturing Telnet traffic with your honeypot, you’ll also want to change the listen_port in the Telnet section to 23
Save and exit.
One last thing to change – edit the /home/cowrie/cowrie/bin/cowrie file and change the second line to read:
AUTHBIND_ENABLED = yes
Now we should be ready to start Cowrie.
6. Starting Cowrie
Cowrie is implemented as a module for Twisted, but to properly import everything the top-level source directory needs to be in python’s os.path. This sometimes won’t happen correctly, so make it explicit:
$ export PYTHONPATH=/home/cowrie/cowrie
Start Cowrie as shown below. This will automatically start the virtual environment as well.
Activating virtualenv “cowrie-env”
Starting cowrie with extra arguments  …
From here you can exit as the cowrie user and exit from your virtual server.
At this point, you now have a Dionaea and a Cowrie honeypot running and capturing data on your VPS.
Here are a few places on your honeypot server to look for data:
/opt/dionaea/var/dionaea/binaries – Captured binaries
/opt/dionaea/var/dionaea/bistreams/YYYY-MM-DD – Session transcripts
/opt/dionaea/var/dionaea/dionaea.log – Dionaea’s text-based log file
/opt/dionaea/var/dionaea/dionaea.sqlite – Dionaea’s SQLite log file
/home/cowrie/cowrie/dl – Captured binaries
/home/cowrie/cowrie/log – .json log files
/home/cowrie/cowrie/log/tty – Session playback files
In the next blog entry, we’ll talk about how to visualize and utilize these data.