Setting up the Dshield honeypot and

Published: 2020-07-01
Last Updated: 2020-07-02 01:46:55 UTC
by Jim Clausing (Version: 1)
6 comment(s)

After Johannes did his Tech Tuesday presentation last week on setting up Dshield honeypots, I thought I'd walk you through how I setup my honeypots. I like to combine the Dshield honeypot with Didier Stevens' tcp-honeypot so I can capture more suspicious traffic. Today, I'll walk you through my setup using a VM hosted by Digital Ocean, though the steps would work for pretty much any cloud provider.

I'm using Digital Ocean because you can set up a simple VM that is more than adequate as a honeypot for $5/mo. So, let's get to it.

First off, I'm going to create a new droplet (you may have to create a new project first). It is pretty straight forward. 

As you can see, that gets you a VM with 1 processor and 1GB of RAM, but that will be plenty. Next, you get to choose which datacenter you want this VM running in. For this exercise, I'm choosing London, but my next one might be Bangalore or Singapore or Toronto (you know how those Canadians are).

There a few more decisions you need to make. I highly recommend that you upload an ssh public key rather than setting a root password, but once you've done all that, hit the button to create your VM and wait until it comes back with the public IP of said new VM.

Now, from wherever you intend to administer the VM from, slogin root@<ip of your VM>, and one of the first things I would do (assuming you used a public key) is to modify /etc/ssh/sshd_config and change PermitRootLogin to without-password (don't get me started on what a poor choice that was for the name for enforcing only key-based logins). From this point on, I'll mostly follow the instructions found on github for installing the Dshield honeypot on Ubuntu. Note, I can skip the step about installing openssh-server since that is already there by default. Before installing the honeypot, let's get the system current on patches

# apt update && apt full-upgrade -y && init 6

So, we're now up-to-date on patches. Personally, there are a few other things that I add now to help me administer the honeypot, like installing aide and apticron. I also tweak the settings for unattended-upgrades, and modify /etc/postfix/ to set the interfaces line to loopback-only, but we have a reasonably minimal system, at this point. Next we'll get the install script from github (git is also already installed) and actually install the Dshield honeypot.

Then you can run dshield/bin/ to do the actual install. A couple of things to beware of in doing the install. First, make sure you include the IP of the system from which you plan to administer the honeypot in the 'local' IPs. Trust me, I've locked myself out more than once by forgetting that, so learn from my mistakes. Then, I'm going to set this honeypot for manual update for reasons I'll explain below. Otherwise, I pretty much just take the defaults and paste in my e-mail and API key from my account page at At this point, you actually should have a working Dshield honeypot, but as I mentioned above, I want to add another honeypot tool.

I've become a big fan of Didier Stevens' (he's going to rename it when he officially releases it sometime soon-ish, because it can also do UDP), but I'm using the 0.1.0 version from Feb 2020. He appears not to have checked into his github beta repo, so if you want to play with the version I'm using, I guess you could contact me or just wait for Didier's official release whenever that happens. I've actually made 2 minor modifications to the 0.1.0 version, the first is that I make it log to /var/log/tcp-honeypot-3/ and I've fixed the logging so that it shows src-dst rather than dst-src. The latter fix Didier has already incorporated, and I expect he'll have a way of doing the former by the time he releases.

I've also created a systemd unit file (no, I don't want to get into the religious wars about how good or awful systemd is, that's what all the Linux distros are going with, so that is what I'm using to make sure the tcp-honeypot starts up with the system). Again, I've shared it with Didier, but if you want to play with it now, I've temporarily put it up on my own github (though I will probably remove it if Didier includes it with his release), you can find it here.

So, now I have both the Dshield honeypot on tcp-honeypot on the system, but the tcp-honeypot isn't actually capturing anything. The problem is, the Dshield honeypot is controlling the iptables rules. So, we'll need to modify those rules to allow traffic through to the tcp-honeypot. The reason I set the Dshield honeypot to manual updates is that any update to the Dshield honeypot, would wipe out these updates to the iptables rules. Johannes is working on an update to allow the "local" iptables rules to persist, so at some point, I'll be able to run auto update back on. He's also working on handling IPv6, too (which the current version of the honeypot disables completely on your VM). No pressure, Johannes, now that others know you are working on it there's no pressure to get it done soon. :-)

With the systemd unit file properly placed into /etc/systemd/system/, I can run 

# systemctl enable tcp-honeypot && systemctl start tcp-honeypot 

Now, let's see what all is listening on my honeypot, I'll quickly run lsof -Pni and I get the following

So, those python3 lines are the tcp-honeypot, the ones running as the cowrie user are the standard Dshield honeypot processes. I need to update the iptables rules to allow traffic through to the tcp-honeypot. I could do this in a couple of ways, but ultimately, we need to remember that the rules that the Dshield honeypot installed are located in /etc/network/iptables. So, we could modify that file, and then run iptables-restore < /etc/network/iptables. I actually chose to first run iptables-save > /etc/network/iptables, just to make sure that there was no difference between that file and what was live on the system. Then I added the 2 rules in the green box below to allow traffic through to the ports that tcp-honeypot is listening on and then ran the iptables-restore < /etc/network/iptables mentioned above. This way, I was reasonably certain I wouldn't lock myself out in the process.

And there you have it. My honeypot is now more flexible with both the standard Dshield honeypot and Didier's tcp-honeypot. Now if I see strange spikes in traffic to unknown ports, I can have tcp-honeypot listen on that port, update the appropriate rule above (for TCP or UDP) do the iptables-restore and I'll have a log where I can look at that traffic and hopefully figure out what the attackers are looking for.

I hope you found this useful, if you have questions or suggestions, feel free to comment here or e-mail me.

Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

6 comment(s)


Hi Jim,

thanks for the great article. Just a small thing to ease your pain with the config of sshd: The man page of sshd_config says about PermitRootLogin:
"If this option is set to prohibit-password (or its deprecated alias, without-password), password and keyboard-interactive authentication are disabled for root."
Thus, no need to use the confusing "without-password" anymore :)

Hey Jim,

pretty nice write up. I've started with my first honeypot project in 2014 with a hosted standard Ubuntu VM with dionea and some personal "tweeks" and "active response".

After some years the old setup was a bit of outdated and I reached out for an alternative. So I stumbled about T-Pot ( with a lot of different specialized honeypots and one generic covering a lot of ports. T-Pot was mentioned in a diary some month ago too, regarding ssh reporting with T-Pot by Tom Webb ( Until this diary I grabbed the cowrie logs, parsed it and reported it to dshield, now it does it by itself. TNX to Tom for the hint.

Now to the point of your diary "to get more data". This T-Pot instance at my place is monitored with Security Onion (because it is running anyway), saving FPC's of all honypot traffic. This could be done with a simple tcpdump service on the T-Pot standard ubuntu setup too. Then at an hourly base a script goes through the FPC of the previous period, extracts the "firewall logs" and "404 Pages" and reports this to dshield.

It's just another approach, maybe with different goals. With the FPC's, if needed, I can differentiate a bit between bot or human behaviour.

Hi Ron,

I have a similar setup - running T-Pot and reporting Cowrie/SSH logins as per Tom's article.

I'm also running Security Onion, although I'm new to it.

Are you prepared to share your script to extract the "firewall logs" and "404 Pages" on SO to report it to DShield?


Hi Willie,

sure, just give me a bit of time to redact personal information. The script in fact does a bit more than only extract these logs.

stay tuned,
Hi Willie,

sorry for the delay, just had a little dispute with my webserver. One can find the "firewall" extraction script here:

It was a quick'n'dirty hack some time ago, but it does the job. So you may have to scroll down a bit to insert your IDs and keys. It depends on some wireshark/tshark tools, so that's required. As you can see, it may do a bit more analytics, including logging to a DB. For the firewall reports it is called via cron by " hourdummy -h".

Bad thing: Although I see I'm reporting to the 404 Project, I'm unfortunately unable to locate how I tricked some system a time ago, managing this :-(. If I find it out, I'll share it. Promise.

If anyone is inspired or may improve this, feel free to do so. There is no copyright, it was just a working POC.

Hi Ron,

That is awesome - thank you very much for sharing!!


Diary Archives