Honeypots

Special Thanks: This article was made possible by support from Linux Professional Institute

For one reason or another, I stumbled across a relatively old piece of software the other day while researching some unrelated DevOps security news. Doing so reminded me that I hadn’t run a honeypot for around fifteen years, and it inspired me to see if there were any advances in honeypot functionality.

There are three key types of honeypots, which fall into categories base on interactivity:

• A “low interaction” honeypot tempts attackers to probe a system or network with, for example, visible but inaccessible admin network ports for common applications.
• A “medium interaction” honeypot might tempt an attacker with some interaction on the system itself (I'll look more at this type of honeypot in a moment).
• A “high interaction” honeypot looks like a precious system and alludes to being fully open and exploitable. Any business offering a this type of honeypot publicly will most likely treat it as a disposable resource that can be resurrected with relative ease.

Nectar

Because my professional background with Linux, I was initially drawn to Kippo, which then led me to Cowrie, a more-recently maintained fork of Kippo.

Cowrie appealed to me mainly because I wanted to use a container to capture some real attack data. I liked the idea of seeing precisely what commands an attacker might have been typing, with the aim of being able to gauge the sophistication and maturity level of an attack and whether the attack used manually input commands or automated bot behavior.

In this article, I’ll show you how to install Cowrie using Docker, attack it non-invasively, and then analyze the results. Cowrie describes itself on Docker Hub as “a medium interaction SSH and Telnet honeypot designed to log brute force attacks and the shell interaction performed by the attacker.” Intrigued? Let’s crack on. But a serious word of warning before you get started, see the “Danger, High Voltage!” box.

Stack ‘Em Up

For speed, reproducibility, and a DevOps approach, I wanted to fire up Terraform on AWS to create a locked-down EC2 instance and then use Docker running Cowrie for testing. I started with this Docker Hub page, which provided a Dockerfile to view and then use to build a container.

To get Docker installed on my shiny Ubuntu 18.04 instance that Terraform built, I used the Docker Community Edition (CE) install instructions. If you don’t have Docker installed, then skip to the “Install from a repository” section in the instructions and continue from there. However, for testing, the route that I prefer is installing from Docker in its newer containerd incarnation as a compressed package, so I found the packages URL for my Ubuntu version (Bionic Beaver) and then ran the command as shown in Listing 1 to install the latest package I could find. I’m using m1.large for the instance size if it helps (which uses the amd64 architecture).

Listing 1: Installing Docker CE

$ wget https://download.docker.com/linux/ubuntu/dists/bionic/pool/stable/
  amd64/containerd.io_1.2.2-1_amd64.deb
$ dpkg -i containerd.io_1.2.2-1_amd64.deb

$ wget https://download.docker.com/linux/ubuntu/dists/bionic/pool/stable/
  amd64/docker-ce-cli_18.09.1~3-0~ubuntu-bionic_amd64.deb
$ dpkg -i docker-ce-cli_18.09.1~3-0~ubuntu-bionic_amd64.deb

$ apt install -f # meet unmet package dependencies

$ wget https://download.docker.com/linux/ubuntu/dists/bionic/pool/stable/
  amd64/docker-ce_18.09.1~3-0~ubuntu-bionic_amd64.deb
$ dpkg -i docker-ce_18.09.1~3-0~ubuntu-bionic_amd64.deb

As shown in Listing 1, there’s some tidying up of unmet dependencies midway through the installation.

Innards

Now that I’ve got a container run time working on a non-public host, I can build my Cowrie container.

Cowrie's author is Michel Oosterhof, who originally forked Kippo from what I can determine. Having looked through the Dockerfile a bit more closely, I can see that there are two ports exposed on the last line, which provide SSH and Telnet servers, as shown in Listing 2.

Listing 2: The Bottom of the Dockerfile

USER ${COWRIE_USER}
WORKDIR ${COWRIE_HOME}/cowrie-git
VOLUME [ "/cowrie/cowrie-git/var", "/cowrie/cowrie-git/etc" ]
ENTRYPOINT [ "cowrie" ]
CMD [ "start", "-n" ]
EXPOSE 2222 2223

Keep in mind the following about the Dockerfile: Two images are created, with one trimmed down for running (see the comments at the top of the Dockerfile); I'm using a Debian OS as my base for the images; the images will be built fresh from the latest GitHub source; and there’s a few fairly sizable chunks of Python involved.

Build It and They Will Come

To get started, I copy the Dockerfile to my server’s filesystem and then run the following command, which kicks off the image-building process beautifully if all goes well:

$ docker build -t cowrie

As you can see, the images built from that command begin with cowrie. Size-wise, the images come in at 553MB and 386MB for the run-time image. As promised in the Dockerfile comments, there’s a difference in image size between the unnamed <none> “builder” image and the “run-time” images, which is good news. Figure 1 shows what denotes success once your terminal has stopped scrolling with build information.

Figure 1: The docker ps command shows which container images are on the system.

Figure 1's output looks promising; next I will try to fire up Cowrie.