Reader small image

You're reading from  Building and Automating Penetration Testing Labs in the Cloud

Product typeBook
Published inOct 2023
PublisherPackt
ISBN-139781837632398
Edition1st Edition
Right arrow
Author (1)
Joshua Arvin Lat
Joshua Arvin Lat
author image
Joshua Arvin Lat

Joshua Arvin Lat is the Chief Technology Officer (CTO) of NuWorks Interactive Labs, Inc. He previously served as the CTO for three Australian-owned companies and as director of software development and engineering for multiple e-commerce start-ups in the past. Years ago, he and his team won first place in a global cybersecurity competition with their published research paper. He is also an AWS Machine Learning Hero and has shared his knowledge at several international conferences, discussing practical strategies on machine learning, engineering, security, and management.
Read more about Joshua Arvin Lat

Right arrow

Succeeding with Infrastructure as Code Tools and Strategies

In the previous chapter, we manually created our first vulnerable lab environment using the AWS Management Console. It probably took us about an hour and a half to set everything up. After completing the lab setup, it may have taken us an additional 30 minutes to test whether everything was (mis)configured as expected. What if we wanted to set up 10 lab environments similar to what we prepared in Chapter 2 for a security training course? Do we really need around 20 hours to set all of these up? In addition to this, remember that we only worked on a small component of an entire cloud penetration testing lab environment! Complete lab environments generally have about 5 to 10 times more resources compared to what we prepared in Chapter 2. Assuming the complete environment is at least five times larger than what we initially prepared, and taking into account the need to create and delete the entire environment every time to manage...

Technical requirements

Before we start, we must have the following ready:

  • Required: The “target” AWS account used in Chapter 2, which will contain the vulnerable environment and resources
  • Optional: A second AWS account (also used in Chapter 2), which will serve as the “attacker’s account”

In case you skipped Chapter 2, Preparing Our First Vulnerable Cloud Lab Environment, feel free to create the AWS accounts using the following link: https://aws.amazon.com/free/. You may proceed with the next steps once the accounts are ready.

Note

This chapter primarily focuses on using Terraform to build a sample vulnerable lab environment on AWS. Of course, we need to have our Microsoft Azure and Google Cloud Platform (GCP) accounts ready once we reach the hands-on portion of the succeeding chapters of this book (Chapter 4 onward). In the meantime, setting up two AWS accounts should do the trick for now.

The source code and other files...

Diving deeper into IaC tools and strategies

Before we dive into the practical exercises in this chapter, we will first establish a clear understanding of IaC in this section and discuss how it can be harnessed for building complex penetration testing labs.

Demystifying IaC

IaC is the practice and process of using code to provision and manage infrastructure resources. This code works similarly to how a blueprint of a house is used as a reference when building the actual house. The cool thing when dealing with IaC code is that the actual infrastructure resources are created and configured automatically from the code that represents the desired final state of the infrastructure. Behind the scenes, the IaC automation tools simply make use of the same set of APIs we would use when trying to automate specific processes. The process is illustrated in the following diagram:

Figure 3.1 – Using IaC tools and services to create and manage cloud resources...

Setting up Terraform in AWS CloudShell

In this chapter, we will focus on using Terraform to provision and manage our cloud infrastructure. Terraform is an open source IaC tool created by HashiCorp. It’s one of the most powerful and most used IaC tools at the moment. It enables users to define and provision infrastructure resources using a high-level configuration language. By utilizing a simple, declarative, and intuitive syntax, this IaC tool simplifies the process of creating, updating, and versioning infrastructure, which provides a powerful way to automate infrastructure management.

Here’s an example of how Terraform code looks:

resource "google_compute_firewall" "allow-ssh-from-my-ip" {  name    = "allow-ssh-from-my-ip"
  network = local.net_02
  allow {
    protocol = "tcp"
    ports    = ["22"]
 ...

Getting our feet wet with Terraform

In this section, we will provide a brief overview of the essential Terraform workflow and then move on to a “Hello World” example to test our setup.

Understanding the core Terraform workflow

It may take most of us around 2-4 weeks to learn a new tool, platform, or framework. However, it would probably take us just a few hours (to, at most, a few days) to learn Terraform since using it is straightforward and easy. When using Terraform, engineers generally follow a process similar to what we have in Figure 3.3:

Figure 3.3 – A common workflow when using Terraform to create and update resources

Once we have the configuration file (or files) ready, we simply run terraform init to initialize the Terraform environment. The terraform init command is usually executed when our environment has not been initialized yet or when additional files or plugins need to be downloaded. The next step involves using...

Understanding the Terraform configuration language

In this section, we will dive into the core aspects of Terraform’s configuration language and then proceed with working with relatively simple configuration code to equip us with the foundational knowledge needed to manage IaC with Terraform.

Demystifying commonly used Terraform configuration blocks

Understanding how to write and interpret Terraform configuration code is essential for effective infrastructure management. This knowledge allows us to customize and modify existing infrastructure resources created and managed using Terraform. It also enables us to troubleshoot issues more effectively and save time when resolving errors and blockers while using the IaC tool.

So, where do we start? For one thing, simple and complex Terraform configuration code generally makes use of the same set of elements and building blocks. This common foundation allows us to gradually build our understanding by starting with simple configurations...

Building our vulnerable lab environment with Terraform

The previous sections of this chapter allowed us to have a better understanding of how Terraform works. We worked with relatively simple examples, and it’s about time we worked on a relatively more complete and realistic example! That said, we will now use Terraform to automatically create and configure the vulnerable lab environment we manually prepared in Chapter 2, Preparing Our First Vulnerable Cloud Lab Environment. By utilizing Terraform, we should be able to streamline the process of setting up the vulnerable lab environment that we previously prepared manually.

Note

What happened again in Chapter 2? In Chapter 2, we manually created an empty S3 bucket through the AWS Management Console and configured it for static website hosting. We then modified the access control settings of the bucket to allow authenticated AWS users to list and retrieve objects. To complete the setup, we uploaded sample files to the S3...

Configuring a Terraform backend with state locking

In this section, we will explore how Terraform remote backends work and understand how state locking ensures the integrity and consistency of our infrastructure state when managing infrastructure deployments. Then, we will delve into the step-by-step process of configuring a remote backend to enable state locking.

Understanding Terraform remote backends

Up until this point, we have used the default local backend, which stores the state as a local file (that is, the terraform.tfstate file). This type of setup should be okay when only a single engineer is involved. Once another engineer wants to apply configuration changes to the same set of resources with Terraform, using a remote backend will make more sense since the second engineer needs to have access to the existing state file (used by the first engineer). In addition to this, we need to make sure that configuration changes to the same set of resources are not applied at...

Verifying the state-locking setup

Verifying the Terraform state-lock setup is crucial to ensure the integrity of our infrastructure management process. By verifying the state-lock setup, we can confirm that the distributed lock mechanism using S3 and DynamoDB from the previous section is functioning correctly. That said, what happens when two users attempt to run terraform apply almost at the same time? We will see what happens in the next set of steps!

Note

This scenario of concurrent terraform apply commands highlights the importance of state locking to prevent conflicts and ensure data consistency. In this section, we will explore how Terraform manages state locks and handles concurrent operations. This will help us have a better understanding of the behavior and safeguards implemented by Terraform in such situations.

Part 1 of 4 – Adding a 60-second delay to the upload script

  1. Continuing from where we left off in the previous section, let’s navigate...

Summary

In this chapter, we talked about how IaC can help us automatically prepare, configure, and manage our penetration testing lab environments in the cloud. We then used Terraform, one of the most powerful and most used IaC tools available, to create, modify, and delete cloud infrastructure resources. After setting up Terraform in our environment, we then proceeded with several hands-on examples to demonstrate the different capabilities of the tool. In addition to this, we rebuilt the vulnerable lab environment we prepared in Chapter 2 using Terraform (this time, automatically). Finally, we had a quick look at how to configure a Terraform backend with state locking to help prevent conflicts when multiple engineers are using Terraform to modify infrastructure resources.

In the next chapter, we’ll dive deep into the different strategies for isolating accounts and environments in the cloud. The information, along with the hands-on solutions in the next chapter, will help...

Further reading

For more information on the topics covered in this chapter, feel free to check out the following resources:

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Building and Automating Penetration Testing Labs in the Cloud
Published in: Oct 2023Publisher: PacktISBN-13: 9781837632398
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime

Author (1)

author image
Joshua Arvin Lat

Joshua Arvin Lat is the Chief Technology Officer (CTO) of NuWorks Interactive Labs, Inc. He previously served as the CTO for three Australian-owned companies and as director of software development and engineering for multiple e-commerce start-ups in the past. Years ago, he and his team won first place in a global cybersecurity competition with their published research paper. He is also an AWS Machine Learning Hero and has shared his knowledge at several international conferences, discussing practical strategies on machine learning, engineering, security, and management.
Read more about Joshua Arvin Lat