Cloud honeypot deployment: Complete guide for AWS, Azure and GCP

A cloud honeypot is a decoy system designed to attract attackers, allowing your cybersecurity team to detect and analyze their methods. While the purpose of honeypots in cloud security is similar to their use in traditional networking, there are several considerations to keep top of mind when deploying and managing them in a cloud context. 

Here, we explore the implementation of honeypots in cloud environments, including tools that facilitate this process, and discuss the associated costs of using honeypots to protect cloud-based systems. 

Editor’s note: AWS has made cloud deployment accessible to even very small organizations with limited budgets. We have a FREE workshop to help you get started with AWS. Watch it for free here: Live AWS workshop: Build and deploy your first cloud infrastructure. 

View Free Course

How to implement a honeypot for cloud infrastructure 

While AWS honeypot setup and Azure honeypot deployment are unique, they, like other cloud honeypot deployments, have several steps in common. Understanding these points of commonality makes it easier to both deploy honeypots and see how they fit into your overall Azure, GCP or AWS security testing. 

Here’s what’s involved in deploying honeypots in public cloud environments:

Account setup and preparation 

The first step, regardless of the platform you’re using, is to establish an account and prepare for the deployment. This involves dedicating either a project within an account or an entire account to creating your honeypot. The goal is to ensure the honeypot is completely isolated from the production systems your organization needs. 

Applying strict identity and access management (IAM) permissions is crucial to the preparation process, as unauthorized access to your honeypot environment could provide an attacker with valuable insights into your cyber defense mechanisms. 

Restrictive IAM permissions can also limit the blast radius if your honeypot gets compromised. For example, using role-based access control (RBAC), you can restrict permissions to team members with limited access to other sensitive systems. If the honeypot gets compromised, the attacker’s lateral movement would be contained. 

Network design 

You’ll want to set up a public network, such as a VPC in AWS and GCP or a VNet in Azure. In this way, you expose your honeypot to a broad swath of the cybercriminal ecosystem. 

To ensure a deep, diverse range of data, it’s also important to configure your firewall rules or security groups to allow sufficient inbound traffic. You should focus on the ports you want to monitor. For instance, suppose you want to observe both brute force and credential stuffing attacks. In that case, you could use a security group to expose SSH (Secure Shell) via port 22. This could attract a mix of automated and manual attacks, yielding plenty of useful data. 

It’s also important to keep in mind that with the typical cloud honeypot design, you wouldn’t want to enable outgoing traffic. If you were to allow outbound traffic, you could use your honeypot to attack another system. For instance, using the right malware, an attacker could turn your honeypot into a command-and-control node and use it to launch assaults on other environments. Blocking all outbound traffic helps prevent this.

Virtual machine deployment 

Since your honeypot is only being used for cloud intrusion detection, you should deploy a small, inexpensive virtual machine (VM) instance. If you’re using AWS, you could choose an EC2 T3 instance, or if you’re using Azure, you could opt for a Bv1 VM. Within GCP, an e2-micro instance may make the most sense. 

Given that you’re only using the honeypot for threat intelligence collection, one of the above options should more than suffice. 

The next step is to harden the base operating system (OS). This involves installing the latest version, applying any necessary system updates, and removing any unnecessary services. 

As mentioned earlier, hardening also involves giving your honeypot its own subnet or virtual private cloud (VPC), which provides you with a private, controlled environment for your cloud-native security monitoring.

Honeypot installation 

Installing a cloud honeypot starts with choosing the software you want to use, such as Cowrie, T-Pot and Honeyd. All three of these solutions can run in AWS, GCP and Azure environments. 

You should then choose the port to bind the honeypot to, keeping in mind the kinds of attacks you want to study. For example, some organizations may bind a honeypot to 445 TCP if they’re trying to observe ransomware or worm exploits. Since this port is commonly used for sharing files within a network, ransomware and other malware attackers like to use it to deliver their malicious payloads.

Logging and monitoring 

Logging and monitoring are foundational for deception technology cloud deployments because they give you actionable insights you can use to prevent attacks. If you’re building in Azure, you may opt to use Log Analytics Agent, or Ops Agent if you’re working in GCP. For AWS, CloudWatch Agent is a good option for monitoring your honeypot environment. In reality, a number of cloud security monitoring tools can work, including whatever you’re using to monitor your current cloud ecosystem. 

Your monitoring solution reveals a wealth of useful information about the tactics attackers use as they try to breach your defenses. For instance, using a CloudWatch dashboard, you can observe how an attack impacts your system’s use of resources. You also get a log of all activity. Combining these two features, your security team can identify exactly when an attack occurred and see which resource usages spiked during that time. 

With that data in hand, you can establish an alert system based on the corresponding resource usage spikes. 

Another way to get the most out of your logging and monitoring solution is to perform a cloud attack simulation and see how its effects manifest in your system. A data exfiltration attack will produce metrics with one set of characteristics, while a DDoS attack would result in very different, yet equally helpful, stats. 

Where to position cloud-based honeypot tools 

When positioning cloud-based honeypot tools, you should:

1. Bind your honeypot with select ports open to the internet. 
2. Give it its own VPC on a unique subnet.
3. Dedicate an additional VPC and subnet to monitor the honeypot.

Popular tools for cloud honeypot deployment 

Three common tools for deploying honeypots include Cowrie, T-Pot and Honeyd. Here are some of their standout capabilities: 

• Cowrie has a low price point, making it a solid entry-level option for smaller organizations. It’s also good for deploying a number of decoys on VMs and containers. IT has a relatively small resource footprint as well, which reduces its ongoing costs. 

• T-Pot is on the other end of the spectrum when it comes to resource appetite, but it’s good for detecting broad attacks across a complex environment. It also has a higher price tag and more complicated implementation than Cowrie. 

• Honeyd is useful for teams that want to emulate many virtual hosts simultaneously. If you use it for only a few emulations, it may not consume as many resources as T-Pot, but the more complex you make your emulation environment, the more resource-intensive T-Pot becomes. 

The costs of cloud threat detection with honeypots 

Deploying honeypots in the cloud can be relatively inexpensive, but the total cost will depend on the resources you need. Typically, in a cloud environment, you’d have to pay for: 

• The VM used to run the honeypot environment 

• Logging costs, which depend on the amount of traffic you’ll be monitoring 

• Storage costs, which are incurred because your honeypot’s logs get forwarded to a storage service, such as CloudWatch 

For a small VM, such as T3.micro, you may only have to pay around $10.00 USD per month. Your logging expenses may be as little as $3.00, and storage may run you around $0.25, giving you a total of $13.25 per month. 

These numbers are very rough approximations and assume relatively low compute loads. To get a more accurate estimation, you’d have to reach out to your cloud provider. 

Deploying a honeypot using infrastructure as code 

Infrastructure as code is a method of building infrastructure using lines of code as opposed to a graphical user interface (GUI). With infrastructure as code, you determine what you need and how it interacts with dependencies and other virtual components with your code, as opposed to choosing components represented by icons on a screen. 

One of the more common infrastructure-as-code solutions is Terraform. Here’s an example of a template you can use to deploy a Cowrie honeypot on AWS using Terraform. It’s important to keep in mind that to make the template work in your environment, you’d have to: 

• Adjust the Amazon Machine Image (AMI) to match the one you need. What’s in the code is just a placeholder. 

• Change the instance_type from the placeholder value of t3.micro to the type of instance you need 

• Adjust the region from us-east-1 to the region that best fits your needs 

• Check the IP ranges of your current VPC and subnet to make sure they don’t overlap with what’s in the code 

provider "aws" { 

region = "us-east-1" 

} 

 

resource "awsvpc" "honeypotvpc" { 

cidr_block = "10.0.0.0/16" 

} 

 

resource "awssubnet" "honeypotsubnet" { 

vpcid = awsvpc.honeypot_vpc.id 

cidr_block = "10.0.1.0/24" 

mappubliciponlaunch = true 

} 

 

resource "awssecuritygroup" "honeypot_sg" { 

name = "honeypot_sg" 

description = "Allow inbound SSH/Telnet for honeypot" 

vpcid = awsvpc.honeypot_vpc.id 

 

ingress { 

from_port = 22 

to_port = 22 

protocol = "tcp" 

cidr_blocks = ["0.0.0.0/0"]  

} 

 

ingress { 

from_port = 23 

to_port = 23 

protocol = "tcp" 

cidr_blocks = ["0.0.0.0/0"]  

} 

 

egress { 

from_port = 0 

to_port = 0 

protocol = "-1" 

cidr_blocks = ["0.0.0.0/0"]  

} 

} 

 

resource "awsinstance" "cowriehoneypot" { 

ami = "ami-0c94855ba95c71c99" # Example Amazon Linux 2 

instance_type = "t3.micro" 

subnetid = awssubnet.honeypot_subnet.id 

securitygroups = [awssecuritygroup.honeypotsg.name] 

 

user_data = <<-EOF 

#!/bin/bash 

sudo yum update -y sudo amazon-linux-extras install python3 -y git clone https://github.com/cowrie/cowrie.git /opt/cowrie cd /opt/cowrie pip3 install -r requirements.txt ./start.sh EOF  

 

tags = { 

Name = "Cowrie-Honeypot" 

} 

} 

 

# CloudWatch log group for honeypot  

resource "awscloudwatchloggroup" "honeypotlogs" { 

name = "/honeypot/cowrie" 

retentionindays = 30 

} 

Use honeypots to secure your cloud environments 

Honeypots can be a powerful addition to your arsenal of options when battling cloud computing attacks because they let you analyze actual attack methods. Since there are multiple tools compatible with the most popular public clouds, as well as pre-built monitoring solutions, the path to creating effective honeypots may be more straightforward than you think.  

For more on cloud security, check out other cloud trainings and resources from Infosec Institute.