Présentation d’IPsec
IPsec est un groupe de protocoles que vous pouvez utiliser pour sécuriser les transmissions entre équipements.
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge IPsec par la plate-forme et la version.
Présentation des associations de sécurité
Pour utiliser les services de sécurité IPsec , vous devez créer des SAentre les hôtes. Une SA est une connexion simplex qui permet à deux hôtes de communiquer entre eux en toute sécurité au moyen d’IPsec. Il existe deux types de SA : manuelle et dynamique.
Les SA manuelles ne nécessitent aucune négociation ; Toutes les valeurs, y compris les clés, sont statiques et spécifiées dans la configuration. Les SA manuelles définissent de manière statique les valeurs, les algorithmes et les clés de l’indice des paramètres de sécurité (SPI) à utiliser, et nécessitent des configurations correspondantes aux deux extrémités du tunnel. Chaque pair doit avoir les mêmes options configurées pour que la communication ait lieu.
Les SA dynamiques nécessitent une configuration supplémentaire. Avec les SA dynamiques, vous configurez d’abord l’IKE , puis l’AS. IKE crée des associations de sécurité dynamiques ; il négocie les SA pour IPsec. La configuration IKE définit les algorithmes et les clés utilisés pour établir la connexion IKE sécurisée avec la passerelle de sécurité homologue. Cette connexion est ensuite utilisée pour convenir dynamiquement des clés et d’autres données utilisées par la SA IPsec dynamique. L’IKE SA est d’abord négociée, puis utilisée pour protéger les négociations qui déterminent les SA IPsec dynamiques.
Configurez des tunnels ou SA au niveau de l’utilisateur, y compris les négociations d’attributs de tunnel et la gestion des clés. Ces tunnels peuvent également être actualisés et terminés sur le même canal sécurisé.
L’implémentation IPsec de Junos OS prend en charge deux modes de sécurité (mode transport et mode tunnel).
Voir aussi
Présentation du protocole de gestion des clés IKE
IKE est un protocole de gestion des clés qui crée des SAdynamiques. il négocie les SA pour IPsec. Une configuration IKE définit les algorithmes et les clés utilisés pour établir une connexion sécurisée avec une passerelle de sécurité homologue.
IKE effectue les opérations suivantes :
Négocie et gère les paramètres IKE et IPsec
Authentifie l’échange sécurisé de clés
Authentification mutuelle des pairs au moyen de secrets partagés (pas de mots de passe) et de clés publiques
Assure la protection de l’identité (en mode principal)
L’IKE se déroule en deux phases. Dans un premier temps, il négocie les attributs de sécurité et établit des secrets partagés pour former l’IKE SA bidirectionnel. Dans un deuxième temps, des SA IPsec entrantes et sortantes sont établies. L’IKE SA sécurise les échanges dans la deuxième phase. IKE génère également du matériel d’incrustation, fournit une confidentialité persistante parfaite et échange des identités.
À partir de la version 14.2 de Junos OS, lorsque vous effectuez une promenade SNMP de l’objet jnxIkeTunnelEntry dans la table jnxIkeTunnelTable, le message d’erreur Request failed: OID not increasing peut être généré. Ce problème ne se produit que lorsque des associations de sécurité IKE (Internet Key Exchange) simultanées sont créées, ce qui se produit lorsque les deux extrémités de la SA lancent des négociations IKE SA en même temps. Lorsqu’une migration MIB SNMP est effectuée pour afficher des SA IKE, l’outil snmpwalk s’attend à ce que les identificateurs d’objet (OID) soient dans l’ordre croissant. Toutefois, dans le cas de SA IKE simultanées, il est possible que les OID de la table SNMP ne soient pas dans l’ordre croissant. Ce comportement se produit parce que les ID de tunnel, qui font partie des OID, sont alloués en fonction de l’initiateur de la SA IKE, qui peut se trouver d’un côté ou de l’autre du tunnel IKE.
Voici un exemple de marche MIB SNMP effectuée sur des SA IKE simultanées :
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
La comparaison d’OID échoue lorsque la marche SNMP est l’ID de tunnel (47885 et 47392). Lors d’une marche SNMP, il n’est pas possible de garantir que les ID de tunnel sont dans l’ordre croissant, car les tunnels peuvent être initiés d’un côté ou de l’autre.
Pour contourner ce problème, la marche MIB SNMP contient une option, -Cc, permettant de désactiver la vérification de l’augmentation des OID. Voici un exemple de marche MIB effectuée sur la table jnxIkeTunnelEntry avec l’option -Cc :
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
Voir aussi
Exigences IPsec pour Junos-FIPS
Dans un environnement Junos-FIPS, les configurations matérielles avec deux moteurs de routagedoivent être configurées pour utiliser IPsec et une instance de routage privée pour toutes les communications entre les moteurs de routage. La communication IPsec entre les moteurs de routage et les PIC FIPS AS II EST ÉGALEMENT REQUISE.
Voir aussi
Présentation d’IPsec
La sécurité IP (IPsec) est un cadre normalisé permettant de sécuriser les communications privées sur les réseaux IP. IPsec offre un moyen sécurisé d’authentifier les expéditeurs et de chiffrer le trafic IP version 4 (IPv4) et version 6 (IPv6) entre les périphériques réseau, tels que les routeurs et les hôtes. IPsec inclut l’intégrité des données, l’authentification de l’expéditeur, la confidentialité des données sources et la protection contre la relecture des données.
Les principaux concepts que vous devez comprendre sont les suivants :
Cartes de ligne compatibles IPsec
Le premier choix que vous devez faire lors de l’implémentation d’IPsec sur un routeur basé sur Junos OS est le type de carte de ligne que vous souhaitez utiliser. Le terme « carte de ligne » comprend les cartes d’interface physiques (PIC), les cartes d’interface modulaires (MIC), les concentrateurs de ports denses (DPC) et les concentrateurs de ports modulaires (MPC). Les cartes de ligne suivantes prennent en charge l’implémentation IPsec.
Reportez-vous à la documentation matérielle spécifique de votre routeur pour déterminer si les cartes de ligne de ce routeur prennent en charge IPsec.
Les cartes de ligne suivantes prennent en charge IPsec :
Le PIC des services de chiffrement (ES) fournit des services de chiffrement et une prise en charge logicielle pour IPsec.
Le PIC Adaptive Services (AS) et le PIC Adaptive Services (AS) II fournissent des services IPsec et d’autres services, tels que la traduction d’adresses réseau (NAT) et un pare-feu dynamique.
Le PIC FIPS (Federal Information Processing Standards) de l’AS II est une version spéciale du PIC AS qui communique en toute sécurité avec le moteur de routage à l’aide d’IPsec interne. Vous devez configurer IPsec sur le PIC FIPS AS II lorsque vous activez le mode FIPS sur le routeur. Pour plus d’informations sur l’implémentation d’IPsec sur un PIC FIPS AS II installé dans un routeur configuré en mode FIPS, reportez-vous au Guide de configuration sécurisée pour les critères communs et Junos-FIPS.
Les PIC multiservices assurent l’accélération matérielle d’un large éventail de services gourmands en traitement de paquets. Ces services comprennent des services IPsec et d’autres services, tels que le pare-feu dynamique, le NAT, IPsec, la détection des anomalies et les services de tunnel.
Les concentrateurs de ports denses multiservices (DPC) fournissent des services IPsec.
Les concentrateurs de ports modulaires multiservices (MS-MPC) prennent en charge les services IPsec.
Les cartes d’interface modulaire multiservices (MS-MIC) prennent en charge les services IPsec.
Les packages du fournisseur d’extension Junos OS, y compris le pack de services IPsec, sont préinstallés et préconfigurés sur les MS-MPC et MS-MIC.
Voir aussi
Algorithmes d’authentification
L’authentification est le processus de vérification de l’identité de l’expéditeur. Les algorithmes d’authentification utilisent une clé partagée pour vérifier l’authenticité des appareils IPsec. Junos OS utilise les algorithmes d’authentification suivants :
Message Digest 5 (MD5) utilise une fonction de hachage unidirectionnelle pour convertir un message de longueur arbitraire en un condensé de message de longueur fixe de 128 bits. En raison du processus de conversion, il est mathématiquement impossible de calculer le message d’origine en le calculant à rebours à partir du résumé du message résultant. De même, une modification d’un seul caractère dans le message entraînera la génération d’un numéro de résumé de message très différent.
Pour vérifier que le message n’a pas été altéré, Junos OS compare le résumé de message calculé avec un résumé de message déchiffré avec une clé partagée. Junos OS utilise la variante du code d’authentification de message haché (HMAC) MD5 qui fournit un niveau supplémentaire de hachage. MD5 peut être utilisé avec l’en-tête d’authentification (AH), la charge utile de sécurité d’encapsulation (ESP) et l’Internet Key Exchange (IKE).
L’algorithme de hachage sécurisé 1 (SHA-1) utilise un algorithme plus puissant que MD5. SHA-1 prend un message de moins de 264 bits et produit un condensé de message de 160 bits. Le récapitulatif volumineux des messages garantit que les données n’ont pas été modifiées et qu’elles proviennent de la bonne source. Junos OS utilise la variante HMAC SHA-1 qui offre un niveau supplémentaire de hachage. SHA-1 peut être utilisé avec AH, ESP et IKE.
SHA-256, SHA-384 et SHA-512 (parfois regroupés sous le nom de SHA-2) sont des variantes de SHA-1 et utilisent des résumés de messages plus longs. Junos OS prend en charge la version SHA-256 de SHA-2, qui peut traiter toutes les versions du chiffrement AES (Advanced Encryption Standard), AES (Data Encryption Standard) et 3DES (Triple DES).
Algorithmes de chiffrement
Le chiffrement encode les données dans un format sécurisé afin qu’elles ne puissent pas être déchiffrées par des utilisateurs non autorisés. À l’instar des algorithmes d’authentification, une clé partagée est utilisée avec des algorithmes de chiffrement pour vérifier l’authenticité des appareils IPsec. Junos OS utilise les algorithmes de chiffrement suivants :
Le chiffrement par blocs de chiffrement standard (DES-CBC) est un algorithme symétrique de blocage de clé secrète. DES utilise une taille de clé de 64 bits, où 8 bits sont utilisés pour la détection des erreurs et les 56 bits restants fournissent le chiffrement. DES effectue une série d’opérations logiques simples sur la clé partagée, y compris des permutations et des substitutions. CBC prend le premier bloc de 64 bits de sortie de DES, combine ce bloc avec le deuxième bloc, le réinjecte dans l’algorithme DES et répète ce processus pour tous les blocs suivants.
Triple DES-CBC (3DES-CBC) est un algorithme de chiffrement similaire à DES-CBC, mais qui fournit un résultat de chiffrement beaucoup plus fort, car il utilise trois clés pour un chiffrement 168 bits (3 x 56 bits). 3DES fonctionne en utilisant la première clé pour chiffrer les blocs, la deuxième clé pour déchiffrer les blocs et la troisième clé pour rechiffrer les blocs.
Advanced Encryption Standard (AES) est une méthode de chiffrement de nouvelle génération basée sur l’algorithme de Rijndael développé par les cryptographes belges Dr. Joan Daemen et Dr. Vincent Rijmen. Il utilise un bloc de 128 bits et trois tailles de clé différentes (128, 192 et 256 bits). En fonction de la taille de la clé, l’algorithme effectue une série de calculs (10, 12 ou 14 tours) qui incluent la substitution d’octets, le mélange de colonnes, le décalage de lignes et l’ajout de clés. L’utilisation d’AES en conjonction avec IPsec est définie dans la RFC 3602, L’algorithme de chiffrement AES-CBC et son utilisation avec IPsec.
À partir de la version 17.3R1 de Junos OS, la norme de chiffrement avancée en mode Galois/compteur (AES-GCM) est prise en charge pour les MS-MPC et MS-MIC. Toutefois, en mode FIPS Junos, AES-GCM n’est pas pris en charge dans Junos OS version 17.3R1. À partir de la version 17.4R1 de Junos OS, AES-GCM est pris en charge en mode FIPS Junos. AES-GCM est un algorithme de chiffrement authentifié conçu pour fournir à la fois l’authentification et la confidentialité. AES-GCM utilise un hachage universel sur un champ de Galois binaire pour fournir un chiffrement authentifié et permet un chiffrement authentifié à des débits de données de plusieurs dizaines de Gbit/s.
Voir aussi
Protocoles IPsec
Les protocoles IPsec déterminent le type d’authentification et de chiffrement appliqué aux paquets sécurisés par le routeur. Junos OS prend en charge les protocoles IPsec suivants :
AH : défini dans la RFC 2402, AH assure l’intégrité sans connexion et l’authentification de l’origine des données pour les paquets IPv4 et IPv6. Il offre également une protection contre les reprises. AH authentifie autant d’en-têtes IP que possible, ainsi que les données de protocole de niveau supérieur. Toutefois, certains champs d’en-tête IP peuvent changer en cours de route. Étant donné que la valeur de ces champs peut ne pas être prévisible par l’expéditeur, ils ne peuvent pas être protégés par AH. Dans un en-tête IP, AH peut être identifié par une valeur de
51dans leProtocolchamp d’un paquet IPv4 et leNext Headerchamp d’un paquet IPv6. La Figure 1 illustre la protection IPsec offerte par AH.Note:AH n’est pas pris en charge sur les routeurs T Series, M120 et M320.
AH
ESP : défini dans la RFC 2406, ESP peut fournir le chiffrement et la confidentialité des flux de trafic limités, ou l’intégrité sans connexion, l’authentification de l’origine des données et un service anti-rejeu. Dans un en-tête IP, ESP peut être identifié une valeur de
50dans leProtocolchamp d’un paquet IPv4 et leNext Headerchamp d’un paquet IPv6. La figure 2 illustre la protection IPsec offerte par ESP.
ESP
Bundle : lorsque vous comparez AH et ESP, les deux protocoles présentent des avantages et des inconvénients. ESP fournit un niveau décent d’authentification et de chiffrement, mais ne le fait que pour une partie du paquet IP. À l’inverse, bien qu’AH ne fournisse pas de chiffrement, il fournit une authentification pour l’ensemble du paquet IP. Pour cette raison, Junos OS propose une troisième forme de protocole IPsec appelée bundle de protocoles. L’option groupée offre une combinaison hybride d’authentification AH et de chiffrement ESP.
Voir aussi
Chiffrements IKE et IPsec pris en charge pour les équipements SRX Series
Utilisez les tableaux suivants pour passer en revue les chiffrements pris en charge sur votre plate-forme SRX Series.
| Chiffrements (IKE) |
SRX1500 |
SRX1600 |
SRX2300, SRX4120 |
SRX4100, SRX4200 et SRX4300 |
SRX4600 et SRX4700 |
SRX5400, SRX5600 et SRX5800 |
|---|---|---|---|---|---|---|
| AES-128-GCM |
Oui |
Oui |
Oui |
Oui |
Oui |
Oui |
| AES-192-GCM |
Non |
Non |
Non |
Non |
Non |
Non |
| AES-256-GCM |
Oui |
Oui |
Oui |
Oui |
Oui |
Oui |
| Chiffrements (IPSec) |
SRX1500 |
SRX1600 |
SRX2300, SRX4120 |
SRX4100, SRX4200 et SRX4300 |
SRX4600 et SRX4700 |
SRX5400, SRX5600 et SRX5800 |
|---|---|---|---|---|---|---|
| AES-128-GCM |
Oui |
Oui |
Oui |
Oui |
Oui |
Oui |
| AES-192-GCM |
Oui |
Oui |
Oui |
Oui |
Oui |
Oui |
| AES-256-GCM |
Oui |
Oui |
Oui |
Oui |
Oui |
Oui |
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.
Request failed: OID not increasing peut être généré.