Frequently asked questions for Azure Web Application Firewall on Azure Front Door Service

Azure WAF is a web application firewall that helps protect your web applications from common threats such as SQL injection, cross-site scripting, and other web exploits. You can define a WAF policy consisting of a combination of custom and managed rules to control access to your web applications.

An Azure WAF policy can be applied to web applications hosted on Application Gateway or Azure Front Doors.

Azure Front Door is a highly scalable, globally distributed application and content delivery network. Azure WAF, when integrated with Front Door, stops denial-of-service and targeted application attacks at the Azure network edge, close to attack sources before they enter your virtual network, offers protection without sacrificing performance.

Front Door offers TLS offloading. WAF is natively integrated with Front Door and can inspect a request after it's decrypted.

Yes. You can configure IP restriction for IPv4 and IPv6.

We do our best to keep up with changing threat landscape. Once a new rule is updated, it's added to the Default Rule Set with a new version number.

Most WAF policy deployments complete under 20 minutes. You can expect the policy to take effect as soon as the update is completed across all edge locations globally.

When integrated with Front Door, WAF is a global resource. Same configuration applies across all Front Door locations.

You may configure IP Access Control List in your back-end to allow for only Front Door outbound IP address ranges using Azure Front Door service tag and deny any direct access from Internet. Service tags are supported for you to use on your virtual network. Additionally, you can verify that the X-Forwarded-Host HTTP header field is valid for your web application.

There are two options when applying WAF policies in Azure. WAF with Azure Front Door is a globally distributed, edge security solution. WAF with Application Gateway is a regional, dedicated solution. We recommend you choose a solution based on your overall performance and security requirements. For more information, see Load-balancing with Azure’s application delivery suite.

When you enable the WAF on an existing application, it's common to have false positive detections where the WAF rules detect legitimate traffic as a threat. To minimize the risk of an impact to your users, we recommend the following process:

• Enable the WAF in Detection mode to ensure that the WAF doesn't block requests while you are working through this process. This step is recommended for testing purposes on WAF.

  Important

  This process describes how to enable the WAF on a new or existing solution when your priority is to minimize the disturbance to your application's users. If you are under attack or imminent threat, you may want to instead deploy the WAF in Prevention mode immediately, and use the tuning process to monitor and tune the WAF over time. This will probably cause some of your legitimate traffic to be blocked, which is why we only recommend doing this when you are under threat.

• Follow our guidance for tuning the WAF. This process requires that you enable diagnostic logging, review the logs regularly, and add rule exclusions and other mitigations.
• Repeat this whole process, checking the logs regularly, until you're satisfied that no legitimate traffic is being blocked. The whole process may take several weeks. Ideally you should see fewer false positive detections after each tuning change you make.
• Finally, enable the WAF in Prevention mode.
• Even once you're running the WAF in production, you should keep monitoring the logs to identify any other false-positive detections. Regularly reviewing the logs will also help you to identify any real attack attempts that have been blocked.

Currently, ModSec CRS 3.0, CRS 3.1 and CRS 3.2 rules are only supported with WAF on Application Gateway. Rate limiting and Azure managed Default Rule Set rules are supported only with WAF on Azure Front Door.

Globally distributed at Azure network edges, Azure Front Door can absorb and geographically isolate large volume attacks. You can create custom WAF policy to automatically block and rate limit http(s) attacks that have known signatures. Further more, you can enable DDoS Network Protection on the VNet where your back-ends are deployed. Azure DDoS Protection customers receive additional benefits including cost protection, SLA guarantee, and access to experts from DDoS Rapid Response Team for immediate help during an attack. For more information, see DDoS protection on Front Door.

You might not see requests immediately blocked by the rate limit when requests are processed by different Front Door servers. For more information, see Rate limiting and Front Door servers.

Front Door WAF supports the following content types:

• DRS 2.0

  Managed rules

  • application/json
  • application/xml
  • application/x-www-form-urlencoded
  • multipart/form-data

  Custom rules

  • application/x-www-form-urlencoded

• DRS 1.x

  Managed rules

  • application/x-www-form-urlencoded
  • text/plain

  Custom rules

  • application/x-www-form-urlencoded

No, you can't. The AFD profile and the WAF policy need to be in the same subscription.

Next steps

• Learn about Azure Web Application Firewall.
• Learn more about Azure Front Door.