TCP Sessions
Pour envoyer des données via TCP dans un réseau, nous suivons un processus d’établissement de session d’établissement de liaison à trois voies. Il existe un processus pour démarrer une session, ainsi qu’un processus pour mettre fin à la session TCP. Cette rubrique vous aide à comprendre le processus impliqué dans le traitement d’une session TCP.
Comprendre les contrôles 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 indicateurs d’options TCP, no-sequence-check et no-syn-check, sont disponibles à un 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 des options TCP par stratégie, vous devez désactiver les options globales respectives ; sinon, la vérification de la validation échouera. Si les options TCP globales sont désactivées et que la protection contre le flooding SYN autorise le premier paquet, les options TCP par stratégie contrôleront si les vérifications SYN et/ou de séquence sont effectuées.
L’option par stratégie
syn-check-requiredne remplace pas le comportement de laset security flow tcp-session no-syn-check-in-tunnelcommande CLI.La désactivation du contrôle SYN global réduit l’efficacité de l’appareil à se défendre contre le flooding de paquets.
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. Les opérations du processeur sont ainsi intenses. Lorsque vous désactivez le contrôle SYN global et activez l’application du contrôle 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 les implémentations TCP sont défectueuses.
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.
Vue d’ensemble
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 être 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.
La 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 :
Configurez la vérification du bit TCP SYN avant de créer une session.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options syn-check-required
Configurez la vérification des numéros de séquence dans les segments TCP lors de l’inspection dynamique.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options sequence-check-required
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit] user@host# commit
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 l’appareil.
Exigences
Avant de commencer, comprenez les circonstances de la désactivation des contrôles de sécurité des paquets TCP. .
Vue d’ensemble
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 équipements dont les implémentations TCP sont défectueuses. Lors d’une vérification no-SYN, 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, réduisant ainsi la sécurité. Cela peut être nécessaire dans des scénarios avec des clients tels que de gros fichiers de transfert, ou avec des applications qui ne fonctionnent pas correctement avec les normes.
La 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 la procédure à suivre, consultez Utilisation de l’éditeur CLI en mode Configuration dans le Guide de l’utilisateur de la CLI.
Pour désactiver les contrôles de sécurité des paquets TCP :
Désactivez la vérification du bit TCP SYN avant de créer une session.
[edit security flow] user@host# set tcp-session no-syn-check
Désactivez la vérification des numéros de séquence dans les segments TCP lors de l’inspection dynamique.
[edit security flow] user@host# set tcp-session no-sequence-check
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit ] user@host# commit
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 dans lesquelles la taille de segment maximale est définie.
Vue d’ensemble
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 entrantes 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 d’erreur ICMP de type 3 code 4 au serveur d’applications (Destination inaccessible ; Fragmentation nécessaire et DF défini). Ce message d’erreur ICMP contient le MTU correct (tel que défini dans tcp-mss) à utiliser par le serveur d’applications, qui doit recevoir ce message et ajuster la taille du paquet en conséquence. Cela est particulièrement nécessaire avec les VPN, car IPsec a ajouté une surcharge de paquets ; Ainsi, le TCP-MSS doit être abaissé de manière appropriée.
Lorsque vous exécutez des pare-feu SRX Series en mode paquet, vous utilisez le set system internet-options tcp-mss pour ajuster la valeur TCP-MSS. Tous les ports sont affectés par la configuration TCP-MSS ; Vous ne pouvez pas exclure un port particulier. Lorsque vous exécutez des pare-feu SRX Series en mode flux, bien que vous puissiez utiliser le set system internet-options tcp-mss , nous vous recommandons d’utiliser uniquement le set security flow tcp-mss pour ajuster la valeur TCP-MSS. Si les deux instructions sont configurées, la plus faible des deux valeurs prendra effet.
La configuration
Procédure
Procédure étape par étape
Pour configurer la taille maximale de segment pour toutes les sessions TCP :
Définissez la taille maximale du segment TCP pour toutes les sessions TCP.
[edit security flow] user@host# set tcp-mss all-tcp mss 1300
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit ] user@host# commit
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, cette show sortie de commande inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).
[edit]
user@host# show security flow
...
tcp-mss{
all-tcp{
mss 1300;
}
}
...
Vérification
Pour vérifier que la configuration fonctionne correctement, entrez la show configuration security flow commande en mode opérationnel.
user@host> show configuration security flow
tcp-mss{
all-tcp{
mss 1300;
}
}
Présentation de la journalisation des pertes de paquets TCP hors de l’é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 toutes les mesures correctives nécessaires pour maintenir des communications de bout en bout sans erreur.
Les modules de flux prennent déjà en charge la génération de RTLOG pour les événements basés sur des 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 les paquets tels que la perte de paquets sans session existante.
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é de journalisation TCP des pertes de paquets hors de l’état évite toute perte de paquets et permet la récupération des paquets en enregistrant 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é repose sur la fonctionnalité de journal de sécurité (RTLOG).
La journalisation TCP des pertes de paquets hors de l’état prend en charge la capture des journaux de perte 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 expirée, les paquets TCP sont perdus. Cette fonctionnalité prend en charge la journalisation de ces paquets TCP perdus.
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 visible sur un site, mais les paquets d’accusé de réception de synchronisation (SYN_ACK) sont visibles sur un autre site.
Cela signifie que le pare-feu SRX Series détecte 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).
Les paquets SYN_ACK détectés sur un autre site dans ce cas 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 en état de fermeture TCP à quatre voies mais reçoit des paquets SYN, ou s’il y a une défaillance d’établissement de liaison à trois voies, le pare-feu SRX Series abandonne les paquets TCP et ces paquets perdus sont enregistrés.
Le journal TCP non synchronisé de perte de paquets hors état est un journal basé sur les paquets et non sur la session.
La journalisation TCP des pertes de paquets hors de l’état est conçue avec un mécanisme d’étranglement pour protéger le processeur contre les attaques. À chaque intervalle d’accélération, des journaux peuvent être supprimés.
Seuls les paquets TCP hors état abandonnés par le module Flow sont enregistrés. Les paquets TCP abandonnés par TCP-proxy et IDP ne sont pas journalisés.
- Comprendre la journalisation des pertes de paquets TCP hors de l’état
- Fonctionnalités de journalisation TCP hors état prises en charge
Comprendre la journalisation des pertes de paquets TCP hors de l’état
Pour comprendre l’implémentation de la journalisation TCP des pertes de paquets 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 visible sur un site et le paquet SYN_ACK est visible sur un autre site. Dans ce cas, le paquet SYN_ACK serait refusé mais pas enregistré. La fonctionnalité TCP de journalisation des pertes de paquets hors état offre une visibilité sur ces pertes de paquets non synchronisées.
Prenons l’exemple d’un datacenter dans lequel les bases de données du datacenter conservent leurs sockets TCP ouverts, sans qu’aucun keepalive ne soit envoyé. Si aucune donnée n’est transmise, le pare-feu SRX Series expire les sessions. Bien que les bases de données envoient des données via ce socket TCP, lorsque le trafic atteint le pare-feu SRX Series, la session n’est plus là et le paquet est abandonné, mais pas journalisé. Ces paquets TCP hors de l’état qui sont supprimés sont maintenant enregistrés par le pare-feu SRX Series.
Fonctionnalités de journalisation TCP hors état prises en charge
La journalisation TCP hors de l’état prend en charge les fonctionnalités suivantes :
Un composant de filtre de paquets pour filtrer le trafic cible.
Composant de limitation pour protéger le processeur contre la surcharge par les messages de journal.
Flexibilité pour modifier le taux de génération des journaux.
- Composant de filtre de paquets
- Composant d’accélérateur
- Flexibilité de modification du taux de génération des journaux
Composant de filtre de paquets
Le filtre de journalisation exploite le filtre de suivi de flux actuel. Il fournit différentes façons de filtrer le trafic. Vous devez configurer les filtres pour générer des journaux de paquets, sinon les journaux ne seront pas déclenchés.
Cette fonctionnalité de filtrage évite d’activer les journaux de manière inattendue. Le nombre maximum 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 que vous souhaitez.
Composant d’accélérateur
La journalisation de chaque paquet TCP hors de l’état peut surcharger l’appareil en cas de trafic intense ou d’attaque. Si le processeur est inactif et que vous souhaitez enregistrer autant de messages que possible, cela peut entraîner une surcharge du processeur.
Le mécanisme d’accélération vous permet de configurer l’intervalle d’accélération à partir de la CLI, afin de 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.
Dans chaque intervalle d’accélération, 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ération n’est impliqué. Cela convient aux scénarios où le trafic est très faible et où vous souhaitez enregistrer tous les journaux de perte de paquets.
La configuration de l’intervalle d’accélération sur 2^N rend le mécanisme d’accélérateur sans verrouillage et offre de bonnes performances de capture de journaux.
Flexibilité de modification du 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’à chaque intervalle de 32 millisecondes (ms), un nombre limité de journaux peut être généré et que le reste peut être supprimé. Nous vous recommandons de configurer l’intervalle comme (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 liés à l’utilisation 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 économisées lorsque les paquets de 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’aucune liaison du 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ésultants doit contenir des informations d’en-tête de paquet, en plus de la charge utile ou des données. L’augmentation de la charge 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 nœud de destination, ce qui consomme des ressources réseau supplémentaires.
D’autre part, des ressources réseau sont gaspillées lorsqu’un hôte envoie des paquets beaucoup plus petits que le chemin MTU (path Maximum Transmission Unit), ce qui entraîne un débit sous-optimal. Le processus de découverte de la MTU de chemin permet de déterminer la taille optimale de la MTU 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 du paquet est donc celle du chemin MTU. La fragmentation se produit lorsque la taille d’un paquet dépasse la MTU du chemin.
Si des services de couche applicative sont configurés sur le pare-feu SRX Series, les fragments de paquets à l’interface entrante doivent être réassemblés avant de pouvoir appliquer les services et inspecter le contenu. Ces fragments de paquets réassemblés doivent être décomposés à nouveau avant que les données ne soient transmises hors de l’interface de sortie. Normalement, c’est la taille de la 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 taille du MTU de sortie sur le pare-feu SRX Series soit supérieure au chemin MTU, ce qui, là encore, entraînerait une fragmentation de paquets dans le chemin de données, réduisant les performances ou provoquant une perte de paquets. Les fragments de paquets doivent être suffisamment petits pour transiter par chaque lien du chemin source à destination.
Par défaut, le pare-feu SRX Series utilise la taille de MTU configurée pour l’interface de sortie afin de déterminer la taille des fragments de paquet qu’il transmet. Toutefois, si vous activez la fonctionnalité de conservation 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, les pare-feu SRX Series suivent et ajustent la MTU de sortie pour ce flux. Il identifie la taille maximale de tous les fragments entrants. Il utilise ces informations conjointement avec les MTU existantes de l’interface de sortie pour déterminer la taille de MTU correcte pour les paquets fragmentés envoyés par 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 de la MTU de l’interface de sortie.
Configurez l’appareil à 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 la MTU de sortie de SRX Series est déterminée.
Taille du fragment entrant |
Taille de la MTU de sortie existante |
Taille finale de la MTU de sortie |
|---|---|---|
Si le fragment le plus volumineux est |
plus petite que la taille de la MTU de sortie existante |
La plus grande taille de fragment entrant est utilisée. |
Si le fragment le plus volumineux est |
supérieure à la taille de la MTU de sortie existante |
L’interface de sortie existante MTU est utilisée. |
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 affectent la taille des fragments :
Pour les applications basées sur les flux, telles que Content Sécurité et ALG, les applications elles-mêmes peuvent modifier ou réassembler les paquets même en l’absence de fragments. Dans ce cas, l’interface de sortie existante MTU est utilisée.
Lorsqu’un paquet de découverte de chemin MTU est livré à une session, le chemin d’accès à la MTU de cette session est réinitialisé à la valeur établie par le paquet de chemin MTU.
Court-circuit de proxy TCP
Le court-circuit du proxy TCP est activé par défaut sur votre appareil. Il se déclenche automatiquement lorsqu’aucun utilisateur (plugins d’application de politique L7/services d’application avancés) n’est intéressé par l’utilisation du proxy TCP pour la session. Une fois la session TCP établie et appliquée avec stratégie, l’équipement fait passer la session à un état court-circuité, ce qui permet aux paquets de données suivants de circuler directement entre le client et le serveur.
Pendant la phase d’établissement de liaison initiale, l’appareil conserve un comportement de proxy TCP complet, gérant indépendamment l’état TCP, les numéros de séquence et les accusés de réception des deux côtés de la connexion. Une fois la légitime et la stabilité de la session vérifiée, l’équipement n’envoie plus de proxy aux numéros de séquence ou aux retransmissions pour le trafic de données. Au lieu de cela, il transfère directement les paquets tout en continuant à surveiller la session pour détecter la conformité aux politiques et les violations de sécurité.
Le court-circuit de proxy TCP convient aux déploiements qui nécessitent une sécurité et une validation TCP fortes sans la surcharge de performances à long terme d’un proxy TCP complet. Elle est particulièrement efficace dans les environnements à haut débit tels que les centres de données, les périphéries des fournisseurs de services et les réseaux de grandes entreprises.
Avantages du court-circuit du proxy TCP
-
Équilibre entre sécurité et performances
-
Réduction de la surcharge de traitement et de la latence pour le trafic de données.
-
Préservez l’application des politiques en maintenant les contrôles de sécurité des stratégies, le suivi des sessions et la surveillance, même après un court-circuit de connexion.
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.
set security flow preserve-incoming-frag-size commande pour activer la fonctionnalité qui prend en compte la taille des fragments de paquets entrants.