Playing with honeypots: part 2

Following on from part one, where I explained what a honeypot is, I'll discuss how I built my honeypot and some considerations to take.  If you've not read part one, and you're not familiar with the concept of honeypots, I recommend you read that post first.

Precautions

Clearly you don't want the honeypot to be used as a jump point for an attack against your real network.  For low interaction honeypots this risk is reduced, as an attacker can't do anything with them.  In medium or high interaction cases there's more software available to an attacker, so onward bound traffic should be controlled or the results simulated.  Clearly a pure honeypot (a real system used as a honeypot) is the biggest risk to the rest of the environment.

In my case my honeypot is running in its own Azure environment - there's literally nothing else there.  If I had other resources in Azure I could easily have isolated this honeypot in its own subnet and used network security groups to absolutely ensure it couldn't communicate with my other assets.  Fortunately that's not a concern for me.  I do discuss what my honeypot can do to other people further down this post though.

Given honeypots can be used on a production network, the place your organisation works, it's important to take adequate precautions.  What you do is up to you, and will depend on your risk appetite and use case.  As a disclaimer: only set up a honeypot if you're confident you understand the risks, can mitigate them, and are authorised to do so.

Virtual machine setup

Firstly I built a virtual machine (VM) in Microsoft Azure running Ubuntu Linux.  Ubuntu is easy to use and I knew it contained all of the applications I'd need to run the honeypot, meaning I could save time on implementation (this is a hobby project - I didn't want to be spending days on it).  A public IP was assigned to the honeypot to allow people on the Internet to connect to the honeypot.

Building the actual VM was quite a simple process, something I was really pleased with when it came to Azure.  My honeypot didn't need much in terms of resources so I picked a VM with only 1 GB RAM.  This honeypot is a command line only environment so there's no graphical environment requiring additional resources.

Once the VM had been provisioned (i.e. created automatically, without the need for me to go through Ubuntu's installation process) I needed to create a rule inside the network security group (NSG) attached to the VM.  Network Security Groups act like stateful firewalls, allowing me to control inbound and outbound traffic by use of basic packet filtering rules.  If an incoming network packet matches a rule the corresponding action is applied.  Not familiar with firewalls?  Have a read of my what is a firewall? blog post.

I'm going to be running an SSH (Secure SHell) server to manage the honeypot, and the honeypot itself will look like an SSH server, so I needed two rules to allow the Internet traffic inbound:

The rules above allow inbound connections on two ports.  SSH uses a default port of TCP 22, so that will be assigned to my honeypot software to make it easier for potential attackers to find the honeypot.  I'll manage the honeypot software via a separate SSH server running on TCP port 2222, although access to port 2222 is locked down to my office.

Software

I chose to use Cowrie as my honeypot software - a medium to high interaction honeypot that can simulate telnet and SSH (remote command line) servers.  Cowrie is easy to set up on a Linux VM, and their documentation gives you seven steps to get a basic environment operational.  I chose to only listen on port 22 and to simulate an SSH environment that's commonly used to manage Linux servers and network equipment.  To make Cowrie listen on port 22, which is normally reserved for system services, I configured authbind - there was no point for this research having my honeypot on a non-standard port as I wanted attackers to find the honeypot.  That did mean swapping my VM's real SSH server, that I'm using to manage the honeypot, over onto a different port - 2222.

Embarrassingly, I did forget I'd moved my real SSH server on to port 2222 so at one point I was trying to login to manage the honeypot and got thoroughly confused.  I couldn't login so started to worry my honeypot had actually been hacked - I remembered just before panic set in!

Won't this look like any other Cowrie instance?

I'm not spending any time customising this Cowrie instance so, yes, it'll look like any other Cowrie instance out there.  There are configuration options that allow you to change the allowed usernames and alter the files the attacker can see.  I don't mind if an attacker works out this is a honeypot because I'm not writing an academic paper or basing a PhD on this.

Exploring my honeypot

In the interests of knowing what an attacker would encounter I had a look around my honeypot, testing various things.  First, I'll connect to the honeypot using SSH and see what I get.  I'm going to login as the root (admin) user with any password:

jonathan@laptop:~$ ssh [email protected]
The authenticity of host '20.39.x.y (20.39.x.y)' can't be established.
RSA key fingerprint is SHA256:729jUDTM6n3strsNGK/cvkwhysE5qCJz5BvOaB8O6jw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '20.39.x.y' (RSA) to the list of known hosts.
[email protected]'s password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

root@file-01:~#

So far this looks like a normal Debian instance called file-01.  Eagle eyed readers will recall my honeypot VM is running Ubuntu and you're quite correct, it is.  Cowrie is pretending to be running Debian and we can see just how old it claims to be by using uname -ar.

root@file-01:~# uname -ar
Linux file-01 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux

Output from uname shows we're running version 3.2.0 of the Linux kernel - very old (as I write this, the latest version of the Linux kernel is 5.13.10).

Looking around a bit more I can see a number of files in /etc, including /etc/debian_version.  Sadly trying to read the contents of that file with cat resulted in "no such file or directory".  I can, however, see there's an empty home directory for a user called phil and can even dump the user database using cat /etc/shadow, which I've excerpted below.

root:$6$4aOmWdpJ$/kyPOik9rR0kSLyABIYNXgg/UqlWX3c1eIaovOLWphShTGXmuUAMq6iu9DrcQqlVUw3Pirizns4u27w3Ugvb6.:15800:0:99999:7:::
daemon:*:15800:0:99999:7:::
irc:*:15800:0:99999:7:::
sshd:*:15800:0:99999:7:::
phil:$6$ErqInBoz$FibX212AFnHMvyZdWW87bq5Cm3214CoffqFuUyzz.ZKmZ725zKqSPRRlQ1fGGP02V/WawQWQrDda6YiKERNR61:15800:0:99999:7:::

I can even login to the honeypot as phil using any password.

Next I wanted to check if my honeypot could be used to attack another system.  A basic check with ping while monitoring network traffic coming from the Ubuntu environment showed there was no ping traffic leaving the honeypot, even though the command was getting replies, as we can see below.

Pinging from the honeypot:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8 (8.8.8.8): icmp_seq=1 ttl=50 time=48.9 ms
64 bytes from 8.8.8.8 (8.8.8.8): icmp_seq=2 ttl=50 time=41.6 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 48.264/50.352/52.441/2.100 ms

Checking traffic leaving the honeypot, from the Ubuntu instance:

toffeeuser@UBU-HNY-01:/home/cowrie/cowrie/var/log/cowrie$ sudo tcpdump -i eth0 host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Attempting to connect out with nc, for example to an external mail server, just returned me to a prompt - seems that's not permitted.  I could connect out with wget (for example wget blog.jonsdocs.org.uk) so potentially the honeypot could have been used to attack someone else that way.

I tried to issue the shutdown command too, but that told me to read the manual.  Issuing the reboot command disconnected me.

Waiting for the attackers

It's time for my honeypot to lie in wait for some attackers.  It's published to the public Internet and I can already see there's inbound traffic hitting the honeypot.  I'll look at the traffic in part three and I hope you'll join me.

Banner image: MIELE by dordy on OpenClipart.org (modified) with an added Azure virtual machine logo.