AWS Network Firewall cambia su acción predeterminada: cómo afecta a tus reglas de seguridad

Introducción

Hasta hace unos días, AWS Network Firewall aplicaba la acción «Application drop established (bidirectional)» por defecto en todas las políticas de firewall nuevas. Este comportamiento, aunque útil para bloquear tráfico malicioso, tenía un efecto colateral no deseado: podía interrumpir conexiones TCP legítimas como actualizaciones de ventana, keep-alives y resets. El problema no era visible a simple vista, pero generaba fallas intermitentes en aplicaciones que dependían de flujos de red estables.

AWS resolvió este comportamiento al cambiar el valor predeterminado a «Application drop established (server-directed only)» en políticas nuevas. Esta modificación reduce el riesgo de caídas silenciosas sin afectar la capacidad de bloquear tráfico no autorizado. Sin embargo, el cambio introduce un requerimiento de revisión en reglas existentes que dependan del comportamiento anterior, especialmente en entornos con protocolos TLS fragmentados o criptografía post-cuántica.

Qué ocurrió

El 17 de junio de 2026, AWS anunció que AWS Network Firewall actualizó el comportamiento predeterminado de las políticas de firewall recién creadas. La acción anterior, «Application drop established (bidirectional)» —también conocida como «Application layer drop established»—, bloqueaba tanto paquetes del cliente al servidor (to_server) como del servidor al cliente (to_client) en conexiones TCP establecidas. Esto incluía paquetes críticos para la estabilidad de la conexión, como:

• TCP window updates: paquetes que notifican cambios en el tamaño de la ventana de recepción.
• TCP keep-alives: mensajes para mantener vivas conexiones inactivas.
• TCP resets (RST): señales de terminación de conexión.

El problema era silencioso: las aplicaciones afectadas no generaban logs claros y los fallos aparecían como interrupciones intermitentes o timeouts. Según la documentación de AWS, esto ocurría porque el firewall interpretaba estos paquetes como «tráfico establecido» y los descartaba si no coincidían con las expectativas de la política.

El cambio introduce dos acciones predeterminadas distintas, según el contexto:

1. «Application drop established (server-directed only)» (nuevo predeterminado):

– Permite el tráfico de vuelta del cliente al servidor (to_server).

– Reduce el riesgo de caídas silenciosas en conexiones legítimas.

1. «Application drop established (bidirectional)» (opcional):

– Requiere configuración manual en políticas existentes o nuevas que necesiten este comportamiento.

AWS aclaró que no es necesario realizar ninguna acción para beneficiarse del cambio en políticas nuevas. El valor predeterminado se aplica automáticamente al crear una política. Sin embargo, los equipos que dependían del comportamiento anterior deben revisar sus reglas para evitar interrupciones.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y Cloud

El cambio afecta principalmente a equipos que gestionan políticas de AWS Network Firewall en entornos con tráfico TCP complejo, como:

• Aplicaciones con TLS 1.3 fragmentado o con handshakes extendidos.
• Servicios que dependen de keep-alives para mantener conexiones persistentes (como bases de datos o colas de mensajes).
• Arquitecturas con balanceadores de carga que usan health checks frecuentes.

Según datos de AWS, este cambio reduce en un 30% las interrupciones no diagnosticadas en políticas nuevas. Sin embargo, en entornos con reglas personalizadas que dependían del comportamiento anterior, el impacto podría ser mayor si no se actualizan. Por ejemplo, políticas que bloqueaban tráfico bidireccional para cumplir con estándares de seguridad podrían dejar de funcionar como se esperaba.

Para equipos de Seguridad

Desde el punto de vista de seguridad, el cambio no debilita la capacidad de bloquear tráfico malicioso, pero sí modifica cómo se aplican las reglas de estado:

• Ventaja: Elimina falsos positivos en detección de tráfico legítimo.
• Riesgo: Si una política dependía del bloqueo bidireccional para mitigar un vector de ataque específico (como fugas de datos en túneles TLS), ahora debe ajustarse manualmente.

AWS recomienda revisar políticas que usen la acción "stateful_rule_action": "DROP" sin flags adicionales. En particular, políticas con reglas tipo "DROP", "ALERT", o "PASS" en modo estado deben evaluarse para evitar comportamientos inesperados.

Para equipos de SRE

Los Site Reliability Engineers deben monitorear métricas de conectividad en políticas nuevas y existentes. El cambio introduce un riesgo de regresión si:

• Las aplicaciones dependen de conexiones TCP mantenidas por largos períodos.
• Se usan protocolos como WebSockets, gRPC, o bases de datos con conexiones persistentes.

AWS sugiere configurar alertas en CloudWatch para métricas como:

• NetworkFirewallManagedStatefulRuleEvaluations
• NetworkFirewallManagedStatefulRuleDrops

Si se detecta un aumento en descartes de paquetes, es señal de que alguna regla necesita ajuste.

Detalles técnicos

Versiones afectadas

El cambio se aplica a todas las políticas nuevas de AWS Network Firewall creadas después del 17 de junio de 2026, en todas las regiones donde el servicio está disponible. No hay versión específica del servicio afectada, ya que la modificación es en el comportamiento predeterminado del motor de análisis de estado.

Componentes involucrados

1. AWS Network Firewall Engine: Motor de análisis de estado que evalúa paquetes en conexiones TCP/UDP/ICMP.
2. Políticas de Firewall: Conjunto de reglas que definen acciones sobre tráfico (permitir, bloquear, alertar).
3. Reglas estadoful: Reglas que evalúan el estado de las conexiones (ej: "stateful_rule": { "action": "DROP", "header": { "protocol": "TCP", "direction": "FORWARD" } }).

Comportamiento anterior vs. nuevo

Considera una política con una regla estadoful que bloquea tráfico no autorizado:

{
  "StatefulRuleGroup": {
    "Rules": [
      {
        "RuleType": "STATEFUL",
        "Action": "DROP",
        "Header": {
          "Protocol": "TCP",
          "Direction": "FORWARD",
          "Source": "0.0.0.0/0",
          "Destination": "192.168.1.0/24"
        }
      }
    ]
  }
}

• Bloqueaba tanto paquetes del cliente al servidor como del servidor al cliente.
• Podía descartar keep-alives o resets, causando fallos intermitentes.

• Solo bloquea paquetes del servidor al cliente, permitiendo respuestas del cliente.
• Reduce el riesgo de caídas silenciosas.

Requisitos para políticas existentes

Si una política existente usa "Application drop established (bidirectional)" y depende de este comportamiento (por ejemplo, para cumplir con estándares de seguridad o mitigar un vector de ataque específico), AWS recomienda:

1. Migrar a «server-directed only»:

   # Ejemplo de actualización usando AWS CLI
   aws network-firewall update-firewall-policy \
     --firewall-policy-arn arn:aws:network-firewall:us-east-1:123456789012:firewall-policy/my-policy \
     --stateful-default-actions '[
       {"Action": "DROP", "Override": {"StatefulRuleAction": "Application drop established (server-directed only)"}}
     ]'
   

1. Añadir flags explícitos a reglas TCP:

   {
     "Rules": [
       {
         "RuleType": "STATEFUL",
         "Action": "DROP",
         "Header": {
           "Protocol": "TCP",
           "Direction": "FORWARD",
           "Source": "0.0.0.0/0",
           "Destination": "192.168.1.0/24"
         },
         "Override": {
           "StatefulRuleAction": "Application drop established (server-directed only)",
           "Flags": ["SYN", "FIN", "RST"]
         }
       }
     ]
   }
   

Qué deberían hacer los administradores y equipos técnicos

1. Revisar políticas nuevas y existentes

• Políticas nuevas: No es necesario hacer nada. El nuevo comportamiento predeterminado se aplica automáticamente.
• Políticas existentes: Identificar reglas que usen "stateful_rule_action": "DROP" sin flags adicionales. Priorizar políticas con:

– Tráfico TCP con handshakes complejos (ej: TLS 1.3 con fragmentación).

aws network-firewall list-firewall-policies --query 'FirewallPolicies[*].[Name, Arn]' --output table

2. Actualizar reglas críticas

Si una política depende del bloqueo bidireccional (por ejemplo, para cumplir con un estándar de seguridad como PCI DSS o NIST), actualizarla con:

# Actualizar política para usar el nuevo comportamiento predeterminado
aws network-firewall update-firewall-policy \
  --firewall-policy-arn arn:aws:network-firewall:us-west-2:123456789012:firewall-policy/my-secure-policy \
  --stateful-default-actions '[
    {"Action": "DROP", "Override": {"StatefulRuleAction": "Application drop established (server-directed only)"}}
  ]'

3. Validar con pruebas de carga

Antes de aplicar cambios en producción, simular tráfico TCP con keep-alives y resets en un entorno de staging. Usar herramientas como:

• iperf3 para generar tráfico TCP persistente:

  iperf3 -c <IP_DESTINO> -t 60 -i 5
  

• tcpdump para verificar descartes:

  tcpdump -i any -n 'tcp[tcpflags] & (tcp-rst|tcp-ack) != 0'
  

4. Monitorear métricas post-cambio

Configurar alertas en CloudWatch para:

• NetworkFirewallManagedStatefulRuleDrops: Aumentos inusuales indican reglas que necesitan ajuste.
• NetworkFirewallManagedStatefulRuleEvaluations: Comparar con líneas de base previas al cambio.

Alarm:
  AlarmName: "NetworkFirewallHighDropRate"
  MetricName: "NetworkFirewallManagedStatefulRuleDrops"
  Namespace: "AWS/NetworkFirewall"
  Statistic: "Sum"
  Period: 300
  Threshold: 100
  ComparisonOperator: "GreaterThanThreshold"

5. Documentar cambios en la política de seguridad

Actualizar la documentación interna para reflejar:

• El nuevo comportamiento predeterminado en políticas nuevas.
• Los pasos para migrar políticas existentes.
• Casos de uso donde "Application drop established (bidirectional)" sigue siendo necesario (ej: entornos con criptografía post-cuántica).

Conclusión

AWS Network Firewall simplificó su comportamiento predeterminado para reducir interrupciones en conexiones TCP legítimas. El cambio de "Application drop established (bidirectional)" a "Application drop established (server-directed only)" en políticas nuevas es un avance en fiabilidad sin sacrificar seguridad, pero requiere atención en entornos con reglas estadoful personalizadas.

1. No hacer nada en políticas nuevas (el cambio es automático).
2. Revisar políticas existentes que usen bloqueo bidireccional.
3. Validar con pruebas de carga antes de aplicar cambios en producción.
4. Monitorear métricas post-cambio para detectar ajustes necesarios.

Este cambio subraya la importancia de probar políticas de firewall en entornos controlados antes de aplicarlas a producción. AWS Network Firewall sigue evolucionando para equilibrar seguridad y confiabilidad, pero la responsabilidad de adaptar reglas existentes recae en los equipos de infraestructura.