Seguimiento de conexiones de grupos de seguridad

Los grupos de seguridad utilizan el seguimiento de las conexiones para realizar un seguimiento de la información sobre el tráfico hacia y desde la instancia. Las reglas se aplican según el estado de la conexión del tráfico para determinar si el tráfico se permite o se deniega. Con este enfoque, los grupos de seguridad tienen estado. Esto significa que se permite la salida de las repuestas al tráfico de entrada de la instancia, independientemente de las reglas de salida del grupo de seguridad y viceversa.

Por ejemplo, suponga que inicia un comando como netcat o alguno similar en las instancias desde la computadora doméstica y las reglas de tráfico de entrada del grupo de seguridad permiten el tráfico de ICMP. Se realiza un seguimiento de la información sobre la conexión (incluida la información del puerto). El tráfico de respuesta desde la instancia del comando no se sigue como una nueva solicitud, sino como una conexión establecida, y se permite que salga de la instancia, aunque las reglas de salida del grupo de seguridad restrinjan el tráfico de ICMP de salida.

En el caso de otros protocolos que no sean TCP, UDP o ICMP, solo se realiza el seguimiento de la dirección IP y del número de protocolo. Si la instancia envía tráfico a otro host, y este envía el mismo tipo de tráfico a su instancia en un plazo de 600 segundos, el grupo de seguridad de la instancia lo acepta independientemente de las reglas de entrada. El grupo de seguridad lo acepta porque se considera un tráfico de respuesta del tráfico original.

Cuando cambia una regla del grupo de seguridad, las conexiones de seguimiento no se interrumpen de forma inmediata. El grupo de seguridad sigue permitiendo paquetes hasta que las conexiones existentes se agoten. Para asegurarse de que el tráfico se interrumpa de forma inmediata, o que todo el tráfico esté sujeto a reglas de firewall, independientemente del estado de seguimiento, puede utilizar una ACL de red para su subred. Las ACL de red son sin estado y, por lo tanto, no permiten automáticamente el tráfico de respuesta. Agregar una ACL de red que bloquee el tráfico en cualquier dirección provoca la interrupción de las conexiones existentes. Para obtener más información, consulte la sección relacionada con las ACL de red en la Guía del usuario de Amazon VPC.

nota

Los grupos de seguridad no afectan al tráfico de DNS hacia el servicio Route 53 Resolver o desde el mismo, a veces denominado “dirección IP de VPC+2” (consulte ¿Qué es Amazon Route 53 Resolver? en la Guía para desarrolladores de Amazon Route 53) o “AmazonProvidedDNS” (consulte Trabajo con conjuntos de opciones de DHCP en la Guía del usuario de Amazon Virtual Private Cloud). Si desea filtrar las solicitudes de DNS a través de Route 53 Resolver, puede habilitar el firewall de DNS de Route 53 Resolver (consulte Firewall de DNS de Route 53 Resolver en la Guía para desarrolladores de Amazon Route 53).

Conexiones sin seguimiento

No se realiza un seguimiento de todos los flujos de tráfico. Si una regla del grupo de seguridad permite los flujos TCP o UDP para todo el tráfico (0.0.0.0/0 o ::/0) y hay una regla correspondiente en la otra dirección que permita todo el tráfico de respuesta (0.0.0.0/0 o ::/0) para todos los puertos (0-65 535), no se realizará un seguimiento de ese flujo de tráfico, a menos que sea parte de una conexión de la cual se realiza un seguimiento de manera automática. En el caso de un flujo sin seguimiento, se permite el tráfico de respuesta en función de la regla de entrada o de salida que permita el tráfico de respuesta y no según la información de seguimiento.

Un flujo de tráfico del que no se realiza seguimiento se interrumpe de inmediato si se elimina o modifica la regla que permite el flujo. Por ejemplo, si tiene una regla de salida abierta (0.0.0.0/0) y elimina una regla que permite todo el tráfico SSH (puerto TCP 22) entrante (0.0.0.0/0) a la instancia (o la modifica de modo que la conexión ya no se permita), las conexiones SSH existentes a la instancia se eliminan inmediatamente. La conexión no estaba siendo rastreada previamente, por lo que el cambio romperá la conexión. Por otro lado, si tiene una regla de entrada más estrecha que inicialmente permite la conexión SSH (lo que significa que se hizo un seguimiento de la conexión), pero cambia esa regla para que ya no permita nuevas conexiones desde la dirección del cliente SSH actual, la conexión SSH existente no se interrumpirá porque se le ha hecho un seguimiento.

Conexiones con seguimiento automático

Se hace un seguimiento automático de las conexiones realizadas a través de lo siguiente, incluso si la configuración del grupo de seguridad no requiere otro tipo de seguimiento. Se debe hacer un seguimiento de estas conexiones a fin de garantizar un enrutamiento simétrico, ya que podría haber varias rutas de respuesta válidas.

• Gateways de Internet de solo salida

• Equilibradores de carga de puerta de enlace

• Aceleradores de Global Accelerator

• Puerta de enlace NAT

• Puntos de conexión de firewall de Network Firewall

• Equilibrador de carga de red

• AWS PrivateLink (Puntos de conexión de VPC de tipo interfaz)

• Vinculaciones de las puerta de enlaces de tránsito

• AWS Lambda (interfaces de red elásticas de hiperplano)

Limitación

Amazon EC2 define el número máximo de conexiones que se pueden rastrear por instancia. Una vez alcanzado el máximo, los paquetes que se envían o reciben se pierden porque no se puede establecer una nueva conexión. Cuando esto sucede, las aplicaciones que envían y reciben paquetes no pueden comunicarse correctamente. Utilice la métrica de rendimiento de red conntrack_allowance_available para determinar la cantidad de conexiones rastreadas que aún están disponibles para ese tipo de instancia.

Para determinar si los paquetes se descartaron porque el tráfico de red de la instancia excedió el número máximo de conexiones que se pueden rastrear, utilice la métrica de rendimiento de red conntrack_allowance_exceeded. Para obtener más información, consulte Monitorear el rendimiento de la red de la instancia EC2.

Con Elastic Load Balancing, si supera el número máximo de conexiones que se pueden rastrear por instancia, se recomienda escalar el número de instancias registradas con el equilibrador de carga o el tamaño de instancias registradas con el equilibrador de carga.

Tiempo de espera de seguimiento de conexiones inactivas

El grupo de seguridad hace el seguimiento de cada conexión establecida para asegurarse de que los paquetes devueltos se entreguen como se espera. Existe un número máximo de conexiones que se pueden rastrear por instancia. Las conexiones que permanecen inactivas pueden provocar que se agote el seguimiento de las conexiones, que no se rastreen y que se pierdan paquetes. Puede establecer el tiempo de espera para el seguimiento de las conexiones inactivas en una interfaz de red elástica.

nota

Esta característica solo está disponible para las instancias de EC2 basadas en Nitro.

Hay tres tiempos de espera configurables:

• Tiempo de espera establecido de TCP: tiempo de espera (en segundos) para las conexiones TCP inactivas en un estado establecido. Valor mínimo: 60 segundos. Valor máximo: 432 000 segundos (5 días). Valor predeterminado: 432 000 segundos. Valor recomendado: menos de 432 000 segundos.

• Tiempo de espera de UDP: tiempo de espera (en segundos) para los flujos de UDP inactivos que solo han registrado tráfico en una sola dirección o en una sola transacción de solicitud-respuesta. Valor mínimo: 30 segundos. Valor máximo: 60 segundos. Valor predeterminado: 30 segundos.

• Tiempo de espera del flujo de UDP: tiempo de espera (en segundos) para los flujos de UDP inactivos clasificados como flujos que han recibido más de una transacción de solicitud-respuesta. Valor mínimo: 60 segundos. Valor máximo: 180 segundos (3 minutos). Valor predeterminado: 180 segundos.

Si quiere modificar los tiempos de espera predeterminados para cualquiera de los siguientes casos:

• Si supervisa las conexiones rastreadas mediante métricas de rendimiento de red de Amazon EC2, las métricas conntrack_allowance_exceeded y conntrack_allowance_available le permiten supervisar los paquetes descartados y el uso de las conexiones rastreadas para administrar de forma proactiva la capacidad de la instancia de EC2 con acciones de escalado vertical u horizontal para ayudar a satisfacer la demanda de conexiones de red antes de descartar paquetes. Si observa caídas de conntrack_allowance_exceeded en sus instancias de EC2, puede resultarle útil definir un tiempo de espera establecido de TCP más bajo para tener en cuenta las sesiones de TCP/UDP obsoletas que se deben a clientes o cajas intermedias de red inadecuadas.

• Por lo general, los equilibradores de carga o los firewalls tienen un tiempo de espera de inactividad establecido de TCP de entre 60 y 90 minutos. Si ejecuta cargas de trabajo que se espera que gestionen un número muy elevado de conexiones (más de 100 000) desde dispositivos como firewalls de red, se recomienda configurar un tiempo de espera similar en una interfaz de red de EC2.

• Si ejecuta cargas de trabajo con un gran número de conexiones, como DNS, SIP, SNMP, Syslog, Radius y otros servicios que utilizan principalmente UDP para atender las solicitudes, establecer el tiempo de espera de “flujo de UDP” en 60 segundos proporciona una mayor escala o un mayor rendimiento para la capacidad existente y evita errores grises.

• En el caso de las conexiones TCP o UDP a través de equilibradores de carga de red (NLB) y equilibradores de carga elásticos (ELB), se hace un seguimiento de todas las conexiones. El valor de tiempo de espera de inactividad para los flujos de TCP es de 350 segundos y para los flujos de UDP es de 120 segundos, y varía según los valores de tiempo de espera de nivel de interfaz. Es posible que quiera configurar los tiempos de espera en el nivel de interfaz de red para permitir una mayor flexibilidad de tiempo de espera que los tiempos de espera predeterminados para ELB o NLB.

Tiene la opción de configurar los tiempos de espera de seguimiento de conexiones si hace lo siguiente:

• Crear una interfaz de red

• Modificar atributos de interfaz de red

• Lanzar una instancia de EC2

• Crear una plantilla de lanzamiento de una instancia de EC2

Ejemplo

En el siguiente ejemplo, el grupo de seguridad incluye reglas de entrada que permiten el tráfico TCP e ICMP y reglas de salida que permiten todo el tráfico de salida.

Entrada
Tipo de protocolo	Número de puerto	Origen
TCP	22 (SSH)	203.0.113.1/32
TCP	80 (HTTP)	0.0.0.0/0
TCP	80 (HTTP)	::/0
ICMP	Todos	0.0.0.0/0

Salida
Tipo de protocolo	Número de puerto	Destino
Todos	Todos	0.0.0.0/0
Todos	Todos	::/0

Con una conexión de red directa a la instancia o la interfaz de red, el comportamiento del seguimiento es el siguiente:

• Se hace un seguimiento del tráfico TCP entrante y saliente en el puerto 22 (SSH), ya que la regla de entrada solo permite el tráfico desde 203.0.113.1/32 y no todas las direcciones IP (0.0.0.0/0).

• No se hace un seguimiento del tráfico TCP entrante y saliente en el puerto 80 (HTTP), ya que tanto las reglas de entrada como las de salida permiten el tráfico desde todas las direcciones IP.

• Siempre se hace un seguimiento del tráfico ICMP.

Si elimina la regla de salida para el tráfico IPv4, se hace un seguimiento de todo el tráfico IPv4 entrante y saliente, incluido el tráfico del puerto 80 (HTTP). Lo mismo ocurre con el tráfico IPv6 si se elimina la regla de salida para este.