Unpacking AWS Cloud NGFW

Oh Boy!! That was super insightful and interesting to unpack and discover this brand new product co-provided by AWS & Palo Alto! I guess it is mostly the case for us geeks as a new surprise or present is offered to us, no? You have this little excitement not really knowing what you are going to fall on.. You discover piece by piece the capabilities, you have the impression to be a bit a pioneer as this is so new that nobody has a lot of inputs on it. Now you know what has been my state of mind, dont't read this post after a heavy lunch 😏: this is dense & complex (I found even myself sometimes struggling structuring this blog post due to the quantity of information I wanted to include).

So guys, are you ready to discover with me the AWS Cloud NG FW, born from a partnership between AWS & Palo Alto and provided to you as a SaaS? Let's go!

Lessons learned

The first thing that stroke me (again) was the complexity of the architecture build to be in the position of starting the actual configuration of the Cloud NGFW. You might remember a recent post on AWS Network Firewall: this architecture build is quite similar. Multiple Routing Tables in the Security VPC as well as for the AWS Transit Gateway must be configured and thus, for a single AZ.

The second thing is (again as per AWS Network Firewall), the lack of proper tool for analysing the flows (other than S3 or Cloud Watch). I really think this is a big miss, especially for a Firewall..

Another thing is that FQDN Object does not behave as it should and shows that today the product is very new and not yet mature.

The least I can say is that was quite a roller coaster to achieve what I had in mind for that post and I spent far more time than I anticipated:

• When you hear new product, you have to think 'not much documentation available to explain how it works and how to set this up'

• I did not expect naively to test so many things but due to the extended capabilities of this product... (and I did not test them all!)

• This is a SaaS product but there is a clear demarc point between AWS & Palo Alto

• 2 different Web Interfaces (AWS Console + Palo Alto for Cloud NGFW specifics)

• 2 different supports (AWS Support & Palo Alto Community): I must say I don't like the Support 'Community' from Palo Alto - there is no real Support Case created (even if I subscribed Premium Support)

However, when you get over these (non negligible) obstacles, the configuration of Cloud NGFW for AWS is quite straight forward, as powerful as a NGFW can be (which is good for a SaaS product!) & the Web interface is nicely done. 

I promise you: nobody in Aviatrix asked me to make this blog post or promote our product. As a Solution Architect, I think it is a good practice to know what others do. However 😉,  you might know Aviatrix has a solution with Firenet and its seamless insertion of NG FW (and that is 3 years we are doing it):

- No matter the Public Cloud (AWS, Azure, GCP, etc..)

- No matter your NG FW vendor (Palo Alto, Checkpoint, Fortinet, even 'BYOL' (Bring Your Own License (ie appliance))

What is AWS Cloud NGFW?

Cloud NGFW for AWS is Palo Alto network managed service offering Next-Generation Firewall Software along with its infrastructure to secure your AWS workloads. It is considered as a SaaS (Software as a Service): there is no need to make Software updates for example.

What about AWS Cloud NGFW with other vendors?

Today, this partnership is only with Palo Alto. There is no other AWS Cloud NGFW SaaS with another vendor.

What about this type of service with another Public Cloud?

Only AWS provides this SaaS managed service.

However Azure provides in Preview a similar solution with Checkpoint in vWAN.

What are the functionalities of AWS Cloud NG FW?

• Palo Alto Cloud NGFW for AWS offers all the advanced functionalities a NG FW can bring (Deep Packet Inspection) meaning simple packet filtering, URL filtering based on URL categories & geolocations, SSL/TLS decryption, Threat prevention & App-id to secure connections & reduce vulnerabilities, while shifting the operational responsibility (deployment, maintenance, availability & scale) to Palo Alto. 

• Subnet level inspection is possible (meaning SubnetA can be protected from SubnetB with the same VPC. But this justifies a Distributed deployment model only with NGFW endpoint being within that VPC (multiple Route Tables needed)

AWS Network Firewall vs AWS Cloud NGFW

You might remember my post on AWS Network Firewall.

• Similarities

• Similar complex architectures types with endpoints (Central & Distributed architectures)

• Same visualization of Logs with S3, Cloud Watch and Firehose

• Packet filtering & Domain Name filtering

• Differences

•  AWS Network Firewall is configured through AWS Console whereas AWS Cloud NGFW is configured through Palo Alto specific Web Interface

• AWS Cloud NGFW is a FW with real advanced Cyber Threat & Deep Packet Inspection (DPI) capabilities like IPS Vulnerability, Anti Spyware, Antivirus, File Blocking & URL Categories filtering

• It is possible on Logs like Cloud Watch for example to see easily if the packet processed has been allowed or blocked & which rule has processed the packet. (which is a big difference compared to AWS Network Firewall)

• Some architectures though are less complex to build, like Internet Egress as a dedicated Egress VPC is not needed (NATGW & FW endpoints are located in the same Security VPC but in different subnets)

The bottom line is that if I had to pick up among these 2, this is a no brainer - AWS Cloud NGFW is 2 heads above - architecture, capabilities & Logs

Components

• Cloud NGFW Tenant is an instantiation of Cloud NGFW service associated with your AWS account when 1 of your AWS users subscribes to the service. Cloud NGFW designates you, the subscribing AWS user, as the admin. of Cloud NGFW tenant (TenantAdmin user role), who can invite other users to the tenant. Based on the assigned role, other users can create Cloud NGFW resources & configure rulestacks with the tenant.

• Cloud NGFW is a Firewall resource which is associated with your VPC & can span multiple AZs. This resource provides NGFW capabilities & has built-in resiliency, scalability & life cycle management.

• To use Cloud NGFW resource, you create a dedicated subnet in your VPC for each AZ, then create NGFW endpoints on the subnets & update the VPC route tables to send traffic through these Cloud NGFW endpoints. NGFW endpoints are responsible for directing traffic to the NGFW for inspection & enforcement (there are 2 ways to configure these endpoints. Either service-managed mode where Cloud NGFW Tenant creates automatically an endpoint in each subnet you specify or customer-managed mode where you have to manually create these endpoints towards AWS Console)

• Rulestacks define the NGFW traffic filtering behaviour (App-id, URL filtering & Threat prevention). A rulestack includes a set of security rules, the associated objects & security profiles. To use a rulestack, you associate it with NGFW resource(s). A Cloud NGFW resource uses the rulestack definition to protect the traffic by a 2-step process (1. First, it enforces the rule by allowing or denying the traffic & 2. Then, it performs Content inspection on the allowed traffic based on what is specified on the Security profiles. Cloud NGFW provides 2 types of rulestacks:
• Local Rulestack: local account admin. can associate a local rulestack with an NGFW in their AWS account. A local rulestack includes local rules.
• Global Rulestack: the AWS FW manager admin. can author a Firewall Manager Service (FMS) policy & associate a Global rulestack with it. AWS FW Manager manages Global rulestacks across all NGFWs in different AWS accounts of a AWS Organization (OU). A global rulestack includes pre-rules (rules added on the top of the rule order & evaluated first) & post-rules (rules added at the bottom of the rule order & evaluated after pre-rules & rules of a localrulestack). This is less granular than the console for Cloud NGFW. [AWS recommends to use AWS FW Manager for the distributed deployment model with multiple VPCs / accounts & the Cloud NGFW console for the centralized models]

NOTE: AWS Firewall Manager can be used only if  the AWS FW Manager administrator account is part of an AWS Organization. This is not my case & as we will test more the Centralized deployment models than Distributed, AWS Firewall Manager will not be tested.

Please see this link if you are interested.

Zoom on Rulestack

NOTE: Local Rulestack only as I will deploy Centralized models. As already explained, the Rulestack is made with Objects, Rules & Security Profiles.

Objects

• Prefix Lists allow you to group specific sources & destinations IP@ requiring the same policy enforcement

• FQDN Lists allow you to group specific destinations FQDNs requiring the same policy enforcement

• Custom URL category allows you to specify exceptions to a URL category enforcement and to create a custom URL category based on multiple existing categories

Wildcards examples (many more possibilities than below)

    '*.google.com' matches www.google.com & www.google.com.uk (if it existed :-) )

    '*.google.com/' matches www.google.com but not www.google.com.uk

    'mail.google.*' matches mail.google.com & mail.google.co.uk

• Intelligent feed (also called external dynamic list: EDL) is an ongoing stream of data related to potential or current threats to you. It records & tracks IP@ & URL's associated with threats such as phishing, scams, malware, bots, spyware, ransomware, etc.. There are built-in intelligent feeds.

• Certificate is a reference to a TLS certificate stored in AWS Secret Manager

Rules

• General

• Priority: the lower the number is, the highest priority the rule has

• 'Enabled' means that this rule will be processed

• Source & Destination

• Source can be Any, CIDR, Countries, Feeds or Prefix List

• Destination can be Any, CIDR, Countries, Feeds, Prefix List or FQDN

• Granular control can be App-ID, URL category or Protocol / Port

• Action can be Allow, Deny or Reset

• Logging must be enabled if there is a need to visualize the logs in S3, Firehose or Cloud Watch

Security Profiles

Cloud NGFW has the capability of performing content inspection on the allowed traffic based on what you specify on the Security Profiles. Additionally, it helps you define how Cloud NGFW should scan the allowed traffic & blocks threats like viruses, malware, spyware & DDoS attacks.

• IPS Vulnerability is enabled by default. It is based on a Vulnerability Signature Database with categories like brute force, dos, phishing, sql-injection, etc...

• Anti-Spyware is enabled by default. It is based on a Spyware Signature Database with categories like backdoor, botnet, cryptominer, spyware, fraud, etc...

• Anti Virus is enabled by default. It is based on a Anti virus Signature Data base with categories like linux, office, etc...

• File Blocking (if you want to block specific file type) is enabled by default & set to Palo Alto best Practice. However, you can customize it & choose the action that needs to be applied (Alert or Block). 

• URL Categories & Filtering is a Security Profile disabled by default. When enabled, it provides you the capability to monitor & control how users access Internet based on different categories:

• Risk: high/medium/low

• Threat: Malware, Hacking, Phishing, etc..

• Suspicious: proxy avoidance, insufficient content, etc...

• Legal/Policy: drugs, adult, gaming, dating, auctions, gambling, religion, etc...

Pricing

Deployment models

There are different deployment models for AWS Cloud NG FW: Centralized & Distributed. These 2 models are for any kind of traffic patterns: East/West, ie VPC to VPC; Inbound Internet & Outbound Internet.

To stick to what Aviatrix does (ie Transit Firenet), I will configure & test Centralized model for E/W & Outbound.

NOTE: if you want to know more about the different deployment models for any traffic pattern, please use this link.

High Level Steps for Cloud NGFW configuration

AWS Cloud NGFW configuration is a 3-step process:

• AWS Cloud NGFW subscription, login & AWS account onboarding

• Configure Rule Stack: Objects, Rules & Security profiles

• Configure NGFW & NGFW endpoints

AWS Cloud NGFW Subscription, First Login & AWS account onboarding

1. Subscribe to Cloud NGFW in AWS Marketplace

You are then redirected to Palo Alto website.

Enter your information as above.

Check your email, click on Verify.

TIP: Don't miss to click on 'Verify' as highlighted above otherwise you will be in trouble connecting PAN interface. And password reset procedure will not work. I lost 1 full day because of this :😅

Fill in the fields as below.

NOTE: You will receive a second email where you have to 'activate' your new Palo Alto account.

2. Add AWS Account to Cloud NGFW

Launch the Cloud Formation Template.

The CF Template will send the logs to a Cloud Watch Group with default name 'PaloAltoCloudNGFW'. Therefore you have to create a Log Group in AWS Cloud Watch with that name. You also can modify the Log Group name if you want.

NOTE: I use Cloud Watch but Logs can also be sent to S3 or Firehose.

It redirects you to AWS Console: just click 'ok' at the end.

The Cloud Formation stack is created.

Then when you go to PAN Website, you can see the AWS onboarding is a success.

NOTE: Don't think Steps 1 & 2 are a walk in a park.... Because it's not!!!... I opened 2 AWS cases to be there...

The Tenant is finally created. [all IDs are of course incomplete]

What are we going to test?

• Centralized deployment model for East / West traffic

• Ping between Spoke A & Spoke B using Prefix List (Object) & App-id (finer granularity) when it is allowed

• Ping between Spoke A & Spoke B using Prefix List (Object) & App-id (finer granularity) when it is blocked

• Test Log4J attack between Spoke A & Spoke B & see if this is blocked with Security Profiles

• Centralized deployment model for Internet Egress traffic

• HTTP request to websites using FQDN List

• Test Intelligent feed to see if a malicious IP is blocked

• Test URL Category / Custom URL Category to allow or deny web site access from our VPC

Centralized deployment model for East/West

Flow

1. Instance in VPC A sends traffic to Instance in VPC B towards its VPC Route Table

2. VPC A send the request to AWS TGW to its Spoke RT towards TGW-VPCA attachment between Spoke A VPC and AWS TGW.

3. AWS TGW sends the request to Security VPC towards the TGW - Security VPC attachment (thanks its default route)

4. The request is forwarded to NGFW endpoint towards VPC RT 'TGW' (with the default route). It is then forwarded to the Cloud NGFW Tenant for Inspection & back to the endpoint - Security VPC (in Firewall RT).

5. If traffic is allowed, it is sent to TGW RT Security towards TGW - Security VPC attachment (with default route in VPC Security Firewall RT)

6. The traffic is then sent to VPC B towards the TGW - VPC B attachment.

7. The traffic finally arrives @destination (Instance in VPC B).

Architecture Build

1. Create VPCs A & B with their 2 associated subnets as described above in the diagram

2. Create Security VPC with its 2 associated subnets. Create 2 VPC Routing Tables for that VPC as shown above ('TGW' & 'Firewall').

3. Create AWS TGW

4. Create the 3 TGW - VPC attachments

5. Create the 2 TGW Routing Tables as described above (Spoke & Security)

6. Add explicit route towards TGW for VPC Route tables for Spoke VPCs A & B (as above diagram)

7. In Spoke TGW Routing Table, create a default route towards the Security attachment

8. In Security TGW Routing Table, create static routes to Spoke VPCs A & B towards their respective Spoke attachments.

9. Associate the TGW-VPC attachments to their respecting TGW Routing Tables:

    - Spoke VPC A & B attachments to TGW RT Spoke

    - Security VPC attachment to TGW RT Security

NOTE: The TGW attachments are associated by default to the default TGW RT. A 'disassociation' with the default TGW RT must be made first.

10. Do explicit subnet associations to their respective VPC RT (only for the RT in the Security VPC where there are multiple RT).

11. Add default route towards TGW for VPC FW RT

AWS Cloud NGFW configuration

1. Rulestack creation (choose 'local' rulestack & call it 'EastWest')

Fill in the fields as below and Save.

2. Creation of the Prefix Lists for Spoke A & Spoke B VPCs (Objects)

3. Creation of the Rule allowing ICMP between Spoke A & Spoke B EC2 instance using App-id

NOTE: Protocols & Ports in 'Granular Control' can only be TCP or UDP based protocols. That is why App-id (which is even more precise than protocol/port) is used in our case for ping.

• Rule Priority is 10 (for the purpose of the second Test)

• Only Prefix List 'Spoke A' has been specified as the source & 'Any' as Destination (for the purpose of the second test also)

• App-ID 'ping' is specified

• Action 'Allow' is specified to allow ICMP between Spoke A & Spoke B

• Logging is enabled to send Logs to Cloud Watch default Log Group

4. Deploy the configuration (even if no FW associated yet)

5. Commit

6. Firewall resource creation

• Name

• Select AWS Account id

• Select the VPC where the Firewall endpoints will be located (in our case, Security VPC)

• Select the Rulestack previously created

• Select automatic creation of the NGFW endpoints

• Select the subnet where NGFW endpoint(s) will be located (in our case, Security subnet). The endpoint type is a GWLB endpoint.

NOTE: Wait for a while the time the endpoint is created.

7. Configuration of the NGFW logs

• Select 'Traffic' & 'Threat' as Log Type

• Select Cloud Watch & indicate the default Log Group destination for both Traffic & Threat

8. Add a default route in VPC Route Table called 'TGW' towards the newly created vpce

9. Test1: Ping works as expected with Rule10 configured in NGFW.

10. Visualization in Cloud Watch of Test 1

We can see the Source, Destination & Protocol, but more importantly, the rule of NGFW that had an action on the ping. [rule: "allowicmpAB" with action: "allow"]

11. Test2: Ping blocked with new rule added with lowest priority (=5) & visualization with Cloud Watch.

11.1 Rule configuration 

NOTE: Don't forget to deploy new configuration & commit.

11.2 Ping Test: Ping is NOK as expected

11.3 Visualization on Cloud Watch

12. Test if Log4J attack is well detected & blocked by default when simulated from Spoke A EC2 to Spoke B EC2.

NOTE: Remember that the traffic must be first allowed in the rules to be detected by Security Profiles (Content Inspection).

Curl is not successful.

We can see in Cloud Watch that AWS Cloud NGFW has detected the Attack in its Security Profile, considering this as a threat and even identified it was Log4J attack.

Centralized deployment model for Internet Egress

NOTE: in my lab, Security VPC is 10.3/16. (not 10.2/16 as above)

NOTE: for the Internet Egress traffic, I will configure a dedicated rulestack, therefore a new NGFW endpoint & a new NGFW resource. However, keep in mind it is absolutely possible to filter East / West + Internet Egress with the same local rulestack, same NGFW endpoint & same NGFW resource (I tested it).

Flow

1. VPC A send the request to AWS TGW to its Spoke RT towards TGW-VPCA attachment between Spoke A VPC and AWS TGW.

2. The TGW routes the traffic Security VPC towards TGW ENI subnet.

3. The traffic is then forwarded to NGFW endpoint, then Cloud NGFW for inspection. 

4. If the traffic is allowed, the NGFW endpoint routes traffic to the NATGW.

5. NATGW forwards the traffic to the IGW, then to destination.

Architecture Build

1. Add default route in VPC Spoke A Route Table towards TGW

2. In Firewall subnet Route Table, add static routes to 10.1/16 & 10.2/16 towards TGW.

3. Create NAT subnet, its dedicated Route Table & associate the subnet to the RT.

4. Create IGW & attach it to Security VPC

5. Create NATGW in NAT subnet (with EIP)

6. In NAT subnet Route Table, add default route towards IGW & static route to 10.1/16 towards NGFW endpoints

7. In Firewall subnet Route table, add default route towards NATGW.

AWS Cloud NGFW Configuration

1. Create a new local rulestack called 'Egress'

NOTE: For each local rulestack, a new NGFW resource and its associated NGFW endpoint must be created.

2. Create a new NGFW resource & NGFW endpoint, associate it to the newly created local rulestack called 'Egress'

3. Adapt the routing towards endpoints to make co-exist the East/West policy & the Egress policy.

    - in Security VPC RT 'TGW', static route to 10/8 towards EastWest vcpe

    - in Security VPC RT 'TGW', default route towards Egress vcpe

    - in Security VPC RT 'NAT', static route to 10.1/8 towards Egress vpce

4. Testing FQDN List Object

I spent so much time on this one without any success! Clearly today, FQDN List Object does not look to work & behave properly for 2 main reasons:

1. Wildcards are NOT supported. I let you imagine the never-ending list of URL's to allow or deny.

2. There is a known issue FWAAS-1501. AWS Cloud NGFW uses AWS R53 to resolve FQDN in your rules. It might resolve to an IP@ address which is different than what you may see when you use R53 Resolver in your VPC.

For all Internet Egress filtering, please prefer URL Custom Category. I made it work with a last rule allowing anything to anything: just imagine! 😜

5. Testing 'Intelligent Feed': Cyber Threat Protection against the malicious IPs (IDS / IPS).

5a. Add a Rule blocking all the pre-populated Palo Alto Feeds for Spoke A VPC CIDR (10.1/16). Spoke A EC2 should not be able then to reach out these bad actors.

5b. Deploy Configuration & Commit

5c. From Spoke A EC2, try curl to a ToR Exit Node - Curl is not successful as expected

5d. Confirmation / Visualization on Cloud Watch

The AWS Cloud NGFW has identified the ToR Node IP as a bad IP in its Feed and Rule called 'Feed' previously created has dropped the request.

 

6. Testing URL Category & Custom URL Category

The goal of the test is to: 

• block 'dating websites' only with Security Profile

• Create 2 Custom URL Categories (AllowGoogle & DenyAmazon)

6a. Create 2 objects Custom URL Categories as below (we can see that Google website is going to be allowed whereas Amazon is going to be blocked)

6b. In Security Profiles, click on edit 'URL categories & filtering'

6c. Change the 'dating' category Site Access to 'block'. Note that on top of the screen, we can see the 2 custom URL Categories previously created.

6d. Deploy Configuration & Commit

6e. Curl google is successful whereas curl amazon & tinder (dating website) are not.

6f. Visualization on Cloud Watch

Amazon Website is considered as a threat with the Custom URL Category 'DenyAmazon' previously created and therefore its access is denied.

Tinder website is considered as being part of the 'dating' category. Dating category is considered as a threat & blocked as previously configured.

Useful Links

Palo Alto Community (for configuration)

Palo Alto Support Cases (only for Admin, not for configuration)

AWS Cloud NGFW Portal (once you have subscribed)

Conclusion

• Only available in AWS

• Only available with Palo Alto vendor

• Price is ... what it is... (I did not dare calculating seeing how it is complex & looks prohibitive)

• No proper tools for analysing the Firewall traffic (other than Cloud Watch or S3) however better granularity of the infos received in the Logs than with AWS Network Firewall

• Architecture complex & pretty similar to AWS Network Firewall, especially the routing; however simpler in some deployment models (like Internet Egress) than with AWS Network Firewall

• Creation of Security VPC to locate NGFW endpoints leading to re architecture / re configuration in Brownfield

• Need of creating static routes to endpoints (not dynamic)

• Wildcards not supported on FQDN List Objects

• Rules with FQDN List Objects do not behave properly

• Palo Alto Web Interface is (to me) better that what you have with PAN VM-Series; not doubt. This is intuitive & quite easy to configure.

All roads lead to Rome -- Aviatrix & NGFW insertion

If you liked all of the above, but you even want to go to the next level, please read this..

Aviatrix provides a feature called Firenet for a seamless / transparent  NG FW insertion on any kind of traffic pattern:

• East / West (Cloud to Cloud), not only VPC to VPC as AWS Cloud NGFW

• North / South (Cloud to On Prem)

• Ingress Internet

• Egress Internet

Please check out this link for different design pattern.

What are the advantages of Aviatrix Firenet?

• Easiness

• No re-architecture of your Cloud infrastructure

• Aviatrix Controller configures the interfaces and routing of your Firewall for you

• Scaling Out

• Multi-AZ deployment for a better resiliency

• Performance (depending on the Public Cloud): up to 75 Gbps with up to 20 active / active NG FWs.

• Convergence: Firenet leverages ECMP (Equal Cost Multi Path) & Active Mesh 2.0 (Aviatrix home made) allowing you for most of the failure scenarios to have no time to re-converge; meaning the failure will be totally transparent for the flows as all links are active and are forwarding traffic.

• Automated Route Management: Aviatrix Controller automatically reprograms the routes of Aviatrix Gateways & NGFW when needed. You don't have to bother with routing.

• Deep visibility & operational capability

• no IPSEC between Aviatrix Gateways & NGFW

• no SNAT

• Repeatable architecture across any Cloud (not only AWS). You can insert seamlessly your NG FW exactly the same way regardless of the Public Cloud (AWS, Azure, GCP, AliCloud, OCI)

• You can insert the NGFW of your choice (PAN, Checkpoint, Fortinet). You can even Bring Your Own Appliance (BYOA) - not only Palo Alto NGFW

NOTE: later in the summer, a specific post on Aviatrix Firenet with AWS GWLB integration will be released. You then will be able to see how easy it is to insert NGFW with Aviatrix Firenet.