TCP
Muchas aplicaciones y servicios usan TCP para comunicarse. Configure las opciones de TCP para mejorar la calidad y la seguridad del vínculo.
Seguridad para encabezados TCP con conjunto de indicadores SYN y FIN
De forma predeterminada, el dispositivo acepta paquetes que tienen los bits SYN y FIN establecidos en la marca TCP. Configure su dispositivo para que suelte paquetes con los bits SYN y FIN configurados para reducir las vulnerabilidades de seguridad.
Normalmente, los indicadores de control SYN y FIN no se establecen en el mismo encabezado del segmento TCP. La marca SYN sincroniza los números de secuencia para iniciar una conexión TCP. El indicador FIN indica el final de la transmisión de datos para finalizar una conexión TCP. Sus propósitos son mutuamente excluyentes. Un encabezado TCP con el conjunto de indicadores SYN y FIN es un comportamiento TCP anómalo, lo que provoca varias respuestas del destinatario, según el sistema operativo. Véase la figura 1.
de indicadores SYN y FIN
Un atacante puede enviar un segmento con ambas marcas configuradas para ver qué tipo de respuesta del sistema se devuelve y, por lo tanto, determinar qué tipo de sistema operativo está en el extremo receptor. Luego, el atacante puede usar cualquier vulnerabilidad del sistema conocida para ataques posteriores. Cuando habilite la tcp-drop-synfin-set instrucción, Junos OS comprueba si los indicadores SYN y FIN se establecen en los encabezados TCP. Si descubre un encabezado de este tipo, deja caer el paquete.
[edit system internet-options] tcp-drop-synfin-set;
Deshabilitar extensiones TCP RFC 1323
Para deshabilitar las extensiones TCP de RFC 1323, incluya la no-tcp-rfc1323 instrucción en el [edit system internet-options] nivel de jerarquía:
[edit system internet-options] no-tcp-rfc1323;
Para deshabilitar la extensión del número de protección contra secuencia empaquetada (PAWS) (descrito en RFC 1323, Extensiones TCP para alto rendimiento), incluya la no-tcp-rfc1323-paws instrucción en el [edit system internet-options] nivel de jerarquía:
[edit system internet-options] no-tcp-rfc1323-paws;
Configurar TCP MSS para la negociación de sesión
Durante el establecimiento de la conexión de sesión, dos pares acuerdan en negociaciones determinar el tamaño del segmento IP de los paquetes que intercambiarán durante su comunicación. El valor TCP MSS (tamaño máximo de segmento) en los paquetes TCP SYN especifica la cantidad máxima de bytes que el campo de datos de un paquete TCP o segmento puede contener. Un valor MSS que se establece demasiado alto puede dar como resultado un datagrama de IP demasiado grande para enviar y que debe fragmentarse. La fragmentación puede generar costos adicionales de sobrecarga y pérdida de paquetes.
Para reducir la probabilidad de fragmentación y proteger contra la pérdida de paquetes, puede usar la tcp-mss instrucción para especificar un valor TCP MSS más bajo. La tcp-mss instrucción se aplica a todos los paquetes TCP SYN IPv4 que atraviesan todas las interfaces de entrada del enrutador cuyo valor MSS es mayor que el especificado. No puede eximir a puertos concretos de sus efectos.
En la siguiente sección se describe cómo configurar TCP MSS en enrutadores serie T, M y serie MX.
- Configuración de TCP MSS en enrutadores serie T y M, y enrutadores serie MX mediante una tarjeta de servicio
- Configurar TCP MSS en línea en enrutadores de la serie MX mediante tarjetas de línea MPC
Configuración de TCP MSS en enrutadores serie T y M, y enrutadores serie MX mediante una tarjeta de servicio
Para especificar un valor TCP MSS en enrutadores serie T y M, así como en enrutadores serie MX mediante una tarjeta de servicio, incluya la tcp-mss mss-value instrucción en el [edit services service-set service-set-name] nivel de jerarquía:
[edit services service-set service-set-name] tcp-mss mss-value;
El intervalo del tcp-mss mss-value parámetro es de 536 a 65535 bytes.
Agregue el conjunto de servicios a cualquier interfaz para la que desee ajustar el valor TCP-MSS:
[edit interfaces interface-name unit 0 family family service] input service-set service-set-name; output service-set service-set-name;
Para ver las estadísticas de los paquetes SYN recibidos y de los paquetes SYN cuyo valor MSS se modifica, emita el comando de show services service-sets statistics tcp-mss modo operativo.
Para obtener más información acerca de cómo configurar TCP MSS en enrutadores serie T y M, consulte la biblioteca de interfaces de servicios de Junos OS para dispositivos de enrutamiento.
Configurar TCP MSS en línea en enrutadores de la serie MX mediante tarjetas de línea MPC
Para especificar un valor TCP MSS en enrutadores serie MX que usan tarjetas de línea MPC, incluya la tcp-mss instrucción en el [edit interfaces interface-name unit logical-unit-number family family] nivel de jerarquía:
[edit interfaces interface-name unit logical-unit-number family family] tcp-mss mss-value;
El intervalo del mss-value parámetro es de 64 a 65,535 bytes. El valor TCP MSS debe ser menor que la MTU de la interfaz.
Esta instrucción se admite en las siguientes interfaces: gr- (GRE), ge- (Gigabit Ethernet), xe- (10 Gigabit Ethernet) y et- (40 Gigabit y 100 Gigabit Ethernet). Las familias respaldadas son inet y inet6.
La configuración de TCP MSS en línea en enrutadores de la serie MX mediante tarjetas de línea MPC funciona solo para el tráfico que sale o sale de la interfaz, no para el tráfico que entra o ingresa a la interfaz.
Seleccione una dirección de origen fija para los paquetes TCP/IP generados localmente
Los paquetes IP generados localmente son los paquetes que se producen por las aplicaciones que se ejecutan en el motor de enrutamiento. Junos OS elige una dirección de origen para estos paquetes para que los pares de la aplicación puedan responder. También le permite especificar la dirección de origen por aplicación. Para cumplir este propósito, el comando de CLI telnet contiene el source-address argumento.
En esta sección se presenta la default-address-selection declaración:
[edit system] default-address-selection;
Si elige específicamente la dirección de origen, como en el caso de Telnet, default-address-selection no influye en la selección de dirección de origen. La dirección de origen se convierte en la especificada con el source-address argumento (siempre que la dirección sea una dirección válida especificada en la interfaz de un enrutador). Si no se especifica la dirección de origen o si la dirección especificada no es válida, default-address-selection influye en la selección predeterminada de dirección de origen.
Si la dirección de origen no se especifica explícitamente como en el caso de Telnet, de forma predeterminada (cuando default-address-selection no se especifica) la dirección de origen elegida para los paquetes IP generados localmente es la dirección IP de la interfaz de salida. Esto indica que, según la interfaz de salida elegida, la dirección de origen puede ser diferente para diferentes invocaciones de una aplicación determinada.
Si la interfaz no está numerada (no se especifica ninguna dirección IP en una interfaz), Junos OS usa un algoritmo predecible para determinar la dirección de origen predeterminada. Si default-address-selection se especifica, Junos OS usa el algoritmo para elegir la dirección de origen independientemente de si la interfaz de salida está numerada. Esto indica que con default-address-selection, puede influir en Junos OS para que proporcione la misma dirección de origen en los paquetes IP generados localmente, independientemente de la interfaz de salida.
El comportamiento de la selección de direcciones de origen por Junos OS se puede resumir como se muestra en la siguiente tabla:
| Interfaz de salida |
Cuándo |
Cuándo |
|---|---|---|
| Sin numerar |
Uso |
Uso |
| Numeradas |
Uso |
Usar la dirección IP de la interfaz de salida |
Consulte Configurar direcciones e interfaces predeterminadas, principales y preferidas para obtener más información acerca del algoritmo de selección de origen de direcciones predeterminado.
Para los paquetes IP enviados por protocolos de enrutamiento IP (incluidos OSPF, RIP, RSVP y los protocolos de multidifusión, pero no incluyendo IS-IS), la selección de direcciones locales suele estar limitada por la especificación del protocolo para que el protocolo funcione correctamente. Cuando esta restricción existe en el protocolo de enrutamiento, la dirección de origen del paquete no se ve afectada por la presencia de la default-address-selection instrucción en la configuración. Para los protocolos en los que la dirección local no está restringida por la especificación del protocolo, como IBGP y EBGP multihop, si no configura una dirección local específica al configurar el protocolo, la dirección local se elige mediante el mismo método que otros paquetes IP generados localmente.
Autenticación TCP
Habilitar un método de autenticación TCP mejora la seguridad y garantiza la autenticidad de los segmentos TCP intercambiados durante las sesiones de BGP y LDP. Los dispositivos Junos admiten tres tipos principales de autenticación TCP: TCP MD5, opción de autenticación TCP (TCP-AO) y autenticación basada en llaveros TCP. Para obtener más información acerca de TCP-AO, consulte Opción de autenticación TCP (TCP-AO).
Aunque los dispositivos Junos son compatibles con los métodos de autenticación TCP-AO y TCP MD5, no puede usar ambos al mismo tiempo para una conexión determinada.
Soporte de subred IP
Antes de Junos OS Evolved versión 22.4R1, los dispositivos Junos solo le permiten usar la autenticación TCP con una dirección específica. Esto significa que solo puede autenticar conexiones TCP a pares remotos con direcciones IP conocidas.
A partir de Junos OS Evolved versión 22.4R1, la autenticación TCP-AO y TCP MD5 admite subredes IP para sesiones de LDP y BGP. Cuando configure la autenticación TCP con una dirección de red y una longitud de prefijo, el método de autenticación TCP elegido autentica las conexiones TCP con todo el rango de direcciones en esa subred. Esto significa que puede autenticar conexiones TCP sin necesidad de saber las direcciones IP exactas de los dispositivos de destino.
Cuando las subredes IP se superponen, el método de autenticación usa la coincidencia de prefijo más larga (LPM) para determinar la clave de autenticación exacta para una sesión TCP específica.
BGP
Para configurar la autenticación basada en prefijos para sesiones de BGP, incluya la allow (all | prefix-list) instrucción en cualquiera de las jerarquías siguientes:
-
[edit protocols bgp group group-name] -
[edit protocols bgp group group-name dynamic-neighbor dyn-name]
Puede usar direcciones IPV4 o IPV6 para la subred.
En este ejemplo, TCP MD5 autentica las conexiones TCP con dispositivos en la subred 10.0.3.0/24 para todas las sesiones de BGP:
[edit protocols]
bgp {
group one {
authentication-key "$ABC123";
allow 10.0.3.0/24;
dynamic-neighbor dyn_one {
allow 10.0.3.0/24;
authentication-key "$ABC123";
}
}
}
LDP
Para configurar la autenticación basada en prefijos para LDP, configure la autenticación TCP en la session-group ip-prefix jerarquía. Debe usar una dirección IPv4.
En este ejemplo, LDP usa TCP-AO para autenticar cualquier conexión TCP con un dispositivo que tenga una dirección en la subred 10.0.0.0/24:
[edit protocols ldp]
session-group 10.0.0.0/24 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
Para saber cómo configurar el llavero TCP-AO, consulte Opción de autenticación TCP (TCP-AO).
Soporte de VRF
En versiones anteriores a Junos OS Evolved versión 22.4R1, TCP MD5 y TCP-AO ignoran las instancias de enrutamiento y reenvío virtual (VRF). El dispositivo ignora las configuraciones de TCP MD5 y TCP-AO en instancias de enrutamiento no predeterminadas. Cuando configure TCP MD5 o TCP-AO en la instancia predeterminada de VRF, el dispositivo aplica ese método de autenticación a todas las sesiones TCP que tengan destinos dentro del rango de direcciones IP para esa instancia VRF. Si una sesión TCP pertenecía a una instancia de VRF no predeterminada pero tenía la misma dirección IP de destino que la instancia predeterminada de VRF, TCP MD5 y TCP-AO aplicarían la misma clave de autenticación a dos conexiones TCP con la misma dirección IP de destino.
A partir de Junos OS Evolved versión 22.4R1, la autenticación TCP-AO y TCP MD5 son conscientes de VRF en las sesiones de BGP y LDP. Puede configurar TCP-AO y TCP MD5 en instancias de enrutamiento no predeterminadas. El método de autenticación TCP que configure bajo una instancia de enrutamiento solo se aplica a las sesiones TCP dentro de esa instancia VRF. Si una conexión TCP en una instancia de VRF diferente tiene la misma dirección IP de destino, el método de autenticación TCP no se aplica a esa conexión TCP si la instancia de VRF no tiene autenticación TCP configurada para el par.
Configure la autenticación TCP basada en VRF como lo haría normalmente, pero bajo un routing-instances nivel de jerarquía. Para usar la autenticación TCP MD5, incluya la authentication-key authentication-key instrucción. Para usar TCP-AO, incluya las siguientes instrucciones:
user@device# set authentication-algorithm ao user@device# set authentication-key-chain keychain
Para saber cómo configurar el llavero TCP-AO, consulte Opción de autenticación TCP (TCP-AO).
Puede combinar configuraciones compatibles con VRF con subredes IP. Esto le permite autenticar conexiones a un rango de direcciones dentro de la instancia vrf.
BGP
Configure la autenticación TCP basada en VRF para sesiones de BGP en cualquiera de los siguientes niveles jerárquicos:
-
[edit routing-instances vrf-instance protocols bgp] -
[edit routing-instances vrf-instance protocols bgp group group-name] -
[edit routing-instances vrf-instance protocols bgp group group-name neighbor neighbor-ip] -
[edit routing-instances vrf-instance protocols bgp group group-name dynamic-neighbor dyn-name]
Si configura la autenticación basada en VRF en el dynamic-neighbor nivel, incluya la instrucción junto con la allow configuración del método de autenticación elegida. Por ejemplo, para usar TCP-AO con un vecino dinámico:
[edit routing-instances vrf-instance protocols bgp group group-name dynamic-neighbor dyn-name] user@device# set allow (all | prefix-list) user@device# set authentication-algorithm ao user@device# set authentication-key-chain keychain
En el ejemplo siguiente, el BGP usa la autenticación TCP para garantizar la seguridad de las conexiones TCP en una instancia VRF llamada vrf-one. En el grupo uno, el BGP usa TCP MD5 para autenticar conexiones con el vecino con la dirección IP 10.0.1.1. Usa TCP-AO para autenticar conexiones con el vecino con la dirección IP 10.0.1.2.
En el grupo dos, el BGP usa TCP-AO para autenticar conexiones con cualquier dispositivo en la subred 10.0.0.0/24.
[edit routing-instances]
vrf-one {
protocols {
bgp {
group one {
peer-as 22;
neighbor 10.0.1.1 {
authentication-key "$ABC123"; ## SECRET-DATA
}
neighbor 10.0.1.2 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
group two {
peer-as 22;
dynamic-neighbor dyn_two {
allow 10.0.0.0/24;
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
}
}
}
LDP
Configure la autenticación basada en VRF para sesiones de LDP en cualquiera de los siguientes niveles jerárquicos:
-
[edit routing-instances vrf-instance protocols ldp] -
[edit routing-instances vrf-instance protocols ldp session session-ip] -
[edit routing-instances vrf-instance protocols ldp session-group ip-prefix]
En este ejemplo, TCP-AO autentica las conexiones TCP en una instancia VRF llamada vrf-two. Autentica las conexiones TCP con la dirección 10.0.1.1, así como cualquier dirección en la subred 10.0.0.0/24.
[edit routing-instances]
vrf-two {
protocols {
ldp {
session 10.0.1.1 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
session-group 10.0.0.0/24 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
}
}