What is a Security Group?
An AWS security group is a virtual firewall which can be applied to one or more AWS resources to control its inbound traffic. One thing to keep in mind is that AWS security groups are all permissive in nature which means you can’t deny specific traffic sources with this firewall, you can just allow where your traffic should come from and where it should reach. An AWS security group can be applied to AWS resources such as EC2 instances, databases among a variety of other resource types.
A typical security group configuration looks something like this:
A little about the fields:
- Security group rule ID: You can’t assign the rule id to a rule yourself. AWS does that automatically once you’ve created the rule. If you delete the rule and configure the same rule again, there’s a 100 percent chance that AWS will set a different rule id for it.
- Type: The type of traffic you want to allow to/from your network. This allows a user to select from a wide range of services like Redshift, PSQL, LDAP etc.
- Protocol: Mostly, the protocol supporting your type of traffic is automatically set, but it’s possible to change it for some other remaining types.
- Port range: This comes in handy when defining a custom type of traffic. You can select a single port or a range too. As shown in the image below, we don’t have to worry about filling in the protocol and port range as we selected SSH as our traffic type.
- Source/Destination: Depending upon whether we are configuring an inbound or an outbound security rule, we can choose the source/destination varying from the Internet (0.0.0.0/0 – supporting both IPV4 and IPV6) to even a single IP Address by using /32 CIDR notation.
- Description: This last entry is really useful to tag a rule in some way to keep track of which rule is for what purpose when there are 10s of rules to look at. This makes working with security groups a little less overwhelming.
Pro Tip: Never allow traffic from 0.0.0.0/0 unless absolutely required.
AWS Security Group Best Practices
Restrict Default Security Groups
Each VPC in a region comes with a default security group. One can identify it by looking at the security group name field as default in the list of available security groups.
This default SG has following characteristics:
- Allows all Outbound/Egress traffic.
- Denies all Inbound/Ingress traffic EXCEPT the inbound traffic from network interfaces and instances that are assigned to the same security group. Here, the security group itself is passed as a source of traffic.
It becomes clear now why we shouldn’t use a default security group without tweaking it to restrict traffic to/from bad actors and the internet.
Carefully Use Security Group with Internet Ingress
While configuring SGs, many times we see that people use 0.0.0.0/0 as the source CIDR. This is said to give access to the Internet. Whatsoever the reason, a security group attached to your internal infrastructure should not be accessible from the internet. That’s a big NO. This is the equivalent of leaving the front door of your house open.
Not to mention if internet access is opened to admin ports such as SSH(22) or RDP(3389), this can pose an entry point for an attacker.
Don’t Use Excessive Security Groups
For easy manageability and awareness, one should implement such a strategy that the number of security groups in a VPC are minimum but at the same time, be able to suffice the infrastructure requirements.
One should also remove any unused security groups from the account because the team responsible for managing org infra might not have an up to date awareness of the rules and if attached to any resource mistakenly, can result in some brutal outcomes.
Restrict Access
In the beginning we talked about how the security groups are permissive in nature.
Another way to look at it is these, by default, deny traffic. We just have to add the sources/destinations that we need to ALLOW.
Taking this to our advantage, we should always only grant fine grained access, just like for any other cloud resource. This includes every field present in configuring a security group, even the CIDR block prefix.
NACLs vs Security Groups
There is often a discussion around when to use NACLs as opposed to security groups. Before getting into that, let’s look at what NACLs are in the first place.
A NACL (or Network Access Control List) is a stateful network control that allow administrators to control outbound traffic from a network. This is especially useful in data sensitive environments where outbound network calls need to be restricted.
Let’s now compare a NACL to a Security Group.
Stateful vs Stateless: Security groups are stateful, which means that a rule designed to allow traffic at a port from some source will also enable outgoing traffic from the same port to the same sources as the destination. However, NACLs on the other hand are stateless, which would mean that a rule designed to allow outbound traffic will not allow inbound traffic implicitly.
Applicability: Security groups can be applied to a variety of AWS resources like we mentioned earlier, such as EC2 instances, databases etc; whereas NACLs are applied to entire subnets.
Type of Rules: Security groups support only inbound rules, whereas NACLs support both inbound and outbound rules.
Cy5 and Security Groups
Cy5’s cloud native security products help customers to assessing their usage of security groups. It various checks to flag issues like we discussed earlier under best practices. All this, automatically and continuously.
Here are some checks that you could expect out of the box:
Or you could quickly analyse impact by using the search functionality:
Head over to our cloud security posture management product offering to explore this further.