Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

TCP

De nombreuses applications et services utilisent tcp pour communiquer. Configurez les options TCP pour améliorer la qualité et la sécurité des liaisons.

Sécurité des en-têtes TCP avec ensemble de flags SYN et FIN

Par défaut, votre équipement accepte les paquets dont les bits SYN et FIN sont définis dans l’indicateur TCP. Configurez votre équipement pour qu’il abandonne les paquets avec les bits SYN et FIN définis pour réduire les vulnérabilités de sécurité.

Les indicateurs de contrôle SYN et FIN ne sont normalement pas définis dans le même en-tête de segment TCP. L’indicateur SYN synchronise les numéros de séquence pour lancer une connexion TCP. L’indicateur FIN indique la fin de transmission des données pour terminer une connexion TCP. Leurs objectifs sont mutuellement exclusifs. Un en-tête TCP avec les indicateurs SYN et FIN est un comportement TCP anormal, ce qui entraîne diverses réponses du destinataire, en fonction du système d’exploitation. Voir la figure 1.

Figure 1 : en-tête TCP avec ensemble d’indicateurs TCP Header with SYN and FIN Flags Set SYN et FIN

Un attaquant peut envoyer un segment avec les deux indicateurs définis pour voir quel type de réponse système est renvoyé et ainsi déterminer quel type d’OS se trouve à l’extrémité de la réception. L’attaquant peut alors utiliser toutes les vulnérabilités connues du système pour d’autres attaques. Lorsque vous activez l’instruction tcp-drop-synfin-set , Junos OS vérifie si les indicateurs SYN et FIN sont définis dans les en-têtes TCP. S’il découvre un tel en-tête, il abandonne le paquet.

Désactiver les extensions RFC TCP 1323

Pour désactiver les extensions TCP RFC 1323, incluez l’instruction no-tcp-rfc1323 au niveau de la [edit system internet-options] hiérarchie :

Pour désactiver l’extension PAWS (Protection Against Wrapped Sequence) (décrite dans la RFC 1323, Extensions TCP pour hautes performances), incluez l’instruction no-tcp-rfc1323-paws au niveau de la [edit system internet-options] hiérarchie :

Configurer TCP MSS pour la négociation de session

Lors de l’établissement de la connexion de session, deux pairs s’accordent lors de négociations pour déterminer la taille des segments IP des paquets qu’ils échangeront pendant leur communication. La valeur TCP MSS (taille de segment maximale) dans les paquets TCP SYN spécifie le nombre maximal d’octets que le champ de données d’un paquet TCP, ou segment, peut contenir. Une valeur MSS trop élevée peut entraîner un datagramme IP trop volumineux à envoyer et doit être fragmenté. La fragmentation peut entraîner des coûts supplémentaires et des pertes de paquets.

Pour réduire la probabilité de fragmentation et protéger contre la perte de paquets, vous pouvez utiliser l’instruction tcp-mss pour spécifier une valeur MSS TCP inférieure. L’instruction tcp-mss s’applique à tous les paquets TCP SYN TCP IPv4 traversant toutes les interfaces entrantes du routeur dont la valeur MSS est supérieure à celle que vous spécifiez. Vous ne pouvez pas exempter certains ports de ses effets.

La section suivante explique comment configurer TCP MSS sur les routeurs T Series, M Series et MX Series.

Configuration de TCP MSS sur les routeurs T Series et M Series, ainsi que sur les routeurs MX Series à l’aide d’une carte de service

Pour spécifier une valeur TCP MSS sur les routeurs T Series et M Series, ainsi que sur les routeurs MX Series à l’aide d’une carte de service, incluez l’instruction tcp-mss mss-value au niveau de la [edit services service-set service-set-name] hiérarchie :

La plage du tcp-mss mss-value paramètre est de 536 à 6 5535 octets.

Ajoutez l’ensemble de services à n’importe quelle interface pour laquelle vous souhaitez ajuster la valeur TCP-MSS :

Pour consulter les statistiques des paquets SYN reçus et des paquets SYN dont la valeur MSS est modifiée, la commande du show services service-sets statistics tcp-mss mode opérationnel est envoyée.

Pour plus d’informations sur la configuration de TCP MSS sur les routeurs T Series et M Series, consultez la bibliothèque d’interfaces de services Junos OS pour les équipements de routage.

Configuration de TCP MSS inline sur les routeurs MX Series à l’aide de cartes d’interface MPC

Pour spécifier une valeur TCP MSS sur les routeurs MX Series qui utilisent des cartes d’interface MPC, incluez l’instruction tcp-mss au niveau de la [edit interfaces interface-name unit logical-unit-number family family] hiérarchie :

La plage du mss-value paramètre est de 64 à 65 535 octets. La valeur TCP MSS doit être inférieure à la MTU de l’interface.

Cette déclaration est prise en charge sur les interfaces suivantes : gr- (GRE), ge- (Gigabit Ethernet), xe- (10 Gigabit Ethernet) et et- (40-Gigabit et 100-Gigabit Ethernet). Les familles soutenues sont inet et inet6.

Note:

La configuration de TCP MSS inline sur les routeurs MX Series à l’aide de cartes d’interface MPC fonctionne uniquement pour le trafic sortant/sortant de l’interface, et non pour le trafic entrant/entrant dans l’interface.

Sélectionnez une adresse source fixe pour les paquets TCP/IP générés localement

Les paquets IP générés localement sont les paquets produits par les applications s’exécutant sur le moteur de routage. Junos OS choisit une adresse source pour ces paquets afin que les pairs de l’application puissent répondre. Il vous permet également de spécifier l’adresse source par application. Pour cela, la commande CLI Telnet contient l’argument source-address .

Cette section présente l’énoncé default-address-selection :

Si vous choisissez spécifiquement l’adresse source, comme dans le cas de Telnet, default-address-selection n’influence pas la sélection de l’adresse source. L’adresse source devient celle spécifiée avec l’argument source-address (à condition que l’adresse soit une adresse valide spécifiée sur l’interface d’un routeur). Si l’adresse source n’est pas spécifiée ou si l’adresse spécifiée n’est pas valide, default-address-selection elle influence la sélection de l’adresse source par défaut.

Si l’adresse source n’est pas explicitement spécifiée comme dans le cas de Telnet, alors par défaut (lorsqu’elle default-address-selection n’est pas spécifiée) l’adresse source choisie pour les paquets IP générés localement est l’adresse IP de l’interface sortante. Cela indique qu’en fonction de l’interface de sortie choisie, l’adresse source peut être différente pour différentes invocations d’une application donnée.

Si l’interface n’est pas numérotée (aucune adresse IP n’est spécifiée sur une interface), Junos OS utilise un algorithme prévisible pour déterminer l’adresse source par défaut. Si default-address-selection elle est spécifiée, Junos OS utilise l’algorithme pour choisir l’adresse source, que l’interface sortante soit numérotée ou non. Cela indique qu’avec default-address-selection, vous pouvez influencer Junos OS pour fournir la même adresse source dans les paquets IP générés localement, quelle que soit l’interface sortante.

Le comportement de la sélection de l’adresse source par Junos OS peut être résumé comme illustré dans le tableau suivant :

Tableau 1 : Sélection de l’adresse source

Interface sortante

Quand default-address-selection est spécifié

Quand default-address-selection n’est pas spécifié

Sans numéro

Utiliser default-address-selection

Utiliser default-address-selection

Numérotés

Utiliser default-address-selection

Utiliser l’adresse IP de l’interface sortante

Voir Configuration des adresses et interfaces par défaut, primaire et préférée pour plus d’informations sur l’algorithme de sélection des sources d’adresses par défaut.

Note:

Pour les paquets IP envoyés par les protocoles de routage IP (y compris OSPF, RIP, RSVP et les protocoles multicast, mais non is-IS), la sélection des adresses locales est souvent limitée par la spécification du protocole afin que le protocole fonctionne correctement. Lorsque cette contrainte existe dans le protocole de routage, l'adresse source du paquet n'est pas affectée par la présence de l' default-address-selection instruction dans la configuration. Pour les protocoles dans lesquels l’adresse locale n’est pas contrainte par la spécification du protocole comme IBGP et EBGP multihop, si vous ne configurez pas une adresse locale spécifique lors de la configuration du protocole, l’adresse locale est choisie selon la même méthode que les autres paquets IP générés localement.

Authentification TCP

L’activation d’une méthode d’authentification TCP améliore la sécurité et garantit l’authenticité des segments TCP échangés lors des sessions BGP et LDP. Les équipements Junos prennent en charge trois principaux types d’authentification TCP : TCP MD5, TCP Authentification Option (TCP-AO) et authentification basée sur le trousseau TCP. Pour plus d’informations sur TCP-AO, consultez l’option d’authentification TCP (TCP-AO).

Note:

Bien que les équipements Junos prennent en charge à la fois les méthodes d’authentification TCP-AO et TCP MD5, vous ne pouvez pas utiliser les deux en même temps pour une connexion donnée.

Prise en charge des sous-réseaux IP

Avant La version 22.4R1 de Junos OS Evolved, les équipements Junos ne vous permettaient d’utiliser l’authentification TCP qu’avec une adresse spécifique. Cela signifie que vous ne pouvez authentifier les connexions TCP auprès de pairs distants qu’avec des adresses IP connues.

À partir de la version 22.4R1 de Junos OS Evolved, les authentifications TCP-AO et TCP MD5 prennent en charge les sous-réseaux IP pour les sessions LDP et BGP. Lorsque vous configurez l’authentification TCP avec une adresse réseau et une longueur de préfixe, la méthode d’authentification TCP choisie authentifie les connexions TCP sur l’ensemble de la gamme d’adresses sous ce sous-réseau. Cela signifie que vous pouvez authentifier les connexions TCP sans avoir besoin de connaître les adresses IP exactes des équipements de destination.

Lorsque les sous-réseaux IP se chevauchent, la méthode d’authentification utilise la correspondance de préfixe (LPM) la plus longue pour déterminer la clé d’authentification exacte pour une session TCP spécifique.

BGP

Pour configurer l’authentification basée sur des préfixes pour les sessions BGP, incluez l’instruction allow (all | prefix-list) dans l’une des hiérarchies suivantes :

  • [edit protocols bgp group group-name]

  • [edit protocols bgp group group-name dynamic-neighbor dyn-name]

Vous pouvez utiliser des adresses IPV4 ou IPV6 pour le sous-réseau.

Dans cet exemple, TCP MD5 authentifie les connexions TCP aux équipements du sous-réseau 10.0.3.0/24 pour toutes les sessions BGP :

LDP

Pour configurer l’authentification basée sur les préfixes pour LDP, configurez l’authentification TCP dans la session-group ip-prefix hiérarchie. Vous devez utiliser une adresse IPv4.

Dans cet exemple, LDP utilise TCP-AO pour authentifier toute connexion TCP avec un équipement dont l’adresse est dans le sous-réseau 10.0.0.0/24 :

Pour configurer votre trousseau TCP-AO, consultez l’option d’authentification TCP (TCP-AO).

Assistance VRF

Dans les versions antérieures à Junos OS Evolved version 22.4R1, TCP MD5 et TCP-AO ignorent les instances VRF (Virtual Routing and Forwarding). L’équipement ignore les configurations TCP MD5 et TCP-AO sous des instances de routage non par défaut. Lorsque vous configurez TCP MD5 ou TCP-AO sous l’instance VRF par défaut, l’équipement applique cette méthode d’authentification à toutes les sessions TCP qui ont des destinations dans la plage d’adresses IP de cette instance VRF. Si une session TCP appartenait à une instance VRF non par défaut mais avait la même adresse IP de destination que l’instance VRF par défaut, TCP MD5 et TCP-AO appliqueraient la même clé d’authentification à deux connexions TCP avec la même adresse IP de destination.

À partir de la version 22.4R1 de Junos OS Evolved, les authentifications TCP-AO et TCP MD5 sont compatibles VRF dans les sessions BGP et LDP. Vous pouvez configurer TCP-AO et TCP MD5 sous des instances de routage non par défaut. La méthode d’authentification TCP que vous configurez sous une instance de routage n’est appliquée qu’aux sessions TCP de cette instance VRF. Si une connexion TCP dans une autre instance VRF a la même adresse IP de destination, la méthode d’authentification TCP ne sera pas appliquée à cette connexion TCP si l’instance VRF n’a pas d’authentification TCP configurée pour l’homologue.

Configurez l’authentification TCP basée sur VRF comme vous le feriez normalement, mais au routing-instances niveau hiérarchique. Pour utiliser l’authentification TCP MD5, incluez l’instruction authentication-key authentication-key . Pour utiliser TCP-AO, incluez les déclarations suivantes :

Pour configurer votre trousseau TCP-AO, consultez l’option d’authentification TCP (TCP-AO).

Vous pouvez combiner des configurations compatibles VRF avec des sous-réseaux IP. Cela vous permet d’authentifier les connexions à une gamme d’adresses au sein de l’instance VRF.

BGP

Configurez l’authentification TCP basée sur VRF pour les sessions BGP à l’un des niveaux hiérarchiques suivants :

  • [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 vous configurez l’authentification basée sur VRF dynamic-neighbor au niveau, incluez l’instruction ainsi que la allow configuration de la méthode d’authentification choisie. Par exemple, pour utiliser TCP-AO avec un voisin dynamique :

Dans l’exemple suivant, BGP utilise l’authentification TCP pour assurer la sécurité des connexions TCP dans une instance VRF appelée vrf-one. Dans le groupe 1, BGP utilise TCP MD5 pour authentifier les connexions au voisin avec l’adresse IP 10.0.1.1. Il utilise TCP-AO pour authentifier les connexions au voisin avec l’adresse IP 10.0.1.2.

Dans le groupe 2, BGP utilise TCP-AO pour authentifier les connexions à n’importe quel équipement du sous-réseau 10.0.0.0/24.

LDP

Configurez l’authentification basée sur VRF pour les sessions LDP à l’un des niveaux hiérarchiques suivants :

  • [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]

Dans cet exemple, TCP-AO authentifie les connexions TCP dans une instance VRF appelée vrf-two. Il authentifie les connexions TCP à l’adresse 10.0.1.1 ainsi que toute adresse du sous-réseau 10.0.0.0/24.

Tableau de l’historique des versions
Libération
Description
22.4R1
À partir de la version 22.4R1 de Junos OS Evolved, vous pouvez configurer l’authentification TCP-AO ou TCP MD5 avec un sous-réseau IP afin d’inclure toute la gamme d’adresses sous ce sous-réseau.
22.4R1
À partir de la version 22.4R1 de Junos OS Evolved, l’authentification TCP est compatible VRF.