Security groups provide stateful firewall capabilities for both internet-facing and internal traffic. Use them to control internal network communication, isolate subnets, and manage Layer 4 network access.
Security risks
Full network connectivity between all Elastic Compute Service (ECS) instances within the same virtual private cloud (VPC) creates security risks, such as lateral movement and unauthorized access. For example, if an ECS instance on the internal network is compromised or infected with a virus, the threat can spread to other instances on the same network. Additionally, services on internal networks often have weak authentication and authorization, which makes them easy targets for unauthorized access from within the network.
Using security groups to isolate different service clusters or block lateral network access between instances can effectively mitigate the risks of internal lateral movement and unauthorized access.
Best practices
Isolate different service clusters with security groups
Imagine you have two ECS instance clusters: a database cluster and a web server cluster. The instances in the database cluster need to communicate with each other, but the instances in the web server cluster do not. The objective is to allow the web server cluster to access only the service ports of the database cluster.
Assume the IP address range for the database cluster is 10.1.0.0/24, and the range for the web server cluster is 10.2.0.0/24. The service port is 5432, which is the default for PostgreSQL. The security goal is to allow the web server cluster to access only the service port of the database cluster. All other access, including access to other ports or from the database cluster to the web server cluster, must be denied. A possible security group configuration is as follows:
Create Security Group A. Add an inbound rule to allow traffic from source 10.2.0.0/24 to destination port 5432, with a priority of 1. Attach the database cluster instances to Security Group A.
Create Security Group B. Attach the web server cluster instances to Security Group B.
Note: By default, a security group denies all inbound traffic that is not explicitly allowed and allows all outbound traffic that is not explicitly denied. Therefore, you do not need to add a rule to Security Group A to deny other access. You also do not need to add a rule to Security Group B to allow access to the service ports of the web server cluster.
You can use tags to attach multiple ECS instances with a specific tag to a security group that has the same tag. For example, you can add the tag cluster:PostgreSQL to all ECS instances in the database cluster. Then, add the same tag to Security Group A. Next, run the ACS-ECS-CorrectSecurityGroupInstancesByTags OOS template and enter the tag value as a parameter. This attaches the instances to the security group in a batch operation. For more information, see Use tags to find ECS instances and add them to a security group with the same tag.
Isolate ECS instances within a single security group
In the previous example, the instances in the web server cluster do not need to communicate with each other. The database cluster requires only a few ports to be open for synchronization and management. Therefore, there is no need to allow all internal communication within the group. This practice prevents a threat from spreading laterally from a compromised ECS instance.
You can use micro-segmentation to achieve this. With micro-segmentation, instances within a security group cannot communicate with each other by default. You must explicitly allow communication on specific ports.
You can use an enterprise security group. Enterprise security groups enforce mandatory internal isolation. The isolation rule cannot be modified.
You can also use a basic security group. By default, instances within a basic security group can communicate with each other. This is because the system automatically adds a hidden, high-priority rule to allow internal traffic. Custom rules only apply to traffic from outside the group. You must explicitly deny internal communication. On the security group details page, change the internal access policy to Internal Isolation, as shown in the following figure.
Then, you must explicitly allow traffic on internal communication ports. For example, for the database cluster in the 10.1.0.0/24 address range, internal communication requires port 2379. You can add a rule to Security Group A to allow inbound traffic from source 10.1.0.0/24 to destination port 2379 with a priority of 1.
Note: If an ECS instance is attached to multiple security groups, and one group allows internal traffic while another isolates it, the combined effect is to allow internal traffic.
Note the combined effect when using multiple security groups
An instance can be attached to multiple security groups. The rules from all groups are combined and applied based on priority. To avoid unexpected results, review the final combined rules. You can find these rules on the security group page for the specific instance.
Compliance
Check for overly permissive network access rules
You can use VPC flow logs to analyze communication patterns within your cluster. This helps you identify overly permissive security group rules and tighten your security group permissions.