Desktop and Application Streaming

Filtering internet traffic from Amazon WorkSpaces

Introduction

Amazon WorkSpaces is a fully managed Desktop as a Service (DaaS) that prioritizes security and simplicity. Customers can secure their Amazon WorkSpaces deployments through a variety of means. Security groups and network access control lists are available on a customer’s Virtual Private Cloud (VPC). The Amazon WorkSpaces service side has RADIUS multi-factor authentication, trusted devices, and IP access control groups.

When migrating to Amazon WorkSpaces, customers often want to extend network security controls to prevent known risks. For example, to enable domain name filtering for in-session web browsing mitigating malware. Before the introduction of AWS Network Firewall, customers did this in one of two methods. One method was to route Internet-bound traffic to their on-premises firewalls for inspection. Alternatively, customers used an equivalent firewall service on the AWS Marketplace. These methods can add complexity, and time, to complete a WorkSpaces launch. Customers continually looked for simplified ways to bring this type of filtering and inspection natively to AWS Cloud. Customers want to remove the need for routing that is unoptimized, and reduce licensing cost.

AWS Network Firewall extends protection beyond SG- and NACL-levels by protecting at the route level and offering stateless and stateful rules from layers 3 through 7 in the OSI Model. It uses the certificate fully qualified domain name (FQDN) or Server Name Indication (SNI) to determine if a website is allowed for HTTPS traffic. This is a commonly requested security requirement. Reviewing these design examples of AWS Network Firewall will accelerate your migration to Amazon WorkSpaces. AWS Network Firewall is a managed service, with no infrastructure to manage or patch you can simplify operational excellence. Native settings for advanced filtering (including domain name), and network traffic inspection can alert and block traffic related to malware. It also has layer 7 intrusion prevent system (IPS) rules, and the ability to apply TLS fingerprinting to prevent a spoofed IP or FQDN.

Design examples

Before reviewing the options available, I encourage you to review the deployment models for AWS Network Firewall how-to. The how-to provides all the ways you can use AWS Network Firewall. In this blog, I will focus on two examples:

  1. Single VPC firewall
  2. Centralized inspection VPC firewall

The design example that is best to model for your environment is chosen by the design requirements for your Amazon WorkSpaces deployment.

Single VPC Firewall

In this design, the Amazon WorkSpaces deployment is confined to a single VPC. The VPC consists of a total of six subnets: two in each Availability Zone (AZ) for high availability (HA), four public and two private. NAT Gateways are in the public subnets to connect Amazon WorkSpaces in private subnets to the public internet. The private subnets are the Amazon WorkSpaces deployment. The AWS Network Firewall is used to specify and block FQDNs that must not be accessible from Amazon WorkSpaces. The AWS Network Firewall also prevents malware, and other protocols that are not approved by the organization.

To achieve this, create two additional public subnets. Then, make the following changes:

  1. Deploy AWS Network Firewall endpoints into the new public subnets.
  2. Create a route table and assign it to the VPC’s internet gateway. Specify the return traffic destinations for the original public subnets with targets for the firewall endpoints.
  3. Update to the original public subnets route tables, specifically by changing the default route target from the internet gateway to the firewall endpoints.

Figure 1: Due to Amazon VPC-specific routes for the internet gateway to return network traffic, route associations for the edge must be defined for firewall endpoints.

Centralized inspection VPC firewall

This design accommodates multiple VPC and Amazon WorkSpaces deployments. It supports future growth requirements for other AWS services including Amazon AppStream 2.0. AppStream 2.0 can benefit from AWS Network Firewall in the same manner as Amazon WorkSpaces. You can centrally manage configurations for inter-VPC packet inspection, and specifying and blocking FQDNs. Regardless of the number of VPCs your organization, with AWS Network Firewall you provision a single set of endpoints and NAT Gateways. This reduces costs. This design is only supported through Transit Gateway (TGW). This design requires no changes to the internet gateway.

To achieve this, make the following changes:

  1. Create a VPC with four private subnets, across two Availability Zones. This VPC is created for traffic inspection.
    Note: If your Amazon WorkSpaces deployment consists of multiple directories spanning more than two Availability Zones, create more matching Availability Zone private subnets for traffic inspection. Use the smallest possible IP range for these subnets (for example, /28).
  2. Create subnet-assigned route tables for all VPCs (except traffic inspection VPC) that specify default route to the TGW.
  3. Deploy firewall endpoints into two (or more) traffic inspection firewall subnets.
  4. Configure the TGW VPC attachment for the remaining two (or more) traffic inspection VPC TGW VPC attachment subnets.
  5. Create subnet-assigned route tables for traffic inspection VPC with TGW VPC attachment subnets. Specify the default route with targets for the firewall endpoints. The AWS Network Firewall subnets must specify default route with targets for TGW.
  6. Create TGW route table. Assign the route table to all non-traffic inspection VPCs specifying default route with target for traffic inspection VPC attachment. This forces all inter-VPC traffic to be inspected by AWS Network Firewall.
  7. Create TGW route table and assign it to traffic inspection VPC. Specify routes for every VPC, and default route with target to the outbound internet VPC.

Figure 2: Routing at the subnet always sends network traffic for inspection for most functions. Once AWS Network Firewall has performed inspection, the route table attached to the Transit Gateway attachment will route to the appropriate destination unless denied.

For a deeper understanding of routing requirements, review the blog for centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway.

Building your firewall

Begin by navigating to VPC in the AWS Management Console.

Step 1: Create your first rule groups

  1. Choose AWS Network Firewall -> ‘Network firewall rule groups’ on the left side of the console.
  2. Choose Create Network Firewall rule group.
  3. Choose Stateless rule group.
  4. Provide a meaningful name for the stateless rule group, a description, and a capacity.
  5. For the protocol, select only TCP, and source and destination being any IPv4 and port for this example. (Note: If you have a more specific example you want to try, feel free to use that.)
  6. Keep the optional settings blank. For Action, select Forward to stateful rule groups, then choose Add rule.
  7. Choose Create stateless rule group.
  8. Return to create a rule group and choose Stateful rule group.
  9. Specify a name for ‘workspaces-block-domains-stateful’ and specify the stateful rule group Domain list.
  10. Enter the list of domain names, separated by the return key, with the action Deny and choose Create stateful rule group.

Step 2: Create your firewall policy

  1. With both rule groups created, choose AWS Network Firewall -> ‘Firewall policies’ on the left side of the console.
  2. Choose Create firewall policy.
  3. Enter a name that is meaningful such as ‘amazon-workspaces-policy’ and enter a description, then choose Next.
  4. Before any other settings being configured, a stateless rule group must be configured. Choose Add rule groups.
  5. Select the stateless rule group, and click Add rule groups.
  6. In Stateless default actions, select Use different actions for full packets and fragmented packets and the default action for both Forward to stateful rule groups.
  7. Choose Add rule groups to add the stateful rule.
  8. Select the stateful rule group previously created and choose Add rule group.
  9. Choose Next and then Next again.
  10. Review the settings and click Create firewall policy.

Centralized inspection VPC firewall consideration

If the design is for a centralized inspection VPC firewall, an additional step is required. Update the stateful rule through AWS CLI for HOME_NET to contain all VPC CIDRs that are routed to the inspection VPC. If this is not required, continue to step 3.

  1. Using the command line interface (CLI), enter the following command that includes your AWS Region.aws network-firewall describe-rule-group –-type STATEFUL –-rule-group-name workspaces-block-domains-stateful –-region [your-region]
  2. Record the values for UpdatesToken and RuleGroupArn.
  3. Create a ‘variables.json’ file using your VPC CIDRs in the ‘Definitions’. For example:
  4. {
    "RuleVariables": {
        "IPSets": {
           "HOME_NET": {
             "Definition": [
               "10.0.0.0/22",
               "10.0.4.0/22",
               "10.10.0.0/16",
               “10.64.0.0/16”
             ]
           }
        }
    },
    "RulesSource": {
        "RulesSourceList": {
           "Targets": [
               ".facebook.com",
               ".youtube.com"
           ],
           "TargetTypes": [
               "HTTP_HOST",
               "TLS_SNI"
           ],
           "GeneratedRulesType": "DENYLIST"
        }
    }
}
  5. Save ‘variables.json’ to the path where you are running the CLI commands.
  6. Using the copied values from the previous command, create the update command and execute in the CLI, example: aws network-firewall update-rule-group --rule-group-arn arn:aws:network-firewall:us-west-2:0123456789:stateful-rulegroup/block-sites --update-token fc4a0144-71d2-4cbf-8007-2871379cb925 --rule-group file://variables.json --region us-west-2

Step 3: Deploy your Firewall endpoints

  1. With your rule groups and new policy created, choose AWS Network Firewall -> ‘Firewall’ on the left side of the console.
  2. Choose Create firewall.
  3. Provide a name and description.
  4. Select the VPC, Availability Zones, and subnets that fit your design model (refer to Design Examples section of this blog).
  5. Select Associate an existing firewall policy and then select the drop-down to choose your policy.
  6. Choose Create firewall.

Costs

The AWS Network Firewall is detailed on the pricing webpage. Overall costs include:

  • AWS Network Firewall endpoints (minimum of 2) at $0.395/hour.
  • Network traffic processing at $0.065/GB.
  • Amazon NAT Gateway has no charge for each hour that the firewall endpoint is provisioned.

In the centralized insepction VPC firewall design, there is the additional cost of the AWS Transit Gateway, which is detailed on the Transit Gateway pricing webpage.

Clean up

  • Change routing tables for both subnets (and Transit Gateway if necessary) to original settings.
  • Delete AWS Network Firewall endpoints and AWS Network Firewall.

Conclusion

AWS Network Firewall provides a cloud-native solution that accelerates on-premises migrations to Amazon WorkSpaces in a secure, consistent, and hierarchical manner. As previously mentioned, the design examples are a starting point to centralized firewall management.

Simplified and centralized firewall management is important to customers that deploy many endpoints with complex configurations with multiple policies for each AWS account. Customers are using more and more of AWS Firewall Manager, with many more features yet to come. While not mentioned in this blog, it also supports AWS Web Application Firewall, AWS Shield, security groups, and DNS firewall. For guidance on automation through AWS CloudFormation, visit the documentation. There is also documentation for automation through Terraform.