Merge pull request #204235 from johndowns/front-door-best-practices

Add Front Door and WAF best practices

Author: ttorble

articles/frontdoor/TOC.yml

@@ -158,6 +158,8 @@
         href: front-door-url-redirect.md?pivots=front-door-standard-premium
       - name: Private Link
         href: private-link.md
+      - name: Best practices
+        href: best-practices.md
     - name: Classic
       items:
         - name: Caching

articles/frontdoor/best-practices.md

@@ -0,0 +1,107 @@
+---
+title: Azure Front Door - Best practices
+description: This page provides information about how to configure Azure Front Door based on Microsoft's best practices.
+services: frontdoor
+documentationcenter: ''
+author: johndowns
+ms.service: frontdoor
+ms.topic: article
+ms.tgt_pltfrm: na
+ms.workload: infrastructure-services
+ms.date: 07/10/2022
+ms.author: jodowns
+---
+
+# Best practices for Front Door
+
+This article summarizes best practices for using Azure Front Door.
+
+## General best practices
+
+### Avoid combining Traffic Manager and Front Door
+
+For most solutions, you should use *either* Front Door *or* [Azure Traffic Manager](/azure/traffic-manager/traffic-manager-overview).
+
+Traffic Manager is a DNS-based load balancer. It sends traffic directly to your origin's endpoints. In contrast, Front Door terminates connections at points of presence (PoPs) near to the client and establishes separate long-lived connections to the origins. The products work differently and are intended for different use cases.
+
+If you combine both Front Door and Traffic Manager together, it's unlikely that you'll increase the resiliency or performance of your solution. Also, if you have health probes configured on both services, you might accidentally overload your servers with the volume of health probe traffic.
+
+If you need content caching and delivery (CDN), TLS termination, advanced routing capabilities, or a web application firewall (WAF), consider using Front Door. For simple global load balancing with direct connections from your client to your endpoints, consider using Traffic Manager. For more information about selecting a load balancing option, see [Load-balancing options](/azure/architecture/guide/technology-choices/load-balancing-overview).
+
+### Use the latest API version and SDK version
+
+When you work with Front Door by using APIs, ARM templates, Bicep, or Azure SDKs, it's important to use the latest available API or SDK version. API and SDK updates occur when new functionality is available, and also contain important security patches and bug fixes.
+
+## TLS best practices
+
+### Use end-to-end TLS
+
+Front Door terminates TCP and TLS connections from clients. It then establishes new connections from each point of presence (PoP) to the origin. It's a good practice to secure each of these connections with TLS, even for origins that are hosted in Azure. This approach ensures that your data is always encrypted during transit.
+
+For more information, see [End-to-end TLS with Azure Front Door](end-to-end-tls.md).
+
+### Use HTTP to HTTPS redirection
+
+It's a good practice for clients to use HTTPS to connect to your service. However, sometimes you need to accept HTTP requests to allow for older clients or clients who might not understand the best practice.
+
+You can configure Front Door to automatically redirect HTTP requests to use the HTTPS protocol. You should enable the *Redirect all traffic to use HTTPS* setting on your route.
+
+### Use managed TLS certificates
+
+When Front Door manages your TLS certificates, it reduces your operational costs, and helps you to avoid costly outages caused by forgetting to renew a certificate. Front Door automatically issues and rotates managed TLS certificates.
+
+For more information, see [Configure HTTPS on an Azure Front Door custom domain using the Azure portal](standard-premium/how-to-configure-https-custom-domain.md).
+
+### Use 'Latest' version for customer-managed certificates
+
+If you decide to use your own TLS certificates, then consider setting the Key Vault certificate version to 'Latest'. By using 'Latest', you avoid having to reconfigure Front Door to use new versions of your certificate and waiting for the certificate to be deployed throughout Front Door's environments.
+
+For more information, see [Select the certificate for Azure Front Door to deploy](standard-premium/how-to-configure-https-custom-domain.md#select-the-certificate-for-azure-front-door-to-deploy).
+
+## Domain name best practices
+
+### Use the same domain name on Front Door and your origin
+
+Front Door can rewrite the `Host` header of incoming requests. This feature can be helpful when you manage a set of customer-facing custom domain names that route to a single origin. The feature can also help when you want to avoid configuring custom domain names in Front Door and at your origin. However, when you rewrite the `Host` header, request cookies and URL redirections might break. In particular, when you use platforms like Azure App Service, features like [session affinity](/azure/app-service/configure-common#configure-general-settings) and [authentication and authorization](/azure/app-service/overview-authentication-authorization) might not work correctly.
+
+Before you rewrite the `Host` header of your requests, carefully consider whether your application is going to work correctly.
+
+For more information, see [Preserve the original HTTP host name between a reverse proxy and its back-end web application](/azure/architecture/best-practices/host-name-preservation).
+
+## Web application firewall (WAF)
+
+### Enable the WAF
+
+For internet-facing applications, we recommend you enable the Front Door web application firewall (WAF) and configure it to use managed rules. When you use a WAF and Microsoft-managed rules, your application is protected from a range of attacks.
+
+For more information, see [Web Application Firewall (WAF) on Azure Front Door](web-application-firewall.md).
+
+### Follow WAF best practices
+
+The WAF for Front Door has its own set of best practices for its configuration and use. For more information, see [Best practices for Web Application Firewall on Azure Front Door](../web-application-firewall/afds/waf-front-door-best-practices.md).
+
+## Health probe best practices
+
+### Disable health probes when there’s only one origin in an origin group
+
+Front Door's health probes are designed to detect situations where an origin is unavailable or unhealthy. When a health probe detects a problem with an origin, Front Door can be configured to send traffic to another origin in the origin group.
+
+If you only have a single origin, Front Door always routes traffic to that origin even if its health probe reports an unhealthy status. The status of the health probe doesn't do anything to change Front Door's behavior. In this scenario, health probes don't provide a benefit and you should disable them to reduce the traffic on your origin.
+
+For more information, see [Health probes](health-probes.md).
+
+### Select good health probe endpoints
+
+Consider the location where you tell Front Door's health probe to monitor. It's usually a good idea to monitor a webpage or location that you specifically design for health monitoring. Your application logic can consider the status of all of the critical components required to serve production traffic including application servers, databases, and caches. That way, if any component fails, Front Door can route your traffic to another instance of your service.
+
+For more information, see the [Health Endpoint Monitoring pattern](/azure/architecture/patterns/health-endpoint-monitoring)
+
+### Use HEAD health probes
+
+Health probes can use either the GET or HEAD HTTP method. It's a good practice to use the HEAD method for health probes, which reduces the amount of traffic load on your origins.
+
+For more information, see [Supported HTTP methods for health probes](health-probes.md#supported-http-methods-for-health-probes).
+
+## Next steps
+
+Learn how to [create an Front Door profile](create-front-door-portal.md).

articles/web-application-firewall/afds/waf-front-door-best-practices.md

@@ -0,0 +1,95 @@
+---
+title: Best practices for Web Application Firewall on Azure Front Door
+description: In this article, you learn about the best practices for using the web application firewall with Azure Front Door.
+services: web-application-firewall
+author: johndowns
+ms.service: web-application-firewall
+ms.topic: conceptual
+ms.date: 07/18/2022
+ms.author: jodowns
+
+---
+
+# Best practices for Web Application Firewall (WAF) on Azure Front Door
+
+This article summarizes best practices for using the web application firewall (WAF) on Azure Front Door.
+
+## General best practices
+
+### Enable the WAF
+
+For internet-facing applications, we recommend you enable a web application firewall (WAF) and configure it to use managed rules. When you use a WAF and Microsoft-managed rules, your application is protected from a range of attacks.
+
+### Tune your WAF
+
+The rules in your WAF should be tuned for your workload. If you don't tune your WAF, it might accidentally block requests that should be allowed. Tuning might involve creating [rule exclusions](waf-front-door-exclusion.md) to reduce false positive detections.
+
+While you tune your WAF, consider using [detection mode](waf-front-door-policy-settings.md#waf-mode), which logs requests and the actions the WAF would normally take, but doesn't actually block any traffic.
+
+For more information, see [Tuning Web Application Firewall (WAF) for Azure Front Door](waf-front-door-tuning.md).
+
+### Use prevention mode
+
+After you've tuned your WAF, you should configure it to [run in prevention mode](waf-front-door-policy-settings.md#waf-mode). By running in prevention mode, you ensure the WAF actually blocks requests that it detects are malicious. Running in detection mode is useful while you tune and configure your WAF, but provides no protection.
+
+## Managed ruleset best practices
+
+### Enable default rule sets
+
+Microsoft's default rule sets are designed to protect your application by detecting and blocking common attacks. The rules are based on a various sources including the OWASP top 10 attack types and information from Microsoft Threat Intelligence.
+
+For more information, see [Azure-managed rule sets](afds-overview.md#azure-managed-rule-sets).
+
+### Enable bot management rules
+
+Bots are responsible for a significant proportion of traffic to web applications. The WAF's bot protection rule set categorizes bots based on whether they're good, bad, or unknown. Bad bots can then be blocked, while good bots like search engine crawlers are allowed through to your application.
+
+For more information, see [Bot protection rule set](afds-overview.md#bot-protection-rule-set).
+
+### Use the latest ruleset versions
+
+Microsoft regularly updates the managed rules to take account of the current threat landscape. Ensure that you regularly check for updates to Azure-managed rule sets.
+
+For more information, see [Web Application Firewall DRS rule groups and rules](waf-front-door-drs.md).
+
+## Rate limiting best practices
+
+### Add rate limiting
+
+Front Door's WAF enables you to control the number of requests allowed from each client's IP address over a period of time. It's a good practice to add rate limiting to reduce the impact of clients accidentally or intentionally sending large amounts of traffic to your service, such as during a [*retry storm*](/azure/architecture/antipatterns/retry-storm/).
+
+For more information, see the following resources:
+- [Configure a Web Application Firewall rate limit rule using Azure PowerShell](waf-front-door-rate-limit-powershell.md).
+- [Why do additional requests above the threshold configured for my rate limit rule get passed to my backend server?](waf-faq.yml#why-do-additional-requests-above-the-threshold-configured-for-my-rate-limit-rule-get-passed-to-my-backend-server-)
+
+## Geo-filtering best practices
+
+### Geo-filter traffic
+
+Many web applications are designed for users within a specific geographic region. If this situation applies to your application, consider implementing geo-filtering to block requests that come from outside of the countries you expect to receive traffic from.
+
+For more information, see [What is geo-filtering on a domain for Azure Front Door Service?](waf-front-door-tutorial-geo-filtering.md).
+
+### Specify the unknown (ZZ) location
+
+Some IP addresses aren't mapped to locations in our dataset. When an IP address can't be mapped to a location, the WAF assigns the traffic to the unknown (ZZ) country. To avoid blocking valid requests from these IP addresses, consider allowing the unknown (ZZ) country through your geo-filter.
+
+For more information, see [What is geo-filtering on a domain for Azure Front Door Service?](waf-front-door-tutorial-geo-filtering.md).
+
+## Logging
+
+### Add diagnostic settings to save your WAF's logs
+
+Front Door's WAF integrates with Azure Monitor. It's important to save the WAF logs to a destination like Log Analytics. You should review the WAF logs regularly. Reviewing logs helps you to [tune your WAF policies to reduce false-positive detections](#tune-your-waf), and to understand whether your application has been the subject of attacks.
+
+For more information, see [Azure Web Application Firewall monitoring and logging](waf-front-door-monitor.md).
+
+### Send logs to Microsoft Sentinel
+
+Microsoft Sentinel is a security information and event management (SIEM) system, which imports logs and data from multiple sources to understand the threat landscape for your web application and overall Azure environment. Front Door's WAF logs should be imported into Microsoft Sentinel or another SIEM so that your internet-facing properties are included in its analysis. For Microsoft Sentinel, use the Azure WAF connector to easily import your WAF logs.
+
+For more information, see [Using Microsoft Sentinel with Azure Web Application Firewall](../waf-sentinel.md).
+
+## Next steps
+
+Learn how to [create a Front Door WAF policy](waf-front-door-create-portal.md).

articles/web-application-firewall/ag/best-practices.md

@@ -0,0 +1,86 @@
+---
+title: Best practices for Web Application Firewall on Azure Application Gateway
+description: In this tutorial, you learn about the best practices for using the web application firewall with Application Gateway.
+services: web-application-firewall
+author: vhorne
+ms.service: web-application-firewall
+ms.topic: tutorial
+ms.date: 07/18/2022
+ms.author: jodowns
+---
+
+# Best practices for Web Application Firewall on Application Gateway
+
+This article summarizes best practices for using the web application firewall (WAF) on Azure Application Gateway.
+
+## General best practices
+
+### Enable the WAF
+
+For internet-facing applications, we recommend you enable a web application firewall (WAF) and configure it to use managed rules. When you use a WAF and Microsoft-managed rules, your application is protected from a range of attacks.
+
+### Use WAF policies
+
+WAF policies are the new resource type for managing your Application Gateway WAF. If you have older WAFs that use WAF Configuration resources, you should migrate to WAF policies to take advantage of the latest features.
+
+For more information, see the following resources:
+- [Migrate Web Application Firewall policies using Azure PowerShell](./migrate-policy.md)
+- [Upgrade Application Gateway WAF configuration to WAF policy using Azure Firewall Manager](../shared/manage-policies.md#upgrade-application-gateway-waf-configuration-to-waf-policy)
+
+### Tune your WAF
+
+The rules in your WAF should be tuned for your workload. If you don't tune your WAF, it might accidentally block requests that should be allowed. Tuning might involve creating [rule exclusions](application-gateway-waf-configuration.md) to reduce false positive detections.
+
+While you tune your WAF, consider using [detection mode](create-waf-policy-ag.md#configure-waf-rules-optional), which logs requests and the actions the WAF would normally take, but doesn't actually block any traffic.
+
+For more information, see [Troubleshoot Web Application Firewall (WAF) for Azure Application Gateway](web-application-firewall-troubleshoot.md).
+
+### Use prevention mode
+
+After you've tuned your WAF, you should configure it to [run in prevention mode](create-waf-policy-ag.md#configure-waf-rules-optional). By running in prevention mode, you ensure the WAF actually blocks requests that it detects are malicious. Running in detection mode is useful while you tune and configure your WAF, but provides no protection.
+
+## Managed ruleset best practices
+
+### Enable core rule sets
+
+Microsoft's core rule sets are designed to protect your application by detecting and blocking common attacks. The rules are based on a various sources including the OWASP top 10 attack types and information from Microsoft Threat Intelligence.
+
+For more information, see [Web Application Firewall CRS rule groups and rules](application-gateway-crs-rulegroups-rules.md).
+
+### Enable bot management rules
+
+Bots are responsible for a significant proportion of traffic to web applications. The WAF's bot protection rule set categorizes bots based on whether they're good, bad, or unknown. Bad bots can then be blocked, while good bots like search engine crawlers are allowed through to your application.
+
+For more information, see [Azure Web Application Firewall on Azure Application Gateway bot protection overview](bot-protection-overview.md).
+
+### Use the latest ruleset versions
+
+Microsoft regularly updates the managed rules to take account of the current threat landscape. Ensure that you regularly check for updates to Azure-managed rule sets.
+
+For more information, see [Web Application Firewall CRS rule groups and rules](application-gateway-crs-rulegroups-rules.md).
+
+## Geo-filtering best practices
+
+### Geo-filter traffic
+
+Many web applications are designed for users within a specific geographic region. If this situation applies to your application, consider implementing geo-filtering to block requests that come from outside of the countries you expect to receive traffic from.
+
+For more information, see [Geomatch custom rules](geomatch-custom-rules.md).
+
+## Logging
+
+### Add diagnostic settings to save your WAF's logs
+
+Application Gateway's WAF integrates with Azure Monitor. It's important to save the WAF logs to a destination like Log Analytics. You should review the WAF logs regularly. Reviewing logs helps you to [tune your WAF policies to reduce false-positive detections](#tune-your-waf), and to understand whether your application has been the subject of attacks.
+
+For more information, see [Azure Web Application Firewall Monitoring and Logging](application-gateway-waf-metrics.md).
+
+### Send logs to Microsoft Sentinel
+
+Microsoft Sentinel is a security information and event management (SIEM) system, which imports logs and data from multiple sources to understand the threat landscape for your web application and overall Azure environment. Application Gateway's WAF logs should be imported into Microsoft Sentinel or another SIEM so that your internet-facing properties are included in its analysis. For Microsoft Sentinel, use the Azure WAF connector to easily import your WAF logs.
+
+For more information, see [Using Microsoft Sentinel with Azure Web Application Firewall](../waf-sentinel.md).
+
+## Next steps
+
+Learn how to [enable the WAF on an Application Gateway](application-gateway-web-application-firewall-portal.md).

articles/web-application-firewall/toc.yml

@@ -66,6 +66,8 @@
       href: ./ag/bot-protection-overview.md
     - name: WAF engine
       href: ./ag/waf-engine.md
+    - name: Best practices
+      href: ./ag/best-practices.md
     - name: FAQ
       href: ./ag/application-gateway-waf-faq.yml
   - name: Front Door
@@ -82,6 +84,8 @@
       href: ./afds/waf-front-door-policy-settings.md
     - name: Geo-filtering
       href: ./afds/waf-front-door-geo-filtering.md
+    - name: Best practices
+      href: ./afds/waf-front-door-best-practices.md
     - name: FAQ
       href: ./afds/waf-faq.yml
   - name: Security