Azure Application Gateway protection against CVE-2025-8671 (MadeYouReset)
A new HTTP/2 vulnerability, CVE-2025-8671 (MadeYouReset), was recently disclosed on August 13, 2025. This attack leverages carefully crafted protocol frames to force servers into repeatedly resetting streams on a single connection, which can lead to high resource consumption and denial of service (DoS) in extreme cases. MadeYouReset and Rapid Reset (CVE-2023-44487) are two similar attack patterns exploiting HTTP/2 steam resets feature leading to resource exhaustion. Stronger Defense with Azure Application Gateway If you are using Azure Application Gateway, you are already protected against MadeYouReset vulnerability. Two years ago in 2023, when addressing the Rapid Reset (CVE-2023-44487) attack, our engineering team implemented a comprehensive mitigation for these streams reset types of attacks. We introduced stronger safeguards to account for all kinds of stream cancellation regardless of the reason to protect against different flavors of rapid reset attacks. Customer Impact These safeguards are already active in Azure Application Gateway. No customer action is required. Azure services remain secure and resilient against this new class of HTTP/2 protocol attacks.Protect against SharePoint CVE-2025-53770 with Azure Web Application Firewall (WAF)
Summary Microsoft recently disclosed CVE-2025-53770, a critical vulnerability affecting on-premises SharePoint Server versions 2016, 2019, 2010, 2013, and Subscription Edition (SE). The vulnerability allows unauthenticated remote code execution (RCE) by chaining two separate CVEs: CVE-2025-49706 – Authentication Bypass CVE-2025-49704 – Deserialization Vulnerability Microsoft has released security updates for SharePoint Server 2016, 2019, and SE. Versions 2010 and 2013 are out of support and will not receive patches, leaving them exposed. If exploited, this vulnerability could allow an attacker to bypass authentication, extract cryptographic keys, and execute arbitrary C# code on the server. Technical details On-premises SharePoint Servers are enterprise-grade collaboration platforms that organizations install and manage on their own infrastructure, typically in their data centers. The attack chain for CVE-2025-53770 involves the following steps: CVE-2025-49706 – Authentication Bypass The attacker sends a crafted POST request targeting the endpoint:/_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx with a malicious Referer value:/_layouts/SignOut.aspxThis manipulates SharePoint into trusting the request and its payload. CVE-2025-49704 – Deserialization Vulnerability The attacker then sends a POST request with a serialized spinstall0.aspx payload, designed to extract MachineKey values from web.config. These keys are then used to craft a serialized C# code payload embedded in a valid __VIEWSTATE, which SharePoint trusts and executes. Microsoft guidance We strongly recommend following Microsoft's official mitigation steps outlined in the MSRC blog: Customer guidance for SharePoint vulnerability CVE-2025-53770 | Microsoft Security Response Center See the “How to protect your environment” section for patching guidance, configuration updates, and additional mitigation strategies. Protecting with Azure Web Application Firewall You can create a custom rule to help detect and block suspicious requests matching known indicators of this attack. Example WAF custom rule: Condition 1: URI contains / _layouts/15/ToolPane.aspx or / _layouts/15/spinstall0.aspx Condition 2: Referer header contains / _layouts/SignOut.aspx or / _layouts/15/SignOut.aspx JSON view "customRules": [ { "name": "CVE202553770", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestUri" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "(?i)/_layouts(?:/\\d+)?/(SignOut|spinstall0|ToolPane)\\.aspx" ], "transforms": [] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Referer" } ], "operator": "Regex", "negationConditon": false, "matchValues": [ "(?i)/_layouts(?:/\\d+)?/(SignOut|spinstall0|ToolPane)\\.aspx" ], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" } ] Next steps Patch immediately: Apply Microsoft’s updates for SharePoint 2016, 2019, and SE. Isolate legacy systems: SharePoint 2010 and 2013 remain vulnerable—consider restricting network access or migrating to supported versions. Deploy WAF protections: Add the custom rule above to monitor and block suspicious traffic targeting vulnerable endpoints. You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here. For more on Azure WAF, see: Azure Web Application Firewall documentation
Securing Containerized Applications with Application Gateway for Containers and Azure WAF
Azure Application Gateway for Containers is a modern, Kubernetes-native Layer 7 load balancer designed to manage ingress traffic for containerized applications running in Azure Kubernetes Service (AKS). Application Gateway for Containers is the evolution of the Application Gateway Ingress Controller (AGIC), and introduces a new control and data plane architecture, enabling near-instant updates to routes, probes, and backend pods. It supports features like traffic splitting, mutual TLS, header-based routing and increased performance—making it ideal for microservices and multi-tenant environments. But what truly sets Application Gateway for Containers apart is its native integration with Azure Web Application Firewall (WAF). Application Gateway for Containers introduces a Kubernetes-native custom resource called WebApplicationFirewallPolicy, allowing WAF policies to be defined and scoped directly within the cluster. WAF acts as the first line of defense, inspecting all incoming traffic before it reaches your pods. WAF policies can be applied at the listener level or scoped down to specific routes, giving you precise control over how and where security is enforced. This flexibility allows security teams to deploy global protections (like the OWASP Top 10 rules for SQL injection and cross-site scripting protection) across services while also enabling developers to fine-tune route-level rules for sensitive endpoints, like /login, /upload, or /admin. Further, Azure WAF supports prevention and detection modes, enabling you to start with alert-only configurations before moving to full enforcement allowing you to fine tune the WAF for your environment. You can also write your own rules by using the Custom Rules option. Using custom rules, you can block, allow, or log traffic based on headers, IP addresses, query parameters, or geolocation—giving security teams precise control over how threats are mitigated. Let’s walk through how Azure WAF enhances security when integrated with Application Gateway for Containers. Bot mitigation: Azure WAF’s bot manager uses Microsoft threat intelligence to categorize and manage bot traffic—blocking known malicious bots, allowing verified good bots, and logging unknown ones by default. DRS 2.1: Provides robust coverage against common web vulnerabilities, including Path Traversal, Cross-Site Scripting (XSS), SQL Injection and other OWASP Top 10 threats along with MSTIC (Microsoft Threat Intelligence Collection) rules. Custom rules: You can block requests with suspicious user-agent headers, rate-limit traffic to prevent abuse, geo-block traffic from regions you don’t serve, apply header inspection, IP filtering, and more Real-time observability: With Application Gateway for Containers, WAF logs and metrics are integrated into your observability stack. You can correlate WAF blocks with transaction IDs, trace attack vectors end-to-end, and validate that legitimate users remain unaffected. Let’s take a look at how you can achieve these benefits using WAF for Application Gateway for Containers: Deploying WAF and defining WAF policies in Kubernetes: Please make sure you have the following resources set up before getting started: Azure Kubernetes Service (AKS) – Ensure your backend application is deployed and running in AKS. Application Gateway for Containers – Deploy Application Gateway for Containers to manage ingress traffic to your containerized workloads. WAF Policy – Create a new WAF policy or reuse an existing one already configured for Application Gateway. Attach the WAF Policy – Attach the WAF policy with a new security policy under the Application Gateway for Containers settings as shown below. Note: Security policies act as the bridge between your Azure WAF policy and the Kubernetes-native routing resources (like Gateway or HTTP Route). Without this association, the WAF policy exists in Azure but isn’t enforced on your containerized traffic. In this example, we have setup a backend application in AKS. The setup includes: A namespace called test-infra Two services called backend-v1 and backend-v2 Two deployments called backend-v1 and backend-v2 You’ll also create: A Gateway named gateway-01 Two HTTP Routes: http-route1 for path /bar and /some/thing http-route2 for path /anything Defining WAF policies As mentioned earlier, Application Gateway for Containers introduces a new Kubernetes custom resource called WebApplicationFirewallPolicy which allows you to define and scope Azure WAF policies directly within your AKS cluster. The following scopes may be defined: Gateway (global) HTTP Route (granular) Note: These are not mutually exclusive, you can apply both a gateway-level policy and per-route policies, and the route-level policy takes precedence over the gateway-level one. Here is an example WebApplicationFirewallPolicy YAML file: apiVersion: alb.networking.azure.io/v1 kind: WebApplicationFirewallPolicy metadata: name: sample-waf-policy namespace: test-infra spec: targetRef: group: gateway.networking.k8s.io kind: HTTPRoute name: http-route2 namespace: test-infra sectionNames: ["pathA"] webApplicationFirewall: id: /subscriptions/.../Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/waf-policy-0 Note: The name field here should match the HTTP route name so it can be applied to the appropriate HTTP route when there are multiple of them. Applying the policy: To apply the policy in AKS: kubectl apply -f waf.yaml To verify it was applied correctly: kubectl get webapplicationfirewallpolicy.alb.networking.azure.io -A -o yaml The output should look like this- apiVersion: alb.networking.azure.io/v1 kind: WebApplicationFirewallPolicy metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"alb.networking.azure.io/v1","kind":"WebApplicationFirewallPolicy","metadata":{"annotations":{},"name":"sample-waf-policy","namespace":"test-infra"},"spec":{"targetRef":{"group":"gateway.networking.k8s.io","kind":"HTTPRoute2","name":"http-route","namespace":"test-infra"},"webApplicationFirewall":{"id":"/subscriptions/{Subscription Name}/resourceGroups/{Resource Group Name}/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/{WAF Name}"}}} creationTimestamp: "2025-07-17T04:50:30Z" generation: 7 name: sample-waf-policy namespace: test-infra resourceVersion: "175009" uid: 031b6b5a-96c8-4d9f-8cc0-9d5e00000 spec: targetRef: group: gateway.networking.k8s.io kind: HTTPRoute name: http-route2 namespace: test-infra webApplicationFirewall: id: /subscriptions/{Subscription Name}/resourceGroups/{Resource Group Name}/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/{WAF Name} status: conditions: - lastTransitionTime: "2025-07-17T05:33:39Z" message: Valid WebApplicationFirewallPolicy observedGeneration: 7 reason: Accepted status: "True" type: Accepted kind: List metadata: resourceVersion: "" This confirms that the WAF policy has been applied correctly to the right HTTP Route as shown here - name: http-route2 In this scenario, we’ve configured two WAF policies: WAF Policy 1: Associated with http-route1, using DRS 2.1 in Prevention Mode. WAF Policy 2: Associated with http-route2, using a custom geo-blocking rule to deny US based traffic and is in Prevention Mode. Testing WAF behavior: In this scenario, we attempt to access the frontend URL specifically the path “/some/thing” which has the WAF Policy1 associated to it. To test the policy’s effectiveness, we simulate a SQL injection attack targeting this path as seen below. The response below demonstrates the WAF engine detecting and blocking the malicious request with an “Access Forbidden” response: In the next test scenario, when a request is sent from a US-based IP address to the path /anything, we get a 403 Forbidden message. This is because WAF Policy 2 is configured with a custom geo-blocking rule to block traffic from the US region using the Client IP address. It detects the origin and blocks the request. As a result, the client receives an “Access Forbidden” response, confirming that the policy is actively enforcing geographic restrictions. However, when accessing other paths such as /bar or /some/thing, the request is not blocked. This is because those paths are handled by a different route (http-route1) that is associated with WAF Policy 1, which does not include geo-blocking rules. This behavior highlights how WAF policy scoping allows you to apply different security rules to different parts of your application, enabling fine-grained control over traffic protection. Note: If a specific path does not have a WAF Rule associated with it, it inherits the WAF Policy that is applied at the Global level Monitoring: While Azure WAF protects the Application Gateway for Containers, having deep visibility into traffic and threat patterns is essential for maintaining a secure and resilient application environment. To do that, we will enable diagnostic logging on the Application Gateway for Containers as shown below: Once the traffic triggers a WAF rule due to an identified attack or custom rule, you will see WAF related logs using the query- “AGCFirewallLogs”. As seen, the logs provide detailed information related to the attacks such as the WAF policy that is being applied, the scope at which it is being applied, the RequestUri, RulesetType and much more. Azure WAF also supports sensitive data scrubbing. For example, you can redact fields like the request IP address in the logs to maintain privacy while still capturing actionable intelligence as shown below: As seen here, by integrating WAF logs and metrics into your observability stack, you gain real-time insights into blocked threats, user behavior, and application performance. This enables teams to trace incidents end-to-end, validate WAF effectiveness, and fine-tune policies with confidence. Whether you're investigating a blocked request or correlating alerts with backend performance, Log Analytics empowers you to move from detection to diagnosis seamlessly. Conclusion: Azure Application Gateway for Containers paired with Web Application Firewall (WAF) offers a powerful, flexible, and Kubernetes-native approach to securing microservices at the edge. By enabling WAF policies at both the listener and route levels, teams can enforce broad protections while tailoring defenses for high-risk endpoints. Whether you're mitigating bots, blocking injection attacks, or applying geo-based restrictions, Application Gateway for Containers with WAF empowers you to shift security left—closer to where your services live and evolve. Start with detection, move to prevention, and scale with confidence. Next steps What is Application Gateway for Containers? | Microsoft Learn Web Application Firewall on Application Gateway for Containers | Microsoft Learn Default rule set 2.1 - Azure Web Application Firewall WAF on Azure Application Gateway bot protection overview | Microsoft Learn Azure Web Application Firewall (WAF) v2 custom rules on Application Gateway | Microsoft LearnAzure WAF Tuning for Entra External ID
Introduction This blog is the second part of a series on tuning Azure Web Application Firewall (WAF) for Entra External ID/Azure Active Directory (AD) and serves as a follow-up to the earlier blog on Azure WAF Tuning with AD B2C Applications. With the introduction of Microsoft Entra External ID in 2024, some customers may experience similar challenges to those faced with Azure AD B2C, particularly around false positives generated by Azure WAF. This blog aims to provide guidance on how to best tune Azure WAF to handle traffic from Entra External ID, ensuring a seamless and secure experience for your users. Difference between Azure AD B2C and Entra External ID Microsoft Entra External ID is an identity platform that lets organizations manage external users securely while offering greater flexibility and scalability. It streamlines the integration of external identities with applications, delivers a seamless sign-in experience, and provides advanced security and compliance features for both B2C and B2B scenarios. Azure AD B2C was designed for customer-facing applications, providing features such as social identity providers, custom branding, and self-service password reset. While it served many use cases effectively, Microsoft has since introduced Entra External ID as a more advanced and unified solution for both consumer-oriented app developers and businesses seeking secure B2B collaboration. Entra External ID includes enhanced security, compliance, and scalability features, making it a comprehensive solution for managing external identities. Note: Effective May 1, 2025, Azure AD B2C is no longer available to purchase for new customers. Microsoft is transitioning all new external identity scenarios to Microsoft Entra External ID. Existing Azure AD B2C tenants will continue to be supported until at least 2030. Please refer to Azure AD B2C end of sale. Understanding the Challenge Similar to Azure AD B2C, Microsoft Entra External ID uses OAuth/OpenID Connect flows. During sign-in, parameters such as code, and id_token can contain base64-encoded strings that appear suspicious to WAF’s Managed Rule Sets. Some of the commonly triggered rules belong to paranoia level 2 (PL2) rules, a more aggressive paranoia level that may trigger blocks (see the section on paranoia levels later in this post). The two PL2 rules we encounter most are: 942430 - This rule checks for a high number of special characters in request data indicating a possible SQL injection attempt. This rule is disabled by default in DRS 2.1. 942440 – This rule detects sequences in request data that resemble SQL comments which are often used in SQL injection attacks. This rule is disabled by default in DRS 2.1 (Azure Front Door WAF) and is replaced by the Microsoft Threat Intelligence Center (MSTIC) rule 99031002. In Application Gateway WAF, users can manually disable it. These rules often flag tokens or code parameters as potential SQL injection attempts because they detect certain characters and patterns in the tokens. Learn more about Azure WAF rulesets. Tuning Azure WAF for Entra External ID In this blog, we’ll demonstrate the tuning process using: Microsoft Entra External ID Tenant – configured for external-facing authentication. Static Web App (SWA) – front-end code with ‘.auth login’ using Microsoft Entra ID, allowing flexibility to create a custom application. Azure Front Door Premium with a WAF Policy – running DRS 2.1 managed rules. Custom Domain – ensures all traffic, including OAuth callbacks, flows via Azure Front Door with WAF. We begin by registering our static web app to Entra external ID. In our Microsoft Entra Admin center, we navigate to Identity > Applications > App registrations. We select ‘New registration’ and fill in the details for our static web app as below: Once registered, we proceed to grant authentication and finally grant admin consent. To learn more about registering an application in Entra ID refer to How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn. Once we verify authentication to our static web app, we configure Azure Front Door with WAF to protect the web app. Learn how to configure Azure Front Door with WAF by following this tutorial. We have configured our Static Web App to be accessed through an Azure Front Door endpoint (with WAF), ensuring all authentication requests also flow through WAF for inspection and protection. To achieve this, we use a custom domain so that the OAuth callbacks and user traffic are routed exclusively through the Azure Front Door rather than the default - .azurestaticapps.net domain. Please refer to Add a custom domain to Azure Front Door | Microsoft Learn to learn more about Azure Front Door custom domains. Resolving False Positives When your WAF policy is running in prevention mode, genuine user authentication requests might sometimes be blocked - this is called a false positive. When a false positive occurs, a user successfully authenticates, but they see a block page (example below) instead of the static web app. However, you might notice that sometimes the very same sign-in flow completes successfully with no block at all. This seemingly “inconsistent” behavior arises because WAFs running the Default Rule Set (DRS) 2.x uses anomaly scoring. In Anomaly scoring each triggered rule contributes a severity-based score: Notice (2), Warning (3), Error (4), and Critical (5). If the total anomaly score exceeds the threshold of 5, the request is blocked, otherwise it is allowed. Since OAuth tokens (such as code or id_token) change with each login attempt, they may sometimes trigger enough rules to reach this threshold – resulting in a block. To address this challenge, we take the following steps: Evaluate the WAF Logs Remediate with: Exclusions Custom rules Change the rule actions Disable rules Evaluate paranoia levels Evaluating the WAF Logs Understanding the logs generated by the WAF is critical to diagnosing and resolving these issues. It is recommended to initially run the WAF policy in detection mode to log traffic without blocking requests, allowing you to identify and fine-tune exclusions before enabling prevention mode. Once you have reviewed the logs and adjusted configurations as needed, you can switch to prevention mode to actively block malicious requests. In our setup, we evaluate the WAF behavior directly in prevention mode to observe real-time blocks and evaluate which rules were triggered. You can use the following KQL query in your Log Analytics Workspace to identify blocked requests: AzureDiagnostics | where ResourceProvider == "MICROSOFT.CDN" and Category == "FrontDoorWebApplicationFirewallLog" | where action_s == "Block" We observe several requests that were blocked: Each WAF log entry provides a tracking reference which is a unique identifier assigned to each WAF event to make it easier to correlate and trace specific requests across different logs. You can use this reference to correlate WAF events with application logs or client-side tracing tools. This is especially helpful in complex authentication flows involving multiple redirects as the tracking reference can pinpoint exactly which request in the chain was blocked. Using the tracking reference from our first log, we can identify the specific rules whose score added up for the block: We can identify that rules 942430 and 942440—both of which target SQL injection signatures—are contributing to the anomaly score and ultimately causing the block. These rules belong to the Default Rule Set (DRS) 2.x and are designed to detect common SQL injection attempts by scanning for suspicious tokens, special characters, or query-like substrings. Both 942430 and 942440 reside in the OWASP ModSecurity Core Rule Set (CRS) family, which specifically targets SQL injection attempts by looking for patterns often used in malicious queries. In the official CRS documentation, these rules focus on suspicious characters (e.g., ‘, -, ;), SQL keywords (SELECT, UNION), and encoded strings. More specifically: Rule 942430 – “Restricted SQL Character Anomaly Detection” - This rule counts the number of special characters (like =, +, ', etc.) within request parameters. If it detects too many in a single payload (for example, “# of special characters exceeded (12)”), it flags the request as highly suspicious. OAuth tokens, being base64-encoded, can contain =, +, and other symbols that push this count over the threshold, triggering a false positive. Rule 942440 – “SQL Comment Sequence Detected” - This rule looks for typical SQL comment patterns such as -- or #. If it detects any substring resembling a comment sequence—possibly even certain base64 fragments—it interprets the request as a potential SQL injection. Because Entra External ID tokens are randomized, they may occasionally contain partial sequences that match the rule’s detection logic, again leading to false positives. For more details on the specific rule IDs and their matching criteria, see the OWASP ModSecurity Core Rule Set (CRS) documentation, or the Azure WAF rule reference for Managed Rule Sets. Understanding the purpose and scope of these rules helps you decide how to best tune WAF—whether by using exclusions, custom rules, or other remediation methods—to accommodate legitimate Entra External ID tokens without compromising your application’s overall security. Remediation Options Exclusions Exclusions tell the WAF to bypass certain parameters, cookies, or headers for specified rules. This is often the safest approach when you trust specific values—such as the id_token and code parameters from Microsoft Entra ID. By removing these from inspection, you prevent them from contributing to the anomaly score. In the Azure portal, you can configure exclusions under your WAF policy’s Managed Rule Set settings, matching the relevant parameter name (e.g., code) to a specific location (like Request Body or QueryParam). Learn more about WAF exclusion lists in Azure Front Door and how to configure exclusion lists for Azure Front Door. In our own environment, we determined that rule 942430 often triggered on the code parameter, while rule 942440 flagged the id_token parameter—both located in the request body. To address this in a granular way, we created exclusion lists so that 942430 ignores code in the request body and 942440 ignores id_token in the request body. This ensures that WAF still inspects all other fields and traffic for malicious patterns, but no longer incorrectly penalizes these legitimate Entra External ID tokens. Below are screenshots illustrating these exclusions in action: Excluding in_code Parameter from SQL Comment Sequence Detection: Excluding code Parameter from SQL Comment Sequence Detection: Custom Rules Custom rules give you finer control over how the WAF handles requests - beyond what you can configure with exclusions or default managed rules. You can allow or block specific traffic patterns based on conditions such as request path, HTTP method, header contents, or query parameters. For a straightforward scenario, you might match the path /.auth/login/aad/callback (or whichever callback path your app uses), set the Action to Allow, and give the custom rule a lower priority so it’s evaluated first. This ensures legitimate Entra External ID traffic bypasses the SQL injection checks. If your tokens or parameters follow a partially predictable pattern (for instance, a certain prefix or structure in the base 64-encoded string), you can use regex matching in your custom rule to be more selective. For example, you might match the request parameter code with a regex like ^[A-Za-z0-9_-]+(\.[A-Za-z0-9_-]+)*$, which loosely allows base 64 token formats. This approach is handy if you notice tokens often trigger a variety of sub-rules. By allowing only the known safe format you drastically cut false positives while still blocking anything that strays from the legitimate pattern. Whether you’re using simple path matches or advanced regex, carefully scope your conditions—limit them to the specific parameters or paths you know are safe. A broad “Allow everything that includes ‘callback’” could inadvertently open a hole for real attacks. Change Rule Actions In some cases, you may prefer to keep the relevant rule enabled but change its action from Block to Log. This ensures that even if the rule matches, the request isn’t automatically blocked—rather, it’s logged for further investigation. If you later identify genuine threats in these tokens, you can revert to a stricter rule action or add more precise exclusions. Disable Specific Rules In some cases, you may decide that certain rules (for example, those repeatedly generating false positives but offering little relevant protection for your application) should be disabled entirely. This approach is generally a last resort because it removes that protective layer for all traffic rather than targeting just the problematic parameters. However, in our scenario, the two problematic rules - 942430 (Restricted SQL Character Anomaly Detection) and 942440 (SQL Comment Sequence Detected) - are disabled or replaced by default in DRS 2.1. If you’re seeing them trigger, you may be on an older rule set or a configuration where they remain active. Disabling them manually in the Managed Rule Set will stop the false positives, but you should monitor your WAF logs closely for genuine attacks that might have otherwise been caught by those rules. Where possible, consider upgrading to the latest rule set which often addresses these issues by default. Evaluate the Paranoia Levels Paranoia levels (PL) determine how aggressively rules in the OWASP Core Rule Set (CRS) detect and block potential threats in a Web Application Firewall (WAF). OWASP CRS defines four paranoia levels (PL1–PL4), each offering progressively stricter security controls: PL1 (Default): Offers baseline protection against common web attacks, minimizes false positives, and is appropriate for most applications. PL2: Adds additional rules targeting more sophisticated threats, which may result in more false positives. PL3: Provides stricter rules suitable for applications requiring high security, though these typically require extensive tuning. PL4: Implements the most aggressive security rules, suitable for highly secure environments, requiring extensive management and tuning efforts. For more detailed explanations of each paranoia level, refer to the OWASP CRS Paranoia Levels documentation. The Azure WAF managed rulesets - DRS 2.1 and CRS 3.2 – each contain rules with an assigned paranoia level. By default, these rulesets contain rules that include paranoia levels 1 and 2 (PL1 and PL2). To reduce false positives, you can either disable specific PL2 rules or set their action to 'log' instead of blocking. Azure WAF currently does not support rules from paranoia levels 3 and 4. For more information on Azure WAF paranoia levels refer to Azure Front Door WAF paranoia levels. In our scenario, rules 942430 and 942440 are classified under PL2 and carry a default anomaly score of 5. Triggering either rule individually exceeds the anomaly scoring threshold, causing legitimate authentication requests - such as those from OAuth/OpenID Connect flows used by Entra External ID - to be inadvertently blocked. To manage and reduce these false positives effectively: Initially configure your Azure WAF policy to use only PL1 rules to significantly lower the likelihood of false positives. Review and selectively re-enable necessary PL2 rules after analyzing WAF logs, applying specific exclusions or custom rules as described in the remediation section. Conclusion Azure Web Application Firewall (WAF) provides robust protection against web threats. However, when integrating with Microsoft Entra External ID for authentication, careful tuning is essential to avoid false positives that disrupt legitimate user access. By reviewing WAF logs, creating precise exclusions, implementing targeted custom rules, and leveraging the latest managed rule sets, organizations can optimize their security posture while ensuring smooth authentication experiences. Proper WAF tuning maintains a crucial balance between application security and user experience References Configure Microsoft Entra External ID with Azure Web Application Firewall - Microsoft Entra External ID | Microsoft Learn Tune Azure Web Application Firewall for Azure Front Door | Microsoft Learn Troubleshoot - Azure Web Application Firewall | Microsoft Learn Azure Web Application Firewall DRS rule groups and rules | Microsoft Learn Azure WAF tuning with AD B2C applications | Microsoft Community Hub
Azure WAF Integration in Security Copilot is Now Generally Available
We’re excited to announce the general availability (GA) of Azure Web Application Firewall (WAF) integration with Microsoft Security Copilot. This marks a significant advancement in web application protection, bringing together Azure WAF’s industry-leading defense with the AI-powered capabilities of Security Copilot to transform how security teams detect, investigate, and respond to threats. Why This Integration Is a Game-Changer Modern web applications face relentless threats - from SQL injections and cross-site scripting (XSS) to bot attacks and sophisticated Layer 7 DDoS attempts. Defending against these threats requires more than just reactive measures; it demands intelligent, scalable solutions. With Azure WAF now integrated into Security Copilot, security teams can gain: Proactive threat analysis: Quickly uncover attack patterns and identify emerging threats. Optimized WAF configurations: Use AI insights to fine-tune rules and policies. Accelerated investigations: Leverage Copilot’s generative AI to streamline incident triage and response. This integration enables teams to work smarter and faster - turning raw data into actionable intelligence with the help of natural language prompts and AI-guided workflows. Seamless Protection Across Azure Platforms Azure WAF protects applications behind Azure Front Door and Azure Application Gateway, offering centralized, cloud-native security at scale. Now, with Security Copilot, analyzing WAF diagnostic logs no longer requires manual parsing or deep scripting expertise. Instead, AI delivers contextual insights directly to your SOC teams, cloud admins, and DevSecOps engineers. Whether you're investigating blocked requests or tuning security policies, this integration helps reduce operational overhead while strengthening your overall security posture. What Can You Do with Azure WAF in Security Copilot Let’s explore some of the core capabilities now available: SQL Injection (SQLi) Attack Analysis Understand why Azure WAF blocked specific SQLi attempts through detailed summaries of diagnostic logs and correlation of related events over time. Cross-Site Scripting (XSS) Attack Insights Get clear explanations for WAF’s enforcement actions against XSS attacks, with trend analysis across your environment. Top Offending IPs Analysis Identify the most malicious IPs triggering WAF rules, along with insights into the behaviors and rule patterns that led to their blocking. Most Triggered Rules and Actions Gain visibility into your most active WAF rules - helping prioritize tuning efforts and enhance threat detection effectiveness. These capabilities are designed to turn WAF data into actionable knowledge - without the need for custom queries or extensive log review. Built for the Future of Intelligent Security As threats continue to evolve, so must our defenses. The Azure WAF and Security Copilot integration represents the next generation of web application protection - combining automation, AI reasoning, and expert knowledge to deliver adaptive security at cloud scale. By augmenting your team with AI, you can stay ahead of attackers, protect critical apps, and respond faster than ever before. Learn More and Get Started The GA of Azure WAF integration in Microsoft Security Copilot is more than just a feature release - it’s a new paradigm for web application security. Explore the capabilities today by visiting the Azure WAF documentation. Want to talk to us? Reach out to the Azure WAF product team to share feedback or request a demo. Let’s build a more secure web, together.Mastering Regex with GitHub Copilot for Enhanced Azure WAF Security
Written in collaboration with davidfrazee Introduction Azure Web Application Firewall (WAF) is a cloud native security service that provides protection for web applications from common exploits and vulnerabilities. It provides centralized protection for applications hosted on Azure Front Door and Azure Application Gateway ensuring that malicious traffic is detected and blocked before reaching the application backend. Azure WAF leverages managed rulesets to actively protect web applications from threats and attacks. These rule sets are maintained by Azure, with the Default Ruleset (DRS) including rules from the Microsoft Threat Intelligence Collection, ensuring enhanced coverage, specific vulnerability patches, and improved false positive reduction. In addition to the managed rulesets, Azure WAF offers custom rules that enable you to create your own rules. With custom rules, you can set conditions based on attributes such as IP addresses, HTTP headers, and query strings to precisely control which traffic is allowed or blocked, providing flexibility and granularity. Within the custom rules, you can incorporate regex, which offers enhanced accuracy when matching patterns in your traffic. Regex (regular expressions) enable you to define complex conditions, allowing for highly specific filtering of incoming requests. Working with regex can sometimes be challenging due to its non-intuitive syntax. In this blog, we will demonstrate a practical, step-by-step approach for generating regex patterns using GitHub Copilot, refining them on Regex101, and validating their effectiveness in Azure WAF. This process helps ensure that your custom rules with regex work as intended, thereby enhancing your overall security effectiveness. GitHub Copilot GitHub Copilot is an AI-powered code completion tool developed by GitHub in collaboration with OpenAI. It assists developers by suggesting code snippets, functions, and even entire blocks of code as they type. By leveraging machine learning models trained on a vast amount of public code, GitHub Copilot can understand the context of the code being written and provide relevant suggestions, making the coding process faster and more efficient. Prompting GitHub Copilot can be particularly useful for security professionals. Enhanced code quality is one of the benefits, as GitHub Copilot can help security professionals write cleaner and more secure code by identifying potential vulnerabilities and suggesting best practices for secure coding, thus reducing the risk of introducing security flaws. Additionally, it offers time efficiency, as security professionals often need to write scripts or tools to automate security tasks, and GitHub Copilot can speed up this process by generating code snippets based on the prompts provided, allowing professionals to focus on more critical aspects of their work. GitHub Copilot can also assist in creating regex code, which is often complex and challenging to write. By providing accurate regex patterns based on prompts, it can help security professionals quickly develop effective text manipulation and pattern matching solutions. While AI-generated content can significantly streamline the process of creating regex patterns, it is important to verify the accuracy of these patterns to ensure they work as intended. Tools such as Regex101 provide a valuable platform for refining and validating regex patterns, helping to identify and correct any errors before implementation. What is Regex? Regular expressions, commonly known as regex, are sequences of characters that define search patterns. They are used in various programming languages and tools to match, locate, and manage text. Regex is incredibly powerful because it allows for complex text manipulation and pattern matching, making it an essential tool for tasks such as data validation, parsing, and transformation. However, regex can be difficult to learn due to its intricate syntax and the need for precise pattern construction. The learning curve is steep because even small mistakes can lead to unexpected results or errors. Additionally, regex patterns can become quite complex, requiring a deep understanding of both the syntax and the specific text being manipulated. Despite these challenges, regex is invaluable in the field of security. It can be used to detect and prevent malicious activities by identifying patterns associated with attacks, such as SQL injections or cross-site scripting. Regex can also help in filtering user inputs, ensuring that only safe and valid data is processed. Its ability to analyze large volumes of text swiftly and accurately makes it a powerful tool for security professionals aiming to protect systems and data from threats. Creating & Validating Regex Patterns Now that we have explored the capabilities of GitHub Copilot and the intricacies of regex, it is time to put this knowledge into practice. In the following steps, we will guide you through the process of leveraging GitHub Copilot to create and validate regex patterns effectively. By combining the power of AI-driven code suggestions with the precision of regex, you will be able to enhance your security tasks, automate complex text manipulations, and ensure robust data validation. Let us dive into the practical steps to get this done and see how these tools can streamline your workflow and bolster your security measures. To get started with GitHub Copilot, navigate here. We are going to leverage GitHub Copilot through Visual Studio Code (VSC). Once you have completed the requirements from the link above and you have enabled the extension, you can start prompting GitHub Copilot Chat. Prompt: Create two unique regex patterns. The first pattern should match any of the following words: "l33t", "h@x0r", "kewl", and "n00b", but the characters can be case insensitive. The second pattern should match the string of special characters "!@#$" followed by any integer that comes after the symbol "&". Response: Here are the two regex patterns: To match any of the words "l33t", "h@x0r", "kewl", and "n00b" in a case-insensitive manner: (?i)\b(l33t|h@x0r|kewl|n00b)\b To match the string of special characters "!@#$" followed by any integer that comes after the symbol "&": !@#\$&\d+ Now that GitHub Copilot has delivered 2 unique regex strings for use in our Azure WAF, let’s verify if the regex patterns work with the use of https://regex101.com. Regex101.com is an online platform designed to help users create, test, and debug Regex. It provides a user-friendly interface where you can input your regex patterns and evaluate them against sample text to see how they match. The site offers real-time feedback, highlighting matches and providing detailed explanations of each part of the regex pattern. This makes it an invaluable tool for both beginners learning regex and experienced users fine-tuning their patterns. Additionally, Regex101.com supports multiple regex flavors, including PCRE, JavaScript, and Python, allowing users to work with the syntax specific to their needs. Above, we see how we are validating the regex pattern at Regex101.com. I paste my regex pattern provided by GitHub Copilot at the top and then enter a JSON test body to match against the pattern. The tool verifies that the first regex pattern captures malicious attempts without case sensitivity and provides a detailed breakdown on the right side. This breakdown includes explanations of each part of the regex, helping to ensure that the pattern is correctly identifying the intended matches and highlighting any potential issues. In another example, we are using Regex101.com to validate a regex pattern aimed at identifying strings of unique characters. The tool verifies that the regex pattern successfully captures the string where each character appears only once and in order, followed by an integer. On the right side, Regex101.com provides a detailed breakdown of the regex pattern, explaining how each part contributes to the overall match. Now that we have validated the regex patterns with Regex101.com, let us implement them into Custom rules for Azure WAF. Using Regex with Azure WAF Having validated the regex patterns with Regex101.com, we can now proceed to implement these patterns into Custom rules for Azure WAF. This section provides a guide on integrating the validated regex patterns into your Azure WAF configuration to enhance web application security. By establishing these custom rules, you can tailor protection to meet specific requirements, ensuring malicious attempts are effectively intercepted and blocked. First, we will navigate to the Custom rules section of our Azure WAF policy, and author the two regex rules that we want to use to identify special patterns in request bodies going through our WAF. What is unique about using regex in Custom rules, is that you select Regex as an Operator in the Condition. From there, you will enter your regex pattern in the Match values section, select the action and the Custom rule is complete. After implementing the custom regex rules into Azure WAF, we executed a simulated malicious attempt to evaluate their effectiveness. The WAF, equipped with our regex patterns, successfully detected and intercepted the attack. The custom rules accurately identified the malicious activity and promptly blocked it, demonstrating the power and precision of using AI-generated regex patterns to enhance security measures. After executing the simulated malicious attempt, we examined the Azure WAF logs to confirm the effectiveness of our custom regex rules. The logs clearly indicated that the attack was intercepted, with the highlighted rule name and match value providing specific details about the block. This information is crucial for verifying that the custom rules are functioning as intended and accurately identifying malicious activities. By reviewing these logs, we can ensure that our security measures are robust and capable of protecting against potential threats. The detailed log entries not only confirm the success of our regex patterns but also offer insights into further refining and optimizing our security configurations. Conclusion Leveraging GitHub Copilot to generate regex patterns and validating them on Regex101.com before applying them to Azure WAF showcases the remarkable synergy between AI and security practices. By utilizing GitHub Copilot's intelligent code suggestions, we can efficiently create complex regex patterns tailored to our specific needs. Validating these patterns on Regex101.com ensures their accuracy and effectiveness in capturing malicious attempts. Once applied to Azure WAF, these regex patterns enhance our security measures, providing robust protection against potential threats. Testing and observing the impact of these AI-generated regex strings highlight the power and value of integrating AI into our security workflows. This approach not only streamlines the process but also demonstrates how AI can significantly contribute to hardening security, making it an efficient and worthwhile endeavor. References Introduction to Azure Web Application Firewall | Microsoft Learn What is Azure Web Application Firewall on Azure Application Gateway? | Microsoft Learn What is Azure Web Application Firewall on Azure Front Door? | Microsoft Learn Create and use v2 custom rules - Azure Web Application Firewall | Microsoft Learn GitHub CopilotComprehensive Guide to Monitoring Azure WAF Metrics and Logs
In today’s digital landscape, web applications are constantly under threat from various types of attacks such as SQL injection, cross-site scripting (XSS), and distributed denial-of-service (DDoS) attacks. Azure Web Application Firewall provides robust mechanisms to protect your applications and services against such threats. In this blog post, we’ll explore how to configure and monitor Azure WAF metrics and logs for both Application Gateway v2 WAF and Azure Front Door WAF and demonstrate how to fully utilize the available metrics/logs to monitor your web applications for potential threats. Understanding Azure WAF Metrics Azure WAF offers a variety of metrics that provide insights into potential threats targeting your resources. These metrics are accessible through Azure Monitor and can be used to set up alerts and automated responses. Key metrics include: Application Gateway v1 WAF Metrics: Web Application Firewall Blocked Requests Count: Count of total requests that have been blocked by the WAF engine. Web Application Firewall Blocked Requests Distribution: Total number of rules hit distribution for the blocked requests by Rule Group and Rule ID. Web Application Firewall Total Rule Distribution: Count of total matched requests distribution by Rule Group and Rule ID. Note: The Application Gateway v1 SKU (Standard and WAF) was deprecated on April 28, 2023 and will be retired on April 28, 2026. Customers on the v1 SKU are advised to migrate to the v2 SKU. For more details, please refer to - Migrate from V1 to V2 - Azure Application Gateway | Microsoft Learn Application Gateway v2 WAF Metrics: WAF Total Requests: Count of successful requests that the WAF engine has served. WAF Managed Rule Matches: Count of total managed rule matches. WAF Custom Rule Matches: Count of custom rule matches. WAF Bot Protection Matches: Count of total bot protection rule matches that have been blocked or logged from malicious IP addresses. WAF JS Challenge Request Count: Count of requests that match JavaScript challenge WAF rules. Azure Front Door WAF Metrics: Web Application Firewall Request Count: Tracks the number of requests that match WAF rules. Web Application Firewall JS Challenge Request Count: Tracks the number of requests that match JavaScript challenge WAF rules. Note: These metrics are not found in the WAF policy resource but in the Application Gateway or Azure Front Door resource themselves. Steps to Monitor WAF Metrics Navigate to Azure Monitor: Sign in to the Azure portal and go to Azure Monitor. Select Metrics: In the Azure Monitor menu, select “Metrics.” Choose Scope: Select the scope by choosing the subscription and the specific WAF resource you want to monitor. Add Metric: Click on “Add metric” and select the desired metric, such as “WAF Total Requests” or “Web Application Firewall Request Count.” Set Aggregation Type: Choose the aggregation type. Configuring Alerts Configuring alerts for Azure WAF metrics is crucial for proactive monitoring and quick response to potential threats. Here are detailed steps to set up alerts: Navigate to Azure Monitor: Sign in to the Azure portal and go to Azure Monitor. Select Metrics: In the Azure Monitor menu, select “Metrics.” Choose Scope: Select the scope by choosing the subscription and the specific WAF resource you want to monitor. Add Metric: Click on “Add metric” and select the desired metric, such as “WAF Total Requests” or “Web Application Firewall Request Count.” Set Aggregation Type: Choose the aggregation type (e.g., Sum, Average, Maximum). Configure Alert Rule: Click on “New alert rule.” Set the signal name (e.g., “WAF Request Count Alert”). Select the aggregation type (e.g., Maximum). Choose the operator (e.g., “Greater than or equal to”). Select the unit (e.g., Count). Set the threshold value based on the average traffic you see in the chart, choosing a value lower than the WAF threshold. Click “Next” and under the Actions tab, choose how you want to be notified (e.g., email, SMS, webhook). Click on “Review + create.” WAF Alert example and use case With the increasing threat of DDoS attacks, it's vital to have alerting systems in place that keep you informed about any unusual activities in your web environment. By setting targeted alerts, you can quickly identify and address potential threats. Here's a practical example to demonstrate this. Suppose you want to be alerted about potential DDoS attacks targeting your web environment. For this scenario, we have a custom rule named "RateLimitRequest." This rule is designed to limit the number of requests to 400 within a 5-minute window, grouping the traffic by client address. This helps in identifying and mitigating potential threats from specific IP addresses. To ensure you are promptly notified of any potential DDoS attacks without enabling alerts for all rules, you can create a targeted alert based on the metric "WAF Custom Rule Match." Here's how you can configure it: Select the Signal: Navigate to the Alert page and choose "WAF Custom Rule Match" as the signal. This metric tracks the matches for your custom WAF rules. Configure Dimensions: In the "Split by dimensions" section, select "Rule name" as the dimension name. This allows you to filter the alerts based on specific rules. Set the Operator and Value: Set the operator to "=" and enter "RateLimitRequest" as the dimension value. This ensures that the alert is triggered only for the specified custom rule. In this example, I’ve configured a notification to be sent only through email. However, you can also set up notifications via SMS, the Azure Mobile app, or voice calls. Besides receiving notifications from alerts, you can configure the system to trigger various actions such as an Automation runbook, Azure Function, or Logic App. This allows you to, for instance, automatically create a ticket for the SOC team immediately through the alert rule action. By configuring the alert in this manner, you will receive notifications whenever the rate limit rule is triggered beyond a certain threshold. This indicates that a few client IPs are being blocked due to rate limiting, which could be a sign of a potential DDoS attack. Being promptly alerted allows you to take necessary actions to protect your web environment from such threats. Configuring logging In addition to monitoring metrics, logging plays a crucial role in maintaining the security and performance of your web applications. While metrics provide a high-level overview of your application's health and potential threats, logs offer detailed insights into specific events and activities. By using both metrics and logs together, you can gain a comprehensive understanding of your application's behavior, quickly identify and respond to security incidents, and ensure optimal performance. Enabling Application Gateway WAF logs To configure logging for workspace analytics for Application Gateway WAF, follow these steps: Navigate to Azure Portal: Sign in to the Azure portal. Select Application Gateway Resource: Go to your Application Gateway resource. Diagnostic Settings: Under the 'Monitoring' section, select 'Diagnostic settings'. Add Diagnostic Setting: Click on 'Add diagnostic setting'. Configure Logs: Select the logs you want to collect, such as 'ApplicationGatewayAccessLog', 'ApplicationGatewayPerformanceLog', and 'ApplicationGatewayFirewallLog' and make sure to select the 'Application Gateway Firewall Log' category to get WAF logs. Destination: Choose the destination for the logs. You can send them to a Log Analytics workspace, an Event Hub, or a Storage Account. Save: Click 'Save' to apply the settings. Note: The Application Gateway supports both Azure diagnostics tables and resource-specific tables. Make sure to use the correct query. For example, if you send logs to an Azure diagnostics table and query “AGWFirewallLogs,” you will not get any results. Enabling Azure Front Door WAF logs To set up logging for workspace analytics for Azure Front Door WAF, follow these steps: Navigate to Azure Portal: Sign in to the Azure portal. Select AFD Resource: Go to your Azure Front Door resource. Diagnostic Settings: Under the 'Monitoring' section, select 'Diagnostic settings'. Add Diagnostic Setting: Click on 'Add diagnostic setting'. Configure Logs: Choose the logs you want to collect by selecting the categories: 'FrontDoor Access Log', 'FrontDoor Health Probe Log', and 'FrontDoor WebApplicationFirewall Log'. Ensure you select the 'FrontDoor WebApplicationFirewall Log' category to capture WAF logs. Destination: Choose the destination for the logs. You can send them to a Log Analytics workspace, an Event Hub, or a Storage Account. Save: Click 'Save' to apply the settings. Running KQL queries Kusto Query Language (KQL) is a powerful tool for querying and analyzing data in Azure Monitor logs. Logs can be accessed directly under the resource, such as Application Gateway or Front Door, by navigating to the Logs section. Alternatively, you can query the logs from your Log Analytics workspace. Below are some useful KQL queries for monitoring Azure WAF metrics, along with scenarios to help you understand their use cases. Identify Top IP Offenders To identify the top IP addresses that are being blocked by your Azure WAF, you can use the following query for Application Gateway WAF logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | summarize count() by clientIp_s | top 10 by count_ Scenario: Suppose you notice an unusual spike in blocked requests on your Azure WAF. You want to identify the top IP addresses that are being blocked to understand if there is a targeted attack from specific IPs. This query will help you list the top offending IP addresses, allowing you to take further action, such as blocking these IPs at the firewall level. Azure Front Door WAF Query To monitor the top IP addresses being blocked by Azure Front Door WAF, use this query: AzureDiagnostics | where Category == "FrontDoorWebApplicationFirewallLog" | summarize count() by clientIP_s | top 10 by count_ Top Five Matched Rules To understand which WAF rules are being triggered the most, you can use the following query for Application Gateway WAF logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | summarize count() by ruleId_s | top 5 by count_ Scenario: You want to identify potential focused attacks or false positives by understanding which WAF rules are being triggered the most. By running this query, you can see the top five rules with the highest number of matches. This information can help you fine-tune your WAF rules to reduce false positives or strengthen your defenses against specific attack vectors. Azure Front Door WAF Query To monitor the top rules being triggered by Azure Front Door WAF, use this query: AzureDiagnostics | where Category == "FrontDoorWebApplicationFirewallLog" | summarize count() by ruleName_s | top 5 by count_ Matched/Blocked Requests by URI To understand which parts of your web application are being targeted the most, use this query to identify the top URIs that are being matched or blocked by the Application Gateway WAF logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | project TimeGenerated, clientIp_s, requestUri_s, ruleId_s, action_s, Message | summarize count() by requestUri_s | top 10 by count_ This query helps you pinpoint vulnerable areas of your application by identifying the top URIs that are being matched or blocked by the WAF. You can then take appropriate measures to secure these areas. Azure Front Door WAF Query To monitor the top URIs being matched or blocked by Azure Front Door WAF, use this query: AzureDiagnostics | where Category == "FrontDoorWebApplicationFirewallLog" | project TimeGenerated, clientIP_s, requestUri_s, ruleName_s, action_s, details_msg_s | summarize count() by requestUri_s | top 10 by count_ Best Practices for Monitoring WAF Metrics and Logs Enable Logging: Ensure that logging is enabled for all WAF resources. This includes enabling diagnostic logs and integrating them with Azure Monitor logs. Use Managed Rules: Utilize managed rules provided by Azure WAF to protect against common threats. Regularly update these rules to ensure they cover the latest vulnerabilities. Set Up Alerts: Configure alerts for critical metrics such as “WAF Managed Rule Matches” and “WAF Custom Rule Matches” to get notified of potential threats in real-time. Regularly Review Logs: Periodically review WAF logs to identify patterns and trends in the traffic. This helps in fine-tuning the WAF rules and improving the overall security posture. Implement Exclusions: Use exclusions to fine-tune rules and exclude any data that you want to be excluded from the logs. This helps in reducing false positives and focusing on actual threats. Monitor Traffic Thresholds: Compare your real traffic to the thresholds set by Azure WAF to determine if you are close to or far from them. Adjust the thresholds as needed to suit your environment and downstream architecture. Integrate with SIEM/SOAR: Utilize Azure Sentinel for creating Workbooks and automating responses to threats. This integration allows for enhanced monitoring and automated threat response, ensuring a more robust security posture. For more details, you can refer to https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Real-World Scenarios for WAF Metrics and Logs High Volume of Requests: If you notice a sudden spike in the “WAF Total Requests” metric, it could indicate a potential DDoS attack. Setting up alerts for this metric can help you respond quickly to mitigate the attack. To configure WAF for high volume of requests: Scaling: Ensure your Application Gateway is set to auto scale. For Application Gateway v2 SKU, set the maximum instance count to the maximum possible value of 125 to handle traffic surges. Rate Limiting: Implement rate limiting to control the number of requests from specific IP addresses or geographies. Frequent Rule Matches: A high number of matches for “WAF Managed Rule Matches” or “WAF Custom Rule Matches” could indicate that your application is being targeted by specific types of attacks. Reviewing the logs and adjusting the rules can help in blocking these attacks more effectively. To configure WAF for frequent rule matches: Custom Rules: Create custom rules to block or allow traffic based on specific criteria. For example, you can block all requests from a specific IP address range. Detection Mode: Set the WAF policy to detection mode to log requests that match custom rules without blocking them, allowing you to analyze the traffic patterns. Bot Protection: If the “WAF Bot Protection Matches” metric shows a high count, it could indicate that your application is being targeted by malicious bots. Implementing bot protection rules and monitoring this metric can help in blocking these bots and protecting your application. To configure WAF for bot protection: Bot Protection Rule Set: Enable the managed bot protection rule set in your WAF policy to block or log requests from known malicious IP addresses. JavaScript Challenge: Enable the JavaScript challenge action for bot rules. This helps in blocking bots and reducing false positives by challenging requests that match specific criteria. JavaScript Challenge: The “WAF JS Challenge Request Count” metric tracks the number of requests that match JavaScript challenge WAF rules. A high count could indicate that your application is being targeted by automated scripts. Monitoring this metric and adjusting the challenge rules can help in mitigating such attacks. Key Takeaways Azure Web Application Firewall offers robust protection mechanisms for web applications. By monitoring Azure WAF metrics, you can gain valuable insights into the security and performance of your web applications. Proactively monitoring and analyzing WAF logs using Kusto Query Language (KQL) helps identify and mitigate potential threats. This approach ensures your web applications remain secure and performant, providing a seamless experience for your users. Understanding and fine-tuning WAF policies and rules reduce false positives and focus on actual threats. Regularly reviewing WAF logs helps identify patterns and trends, improving your security strategies continuously. In conclusion, staying vigilant and proactive in your WAF protection strategy is essential for ensuring uninterrupted service delivery and safeguarding your web applications from potential threats. By fully utilizing the available metrics and logs, you can effectively monitor and protect your resources, providing a secure and reliable experience for your users. References Monitoring metrics for Azure Application Gateway Web Application Firewall metrics | Microsoft Learn Azure Monitor metrics for Application Gateway | Microsoft Learn Azure Web Application Firewall monitoring and logging | Microsoft Learn https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinelAzure WAF’s Bot Manager 1.1 and JavaScript Challenge: Navigating the Bot Threat Terrain
Discover how Azure WAF’s Bot Manager 1.1 and the JavaScript Challenge elevate your bot protection strategy. In this blog, we explore how these advanced features in Azure Front Door and Application Gateway provide a robust defense against malicious bots while ensuring legitimate traffic flows smoothly. Learn how to fine-tune your web application’s security to safeguard against evolving bot threats without compromising on performance.
WAF custom rule for bock others cookie and permit only a specific cookie name and value
Hello all, I need to create a custom WAF rule that only allows traffic for a specific request URI (/example-path) if it contains a particular cookie, Cookie=abc123, and blocks all other requests. Additionally, could someone clarify the difference between configuring the policy this way: RequestHeaders['Cookie'], Operator=DoesNotEqual, Values="Cookie=abc123" RequestCookie, Values="CookieName", Operator=Equal, valueOfTheCookie="abc123" I hope I explained myself clearly. Thanks in advance for your responses!
