5 Not-to-Ignore Best Practices for AWS Security Groups
Tags: awssecurity, firewalls, securitygroups, nacls
Published: 2018-10-20 19:41:35

---
title: 5 Not-to-Ignore Best Practices for AWS Security Groups
published: true
description: AWS Security groups help protect applications and data along with NACLs, VPCs. They restrict access to certain IP addresses or resources and ensures your AWS security perimeter is always guarded. Here are five best practices you must never ignore while configuring AWS Security Groups (SGs).
tags: AWS Security, Firewalls, Security Groups, NACLs,
---

<span style="font-weight: 400; color: #000000;">To secure AWS resources 24X7 from unwanted attacks, you must always have the right combination of VPC, Network Access Control Lists (NACLs), and AWS Security Groups (SGs). </span>
<blockquote>
<h3><span style="font-weight: 400; color: #000000;">AWS Security groups are cloud firewalls that help protect applications and data. They restrict access to certain IP addresses or resources. They guard your AWS security perimeter, always, <span style="text-decoration: underline;">provided you configure them in the right way!</span> Here are five best practices you must never ignore while configuring AWS SGs.</span></h3>
</blockquote>
&nbsp;
<h2><span style="color: #000000;"><b>#1 Ensure EC2 SGs Do Not Have Large Range of Ports Open </b></span></h2>
<span style="font-weight: 400; color: #000000;">Large port ranges, when open, expose the instances to unwanted attacks. More than that, they make traceability of vulnerabilities very difficult. For instance, your web servers may only require 80 and 443 ports to be open, but not all. </span>

<span style="font-weight: 400; color: #000000;">One of the most common mistakes we observe is users open all ports for 0.0.0.0/0 range, in a rush to access the instance and later forget to fix it!</span>

<span style="color: #000000;">When running on EC2 instances, you must expose your apps only to those ports enabled on the corresponding security group level.</span>
<h2><span style="color: #000000;"><b>#2 Use ELB’s SGs Wisely to Restrict EC2s’ Access to the Internet</b></span></h2>
<span style="font-weight: 400; color: #000000;">Even though a web server’s port 80 or 443 needs access to 0.0.0.0/0, it need not be open directly. Use an AWS ELB to receive all incoming traffic from the internet and forward it to these web servers or EC2s, then allow these EC2s to intake incoming traffic from the ELB only. Lock down ingress rules for these instances to the ELB SG. This way, no one will be able to reach the EC2s directly.</span>
<h2><span style="color: #000000;"><b>#3 Never Keep Unattached Security Groups &amp; Limit Modifications to Only Certain Roles</b></span></h2>
<span style="font-weight: 400; color: #000000;">Security configurations on AWS are dynamic. An administrator can change these configurations anytime. With the presence of unattached SGs, the risk of misconfiguration increases, because it makes it difficult for an administrator to figure out attached and unattached SGs in a large scale infrastructure. Chances of him/her changing the configurations of wrong SGs or accidentally attaching them to public instance becomes high, inadvertently opening up your environment to attacks.</span>

<span style="font-weight: 400; color: #000000;">Pro tip: The easiest way to identify unused security groups is to browse through security groups list, select ALL, and click Delete. AWS shows the list of attached SGs and prompts to delete only unattached SGs. Once you hit Delete, only unattached SGs are removed. The best way is to use an automated program doing this as part of your regular audits. </span>

<span style="font-weight: 400; color: #000000;">Just like an administrator accidentally misconfiguring SGs, other IAM roles with access to modifying SGs can misconfigure them too. Authorize only specific users to modify resource-specific security groups. </span>

<span style="font-weight: 400; color: #000000;">Keep a constant eye on IAM policies with a check on instance metadata, network ACLs, and SGs together. Only selective users must be able to change only a particular security group in a given region so that they can update or modify  as and when needed. </span>
<h2><span style="color: #000000;"><b>#4 Do Not Ignore Outbound Rules of an SG; Set Restrictions Decisively </b></span></h2>
<span style="font-weight: 400; color: #000000;">By default, an AWS SG does not have any ingress rules, and the outbound ports are open to the Internet. That emphasizes the fact that not only ingress rules need attention. However, egress rules need attention too. So, SGs attached to an application layer should only allow egress connections to the layer where it needs to connect. For instance,  if the web layer is only authorized to initiate connections to the application layer, the egress rules should only point to application-specific ports and specific subnetworks (e.g., VPC, security groups).</span>
<h2><span style="color: #000000;"><b>#5 Track Rate of Change in SGs’ Creation &amp; its Ports Opening &amp; Closing, in Production</b></span></h2>
<span style="font-weight: 400; color: #000000;">If an SG was created and its port was opened and closed in a very short duration of time, say less than 30 minutes, it typically is a case of suspicious activity. Especially, if it is in the production environment. The best way forward is to parse the AWS Cloud Trail logs in the production environment, compare with usual patterns and monitor the activities.</span>
<h2><span style="color: #000000;"><b>Conclusion:</b></span></h2>
<span style="font-weight: 400; color: #000000;">There are tens of other best practices for AWS Security Group. Like avoiding opening SSH/RDP to other instances of production environment. All these are very important but the above list are  ‘must dos.’ You can use tools like Puppet, Chef, RunDesk, etc. in conjunction with AWS to automate security audits. However, it’s overwhelming to keep a track on all these tools on different dashboards.</span>

<span style="font-weight: 400; color: #000000;">Moreover, SGs alone do not help mitigate security risks. Like we said before, the right combination of VPC, NACLs, and SGs make up for the security of your infrastructure. </span>
<blockquote>
<h3><span style="font-weight: 400; color: #000000;"><span style="font-weight: 400;"><span style="color: #000000;">Having said that, multiple dashboards to monitor and manage all these resources will take the energy out of the team. A single visual console rendering the relationship between all these resources, showing all the port connections with ingress and egress details helps find vulnerabilities in a snap. </span></span></span></h3>
</blockquote>
<span style="font-weight: 400; color: #000000;"><span style="font-weight: 400;"><span style="color: #000000;">TotalCloud Inc. will be soon rolling out such an Security View. This new view provides a focused visual environment with real-time cues to security loopholes in a 3D space. So stay tuned with us!</span>   </span> </span>

P.S.: We have listed out <a href="http://blog.totalcloud.io/5-not-to-ignore-best-practices-for-aws-nacls-network-access-control-lists/">top 5 best practices for AWS NACLs</a> too.

<span style="color: #000000;"> Note: Originally published at <a href="https://blog.totalcloud.io/5-not-ignore-best-practices-aws-security-groups/" target="_blank" rel="noopener"> blog.totalcloud.io </a> on August 24, 2018.
</span>