Overview

This is going to be a multi-part series where I will cover various AWS concepts, terminology and technology. Subsequent posts will be more information security focused. There will be a bit of bias towards Incident Response (IR).

Follow along at the AWS Security Overview Table of Contents

Level Setting

There are exceptional companies (Netflix comes to mind) who are already doing really cool things in the cloud. Both from a Digital Forensics and Incident Response (DFIR) and Engineering perspective. There are also a couple good cloud security tools, a couple cloud security blogs, and I have even seen a couple CON talks on the topic.

Then there is the majority.

The individual(s) that got a call to respond to a compromised company only to find out the client's servers are in the cloud and the client's engineers didn't think their deployment through and no one knows anything about cloud. Oh yeah, and nothing is documented either. They give you console access, and say, "Here you go. Hook us up."

Then there is the Security Operations Center (SOC) team that was told during a morning meeting, "Hey, we are moving to the cloud, and oh yeah, we already have a dozen systems in there. A few of them are critical. Information security is a roadblock so we just deployed them."

This is my small part to try and close the gap a tad bit for the people that experience these kind of scenarios in their workplace.

NOTE:  For any definitions, I am going to use it more or less verbatim from the AWS documentation.  Their documentation is robust and usually pretty current.  So rather than citing everything, just assume I have gotten it directly from the respective AWS documentation.

Terminology

One of the challenges I had when first learning about cloud was the terminology was more or less all new and the concepts were foreign to me. I will start with the foundations in this post. In later posts I will get into more details for each respective technology.

Let's begin...

Regions

Each region is a separate geographic area. The list of currently supported regions and services can be found here. Again, this could change, especially with re:Invent 2017 around the corner. I will be using, Northern Virginia because that's where I have all my stuff located.

Some services are only located in certain regions, some are global and span all regions. For example, Identity and Access Management (IAM) does not support regions. It's global. Resources aren't replicated across regions. It is your responsibility to replicate them. There are fees associated with transferring data between regions.

Each region is completely independent, which achieves a high level of fault tolerance. It also ensures that you're meeting your legal compliance requirements. For example, maybe your organization conducts business in a country where you're not allowed to move citizen data outside of a particular country/region.

Choosing the right region can also; provide cost savings, decreases latency for users/customers, etc.

A region consists of two or more Availability Zones (AZs).

Availability Zones

Within a region, there are multiple (two or more - isolated) locations referred to as, Availability Zones, or "AZs".

An Availability Zone is represented by a region code followed by a letter identifier; for example, us-east-1a. The AZs are composed of one or more data centers. No one data center can be part of two AZs. This allows for independent failure zones.

Each AZ is isolated (physically separated), but the AZs in a region are connected through low-latency links. It should be noted that regions are connected over the "internet". Regions do not have low-latency links connecting them together like AZs do.

Virtual Private Cloud (VPC)

A VPC is a virtual network dedicated to your AWS account. It resembles the traditional networks we all use today. It's the networking layer for Amazon Elastic Compute Cloud (EC2). It's logically isolated from other virtual networks within AWS. This means you're network isn't going to cross paths with my network. I can't see your stuff.

As soon as you create an AWS account, you're assigned a "default VPC". This default VPC has everything you need to get started. You can launch an Amazon Machine Image (AMI) and have a web server up and running in just a few mins.

You can choose to keep this default VPC and make modifications to it to fit your environment, or you can create another VPC. When you create VPCs within your AWS account they are called, "non-default VPCs". You can also delete it if you want. If you delete it, and change your mind, you can recreate your default VPC within the VPC dashboard as well.

When you create a non-default VPC you will need to assign an IPv4 address range for the VPC (Ex. 10.0.0.0/16). You can, if you want, assign IPv6 CIDR block to your VPC as well.

Within your VPC, you can (just like a traditional network), configure an IP address range, specify/create private/public subnets, manage your route tables, implement network gateways, configure security settings among others.

Each VPC will have a unique ID (Ex. vpc-0cb12345).

VPCs span all the AZs. You can also add more than one subnet in a particular AZ. Subnets cannot span AZs.

We will discuss more about VPCs as we go on. A lot of other things make up a VPC. Those other things, will get their own sections (Ex. subnets).

Subnets

As mentioned above in the VPC section, you're assigned a, "default VPC".
You're also assigned a "default subnet". This default subnet is a public subnet, which means you can reach the internet out of the box.

When you create subnets within this default VPC, they are called, "non-default subnets". If you create an instances within those non-default subnets, they will be assigned IPv4 private addressing that's not routable to the internet (by default). They are; however, able to talk to other subnets via target local as you will see inside the respective route table. Each subnet that is created is assigned a unique ID (Ex. subnet-d123456d)

Subnets must reside within one Availability Zone and cannot span AZs.

If a subnet's traffic is routed to an internet gateway, the subnet is known as a public subnet. A subnet without a route to an IGW, is a private subnet. If the subnet has traffic routed to a virtual private gateway, it's referred to as a VPN-only subnet.

If you wanted a system within a public subnet to communicate to the internet it would need to have a public IP or a Elastic IP (EIP). Each instance that receives a public IP address is also given an external DNS hostname.

Each subnet must be associated with a route table. When you create a subnet, it will be automatically associated with the main route table of the VPC.

Subnets use Network Access Control Lists (ACLs) to manage inbound and outbound traffic for your subnet(s). They act as firewalls at the subnet level.

I'll write more about the security features in subsequent posts.

IP Addressing

I mentioned in the subnet section that, "If you wanted a system within a public subnet to communicate to the internet it would need to have a public IP or an Elastic IP (EIP)."

When you launch an instance into a VPC, your subnet has an attribute that determines whether instances launched into that subnet receive a public IP address.

This is configured here within your VPC dashboard. Subnet Actions -> Modify auto-assign IP settings

You can also enable or disable the public IP addressing feature during launch, which overrides the subnet's public IP addressing attribute.

By default, Amazon assigns a public IP address to instances launched in the default VPC, and Amzon does not assign a public IP address to instances launched in a non-default subnet.

The public IP address is not assigned to your account. If you stop (or terminate) your instance(s), you will receive a new public IP address when it's restarted. If you decide later to assign an Elastic IP (EIP) address to your instance, you will not be given the already assigned public IP address. It will give you a new one. If you change your mind an no longer want an EIP, when you disassociate that EIP you will receive a new public IP.

If you want a persistent public IP address for your systems, use EIP.

I bring this section up because I can foresee a case where someone has their web server popped, they panic, stop the instance, fiddle around a bit, then restart it. Then the security team is reviewing logs and they wonder why there is two different public IP addresses for this web server they are analyzing.

More on Network ACLs in a subsequent post.

Internet Gateways (IGW)

Amazon says the IGW is, "a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the Internet." Amazon manages the IGW. It just, works.

It serves two purposes. 1) provide a target in your VPC route tables for Internet-routable traffic 2) perform network address translation (NAT) for instances that have been assigned public IPv4 addresses.

IGWs are attached to the VPC. The default VPC that's created when you open an AWS account already has an IGW associated with it. If you create non-default VPCs, and you want them to talk to the internet you will need to associate an IGW.

You can then create routes with your associated subnets and create a route that points to the target, igw-xxxxxxxx.

Public Subnet Route Example. Note the route to the 0.0.0.0/0 target, igw-xxxxxxxx. This indicates that this is subnet can route out to the internet. If you do not have this route, you're system wont be able to communicate out to the internet.

Private Subnet Route Example. Notice the missing route to the igw.

You can also have VPN-only subnets if traffic is routed to a virtual private gateway (vgw-xxxxxxxx). I don't have an example of this within my account. You would use something like this for example to connect your corporate environment (or house) to your AWS environment.

NAT Gateways

You can use a NAT gateway to enable instances within a private subnet to connect to the internet (or other AWS services) without having to expose them to the internet via a public subnet. This can be useful for software patches (Ex. yum/apt-get updates), or to isolate a web server in a public subnet behind a NAT gateway.

The NAT gateway prevents the internet from connecting to the instances within that private subnet.

If you use IPv6, you will need to use an egress-only internet gateway as IPv6 is not supported with a NAT gateway (at the time of this post).

You can monitor you NAT Gateway via CloudWatch, which are sent in intervals of 1 min. Some of the metrics sent are: PacketsOutToDestination, PacketOutToSource, PacketsInFromSource, PacketsInFromDestination, BytesOutToDestination, etc. Look at the VPC documentation for specifics about those metrics.

These metrics could be useful in an exfiltration scenario. You can also use flow logs to capture the traffic for both, NAT Gateways and NAT Instances. Flow logs will be a separate post.

There are also NAT Instances, which vary a bit from NAT Gateways. You can read more about them here.

Route Tables

Just like physical networking, a route table within AWS; contains routes (or rules) that route traffic to its respective route (or direction).

"A subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same route table. If you don't explicitly associate a subnet with a particular route table, the subnet is implicitly associated with the main route table."

You must update the route tables for your subnets that use gateways or connections. For example, if you setup an IGW, you will need to modify the route table to traffic knows to use the IGW.

You can determine what routes a subnet is associated with my going to the VPC Dashboard -> Subnets -> Select your subnet -> Route Table tab (next to the Summary tab).

You can also, determine how many and which subnets are explicitly associated with a route table.

VPN Connections

Like a traditional VPN, you can connect your VPC to remote networks, whether it's your home or your corporate network (or both). In AWS, a VPN connection is defined as, "the connection between your VPC and your own network."

Setting up a VPN is quite simple. You will need to setup a; Virtual Private Gateway (VPN concentrator) and a Customer Gateway, which is the device (HW or SW) on your end of the connection. You must then update your route table to include the routes used by the VPN.

It uses a 32 bit pre-shared key (PSK) to establish the initial Initial Key Exchange (IKE) Security Association between the virtual private gateway and customer gateway.

If your key is compromised you can replace it. You will have to delete your VPN connection and then create a new one using the same virtual private gateway. Then you will need to configure the new keys on your customer gateway.

If a subnet doesn't have a route to an IGW, but has traffic routed to a virtual private gateway, it's called a VPN-only subnet.

You can monitor the VPN tunnel metrics using CoudWatch. They are recorded for a period up to 15 months. VPN metric data is automatically sent to CloudWatch.

Visual

So here we have a visual depicting most of the topics we covered briefly above. I have not added any computing instances yet. I will build on this diagram in future posts to help visualize all this terminology. Some of the services above are an additional fee (VPN and NAT Gateway), so I do not have them configured in my environment (hence, not on the diagram).

In Summary

Now that we have laid the networking foundations, I will start getting into more specifics about each of these in subsequent posts. There is A LOT to cover. It can get long winded, so separate posts are necessary.

Enjoy!