IDP SSL Inspection
L’inspection SSL IDP permet aux pare-feu SRX Series d’inspecter le trafic HTTP chiffré SSL sur n’importe quel port.
SSL, le prédécesseur de TLS, est une suite de protocoles pour la sécurité Web qui assure l’authentification, la confidentialité et l’intégrité des messages. L’authentification protège contre les transmissions frauduleuses en permettant à un navigateur de valider l’identité d’un serveur Web. Des mécanismes de confidentialité garantissent la confidentialité des communications. SSL applique la confidentialité en cryptant les données afin d’empêcher les utilisateurs non autorisés d’écouter les communications électroniques. Enfin, l’intégrité des messages garantit que le contenu d’une communication n’a pas été altéré.
Pour plus d’informations, consultez les rubriques suivantes :
Présentation d’IDP SSL
Chaque session SSL commence par une négociation au cours de laquelle le client et le serveur se mettent d’accord sur la clé de sécurité spécifique et les algorithmes de chiffrement à utiliser pour cette session. À ce stade, le client authentifie également le serveur. Si vous le souhaitez, le serveur peut authentifier le client. Une fois l’établissement de liaison terminé, le transfert des données chiffrées peut commencer.
Juniper Networks assure l’inspection SSL de détection et prévention d’intrusion (IDP) qui utilise la suite de protocoles SSL composée de différentes versions SSL, chiffrements et méthodes d’échange de clés. Associée à la fonction d’identification des applications, la fonction d’inspection SSL permet aux pare-feu SRX Series d’inspecter le trafic HTTP chiffré en SSL sur n’importe quel port. Les protocoles SSL suivants sont pris en charge :
SSLv2
SSLv3
TLS (en anglais)
Voir aussi
Chiffrements SSL IDP pris en charge
Un chiffrement SSL comprend le chiffrement, la méthode d’authentification et la compression. Junos OS prend en charge tous les chiffrements pris en charge par OPENSSL qui n’impliquent pas l’utilisation de clés privées temporaires. Pour l’authentification, les méthodes d’authentification NULL, MD5 et SHA-1 sont prises en charge.
La compression et les chiffrements SSLv2 ne sont pas pris en charge. Actuellement, la plupart des serveurs SSL passent automatiquement à un chiffrement TLS lorsqu’un chiffrement SSLv2 est reçu dans un message de bonjour du client. Vérifiez votre navigateur pour voir à quel point les chiffrements peuvent être puissants et ceux que votre navigateur prend en charge. (Si le chiffrement ne figure pas dans la liste des chiffrements pris en charge, la session est ignorée pour l’inspection approfondie des paquets.)
Le Tableau 1 présente les algorithmes de chiffrement pris en charge par les pare-feu SRX Series.
| Chiffrement | Type | Exportable Clé Matériel | Expanded Key | Bits Effectifs | Taille IV||
|---|---|---|---|---|---|---|
ZÉRO |
Non |
Ruisseau |
0 |
0 |
0 |
N/A |
DES-CBC-SHA |
Non |
Bloquer |
8 |
8 |
56 |
8 |
DES-CBC3-SHA |
Non |
Bloquer |
24 |
24 |
168 |
8 |
AES128-SHA |
Non |
Bloquer |
16 |
16 |
128 |
16 |
AES256-SHA |
Non |
Bloquer |
32 |
32 |
256 |
16 |
Pour plus d’informations sur les algorithmes de chiffrement, consultez Présentation du VPN IPsec /documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-vpn-overview.html. Le tableau 2 indique les chiffrements SSL pris en charge.
| Valeur des | suites de chiffrement |
|---|---|
TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA |
0x0001 0x0002 0x0009 0x000A 0x002F 0x0035 |
Les chiffrements RC4 et IDEA ne sont pas pris en charge en raison de la disponibilité des licences et de la bibliothèque OPENSSL.
Comprendre l’IDP Internet Key Exchange
Internet Key Exchange (IKE) établit un secret prémaître qui est utilisé pour générer des clés symétriques pour le chiffrement et l’authentification des données en masse. La section F.1.1 de la RFC 2246 définit l’authentification TLS (couche transport security) et les méthodes d’échange de clés. Les trois principales méthodes d’échange sont les suivantes :
RSA : le protocole Rivest-Shamir-Adleman (RSA) est un algorithme d’échange de clés qui régit la façon dont les participants créent des clés symétriques ou un secret utilisé au cours d’une session SSL. L’algorithme d’échange de clés RSA est la méthode la plus couramment utilisée.
DSA : l’algorithme de signature numérique (DSA) ajoute une option d’authentification supplémentaire aux propositions de la phase 1 de l’IKE. Le DSA peut être configuré et se comporte de manière analogue au RSA, obligeant l’utilisateur à importer ou à créer des certificats DSA et à configurer une proposition IKE pour utiliser le DSA. Les certificats numériques sont utilisés pour les signatures RSA, les signatures DSA et la méthode d’authentification basée sur la clé publique RSA dans le protocole IKE.
Diffie-Hellman - Diffie-Hellman (DH) est une méthode d’échange clé qui permet aux participants de produire une valeur secrète partagée. La force de la technique est qu’elle permet aux participants de créer la valeur secrète sur un support non sécurisé sans faire passer la valeur secrète à travers le fil.
Les méthodes d’échange de clés peuvent utiliser une clé de serveur fixe ou temporaire. IDP ne peut récupérer le secret prémaître que si une clé de serveur fixe est utilisée. Pour plus d’informations sur Internet Key Exchange, reportez-vous à la section Éléments de base de la PKI dans Junos OS.
Juniper IDP ne déchiffre pas les sessions SSL qui utilisent l’échange de clés Diffie-Hellman.
Présentation de la gestion des clés cryptographiques IDP
Grâce à la fonctionnalité de déchiffrement SSL (Secure Sockets Layer) de détection et prévention d’intrusion (IDP), les pare-feu SRX Series chargent les clés privées RSA configurées en mémoire et les utilisent pour établir des clés de session SSL afin de déchiffrer les données. L’IDP est tenu de déchiffrer les clés RSA et d’en vérifier l’intégrité avant d’effectuer des opérations normales de chiffrement ou de déchiffrement à l’aide des clés.
L’objectif principal de cette fonctionnalité est de s’assurer que les clés privées RSA utilisées par IDP ne sont pas stockées sous forme de texte brut ou dans un format facilement compréhensible ou utilisable. Les clés sont déchiffrées pour effectuer des opérations normales de chiffrement ou de déchiffrement. Cette fonctionnalité implique également des contrôles de détection d’erreurs lors de la copie des clés d’un emplacement mémoire à un autre, ainsi que l’écrasement du stockage intermédiaire avec des modèles différents lorsque les clés ne sont plus nécessaires.
La set security idp sensor-configuration ssl-inspection key-protection commande CLI configuration permet d’activer cette fonctionnalité.
Comprendre la gestion des clés du serveur SSL IDP et la configuration des stratégies
L’appareil peut prendre en charge jusqu’à 1000 clés privées de serveur. Chaque clé peut avoir jusqu’à 100 serveurs qui l’utilisent. Cette capacité est la même quel que soit le nombre de SPU disponibles sur l’appareil, car chaque SPU doit pouvoir accéder à toutes les clés.
Plusieurs serveurs peuvent partager la même clé privée ; Cependant, un serveur ne peut avoir qu’une seule clé privée. Le déchiffrement SSL est désactivé par défaut. Les clés simples et chiffrées sont prises en charge.
Junos OS ne chiffre pas le fichier de clés SSL.
Vous pouvez définir la valeur du paramètre de délai d’expiration du cache de l’ID de session SSL à l’aide de la set security idp sensor-configuration ssl-inspection session-id-cache-timeout commande. La valeur par défaut du paramètre de délai d’expiration du cache est de 600 secondes.
Configuration d’une inspection SSL IDP (procédure CLI)
Le décodeur SSL est activé par défaut. Si vous devez l’activer manuellement via l’interface de ligne de commande, utilisez la commande CLI suivante.
set security idp sensor-configuration detector protocol-name SSL tunable-name sc_ssl_flags tuneable-value 1
Pour configurer une inspection SSL IDP, utilisez la procédure CLI suivante :
[edit security]
idp {
sensor-configuration {
ssl-inspection {
sessions <number>;
}
}
Le capteur inspecte désormais le trafic pour lequel il dispose d’une paire clé/serveur.
Nombre maximal de sessions prises en charge par SPU : la valeur par défaut est 10 000 et la plage est comprise entre 1 et 100 000. La limite de sessions est par SPU, et elle est la même quel que soit le nombre de SPU sur l’appareil.
Ajout de clés SSL IDP et des serveurs associés
Lorsque vous installez une clé, vous pouvez la protéger par mot de passe et l’associer à un serveur.
Pour installer une clé PEM (Privacy-Enhanced Mail), utilisez la commande CLI suivante :
request security idp ssl-inspection key add key-name file file-path server server-ip password password-string
Dans un cluster SRX Series à deux nœuds, la clé doit être copiée manuellement sur le nœud 0 et le nœud 1 au même emplacement pour que la commande request réussisse.
Vous pouvez également associer la clé à un serveur ultérieurement à l’aide de la commande CLI ajouter un serveur. Un serveur ne peut être associé qu’à une seule clé. Pour associer un serveur à la clé installée, utilisez la commande CLI suivante :
request security idp ssl-inspection key add key-name server server-ip
La longueur maximale du nom de clé est de 32 octets, y compris la terminaison « \0 ».
Suppression des clés SSL IDP et des serveurs associés
Pour supprimer toutes les clés et tous les serveurs, utilisez la commande CLI suivante :
user@host> request security idp ssl-inspection key deleteToutes les clés installées sont supprimées, ainsi que tous les serveurs associés.
Pour supprimer une clé spécifique et tous les serveurs associés à cette clé, utilisez la commande CLI suivante :
user@host> request security idp ssl-inspection key delete <key-name>Supprime la clé spécifiée et tous les serveurs associés à cette clé.
Pour supprimer un seul serveur, utilisez la commande CLI suivante :
user@host> request security idp ssl-inspection key delete <key-name> server <server-ip>
Supprime le serveur spécifié qui est lié à la clé spécifiée.
Affichage des clés SSL IDP et des serveurs associés
-
Pour afficher toutes les clés de serveur installées et le serveur associé, utilisez la commande CLI suivante :
user@host> show security idp ssl-inspection key
Affiche toutes les clés de serveur et les adresses IP liées à ces clés. L’exemple suivant montre la sortie CLI lorsque la
show security idp ssl-inspection keycommande est utilisée :Total SSL keys : 2 SSL server key and ip address : Key : key1, server : 10.1.1.1 Key : key2, server : 10.2.2.2 Key : key2, server : 10.2.2.3 -
Pour afficher les adresses IP liées à une clé spécifique, utilisez la commande CLI suivante :
user@host> show security idp ssl-inspection key <key-name>
Voici un exemple de sortie CLI reçue lors de l’utilisation de la
show security idp ssl-inspection key <key-name>commande :Key : key1, server : 10.1.1.1
Exemple : Configuration de l’IDP lorsque le proxy SSL est activé
Cet exemple décrit comment IDP prend en charge la fonctionnalité d’identification d’application (AppID) lorsque le proxy SSL est activé.
Exigences
Avant de commencer :
Créez des zones. Reportez-vous à la section Exemple : Création de zones de sécurité.
Configurez un carnet d’adresses avec les adresses de la stratégie. Reportez-vous à la section Exemple : Configuration de carnets d’adresses et de jeux d’adresses.
Créez une application (ou un ensemble d’applications) qui indique que la stratégie s’applique au trafic de ce type. Reportez-vous à la section Exemple : Configuration d’applications et d’ensembles d’applications de stratégie de sécurité.
Créez un profil de proxy SSL qui active le proxy SSL au moyen d’une stratégie. Reportez-vous à la section Configuration du proxy de transfert SSL.
Configurez une stratégie IDP en tant que stratégie active.
Aperçu
Cet exemple montre comment configurer IDP dans une règle de stratégie lorsque le proxy SSL est activé.
Configuration
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set security policies from-zone Z_1 to-zone Z_2 policy policy1 match source-address any set security policies from-zone Z_1 to-zone Z_2 policy policy1 match destination-address any set security policies from-zone Z_1 to-zone Z_2 policy policy1 match application junos-https set security policies from-zone Z_1 to-zone Z_2 policy policy1 then permit application-services ssl-proxy profile-name ssl-profile-1 set security policies from-zone Z_1 to-zone Z_2 policy policy1 then permit application-services idp
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.
Dans cet exemple, vous configurez une stratégie de sécurité qui utilise IDP comme service d’application.
Configurez une stratégie pour traiter le trafic avec le profil proxy SSL ssl-profile-1.
[edit security policies from-zone Z_1 to-zone Z_2 policy policy1 user@host# set match source-address any user@host# set match destination-address any user@host# set match application junos-https user@host# set then permit application-services ssl-proxy profile-name ssl-profile-1
Définissez IDP comme le service d’application.
[edit security policies from-zone Z_1 to-zone Z_2 policy policy1 user@host# set then permit application-services idp
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security policies commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
Vérification
Vérifiez que la configuration fonctionne correctement. La vérification dans IDP est similaire à la vérification dans Application Firewall. Reportez-vous à la section Pare-feu applicatif.
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.