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 que implica procesar una sesión TCP.
Descripción de las comprobaciones de sesión TCP por política
De forma predeterminada, las opciones de comprobación TCP SYN y la comprobación de secuencia están habilitadas en todas las sesiones TCP. El sistema operativo Junos (Junos OS) realiza las siguientes operaciones durante las sesiones TCP:
Comprueba si hay marcas SYN en el primer paquete de una sesión y rechaza cualquier segmento TCP con marcas que no son 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 le permite configurar SYN y pruebas de secuencia para cada política. Actualmente, los indicadores 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 las opciones TCP por política, están disponibles las dos opciones siguientes:
sequence-check-required: el valor sequence-check-required reemplaza el valor global no-sequence-check.
syn-check-required: el valor syn-check-required reemplaza 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 de TCP globales están deshabilitadas y la protección contra inundación SYN permite el primer paquete, las opciones TCP por política controlarán si se realizan comprobaciones de SYN o de secuencia.
La opción por política
syn-check-requiredno invalidará el comportamiento del comando de cliset security flow tcp-session no-syn-check-in-tunnel.Deshabilitar la comprobación global SYN reduce la eficacia del dispositivo en la defensa contra la inundación de paquetes.
Deshabilitar la comprobación GLOBAL SYN y hacer cumplir la comprobación SYN después de la búsqueda de políticas afectará en gran medida la cantidad de paquetes que el enrutador puede procesar. Esto, a su vez, dará lugar a operaciones de CPU intensas. Cuando desactive la comprobación global syn y habilite la aplicación de la comprobación SYN por política, debe tener en cuenta este impacto en el rendimiento.
Deshabilitar las comprobaciones de seguridad de paquetes TCP
En un dispositivo 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 modo predeterminado o basado en hash.
Ejemplo: Configurar 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 comenzar, debe deshabilitar las opciones tcp, tcp-syn-checky tcp-sequence-check que están configuradas a nivel global. .
Visión general
Las opciones de comprobación syn y secuencia están habilitadas 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, es posible que sea necesario configurar la secuencia y sincronizar las comprobaciones de manera diferente para cada política. En este ejemplo, se configura la comprobación de secuencia y sincronización para la política pol1.
Configuración
Procedimiento
Procedimiento paso a paso
Para configurar las comprobaciones de seguridad de paquetes TCP a nivel de política:
Configure la comprobación para el 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
Si ha terminado de configurar el dispositivo, confirme la configuración.
[edit] user@host# commit
Verificación
Para comprobar que la configuración funciona correctamente, escriba el show security policies detail comando.
Ejemplo: Deshabilitar las comprobaciones de seguridad de paquetes TCP para puertas de enlace de servicios 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. .
Visión general
Junos OS proporciona un mecanismo para deshabilitar las comprobaciones de seguridad en paquetes TCP para 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 sesión. La comprobación sin secuencia deshabilita la validación de comprobación de secuencia TCP. Además, aumenta la transferencia de datos. La comprobación SYN y la comprobació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 tanto, reduce la seguridad. Esto puede ser necesario en situaciones con clientes como grandes archivos de transferencia o con aplicaciones que no funcionan correctamente con los estándares.
Configuración
Procedimiento
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
Para deshabilitar las comprobaciones de seguridad de paquetes TCP:
Desactive la comprobación del bit TCP SYN antes de crear una sesión.
[edit security flow] user@host# set tcp-session no-syn-check
Desactive 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
Si ha terminado de configurar el dispositivo, confirme la configuración.
[edit ] user@host# commit
Verificación
Para comprobar que la configuración funciona correctamente, escriba el show security flow comando.
Ejemplo: Establecer el tamaño máximo de segmento para todas las sesiones TCP para puertas de enlace de servicios serie SRX
En este ejemplo, se muestra cómo establecer el tamaño máximo de segmento para todas las sesiones TCP para dispositivos serie SRX.
Requisitos
Antes de comenzar, comprenda las circunstancias para establecer el tamaño máximo del segmento.
Visión general
Puede terminar todas las sesiones TCP cambiando el tamaño máximo del segmento TCP (TCP-MSS). Para reducir la probabilidad de fragmentación y proteger 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 especificado.
Si se establece el bit DF, no fragmentará el paquete y Junos OS enviará el error ICMP tipo 3 código 4 paquete al servidor de la aplicación (Destino inalcanzable; Fragmentación necesaria y conjunto de DF). Este mensaje de error ICMP contiene la MTU correcta (definida en tcp-mss) que va a utilizar el servidor de aplicaciones, el cual debería recibir este mensaje y ajustar el tamaño del paquete en consecuencia. Esto se requiere específicamente con VPN, ya que IPsec agregó sobrecarga de paquetes; por lo tanto, se debe reducir tcp-mss de manera adecuada.
Al ejecutar dispositivos 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 puede excluir un puerto en particular. Cuando se ejecutan dispositivos de la serie SRX en modo de flujo, aunque puede usar el set system internet-options tcp-mss , recomendamos usar solo el set security flow tcp-mss para ajustar el valor TCP-MSS. Si se configuran ambas instrucciones, la parte inferior de los dos valores tendrá efecto.
Configuración
Procedimiento
Procedimiento paso a paso
Para configurar el tamaño máximo del 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
Si ha terminado 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 en este ejemplo para corregirla.
Para mayor brevedad, el resultado de este show comando solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración del sistema se ha reemplazado 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 de registro de caída de paquetes tcp fuera de estado
En cualquier red conmutada de paquetes, cuando la demanda supera la capacidad disponible, se hacen colas para contener el exceso de paquetes hasta que la cola se llena y, luego, se pierden 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 sesión, como la creación de sesiones y el cierre de sesión. Los dispositivos de la serie SRX ahora admiten la generación de RTLOG para eventos basados en paquetes, como la caída de paquetes sin una sesión existente.
Los dispositivos de la serie SRX admiten el registro de paquetes TCP no sincronizados fuera de estado que el módulo de flujo deja caer.
La función de registro de caída de paquetes fuera de estado TCP evita cualquier pérdida de paquetes y permite la recuperación de paquetes mediante la sesión de los paquetes fuera de sincronización para una comunicación sin errores, e impide que los servidores de base de datos se desincronicen. Esta función se basa en las instalaciones del registro de seguridad (RTLOG).
El registro de caída de paquetes fuera de estado TCP admite la captura de registros de caída de paquetes TCP bajo 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 se agote, los paquetes TCP se pierden. Esta función admite el registro de estos paquetes TCP caídos.
Unsynchronized first packets due to attacks or asymmetric routes— Cuando implementa dispositivos de la serie SRX en dos sitios, y cuando el enrutamiento a veces fuerza 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 dispositivo serie SRX ve un paquete TCP ACK para el cual 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 el reinicio de una política).
Los SYN_ACK paquetes que se ven en otro sitio, en este caso, fueron denegados por el dispositivo serie SRX, pero no se registraron. Esta función 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 dispositivo serie SRX detecta un error de secuencia, si el dispositivo está en estado de cierre de cuatro vías TCP pero recibe paquetes SYN, o si hay un error de apretón de manos de tres vías, el dispositivo serie SRX deja caer los paquetes TCP y estos paquetes caídos se registran.
El registro de caída de paquetes TCP fuera de estado no sincronizado es un registro basado en paquetes, no un registro basado en sesión.
El registro de caída de paquetes tcp fuera de estado está diseñado con un mecanismo de aceleración para proteger a la CPU de ataques, y dentro de cada intervalo de aceleración se pueden caer algunos registros.
Solo se registran los paquetes TCP fuera de estado caídos por el módulo de flujo. Los paquetes TCP caídos por TCP-proxy e IDP no se registran.
- Descripción del registro de caída de paquetes fuera de estado TCP
- Funciones de registro fuera de estado tcp compatibles
Descripción del registro de caída de paquetes fuera de estado TCP
Para comprender la implementación del registro de caída de paquetes TCP fuera de estado, tenga en cuenta que implementa dispositivos serie SRX en dos sitios y que el enrutamiento a veces fuerza tráfico asimétrico, en el que 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ída de paquetes TCP fuera de estado proporciona visibilidad de estas caídas de paquetes no sincronizadas.
Considere la situación en la que las bases de datos del centro de datos mantienen sus sockets TCP abiertos, sin que se envíen elementos de seguimiento. Si no se transmite ningún dato, el dispositivo serie SRX tendrá 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 dispositivo de la serie SRX, la sesión ya no está allí y el paquete se cae, pero no se registra. Estos paquetes TCP fuera de estado que se pierden ahora se registran en el dispositivo serie SRX.
Funciones de registro fuera de estado tcp compatibles
El registro fuera de estado TCP admite las siguientes funciones:
Un componente de filtro de paquetes para filtrar el tráfico de destino.
Un componente de aceleración para proteger la CPU de la sobrecarga de mensajes de registro.
Flexibilidad para cambiar la velocidad de generación de registros.
- Componente de filtro de paquetes
- Componente de acelerador
- Flexibilidad para cambiar la tasa de generación de registros
Componente de filtro de paquetes
El filtro de registro aprovecha el filtro de seguimiento de flujo actual. Ofrece diferentes formas de filtrar el tráfico. Debe configurar los filtros para generar registros de paquetes, de lo contrario, los registros no se activarán.
Esta funcionalidad de filtro evita habilitar registros de forma inesperada. Los filtros máximos admitidos son 64.
Utilice el set security flow packet-log packet-filter <filter-name> comando para habilitar los componentes de filtro relacionados que desee.
Componente de acelerador
Registrar cada paquete TCP fuera de estado puede sobrecargar el dispositivo cuando el tráfico es pesado o cuando se produce un ataque. Si la CPU está inactiva y desea registrar tantos mensajes como sea posible, esto podría dar lugar a una sobrecarga de CPU.
El mecanismo de aceleración le permite configurar el intervalo de aceleración desde la CLI, para que pueda proteger su CPU de la sobrecarga.
Se introduce una tabla hash para asignar 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. El resto de los mensajes de registro se limitarán.
El intervalo de aceleración predeterminado es de 1 segundo. El intervalo de aceleración (a nivel de milisegundo) 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 intervendrá 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 caída de paquetes.
La configuración del intervalo de aceleración como 2^N hace que el mecanismo de aceleración no se bloquee y proporciona un buen rendimiento de captura de registro.
Flexibilidad para cambiar la tasa de generación de registros
Según el conjunto de intervalos de aceleración, 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 se podrían eliminar los restantes. 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á a 2^N automáticamente durante el procesamiento del flujo. Por ejemplo, si configura un intervalo de 10 ms, se alineará a un intervalo de 8 ms automáticamente.
Comprender cómo conservar las características de fragmentación entrantes puede mejorar la transferencia de datos
En este tema, se tratan las ventajas de usar el dispositivo serie SRX para conservar las características de los fragmentos de paquetes entrantes.
Cuando los datos se envían 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 mayor tamaño pueden transitar 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 se debe fragmentar en paquetes más pequeños para transitar un vínculo en la ruta porque el paquete es mayor que el de la unidad de transmisión máxima (MTU) 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 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 mucho más pequeños que la MTU (unidad de transmisión máxima de ruta de ruta), lo que da como resultado una transferencia de datos insuficiente. El proceso de descubrimiento de MTU de ruta funciona para descubrir el tamaño óptimo de la MTU para los fragmentos que transitan 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 MTU de ruta. La fragmentación se produce cuando el tamaño de un paquete supera la MTU de ruta.
Si los servicios de capa de aplicación se configuran en el dispositivo de la serie SRX, los fragmentos de paquetes en la interfaz de entrada se deben volver a ensamblar antes de que los servicios se puedan aplicar y el contenido se inspeccione. Estos fragmentos de paquetes reensamblados deben descomponerse de nuevo antes de que los datos se transmitan fuera de la interfaz de salida. Normalmente, es el tamaño de la MTU de la interfaz de salida el que determina el tamaño de los fragmentos transmitidos desde el dispositivo serie SRX al siguiente vínculo. Podría ser el caso de que el tamaño de la MTU de salida en el dispositivo de la serie SRX sea mayor que la MTU de ruta, lo que, de nuevo, resultaría en la fragmentación del paquete en la ruta de datos, lo que reduciría el rendimiento o causaría la caída de paquetes. Los fragmentos de paquete deben ser lo suficientemente pequeños como para transitar cada vínculo de la ruta desde el origen hasta el destino.
De forma predeterminada, el dispositivo de la serie SRX usa el tamaño de MTU configurado para la interfaz de salida para 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 dispositivo serie SRX detecta y guarda el tamaño de los fragmentos de paquete entrantes.
Para disminuir la probabilidad de fragmentación de paquetes en la ruta de datos, el dispositivo serie SRX realiza un seguimiento y ajusta la MTU de salida para ese flujo. Identifica el tamaño máximo de todos los fragmentos entrantes. Usa esa información junto con la MTU existente de la interfaz de salida para determinar el tamaño de MTU correcto para los paquetes fragmentados enviados a la interfaz de salida. El dispositivo serie SRX compara los dos números. Toma el número más pequeño y lo usa para el tamaño de la interfaz de salida de la MTU.
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 paquete entrantes.
En la tabla 1 se resume cómo se determina el tamaño de la MTU de salida de la serie SRX.
Tamaño del fragmento entrante |
Tamaño de MTU de salida existente |
Tamaño de la MTU de salida final |
|---|---|---|
Si el fragmento más grande es |
más pequeño que el tamaño de MTU 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 de MTU de salida existente |
se utiliza la MTU de interfaz de salida existente. |
Esta función se admite en dispositivos de la serie SRX. Es compatible con el tráfico a través y el tráfico que sale de un túnel. Se aplica tanto al tráfico IPv4 como al de IPv6.
Las dos siguientes consideraciones afectan al tamaño de los fragmentos:
En el caso de las aplicaciones basadas en secuencias, como UTM y ALG, las propias aplicaciones podrían cambiar o volver a ensamblar paquetes, incluso si no se recibieron fragmentos. En este caso, se utiliza la MTU de interfaz de salida existente.
Cuando se entrega un paquete de descubrimiento de MTU de ruta a una sesión, la MTU de ruta de esa sesión se restablece al valor establecido por el paquete de MTU de ruta.
set security flow preserve-incoming-frag-size comando para habilitar la función que tiene en cuenta el tamaño de los fragmentos de paquete entrantes.