Watching the Bad Guys with Cowrie

Portholes

I can launch my shiny cowrie container with the following command, which exposes TCP port 2222 for my (non-public) SSH server, to query it locally:

$ docker run -d --restart=always -p 2222:2222 cowrie
c52f9570af958069dba5ff5b13cf29751e7f71a689413a972b7a460b7a2f4516

The command above (with the -d switch) will keep the container running even if you log out.

I can then access the running container with the following command, which will offer a Bash prompt (abbreviate the hash if you like, which is c52f9570af95 in my case or any unique first few containers relative to other containers on the system):

$ docker exec -it c52f9570af95 bash

You can then log into and rummage around the container's filesystem. Note that you’ll connect as the cowrie user and not the superuser, root.

The next thing to do is ascertain the cowrie container’s IP Address with the output shown near the end having run the following command:

$ docker inspect c52f9570af95

As suspected (the first container often adopts this address by default), I can see this IP address (172.17.0.2) for my container as shown in Listing 3.

Listing 3: Honeypot IP Address

"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:ac:11:00:02",
"DriverOpts": null

Onwards now to see what’s being presented in terms of attack surface by Cowrie.

I’ll install the mighty nmap for a quick port scan (on my localhost) as follows:

$ apt install -y nmap

Next, I’ll run the port scan with this command:

$ nmap 172.17.0.2

In Figure 2, I can confirm firstly that I am connecting to the correct IP address for the container and secondly that I am only exposing TCP port 2222 from the container.

Figure 2: I've found the correct container with an open port, which is good news, using the venerable nmap.

Rummaging Deeper

Now I need to try and get into the SSH daemon that is listening inside my container following the same approach (brute forcing passwords) that an attacker would if the container was publicly accessible.

Running local commands is easy as pie with the following command:

$ ssh root@172.17.0.2 -p2222

Figure 3 shows what to expect if I use root as the username and 123456 as the password. Success!

The default root user password, which I’ve just mentioned, would take a bot or attacker a few attempts to guess, but not long at all (root:root or admin:admin being more common probably).

If you edit the file cowrie.cfg inside the container, then you can affect a few config-related things, such as enabling the Telnet server, which can be found inside the etc volume in Docker. Switching on Telnet, for example, looks like this:

[telnet]
enabled = yes

Now that I’ve got access to our honeypot SSH server, I'll analyze the logs that an attacker might leave behind.

Figure 3: Success! I’ve just got root inside our container (because I knew the simple password).

Having run a few arbitrary commands inside the container, I then log back into the container through Docker. Cowrie provides the magical command, playlog, to look through what commands an attacker has run. You’ll find that running it offers an animated display of what was typed. I can choose between SSH sessions and view the animation as follows:

$ playlog /cowrie/cowrie-git/var/lib/cowrie/tty/f43b369f158dc632e06

When I was rummaging in the container over SSH, I typed the command hello, which I knew would fail as a marker. Next, having run playlog pointed at the path for the SSH session above, it’s clearly the correct SSH session that I’m watching as I’m greeted with a hello again.

Whaddaya Hear, Whaddaya Say?

You might be pleasantly surprised to hear that you can generate some pretty amazing graphs from your honeypot’s logs with Kippo-Graph. According to an online article, “The switch went real smooth as Cowrie is basically a drop in replacement for Kippo and scripts like Kippo-Graph work with it.” Cowrie will run with Kippo-Graph thanks for its Kippo provenance, so it’s worth having a look at the GitHub page. Figure 4 and Figure 5 show some examples from a website that focuses on Kippo-Graph.

Figure 4: A useful graph detailing access attempts (http://www.spamversand.de/kippo/kippo-graph.php).
Figure 5: This pie chart apparently details the top 10 unique IPs and their associated country codes which is then sorted by overall connections (http://www.spamversand.de/kippo/kippo-graph.php).

As the sophisticated graphing software shows, there’s much more to Kippo and Cowrie than simply replaying commands when it comes to analysis of attacker trends.

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Honeypots for the Pi

    Adding a honeypot to your network will slow down attackers and warn you that intruders are on the wire.

  • Honeynet

    Security-conscious admins can use a honeynet to monitor, log, and analyze intrusion techniques.

  • Docker with OwnCloud

    Run your application smoothly and portably in the cloud with the Docker container system. This workshop takes a practical look deploying Docker with the OwnCloud cloud environment.

  • Docker

    Docker is an economical alternative to conventional virtualization. Because each Docker container shares the underlying operating system, it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient.

  • Container Security

    A recent flurry of activity in the container space raises several interesting questions about security among a number of operational aspects in the enterprise environment.

comments powered by Disqus

Direct Download

Read full article as PDF:

News