Security Groups
Security Groups are virtual, stateful firewalls attached to an instance or network interface. Both inbound and outbound rules can be defined to allow specific protocols, ports and source/destination CIDR. A DENY is not possible with security groups.
With Security Groups, all rules are evaluated before a network packet is allowed or blocked, unlike Network ACLs where the rules are evaluated in order of rule number and once a rule matches subsequent rules are not evaluated.
In this exercise, we will modify the security group attached to VPC A Private AZ1 Server
to allow only ICMP traffic inbound from VPC C's CIDR only. We will verify that the EC2 instance in VPC C is able to ping the EC2 instance in VPC A, but that the EC2 instance in VPC B is not able to ping the same EC2 instance in VPC A.
Important
It is NOT best practice to have open Security Groups that allow everything (0.0.0.0/0).
Limit access to what is required.
Modifying the Security Group in VPC A
- In the EC2 Dashboard click on Instances
- In the EC2 instance list, select the check box for
VPC A Private AZ1 Server
- Scroll down to the Security tab and click on the Security Group link named something like
sg-xxxxxxx (VPC A Security Group)
- In the Security Group page, click on the Inbound rules tab, and then click on Edit inbound rules button
- In the Edit inbound rules page, update the rule that is currently allowing ICMP from 0.0.0.0/0 to allow only from VPC C's CIDR
10.2.0.0/16
- Click Save rules
Now we have modified the Security Group on the EC2 instance in VPC A allow ICMP traffic (ping traffic) only from sources in VPC C, and from nowhere else. We will now test to verify that we are NOT able to ping this instance from VPC B, and we are ABLE to ping from VPC C.
Test Connectivity from VPC B to VPC A
- In the EC2 Dashboard click on Instances
- Select the check box for
VPC B Private AZ1 Server
from the list of instances, and click Connect button
- In the ‘Connect to instance’ dialogue click Connect in the Session Manager tab. This will open up a session in a browser window.
- In the command line, try pinging the private IPv4 address of the EC2 instance in VPC A using the command
ping 10.0.1.100 -c 5
It will freeze and make no progress. This is because the Security Group on the EC2 instance in VPC A has inbound rules to only allow ICMP from VPC C. There are no rules for allowing VPC B, and an implicit DENY occurs.
Now connect to the EC2 instance in VPC C and try to ping the EC2 instance in VPC A.
Test Connectivity from VPC C to VPC A
- Terminate the Session Manager connection and click Instances
- Select the check box for
VPC C Private AZ1 Server
from the list of instances, and click Connect button - In the ‘Connect to instance’ dialog, click Connect in the Session Manager tab.
- In the command line, try pinging the private IPv4 address of the EC2 instance in VPC A using the command
ping 10.0.1.100 -c 5
The ping will succeed and traffic will flow through. This is because the Security Group on the EC2 instance in VPC A is allowing ICMP traffic from VPC C's CIDR range.
- Terminate the Session Manager connnection.
We have modified the Security Group on the EC2 instance in VPC A to allow only ICMP traffic from VPC C. We tested and verified that we cannot ping this instance from VPC B, but we are able to ping it from VPC C confirming the behavior of the Security Group.
Reverting Changes to the Security Group in VPC A
- In the EC2 Dashboard click on Instances
- In the EC2 instance list, select the check box for
VPC A Private AZ1 Server
- Scroll down to the Security tab and click on the Security Group link named something like
sg-xxxxxxx (VPC A Security Group)
- In the Security Group page, click on the Inbound rules tab, and then click on Edit inbound rules button
- In the Edit inbound rules page, update the rule that is currently allowing ICMP only from VPC C's CIDR of 10.2.0.0/16 back to
0.0.0.0/0
- Click Save rules
Congratulations you have completed this section on Security Groups