Prise en charge des politiques unifiées pour les flux
À partir de la version 18.2R1 de Junos OS, des politiques unifiées sont prises en charge sur les pare-feu SRX Series, ce qui permet un contrôle et une application granulaires des applications dynamiques de couche 7 dans le cadre de la stratégie de sécurité. Les stratégies unifiées sont les stratégies de sécurité qui vous permettent d’utiliser des applications dynamiques comme conditions de correspondance dans le cadre des conditions de correspondance à 5 ou 6 uplets (5 uplets avec pare-feu utilisateur) existantes pour détecter les changements d’application au fil du temps.
Les stratégies unifiées vous permettent d’utiliser une application dynamique comme critère de correspondance de stratégie dans l’application. Lors de l’application de l’identification d’application (AppID) au trafic, l’AppID vérifie plusieurs paquets et identifie l’application. Une fois l’application identifiée, la politique finale est appliquée à la session. Les actions de stratégie telles que autoriser, refuser, rejeter ou rediriger sont appliquées au trafic conformément à la stratégie.
Au cours de la phase de recherche de stratégie initiale, qui a lieu avant l’identification d’une application dynamique, s’il existe plusieurs stratégies dans la liste de stratégies potentielles, le pare-feu SRX Series applique la stratégie de sécurité par défaut jusqu’à ce qu’une correspondance plus explicite se soit produite. La politique qui correspond le mieux à la demande est la politique finale.
Pour plus d’informations sur les stratégies unifiées, consultez [Stratégies de sécurité unifiées, Prise en charge de l’identification des applications pour les stratégies unifiées et Présentation de la prise en charge des stratégies IDP pour les stratégies unifiées.]
Chemin d’accès axé sur le flux pour des politiques unifiées
Lorsque l’appareil examine le premier paquet d’un flux, il détermine la stratégie de sécurité correspondante et effectue une recherche de stratégie de sécurité. Au cours de ce processus, les cas suivants sont observés :
Si le trafic correspond à une stratégie de sécurité héritée ou à la politique finale, la session est créée.
S’il existe plusieurs stratégies dans la liste de stratégies potentielles et qu’il existe un conflit de stratégie de sécurité, la stratégie de sécurité par défaut est appliquée.
S’il existe plusieurs stratégies dans la liste des stratégies potentielles et que l’action de stratégie n’autorise pas le trafic, la session est fermée. Un message de journal est généré pour indiquer la raison de la fermeture de la session. La stratégie de sécurité par défaut est requise pendant la phase de conflit de stratégie, car chaque stratégie de la liste des stratégies potentielles a des valeurs de configuration différentes pour MSS, la vérification TCP SYN, l’intervalle de délai d’expiration de session, etc. Dans ce cas, lorsque la stratégie de sécurité par défaut est appliquée, toutes les valeurs configurées dans cette stratégie sont appliquées. Lorsqu’une stratégie de sécurité par défaut est mise en correspondance, les actions de stratégie sont appliquées à la session.
-
La stratégie de sécurité par défaut est définie par le système. Cette politique ne peut pas être supprimée.
-
La stratégie par défaut est créée à chaque niveau du système logique, de la même manière que la stratégie globale par défaut.
-
Les valeurs de l’intervalle de délai d’expiration de la session et du journal de session sont exploitées à partir de la stratégie de sécurité par défaut, tandis que les valeurs par défaut telles que TCP-MSS et TCP SYN sont exploitées à partir de la configuration du flux.
-
Lorsqu’une stratégie par défaut est appliquée, des métadonnées potentielles pour l’action de stratégie sont allouées. Les métadonnées potentielles sont mises à jour en fonction de la liste des stratégies potentielles.
-
Le fait de disposer d’une stratégie de sécurité par défaut permet de résoudre les problèmes dans la liste des stratégies potentielles.
-
Il peut y avoir plusieurs sessions correspondant à la stratégie de sécurité par défaut ; Toutefois, les services applicatifs définis dans la stratégie pour le trafic autorisé peuvent être différents. Les informations de flux de sécurité de chaque session sont enregistrées.
-
Lorsqu’un pare-feu SRX Series fonctionne en mode cluster de châssis, les informations sont synchronisées du nœud principal vers le nœud secondaire, ainsi que la session de flux et les objets en temps réel (RTO) du cluster de châssis.
-
Lorsque l’application finale est identifiée, la stratégie de sécurité correspondant à l’application finale est appliquée. Les paquets suivants sont traités conformément à la politique finale.
Comprendre le chemin d’écoulement rapide
Une fois que le premier paquet d’un flux a traversé l’équipement et qu’une session a été établie pour celui-ci, il subit un traitement rapide du chemin. Lorsque l’appareil examine une session de flux de sécurité avec la stratégie par défaut, il effectue une recherche de stratégie de sécurité et les cas suivants sont observés :
Si l’identification d’application existante nécessite une mise à jour, le processus de recherche de stratégie est répété. Le processus est répété jusqu’à ce qu’une stratégie explicite soit renvoyée et remplacée dans la session de flux de sécurité. Si une stratégie implicite est renvoyée, le trafic est refusé et la session est fermée.
Lorsque l’application finale est identifiée, la stratégie finale correspondant au trafic est appliquée. Si les actions de stratégie par défaut et la stratégie finale sont similaires, la stratégie finale remplace la stratégie par défaut dans la session de flux de sécurité. Si les actions de stratégie par défaut et la stratégie finale sont différentes, la stratégie par défaut est conservée et la session de flux de sécurité est fermée.
Remarque :Lorsque la stratégie finale et la stratégie par défaut avec une action de refus sont mises en correspondance, la session de flux de sécurité est fermée.
Pour mettre à jour une session, nous utilisons la configuration du délai d’expiration, du journal ou du compteur de session dans la stratégie finale.
Configuration du journal de session pour la stratégie de sécurité par défaut
La stratégie de sécurité par défaut est requise pour gérer les conflits de stratégies dans la liste de stratégies potentielles. Vous pouvez définir les journaux de session pour les sessions requises dans les configurations de stratégie de sécurité par défaut :
Vous pouvez activer la journalisation à la fin et au début d’une session à l’aide des commandes suivantes :
Nous vous recommandons d’activer la journalisation de clôture de session dans la politique par défaut pre-id. Cela garantit que les journaux de sécurité sont générés par le SRX si un flux ne parvient pas à quitter la pré-id-default-policy. Ces événements sont généralement dus à l’incapacité de classer correctement le trafic grâce à l’inspection approfondie des paquets (JDPI) de Juniper Networks. Les événements peuvent également indiquer des tentatives potentielles d’échapper au moteur d’identification des applications (AppID).
Configuration du délai d’expiration de la session pour la stratégie de Sécurité par défaut
Vous pouvez définir le délai d’expiration des sessions requises dans les configurations de stratégie de sécurité par défaut. Vous pouvez spécifier les valeurs de délai d’expiration pour les sessions UDP, TCP, ICMP et ICMP6 à l’aide de la set security policies pre-id-default-policy then session-timeout commande :
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.