You Shouldn’t Use the EC2 Launch Wizard
TL;DR: You should code your EC2 instances if you care about security
The EC2 launch instance wizard is one of the most familiar and loved wizards out there — in several simple steps, it allows you to create your first instance on the AWS platform, connect to it and start using it for your purposes, whatever they will be.
In this post, I would like to raise awareness to some insecure default configurations that the wizard walks you through as you provision your instance, and discuss what should we do in order to prevent provisioning insecurely configured instances.
Going through the wizard
The EC2 launch wizard consists of several stages:
- Image Selection
- Instance Size Selection
- Instance Configuration
- Storage Configuration
- Tags Configuration
- Security group Configuration
- Final Review
On development / test accounts, developers usually have relatively freedom to explore the various services, while working with Linux / Windows based instances. At least once a week someone will provision an instance without choosing a secure configuration.
By observing the security posture of many accounts, and more noticeably development accounts, I noticed an insecure behavior which I think needs to be addressed differently by design, so let’s dive into it.
Here is the “Instance Configuration” stage:
An interesting case that i seen few times is just skipping all the wizard configurations and pressing on the “Review & Create” button which will assume all the insecure configurations that we will detail.
Let’s spot the insecure default configurations on this stage:
- Default VPC selection will set your new instance VPC to be the default VPC in your working region. The default VPC is defined with public subnets only by default. The reason is obvious: There’s no additional charge for having an internet gateway in your account.
- Default subnet selection is the default subnet, which is public on the default VPC — n accordance with the previous point.
- Auto-assign Public IP is configured to the subnet setting, which defaults to true in case of a public subnet. That is required in order for the instance to reach the internet through the Internet Gateway associated with the route table of the public subnet.
- Metadata accessible is configured to be enabled by default, and metadata version is allowing both V1 and V2 requests.
Moving on, let’s take a look at the “Configure Security Group” stage:
- Despite the warning rectangle, most of the time you would press “Next” because why not, and that will create a “launch-wizard-x” security group with an ingress rule that allows ingress access from 0.0.0.0/0 on the access port by default (RDP / SSH).
What can you do about it?
In our organization we have remediation controls for such cases, you can check out open source projects like Cloud Custodian that help to set up policies to prevent those issues. If not, your instance will be scanned and brute force attempts will occur.
Another possibility is to use an infrastructure-as-code solution such as Terraform, Ansible or Cloudformation to declare on your instance configuration. Having both of these techniques combined will allow you to reuse your code to provision an instance, while remediating issues automatically in response to an insecure trigger (such as adding insecure ingress rule to a security group)
In case you selected a custom AMI with password access or use a user-data script to allow password access to the instance immediately after provisioning, you’re immediately exposing yourself to those risks. On most Linux AMIs you have at least the KeyPair as a security control, but that’s still only one layer of protection.
I felt it is important enough and while I believe these defaults exist to make it easier for users to get started with EC2 I don’t believe it’s the correct approach security-wise, as I see many cloud users & developers keep falling into this trap. You can raise awareness, you can remind users regarding the security best practices, but eventually, someone will be reckless enough to press the “next” button and ignore all these.
Meet secure_ec2
In order to handle those cases, I thought that if you want to beat that wizard, you need to provide a tool that will beat the wizard user experience. While there is a lot to improve, the secure_ec2 tool allows you to go through a simple wizard on your terminal and provision an EC2 instance in a fast, secure way.
§ pip install secure_ec2
After installing the tool, you can choose between launching a number of Windows or Linux instances. The tool will select the latest AMI of the relevant operating system, that is managed and updated by AWS. Based on your selection, you can provision an instance with KeyPair or Session Manager access (which is a more secure way of connecting to your EC2 instance).
If you choose to use a KeyPair, the instance will be provisioned automatically with a security group that will be limited to your local station public ip address. If you’ll choose to connect with Session Manager, the tool will do the heavy lifting and provision the necessary IAM profile, and policies to allow your instance to use that connection method.
While secure_ec2 is built with AWS in mind, I might consider expanding it to additional cloud providers like Azure or GCP. If you have any suggestions or feature requests in mind, you’re more than welcome to raise an issue in the project GitHub repository.
Stay Secure!
