SSH Honeypots Infrastructure Automation

4-minute read
blog • cloud • honeypot
cowrie • python • cdk

Honeypot primer

A honeypot is decoy IT infrastructure that is connected to the internet or to your internal network to observe malicious behaviour. You can learn attack patterns, the origin of connections and gather Threat Intelligence from the collected data. Honeypots come in many shapes and forms. Some are open source, others are commercial. Data you can collect with honeypots:

  • IP addresses
  • Commands executed
  • Files uploaded
  • vulnerabilities used
  • And much more…

Popular open source honeypots are:

  • Cowrie - An SSH and Telnet honeypot
  • Conpot - An ICS specialised honeypot
  • Dionaea - Focused on capturing malware and vulnerabilities

In this blog post we will use Cowrie to capture SSH attacks. Because of the popularity and open source code, it’s wise to add some dummy data and modify some of the default configurations. Scanbots and smart adversaries apply fingerprinting techniques to check if the system they broke into is indeed an honeypot and won’t upload their tools or execute next steps. Modifying the honeypots is outside the scope of this blog, the focus is on the infrastructure deployment.

If you would like to run a different honeypot, you will need to modify the cdk_cowrie_honeypots_stack.py to use a different Docker image and modify the Security Group with the port the honeypot listens on.

Automating infrastructure

Running honeypots is a lot of fun! Setting up the infrastructure? Not so much. Often you face issues with incompatible libraries, downtime because of updates breaking something or outdated hardware. And it’s all manual effort…

I faced these challenges when running three Cowrie SSH honeypots back in 2017. When finally set up, the data collected was super insightful. An overview of what you can do with the data is in the blog post I wrote for the Honeynet project. After a few months however, the infrastructure had to go down because of cuts in sponsorships and because maintainance of the systems became too much work.

A friend recently asked if the honeypots were still running and was disappointed to hear they were taken down. When he asked if setting something up again was easy, I initially thought: No, too much effort. But then I figured: this is a perfect use case for Cloud infrastructure automation and specifically, Cloud Development Kit (CDK). With CDK, you can write complete infrastructures with just a few lines of code, including AWS Elastic Container Service (ECS) clusters. AWS ECS allows you to run Docker or Kubernetes clusters. ECS includes the serverless feature Fargate that deploys your Docker containers on AWS managed systems.

In the CDK for Cowrie honeypots GitHub repository you will find everything you need to deploy the infrastructure. You can configure how many honeypots you want deploy on line 43 of file cdk_cowrie_honeypots_stack.py.

desired_count=1,

To get CDK installed, follow the Getting Started documentation on AWS. Then clone the repository and enable the Python virtual environment

python3 -m venv .env
source .env/bin/activate
pip install -r requirements.txt

And deploy the stack

cdk deploy

Infrastructure overview

Infrastructure we will deploy to run Cowrie honeypot:

  • VPC for the network components
  • EC2 security group that allows port 22
  • ECS cluster to configure Fargate
  • Task definition for Fargate (describes how the container should be deployed)
  • Container definition for Fargate (describes what container should be deployed)

CDK Cowrie infrastructure

Side note: The code for this infrastructure is 45 lines

Docker image

The docker image from Cowrie is used as the base for my new image. The new image will install authbind which allows configuring Cowrie to run on port 22 instead of port 2222. If you want to modify the configuration, I suggest building a Dockerfile that downloads a Cowrie configuration file from a location of your choice.

What can we see

Docker containers that run in AWS Fargate send STDOUT messages to CloudWatch logs. Here we can see what commands are executed within the honeypot and start extracting Threat Intelligence for further research and enrichment.

In the image below you can see that the command echo, ifconfig and wget were used during one of the sessions someone logged in to the honeypot (highlighted in red).

CloudWatch logs example

For further details on what you can do with the data, please read the blog post mentioned earlier on the Honeynet website.

Destroying the infrastructure

If you want to remove the infrastructure stack (this deployment with 1 container will cost you around $10-15 per month), simply run

cdk destroy

And the infrastructure will be torn down. The data you captured will be persistent in CloudWatch and can be exported to S3 if required. Keep in mind that the default retention is set to 1 day. If you want to retain longer, modify cdk_cowrie_honeypots_stack.py on line 32

log_retention=logs.RetentionDays.ONE_DAY,

Conclusion

We discussed the concept of honeypots and the use they have for a Cyber Security program. Then we deployed our SSH honeypots with the help of the Cloud Development Kit and analysed the data. Finally we destroyed the infrastructure to reduce cost.

Happy engineering!