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 debe a si la implementación rastrea o no el estado de las conexiones. 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
Una razón para usar las NACLs junto con los Security Groups es el 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, sus reglas siguen aplicándose a nivel de subred 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
Un error de configuració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, usted configura las reglas de entrada y de salida para permitir el rango de puertos efímeros (1024-65535). Si permitir un rango tan amplio resulta incómodo, una opción es utilizar Security Groups para el control granular y mantener 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. En los flujos TCP y UDP, cuando una regla permite todo el tráfico (0.0.0.0/0 o ::/0) y una regla en la dirección opuesta permite todo el tráfico de respuesta para cualquier puerto, el seguimiento de conexiones no se realiza (salvo en las conexiones con seguimiento automático) porque es innecesario. La tabla de seguimiento de conexiones tiene un límite de tamaño. Amazon EC2 define el número máximo de conexiones que se pueden rastrear por instancia. Cuando se alcanza el máximo, los paquetes que se envían o reciben se descartan porque no se pueden establecer nuevas conexiones. En las cargas de trabajo que manejan grandes cantidades de conexiones de corta duración (como instancias detrás de un balanceador de carga), usted supervisa el número de conexiones rastreadas. La métrica de rendimiento de red conntrack_allowance_exceeded muestra si se descartaron paquetes porque se superó el número máximo de conexiones rastreadas. Los tiempos de espera predeterminados del seguimiento de conexiones inactivas son 30 segundos para UDP y 180 segundos para los flujos UDP de tipo stream, y el de las conexiones TCP establecidas varía según el tipo de instancia. 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, esta configuración no lo restringe 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 con una regla de denegación en la NACL. Cambiar una regla de un Security Group no interrumpe de inmediato las conexiones rastreadas, pero bloquear el tráfico con una NACL también interrumpe las conexiones existentes, por lo que las NACLs pueden usarse para respuestas de emergencia.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.