Sesiones TCP
Para enviar datos a través de TCP en una red, se sigue un proceso de establecimiento de sesión de apretón de manos de tres vías. Hay un proceso para iniciar una sesión y también hay un proceso para finalizar la sesión TCP. Este tema le ayuda a comprender el proceso implicado en el procesamiento de una sesión TCP.
Descripción de las comprobaciones de la sesión TCP por política
De forma predeterminada, las opciones Comprobación TCP SYN y comprobación de secuencia están habilitadas en todas las sesiones TCP. El sistema operativo de Junos (Junos OS) realiza las siguientes operaciones durante las sesiones TCP:
Comprueba si hay indicadores SYN en el primer paquete de una sesión y rechaza cualquier segmento TCP con indicadores que no sean SYN que intenten iniciar una sesión.
Valida los números de secuencia TCP durante la inspección de estado.
La función de comprobación de sesión TCP por política permite configurar comprobaciones SYN y de secuencia para cada política. Actualmente, las marcas de opciones TCP, no-sequence-check y no-syn-check, están disponibles a nivel global para controlar el comportamiento de las puertas de enlace de servicios. Para admitir opciones TCP por política, están disponibles las dos opciones siguientes:
sequence-check-required: el valor sequence-check-required anula el valor global no-sequence-check.
syn-check-required: El valor syn-check-required anula el valor global no-syn-check.
Para configurar las opciones TCP por política, debe desactivar las opciones globales respectivas; de lo contrario, se producirá un error en la comprobación de confirmación. Si las opciones TCP globales están deshabilitadas y la protección contra inundaciones SYN permite el primer paquete, las opciones TCP por política controlarán si se realizan comprobaciones SYN o secuencia.
La opción por política
syn-check-requiredno anulará el comportamiento del comando de laset security flow tcp-session no-syn-check-in-tunnelCLI.Deshabilitar la comprobación SYN global reduce la eficacia del dispositivo para defenderse de las inundaciones de paquetes.
Deshabilitar la comprobación SYN global y aplicar la comprobación SYN después de la búsqueda de políticas tendrá un gran impacto en la cantidad de paquetes que el enrutador puede procesar. Esto, a su vez, dará como resultado operaciones intensas de CPU. Cuando deshabilite la comprobación SYN global y habilite la aplicación de comprobación SYN por política, debe tener en cuenta este impacto en el rendimiento.
Deshabilitar comprobaciones de seguridad de paquetes TCP
En un firewall de la serie SRX, puede deshabilitar las comprobaciones de seguridad en paquetes TCP para garantizar la interoperabilidad con hosts y dispositivos con implementaciones TCP defectuosas.
La no-sequence-check opción deshabilita las comprobaciones de secuencia TCP. También aumenta la transferencia de datos.
El set security flow tcp-session no-sequence-check comando deshabilita las comprobaciones de secuencia TCP en todas las sesiones TCP en los modos predeterminados o basados en hash.
Ejemplo: Configuración de comprobaciones de seguridad de paquetes TCP por política
En este ejemplo, se muestra cómo configurar las comprobaciones de seguridad de paquetes TCP para cada política del dispositivo.
Requisitos
Antes de empezar, debe deshabilitar las opciones tcp-syn-checkTCP y tcp-sequence-check las que están configuradas a nivel global. .
Descripción general
Las opciones SYN y de comprobación de secuencia están activadas de forma predeterminada en todas las sesiones TCP. En entornos que necesitan admitir transferencias de archivos de gran tamaño o que ejecutan aplicaciones no estándar, puede ser necesario configurar las comprobaciones de secuencia y sincronización de forma diferente para cada directiva. En este ejemplo, se configura la secuencia y la sincronización de la política pol1.
Configuración
Procedimiento
Procedimiento paso a paso
Para configurar las comprobaciones de seguridad de paquetes TCP a nivel de directiva:
Configure la comprobación del bit TCP SYN antes de crear una sesión.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options syn-check-required
Configure la comprobación de números de secuencia en segmentos TCP durante la inspección de estado.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options sequence-check-required
Cuando termine de configurar el dispositivo, confirme la configuración.
[edit] user@host# commit
Verificación
Para comprobar que la configuración funciona correctamente, ingrese el show security policies detail comando.
Ejemplo: Deshabilitar comprobaciones de seguridad de paquetes TCP para puertas de enlace de servicios de la serie SRX
En este ejemplo, se muestra cómo deshabilitar las comprobaciones de seguridad de paquetes TCP en el dispositivo.
Requisitos
Antes de comenzar, comprenda las circunstancias para deshabilitar las comprobaciones de seguridad de paquetes TCP. .
Descripción general
Junos OS proporciona un mecanismo para deshabilitar las comprobaciones de seguridad en paquetes TCP a fin de garantizar la interoperabilidad con hosts y dispositivos con implementaciones TCP defectuosas. Durante la comprobación sin SYN, Junos OS no busca el paquete TCP SYN para la creación de la sesión. La comprobación sin secuencia deshabilita la validación de la comprobación de secuencia TCP. Además, aumenta la transferencia de datos. La verificación SYN y la verificación de secuencia están habilitadas de forma predeterminada. El comando set security flow deshabilita las comprobaciones TCP SYN y las comprobaciones de secuencia TCP en todas las sesiones TCP, por lo que reduce la seguridad. Esto puede ser necesario en escenarios con clientes como archivos de transferencia grandes o con aplicaciones que no funcionan correctamente con estándares.
Configuración
Procedimiento
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en el modo de configuración de la Guía del usuario de CLI.
Para deshabilitar las comprobaciones de seguridad de paquetes TCP:
Deshabilite la comprobación del bit TCP SYN antes de crear una sesión.
[edit security flow] user@host# set tcp-session no-syn-check
Deshabilite la comprobación de números de secuencia en segmentos TCP durante la inspección de estado.
[edit security flow] user@host# set tcp-session no-sequence-check
Cuando termine de configurar el dispositivo, confirme la configuración.
[edit ] user@host# commit
Verificación
Para comprobar que la configuración funciona correctamente, ingrese el show security flow comando.
Ejemplo: Establecer el tamaño máximo de segmento para todas las sesiones TCP para firewalls de la serie SRX
En este ejemplo, se muestra cómo establecer el tamaño máximo de segmento para todas las sesiones TCP para firewalls de la serie SRX.
Requisitos
Antes de comenzar, comprenda las circunstancias para establecer el tamaño máximo de segmento.
Descripción general
Puede finalizar todas las sesiones TCP cambiando el tamaño máximo de segmento TCP (TCP-MSS). Para disminuir la probabilidad de fragmentación y protegerse contra la pérdida de paquetes, puede usar tcp-mss para especificar un valor TCP MSS más bajo. Esto se aplica a todos los paquetes TCP SYN que atraviesan las interfaces de entrada del enrutador cuyo valor MSS es mayor que el que especifique.
Si se establece el bit DF, no fragmentará el paquete y Junos OS enviará el paquete de código 4 de error ICMP tipo 3 al servidor de aplicaciones (Destino inalcanzable; Fragmentación necesaria y DF establecido). Este mensaje de error ICMP contiene la UMT correcta (tal como se define en tcp-mss) que debe utilizar el servidor de aplicaciones, que debe recibir este mensaje y ajustar el tamaño del paquete en consecuencia. Esto es un requisito específico con VPN, ya que IPsec ha agregado sobrecarga de paquetes; Por lo tanto, el TCP-MSS debe reducirse adecuadamente.
Cuando se ejecutan firewalls de la serie SRX en modo de paquete, utilice el set system internet-options tcp-mss para ajustar el valor TCP-MSS. Todos los puertos se ven afectados por la configuración TCP-MSS; No se puede excluir un puerto en particular. Cuando ejecute firewalls de la serie SRX en modo de flujo, aunque puede usar la opción set system internet-options tcp-mss , le recomendamos que utilice solo la set security flow tcp-mss opción para ajustar el valor TCP-MSS. Si se configuran ambas instrucciones, surtirá efecto el menor de los dos valores.
Configuración
Procedimiento
Procedimiento paso a paso
Para configurar el tamaño máximo de segmento para todas las sesiones TCP:
Establezca el tamaño máximo de segmento TCP para todas las sesiones TCP.
[edit security flow] user@host# set tcp-mss all-tcp mss 1300
Cuando termine de configurar el dispositivo, confirme la configuración.
[edit ] user@host# commit
Resultados
Desde el modo de configuración, ingrese el comando para confirmar la show security flow configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración de este ejemplo para corregirla.
Para fines de brevedad, este show resultado de comando solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración en el sistema se reemplazó por puntos suspensivos (...).
[edit]
user@host# show security flow
...
tcp-mss{
all-tcp{
mss 1300;
}
}
...
Verificación
Para comprobar que la configuración funciona correctamente, ingrese el comando desde el show configuration security flow modo operativo.
user@host> show configuration security flow
tcp-mss{
all-tcp{
mss 1300;
}
}
Descripción general del registro de caída de paquetes fuera de estado de TCP
Dentro de cualquier red conmutada por paquetes, cuando la demanda excede la capacidad disponible, los paquetes se ponen en cola para contener los paquetes sobrantes hasta que la cola se llena y luego se descartan los paquetes. Cuando TCP opera en una red de este tipo, toma cualquier acción correctiva para mantener comunicaciones de extremo a extremo sin errores.
Los módulos de flujo ya admiten la generación de RTLOG para eventos basados en sesiones, como la creación y el cierre de sesiones. Los firewalls de la serie SRX ahora admiten la generación de RTLOG para eventos basados en paquetes, como la caída de paquetes sin que exista una sesión.
Los firewalls de la serie SRX admiten el registro de paquetes TCP no sincronizados fuera de estado que el módulo de flujo descarta.
La función de registro de caída de paquetes de TCP fuera de estado evita cualquier pérdida de paquetes y permite la recuperación de paquetes mediante el registro de los paquetes desincronizados para una comunicación sin errores, y evita que los servidores de bases de datos se desincronizen. Esta función se basa en la función de registro de seguridad (RTLOG).
El registro de caída de paquetes TCP fuera de estado admite la captura de registros de caída de paquetes TCP en las siguientes condiciones:
Session ages out—Cuando hay aplicaciones en la nube que se ejecutan sobre sesiones TCP largas y cuando estas aplicaciones no actualizan las sesiones TCP después de que la sesión expire, los paquetes TCP se descartan. Esta característica admite el registro de estos paquetes TCP interrumpidos.
Unsynchronized first packets due to attacks or asymmetric routes—Cuando se despliegan firewalls de serie SRX en dos sitios y cuando el enrutamiento a veces fuerza el tráfico asimétrico, el paquete de sincronización (SYN) se ve en un sitio, pero los paquetes de confirmación de sincronización (SYN_ACK) se ven en otro sitio.
Esto significa que el firewall de la serie SRX ve un paquete ACK TCP para el que no tiene una entrada de tabla de estado coincidente. Esto puede ocurrir porque la conexión estuvo inactiva durante un período de tiempo o porque las tablas de conexiones se vaciaron (por ejemplo, debido a la instalación o reinicio de una directiva).
Los paquetes SYN_ACK que se ven en otro sitio en este caso fueron denegados por el firewall de serie SRX, pero no se registraron. Esta característica admite el registro de los paquetes de SYN_ACK denegados.
Other out-of-state conditions (like TCP sequence check fail and synchronization packet received in FIN state)—Cuando un firewall de la serie SRX detecta un fallo de secuencia, si el dispositivo está en estado de cierre de cuatro vías TCP pero recibe paquetes SYN, o si hay un fallo de apretón de manos de tres vías, el firewall de la serie SRX descarta los paquetes TCP y se registran dichos paquetes perdidos.
El registro de caída de paquetes sin estado de TCP no sincronizado es un registro basado en paquetes, no un registro basado en sesión.
El registro de caída de paquetes fuera de estado de TCP está diseñado con un mecanismo de limitación para proteger la CPU de ataques y, dentro de cada intervalo de aceleración, se pueden eliminar algunos registros.
Solo se registran los paquetes TCP fuera de estado caídos por el módulo Flow. Los paquetes TCP caídos por TCP-proxy e DPI no se registran.
- Descripción del registro de caída de paquetes fuera de estado de TCP
- Funciones compatibles de registro TCP fuera del estado
Descripción del registro de caída de paquetes fuera de estado de TCP
Para comprender la implementación del registro de caída de paquetes sin estado de TCP, tenga en cuenta que implementa firewalls serie SRX en dos sitios y que el enrutamiento a veces fuerza el tráfico asimétrico, donde el paquete SYN se ve en un sitio, pero el paquete SYN_ACK se ve en otro sitio. En este caso, el paquete SYN_ACK se denegaría, pero no se registraría. La función de registro de caídas de paquetes fuera de estado de TCP proporciona visibilidad de estas caídas de paquetes no sincronizadas.
Considere el escenario en el que las bases de datos dentro del centro de datos mantienen sus sockets TCP abiertos, sin que se envíen señales de mantenimiento. Si no se transmite ningún dato, el firewall de la serie SRX agotará el tiempo de espera de las sesiones. Aunque las bases de datos enviarán algunos datos a través de ese socket TCP, cuando el tráfico llega al firewall de la serie SRX, la sesión ya no está allí y el paquete se descarta, pero no se registra. El firewall de la serie SRX registra estos paquetes TCP fuera de estado que se descartan.
Funciones compatibles de registro TCP fuera del estado
El registro TCP fuera de estado admite las siguientes características:
Un componente de filtro de paquetes para filtrar el tráfico de destino.
Componente de aceleración para evitar que la CPU se sobrecargue con mensajes de registro.
Flexibilidad para cambiar la velocidad de generación de registros.
- Componente de filtro de paquetes
- Componente del acelerador
- Flexibilidad para cambiar la velocidad de generación de registros
Componente de filtro de paquetes
El filtro de registro aprovecha el filtro de seguimiento de flujo actual. Proporciona diferentes formas de filtrar el tráfico. Debe configurar los filtros para generar registros de paquetes; de lo contrario, no se activarán los registros.
Esta funcionalidad de filtro evita habilitar registros de forma inesperada. El máximo de filtros admitidos es 64.
Use el set security flow packet-log packet-filter <filter-name> comando para habilitar los componentes de filtro relacionados que desee.
Componente del acelerador
El registro de cada paquete TCP fuera de estado puede sobrecargar el dispositivo cuando el tráfico es intenso o cuando se produce un ataque. Si la CPU está inactiva y desea registrar tantos mensajes como sea posible, esto podría provocar una sobrecarga de la CPU.
El mecanismo de limitación le permite configurar el intervalo de limitación desde la CLI, para que pueda proteger su CPU de sobrecargas.
Se introduce una tabla hash para mapear los datos registrados. La clave hash se genera con la dirección IP de origen, la dirección IP de destino, el puerto de origen y el puerto de destino.
Dentro de cada intervalo de aceleración, solo se enviará un número limitado (más de uno) de mensajes a RTLOG. Los mensajes de registro restantes se limitarán.
El intervalo de aceleración predeterminado es de 1 segundo. El intervalo de aceleración (a nivel de milisegundos) debe configurarse como una potencia de dos o cero (0, 1, 2, 4, 8, 16 ... 2^N).
Cuando el intervalo de aceleración se configura como 0, no se involucrará ningún mecanismo de aceleración. Esto es adecuado para situaciones en las que el tráfico es muy ligero y desea registrar todos los registros de pérdida de paquetes.
La configuración del intervalo de aceleración como 2^N hace que el mecanismo de aceleración no tenga bloqueo y proporciona un buen rendimiento de captura de registros.
Flexibilidad para cambiar la velocidad de generación de registros
Según el intervalo de aceleración establecido, la velocidad de generación de registros se puede modificar y administrar.
Esto significa que dentro de cada intervalo de 32 milisegundos (ms), se podría generar un número limitado de registros y el resto podría eliminarse. Le recomendamos que configure el intervalo como (0, 1, 2, 4, 8, 16, 32 ... 2^N).
Si el valor de entrada no está alineado con 2^N, se alineará con 2^N automáticamente durante el procesamiento del flujo. Por ejemplo, si configura un intervalo de 10 ms, se alineará automáticamente con un intervalo de 8 ms.
Comprender cómo la conservación de las características de fragmentación entrante puede mejorar el rendimiento
En este tema se tratan los beneficios de usar el firewall de la serie SRX para conservar las características de los fragmentos de paquete entrantes.
Cuando se envían datos de un host a otro, se transmiten como una serie de paquetes. El rendimiento mejora y los recursos de red se conservan cuando los paquetes del tamaño más grande pueden transitar por la ruta desde el nodo de origen al nodo de destino sin fragmentarse en ningún vínculo de la ruta de datos. Cuando un paquete debe fragmentarse en paquetes más pequeños para transitar por un vínculo en la ruta porque el paquete es más grande que la de la unidad máxima de transmisión (UMT) establecida para ese vínculo, cada uno de los fragmentos resultantes debe contener información del encabezado del paquete, además de la carga o los datos. El aumento de la sobrecarga puede reducir la transferencia de datos y degradar el rendimiento de la red. Además, los fragmentos de paquete se deben volver a ensamblar en el nodo de destino, lo que consume recursos de red adicionales.
Por otro lado, los recursos de red se desperdician cuando un host envía paquetes que son mucho más pequeños que la ruta UMT (unidad máxima de transmisión de ruta), lo que da como resultado una transferencia de datos subóptima. El proceso de detección de UMT de ruta funciona para detectar el tamaño óptimo de UMT para los fragmentos que transitan por la ruta de datos desde el nodo de origen al nodo de destino para una sesión. El tamaño óptimo del paquete, entonces, es el de la ruta UMT. La fragmentación se produce cuando el tamaño de un paquete supera la ruta de acceso UMT.
Si los servicios de capa de aplicación están configurados en el firewall de la serie SRX, los fragmentos de paquete en la interfaz de entrada deben volver a ensamblarse antes de que se puedan aplicar los servicios e inspeccionar el contenido. Estos fragmentos de paquete reensamblados se deben descomponer de nuevo antes de que los datos se transmitan fuera de la interfaz de salida. Normalmente, es el tamaño de la UMT de la interfaz de salida el que determina el tamaño de los fragmentos transmitidos desde el firewall de la serie SRX al siguiente vínculo. Podría darse el caso de que el tamaño del UMT de salida en el firewall de serie SRX sea mayor que el UMT de ruta, lo que, de nuevo, daría como resultado la fragmentación de paquetes en la ruta de datos, lo que reduciría el rendimiento o provocaría una caída de paquetes. Los fragmentos de paquete deben ser lo suficientemente pequeños como para transitar por todos los vínculos de la ruta desde el origen hasta el destino.
De forma predeterminada, el firewall de la serie SRX utiliza el tamaño de UMT configurado para la interfaz de salida a fin de determinar el tamaño de los fragmentos de paquete que transmite. Sin embargo, si habilita la función para conservar las características de los fragmentos entrantes, el firewall de la serie SRX detectará y guardará el tamaño de los fragmentos de paquetes entrantes.
Para disminuir la probabilidad de fragmentación de paquetes en la ruta de datos, el firewall de la serie SRX realiza un seguimiento y ajusta la UMT de salida para ese flujo. Identifica el tamaño máximo de todos los fragmentos entrantes. Usa esa información junto con la UMT existente de la interfaz de salida para determinar el tamaño de UMT correcto para los paquetes fragmentados enviados fuera de la interfaz de salida. El firewall de la serie SRX compara los dos números. Toma el número más pequeño y lo utiliza para el tamaño de UMT de la interfaz de salida.
Configure el dispositivo mediante el set security flow preserve-incoming-frag-size comando para habilitar la función que tiene en cuenta el tamaño de los fragmentos de paquetes entrantes.
En la Tabla 1 se resume cómo se determina el tamaño del UMT de salida serie SRX.
Tamaño del fragmento entrante |
Tamaño de UMT de salida existente |
Tamaño de la UMT de salida final |
|---|---|---|
Si el fragmento más grande es |
más pequeño que el tamaño del UMT de salida existente |
se utiliza el tamaño de fragmento entrante más grande. |
Si el fragmento más grande es |
más grande que el tamaño del UMT de salida existente |
Se utiliza la UMT de interfaz de salida existente. |
Esta función se admite en los firewalls de la serie SRX. Es compatible con el tráfico de paso y el tráfico que sale de un túnel. Se aplica tanto al tráfico IPv4 como al IPv6.
Las siguientes dos consideraciones afectan al tamaño del fragmento:
Para aplicaciones basadas en secuencias, como Content Seguridad y ALG, las propias aplicaciones podían cambiar o volver a ensamblar paquetes incluso si no se recibían fragmentos. En este caso, se utiliza la interfaz de salida UMT existente.
Cuando se entrega un paquete de detección de UMT de ruta a una sesión, la UMT de ruta para esa sesión se restablece al valor establecido por el paquete de UMT de ruta.
Cortocircuito del proxy TCP
El cortocircuito de proxy TCP está habilitado de forma predeterminada en su dispositivo. Se activa automáticamente cuando no hay usuarios (complementos de aplicación de políticas L7/servicios de aplicaciones avanzadas) interesados en utilizar el proxy TCP para la sesión. Después de establecer correctamente la sesión TCP y la aplicación de políticas, el dispositivo pasa a un estado de cortocircuito de la sesión, lo que permite que los paquetes de datos posteriores fluyan directamente entre el cliente y el servidor.
Durante la fase inicial del apretón de manos, el dispositivo mantiene un comportamiento de proxy TCP completo, administrando de forma independiente el estado TCP, los números de secuencia y las confirmaciones para ambos lados de la conexión. Una vez que se verifica que la sesión es legítima y estable, el dispositivo ya no envía números de secuencia ni retransmisiones para el tráfico de datos. En su lugar, reenvía paquetes directamente mientras continúa monitoreando la sesión para detectar violaciones de seguridad y cumplimiento de políticas.
El cortocircuito de proxy TCP es adecuado para despliegues que requieren una seguridad y validación TCP sólidas sin la sobrecarga de rendimiento a largo plazo del proxy TCP completo. Es particularmente eficaz en entornos de alta transferencia de datos, como centros de datos, bordes de proveedores de servicios y grandes redes empresariales.
Beneficios del cortocircuito del proxy TCP
-
Seguridad y rendimiento equilibrados
-
Reducción de la sobrecarga de procesamiento y de la latencia del tráfico de datos.
-
Se preservó la aplicación de políticas al mantener verificaciones de políticas de seguridad, seguimiento de sesiones y monitoreo incluso después de cortocircuitar la conexión.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.
set security flow preserve-incoming-frag-size comando para habilitar la función que tiene en cuenta el tamaño de los fragmentos de paquetes entrantes.