Are you currently experiencing an attack?

Are you currently experiencing an attack?

Azure WAF, A Deep Dive: Part 1

A web application firewall (WAF) is a crucial part of a robust security posture. A WAF detects and blocks a wide variety of threats within incoming traffic: cross-site scripting (XSS), code and SQL injection, protocol exploits, and others.

The top-tier cloud providers (AWS, GCP, and Azure) all offer web security tools, including WAFs. We’ve previously written about some of Azure’s capabilities: for example, How to setup and use Azure WAF, How to setup and use Microsoft Defender for Cloud, and Using DevSecOps on Azure.

Now in this article, we’ll take a deep dive specifically into Azure Web Application Firewall, which is the “frontline” Azure service for protecting web applications. We’ll explore its capabilities, its strengths, and its limitations.

What is Azure WAF?

Azure Web Application Firewall (WAF) is the primary built-in service for web security on Azure. As is typical for cloud provider services, it’s primarily designed for workloads within Azure, although it can be used for external workloads as well. 

Azure WAF is probably best known for its OWASP core rule sets, designed to protect applications from common attack techniques, and available when used with Azure Application Gateway

Azure WAF can also be deployed with Azure Front Door: a global CDN with application routing for different application types hosted in Azure. (Microsoft is also integrating the WAF with Azure CDN; this is currently in public preview.)

As will become clear below, Azure WAF’s built-in rules differ somewhat, depending on whether it’s used with Application Gateway or Front Door.

The service can be run in either detection mode or prevention mode. The latter is the primary use case; the WAF will block incoming requests that violate security policies, and log the details. In detection mode, it will only report on threats without attempting to mitigate them.

Included Security Rules

Azure’s Web Application Firewall is designed to enforce security rulesets. Out of the box, it comes with some predefined rules, managed by Microsoft.

For Application Gateway, it comes configured by default with rules based on the OWASP core rule set. (The default version is 3.2, although it supports several earlier versions as well.) CRS 3.2 protects against these threats:

  • SQL injection 
  • Cross-site scripting 
  • Other common attacks, such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion
  • HTTP protocol violations
  • HTTP protocol anomalies, such as missing host user-agent and accept headers
  • Bots, crawlers, and scanners
  • Common application misconfigurations (for example, Apache and IIS)

For Front Door, Azure WAF comes with the Azure-managed Default Rule Set, which includes rules for these threat categories:

  • Cross-site scripting
  • Java attacks
  • Local file inclusion
  • PHP injection attacks
  • Remote command execution
  • Remote file inclusion
  • Session fixation
  • SQL injection protection
  • Protocol attackers

Azure WAF’s Custom Rule Capabilities

Along with the managed rules, Azure WAF admins can also create custom rules. 

Custom WAF rules for Application Gateway can allow or block requests based upon:

  • The client’s IP address or range
  • The client’s geography 
  • The request’s method (GET, POST, PUT, DELETE, etc.)
  • The request’s URI
  • The request’s headers
  • The request’s body content
  • The request’s cookies
  • Arguments sent in the POST body

Custom WAF rule options for Front Door include:

  • IP allow list and block list
  • Access control based on the client’s geography 
  • Access control based on the HTTP parameters
  • Access control based on the request method (GET, PUT, or HEAD)
  • Size constraints
  • Rate limiting rules

Hostile Bot Mitigation

For both Application Gateway and Front Door, Azure WAF also supports a managed bot protection rule set based on the Microsoft Threat Intelligence Feed. This includes a list of IP addresses that are known to be used by bots; Azure WAF can block traffic originating from these IPs.

Monitoring and Reporting

Monitoring and reporting features are critical to a WAF. Even though its primary responsibility is to mitigate attacks, it must also provide the ability to access traffic data. Admins must be able to respond to attacks as they occur, and also to analyze past traffic data in order to gain insights about the performance of the Azure WAF and other security modules

We have previously discussed the importance of traffic logging and monitoring, and what is provided by the various cloud platforms for this need. In short, an effective security posture requires:

  • An easy-to-use dashboard to display details of incoming requests
  • Alerting, to notify personnel when predefined events have occurred
  • Reporting, so that security managers can analyze past performance, using this information to reduce FP (False Positive) and (False Negative) alarms.

Logs generated by Azure WAF can be sent to Azure Monitor for tracking of firewall alerts and trends, plus it can integrate with Microsoft Defender for Cloud (which combines the former Azure Security Center and Azure Defender) to monitor and display the state of all Azure resources.

Unfortunately, an Azure deployment creates a large amount of log data, and it can be difficult to manage it in order to use it for security decisions. Azure-generated logs include:

  • Activity Logs for viewing operations. 
  • Access Resource Logs to view and analyze Application Gateway access patterns.
  • Performance Resource logs to see how Application Gateway instances are performing.
  • Firewall Resource logs to view the requests that are logged by an application gateway that is configured with Azure WAF.

Azure WAF users need the ability to quickly filter through log data and extract relevant security-related information. Microsoft recommends using Log Analytics for this purpose, but the process can be unwieldy. 

In short, although real-time traffic monitoring and control is necessary for a robust security posture, Azure WAF is not designed for this purpose. (We’ll revisit this issue later in this article series.)

Conclusion

This has been a short overview of Azure WAF and its capabilities. In Part 2 of this series, we’ll look at how it covers (or doesn’t cover) each of the OWASP Top 10 security risks, and then continue with a look at some of Azure WAF’s limitations.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.