Prerequisites

• Have an available Workload account.

The Lesson

We’ve reached the point where it’s hard to gain a visceral understanding of the security implications of what we are building, without some workloads to run. I mean, if you are running through CloudSLAW on the weekly schedule you’ve been at this over 6 months, and haven’t even run anything yet.

It’s time to fix that.

Today we will run our first instance, which is the AWS term for a virtual machine. The odds are high that many, if not most, of you have already done this a zillion times. No worries — my plan is to use this chance to cover some security fundamentals, and set the baseline for how we will use instances moving forward.

Because, Cryptomining (and Stuff)

If you ran through our IAM labs you know that one of the single biggest sources of cloud security breaches is lost/exposed credentials. Everything we did, from basic MFA to IAM Identity Center and IAM roles, was to reduce this risk.

Exposed instances sits right up there on the wall next to IAM abuse. If IAM is Humpty Dumpty, instances (and S3 buckets) are sitting right next to him waiting for their chance to slip and crack open your security program.

Compromised instances are one of the top 3 cloud security risks. And when an instance is compromised, the most common form of abuse is cryptomining. It turns out you can’t make money mining Bitcoin (and friends) unless someone else foots the electricity bill.

There are three primary ways attackers compromise instances in deployments:

• They steal IAM credentials to run their own instances in your account.

• They trick you into running an image with their mining software already installed.

• They use a regular network-based attack to break into your instance and install their mining software.

We’ve been learning about IAM defenses from the start, and today we’ll take our first steps towards running secure instances, to prevent the latter two attacks.

Images, Instances, and Hypervisors

Instance is a term relatively unique to AWS. It refers to a running virtual machine. Instances are based on Images. Images are like the CD-ROM disks old people had to use to load up an operating system on a new computer. An image in AWS is a pre-configured operating system, including the base OS and any additional configured software.

Images in AWS are referred to as AMIs, which stands for Amazon Machine Image, since they are about as creative as I am.

I like that AWS calls these instances because we are just running a copy — one instance — of the image. When we get deeper into workloads we’ll learn about autoscale groups, which run and terminate instances based on the current demand. That’s where the name Elastic Cloud Compute (EC2) comes from: we can build things to expand and contract capacity by adding or removing instances based on demand.

Instances are virtual machines. Virtualization allows us to run multiple operating systems at the same time on one computer. You can be on a Mac and run a full version of Windows on your desktop. We call the hardware the host, and the virtual machine the guest. The software that allows this is a hypervisor. There used to be a big performance hit, but a long time ago the companies who make CPUs added special hardware extensions just for virtualization, so when a guest OS is running it can access its slice of shared hardware directly.

I believe the AWS hypervisor is largely built into the hardware servers now. It includes a bunch of security hardening so individual instances can never access anything from another instance. This is a base requirement for a hypervisor: each instance (virtual machine) is totally isolated from the others. This stands in contrast with containers, which share an operating system — that makes isolation harder.

An instance is a hard security boundary. Guest-to-guest or guest-to-host security vulnerabilities are considered some of the most serious we can encounter. They are are rare and AWS is constantly working to sure we don’t need to worry about them.

This is all just backdrop. Today we’ll learn how to choose a safe image and securely deploy and log into a non-public instance. I’ll skip a ton of detail so we can get running, but future labs will dig in.

Lesson Key Points

• EC2 is the AWS service for running virtual machines.

• These VMs are called instances.

• Instances are based on images.

• Attackers like to hack into instances, or get you to run an image with malicious software already installed. These are some of the most common attacks in the real world.

• Multiple instances run on the same physical server, but the hypervisor ensures they can never see each other. This is the biggest of Amazon’s responsibilities in the shared responsibilities model.

The Lab

The lab is simple and designed to highlight the security concepts explained in The Lesson above:

• We will run a CloudFormation template (hosted in my account) to create a VPC.

• This VPC is the same design we’ve been using, with three additions:

  • A security group with no inbound access and unrestricted outbound access.

  • An IAM role called SSMClient which we will use to allow us to log into the instance.

  • An Instance Profile to attach the role to our instance.

I won’t explain that login piece and the role today — we will have another lab to focus on that. It’s a super-cool which that allows us to deploy more securely. The TL;DR is that the image we will run includes a software agent which communicates with an AWS service, which in turn enables us to log in using the console, even with our instance in private subnet.

Video Walkthrough

Step-by-Step

Start in your Sign In Portal then go to TestAccount1 > AdministratorAccess > CloudFormation > Create stack. Since we’ve done this a lot by this point, I’m skipping some screenshots.

Choose Use an existing template > Amazon S3 URL and paste in this URL: https://cloudslaw.s3.us-west-2.amazonaws.com/basicvpcwithssm.template, then click Next:

Name it SLAW and click Next. Scroll down the next page and click Next again. On the following page scroll down and check the checkbox at the bottom which says The following resource(s) requires capabilities and then click Submit:

Then wait until it’s complete. This creates the same VPC we used for the past 2 labs, but adds a security group and the IAM role and instance profile we need to log in.

When that’s done, go to EC2 > Launch instance:

Name it Slaw and then click Browse more AMIs:

Notice the three categories. One of them has higher security risks:

• Quick Start AMIs are provided by AWS and safe, although that doesn’t mean they are fully patched.

• My AMIs are ones you make.

• AWS Marketplace AMIs are provided by commercial vendors who go through a vetting process. It doesn’t mean they are risk-free, but it’s up to the vendor to keep them secure. Honestly, that doesn’t mean much considering the state of software these days, but at least you have someone to sue if things go bad.

• Community AMIs are the Wild Wild West. Any idiot can put whatever they want in there. I should know — I do it a lot. But adversaries also know this, and routinely spike AMIs with backdoors and cryptomining malware.

Click Select:

Then click Quick Start and select Amazon Linux. This is a flavor of Linux which AWS maintains. It’s pre-installed with settings and tools to make it easier to use in AWS. This includes the software agent we need for our little login trick.

Keep scrolling down. Notice that we are using the t2.micro size, which is low on performance and high on “being on the free tier”. AWS supports a zillion instance types optimized for different kinds of workloads. t2.micro is fine for most experimentation.

Scroll down more and select a key to log in with. Choose the option Proceed without a key pair (not recommend), and scoff at Amazon’s recommendation. Normally this is an SSH key to log into your instance, but we won’t be using SSH so don’t need a key.

Scroll down a smidge more, and in Network settings click Edit. The defaults won’t work for our lab:

Confirm you are in the CloudSLAW VPC, then select private-subnet-1. Remember, this has a NAT Gateway to access the Internet, but there is no incoming route from the Internet so it’s considered private. Don’t create a launch-wizard security group, and don’t use the default security group. Instead select the Slaw-PrivateSecurityGroup I made for you. Ignore the random text at the end — that’s a CloudFormation thing. This SG has no inbound access but allows unrestricted outbound access.

This next part is super important. Every part is important, but this next one is.. super important. Click the arrow to open up Advanced details, then go to IAM instance profile, click the dropdown, and select SSMClient. Yes, I’ll explain more in a future lab — just trust me for now.

Now hit Launch instance on the right side:

While it’s booting feel free to explore the security group and notice how I set it up. Then click Instances in the left menu, wait for the Status checks to complete, then check the box next to the instance and click the Connect button. BTW… I can’t possibly tell you how much easier and better this all is compared to when I started nearly 15 years ago.

We want to use Session Manager. This is a feature of the AWS console which allows us to log into instances, even in private subnets, using that little software agent built into our image. To work our instance needs to be able to talk to the session manager service, but it can do that because we have a NAT Gateway and a Security Group which allows outbound connections. Click Connect:

This is very cool, and I’ll review in the Lab Key Points.

Feel free to play around with Linux commands (type ls if you don’t know any). Once you’ve amused yourself it’s time to wipe everything so we aren’t charged. First go back to your Instances tab, then check the box next to your instance again, then click Instance state, and Terminate. This is a non-recoverable operation! Terminating deletes the instance, releases all its resources, and deletes the associated storage.

You need to wait until it finishes terminating before going to the next step. It looks like this:

To finish cleanup, go to CloudFormation > Delete:

Lab Key Points

• We created a VPC with public and private subnets. The private subnet has a NAT Gateway.

• We selected an AMI supported by AWS. This means it should be safe and has additional software to help use it with AWS.

  • AWS keeps these relatively up to date, but they can still have vulnerabilities. We’ll cover those in a later lab.

• We placed our instance in a private subnet so those pesky Internet hackers can’t attack it. We also put it in a Security Group without inbound access.

• We assigned an IAM role via an instance profile so we can use the Session Manager service. This enables us to log into the instance without any other credentials (our IAM permissions must allow this, and we are running as an administrator).

-Rich