Auditar los servicios de protección de red

Cumplimiento te manda una línea: confirma que toda aplicación expuesta a internet en la cuenta de producción esté protegida por un firewall de aplicaciones web. Abres la consola, encuentras un web ACL llamado prod-web-acl con 14 reglas, incluido el managed core rule set de AWS, y respondes que están cubiertos.

Puede que acabes de firmar la nada. Un web ACL es un recurso autónomo. Hasta que lo asocias a una distribución de CloudFront o a un load balancer concreto, inspecciona cero solicitudes, y la página de la consola se ve idéntica en los 2 casos. La misma forma de hueco existe en los 4 servicios de esta lección, y por eso el examen tiene una habilidad para auditarlos en lugar de una para configurarlos.

Cuatro servicios, cuatro pedazos distintos de tráfico

Antes de auditar estos servicios tienes que saber qué alcanza a ver cada uno. No son capas de la misma pared. Se paran en caminos distintos, y un hueco en uno es completamente invisible para los otros 3.

Dos fronteras de esa tabla merecen su propia frase.

AWS WAF ve solicitudes, Network Firewall ve paquetes. WAF solo existe delante de tipos de recurso que hablan HTTP: distribuciones de CloudFront, Application Load Balancers, REST APIs de API Gateway, APIs GraphQL de AppSync, user pools de Cognito, servicios de App Runner, Bedrock AgentCore Gateways, instancias de Verified Access y Amplify. Nada más. Si tu carga de trabajo es una réplica de base de datos mandando datos por un puerto TCP propio, WAF nunca fue el control que pudo haberlo detectado, y Network Firewall sí.

DNS Firewall ve consultas, Network Firewall ve conexiones. Los 2 pueden filtrar por nombre de dominio, y ese solapamiento es una trampa favorita del examen. DNS Firewall filtra la resolución DNS misma mientras pasa por el Route 53 VPC Resolver, así que evita que la carga de trabajo llegue a conocer la dirección. Network Firewall inspecciona el tráfico resultante en el cable pero no tiene ninguna visibilidad de las consultas al Resolver. AWS lo dice directo: los 2 servicios filtran nombres de dominio en 2 caminos de red distintos.

Las 4 preguntas que responde una auditoría

Cada uno de estos servicios puede estar desplegado y no proteger nada, y la falla siempre es uno de los mismos 4 pasos. Lleva este marco por el resto de la lección y aplícalo al servicio que el examen nombre:

1. ¿Está desplegado? ¿Existe el recurso en esta cuenta y esta región?
2. ¿Está asociado a lo que crees? Asociación, subred, ruta o vínculo con la VPC.
3. ¿Está aplicando la acción o solo observando? Count, Alert y Pass producen telemetría de aspecto sano mientras dejan pasar el tráfico.
4. ¿Puedes demostrar qué hizo? El logging viene apagado en casi todos, y una auditoría sin evidencia es una opinión.

La pregunta 3 es donde fallan los entornos reales, porque el paso 3 es una parte normal y correcta de cada rollout. Arrancas una regla nueva en modo conteo a propósito. Nadie agenda el día de encenderla.

Auditar AWS WAF

Empieza por la asociación, porque es la pregunta que el auditor hizo de verdad. Los web ACLs viven en 2 scopes separados, y el scope de CloudFront solo existe en us-east-1:

# Recursos regionales: ALB, API Gateway, AppSync, Cognito, App Runner, Verified Access
aws wafv2 list-web-acls --scope REGIONAL --region eu-west-1

aws wafv2 list-resources-for-web-acl \
  --web-acl-arn arn:aws:wafv2:eu-west-1:111122223333:regional/webacl/prod-web-acl/a1b2c3d4 \
  --region eu-west-1

# Las distribuciones de CloudFront siempre viven en el scope CLOUDFRONT de us-east-1
aws wafv2 list-web-acls --scope CLOUDFRONT --region us-east-1

Una lista ResourceArns vacía es el hallazgo. Trabaja también en el sentido contrario: lista tus ALBs y tus distribuciones de CloudFront y revisa cuáles no tienen ningún web ACL, porque un recurso sin asociación jamás va a aparecer en la lista de recursos de ningún web ACL.

Confirmada la asociación, 4 detalles de configuración deciden si el web ACL bloquea algo.

La acción por defecto. Un web ACL aplica su acción por defecto a toda solicitud que ninguna regla terminó. Allow es lo normal para un sitio público protegido por reglas de bloqueo explícitas. Block es lo normal para una API interna cerrada. Leer la acción por defecto te dice para cuál de los 2 modelos se diseñó el web ACL, y un default Block con una regla de permiso amplia arriba es una postura de seguridad muy distinta de lo que sugiere su nombre.

Acciones terminantes y no terminantes. Allow y Block detienen la evaluación de inmediato, y la que coincide primero decide la solicitud. Count nunca termina: incrementa una métrica y la evaluación sigue. CAPTCHA y Challenge son condicionales, y terminan solo cuando la solicitud no trae un token válido. Así que un conjunto de reglas puede estar lleno de reglas de bloqueo bien escritas que nunca corren.

La prioridad de las reglas. AWS WAF evalúa las reglas desde la prioridad numérica más baja hacia arriba. Una regla Allow en prioridad 10 que coincide con el rango IP de tu oficina va a terminar antes de que la regla de SQL injection en prioridad 50 llegue a ver la solicitud. Las reglas Allow amplias cerca del tope son lo más productivo que puedes buscar al revisar un web ACL.

Overrides de rule group. Al agregar un managed rule group puedes sobreescribir la acción de todo el grupo a Count, o sobreescribir reglas individuales dentro de él. Es la forma prevista de probar el managed core rule set de AWS sin romper una aplicación viva. También es la razón más común de que un web ACL con reglas excelentes no bloquee nada. Revísalo de forma explícita; la consola lo muestra como una insignia chica que es fácil pasar por alto.

Para la pregunta 4, el logging de WAF está apagado hasta que lo configuras. Puedes mandar los logs del web ACL a un log group de CloudWatch Logs, a un bucket de S3 o a un delivery stream de Amazon Data Firehose, y puedes redactar campos y filtrar qué registros se guardan. Aparte, el muestreo de solicitudes te da una vista móvil de las solicitudes evaluadas hace poco sin configurar nada, y es la forma más rápida de ver si una regla está coincidiendo. Las métricas de CloudWatch que hay que leer son AllowedRequests, BlockedRequests y CountedRequests. Un web ACL cuyo BlockedRequests lleva meses plano en cero mientras CountedRequests sube te está respondiendo la pregunta 3.

Auditar AWS Shield

Shield se parte limpio en una mitad automática y una mitad suscrita, y las preguntas de auditoría son distintas para cada una.

Shield Standard está activo para todo cliente de AWS sin cargo extra y defiende contra las inundaciones comunes de las capas de red y transporte. No hay nada que habilitar, nada que asociar y nada que auditar más allá de saber que está ahí.

Shield Advanced es una suscripción de $3.000 al mes con compromiso de 1 año, facturada por cuenta pagadora cuando esa cuenta o cualquiera de sus cuentas vinculadas está suscrita. Protege instancias EC2, load balancers de Elastic Load Balancing, distribuciones de CloudFront, hosted zones de Route 53 y standard accelerators de Global Accelerator.

Vale nombrar la idea equivocada: suscribirse a Shield Advanced no protege tus recursos. La suscripción desbloquea la capacidad. Igual tienes que crear una protection por cada recurso que quieras cubrir. El hallazgo previsible es un load balancer creado 3 meses después de arrancar la suscripción que nadie agregó, con la cuenta pagando $3.000 al mes en parte por una cobertura que no tiene.

aws shield describe-subscription          # si la cuenta está suscrita y cuándo termina el término
aws shield list-protections               # qué ARNs de recurso están protegidos de verdad

Compara esa lista de protections contra los recursos elegibles de la cuenta. Esa diferencia es tu hallazgo.

Otros 3 ajustes de Shield Advanced cargan peso real en una auditoría:

• La mitigación automática de DDoS en capa de aplicación se puede configurar para contar o para bloquear las solicitudes web que identifica como parte de un ataque. Puesta en contar, es un detector. Habilitarla agrega al web ACL asociado un rule group que consume 150 WCUs, y eso cuenta contra la capacidad del web ACL.
• La detección basada en salud asocia un health check de Route 53 a un recurso protegido para que Shield distinga un impacto real de un pico de tráfico legítimo. Está disponible para todos los tipos de recurso salvo las hosted zones de Route 53, y el compromiso proactivo del Shield Response Team solo funciona sobre recursos que la tienen habilitada.
• El acceso al Shield Response Team exige además un plan de soporte Business o Enterprise. Una suscripción sin ese plan significa que el teléfono de tu runbook no funciona.

Shield Advanced también ofrece protección de costos contra picos de factura causados por un ataque, otorgada como créditos de servicio después del hecho y no como un descuento automático.

Auditar AWS Network Firewall

Network Firewall tiene la mayor distancia entre "el recurso existe" y "el recurso está haciendo algo", así que esta es la más profunda de las 4 auditorías.

El servicio crea un firewall endpoint en cada subred que designas, y cada endpoint le da al firewall disponibilidad en su zona de disponibilidad. Una firewall policy guarda la configuración y apunta a rule groups, stateless y stateful. Nada de eso pone al firewall en el camino del tráfico.

Las route tables son el mecanismo que hace cumplir la inspección. Editas las route tables de la VPC para que el tráfico de una subred protegida vaya al firewall endpoint, y para que el tráfico de vuelta desde el internet gateway pase por el endpoint antes de llegar a la subred. Sáltate ese paso y tienes un firewall perfectamente configurado con una factura mensual y cero paquetes. Cuando un escenario dice que el firewall está desplegado y bien configurado pero el tráfico no se filtra, las rutas son la respuesta.

Cuatro revisiones más, en el orden en que suelen morder:

Cobertura de zonas de disponibilidad. Un endpoint por AZ, y la disponibilidad del endpoint se limita a su propia zona. Las cargas de trabajo en una AZ sin firewall endpoint quedan sin filtrar, o su tráfico cruza el límite de la AZ para llegar a un endpoint en otra zona y se lleva cargos de transferencia entre zonas en el camino. Compara la lista de AZs con subredes de carga de trabajo contra la lista de AZs con subredes de firewall.

Subredes de firewall dedicadas. Un firewall endpoint no puede filtrar el tráfico que entra o sale de la subred donde vive. Pon una carga de trabajo en una subred de firewall y esa carga queda exenta de inspección. AWS es explícito: no uses las subredes de firewall para ninguna otra cosa.

Acciones stateless por defecto. El motor stateless corre primero y decide si cada paquete se pasa, se descarta o se reenvía al motor stateful. Si la acción stateless por defecto es Pass y ninguna regla stateless reenvía tráfico hacia adelante, tus reglas Suricata y tus listas de dominios nunca se ejecutan. La policy es perfectamente válida, y eso es lo que la convierte en un hallazgo de auditoría en lugar de un error. El mismo ajuste tiene un valor por defecto aparte para los fragmentos de paquetes UDP; Network Firewall descarta en silencio los fragmentos de otros protocolos.

Orden de evaluación de las reglas stateful. Una policy usa action order o strict order, y RuleOrder solo se puede definir cuando se crea la policy. Después no se puede editar. Con action order, Suricata evalúa todas las reglas pass antes que cualquier regla drop, reject o alert, sin importar la palabra clave priority, así que una regla pass permisiva en cualquier rule group anula todo lo que viene abajo. Con strict order, los rule groups corren por prioridad ascendente y las reglas corren en el orden en que están escritas, y además eliges acciones por defecto como Drop all o Drop established. AWS recomienda strict order justo por esa previsibilidad. Si una auditoría encuentra una regla drop que nunca dispara, action order más una regla pass amplia es la primera hipótesis.

Para la evidencia, el logging de Network Firewall está apagado hasta que lo configuras, y produce 3 tipos de log que habilitas por separado:

La restricción que agarra desprevenido a la gente: solo se registra el tráfico reenviado al motor stateful. Los descartes stateless nunca aparecen en estos logs. Las métricas de CloudWatch cubren los 2 motores y son el lugar correcto para confirmar que al firewall le está llegando tráfico.

Un último dato que conviene registrar: la protección contra borrado viene habilitada cuando se crea un firewall y hay que apagarla de forma explícita por la API antes de poder borrarlo. La consola no muestra el ajuste porque el flujo de eliminación lo desactiva por ti.

Auditar Route 53 Resolver DNS Firewall

DNS Firewall filtra las consultas DNS salientes mientras pasan por el Route 53 VPC Resolver. Su trabajo principal es detener la exfiltración por DNS, donde un atacante que comprometió una instancia codifica datos dentro de búsquedas contra un dominio que controla. También bloquea la resolución de registros de private hosted zones, de nombres de VPC endpoints y de nombres de instancias EC2.

Asociación. Los rule groups no hacen nada hasta asociarse a una VPC, y puedes asociar hasta 5 rule groups por VPC por región. Confirma la asociación y su prioridad, y después revisa que el orden de prioridad coincida con tu intención, ya que los números más bajos se evalúan primero tanto entre rule groups asociados como entre las reglas de un mismo grupo.

aws route53resolver list-firewall-rule-group-associations --vpc-id vpc-0abc123
aws route53resolver list-firewall-rules --firewall-rule-group-id rslvr-frg-0abc123
aws route53resolver list-firewall-configs        # el ajuste de fail open por VPC

Acción de la regla. Cada regla lleva exactamente una de 3 acciones:

AWS misma recomienda crear una regla de bloqueo primero como Alert para medir cuántas consultas habría bloqueado. Ese consejo produce el hallazgo de DNS Firewall más común que existe: un rule group donde cada regla sigue en Alert un año después. Alert es un detector; Block es un control. Leer la lista de acciones es una revisión de 30 segundos con consecuencias reales.

Respuesta de bloqueo. Cuando la acción es Block, eliges qué escucha el cliente de vuelta:

• NODATA responde que la consulta tuvo éxito pero no hay registro disponible.
• NXDOMAIN responde que el nombre de dominio no existe.
• OVERRIDE devuelve un CNAME propio que tú especificas, con un tiempo de vida que por defecto es 0 para que la respuesta no se cachee. Así ruteas las búsquedas bloqueadas a un sinkhole o a una página de advertencia interna.

Listas de dominios administradas. AWS mantiene 4 listas que puedes usar gratis: Malware, Botnet/Command and Control, Aggregate Threat List (un superconjunto de las otras que suma ransomware, spyware y DNS tunneling) y Amazon GuardDuty Threat List (dominios de los propios hallazgos de DNS de GuardDuty). No puedes ver ni descargar su contenido, y es a propósito: una lista de bloqueo publicada es una especificación para evadirla. Cuando una lista administrada produce un falso positivo, el arreglo es agregar una regla allow para ese dominio puntual y darle una prioridad numérica más baja que la regla de bloqueo, para que corra primero.

Modo de falla. Este es el ajuste que nadie revisa. Cuando el VPC Resolver no recibe respuesta de DNS Firewall, la configuración de firewall de la VPC decide qué pasa:

• Fail closed es el default. La consulta se bloquea y el VPC Resolver devuelve SERVFAIL. Seguridad antes que disponibilidad.
• Fail open, que se define con el campo FirewallFailOpen, deja pasar la consulta. Disponibilidad antes que seguridad.

Las 2 son opciones legítimas y ninguna es un error. Pero una VPC en fail open pierde sus protecciones de DNS exactamente en los momentos en que un atacante querría verlas apagadas, así que el hallazgo de auditoría no es "fail open está mal", es "fail open está puesto y nadie documentó la decisión".

Conviene memorizar junto con la configuración: 5 rule groups por VPC, 100 reglas por rule group, 1.000 rule groups por cuenta por región, 100.000 dominios entre todas tus listas de dominios.

De revisiones puntuales a evidencia permanente

Todo lo anterior es una respuesta de un momento dado. Una auditoría que hay que repetir a mano cada trimestre no se va a repetir.

AWS Config registra los cambios de configuración de estos recursos y evalúa reglas administradas contra ellos de forma continua, así que un web ACL que pierde su asociación o una firewall policy cuya acción por defecto cambia genera un hallazgo de incumplimiento por su cuenta. Los conformance packs juntan las reglas relevantes en una sola unidad desplegable.

AWS Security Hub agrega esos hallazgos de Config junto con los de GuardDuty e Inspector y los puntúa contra estándares como AWS Foundational Security Best Practices, lo que convierte "¿estamos protegidos?" en un número con una línea de tendencia.

Las alarmas de CloudWatch cierran la pregunta 3 de forma permanente. Una alarma sobre el BlockedRequests de un web ACL en cero durante una semana entera, o sobre los contadores de paquetes de Network Firewall cayendo a nada, agarra las regresiones silenciosas que una revisión trimestral se pierde por 89 días.

Una nota de alcance que importa para el examen. Esta habilidad está escrita como auditar estos servicios en una sola cuenta. En cuanto la pregunta se ensancha a cada VPC de cada cuenta miembro, incluidas cuentas que todavía no existen, la respuesta cambia a AWS Firewall Manager, que aplica de forma central políticas de AWS WAF, Shield Advanced, security groups, network ACLs, Network Firewall y DNS Firewall en toda una organización y trae automáticamente los recursos nuevos al alcance. Firewall Manager exige AWS Organizations y AWS Config. Archívalo como la respuesta organizacional para que no te tiente en una pregunta de una sola cuenta.

Tips de examen

• Existir no es proteger. Para WAF lee la asociación, para Shield lee la lista de protections, para Network Firewall lee las route tables, para DNS Firewall lee la asociación con la VPC. Ese solo movimiento responde casi todas las preguntas de auditoría de esta habilidad.
• Count, Alert y Pass son los ajustes de solo observar. Count y los overrides de rule group en WAF, la mitigación automática de Shield puesta en contar, la acción stateless por defecto Pass de Network Firewall, y Alert en DNS Firewall. Un escenario que dice "los logs muestran el tráfico pero no se bloquea" apunta a alguno de estos.
• El filtrado por dominio aparece 2 veces. Las consultas por el Resolver son DNS Firewall; el tráfico en el cable es Network Firewall. Network Firewall no tiene visibilidad de las consultas al Resolver.
• AWS WAF solo se engancha a tipos de recurso HTTP. CloudFront, ALB, API Gateway, AppSync, user pools de Cognito, App Runner, Bedrock AgentCore Gateway, Verified Access, Amplify. No EC2, no NLB, no RDS.
• Shield Standard es gratis y automático; Shield Advanced cuesta $3.000 al mes con compromiso de 1 año y protege solo los recursos que agregas de forma explícita.
• Route tables, subredes de firewall dedicadas y un endpoint por AZ en Network Firewall. Un firewall endpoint no puede filtrar su propia subred.
• RuleOrder se define al crear la policy y no se puede cambiar. Strict order es la opción recomendada.
• DNS Firewall falla cerrado por defecto y devuelve SERVFAIL. El fail open es opcional y explícito.
• Una sola cuenta es la auditoría; AWS Organizations es Firewall Manager.

El hábito que vale llevarse es más chico que la lista de servicios: para cualquier control de protección, encuentra el vínculo que lo conecta con tráfico real, y después encuentra el ajuste que decide si actúa o solo mira. Esos 2 datos son la auditoría. La lección siguiente mira la misma red desde el lado contrario, y no pregunta si está protegida sino cuánto te cuesta cada gigabyte que la cruza.