Sesiones TCP
Para enviar datos a través de TCP en una red, se sigue un proceso de establecimiento de sesión de protocolo de enlace de tres vías. Hay un proceso para iniciar una sesión y también hay un proceso para terminar 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 sesión TCP por directiva
De forma predeterminada, las opciones de comprobación TCP SYN y 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 indicadores SYN en el primer paquete de una sesión y rechaza cualquier segmento TCP con indicadores no SYN que intente iniciar una sesión.
Valida los números de secuencia TCP durante la inspección de estado.
La característica de comprobación de sesión TCP por directiva permite configurar comprobaciones SYN y de secuencia para cada directiva. 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 de TCP por directiva, 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 directiva, debe desactivar las opciones globales respectivas; de lo contrario, se producirá un error en la comprobación de confirmación. Si las opciones globales de TCP están deshabilitadas y la protección contra inundaciones de SYN permite el primer paquete, las opciones de TCP por política controlarán si se realizan comprobaciones de SYN o secuencia.
La opción por política
syn-check-requiredno invalidará el comportamiento del comando de laset security flow tcp-session no-syn-check-in-tunnelCLI.La desactivación de la comprobación SYN global reduce la eficacia del dispositivo en la defensa contra la inundación de paquetes.
Deshabilitar la comprobación SYN global y aplicar la comprobación SYN después de la búsqueda de directivas tendrá un gran impacto en el número 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 la comprobación SYN por directiva, 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 el rendimiento.
El set security flow tcp-session no-sequence-check comando deshabilita las comprobaciones de secuencia TCP en todas las sesiones TCP en los modos predeterminado o basado en hash.
Ejemplo: configuración de comprobaciones de seguridad de paquetes TCP por directiva
En este ejemplo se muestra cómo configurar comprobaciones de seguridad de paquetes TCP para cada directiva del dispositivo.
Requisitos
Antes de comenzar, debe deshabilitar las opciones de tcp, tcp-syn-checky tcp-sequence-check que están configuradas a nivel global. .
Visión general
Las opciones SYN y comprobación de 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, 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 comprobación de directiva pol1.
Configuración
Procedimiento
Procedimiento paso a paso
Para configurar comprobaciones de seguridad de paquetes TCP en el 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
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 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. .
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 la sesión. La comprobación sin secuencia deshabilita la validación de comprobación de secuencia TCP. Además, aumenta el rendimiento. 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 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 es necesario navegar 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
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 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 del segmento.
Visión general
Puede terminar 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 utilizar tcp-mss para especificar un valor de MSS TCP inferior. 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 paquete de código 4 de tipo 3 de error ICMP al servidor de aplicaciones (Destination Unreachable; Fragmentación necesaria y conjunto DF). Este mensaje de error ICMP contiene la MTU correcta (como se define en tcp-mss) para ser utilizada por el servidor de aplicaciones, que debe recibir este mensaje y ajustar el tamaño del paquete en consecuencia. Esto se requiere específicamente con las VPN, ya que IPsec ha agregado sobrecarga de paquetes; Por lo tanto, TCP-MSS debe reducirse adecuadamente.
Cuando se ejecutan firewalls de la serie SRX en modo de paquete, se utiliza 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 ejecute firewalls de la serie SRX en modo flujo, aunque puede usar el set system internet-options tcp-mss , se recomienda usar solo el set security flow tcp-mss para ajustar el valor TCP-MSS. Si se configuran ambas instrucciones, el menor de los dos valores surtirá efecto.
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
Si ha terminado de configurar el dispositivo, confirme la configuración.
[edit ] user@host# commit
Resultados
Desde el modo de configuración, confirme la configuración introduciendo el show security flow comando. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
Para abreviar, este show resultado del comando solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración en el sistema ha sido reemplazada 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, introduzca 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 entrega de paquetes fuera de estado TCP
Dentro de cualquier red conmutada por paquetes, cuando la demanda excede la capacidad disponible, los paquetes se ponen en cola para mantener el exceso de paquetes hasta que la cola se llene y, a continuación, los paquetes se descartan. Cuando TCP opera en una red de este tipo, toma las medidas correctivas 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 fuera de estado no sincronizados que el módulo de flujo deja caer.
La característica TCP de registro de entrega de paquetes fuera de estado evita cualquier pérdida de paquetes y permite la recuperación de paquetes al registrar los paquetes fuera de sincronización para una comunicación sin errores, y evita que los servidores de bases de datos no estén sincronizados. Esta característica se basa en la función de registro de seguridad (RTLOG).
El registro de entrega de paquetes TCP fuera del estado admite la captura de registros de entrega de paquetes TCP en las siguientes condiciones:
Session ages out: cuando hay aplicaciones en la nube ejecutándose sobre sesiones TCP largas, y cuando estas aplicaciones no actualizan las sesiones TCP después de que la sesión expira, los paquetes TCP se eliminan. Esta característica admite el registro de estos paquetes TCP descartados.
Unsynchronized first packets due to attacks or asymmetric routes—Cuando se despliegan firewalls de la 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 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 directiva).
Los paquetes SYN_ACK que se ven en otro sitio en este caso fueron denegados por el firewall de la serie SRX, pero no se registraron. Esta característica admite el registro de los paquetes 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 error de secuencia, si el dispositivo está en un estado de cierre cuatridireccional TCP pero recibe paquetes SYN, o si hay un error de protocolo de enlace de tres vías, el firewall de la serie SRX descarta los paquetes TCP y estos paquetes perdidos se registran.
El registro de entrega 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 del estado está diseñado con un mecanismo de aceleración para proteger la CPU de ser atacada, y dentro de cada intervalo de aceleración se pueden eliminar algunos registros.
Solo se registran los paquetes TCP fuera de estado descartados por el módulo Flow. Los paquetes TCP descartados por TCP-proxy e IDP no se registran.
- Descripción del registro de entrega de paquetes TCP fuera del estado
- Características de registro TCP fuera de estado compatibles
Descripción del registro de entrega de paquetes TCP fuera del estado
Para comprender la implementación del registro de caída de paquetes TCP fuera del estado, tenga en cuenta que implementa firewalls de la 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. El paquete SYN_ACK en este caso sería denegado, pero no registrado. La característica de registro de entrega 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 keepalives. 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.
Características de registro TCP fuera de estado compatibles
El registro TCP fuera del estado admite las siguientes características:
Un componente de filtro de paquetes para filtrar el tráfico de destino.
Un componente del acelerador para proteger la CPU de ser sobrecargada por mensajes de registro.
Flexibilidad para cambiar la tasa de generación de registros.
- Componente de filtro de paquetes
- Componente del 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. 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 inesperadamente. El máximo de filtros admitidos es 64.
Utilice 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 del 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 del acelerador le permite configurar el intervalo del acelerador desde la CLI, para que pueda proteger su CPU de una 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 del acelerador, 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 predeterminado del acelerador es de 1 segundo. El intervalo del acelerador (a nivel de milisegundos) debe configurarse como una potencia de dos o cero (0, 1, 2, 4, 8, 16 ... 2^N).
Cuando el intervalo del acelerador se configura como 0, no intervendrá ningún mecanismo del acelerador. Esto es adecuado para escenarios en los que el tráfico es muy ligero y desea registrar todos los registros de entrega de paquetes.
La configuración del intervalo del acelerador como 2^N hace que el mecanismo del acelerador no se bloquee y proporciona un buen rendimiento de captura de registros.
Flexibilidad para cambiar la tasa de generación de registros
Según el intervalo de aceleración establecido, la tasa 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 las ventajas de usar el firewall de la 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. Se mejora el rendimiento y los recursos de red se conservan cuando los paquetes de 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 debe fragmentarse en paquetes más pequeños para transitar un vínculo en la ruta de acceso porque el paquete es mayor que el de la unidad máxima de transmisión (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 útil o los datos. El aumento de la sobrecarga puede disminuir el rendimiento y degradar el rendimiento de la red. Además, los fragmentos de paquetes 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 MTU (unidad de transmisión máxima de ruta), lo que resulta en un rendimiento subóptimo. El proceso de descubrimiento de MTU de ruta de acceso funciona para detectar el tamaño óptimo de 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 ruta MTU. La fragmentación se produce cuando el tamaño de un paquete supera la ruta MTU.
Si los servicios de la capa de aplicación están configurados en el firewall de la serie SRX, los fragmentos de paquetes en la interfaz de entrada deben volver a ensamblarse antes de poder aplicar los servicios e inspeccionar el contenido. 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 MTU de la interfaz de salida el que determina el tamaño de los fragmentos transmitidos por el firewall de la serie SRX al siguiente vínculo. Podría darse el caso de que el tamaño de MTU de salida en el firewall de la serie SRX sea mayor que la MTU de la 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 la caída de paquetes. Los fragmentos de paquetes deben ser lo suficientemente pequeños como para transitar por todos los eslabones de la ruta desde el origen hasta el destino.
De forma predeterminada, el firewall de la serie SRX utiliza el tamaño de MTU configurado para la interfaz de salida para determinar el tamaño de los fragmentos de paquetes que transmite. Sin embargo, si habilita la característica para conservar las características de los fragmentos entrantes, el firewall de la serie SRX detecta y guarda 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 MTU de salida para ese flujo. Identifica el tamaño máximo de todos los fragmentos entrantes. Utiliza esa información junto con la MTU existente de la interfaz de salida para determinar el tamaño correcto de MTU para los paquetes fragmentados enviados a 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 usa para el tamaño de MTU de la interfaz de salida.
Configure el dispositivo mediante el set security flow preserve-incoming-frag-size comando para habilitar la característica que tiene en cuenta el tamaño de los fragmentos de paquetes entrantes.
La Tabla 1 resume cómo se determina el tamaño de MTU de salida de la serie SRX.
Tamaño del fragmento entrante |
Tamaño de MTU de salida existente |
Tamaño de MTU de salida final |
|---|---|---|
Si el fragmento más grande es |
menor que el tamaño de MTU de salida existente |
Se utiliza el mayor tamaño de fragmento entrante. |
Si el fragmento más grande es |
mayor que el tamaño de MTU de salida existente |
se utiliza MTU de interfaz de salida existente. |
Esta función es compatible con 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 dos consideraciones siguientes afectan al tamaño del fragmento:
Para las aplicaciones basadas en secuencias, como Content Security 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 MTU de interfaz de salida existente.
Cuando un paquete de descubrimiento de MTU de ruta se entrega a una sesión, la ruta de MTU para esa sesión se restablece al valor establecido por el paquete de MTU de ruta.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. 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 característica que tiene en cuenta el tamaño de los fragmentos de paquetes entrantes.