Updated 2021-03-01: Give the reader a heads up that restarting SSH will kick them from their current session.
Honeypots are useful tools for collecting unauthorized interactions as logs. These logs can be digested to identify new attacking techniques or observe active username/password patterns. In the context of a security team, it could provide actionable information to pre-emptively secure the studied environment.
This tutorial will discuss general SSH honeypot pre-configuration,
HoneyTrap installation, logging, and analysis. A docker continer is used to launch a low interaction SSH honeypot
HoneyTrap. Check out the HoneyTrap documentation for more information about
HoneyTrap and what
HoneyTrap can do.
The honeypot workstation for this tutorial is GCP e2-micro instance running Ubuntu 16.04 LTS.
To log unauthorized interactions with the SSH service the default port
22 will be used by the fake honeypot service. The real SSH service will need to be moved to another port. For this tutorial port
1025 is used.
First change the SSH service port number by editing
sudo vim /etc/ssh/sshd_config
Where the file reads…
# What ports, IPs, and protocols we listen for
Port 22 to
Port 1025 and uncomment
ListenAddress 0.0.0.0 and
ListenAddress :: as shown below.
Please wait to restart the SSH service else you may lock yourself out.
ufw to open up the new port for the SSH service.
$ sudo ufw allow 1025/tcp Rules updated Rules updated (v6)
Restart the ssh service with
sudo systemctl restart sshd. If you connected to this VM over SSH you’ll be kicked at this point.
Now go to the GCP console and navigate to the firewall for the managed instance. In the firewall rule table, click on the name “default-allow-ssh” > Edit. Navigate to “Protocols and Ports” and change the specified port from
22 to the desired port number, we’ll use port
1025 for this example.
Now add another rule for wild traffic on port
22. You should now be able to login from the custom port
1025 and honeypot traffic should be able to communicate out port
Return to the honeypot instance. If you are SSH-ing in from the console, use the drop-down selector and choose “Open in browser window on custom port” to login using port
Almost done with pre-configuration. Finally, install docker.
At this point you should be able to install and run any functioning docker honeypot on port
22. We are using
HoneyTrap for this tutorial because of ease of installation: you can pull the container and run it on port
22 with this command:
sudo docker run -ditp 22:8022 honeytrap/honeytrap:latest
Be sure to run the container in detached mode
-d so that after you log out of the terminal session the container continues to run.
You can confirm the docker container is running with the command
docker container ls:
$ sudo docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 713be5f8fa05 honeytrap/honeytrap:latest "/honeytrap/honeytra…" 33 seconds ago Up 32 seconds 5900/tcp, 0.0.0.0:22->8022/tcp happy_freebird
Logs can be viewed by running
sudo docker logs CONTAINER_NAME:
$ sudo docker logs angry_chatterjee 2021/03/01 18:30:18 Using config file /config/config.toml _ _ _____ 🍯 | | | | ___ _ __ ___ _ |_ _| __ __ _ _ __ | |_| |/ _ \| '_ \ / _ \ | | || || '__/ _' | '_ \ | _ | (_) | | | | __/ |_| || || | | (_| | |_) | |_| |_|\___/|_| |_|\___|\__, ||_||_| \__,_| .__/ |___/ |_| Honeytrap starting... Version: DEVELOPMENT.GOGET (DEVELOPMENT.)
Verify this honeypot is running by attempting to login from a remote client. As
HoneyTrap runs on the GCP host, custom verbose debug logs are generated and printed to
stdout. When an interaction is detected a log is created to record the behavior, otherwise periodically a heartbeat is logged to confirm to the operator the honeypot is alive and listening.
We can see an example of password gueesing in the log snippet below. IP
184.108.40.206 attempts to login to
HoneyTrap over port
22 using the password
After successfully guessing or cracking the
HoneyTrap login credentials (username="
root" password “
password") the attacker will see the following fake Ubuntu prompt.
Any attempted commands appear in the logs character by character. An
exit command would appear in the logs as:
In another example, the value
ssh.exec stores the movements of an attacker from source ip
220.127.116.11 sending exec commands over ssh (without logging in). They send 9 commands before realizing they are in a honeypot, at which point they say hello before disconnecting. Below you can see a screenshot of the logs storing
ssh.exec values and then the entered commands in plaintext.
/ip cloud print ifconfig uname -a cat /proc/cpuinfo ps | grep '[Mm]iner' ls -la /dev/ttyGSM* /dev/ttyUSB-mod* /var/spool/sms/* /var/log/smsd.log /etc/smsd.conf* /usr/bin/qmuxd /var/qmux_connect_socket /etc/config/simman /dev/modem* /var/config/sms/* echo Hi | cat -n
To collect information from docker, output the logs to a text file and move the text file to another workstation for log ingestion and analysis.
sudo docker logs CONTAINER_NAME > OUTPUTFILE.txt
I made a script to parse the logs for some basic information including source-ip addresses, commands, and usernames/passwords attempted. Check out the gist here.
Hosting honeypots on cloud architecture enables security researchers to quickly experiement without endangering local networks. It is not without its own considerations, the researcher should monitor and secure the research workstation and have a plan in the event of compromise. Open-source honeypots are commonly criticized for being easy to detect, evade, and come with security vulnerabilities of their own. In additon to making a plan for the honeypot lifecycle, make a plan for log collection and ingestion to automate log analysis and data visualization.
Additionally, the default username of the cloud machine will be the username of the gmail address used by GCP. A researcher using
firstnameLastname@gmail[dot]com may allow an attacker to identify the first and last name of the researcher. This can be mitigated by adding a new user to the honeypot and removing the old
firstnameLastname user. Usernames associated with social media account present similar concerns. Note also at the time of compute instance creation, the hostname set in the networking section defaults to
HOSTNAME.REGION.PROJECT_NAME.internal where PROJECT_NAME and hosting region are exposed.