Written in collaboration with @andrewmathu
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.
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.
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:
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.
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.
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.
For the setup to work correctly, the appropriate certificates must be used for each component. Also refer to the setup diagram.
Certificate CA = Self Signed Root
Intermediate Certificate CN = *.build.seccxp.ninja.
The following OpenSSL commands were used to create the self-signed certificates:
openssl ecparam -out ninjabuild.key -name prime256v1 -genkey
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:
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.
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.
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:
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.
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:
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.