Setting Up a Pentesting Environment in AWS Cloud
A Structured Roadmap
If you are someone in the cybersecurity arena, chances are high that you’ve heard or even attempted penetration testing or pentesting. If you are a white hat newbie, pentesting would be an excellent stepping stone for you to get started with infosec testing. But a few concerns need to be addressed beforehand. This article is aimed at helping you tackle those and prepping you to create your own kind of pentesting lab environment.
Why a lab setup?
Simply put, penetration testing is a type of simulated attack aimed at finding existing vulnerabilities and potential security loopholes in a system. The definition itself hints at the inherent risks there might be in store for the attacker. The severity of those mainly depends on the isolation level of the testing environment setup and the vulnerability level of the target being attacked. Let’s focus on the environment setup.
Having an isolated environment dedicated for testing is a must if you want to stay clear of the risks you might attract or inflict on the target while attempting pentesting. If not isolated, there might be the possibility of your own system getting infested with harmful agents through the target you are attacking, especially if you test while being connected to the internet, which is the case most of the time. Also, on the other hand, you might be live-testing a target and might unintentionally crash or damage the target. So, having a standalone lab environment for testing isolates you away from the aforementioned risks.
Where to set it up?
On a side note, this article is more inclined toward individual testers and preferably for beginners who want to start practicing pentesting. In professional scenarios, however, oftentimes a dedicated duplicate production environment is provided for the testing.
For testing purposes especially if you are still practicing, generally it’s best to use virtualization, as it provides more flexibility for you to switch between your normal working environment and the testing environment. It also provides options for scaling up the space since along the way, you might need to install and use proxies and many other tools to help with the testing.
Where to set up a virtual environment mainly boils down to using the cloud or the local machine. The answer is mostly subjective since either way, you get a standalone environment. Based on the benefit of not having to strain system resources, I opted for cloud virtualization. Again, this is subjective, so if you are not sure yet, you can try out both ways and choose what suits you the most. But this article will be continuing the cloud virtualization testing.
How to set it up?
Now that we have grazed some pentesting context, let’s get more technical. For this article, I’ll be using Amazon Web Services, but it’s up to you to choose any cloud provider you like.
It’s assumed that you already have an AWS account and some knowledge about AWS instances. To give some heads up, we’ll be using the EC2 (Elastic Compute Cloud) web service which is one of the many services offered by AWS, that specifically allows you to use resizable compute capacity in the cloud. I’d be using the EC2 free tier version, which allows you to use a limited amount of compute capacity for free. For a beginner testing experience, the free tier version will suit just right.
Let’s dive in.
Creating the instance
First, you need to login to your AWS EC2 dashboard. Then, navigate to the instances page, and there, you will see a ‘launch instances’ button.
Once you have named your instance and added any tags if needed, next you need to choose an AMI, or an Amazon Machine Image. An AMI is a template that is used to create a virtual machine in EC2. It’s more like a blueprint that comes pre-configured. But you can still edit the configurations as you wish. Apart from choosing a pre-configured AMI, you also have the option of creating a custom AMI. For this, I’ll be using a pre-configured Ubuntu AMI. You can look for any type of AMI you prefer, but be sure to check the free-tier eligibility if you are using the free-tier version of EC2.
After selecting the AMI, by default, your instance type would be updated as ‘t2.micro’, which is the only free-tier eligible instance type. The instance type here simply represents the resources configuration of the virtual machine.
Next comes the key pair generation part, which is crucial in securing your cloud instance. Public key/asymmetric encryption is used here, to secure your instance using 2 keys: a public key and a private key. If you already have a key-pair that you have generated before, then you can use it for this instance as well. If not, you can generate a new one. Usually, the best practice is to create new key-pairs for each of your instances. Those key-pairs will have a file extension of ‘.pem’.
Important — You need to save the generated key pair in a safe place in your device since you won’t get another chance to save it later. Each time you connect to your instance, you’ll have to provide the name of your key-pair and be inside the folder you saved the key pair into.
Next, you have to configure the network settings, which is of highest priority within the context of this article. Let’s see how we can adjust the network security first.
Security Groups
Security groups are the fundamentals of network security in AWS EC2. They create stateful virtual firewalls around your instance. But, not all use cases may require the same type of security groups, for in our case, the default security group provided when creating the instance won’t ensure the level of security we intend to impose. Due to that, we’d have to edit the default one or create a security group of our own.
The security groups simply control the incoming and/or outgoing traffic related to your instance and utilize 2 sets of rules: inbound and outbound rules. The inbound rules define how to allow the traffic that is coming into the instance and outbound, the traffic going out of the instance.
When you are creating an instance, by default, an inbound rule is already in place to allow the SSH traffic into the instance so that you can connect to the instance through port 22. And as per the default outbound rules, you can connect to any other IP, through any port.
(But if you are explicitly creating a security group, unrelated to an instance, then the security group comes with no rules at all.)
But it’s best to create a separate security group dedicated to the pentesting use case prior to launching the instance and then applying it.
Let’s add an inbound rule for the secure shell. Giving access to ‘any’ source IP in the rule would allow literally anyone to SSH into the instance which can be quite risky. So, let’s only allow our own IP to access.
And for the outbound rules, it is best not to open all ports to the internet. Since we’ll have to use the internet later for the installation of a target application and other tools and dependencies needed for the setup, it is necessary to open the HTTP and HTTPS web ports.
Note — To make the above outbound rules more effective, you can specify the IP addresses you’d like to initiate connections with, rather than letting your instance initiate connections to any IP address over the above ports, which would be risky. So, the best practice here would be to disable the above rules, whether you specified any IP or specific IPs, after you’re done with the internet connections.
Afterthoughts
And that’s one of the several ways you can implement a basic level of security for your instance. Even though this isn’t the only way to isolate an instance, this is the most granular way you can apply security directly to an instance. To give you an overall understanding, the other ways AWS let you meddle with the network security are,
- VPC (Virtual Private Cloud)
VPCs work at a broader level than the security groups. It defines network configurations that cover the entire VPC including subnets and network gateways, which might house several instances and provide a higher level of network isolation.
- Private Subnets
These are subdivisions of VPCs and have more granularity. Most importantly they do not have internet access and the resources you put in these subnets do not get public IP addresses, which further reduces the harmful internet exposure.
- Network ACLs
These also operate at the subnet level of security and Network ACLs are stateless unlike the stateful security groups, which means for a specific type of connection, you should explicitly define both ingress and egress rules.
Conclusion
Within the boundary of this discussion, handling the instance-level security through security groups gets the work done. But if you are interested, you can take it up a notch and further tighten the instance security by exploring the above-mentioned other network security enablers.
What we explored here is just a preparation for pentesting and from here, you need to take up the journey through the pentesting target setup and move onto start attacking the target for real. Hopefully, we will continue this exciting journey together with a series of articles in the not so distant future.
