The three previous lessons have closed off the inside of the platform: governed identities, minimal permissions and no exposed secrets. None of that protects Contoso Bookings from what comes in through the front door. It is a public ticket-selling website, so anybody with a connection can throw requests at it, and some of them are not looking to buy a flight. A denial-of-service attack on the eve of a long weekend bills zero euros in sales and plenty in reputation; a SQL injection that slips past the code reaches db-reservas; and a bot that checks prices every second distorts availability and drains the seats into carts without buying any. Today you build the perimeter: DDoS protection at the network layer and a web application firewall on fd-contoso-global, with the realistic rollout process that keeps you from blocking your own customers.

Important cost warning: this is the most expensive module in the course. DDoS Network Protection costs on the order of €2,700 a month per tenant (covering up to 100 public IP addresses), and the Front Door WAF adds a fixed monthly fee on the order of €250–300 plus a cost per rule and per million requests. These are not services you turn on "just to try them". To practice, stay on the free infrastructure protection, create the WAF policy in detection mode on the lowest tier and delete it when you finish.

1. What attacks reach a ticket-selling website
2. Azure DDoS Protection: free versus the paid tiers
3. Web application firewall: where it is deployed
4. The OWASP managed rule set
5. Custom rules: bots, geography and IP lists
6. Detection versus prevention: the realistic rollout
7. Deploying the WAF policy on Front Door with the CLI
8. The network protection layers compared
9. Azure Firewall and centralized management in the hub
10. Additional hardening
11. What to do during an attack
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

The last two deserve attention because they are an airline's daily reality, not the extreme case. Price scraping consumes real capacity from the Availability API without generating a single euro of revenue. And inventory hoarding — a bot that starts thousands of bookings to lock up seats — is an attack that breaks nothing technically: it uses the application exactly as designed, just at a rate no human could reach. Against that, the only practical defense is rate limiting per IP and per session.

Infrastructure protection is active on every Azure public IP without anyone doing anything, and it stops the large volumetric attacks that threaten the platform. What it does not do is learn your application's traffic profile: its thresholds are global, so a moderate attack — aimed at you but irrelevant to Azure — can take you down without anything kicking in.

That is exactly what the paid tiers add: adaptive tuning that learns Contoso Bookings' normal pattern and mitigates from its own thresholds, real-time telemetry, post-attack reports (useful for the insurer and the regulator), access to the Rapid Response team during the incident, and cost protection, which credits the scale-out spend caused by a documented attack.

Contoso's decision, with the reasoning: it does not buy Network Protection at this stage. Public traffic comes in through fd-contoso-global, and Front Door runs on Microsoft's edge network, which already absorbs volumetric attacks at the edge. It will be reviewed when there are exposed public IPs of its own — a VPN, a regional Application Gateway — or when the business justifies €32,000 a year. It is the honest answer for most mid-sized companies, and saying so plainly is part of knowing how to design.

A WAF inspects HTTP content — URL, headers, cookies, body — and blocks whatever matches known attack patterns. In Azure it lives in two places:

Contoso chooses the Front Door WAF, and the reason is purely architectural: fd-contoso-global has been the entry point for the website and the API since lesson 02-06. Blocking at the edge means malicious traffic never reaches West Europe, consuming neither the region's bandwidth nor the origin's capacity. Putting an Application Gateway behind it would mean paying twice to inspect the same thing. And there is a mandatory consequence: if the WAF lives in Front Door, you have to stop anyone bypassing Front Door by calling the origin directly, which is solved by restricting app-contoso-reservas-pro to the AzureFrontDoor.Backend service tag and validating the X-Azure-FDID header. Without that lock-down, the WAF is decorative.

Microsoft maintains the Default Rule Set (DRS), derived from the OWASP core rule set, and updates it as new threats appear. It covers the classic OWASP Top 10 categories:

Two more sets are added: Microsoft's IP reputation list, which blocks addresses with known malicious activity, and the Bot Manager Ruleset, which sorts automated traffic into three buckets — bad (blocked), good (Googlebot and the like, allowed) and unknown (logged or rate-limited). That last bucket is the interesting one for price scraping: nearly all scraping traffic falls into it.

One conceptual note you cannot skip: the DRS works by anomaly scoring. Every rule that matches adds points according to its severity (critical 5, error 4, warning 3, notice 2) and action is only taken when the total reaches the threshold of 5. A single critical match is enough; three notices are not. Understanding this is the difference between tuning the WAF with judgement and disabling rules blindly.

Custom rules are evaluated before the managed ones and have numeric priority: the lowest number wins and stops the evaluation. Contoso defines three.

Rate limiting against the price bot. More than 100 requests a minute from the same IP towards /api/disponibilidad is not a user, it is a scraper:

The threshold is calibrated by measuring: the 99th percentile of legitimate traffic per IP during a peak hour, multiplied by three. Watch out for shared IPs — a whole company or a mobile carrier goes out through a handful of addresses — which is why an overly aggressive limit blocks real travel agencies.

Geo-filtering. Contoso sells in Europe. Traffic from countries where it neither operates nor has customers is blocked, with the honest caveat that a VPN gets around it: it is not a defense against a determined attacker, but a filter that removes most of the automated noise.

IP lists. Always allow the Barcelona and Palma office IPs (so you do not block yourself during testing) and block the specific addresses identified in previous incidents. This is the priority 1 rule, the very first one.

A WAF turned on in prevention on day one blocks legitimate users. Always. The classic false positives: a passenger named O'Brien trips the SQL injection rule because of the apostrophe; a comments field containing HTML trips XSS; an upload of special-baggage paperwork exceeds the body size limit; a long session cookie looks like an overflow attempt.

The correct process, and it is not negotiable:

Exclusions are the fine-tuning tool: instead of disabling the whole SQLI rule (which would leave the application unprotected), you exclude one specific field from one specific rule — for example, not applying SQLI to the apellidoPasajero argument. Disabling whole rules out of convenience is how you end up with a WAF that protects against nothing but shows up in the audit report.

The query used in step 3, over Log Analytics (07-02):

If a rule shows up with thousands of matches on the same legitimate URL, it is a false positive, not an attack.

Four details that avoid mistakes: the policy name does not allow hyphens, unlike the rest of Contoso's resources; the bot set requires Front Door's Premium tier, which costs considerably more than Standard; the Detection mode in step 1 is the most important decision in the script; and the association in step 4 is what actually puts the policy into service — without it, the policy exists and protects nothing, a surprisingly common mistake.

Weeks later, after the analysis, the move to production is a single line: az network front-door waf-policy update -g $RG_NET -n $POLICY --mode Prevention.

They do not replace each other, and this is the essential point of the lesson. An NSG does not understand HTTP, so it will never see a SQL injection: to it, that is legitimate traffic on port 443. A WAF does not see a UDP flood, because it never becomes an HTTP request. Azure Firewall does not protect the way into the application; it controls where internal traffic is allowed to go. And DDoS Protection cannot tell a malicious request from a legitimate one: it counts volume. Each layer covers what the others cannot see.

Outbound traffic matters too. If a VM in snet-app is compromised, the first thing the attacker will try is to exfiltrate data or download tooling. With outbound wide open, they succeed. Azure Firewall is deployed in vnet-contoso-hub-pro and all the spoke networks' traffic is routed to it through user-defined routes, taking advantage of the hub-and-spoke peering from module 2.

Its rules come in three kinds, evaluated in this order: NAT (publishing an internal service), network (by IP, port and protocol) and application (by FQDN, inspecting the host name, including HTTPS via SNI).

Anything not listed is denied. FQDN tags simplify the common cases (WindowsUpdate, AzureBackup) without maintaining lists of IPs that keep changing. And Azure Firewall Manager centrally manages the policies of several firewalls: a base policy at the management group with the rules mandatory across all of Contoso, inherited by child policies that each environment extends without being able to relax the base. It is the same governance principle you will see taken to its logical conclusion in 04-06 with Azure Policy. Cost warning: Azure Firewall Standard runs at around €900 a month plus data processing, so it is not deployed in rg-contoso-reservas-dev; NSGs are enough there.

Cheap measures that close the gaps left by the previous layers:

• TLS 1.2 minimum on App Service, Storage, SQL and Key Vault. It was already applied resource by resource; in 04-06 it becomes a policy that enforces it.
• Mandatory HTTPS with redirection from HTTP and HSTS, plus the Content-Security-Policy, X-Content-Type-Options: nosniff and Referrer-Policy headers. They are configured in the application or as rewrite rules in Front Door.
• Management ports closed: no NSG should allow 22 or 3389 from the internet. Access to the VMs is only through bastion-contoso-pro (02-05). It is, by some distance, the recommendation Defender for Cloud will repeat most often in the next lesson.
• No public IP on the VMs: if it has no public IP, there is no surface to attack.
• Origins locked to Front Door: restrict access to app-contoso-reservas-pro to the AzureFrontDoor.Backend service tag and validate X-Azure-FDID, as stated in section 3.

A rehearsed playbook is worth more than an expensive tool nobody knows how to use:

1. Confirm it is an attack. A traffic spike can be a promotion or a news story. You look at the WAF metrics dashboard (requests blocked by rule, by country, by IP) and the DDoS metrics (Under DDoS attack or not, which reads 1 during an active mitigation).
2. Identify the pattern. With the KQL query from section 6, grouping by IP, country, User-Agent and URI. A clear signature almost always shows up.
3. Contain. Add a low-priority custom rule blocking that pattern; changes in Front Door propagate globally within a few minutes. If the attack is application-layer against one specific route, rate-limit it temporarily.
4. Scale. Increase App Service and vmss-api-disponibilidad-pro instances to absorb the rest while you contain it. With Network Protection, also open a case with the Rapid Response team.
5. Communicate. Tell the business and customer service before the customers do. If there are signs of personal data being accessed, trigger the GDPR notification procedure, with its deadlines.
6. Review afterwards. Mitigation report, threshold tuning, folding the pattern into the permanent rules and updating the playbook itself.

Where you look at all of this: Front Door profile and WAF metrics in Azure Monitor, the FrontDoorWebApplicationFirewallLog and FrontDoorAccessLog logs in Log Analytics, and the DDoS plan's metrics if you have one. All of that is explored in depth in module 7.

• Turning the WAF on in prevention mode on day one. It will block real customers. Two to four weeks in detection, always.
• Creating the policy and not attaching it to the endpoint. The policy exists, the dashboard looks pretty and it protects nothing.
• Putting the WAF on Front Door and leaving the origin open. Anyone who discovers the app-contoso-reservas-pro URL bypasses the entire inspection.
• Disabling a whole rule group over a false positive. Use exclusions scoped to a specific field and rule.
• Buying DDoS Network Protection without needing it. That is €32,000 a year. Assess whether your traffic already comes in through Front Door.
• Confusing the layers. The NSG does not see SQL injections and the WAF does not see UDP floods. They complement each other (section 8).
• Forgetting that the WAF is not a substitute for secure code. It is a safety net against a flaw, not an excuse for concatenating SQL strings.
• Tip: always include an allow rule for your own office IPs at the highest priority. Locking yourself out during an incident is more common than it sounds.
• Tip: every significant change to the application can introduce new false positives. Review the WAF logs after every meaningful deployment.

For each scenario, state which layer stops it and why the others cannot:

1. A 300 Gbps UDP flood against the public IP of the Barcelona VPN.
2. ' UNION SELECT contrasena FROM Usuarios-- in the flight search box.
3. A compromised VM in snet-app trying to upload a dump of db-reservas to an external storage service.
4. A bot making 4,000 queries a minute to /api/disponibilidad from 200 different IPs.

"Contoso Miles" (centro-coste=CC-2077) is about to publish its portal behind Front Door. The team wants the WAF active on launch day.

1. What do you tell the team, and what alternative plan do you propose, with timings?
2. Write the commands to create the policy and attach it to the endpoint.
3. After two weeks, rule 942100 (SQLI) shows up 3,000 times on the nombreCompleto field of the sign-up form. What exactly do you do, and what do you not do?

Contoso currently exposes: fd-contoso-global (website and API), the public IP of the site-to-site VPN gateway and bastion-contoso-pro. The CFO asks whether DDoS Network Protection should be purchased.

1. What protection does each of those three things have today?
2. Argue for and against buying the plan, with figures.
3. What cheaper alternative would you propose, and what condition would change the decision?

Solution 1:

1. DDoS Protection. The WAF does not see it because UDP traffic never becomes an HTTP request, and an NSG cannot filter volume: even if it denied the port, the bandwidth is already saturated upstream.
2. The WAF (the DRS SQLI group), and secondly the code itself with parameterized queries. Neither the NSG nor the firewall inspects the content of a legitimate HTTPS request to port 443.
3. Azure Firewall in the hub, with application rules that only allow outbound traffic to a closed list of FQDNs. The WAF protects the way in, not the way out; an NSG could limit by IP, but maintaining IP lists for external services is unworkable and it cannot tell apart domains that share an IP.
4. The WAF with rate limiting and bot protection. Careful: 200 different IPs mean the per-IP threshold works out at 20 requests a minute each, indistinguishable from an active user; what works there is the bot rule set, IP reputation and, if it persists, requiring a challenge on that route.

Solution 2:

1. That turning on prevention on launch day is the fastest way to block your first customers, at exactly the moment of maximum visibility. Alternative plan: create the policy in detection mode from launch day, review the logs at 7 and 14 days, apply exclusions and switch to prevention in week 3 or 4, during working hours and with somebody watching.
2. az network front-door waf-policy create -g rg-contoso-red-pro -n wafcontosomillas --sku Premium_AzureFrontDoor --mode Detection with the tags and centro-coste=CC-2077; then managed-rules add with Microsoft_DefaultRuleSet 2.1 and Microsoft_BotManagerRuleSet; and finally az afd security-policy create attaching the policy to the endpoint's domain. Without that last command the policy is not applied.
3. It is an obvious false positive: names with an apostrophe (O'Neill, D'Angelo) trip the rule. You add an exclusion for rule 942100 in the SQLI group limited to the variable RequestBodyPostArgNames with the value nombreCompleto. What you do not do: disable rule 942100 globally, and far less the whole SQLI group, because that would leave every other field with no injection protection.

Solution 3:

1. All three have the free infrastructure protection. On top of that, fd-contoso-global benefits from absorption at the edge of Microsoft's global network, which is real and significant protection. The VPN IP and the Bastion IP have only the basic protection, with no adaptive tuning and no telemetry.
2. In favor: mitigation tuned to the real profile, telemetry and reports for the regulator and the insurer, the Rapid Response team and cost protection; if an attack takes down sales over a long weekend, the lost revenue easily exceeds the annual cost. Against: ~€2,700/month, some €32,000 a year, to protect two secondary IPs, given that the real business traffic comes in through Front Door and not through them.
3. DDoS IP Protection on the specific VPN and Bastion IPs, which is billed per IP and costs a fraction; or, better still, remove the exposure altogether: Bastion does not need to be reachable from the whole internet if it is restricted by NSG and Conditional Access. The decision would change the day Contoso publishes a critical workload with its own public IP — a regional Application Gateway, a partners API — or after suffering a documented real attack.

Contoso's perimeter is no longer open. You know what genuinely reaches a ticket-selling website: volumetric and protocol attacks that aim to saturate, application layer attacks that exhaust the server with valid requests, exploitation of flaws in the code, and the everyday abuse of the bots that scrape prices and hoard seats in carts without ever buying. You know Azure DDoS Protection with its free infrastructure protection — always on, with global thresholds — and the paid tiers that add adaptive tuning, telemetry, reports, a Rapid Response team and cost protection, at a price that has to be said out loud: on the order of €2,700 a month for Network Protection. And you can argue why Contoso, today, does not buy it.

You have built the web application firewall where it belongs: on fd-contoso-global, to block at the edge rather than in the region, while also locking down the origin so that nobody bypasses the inspection. You understand the managed rule set with its groups — SQLI, XSS, LFI, RCE, protocol, scanners, threat intelligence — and its anomaly scoring model with a threshold of 5, the bot rule set with its three categories, and IP reputation. You have written custom rules ordered by priority: allow the offices, block the incident IPs, rate-limit /api/disponibilidad and filter by geography. And, above all, you have internalized the process that separates a useful WAF from one that breaks the business: detection first, false positive analysis in the logs, exclusions scoped to a specific field and rule, and only then prevention.

You have compared the four layers and why none of them replaces another — the NSG does not see HTTP, the WAF does not see a UDP flood, Azure Firewall governs outbound traffic from the hub with network and FQDN application rules, and DDoS counts volume — you have added the cheap hardening (minimum TLS, headers, management ports closed, access only through bastion-contoso-pro) and you have a six-step playbook for the day of the attack.

Up to here, security has been built piece by piece, and each piece has required knowing it existed. What is missing is the instrument that looks at the whole platform and says what is missing: which VM still has port 3389 open, which storage account allows public access, which database has no auditing. In the next lesson, Microsoft Defender for Cloud, you will move from point-in-time control to continuous posture: secure score, prioritized recommendations, alerts on anomalous behavior and regulatory compliance dashboards, including the PCI DSS that applies to Contoso because it processes payments. With one warning I will give you now: its paid plans cost money too, and they have to be chosen with judgement.