Zero Trust with Azure Network Security

December 5, 2022

Written in collaboration with @andrewmathu

Introduction

As more organizations continue to migrate workloads into the cloud and adopt hybrid cloud setups, security measures and controls can become complicated and difficult to implement. The zero-trust model assists and guides organizations in the continuous digital transformation space by providing a reliable framework to manage complexity, secure digital assets and manage risk.

The Zero Trust model assumes breach and verifies each request as though it originated from an uncontrolled network regardless of where the request originates or what resource it accesses, instead of believing everything behind the corporate Firewall is safe. For this blog, we will guide you through strengthening one of Zero trust principles - Assume breach. To read more about Zero Trust principles see Zero Trust implementation guidance | Microsoft Learn

Azure Network Security Solutions – Firewall, DDoS Protection, and Web Application Firewall (WAF) provide Zero Trust implementation at the network layer ensuring that organizations’ digital assets are secured from attacks and there is visibility into the network traffic.

In this blog, we will look at how Azure DDoS Protection, Web Application Firewall and Azure Firewall can be deployed to achieve Zero Trust. The deployment is set up with end-to-end TLS encryption showcasing the ability of WAF and Azure Firewall to inspect encrypted traffic.

Setup:

The setup is based on a Hub and Spoke architecture. WAF in Application Gateway and Azure Firewall Premium have been deployed in the Hub VNet with a web application running on a Virtual Machine deployed in the Spoke VNet. The Hub and Spoke VNets have been peered to allow for inter VNet communication.

A client submits a request to the Application Gateway which has a WAF policy to protect against web application exploits and vulnerabilities. The Application Gateway decrypts the packets and the WAF policy inspects the traffic for any threats. If no threats are found, the traffic is forwarded to the Azure Firewall. A User Defined Route (UDR) is configured in the Application Gateway subnet to ensure the traffic destined for the backend web application passes through the Firewall.
Azure Firewall Premium receives the traffic and inspects it for threats. Azure Firewall Premium has TLS inspection capabilities that decrypts the traffic, applies IDPS (Intrusion Detection and Prevention) inspection and re encrypts the traffic to forward to the web application. Azure Firewall Premium uses a private CA (Certificate Authority) which signs the dynamically generated certificates.
The traffic reaches the backend web application. Return traffic from the web application to the Application Gateway goes through the Firewall. A User Defined Route has been configured in the web application subnet to send return traffic to the Firewall. The Firewall receives the outbound traffic and forwards it to the Application Gateway.

Web Application Firewall in Application Gateway

The Application Gateway is configured with Web Application Firewall v2 to terminate the TLS sessions, decrypt user traffic, and inspect it using WAF policies. The Application Gateway is configured with:

Web Application Firewall Policy. Azure Web Application Firewall provides centralized protection for web applications from common exploits and vulnerabilities.
Backend Pool – This has the Fully Qualified Domain Name (FQDN) of the protected web application. The Backend Pool is associated with one or more request-routing rules.

Backend Settings – The Backend Settings define the behavior of the routing rule. It includes the port and protocol used in the backend and settings such as cookie-based session affinity and connection draining. Azure Firewall Premium presents itself as the web server to the Application Gateway. The Application Gateway needs to validate those certificates, therefore the root CA that Azure Firewall Premium uses is configured in the Backend Settings.

The Application Gateway Listener checks for the incoming connection requests by using the IP address, port, protocol, and host. To configure TLS termination, a TLS/SSL certificate must be added to the listener. This allows the Application Gateway to decrypt incoming traffic and forward encrypted traffic to the client. In our configuration, the certificate is signed by a well-known CA that is accepted by any TLS client. A listener, just like the Backend Settings, is associated with routing rules.

Rules – The rules bind the Backend Pools, Backend Settings, and Listeners. The rules send traffic from a given frontend IP address to one or more backend targets.

Azure Firewall

Azure Firewall Premium has been configured inline behind the Application Gateway. The Azure Firewall Premium decrypts the received traffic from the Application Gateway, inspects the traffic with IDPS and Application rules and if no threats are found, re encrypts the traffic and forwards it to the target web application.

In this configuration, a self-signed (private) intermediate (subordinate) certificate is used by the Firewall to generate certificates. This certificate needs to be loaded to an instance of Key Vault associated with a Managed Identity.

IDPS is enabled and set to - Alert and Deny.

An application rule with TLS enable has been configured to allow access from the Application Gateway Subnet to the backend web application FQDN.

Azure DDoS Network Protection

Azure DDoS Network Protection has been configured on the Hub VNet where the Application Gateway Public IP resides.

Web Server

The backend web server contains the web application being accessed via the internet through Application Gateway with WAF and Azure Firewall Premium. In this deployment, IIS (Internet Information Services) running on a Windows Server machine was deployed to act as our backend web application. A server certificate signed by a well-known CA was uploaded to the IIS server. This allows the Application Gateway to trust the website by default.

DNS

Azure Firewall uses Domain Name System to determine the Web Application’s IP address as HTTP headers usually do not contain IP addresses. In this configuration, a private DNS zone was created and linked to the Hub VNet that contains the Firewall. An A record containing the IP address of the web application was added. Private DNS Zone is also what allows the Application Gateway to resolve the FQDN target in the backend pool.

To enable end user clients to connect to the web application over the internet, a public DNS zone was created. An A record for the web application’s domain name pointing to the Application gateway’s public IP address was configured in this DNS zone.

Certificates

For the setup to work correctly, the appropriate certificates must be used for each component. Also refer to the setup diagram.

In Application Gateway HTTPS Listener, a certificate signed by a well-known CA is used. This is the certificate that the end user clients see when they connect to the Web Application via its public domain name or URL.
For the connection between the Application Gateway and Azure Firewall, the root certificate of the Azure Firewall is used in the Application Gateway Backend Settings. This enables the Application Gateway to validate the Azure Firewall certificates as the Firewall presents itself to Application Gateway as the web server.
Azure Firewall contains an intermediate certificate signed by a private CA (custom Certificate Authority). The custom Intermediate/server certificate is generated and signed by the private CA root certificate with a Common Name (CN) of the domain to be protected e.g.

Certificate CA = Self Signed Root

Intermediate Certificate CN = *.build.seccxp.ninja.

The following OpenSSL commands were used to create the self-signed certificates:

Create a root CA certificate

Create the root key:
openssl ecparam -out ninjabuild.key -name prime256v1 -genkey
Create a Certificate Signing Request:
openssl req -new -sha256 -key ninjabuild.key -out SelfSignedRootCA.csr

In the prompt after the above command, type the password for the root key, and the organizational information for the custom CA - Country/Region, State, Organization, OU, and the fully qualified domain name.

ii. Generate the Root Certificate:

openssl x509 -req -sha256 -days 365 -in SelfSignedRootCA.csr -signkey ninjabuild.key -out SelfSignedRootCA.crt

b. Create a server/intermediate certificate

i. Create the certificate's key:

openssl ecparam -out intermediate.key -name prime256v1 -genkey

ii. Create the CSR (Certificate Signing Request):

openssl req -new -sha256 -key intermediate.key -out intermediate.csr

In the prompt after the above command, type the password for the root key, and the organizational information for the custom CA: Country/Region, State, Organization, OU, and the fully qualified domain name. This is the domain of the web application we are protecting:

886x446vv2.png.5e9eab43ce212efb7524c4973395959a.png

iii. Sign the CSR with the CA's root key to create server certificate:

openssl x509 -req -in intermediate.csr -CA SelfSignedRootCA.crt -CAkey ninjabuild.key -CAcreateserial -out Intermediate.crt -days 365 -sha256

c. Verify the newly created certificate

openssl x509 -in Intermediate.crt -text -noout

The Root certificate created in step (a) above is loaded and saved in the Application gateway’s Backend settings. This ensures there is trust established between the Application gateway and Firewall.

The intermediate certificate and private key created in step (b) above is loaded and saved in a Key Vault which is used by the Firewall for TLS inspection.

For more information on generating custom/self-signed certificates please refer to these articles:

For more information on Azure Firewall Premium Certificates and Digital Certificates, please refer to these articles:

The backend web application contains a server certificate signed by a well-known Certificate Authority. This ensures trust between the web application and Azure Firewall as the Firewall verifies that a well-known CA signs the web server TLS packets. To ensure there is no error for outgoing traffic from the web application, the Firewall’s Root CA certificate is added to the web application as a trusted Root CA.

Testing

Web Application Firewall:

The first test validates that the Web Application Firewall in the Application Gateway can detect and prevent Web Application attacks even in HTTPS traffic. The attack is based on a path traversal attack where the characters - ?file=secret.doc%00.pdf – are appended to the web application URL. This attack can be launched from any end user browser towards the web application. In the first test, WAF is set to detection mode and the attack is detected and matched and can be viewed in the Application Gateway Firewall Logs. In the second WAF test, WAF is set to Prevention mode. The attack is logged and denied.

For more information on this type of attack test scenario please see – OWASP Path Traversal.

Testing for a web application attack with WAF policy set to Detection Mode. A path traversal attack is initiated. The characters - ?file=secret.doc%00.pdf – are appended to the web server URL to test the attack.

The attack goes through as WAF is in detection mode. WAF logs from the Application Gateway show the details of the attack:

2. In the second test, the WAF is set to Prevention Mode. The attack does not proceed and the WAF logs in Application gateway show the attack was blocked:

The Application Firewall logs show the block:

Azure Firewall

The test on the Azure Firewall verifies that the Azure Firewall Premium can block malicious attacks inside encrypted traffic. The Firewall decrypts the application-based traffic and inspects it with IDPS. The attack test is based on running a curl command from an end user command prompt. “curl” is a command line tool that enables data transfer over various network protocols. The command used in the test enables data transfer over HTTPS (port 443) using a malicious user agent (HaxerMen).

From a command prompt type: curl -A "HaxerMen" <https://web server URL>. This sends HTTPS traffic to the web application using a known malicious user agent. The traffic will be processed by the Firewall application rules which have TLS inspection enabled. The Firewall TLS inspection decrypts the HTTPS traffic and IDPS signatures identify the malicious agent and alert and prevent the traffic from reaching the web application. The attack tests are carried out with IDPS mode set to alert – for the first test – and prevent for the second test. This validates the detection and prevention capabilities of Azure Firewall IDPS.

The first test on the Firewall is with TLS inspection enabled and IDPS set to Alert Mode. The attack goes through, and the IDPS logs show the attack alert.

2. In the second test, TLS inspection is enabled and IDPS is set to Alert and Deny. The attack is blocked.

The attack times out as Firewall IDPS drops the request, seen in the image below:

DDoS Protection

The Application Gateway public IP address is protected by Azure DDoS Network Protection which is enabled in the Hub VNet where it is located.

A simulated DDoS attack to the Public IP address of the Application Gateway is mitigated.

Summary

By using the three Azure network security solutions – WAF, DDoS and Firewall, organizations can implement and maintain a robust Zero-trust model within their Azure setup. The TLS inspection capabilities of Azure Firewall coupled with its IDPS, and the Web Application Firewall provides granular visibility into application traffic and stop threats even if they are embedded within encrypted traffic. With the addition of Azure DDoS protection, a true defense in depth architecture is achieved at all layers of the network.

Resources

Improve your Azure Network Infrastructure Security with Complementary Services - Microsoft Community Hub

Zero Trust implementation guidance

Overview - Apply Zero Trust principles to Azure infrastructure

Enabling Zero Trust with Azure network security services