Running simple SSH honeypot with Docker

Setting up a honeypot is a very interesting technique to detect and diagnose system vulnerabilities, attack vectors and other things related to computer security. There are many different types of honeypots used in the wild, but the most simple ones are designed to run on systems with intentionally (or not) weakeaned security settings. With a few monitoring tools in place it gives you a good chance of catching bad guys, or most likely automated scripts, red handed.

In the world-wild-web the most common attack vector is targeted for SSH services. Pretty much every server that's not configured to run on private network will have either a standard or tweaked SSH port exposed to public. Accompanied with insecure (short, simple, default) passwords it makes the perfect target for all those bot nets and what not. And what could be possibly worse than a server with a bad root password?

What does it have to do with Docker? Well, one thing that Docker is good at is process and filesystem isolation, which ultimately gives us ability to run more stuff on the same box instead of having to deal with resource hogs like real VMs (VMWare, VBox). One day I was curios what would happen if I just leave a box with a dump root password exposed to internets. More specifically - how long will it take to get infected.

First thing, we'll need a Docker image that has vanilla Ubuntu 14.04 with OpenSSH server running on standard port 22. I made one for example:

FROM ubuntu:14.04

RUN apt-get update && \
    apt-get upgrade -y \
    apt-get install -y openssh-server && \
    mkdir /var/run/sshd

RUN echo root:root | chpasswd
CMD ["/usr/sbin/sshd", "-D"]

Then we just need to build the docker image:

$ docker build -t honeypot .

In order to make docker-based honeypot more effective, we'd need to change SSH server setting on the host system so that honeypot could run on port 22. You can do that by editing /etc/ssh/sshd_server file and change the default port to something like 2222. Make sure to restart SSH service with /etc/init.d/ssh restart.

Now, lets get the party started:

$ docker run -d -p 22:22 honeypot

If you're using any cloud VPS like Digital Ocean there's a big chance that you dont have to wait long. After running a few experiments I found that it takes approximately 10-15 minutes before /var/log/auth.log starts filling up with failed ssh login attempts. Then some "miracle" happens and one of the bruteforcing bots gets in and starts installing software, reconfiguring services, etc and ultimately tries to restart SSH service which will end up with container dying.

It's time to scout. By default Docker uses AUFS filesystem driver and provides ability to see any filesystem changes between container's initial image and it's current state. Simply run diff command:

$ docker diff my-container-id
# C /etc
# C /etc/shadow
# C /etc/ssh
# D /etc/ssh/ssh_config
# A /lib/cpp
# C /root

Where A - additions, D - deletions and C - changes. This is pretty cool because now you dont even have to guess which files were changed in the container. If your system got compromised you can track down every single file that was changed in the process. When I first ran diff command i got the following:

$ docker diff b235c4bdf4be | wc -l
# 6169

Now, how do we get to see the actual file contents? First, if the container is still up and running, you can exec into it:

$ docker exec -it my-container-id bash

In case if container is no longer running, you can copy files from it to the host filesystem using docker cp command, or by jumping directly into container's filesystem diff directory. Obtain container's full ID by running inspect command and then change dir:

$ docker inspect my-container-id
$ cd cd /var/lib/docker/aufs/diff/6c85e7d768b6f405c8cb98b71d21f115ebe317614ae9daf98e822a6978f3301e
$ ls -al
# total 52
# drwxr-xr-x 13 root root 4096 Dec 19 18:10 .
# drwxr-xr-x 31 root root 4096 Dec 19 15:01 ..
# drwxr-xr-x  2 root root 4096 Dec 19 18:10 bin
# drwxr-xr-x 13 root root 4096 Dec 19 18:10 etc
# drwxr-xr-x  3 root root 4096 Dec 19 17:54 lib
# drwx------  7 root root 4096 Dec 19 18:23 root

As an example, dig into compomised root's directory:

$ cd root
$ ls -al
total 4380
# drwxr-xr-x 2 root root    4096 Dec 19 13:28 .
# drwx------ 5 root root    4096 Dec 19 22:22 ..
# -rw-r--r-- 1 root root    2707 Dec  5 20:13 af
# -rw-r--r-- 1 root root     216 May 18  2005 auto
# -rw-r--r-- 1 root root    2205 Dec 19 12:14 get
# -rw-r--r-- 1 root root    2893 Oct 19  2011 mass
# -rw-r--r-- 1 root root   51845 Nov 13 07:33 passfile
# -rw-r--r-- 1 root root     171 Dec 19 07:02 port
# -rw-r--r-- 1 root root  888972 May  8  2015 pscan2
# -rw-r--r-- 1 root root    5843 Dec 14 05:15 pscan2.c
# -rw-r--r-- 1 root root 1246175 Dec 19 08:19 scan.log
# -rw-r--r-- 1 root root  453972 Oct 23  2010 ss

Pretty neat. Keep in mind that all above is a pretty simple (yet entertaining) setup to show you what happens when you don't protect your servers.

P.S. Some other interesting resources related to honeypotting: