Protecting Data using Outbound Security Group Rules

Blue Chip Tek has been working with a client that has a specific security requirement to either limit or completely deny egress traffic from EC2 Instances. 

We have been working with a client that has a specific security requirement to either limit or completely deny egress traffic from EC2 Instances. The experience of meeting this requirement is the reason behind the blog post you are currently reading. Prior to reading further we should note that this post is ideal for readers who either have a need to completely deny egress traffic or who are first encountering EC2 Security Groups.

 

EC2 Security Group Defaults

First off, we want to make folks aware of AWS EC2 Security Group defaults, as the default egress rules will be need to be changed if performing egress filtering. The default settings for a newly created EC2 Security Group are described below:

 

  • Ingress:
    • No rules are created
    • All incoming connections are denied unless explicitly allowed.
  • Egress:
    • Allow all traffic types on any port on network 0.0.0.0/0
    • This tells us that all traffic outbound will be allowed out.

 

Note that for a number of firewalls and routers the default settings allow all outbound connections. This may not be ideal for all environments.

Administrators hold different views on the importance of filtering egress traffic – administrators may suggest anything from “allow all egress by default” to “allow no egress by default.”  Some administrators argue that with good ingress security you do not need to worry about egress and that egress may cause more problems with communication than necessary. Other administrators believe that it’s better to deny all egress and then explicitly allow only required egress traffic. The decision to filter egress traffic will likely be a compromise given your company’s need for simplicity and agility versus tolerance for risk – or a need to meet a security policy.

 

Understanding of EC2 Security Group Rules, Inbound

Before proceeding further, we wanted to make sure you completely understand EC2 Security Group rules (note: feel free to skip this section if you already have this experience). We’ve described a few simple tests to allow you to confirm your understanding of EC2 Security Group rules. The first step is to create an EC2 Security Group with default rules for ingress or egress – the result is an EC2 Security Group with the rules shown below:

Of course, you cannot SSH into an instance with no inbound connections allowed. Your next step is to create a single ingress rule to allow in SSH (tcp port 22). You can allow the connection from the IP from which you are conducting testing, but it is also possible to select another IP, CIDR IP range or allow ingress from all IPs (0.0.0.0/0). Below you can see both an EC2 Security Group in the AWS Console as well as an EC2 Security Group in a CloudFormation YAML file.

            Once the EC2 Security Group is updated you can SSH in and test an outgoing connection using both curl and ping for http://bluechiptek.com. You should be able to perform both actions normally.

 

Understanding of EC2 Security Group Rules, Outbound

            The next step is to create a new security group that allowed us to SSH in, but denied all outbound traffic. An important note: in the AWS console, you can remove the “Allow All Egress” rule but you cannot create a CloudFormation file that will create an EC2 Security Group with no egress rules. The closest you can come to creating an EC2 Security Group in CloudFormation with no egress rules is allowing only traffic to 127.0.0.1/32.

Since EC2 Security Groups are stateful, even though no outbound connections are allowed we are still able to communicate over SSH (tcp port 22). If you are connected to the server via SSH you’ll be able to test limited egress connectivity to the outside world using a simple curl command to http://bluechiptek.com (port 80) and https://www.google.com (port 443). With further testing you can create a single-port egress outbound rule – allowing initiation of outbound connections only on tcp port 80.

Now when you try to curl http://www.bluechiptek.com (port 80) you’ll be able to retrieve data. However, if you try to curl https://www.google.com (port 443) you’ll be denied access.

 

In Conclusion:

So, what does all this mean? If you’ve followed the post you’ll have an understanding of the basics of EC2 Security Groups, as well as understand how we can modify EC2 Security Groups to meet egress filtering rules. In our next blog post we will delve more deeply into controlling traffic egress – specifically to allow hosts to access only particular AWS S3 Buckets.

 

 

 

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-security-group.html

https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/

https://www.sans.org/reading-room/whitepapers/networkdevs/egress-filtering-internet-1536