Lab 5 (Optional): Ingress Traffic Inspection - DIY

The is a Do It Yourself (DIY) lab. It allows you create and configure required constructs using the knowledge that you have gained thus far in this workshop. Recommended hints are based off 5-tuple stateful rule group options and not customizing or building your own Suricata.

Overview:

A given network architecture can be segmented into multiple zones. Resources deemed more risky like your Internet facing load balancers are placed in an untrusted zone or public subnet. Resource such as your applications, which you don’t want to be directly discovered from Internet, are placed in trusted zone or private subnet. Lack of inter-zone traffic inspection can pose a serious threat to resources in private subnet.

In this lab, you will create architecture that allows you to inspect ingress traffic between an Application Load Balancer (ALB) configured in a public subnet and its target configured in a private subnet.

If you are running this module at an AWS hosted event like re:Invent, resources depicted in Figure 1: ALB Based Architecture are already provisioned for you. If you are running this module on your own using your own AWS account, you can visit deploy resources to deploy resources depicted in Figure 1: ALB based architecture using AWS CloudFormation.

lab5_figure1

Figure 1: ALB Based Architecture

As shown below in Figure 2: Expected Architecture, the objective of this DIY Lab is to inspect traffic between Internet facing Application Load Balancer (ALB) located in public subnet and it’s targets (App Instances) located in private subnet.

lab5_figure2

Figure 2: Expected Architecture

Steps:

Step 1: Validate the setup.

Verify you can access sample web service hosted behind an ALB. Use either a web browser or curl command from your terminal to access ALB’s Fully Qualified Domain Name (FQDN).

You can click on Locate Your ALB to retrieve the DNS name

lab5_figure3

Figure 2: ALB Details

% curl http://DIYLab5-ExternalAlb-112362531.us-west-2.elb.amazonaws.com/
<html>
  <head>
    <title>Test Web Server</title>
    <meta http-equiv='Content-Type' content='text/html; charset=ISO-8859-1'>
  </head>
  <body>
    <h1>Welcome to POC:</h1>
    <h2>This is a simple web server running in "us-west-2a". Happy Testing!</h2>
  </body>
</html>

Step 2: Create Firewall RuleGroup

In this step you will create Firewall RuleGroup that allows HTTP traffic and alerts by logging it to CloudWatch Logs.

POINTER: For guidance on how to create firewall rulegroup, refer to Create Firewall RuleGroup.

Step 3: Create Firewall Policy:

In this step you will create Firewall Policy to filter network traffic. Associate Firewall RuleGroup created in Step 2 with this Firewall Policy.

POINTER: For guidance on how to create firewall policy, refer to Create Firewall Policy

Step 4: Create Firewall:

In this step you will create firewall to inspect/filter your network traffic. Firewall connects the inspection rules in the firewall policy to the VPC that the rules protect.

Helper: When you create AWS Network Firewall, you need to provide subnets. Network firewall service creates corresponding firewall endpoints in these subnets. For your architectures to function properly, you should dedicate separate subnets for AWS Network Firewall.

POINTER: For guidance on how to create network firewall, refer to Create Firewall

Step 5: Route traffic transparently to Firewall:

In this step you will edit route tables to route ingress traffic between ALB and its targets to Firewall configured in step 4 for inspection.

Click **here** to reveal a hint.
HINT - Once you have added/edited appropriate routes to appropriate route tables, your final topoloy will look like Figure 3: ALB Based Igress Inspection Architecture

lab5_figure3

Figure 3: ALB Based Igress Inspection Architecture

Step 6: Validation

Verify:

  • You are still able to access simple web service hosted behind ALB using ALB’s FQDN
  • Traffic is being inspected and allowed by Firewall and being logged to CloudWatch Log

POINTER: For guidance on how to validate traffic is being logged to CloudWatch Logs, refer to Step 6 - Verify Alert Logs Captures in CloudWatch