Skip to main content

Security Groups and Network ACLs

Hands-On Lab

 

Photo of Christophe Limpalair

Christophe Limpalair

VP of Growth in Marketing

Length

00:45:00

Difficulty

Intermediate

Security Groups and Network ACLs are the foundation of security in any AWS environment. Understanding the differences between them and the use cases for which they are best suited is crucial to ensuring your environment is as secure as possible to prevent attackers and other malicious actors from compromising your information. In this lab, you will walk through the differences between Security Groups and NACLs. You will also see how these two protective mechanisms are configured.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Security Groups and Network ACLs

Introduction

The accompanying lab video covers more details about Security Groups and Network Access Control Lists (ACLs) than you will find in this written guide. You should watch the video for extra insights, but this written portion focuses on the steps necessary to complete the lab.

Put simply, Security Groups and Network ACLs are both firewalls that allow us to restrict or allow access to different parts of a VPC network. There are several aspects that are unique to each, most notably, where they lie in the network. Security Groups are associated to instances while Network ACLs are associated to subnets.

The Lab Environment

The lab environment has been pre-configured with an EC2 Instance that hosts an example web page that we need to be able to access via its public DNS name in our browser (via HTTP on port 80). We also need to ensure the instance is accessible with SSH. The instance resides inside of a public subnet that was created for us. It is also associated to a pre-configured Security Group and Network ACL.

Concise view of the goals for this lab:

  • Goal - We need our instance to be accessible with HTTP and SSH.
  • Problem - The existing Security Group and Network ACL have been configured incorrectly and both HTTP and SSH are not working. Confirm for yourself if you'd like. Copy/paste the Public DNS of the instance into your browser and try logging into SSH with ssh cloud_user@<paste-the-public-dns>.
  • Solution - We will troubleshoot and modify the Security Group and Network ACL settings so that everything functions as required.

Troubleshooting HTTP

We will first check the settings of the Network ACL since it is the "first destination" for traffic inbound for the instance.

  • Navigate to the VPC Dashboard and click the Network ACLs link on the left.
  • Since HTTP isn't working, check out the Inbound Rules that apply to the HTTP type.

Notice there are both ALLOW and DENY rules for HTTP. These rules are applied in order of their Rule #. Since the number of the DENY is lower than the ALLOW, we know that HTTP is not being allowed to pass through. We could technically fix this by changing the rule numbers such that the ALLOW comes before the deny, but the best solution is to remove the DENY rule (since the later rule could never be applied). .

  • Click the Edit button and delete the rule that is DENYing HTTP.
  • Save the changes.
  • Copy/paste the public DNS of the instance into a new tab to see if HTTP is working now. (Find the Public DNS of the instance from the EC2 Dashboard in the Instances section.)

You will now see the example page being hosted by the instance.

Troubleshooting SSH

Now consider SSH, which is also broken. Notice the last rule in the list. Its rule number (*) is considered larger than any other number, therefore denying any inbound traffic that isn't explicitly allowed. If we want SSH to make it to the instance, we must add an inbound rule to allow it.

  • Click the Edit button and add a new rule:
    • Type: SSH
    • Source: 0.0.0.0/0 (this is the CIDR block for any/all IPs)
  • Save the changes.
  • Try to connect with SSH. Copy the public DNS of the instance from the EC2 Dashboard and run this command in Terminal: ssh cloud_user@<paste-the-public-dns>

Unfortunately, it will fail to connect. In practice, we would need to ensure our Outbound Rules are configured correctly (since Network ACLs are stateless), but we can assume they are correct for this lab in particular. We now know that our Network ACL has been configured properly for SSH, but we need to check the Security Group configuration since SSH still doesn't work.

  • In the VPC Management Console, navigate to the Security Groups section.
  • Click on the Security Group to view it's properties and navigate to the Inbound Rules tab.

(Notice the HTTP rule. The change we made that fixed HTTP only worked because the Security Group was already configured for it.)

There is no inbound rule for SSH, hence the broken behavior.

  • Add a new Inbound Rule:
    • Type: SSH
    • Source: 0.0.0.0/0 (Notice that we can add security groups as the source, not only an IP range)
  • Save the changes.

Since Security Groups are stateless, we know that return traffic for SSH will be allowed automatically. Now that we have ensured that both the Network ACL and Security Group have been configured to allow SSH, we can try to connect again.

  • Open Terminal and re-run the SSH command: ssh cloud_user@<instance-public-hostname>
  • Type yes to accept the fingerprint.
  • Use the password 123456 to confirm that you are able to log in successfully.

Conclusion

We have troubleshooted and corrected the Security Group and Network ACL configurations to allow HTTP and SSH. If you are now able to access the example web page and connect to the instance with SSH, you have successfully completed the lab.