Las tres lecciones anteriores han cerrado el interior de la plataforma: identidades gobernadas, permisos mínimos y ningún secreto expuesto. Nada de eso protege a Contoso Reservas de lo que llega por la puerta principal. Es una web pública de venta de billetes, así que cualquiera con una conexión puede lanzarle peticiones, y algunas de ellas no buscan comprar un vuelo. Un ataque de denegación de servicio la víspera de un puente factura cero euros en ventas y muchos en reputación; una inyección SQL que esquive el código llega hasta db-reservas; y un bot que consulta precios cada segundo distorsiona la disponibilidad y agota las plazas del carrito sin comprar ninguna. Hoy montas el perímetro: protección DDoS en la capa de red y un firewall de aplicaciones web sobre fd-contoso-global, con el proceso realista de puesta en marcha que evita bloquear a tus propios clientes.

Aviso de coste importante: este es el módulo más caro del curso. DDoS Network Protection cuesta del orden de 2.700 € al mes por inquilino (cubre hasta 100 direcciones IP públicas), y el WAF de Front Door añade una cuota fija mensual del orden de 250-300 € más el coste por regla y por millón de peticiones. No son servicios que se activen "para probar". Para practicar, quédate en la protección de infraestructura gratuita, crea la directiva de WAF en modo detección con el nivel más bajo y elimínala al terminar.

1. Qué ataques llegan a una web de venta de billetes
2. Azure DDoS Protection: gratis frente a los niveles de pago
3. Firewall de aplicaciones web: dónde se despliega
4. El conjunto de reglas gestionado de OWASP
5. Reglas personalizadas: bots, geografía y listas de IP
6. Detección frente a prevención: la puesta en marcha realista
7. Desplegar la directiva de WAF sobre Front Door con CLI
8. Las capas de protección de red comparadas
9. Azure Firewall y la gestión centralizada en el hub
10. Endurecimiento adicional
11. Qué hacer durante un ataque
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Los dos últimos merecen atención porque son el día a día de una aerolínea, no el caso extremo. El raspado de precios consume capacidad real de la API de Disponibilidad sin generar ni un euro de ingreso. Y el acaparamiento de inventario —un bot que inicia miles de reservas para bloquear plazas— es un ataque que no rompe nada técnicamente: usa la aplicación exactamente como fue diseñada, solo que a un ritmo que ningún humano alcanzaría. Contra eso, la única defensa práctica es la limitación de velocidad por IP y por sesión.

La protección de infraestructura está activa para toda IP pública de Azure sin que nadie haga nada, y detiene los ataques volumétricos grandes que amenazan a la plataforma. Lo que no hace es aprender el perfil de tráfico de tu aplicación: sus umbrales son globales, así que un ataque moderado —dirigido a ti pero irrelevante para Azure— puede tumbarte sin que se active nada.

Eso es exactamente lo que añaden los niveles de pago: ajuste adaptativo que aprende el patrón normal de Contoso Reservas y mitiga a partir de umbrales propios, telemetría en tiempo real, informes posteriores al ataque (útiles para la aseguradora y el regulador), acceso al equipo de respuesta rápida durante el incidente y protección de coste, que acredita el gasto de escalado provocado por un ataque documentado.

La decisión de Contoso, argumentada: no contrata Network Protection en la fase actual. El tráfico público entra por fd-contoso-global, y Front Door corre sobre la red perimetral de Microsoft, que ya absorbe los ataques volumétricos en el borde. Se revisará cuando haya IPs públicas propias expuestas —una VPN, un Application Gateway regional— o cuando el negocio justifique los 32.000 € anuales. Es la respuesta honesta para la mayoría de las empresas medianas, y decirlo claramente forma parte de saber diseñar.

Un WAF inspecciona el contenido HTTP —URL, cabeceras, cookies, cuerpo— y bloquea lo que coincide con patrones de ataque conocidos. En Azure vive en dos sitios:

Contoso elige el WAF de Front Door, y la razón es puramente arquitectónica: fd-contoso-global ya es la puerta de entrada de la web y de la API desde la lección 02-06. Bloquear en el borde significa que el tráfico malicioso nunca llega a West Europe, no consume ancho de banda de la región ni capacidad del origen. Poner un Application Gateway detrás sería pagar dos veces por inspeccionar lo mismo. Y hay una consecuencia obligatoria: si el WAF vive en Front Door, hay que impedir que alguien salte Front Door llamando directamente al origen, lo que se resuelve restringiendo app-contoso-reservas-pro a la etiqueta de servicio AzureFrontDoor.Backend y validando la cabecera X-Azure-FDID. Sin ese cierre, el WAF es decorativo.

Microsoft mantiene el Default Rule Set (DRS), derivado del conjunto de reglas básicas de OWASP, y lo actualiza cuando aparecen amenazas nuevas. Cubre las categorías clásicas del top 10 de OWASP:

Se añaden dos conjuntos más: la lista de reputación de IP de Microsoft, que bloquea direcciones con actividad maliciosa conocida, y el Bot Manager Ruleset, que clasifica el tráfico automatizado en tres cubos —malintencionados (se bloquean), buenos (Googlebot y similares, se permiten) y desconocidos (se registran o se limitan)—. Ese último cubo es el interesante para el raspado de precios: casi todo el tráfico de scraping cae ahí.

Una nota conceptual imprescindible: el DRS funciona por puntuación de anomalía. Cada regla que coincide suma puntos según su gravedad (crítica 5, error 4, aviso 3, aviso leve 2) y solo se actúa cuando la suma alcanza el umbral 5. Una sola coincidencia crítica basta; tres avisos leves no. Entender esto es la diferencia entre ajustar el WAF con criterio y desactivar reglas a ciegas.

Las reglas personalizadas se evalúan antes que las gestionadas y tienen prioridad numérica: el número más bajo gana y detiene la evaluación. Contoso define tres.

Limitación de velocidad contra el bot de precios. Más de 100 peticiones por minuto desde la misma IP hacia /api/disponibilidad no es un usuario, es un raspador:

El umbral se calibra midiendo: el percentil 99 del tráfico legítimo por IP en una hora punta, multiplicado por tres. Cuidado con las IP compartidas —una empresa entera o una operadora móvil salen por unas pocas direcciones—, motivo por el que una limitación demasiado agresiva bloquea agencias de viajes reales.

Bloqueo geográfico. Contoso vende en Europa. Se bloquea el tráfico de países donde no opera ni tiene clientes, con el matiz honesto de que una VPN lo esquiva: no es una defensa contra un atacante decidido, sino un filtro que elimina la mayor parte del ruido automatizado.

Listas de IP. Permitir siempre las IP de las oficinas de Barcelona y Palma (para no bloquearse a uno mismo durante las pruebas) y bloquear las direcciones concretas identificadas en incidentes anteriores. Es la regla de prioridad 1, la primera de todas.

Un WAF activado en prevención el primer día bloquea usuarios legítimos. Siempre. Los falsos positivos clásicos: un pasajero apellidado O'Brien dispara la regla de inyección SQL por el apóstrofo; un campo de comentarios con HTML dispara XSS; una carga de documentación de equipaje especial supera el límite de tamaño del cuerpo; una cookie de sesión larga se parece a un intento de desbordamiento.

El proceso correcto, y no es negociable:

Las exclusiones son la herramienta de ajuste fina: en lugar de desactivar la regla de SQLI entera (lo que dejaría la aplicación desprotegida), se excluye un campo concreto de una regla concreta —por ejemplo, no aplicar SQLI al argumento apellidoPasajero—. Desactivar reglas completas por comodidad es cómo se acaba con un WAF que no protege de nada pero aparece en el informe de auditoría.

La consulta que se usa en el paso 3, sobre Log Analytics (07-02):

Si una regla aparece con miles de coincidencias sobre la misma URL legítima, es un falso positivo, no un ataque.

Cuatro detalles que evitan errores: el nombre de la directiva no admite guiones, a diferencia del resto de recursos de Contoso; el conjunto de bots exige el nivel Premium de Front Door, que cuesta bastante más que Standard; el modo Detection del paso 1 es la decisión más importante del script; y la asociación del paso 4 es la que realmente pone la directiva en funcionamiento —sin ella, la directiva existe y no protege nada, un error sorprendentemente común.

Semanas después, tras el análisis, el cambio a producción es una línea: az network front-door waf-policy update -g $RG_RED -n $POLITICA --mode Prevention.

No se sustituyen entre sí, y esto es lo esencial de la lección. Un NSG no entiende HTTP, así que jamás verá una inyección SQL: para él es tráfico legítimo al puerto 443. Un WAF no ve una inundación UDP, porque nunca llega a ser una petición HTTP. Azure Firewall no protege la entrada a la aplicación, sino que controla hacia dónde puede salir el tráfico interno. Y DDoS Protection no distingue una petición maliciosa de una legítima: cuenta volumen. Cada capa cubre lo que las demás no pueden ver.

El tráfico de salida también importa. Si una VM de snet-app se ve comprometida, lo primero que intentará el atacante es sacar datos o descargar herramientas. Con salida abierta, lo consigue. Azure Firewall se despliega en vnet-contoso-hub-pro y todo el tráfico de las redes radiales se enruta hacia él mediante rutas definidas por el usuario, aprovechando el peering hub-and-spoke del módulo 2.

Sus reglas son de tres tipos, y se evalúan en este orden: NAT (publicar un servicio interno), red (por IP, puerto y protocolo) y aplicación (por FQDN, con inspección del nombre de host, incluido HTTPS por SNI).

Todo lo que no aparezca se deniega. Las etiquetas de nombre de dominio completo simplifican los casos habituales (WindowsUpdate, AzureBackup) sin mantener listas de IP que cambian. Y Azure Firewall Manager gestiona de forma centralizada las directivas de varios cortafuegos: una directiva base en el grupo de administración con las reglas obligatorias de toda Contoso, heredada por directivas hijas que cada entorno amplía sin poder relajar la base. Es el mismo principio de gobierno que verás llevado al extremo en 04-06 con Azure Policy. Advertencia de coste: Azure Firewall Standard ronda los 900 € al mes más el procesamiento de datos, así que en rg-contoso-reservas-dev no se despliega; ahí bastan los NSG.

Medidas baratas que cierran los huecos que quedan tras las capas anteriores:

• TLS mínimo 1.2 en App Service, Storage, SQL y Key Vault. Ya se aplicó recurso a recurso; en 04-06 pasará a ser una política que lo impone.
• HTTPS obligatorio con redirección desde HTTP y HSTS, más las cabeceras Content-Security-Policy, X-Content-Type-Options: nosniff y Referrer-Policy. Se configuran en la aplicación o como reglas de reescritura en Front Door.
• Puertos de gestión cerrados: ningún NSG debe permitir 22 o 3389 desde internet. El acceso a las VMs es solo por bastion-contoso-pro (02-05). Es, con diferencia, la recomendación que Defender for Cloud repetirá más en la lección siguiente.
• Sin IP pública en las VMs: si no tiene IP pública, no hay superficie que atacar.
• Orígenes cerrados a Front Door: restringir el acceso a app-contoso-reservas-pro a la etiqueta de servicio AzureFrontDoor.Backend y validar X-Azure-FDID, como se dijo en el apartado 3.

Un guion practicado vale más que una herramienta cara sin nadie que la sepa usar:

1. Confirmar que es un ataque. Un pico de tráfico puede ser una promoción o una noticia. Se mira el panel de métricas del WAF (peticiones bloqueadas por regla, por país, por IP) y las métricas de DDoS (Under DDoS attack or not, que vale 1 durante una mitigación activa).
2. Identificar el patrón. Con la consulta KQL del apartado 6, agrupando por IP, país, User-Agent y URI. Casi siempre aparece una firma clara.
3. Contener. Añadir una regla personalizada de prioridad baja bloqueando ese patrón; los cambios en Front Door se propagan globalmente en pocos minutos. Si el ataque es de capa de aplicación contra una ruta concreta, limitarla temporalmente.
4. Escalar. Aumentar instancias de App Service y de vmss-api-disponibilidad-pro para absorber el resto mientras se contiene. Con Network Protection, además, abrir caso con el equipo de respuesta rápida.
5. Comunicar. Avisar a negocio y a atención al cliente antes de que lo hagan los clientes. Si hay indicios de acceso a datos personales, activar el procedimiento de notificación del RGPD, con sus plazos.
6. Revisar después. Informe de mitigación, ajuste de umbrales, incorporación del patrón a las reglas permanentes y actualización del propio guion.

Dónde se mira todo: métricas del perfil de Front Door y del WAF en Azure Monitor, registros FrontDoorWebApplicationFirewallLog y FrontDoorAccessLog en Log Analytics, y las métricas del plan de DDoS si está contratado. Todo eso se explota a fondo en el módulo 7.

• Activar el WAF en modo prevención el primer día. Bloqueará clientes reales. Dos a cuatro semanas en detección, siempre.
• Crear la directiva y no asociarla al punto de conexión. La directiva existe, el panel se ve bonito y no protege nada.
• Poner el WAF en Front Door y dejar el origen abierto. Cualquiera que descubra la URL de app-contoso-reservas-pro se salta la inspección entera.
• Desactivar un grupo de reglas completo ante un falso positivo. Usa exclusiones por campo y regla concreta.
• Contratar DDoS Network Protection sin necesitarlo. Son 32.000 € al año. Evalúa si tu tráfico entra ya por Front Door.
• Confundir las capas. Ni el NSG ve inyecciones SQL ni el WAF ve inundaciones UDP. Se complementan (apartado 8).
• Olvidar que el WAF no sustituye al código seguro. Es una red de seguridad frente a un fallo, no una excusa para concatenar cadenas SQL.
• Consejo: incluye siempre una regla de permitir para las IP de tus oficinas con la prioridad más alta. Bloquearse a uno mismo durante un incidente es más común de lo que parece.
• Consejo: cada cambio importante de la aplicación puede introducir falsos positivos nuevos. Revisa los registros del WAF tras cada despliegue relevante.

Para cada escenario, indica qué capa lo detiene y por qué las demás no pueden:

1. Una inundación de 300 Gbps de tráfico UDP contra la IP pública de la VPN de Barcelona.
2. ' UNION SELECT contrasena FROM Usuarios-- en el buscador de vuelos.
3. Una VM comprometida en snet-app que intenta subir un volcado de db-reservas a un servicio de almacenamiento externo.
4. Un bot que hace 4.000 consultas por minuto a /api/disponibilidad desde 200 IP distintas.

"Contoso Millas" (centro-coste=CC-2077) va a publicar su portal tras Front Door. El equipo quiere el WAF activo el día del lanzamiento.

1. ¿Qué le respondes al equipo y qué plan alternativo propones, con plazos?
2. Escribe los comandos de creación de la directiva y de asociación al punto de conexión.
3. Tras dos semanas, la regla 942100 (SQLI) aparece 3.000 veces sobre el campo nombreCompleto del formulario de alta. ¿Qué haces exactamente y qué no haces?

Contoso expone hoy: fd-contoso-global (web y API), la IP pública de la puerta de enlace VPN de sitio a sitio y bastion-contoso-pro. El director financiero pregunta si hay que contratar DDoS Network Protection.

1. ¿Qué protección tiene hoy cada uno de esos tres elementos?
2. Argumenta a favor y en contra de contratar el plan, con cifras.
3. ¿Qué alternativa más barata propondrías y qué condición haría cambiar la decisión?

Solución 1:

1. DDoS Protection. El WAF no lo ve porque el tráfico UDP nunca llega a ser una petición HTTP, y un NSG no puede filtrar volumen: aunque denegara el puerto, el ancho de banda ya está saturado antes.
2. WAF (grupo SQLI del DRS), y en segundo lugar el propio código con consultas parametrizadas. Ni el NSG ni el firewall inspeccionan el contenido de una petición HTTPS legítima al puerto 443.
3. Azure Firewall en el hub, con reglas de aplicación que solo permiten salir hacia una lista cerrada de FQDN. El WAF protege la entrada, no la salida; un NSG podría limitar por IP, pero mantener listas de IP de servicios externos es inviable y no distingue dominios que comparten IP.
4. WAF con limitación de velocidad y protección contra bots. Cuidado: 200 IP distintas hacen que el umbral por IP sea de 20 peticiones por minuto cada una, indistinguible de un usuario activo; ahí lo que funciona es el conjunto de reglas de bots, la reputación de IP y, si persiste, exigir un desafío en esa ruta.

Solución 2:

1. Que activar prevención el día del lanzamiento es la forma más rápida de bloquear a los primeros clientes, justo cuando más visibilidad hay. Plan alternativo: crear la directiva en modo detección desde el día del lanzamiento, revisar los registros a los 7 y a los 14 días, aplicar exclusiones y pasar a prevención en la semana 3 o 4, en horario laboral y con alguien mirando.
2. az network front-door waf-policy create -g rg-contoso-red-pro -n wafcontosomillas --sku Premium_AzureFrontDoor --mode Detection con las etiquetas y centro-coste=CC-2077; después managed-rules add con Microsoft_DefaultRuleSet 2.1 y Microsoft_BotManagerRuleSet; y por último az afd security-policy create asociando la directiva al dominio del punto de conexión. Sin ese último comando la directiva no se aplica.
3. Es un falso positivo evidente: nombres con apóstrofo (O'Neill, D'Angelo) disparan la regla. Se añade una exclusión para la regla 942100 del grupo SQLI limitada a la variable RequestBodyPostArgNames con valor nombreCompleto. Lo que no se hace: desactivar la regla 942100 globalmente, y mucho menos el grupo SQLI entero, porque eso dejaría todos los demás campos sin protección contra inyección.

Solución 3:

1. Los tres tienen protección de infraestructura gratuita. Además, fd-contoso-global se beneficia de la absorción en el borde de la red global de Microsoft, que es una protección real y significativa. La IP de la VPN y la de Bastion están solo con la protección básica, sin ajuste adaptativo ni telemetría.
2. A favor: mitigación adaptada al perfil real, telemetría e informes para el regulador y la aseguradora, equipo de respuesta rápida y protección de coste; si un ataque tumba la venta en un puente, el lucro cesante supera fácilmente el coste anual. En contra: ~2.700 €/mes, unos 32.000 € al año, para proteger dos IP secundarias, ya que el tráfico de negocio real entra por Front Door y no por ellas.
3. DDoS IP Protection sobre las IP concretas de la VPN y Bastion, que se paga por IP y cuesta una fracción; o, mejor todavía, eliminar la exposición: Bastion no necesita ser alcanzable por todo internet si se restringe por NSG y acceso condicional. Cambiaría la decisión el día en que Contoso publique una carga de trabajo con IP pública propia y crítica —un Application Gateway regional, una API de socios— o tras sufrir un ataque real documentado.

El perímetro de Contoso ya no está abierto. Sabes qué llega de verdad a una web de venta de billetes: ataques volumétricos y de protocolo que buscan saturar, ataques de capa de aplicación que agotan el servidor con peticiones válidas, explotación de fallos del código y el abuso cotidiano de los bots que raspan precios y acaparan plazas en el carrito sin comprar nunca. Conoces Azure DDoS Protection con su protección de infraestructura gratuita —siempre activa, con umbrales globales— y los niveles de pago que añaden ajuste adaptativo, telemetría, informes, equipo de respuesta rápida y protección de coste, a un precio que hay que decir en voz alta: del orden de 2.700 € al mes Network Protection. Y sabes argumentar por qué Contoso, hoy, no lo contrata.

Has montado el firewall de aplicaciones web donde corresponde: sobre fd-contoso-global, para bloquear en el borde y no en la región, cerrando además el origen para que nadie salte la inspección. Entiendes el conjunto de reglas gestionado con sus grupos —SQLI, XSS, LFI, RCE, protocolo, escáneres, inteligencia de amenazas— y su modelo de puntuación de anomalía con umbral 5, el conjunto de bots con sus tres categorías y la reputación de IP. Has escrito reglas personalizadas ordenadas por prioridad: permitir las oficinas, bloquear las IP de incidentes, limitar la velocidad en /api/disponibilidad y filtrar por geografía. Y, sobre todo, has interiorizado el proceso que separa un WAF útil de uno que rompe el negocio: detección primero, análisis de falsos positivos en los registros, exclusiones por campo y regla concreta, y solo entonces prevención.

Has comparado las cuatro capas y por qué ninguna sustituye a otra —el NSG no ve HTTP, el WAF no ve una inundación UDP, Azure Firewall gobierna la salida desde el hub con reglas de red y de aplicación por FQDN, y DDoS cuenta volumen—, has añadido el endurecimiento barato (TLS mínimo, cabeceras, puertos de gestión cerrados, acceso solo por bastion-contoso-pro) y tienes un guion de seis pasos para el día del ataque.

Hasta aquí la seguridad se ha construido pieza a pieza, y cada una ha exigido saber que existía. Falta el instrumento que mire la plataforma entera y diga qué falta: qué VM sigue con el puerto 3389 abierto, qué cuenta de almacenamiento permite acceso público, qué base no tiene auditoría. En la siguiente lección, Microsoft Defender for Cloud, pasarás del control puntual a la postura continua: puntuación de seguridad, recomendaciones priorizadas, alertas ante comportamientos anómalos y paneles de cumplimiento normativo, incluido el PCI DSS que aplica a Contoso por procesar pagos. Con una advertencia que ya adelanto: sus planes de pago también cuestan dinero, y hay que elegirlos con criterio.