Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

TCP Sessions

Pour envoyer des données via TCP dans un réseau, un processus d’établissement de session d’établissement d’une liaison à trois voies est suivi. Il existe un processus pour démarrer une session, et il existe également un processus pour mettre fin à la session TCP. Cette rubrique vous aide à comprendre le processus de traitement d’une session TCP.

Comprendre les vérifications de session TCP par stratégie

Par défaut, les options de vérification TCP SYN et de vérification de séquence sont activées sur toutes les sessions TCP. Le système d’exploitation Junos (Junos OS) effectue les opérations suivantes pendant les sessions TCP :

  • Vérifie les indicateurs SYN dans le premier paquet d’une session et rejette tous les segments TCP avec des indicateurs non-SYN qui tentent de lancer une session.

  • Valide les numéros de séquence TCP lors de l’inspection dynamique.

La fonctionnalité de vérification de session TCP par stratégie vous permet de configurer les vérifications SYN et de séquence pour chaque stratégie. Actuellement, les options TCP, no-sequence-check et no-syn-check, sont disponibles au niveau global pour contrôler le comportement des passerelles de services. Pour prendre en charge les options TCP par stratégie, les deux options suivantes sont disponibles :

  • sequence-check-required : la valeur sequence-check-required remplace la valeur globale no-sequence-check.

  • syn-check-required : la valeur syn-check-required remplace la valeur globale no-syn-check.

Pour configurer les options TCP par stratégie, vous devez désactiver les options globales respectives ; sinon, la vérification de validation échouera. Si les options TCP globales sont désactivées et que la protection contre le saturation SYN autorise le premier paquet, les options TCP par stratégie contrôlent si des vérifications SYN et/ou de séquence sont effectuées.

Note:

  • L’option per-policy syn-check-required ne remplace pas le comportement de la set security flow tcp-session no-syn-check-in-tunnel commande CLI.

  • La désactivation de la vérification SYN globale réduit l’efficacité de l’appareil dans la défense contre le saturation de paquets.
PRUDENCE:

La désactivation de la vérification SYN globale et l’application de la vérification SYN après la recherche de stratégie auront un impact considérable sur le nombre de paquets que le routeur peut traiter. Cela entraînera à son tour des opérations intenses du processeur. Lorsque vous désactivez la vérification SYN globale et que vous activez l’application de la vérification SYN par stratégie, vous devez être conscient de cet impact sur les performances.

Désactivation des contrôles de sécurité des paquets TCP

Sur un pare-feu SRX Series, vous pouvez désactiver les contrôles de sécurité sur les paquets TCP pour garantir l’interopérabilité avec les hôtes et les périphériques dont l’implémentation TCP est défectueuse.

L’option no-sequence-check désactive les vérifications de séquence TCP. Cela augmente également le débit.

La set security flow tcp-session no-sequence-check commande désactive les vérifications de séquence TCP sur toutes les sessions TCP en mode par défaut ou basé sur le hachage.

Exemple : configuration des contrôles de sécurité des paquets TCP par stratégie

Cet exemple montre comment configurer les contrôles de sécurité des paquets TCP pour chaque stratégie de l’appareil.

Exigences

Avant de commencer, vous devez désactiver les options tcp, tcp-syn-check, et tcp-sequence-check qui sont configurées au niveau global. .

Aperçu

Les options SYN et de vérification de séquence sont activées par défaut sur toutes les sessions TCP. Dans les environnements qui doivent prendre en charge des transferts de fichiers volumineux ou qui exécutent des applications non standard, il peut s’avérer nécessaire de configurer les vérifications de séquence et de synchronisation différemment pour chaque stratégie. Dans cet exemple, vous configurez la vérification de séquence et de synchronisation pour la stratégie pol1.

Configuration

Procédure

Procédure étape par étape

Pour configurer les contrôles de sécurité des paquets TCP au niveau de la stratégie :

  1. Configurez la vérification du bit TCP SYN avant de créer une session.

  2. Configurez la vérification des numéros de séquence dans les segments TCP lors de l’inspection dynamique.

  3. Si vous avez terminé de configurer l’appareil, validez la configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, entrez la show security policies detail commande.

Exemple : Désactivation des contrôles de sécurité des paquets TCP pour les passerelles de services SRX Series

Cet exemple montre comment désactiver les contrôles de sécurité des paquets TCP dans le périphérique.

Exigences

Avant de commencer, comprenez les circonstances de la désactivation des vérifications de sécurité des paquets TCP. .

Aperçu

Junos OS fournit un mécanisme permettant de désactiver les contrôles de sécurité sur les paquets TCP afin de garantir l’interopérabilité avec les hôtes et les périphériques dont l’implémentation TCP est défectueuse. Lors de la vérification no-SYN, le système d’exploitation Junos OS ne recherche pas le paquet TCP SYN pour la création de session. La vérification sans séquence désactive la validation de la vérification de séquence TCP. Augmente également le débit. La vérification SYN et la vérification de séquence sont activées par défaut. La commande set security flow désactive les vérifications TCP SYN et les vérifications de séquence TCP sur toutes les sessions TCP, ce qui réduit la sécurité. Cela peut être nécessaire dans des scénarios avec des clients tels que des fichiers de transfert volumineux, ou avec des applications qui ne fonctionnent pas correctement avec les normes.

Configuration

Procédure

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.

Pour désactiver les vérifications de sécurité des paquets TCP :

  1. Désactivez la vérification du bit TCP SYN avant de créer une session.

  2. Désactivez la vérification des numéros de séquence dans les segments TCP lors de l’inspection dynamique.

  3. Si vous avez terminé de configurer l’appareil, validez la configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, entrez la show security flow commande.

Exemple : Définition de la taille de segment maximale pour toutes les sessions TCP pour les pare-feu SRX Series

Cet exemple montre comment définir la taille de segment maximale pour toutes les sessions TCP pour les pare-feu SRX Series.

Exigences

Avant de commencer, comprenez les circonstances de définition de la taille maximale du segment.

Aperçu

Vous pouvez mettre fin à toutes les sessions TCP en modifiant la taille maximale du segment TCP (TCP-MSS). Pour réduire la probabilité de fragmentation et vous protéger contre la perte de paquets, vous pouvez utiliser tcp-mss pour spécifier une valeur TCP MSS inférieure. Cela s’applique à tous les paquets TCP SYN traversant les interfaces d’entrée du routeur dont la valeur MSS est supérieure à celle que vous spécifiez.

Si le bit DF est défini, il ne fragmentera pas le paquet et Junos OS enverra le paquet ICMP de type d’erreur 3 code 4 au serveur d’applications (Destination inaccessible ; Fragmentation nécessaire et DF défini). Ce message d’erreur ICMP contient la MTU correcte (telle que définie dans tcp-mss) qui doit être utilisée par le serveur d’applications, qui doit recevoir ce message et ajuster la taille du paquet en conséquence. C’est particulièrement nécessaire pour les VPN, car IPsec a ajouté une surcharge de paquets. Par conséquent, TCP-MSS doit être abaissé de manière appropriée.

Note:

Lorsque vous exécutez des pare-feu SRX Series en mode paquet, vous utilisez la commande pour set system internet-options tcp-mss ajuster la valeur TCP-MSS. Tous les ports sont concernés par la configuration TCP-MSS ; Vous ne pouvez pas exclure un port en particulier. Lorsque vous exécutez des pare-feu SRX Series en mode flux, nous vous recommandons d’utiliser uniquement le set system internet-options tcp-mss set security flow tcp-mss pour ajuster la valeur TCP-MSS. Si les deux instructions sont configurées, la plus faible des deux valeurs prend effet.

Configuration

Procédure

Procédure étape par étape

Pour configurer la taille de segment maximale pour toutes les sessions TCP :

  1. Définissez la taille de segment TCP maximale pour toutes les sessions TCP.

  2. Si vous avez terminé de configurer l’appareil, validez la configuration.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show security flow commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.

Par souci de concision, la sortie de cette show commande inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).

Vérification

Pour vérifier que la configuration fonctionne correctement, entrez la show configuration security flow commande à partir du mode opérationnel.

Présentation de la journalisation des abandons de paquets TCP hors état

Dans tout réseau à commutation de paquets, lorsque la demande dépasse la capacité disponible, les paquets sont mis en file d’attente pour conserver les paquets excédentaires jusqu’à ce que la file d’attente se remplisse, puis les paquets sont abandonnés. Lorsque TCP fonctionne sur un tel réseau, il prend des mesures correctives pour maintenir des communications de bout en bout exemptes d’erreurs.

Les modules de flux prennent déjà en charge la génération de RTLOG pour les événements basés sur les sessions, tels que la création et la fermeture de session. Les pare-feu SRX Series prennent désormais en charge la génération de RTLOG pour les événements basés sur des paquets, tels que l’abandon de paquets, sans qu’une session n’existe.

Les pare-feu SRX Series prennent en charge la journalisation des paquets TCP non synchronisés hors état qui sont abandonnés par le module de flux.

La fonctionnalité d’abandon de paquets TCP hors état évite toute perte de paquets et permet la récupération des paquets en consignant les paquets désynchronisés pour une communication sans erreur, et empêche les serveurs de base de données de se désynchroniser. Cette fonctionnalité s’appuie sur la fonction de journal de sécurité (RTLOG).

La journalisation des abandons de paquets TCP hors état prend en charge la capture des journaux d’abandon de paquets TCP dans les conditions suivantes :

  • Session ages out: lorsque des applications cloud s’exécutent sur de longues sessions TCP et que ces applications n’actualisent pas les sessions TCP une fois la session terminée, les paquets TCP sont abandonnés. Cette fonctionnalité prend en charge la journalisation de ces paquets TCP abandonnés.

  • Unsynchronized first packets due to attacks or asymmetric routes: lorsque vous déployez des pare-feu SRX Series sur deux sites, et que le routage force parfois un trafic asymétrique, le paquet de synchronisation (SYN) est vu sur un site, mais les paquets d’accusé de réception de synchronisation (SYN_ACK) sont vus sur un autre site.

    Cela signifie que le pare-feu SRX Series voit un paquet TCP ACK pour lequel il n’a pas d’entrée de table d’état correspondante. Cela peut se produire parce que la connexion a été inactive pendant un certain temps ou que les tables de connexions ont été vidées (par exemple, en raison de l’installation ou du redémarrage d’une stratégie).

    Dans ce cas, les paquets SYN_ACK détectés sur un autre site ont été refusés par le pare-feu SRX Series, mais n’ont pas été enregistrés. Cette fonctionnalité prend en charge la journalisation des paquets SYN_ACK refusés.

  • Other out-of-state conditions (like TCP sequence check fail and synchronization packet received in FIN state)—Lorsqu’un pare-feu SRX Series détecte une défaillance de séquence, si l’équipement est dans un état de fermeture à quatre voies TCP mais reçoit des paquets SYN, ou s’il y a un échec d’établissement de liaison à trois voies, le pare-feu SRX Series abandonne les paquets TCP et ces paquets abandonnés sont consignés.

Note:

Le journal d’abandon de paquets TCP non synchronisé est un journal basé sur les paquets et non sur les sessions.

La journalisation des abandons de paquets TCP hors état est conçue avec un mécanisme de limitation pour protéger le processeur contre les attaques, et dans chaque intervalle de limitation, certains journaux peuvent être abandonnés.

Seuls les paquets TCP hors état abandonnés par le module Flow sont consignés. Les paquets TCP abandonnés par le proxy TCP et l’IDP ne sont pas enregistrés.

Comprendre la journalisation des abandons de paquets hors état TCP

Pour comprendre l’implémentation de la journalisation des abandons de paquets TCP hors état, considérons que vous déployez des pare-feu SRX Series sur deux sites et que le routage force parfois un trafic asymétrique, où le paquet SYN est vu sur un site mais le paquet SYN_ACK est vu sur un autre site. Dans ce cas, le paquet SYN_ACK serait refusé, mais pas enregistré. La fonctionnalité de journalisation des abandons de paquets hors état TCP offre une visibilité sur ces abandons de paquets non synchronisés.

Prenons l’exemple d’un scénario dans lequel les bases de données du datacenter gardent leurs sockets TCP ouverts, sans qu’aucun keepalive ne soit envoyé. Si aucune donnée n’est transmise, le pare-feu SRX Series expirera les sessions. Bien que les bases de données envoient certaines données via ce socket TCP, lorsque le trafic atteint le pare-feu SRX Series, la session n’existe plus et le paquet est abandonné, mais pas journalisé. Ces paquets TCP hors état qui sont abandonnés sont maintenant consignés par le pare-feu SRX Series.

Fonctionnalités de journalisation hors état TCP prises en charge

La journalisation TCP hors état prend en charge les fonctionnalités suivantes :

  • Composant de filtrage de paquets pour filtrer le trafic cible.

  • Un composant d’accélérateur pour protéger le processeur contre la surcharge par les messages de journal.

  • Flexibilité pour modifier le taux de génération des logs.

Composant de filtrage de paquets

Le filtre de journalisation s’appuie sur le filtre de trace de flux actuel. Il propose différentes manières de filtrer le trafic. Vous devez configurer les filtres pour qu’ils génèrent des journaux de paquets, sinon les journaux ne seront pas déclenchés.

Cette fonctionnalité de filtrage évite d’activer des journaux de manière inattendue. Le nombre maximal de filtres pris en charge est de 64.

Utilisez la set security flow packet-log packet-filter <filter-name> commande pour activer les composants de filtre associés de votre choix.

Composant d’accélérateur

La journalisation de chaque paquet TCP hors état peut entraîner une surcharge de l’équipement lorsque le trafic est important ou en cas d’attaque. Si le processeur est inactif et que vous souhaitez consigner autant de messages que possible, cela peut entraîner une surcharge du processeur.

Le mécanisme d’accélérateur vous permet de configurer l’intervalle d’accélération à partir de l’interface de ligne de commande, afin que vous puissiez protéger votre processeur contre la surcharge.

Une table de hachage est introduite pour mapper vos données enregistrées. La clé de hachage est générée avec l’adresse IP source, l’adresse IP de destination, le port source et le port de destination.

Au cours de chaque intervalle de régulation, seul un nombre limité (plus d’un) de messages sera envoyé à RTLOG. Les messages de journal restants seront limités.

L’intervalle d’accélération par défaut est de 1 seconde. L’intervalle d’accélération (au niveau de la milliseconde) doit être configuré comme une puissance de deux ou zéro (0, 1, 2, 4, 8, 16 ... 2^N).

Lorsque l’intervalle d’accélération est configuré sur 0, aucun mécanisme d’accélérateur n’est impliqué. Cela convient aux scénarios où le trafic est très faible et où vous souhaitez enregistrer tous les journaux d’abandon de paquets.

La configuration de l’intervalle d’accélérateur en 2^N rend le mécanisme d’accélérateur sans verrouillage et offre de bonnes performances de capture des journaux.

Flexibilité pour modifier le taux de génération des journaux

En fonction de l’intervalle d’accélération défini, le taux de génération des journaux peut être modifié et géré.

Cela signifie qu’au cours de chaque intervalle de 32 millisecondes (ms), un nombre limité de journaux peut être généré et les autres peuvent être abandonnés. Nous vous recommandons de configurer l’intervalle comme suit : (0, 1, 2, 4, 8, 16, 32 ... 2^N).

Si la valeur d’entrée n’est pas alignée sur 2^N, elle sera automatiquement alignée sur 2^N pendant le traitement du flux. Par exemple, si vous configurez un intervalle de 10 ms, il sera automatiquement aligné sur un intervalle de 8 ms.

Comprendre comment la préservation des caractéristiques de fragmentation entrante peut améliorer le débit

Cette rubrique décrit les avantages du pare-feu SRX Series pour préserver les caractéristiques des fragments de paquets entrants.

Lorsque des données sont envoyées d’un hôte à un autre, elles sont transmises sous la forme d’une série de paquets. Les performances sont améliorées et les ressources réseau sont préservées lorsque des paquets de la plus grande taille peuvent transiter par le chemin entre le nœud source et le nœud de destination sans être fragmentés au niveau d’un lien dans le chemin de données. Lorsqu’un paquet doit être fragmenté en paquets plus petits pour faire transiter un lien sur le chemin parce que le paquet est plus grand que celui de l’unité de transmission maximale (MTU) établie pour cette liaison, chacun des fragments résultant doit contenir des informations d’en-tête de paquet, en plus de la charge utile, ou des données. Cette surcharge accrue peut réduire le débit et dégrader les performances du réseau. En outre, les fragments de paquets doivent être réassemblés au niveau du nœud de destination, ce qui consomme des ressources réseau supplémentaires.

D’autre part, les ressources réseau sont gaspillées lorsqu’un hôte envoie des paquets beaucoup plus petits que la MTU (Path Maximum Transmission Unit), ce qui entraîne un débit sous-optimal. Le processus de découverte de MTU de chemin permet de déterminer la taille de MTU optimale pour les fragments qui transitent le chemin de données du nœud source au nœud de destination pour une session. La taille optimale des paquets est donc celle de la MTU du chemin. La fragmentation se produit lorsque la taille d’un paquet dépasse la MTU du chemin.

Si les services de couche applicative sont configurés sur le pare-feu SRX Series, les fragments de paquets au niveau de l’interface entrante doivent être réassemblés avant que les services puissent être appliqués et que le contenu puisse être inspecté. Ces fragments de paquets réassemblés doivent être décomposés à nouveau avant que les données ne soient transmises à l’interface de sortie. Normalement, c’est la taille MTU de l’interface de sortie qui détermine la taille des fragments transmis par le pare-feu SRX Series au lien suivant. Il se peut que la MTU de sortie sur le pare-feu SRX Series soit supérieure à la MTU du chemin, ce qui, là encore, entraînerait une fragmentation des paquets dans le chemin de données, une réduction des performances ou la perte de paquets. Les fragments de paquets doivent être suffisamment petits pour permettre le transit de chaque maillon du chemin entre la source et la destination.

Par défaut, le pare-feu SRX Series utilise la taille MTU configurée pour l’interface de sortie afin de déterminer la taille des fragments de paquets qu’elle transmet. Toutefois, si vous activez la fonctionnalité de préservation des caractéristiques des fragments entrants, le pare-feu SRX Series détecte et enregistre la taille des fragments de paquets entrants.

Pour réduire la probabilité de fragmentation des paquets dans le chemin de données, le pare-feu SRX Series surveille et ajuste la MTU de sortie en fonction de ce flux. Il identifie la taille maximale de tous les fragments entrants. Il utilise ces informations en conjonction avec la MTU existante de l’interface de sortie pour déterminer la taille de MTU correcte pour les paquets fragmentés envoyés à l’interface de sortie. Le pare-feu SRX Series compare les deux chiffres. Il prend le plus petit nombre et l’utilise pour la taille MTU de l’interface de sortie.

Configurez le périphérique à l’aide de la set security flow preserve-incoming-frag-size commande pour activer la fonctionnalité qui prend en compte la taille des fragments de paquets entrants.

Le Tableau 1 résume la façon dont la taille de MTU de sortie SRX Series est déterminée.

Tableau 1 : détermination de la taille de MTU de sortie finale pour les fragments sortant du pare-feu SRX Series

Taille des fragments entrants

Taille de MTU de sortie existante

Taille de MTU de sortie finale

Si le plus grand fragment est

plus petite que la taille MTU de sortie existante

La plus grande taille de fragment entrant est utilisée.

Si le plus grand fragment est

plus grande que la taille MTU de sortie existante

la MTU existante de l’interface de sortie est utilisée.
Note:

Cette fonctionnalité est prise en charge par les pare-feu SRX Series. Il prend en charge le trafic de transit et le trafic sortant d’un tunnel. Elle s’applique aussi bien au trafic IPv4 qu’IPv6.

Les deux considérations suivantes influent sur la taille des fragments :

  • Pour les applications basées sur des flux, telles que Content Security et ALG, les applications elles-mêmes peuvent modifier ou réassembler des paquets, même si aucun fragment n’a été reçu. Dans ce cas, c’est la MTU de l’interface de sortie existante qui est utilisée.

  • Lorsqu’un paquet de découverte MTU de chemin est livré à une session, la MTU de chemin de cette session est réinitialisée à la valeur établie par le paquet MTU de chemin.

Documentation connexe

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libérer
Description
15.1X49-D100
Configurez le périphérique à l’aide de la set security flow preserve-incoming-frag-size commande pour activer la fonctionnalité qui prend en compte la taille des fragments de paquets entrants.