Taking Azure Firewall IDPS on a Test Drive

Written by Gopikrishna Kannan (Head of Products: Azure Firewall and Firewall Manager)

Intrusion detection and prevention (IDPS) is an advanced threat prevention mechanism supported by the Azure Firewall Premium SKU. Unlike simple network filtering, IDPS matches traffic patterns to a set of known malicious signatures. Azure Firewall supports more than 60,000 malicious signatures which are updated in real time. These signatures apply when malicious patterns are detected under the right conditions.  The conditions include traffic direction (inbound or outbound) and network scope (private network or public network). Below are examples to validate IDPS configuration in your environment.

Test Setup

Client VM is running in AppSubnet and will connect to the Internet via Azure Firewall. TLS inspection is enabled to deeply inspect HTTPS traffic. IDPS is configured to Alert and Deny suspicious traffic.

For the demonstration, I have configured two rules to allow encrypted traffic to example.com and another rule to TLS inspect traffic to showmyip.com.

Validating HTTP Traffic

We will validate IDPS by injecting malicious User-Agent HaxerMen in the outbound curl request. Below is the output showing the connection is blocked.

Running the below command in AppSubnet shows no result.

Reviewing the IDPS logs shows traffic is blocked by Signature ID 2032081.

Notice that the source IP is Firewall IP and not the actual client IP. This is a known gap with IDPS logging HTTP traffic.

 Signature ID 2032081

A closer look at signature ID 2032081shows this signature applies to http traffic in ANY (both inbound & outbound) direction. It’s also configured as “Alert and Deny” by policy.

Validating HTTPs traffic

Next, we will test HTTPS connectivity to example.com while injecting user agent HaxerMen. Interestingly, the traffic was allowed and not blocked by IDPS. This is because the agent was undetected as the traffic was encrypted traffic.

So, let’s now run the https connection to showmyip.com which has been configured to be TLS inspected.

Now, let’s browse to www.showmyip.com website by injecting a new agent “HaxerMen”. Notice the traffic is blocked as expected thanks to TLS inspection and IDPS in action.

Inspecting the logs shows the matching malicious signature is 2032081. Note the SourceIp logged is the original client. Unlike the HTTP traffic scenario, IDPS logs the correct source IP.

Conclusion

That’s it! You just finished validating IDPS in a lab. To recap, it’s best practice to enable IDS/IPS with TLS inspection. Depending on your corporate security needs, you can configure IDS/IPS in either Alert mode or Alert & Deny mode. The IDS/IPS signatures are based on emerging threats and automatically pushed to the Firewall at regular intervals (multiple times/hour). It’s the best approach to keep your Azure environments secure. Happy validation!!

If you want to learn more about adopting Zero Trust with Azure Network Security ensuring that organizations’ digital assets are secured from attacks and there is visibility into the network traffic, check out this blog post.