Small-scale honeynet with Raspberry Pi

This post appeared originally in our sysadvent series and has been moved here following the discontinuation of the sysadvent microsite

The Raspberry Pi units are small and don’t use much power. If you have one or two to spare, why not use them to explore the sweet smell of honeypots?

Ye who enter here

First of all, a warning: Even though honeypot software is usually isolated from the underlying operating system, bugs do exist and accidents can happen. You should not run any other services on a system hosting honeypot software.

I would not recommend running an unattended honeypot in a shared network environment. Even low-end routers now have some kind of DMZ option that might be used for such activities, but the better option is using a dedicated IP network with strict firewall control and bandwidth limiting.

A honeypot and its environment should always be considered compromised. Files and scripts downloaded to the honeypot are potentially dangerous and should not be run elsewhere. And if you get tired of watching kiddies try to hack your system, wipe it thoroughly and do a full reinstall before using it for something else.

The setup

One of my honeypot labs consists of two Raspberry Pi units. One handles SSH and Telnet connections, while the other handles HTTP, SMTP, POP3, and IRC. As explained below, they can also communicate between themselves when necessary.

In this lab, both Raspberry Pi nodes also run their own caching DNS server and NTP server. Both are monitored by an IDS - which is kept rather busy - and all inbound and outbound network traffic is saved (full packet capture) if further analysis should be required.

Cowrie

The SSH/telnet honeypot runs Cowrie, a very nice honeypot software based on Kippo. Cowrie imitates SSH and telnet servers and will accept login attempts based on a configurable user/password list. After a successful login, the intruder will find himself in a fully virtualized file system with most commands and binaries available. Every action is logged, and if an intruder downloads root kits or other tools for further exploits, a copy of every downloaded file is stored outside the virtualized environment for analysis.

Cowrie can be configured for logging directly to certain databases, Splunk, Elasticsearch, as well as regular log files in plain text and JSON. There’s also an option for submitting downloaded files to VirusTotal for analysis.

InetSim

The other honeypot node runs InetSim, a piece of honeypot software that simulates multiple services, both plain text and encrypted (SSL/TLS). Almost every server parameter announced to intruders or other nosy visitors can be configured. Not that any script kiddies of today would react to an IIS server running on an AIX/370 mainframe anyways.

When queried for HTTP requests, InetSim will happily serve whatever content you have preconfigured based on MIME type, or the defaults if you haven’t. HTTP submissions using POST will be stored in individual files. For instance, with the recent Mirai botnet, analyzing the postdata files has been useful for identifying the continuously changing servers the exploit downloads stage 2 malware from.

InetSim’s SMTP process can be configured as an authenticated mail relay. It will accept and log submitted email, but will obviously never send it. In addition to gathering credentials the intruders will use for gaining access, InetSim will store the content of every mail submitted to this fake mail server for delivery. Since the mail submitted through this honeypot is close to 100% spam, except for a sporadic mail for reporting the finding of an exploitable relay, a separate scheduled task will automatically feed this mail to Pyzor for improving its spam database. Currently this honeypot submits between 5 000 and 20 000 mail messages per day for training.

Working together

Since quite a lot of those gaining SSH access to the Cowrie honeypot try to use it as a bouncer for sending spam or submitting link spam or forum spam, Cowrie very conveniently provides redirection for outbound requests. Outbound connections are by default not allowed and will (to the attacker) look like they time out, but redirecting will allow the specified ports to reach a configured target. For every fake service running on the InetSim honeypot, outbound connections from Cowrie will end up there instead. This way, both spammers using SMTP directly and using SMTP over SSH tunnels will reach the InetSim honeypot. In Cowrie, redirection is configured like this (in this case for port 25):

forward_redirect_25 = inetsim-honeypot:25

The fun parts

Running a honeypot provides insight and knowledge about current attacks, botnets, rootkits, trojans and other tools. With properly configured logging they provide a continuous stream of useful information, like which username/password combinations are attempted more often, which URLs or IP addresses they download rootkits from, and by using GeoIP information a map will easily expose where your intruders are coming from.

Cowrie also provides a tool for replaying a logged-in session, showing exactly what happened during the intrusion. With botnets and scripts these will usually be quite predictable, but now and again a real human makes an attempt…