AWS Cloud Automation Quickstart – Securing a Network Access Control List (NACL)

In the first part of this series on deploying a web server in AWS we created a Tuono Blueprint that provisioned a VPC with secure Network Access Control Lists (NACL) and manually created a VPC through the AWS console that left our network-wide open to all traffic.

This post will look at securing that VPC with a custom NACL in the AWS console and only open the specific required ports for our web server. In parallel, with a few edits to our original Tuono Blueprint, we will create an inbound rule for ssh (port 22) and HTTP (port 80) on the secure subnet that we already created.

How to secure a VPC with a default Network Access Control List

If you recall from the first part, we discussed how Tuono follows a Secure by Default model and created extra NACLs in order to only allow what you want to let into our network. Well, the AWS console wizard automatically created VPC defaults that allow all traffic inbound and outbound from all networks! Let’s fix that!

Navigate to the VPC dashboard and select “Network ACLs” under “Security.” Select the default NACL associated with our manually created VPC. Here, you can see the default ALLOW rule to All traffic.

Let’s get that locked down by creating a custom NACL by clicking “Create network ACL”. Provide the NACL with a name and be sure to select the VPC we created then click “Create”.

The new NACL is actually created with a deny all traffic policy both inbound and outbound. Next, we need to customize our policy to only allow what we need. Click “Edit inbound rules” from the Inbound Rules tab.

We are going to add the following rules and open ephemeral ports that allow inbound TCP response traffic to flow from our VPC network. Once the rules are added click “Save”. This sets us up for a much more secure subnet by only allowing the minimum required inbound ports for our web server.

You can reference this table with the ports we added to the VPC NACL. The rules are evaluated in order from lowest to highest, so the order will determine what traffic flows to the associated subnet. Note that the Allow All traffic rule is only from the Source of our VPC defined network range.

Network ACL Inbound Rules

Now, when we audit our inbound rules for our subnet NACL we can verify that we are only allowing required traffic into any Instances we are going to create in this subnet.

Next, navigate to the Outbound Rules tab and click “Edit outbound rules”. We are not going to worry about locking down outbound traffic from our Instances in this subnet so let’s create a rule 100 that allows all outbound.

An audit of our Outbound rules shows we are now allowing all traffic out.

The next step is to associate our new secure NACL with our subnet. On the Subnet associations tab click “Edit subnet associations”.

Creating custom NACLs allows you to associate customized security policies to each dedicated subnet you may create. This is recommended rather than applying an insecure default policy to all of your subnets.

Select the subnet associated with the VPC we created and click “Edit”.

We also will tag the new NACL with our Key walkthrough and Value webserver so we can track it in our Resource Group.

Our resource group, with our manually created resources, now contains the following.

Tuono provides simple fine grain control over network security

With Tuono we take steps to secure each subnet by creating a dedicated NACL for each subnet we define. This allows us to create finely tuned network security policies dedicated to the specific purpose our subnet will serve.

Customizing NACLs in the Tuono Blueprint introduces us to protocols. Protocols allow you to open up specific ports and combine them in a firewall definition. Here you can see that we define the ssh and http protocols by assigning a port and setting them to tcp.

protocol:
    ssh:
      ports:
        - port: 22
          proto: tcp
    http:
      ports:
        - port: 80
          proto: tcp

We define a Blueprint firewall using the ssh and HTTP protocol we configure above.

firewall:
    fw-external-access:
      rules:
        - protocols: ssh
          to: self
        - protocols: http
          to: self

The existing subnet NACL is modified with firewall: fw-external-access that we defined to allow ssh and HTTP.

subnet:
    subnet-walkthrough:
      range: 10.0.0.0/24
      network: vnet-walkthrough
      firewall: fw-external-access 
      scope: public

There are no additional objects created with this updated blueprint from part 1 but we do modify the subnet ACL to allow the required ports for our web server and block everything else.

Our complete Blueprint currently looks like the following and forms a ground work of communication and security for the next part in the series where we will be deploying an NGINX web server. Applying this Blueprint will setup the defined VPC and associated objects with secure network access.

#
# This is an example blueprint that demonstrates opening ports to a subnet
#
---
location:
  region:
    my-region:
      country: USA
      area: northwest
  folder:
    aws-walkthrough:
      region: my-region

networking:
  network:
    vnet-walkthrough:
      range: 10.0.0.0/16
      scope: public

  subnet:
    subnet-walkthrough:
      range: 10.0.0.0/24
      network: vnet-walkthrough
      firewall: fw-external-access  # Part 2 adds a Firewall to the subnet and marks it public
      scope: public

# Part 2 Protocols
  protocol:
    ssh:
      ports:
        - port: 22
          proto: tcp
    http:
      ports:
        - port: 80
          proto: tcp
          
# Part 2 adds a Firewall using a protocol
  firewall:
    fw-external-access:
      rules:
        - protocols: ssh
          to: self
        - protocols: http
          to: self

All of the Tuono code samples in this post can be used for free in the Community Edition of the Tuono platform.