AWS Security Groups - Once And For All
Tags: aws, network, security, hipaa
Published: 2021-06-02 19:03:59

As part of securing applications in the cloud, it's important to set the proper network rules, for maximum security and to minimize collateral damage.

Here's a quote from the [official HIPAA](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html) requirement for *Transmission Security*.

> A covered entity must implement **technical security measures** that **guard** against unauthorized access to e-PHI that is being transmitted over an electronic **network**.

## HIPAA

For those of you who are not familiar with HIPAA, it's a very strict regulation that requires protecting medical records and other **p**ersonal **h**ealth **i**nformation (PHI). 

Most startup companies that develop a product for the medical-healthcare sector, aspire to become [HIPAA compliant](https://www.hhs.gov/hipaa/for-professionals/regulatory-initiatives/index.html). 

Here's the question you need to ask yourself when it comes to *Transmission Security*

>  What security measures are currently used to protect e-PHI during
transmission? [HIPAA - Security Rule - Technical Safeguards](https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf)

## Network Security Layers Overview

I'd have to write a book to cover all the network security layers, so let's get a quick glance at the most common network security layers in AWS.

1. Application - [AWS Web Application Firewall (WAF)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html)
1. Subnet - [AWS Network Access Lists (NACLs)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)
1. **(Virtual) Firewall - [AWS Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)**
1. Network - [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html)

In this blog post, I'll focus on the **Virtual Firewall** layer. In AWS, the implementation of a Virtual Firewall is done with AWS Security Groups.

## Stateful Vs. Stateless

Security groups are **stateful**, the [official docs]( [stateful](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)), describe it as follows:

> If you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules. 

By default, a security group is created without any inbound rules. That means it doesn't accept traffic from any device that attempts to **initiate** a connection. 

The default outbound rule is `0.0.0.0/0` which allows devices to **initiate** connections to anywhere. Once a connection is initiated, the security group rule is **ignored**.

So what is stateless? We'll cover that in the *Blocking Specific IPs* section.

### Security Groups Ground Rules

1. Once a connection is initiated, the security group rules are ignored and traffic is allowed for the new connection.
1. There's no way to enforce security group rules on existing connections. Rules are applied to new connections only, so you must terminate existing connections, to force new security group rules.

### Practical Example

Let's say you want to SSH from your local machine to an EC2 instance, that has a public IP address.

To achieve that, you'll add an inbound security rule that allows `SSH` connections from `My IP` (your IP). And then, you'll SSH to the EC2 and it'll work as expected.

Here comes the tricky part; What would happen if, during your SSH session, someone removes your inbound security group rule? Nothing. As mentioned earlier, security group rules **apply to new connections only**, since your SSH session is active, you can still continue with your work. If by any chance, you get disconnected for even a split second, the new security group rules will take place and you'll get disconnected.

## Allow Or Deny?

This is very confusing; One might want to deny traffic from a known set of IP addresses. It is common to think that Security Groups can be used to **block** traffic **explicitly**, though it **is impossible**.

Security Groups are designed to **Allow** access from/to sources, and **implicitly** block unknown sources. When you add a security group rule, you don't have an option to set its type (Allow/Deny), it is **Allowed** by design.

### Blocking Specific IPs

To address the need for explicitly blocking specific sources, you can use AWS Network Access Lists (NACLs), which are stateless, and as part of setting a Network Access Rule, you'll have the option to set its type (Allow/Deny). It's important to mention that NACLs operate at the Subnet level, while Security Groups operate at the VPC level.

Reminding you that NACLs are stateless, which means you'll need to create a rule for both inbound and outbound for any source/target device. Unlike Security Groups, if you haven't **explicitly** allowed a connection both inbound/outbound, it is denied by default. The default NACLs rules, for both inbound and outbound, are `All traffic, from/to: 0.0.0.0/0`.

**NOTE**: I rarely use NACLs, unless there's a specific need to block a set of IP addresses at the subnet's level, which in my experience, is quite rare and should be used with cautious.

### Allow Access According To IP and Request URI-Path

One might think "but hey, I want to allow access to `https://myapp.com/admin/dashboard` from my IP only, how can I do that? Since HTTP requests are handled at the application layer, you can use the AWS Web Application Firewall. 

- Create a rule for [web request component settings](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-fields.html) with the required `URI Path`
- Create a set of IPs and add your IP, call this set `whitelisted`.
- Create another rule that whitelists your [IP address](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-reusable-entities.html).

Here's the **pseudo-code** of the set of rules that should be created

```bash
if AND(
URI-Path == https://myapp.com/admin/dashboard,
SourceIP != Whitelisted-IPs
)
then Block
```

## Selecting The Right Defense

1. Security Groups are designed to **Allow** traffic from/to sources, at the VPC level.
1. NACLs can be used for blocking a set of IP addresses (bots, bad reputation, etc.) at the Subnet level.
1. AWS WAF can be used for blocking all traffic to a specific `URI-Path`, and allowing traffic only from a specific set of IP addresses (whitelisted).

## References

- [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
- [How do I troubleshoot instance connection timeout errors in Amazon VPC?](https://aws.amazon.com/premiumsupport/knowledge-center/instance-vpc-troubleshoot/)
- [Why can't I connect to an endpoint service from my interface endpoint in an Amazon VPC?](https://aws.amazon.com/premiumsupport/knowledge-center/connect-endpoint-service-vpc/)
- [How do I resolve Amazon VPC peering network connectivity issues?](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-peering-connectivity/)
- Cover image - [Hackerboy Emoticons](http://123emoji.com/hacker-boy-sticker-5682/)

## Final Words

When I first started my journey with AWS, Security Groups were one of the first components that I encountered. I also didn't have any background with networks, so stateless and stateful didn't mean anything to me. Once I broke it down and found out which service should be used for each purpose, it was all clear.