CloudLab Guide

The repo with the Terraform code can be found on my GitHub repo

Why have a lab?

A lab can help with testing, developing, and trying new technologies. You can use the cloud to host your lab. Resources can be temporary, keep what goes right and delete what doesn’t work or need.

The cloud as a lab?

There are several issues you may face with using the cloud as a lab: it is easy to forget what you deployed, and the resources can sit idle after practicing and learning, which can cost money. Manually deploying the lab each time can take time and effort. A solution to this is using infrastructure as code (IaC). IaC automates deploying and destroying the lab, saving you time and money from idling resources.

Each cloud vendor has their cloud-native solutions, Cloudformation (AWS), Azure Resource Manager (Azure), and Cloud Deployment Manager (GCP). I’ll use a cloud agonistic IaC tool called Terraform to deploy the lab. IaC tools use JSON or YAML for declaring the code, but Terraform uses HashiCorp Language (HCL).

What is the purpose of the lab?

The lab is security-focused to practice offensive and defensive techniques on a server hosted in the cloud. You can practice both offense and defense.

What does this template do?

The template provisions infrastructure in AWS. It will provision a VPC, three subnets, an internet gateway, a route table, a security group, and three virtual machines (VMs).

Setup / Requirements

Terraform

The setup requires installing Terraform on your local machine. Installation can vary depending on your machine’s operating system; HashiCorp provides excellent documentation to install Terraform.

Credentials

AWS credentials are required so Terraform can communicate to the cloud and provision resources. AWS provides documentation to obtain these credentials from your AWS account, you can find here. The IaC reads your credentials in your root directory with the folder name “.aws” and the file name “credentials.”

Public IP

Your public IP. The script will ask for your public IP (you can find it using a search engine and typing “what is my ip”). This is for the security group rule and limits the lab VMs to only your IP. You can use 0.0.0.0/32 but note that anyone on the internet can probe your machines.

SSH Key Pair

If you want to SSH into the VMs, you will need a public and private key. You’ll want a .ssh folder in your home directory. The script will read the public key from ~/.ssh.

To create these keys, use ssh-keygen.
Generating the keys will prompt you to enter a path and name. Enter ~/.ssh/cloudlab_kp as this is the default path and key name.

A passphrase is optional since it is a lab environment; you can leave it blank and press Enter twice.

The three VMs will use the same key pair for convenience since the lab is for testing and short-lived. For production, you’ll want a key pair for each VM. You can use a different set of keys for each VM by modifying the variables.tf file and specifying the path and name of the public keys. More documentation about generating ssh keys.

Up and running commands

During the plan and apply it will ask for your public IP. Be sure to add /32 to the end of your IP.
Example:
192.168.1.1/32

terraform init - initializes the working directory to use
terraform plan - preview infrastrucuture
terraform apply - provisions the infrastructure to AWS

Resources

VMs

All three instances use the Amazon Linux 2 Amazon Machine Image (AMI). The userdata template will update and install the necessary services. You can modify the template to install additional services or only update the instance. The attacking instance will have docker with a Kali container equipped with the tools necessary to recon, attack, and exploit vulnerabilities. The server can host any service, such as web servers, CI/CD pipelines, databases, etc. This lab will provision the host with an HTTP server apache2 service and install the Wazuh agent. The defending instance will install the Wazuh server. This machine will monitor the server for attacks.

Hourly rates for the VMs (based on the on-demand pricing): EC2 instance running Amazon Linux 2 AMI - t3.small $0.021

Security groups

The security groups will have two rules: Your IP (you can find it using a search engine and typing “what is my ip”). VPC CIDR range It is best practice to add granular rules to security groups. The rules limit access to the lab to only yourself (your IP) and the VPC.

Subnets

The subnets are segmented to simulate environments. The Kali Linux instances will be in a simulated internet (we don’t want to attack machines on the internet we don’t own or have permission to test). The Demilitarized (DMZ) subnet is where machines with public access are. The web server will live here since users will use the website. The on-premises subnet is where the defender instance is.

Further configuration

The script works out of the box, and infrastructure can provisioned quickly by running it by adding your keys and public IP or worldwide access (not recommended). The default variables live in the file named “terraform.tfvars”. You can change the CIDR ranges and region by modifying the file and changing the values for the variables. The userdata can also be modified to change what the script installs. You can also delete the userdata and secure shell (SSH) into the machines to install the services you want to work with. Examples: Change the apache2 web server to the Nginx web server Change the SIEM tool from Wazuh to Splunk You can choose the VM to provision by deleting the unwanted terraform file associated with the VM.

Other ideas

Instead of being your own attacker, how about configuring open access to the webserver? How about learning from live attacks? Install a honeypot on your public VM /web server. The IP ranges for cloud vendors are very well known. At all hours, adversaries scan these ranges for misconfigured cloud services. The IaC sets the base for networking and VMs. The instance will have the Wazuh SIEM tool with the web server having the agent installed for monitoring. The other steps left are installing a honeypot on the web server, this public repository has a list of honeypots, and setting the security group for world access. Scanning and brute force attacks will populate within an hour or even minutes on the Wazuh dashboard. So watch closely!