Design and implement a Web Application Firewall (WAF) deployment

Hollins Travel has an Application Gateway WAF_v2 named agw-book whose WAF policy still uses OWASP CRS 3.1. The security team wants to move to the latest Microsoft-recommended managed rule set version for Application Gateway, which uses anomaly scoring and includes the rules developed by the Microsoft Threat Intelligence team, and to add the bot protection rule set so that known bad bots are blocked alongside OWASP-style attacks.

Which managed rule sets should you configure in the WAF policy?

1. ADRS 2.2 together with Microsoft_BotManagerRuleSet 1.1.DRS 2.2 is the latest and recommended Application Gateway rule set; it is baselined on OWASP CRS 3.3.4, runs on the anomaly scoring engine, includes the Microsoft Threat Intelligence rule groups, and can be combined with the Bot Manager rule set.
2. BOWASP CRS 3.0 together with Microsoft_BotManagerRuleSet 1.0.CRS 3.0 runs on the older engine without anomaly scoring and lacks the Microsoft Threat Intelligence rules; it is far from the latest version.
3. CDRS 2.1 together with Microsoft_BotManagerRuleSet 1.1.DRS 2.1 (baselined on CRS 3.3.2) is still supported and also uses anomaly scoring with Microsoft Threat Intelligence rules, but it has been superseded by DRS 2.2, which Microsoft recommends for new policies and upgrades; the scenario asks for the latest version.
4. DOWASP CRS 3.2 together with OWASP CRS 3.1 to combine the rule coverage of both versions.A WAF policy can have only one core rule set version active at a time, and neither CRS 3.1 nor CRS 3.2 includes the Microsoft Threat Intelligence rule groups.

Saltmarsh Bank runs its online banking portal behind Azure Front Door Premium with a WAF policy named wafp-fd-bank. Requirements: protect against OWASP-style attacks using the newest Microsoft-managed rules; block requests identified as known malicious bots; block all traffic from countries other than the United Kingdom and Ireland; and limit each client IP address to 100 requests per minute on the path /api/login.

How should you configure wafp-fd-bank?

1. AAdd the Microsoft_DefaultRuleSet 2.2 and Microsoft_BotManagerRuleSet 1.1 managed rule sets; add a custom match rule with GeoMatch not in GB or IE with action Block; add a custom rate limit rule on RequestUri contains /api/login with a 100-request threshold per 1 minute and action Block.Front Door WAF supports DRS 2.2 (the newest Default Rule Set, baselined on OWASP CRS 3.3.4) and the Bot Manager rule set as managed rules, geo-filtering through GeoMatch custom rules, and rate limiting as a custom rule type with a per-client threshold.
2. BAdd the OWASP_CRS 3.2 and Microsoft_BotManagerRuleSet 1.1 managed rule sets; add a custom rule with GeoMatch for GB and IE with action Block; add a rate limit rule with a 100-request threshold.OWASP CRS 3.2 is an Application Gateway rule set and is not available on Front Door; also, a GeoMatch rule that blocks GB and IE inverts the requirement.
3. CAdd the Microsoft_DefaultRuleSet 2.2 managed rule set; enable Front Door caching to absorb excess requests to /api/login; use Azure Firewall Premium web categories to block non-UK traffic.Caching does not enforce a per-client request limit on a login endpoint, and Azure Firewall web categories classify sites by content, not client country.
4. DDowngrade to Front Door Standard, add the Microsoft_DefaultRuleSet 2.2 managed rule set, and add rate limit and GeoMatch custom rules to minimize cost.Managed rule sets, including DRS 2.2 and Bot Manager, require Front Door Premium; the Standard tier WAF supports only custom rules.

Pellworth Media has an Application Gateway WAF_v2 named agw-media with one HTTPS listener and a path-based routing rule that sends /api/* to an API backend pool and everything else to a web backend pool. A WAF policy named wafp-default (DRS 2.1, Prevention mode) is associated with the gateway. The API team needs a different policy named wafp-api that disables rule group REQUEST-920-PROTOCOL-ENFORCEMENT for the /api/* traffic only, while all other traffic must continue to use wafp-default. The company wants to avoid deploying additional gateways or listeners.

How should you associate wafp-api?

1. AAssociate wafp-api with the /api/* path rule of the path-based routing rule.Application Gateway supports per-URI WAF policies: a policy associated with a path rule overrides the gateway-level policy for requests matching that path only.
2. BAssociate wafp-api with the HTTPS listener.A listener-level policy applies to every request arriving on that listener, including the web paths, so all traffic would lose the protocol enforcement rules.
3. CAssociate both wafp-default and wafp-api with agw-media at the gateway level and order them so wafp-api is evaluated first for /api/* requests.Only one WAF policy can be associated at a given scope; there is no ordering of multiple gateway-level policies.
4. DCreate a second Application Gateway WAF_v2 for the API, associate wafp-api with it, and update DNS so api.pellworth.example resolves to the new gateway.This works but adds a second gateway and DNS change, which the company explicitly wants to avoid when path-rule association achieves the same result.

Mirabel Health runs a patient portal behind an Application Gateway WAF_v2 named agw-portal with a WAF policy named wafp-portal using DRS 2.1 in Prevention mode. Three problems were reported. First, legitimate requests are blocked because a cookie named SessionData contains base64 text that triggers SQL injection rule 942440. Second, the path /account/login is being brute-forced from many IP addresses, each sending about 300 requests per minute. Third, the path /admin must be reachable only from the company office range 198.51.100.0/24. The policy must remain in Prevention mode with the managed rules otherwise unchanged.

Which three changes should you make to wafp-portal? Each correct answer presents part of the solution.

1. AAdd a per-rule exclusion for rule 942440 with match variable RequestCookieNames, operator Equals, selector SessionData.A per-rule exclusion removes only the named cookie from inspection by the one rule producing the false positive, keeping all other protection intact.
2. BAdd a custom rate limit rule with priority 10 matching RequestUri contains /account/login, grouped by client address, with a threshold of 100 requests per 1 minute and action Block.Rate limit custom rules on Application Gateway WAF v2 block clients that exceed a request threshold per window, which stops the brute-force pattern without affecting normal users.
3. CAdd a custom match rule with priority 20 that blocks requests where RequestUri begins with /admin and RemoteAddr is not in 198.51.100.0/24.A custom match rule combining the URI and a negated IP match restricts the admin path to the office range while leaving the rest of the site unaffected.
4. DDisable the entire REQUEST-942-APPLICATION-ATTACK-SQLI rule group so the cookie is no longer inspected.Disabling the whole SQL injection rule group removes protection from every request parameter, which is far broader than the single-cookie false positive and violates the requirement to leave managed rules otherwise unchanged.
5. ESwitch wafp-portal to Detection mode so the false positive no longer blocks patients.Detection mode stops all blocking, including the brute-force and admin restrictions, and the scenario requires the policy to stay in Prevention mode.