Security Groups son Stateful, NACLs son Stateless - La decisión de diseño detrás de esta diferencia
Explicamos cómo los Security Groups operan de forma stateful mediante el seguimiento de conexiones, por qué las NACLs son stateless, la trampa de los puertos efímeros y los patrones de diseño de defensa en profundidad combinando ambos.
La diferencia entre Stateful y Stateless
Un Security Group es un firewall stateful. Las respuestas a las solicitudes permitidas por las reglas de entrada se permiten automáticamente independientemente de las reglas de salida. A la inversa, las respuestas a las solicitudes permitidas por las reglas de salida se permiten automáticamente independientemente de las reglas de entrada. Una NACL (Network Access Control List) es un firewall stateless. Las reglas de entrada y salida se evalúan de forma independiente. Incluso si una respuesta pertenece a una solicitud permitida por una regla de entrada, será bloqueada si no está explícitamente permitida por una regla de salida. Esta diferencia se origina en una distinción fundamental a nivel de implementación. Los Security Groups mantienen una tabla de seguimiento de conexiones (Connection Tracking) que registra el estado de cada conexión (IP de origen, IP de destino, puerto, protocolo). Cuando llega un paquete de respuesta, se compara con la tabla de seguimiento de conexiones y, si pertenece a una conexión existente, se permite automáticamente. Las NACLs no mantienen una tabla de seguimiento de conexiones y evalúan cada paquete de forma independiente.
Por qué existen dos tipos de firewalls
Aunque los Security Groups por sí solos podrían parecer suficientes, las NACLs existen debido al principio de defensa en profundidad (Defense in Depth). Los Security Groups operan a nivel de instancia (nivel de ENI), mientras que las NACLs operan a nivel de subred. Estas dos capas proporcionan protección en diferentes niveles. Si un Security Group se ve comprometido (por ejemplo, si un atacante con permisos IAM modifica las reglas del Security Group), la NACL sirve como respaldo. Dado que las NACLs se aplican a toda la subred, mantienen la protección incluso si los Security Groups de instancias individuales son alterados. Otra razón es la necesidad de reglas de Deny explícitas. Los Security Groups solo pueden definir reglas de permiso, no reglas de denegación. Si desea bloquear explícitamente el acceso desde una dirección IP específica, los Security Groups no pueden hacerlo. Las NACLs pueden definir tanto reglas de permiso como de denegación, evaluadas en orden por número de regla, lo que permite bloquear explícitamente direcciones IP específicas.
La trampa de los puertos efímeros con NACLs
El error de configuración más común causado por la naturaleza stateless de las NACLs es no permitir los puertos efímeros (puertos temporales). Cuando un cliente se conecta a un servidor, el puerto de origen del cliente utiliza un puerto efímero asignado dinámicamente por el sistema operativo. Linux utiliza el rango 32768-60999 y Windows utiliza 49152-65535. Incluso si la regla de salida de la NACL permite HTTP (puerto 80), la respuesta se envía al puerto efímero del cliente. Si la regla de entrada de la NACL no permite el rango de puertos efímeros, la respuesta es bloqueada. Este problema no ocurre con los Security Groups. Al ser stateful, las respuestas a solicitudes permitidas en la salida se permiten automáticamente. Al usar NACLs, es práctica común permitir el rango de puertos efímeros (1024-65535) tanto en las reglas de entrada como de salida. Si permitir un rango tan amplio resulta incómodo, utilice Security Groups para el control granular y mantenga las NACLs para el control grueso a nivel de subred.
Detalles del seguimiento de conexiones de Security Groups
El seguimiento de conexiones de los Security Groups tiene tanto conexiones rastreadas como no rastreadas. Cuando se configuran reglas que permiten todo el tráfico (0.0.0.0/0) tanto para entrada como para salida, el seguimiento de conexiones no se realiza porque es innecesario. En este caso, se elimina la sobrecarga del seguimiento de conexiones, mejorando el rendimiento. La tabla de seguimiento de conexiones tiene un límite de tamaño. Por defecto, cada ENI puede mantener hasta 65,535 conexiones rastreadas. Cuando se alcanza este límite, no se pueden establecer nuevas conexiones. Las cargas de trabajo que manejan grandes cantidades de conexiones de corta duración (como instancias detrás de un balanceador de carga) deben vigilar el agotamiento de la tabla de seguimiento de conexiones. La métrica de CloudWatch ConnTrackAllowanceExceeded puede usarse para monitorear el agotamiento de la tabla de seguimiento de conexiones. Los tiempos de espera del seguimiento de conexiones son 5 días para conexiones TCP establecidas, 180 segundos para UDP y 30 segundos para ICMP. Las conexiones que expiran se eliminan de la tabla.
Patrones prácticos de diseño de defensa en profundidad
A continuación se presentan patrones de diseño prácticos que combinan Security Groups y NACLs. Para un ALB en una subred pública, permita HTTP/HTTPS de entrada (0.0.0.0/0) en el Security Group y deje la NACL en su configuración predeterminada (permitir todo). Dado que el ALB es un servicio público, no es necesario restringir a nivel de NACL. Para servidores de aplicaciones en una subred privada, permita el tráfico de entrada solo desde el Security Group del ALB en el Security Group, y permita el tráfico de entrada solo desde el CIDR de la subred del ALB en la NACL. El Security Group permite solo el tráfico del ALB, y la NACL proporciona defensa de respaldo a nivel de subred. Para la subred de base de datos, permita el tráfico de entrada solo desde el Security Group del servidor de aplicaciones en el Security Group, y permita el tráfico de entrada solo desde el CIDR de la subred de aplicaciones en la NACL. Si se detecta un ataque desde una dirección IP específica, puede bloquearse inmediatamente con una regla de denegación en la NACL. Los cambios en Security Groups se aplican por instancia, pero los cambios en NACLs se aplican instantáneamente a toda la subred, lo que hace que las NACLs sean adecuadas para respuestas de emergencia. Para aprender diseño de seguridad de redes de forma sistemática, libros especializados (Amazon) son un recurso útil.