Sur cette page
Authentification IKE (authentification basée sur des certificats)
Configurer plusieurs types de certificats pour établir IKE et IPsec SA
Exemple : Configuration d’un équipement pour la validation de la chaîne de certificats homologues
Politique IKE avec une autorité de certification de confiance
Configuration d’un répondeur de tunnel d’établissement uniquement dans IKE
Comportement du répondeur IKEv2 spécifique à la plate-forme uniquement
IKE pour VPN IPsec
En savoir plus sur IKEv2 pour VPN IPsec et sa configuration dans Junos OS.
Internet Key Exchange version 2 (IKEv2) est un protocole de tunnelisation basé sur IPsec. IKEv2 fournit un canal de communication VPN sécurisé entre les périphériques VPN homologues et définit la négociation et l’authentification des associations de sécurité (SA) IPsec de manière protégée.
Utilisez l’Explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Consultez la Comportement du répondeur IKEv2 spécifique à la plate-forme uniquement section pour les notes relatives à votre plate-forme.
Traitement des paquets IKE et IPsec
IKE assure la gestion des tunnels pour IPsec et authentifie les entités finales. IKE effectue un échange de clés Diffie-Hellman (DH) pour générer un tunnel IPsec entre les périphériques réseau. Les tunnels IPsec générés par IKE sont utilisés pour chiffrer, déchiffrer et authentifier le trafic utilisateur entre les périphériques réseau au niveau de la couche IP.
Traitement des paquets IKE
Lorsqu’un paquet en texte clair arrive sur un équipement Juniper Networks nécessitant un tunneling et qu’il n’existe pas de SA Phase 2 active pour ce tunnel, Junos OS entame des négociations IKE et abandonne le paquet. Les adresses source et de destination dans l’en-tête du paquet IP sont respectivement celles des passerelles IKE locales et distantes. Dans la charge utile du paquet IP, un segment UDP encapsule un paquet ISAKMP (IKE). Le format des paquets IKE est le même pour la phase 1 et la phase 2. Reportez-vous à la section Figure 1.
Pendant ce temps, l’hôte source a renvoyé le paquet abandonné. En règle générale, lorsque le deuxième paquet arrive, les négociations IKE sont terminées et Junos OS protège le paquet et tous les paquets suivants de la session avec IPsec avant de le transférer.
Le champ Charge utile suivante contient un nombre indiquant l’un des types de charge utile suivants :
-
0002 : la charge utile de négociation SA contient une définition pour une SA de phase 1 ou de phase 2.
-
0004 : la charge utile de la proposition peut être une proposition de phase 1 ou de phase 2.
-
0008 : la charge utile de transformation est encapsulée dans une charge utile de proposition qui est encapsulée dans une charge utile SA.
-
0010 : la charge utile d’échange de clés (KE) contient les informations nécessaires à l’exécution d’un échange de clés, telles qu’une valeur publique DH.
-
0020 : charge utile d’identification (IDx).
-
Dans la phase 1, IDii indique l’ID de l’initiateur et IDir indique l’ID du répondeur.
-
Dans la phase 2, IDui indique l’initiateur utilisateur et IDur indique l’utilisateur répondeur.
Les ID sont des types d’ID IKE tels que FQDN, U-FQDN, adresse IP, etc. ASN.1_DN.
-
-
0040 : charge utile de certificat (CERT).
-
0080 : charge utile de demande de certificat (CERT_REQ).
-
0100—La charge utile de hachage (HASH) contient la sortie de synthèse d’une fonction de hachage particulière.
-
0200—La charge utile Signature (SIG) contient une signature numérique.
-
0400 : la charge utile Nonce (Nx) contient des informations pseudo-aléatoires nécessaires à l’échange).
-
0800 : notifier la charge utile.
-
1000—ISAKMP Supprimer la charge utile.
-
2000 : la charge utile ID fournisseur (VID) peut être incluse n’importe où dans les négociations de phase 1. Junos OS l’utilise pour marquer la prise en charge de NAT-T.
Chaque charge utile ISAKMP commence par le même en-tête générique, comme illustré à la .Figure 2
Il peut y avoir plusieurs charges utiles ISAKMP enchaînées, chaque type de charge utile suivant étant indiqué par la valeur du champ En-tête suivant. La valeur de 0000 indique la dernière charge utile ISAKMP. Voir Figure 3 pour un exemple.
Traitement IPsec des paquets
Une fois les négociations IKE terminées et les deux passerelles IKE ayant établi les SA de phase 1 et de phase 2, tous les paquets suivants sont transférés via le tunnel. Si la SA de phase 2 spécifie l’ESP (Encapsulating Security Protocol) en mode tunnel, le paquet ressemble à celui illustré à Figure 4. L’équipement ajoute deux en-têtes supplémentaires au paquet d’origine envoyé par l’hôte initial.
Comme illustré à Figure 4la , le paquet construit par l’hôte initiateur comprend la charge utile, l’en-tête TCP et l’en-tête IP interne (IP1).
L’en-tête IP du routeur (IP2), ajouté par Junos OS, contient l’adresse IP de la passerelle distante comme adresse IP de destination et l’adresse IP du routeur local comme adresse IP source. Junos OS ajoute également un en-tête ESP entre les en-têtes IP externe et interne. L’en-tête ESP contient des informations qui permettent à l’homologue distant de traiter correctement le paquet lorsqu’il le reçoit. Reportez-vous à la section Figure 5.
Le champ En-tête suivant indique le type de données dans le champ de charge utile. En mode tunnel, cette valeur est 4, ce qui indique qu’un paquet IP est contenu dans la charge utile. Reportez-vous à la section Figure 6.
Présentation d’IKE dans Junos OS
IKE permet d’échanger des clés de chiffrement et d’authentification en toute sécurité sur un support non sécurisé tel qu’Internet. IKE permet à une paire de passerelles de sécurité de : Établissez de façon dynamique un tunnel sécurisé sur lequel les passerelles de sécurité peuvent échanger des informations de tunnel et des informations clés. Configurez des tunnels ou des 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 au-dessus du même canal sécurisé. IKE utilise les méthodes Diffie-Hellman et est facultatif dans IPsec (les clés partagées peuvent être saisies manuellement au niveau des points de terminaison).
IKEv2 inclut la prise en charge des éléments suivants :
VPN basés sur le routage.
VPN de site à site.
Détection des pairs morts.
Cluster de châssis.
Authentification par clé pré-partagée.
Authentification basée sur les certificats.
SA enfants. Une SA enfant IKEv2 est connue sous le nom de SA de phase 2 dans IKEv1. Dans IKEv2, une SA enfant ne peut pas exister sans la SA IKE sous-jacente.
AutoVPN.
VPN de point de terminaison dynamique.
EAP est pris en charge pour l’accès à distance à l’aide d’IKEv2.
Sélecteurs de trafic.
IKEv2 ne prend pas en charge les fonctionnalités suivantes :
VPN basé sur des stratégies.
Surveillance VPN.
IPComp (IP Payload Compression Protocol).
- Configuration de IKEv2 dans Junos OS
- Comprendre la charge utile de configuration IKEv2
- Comprendre le provisionnement de Pico Cell
Configuration de IKEv2 dans Junos OS
Un homologue VPN est configuré en tant que IKEv1 ou IKEv2. Lorsqu’un homologue est configuré en tant que IKEv2, il ne peut pas revenir à IKEv1 si son homologue distant initie la négociation IKEv1. Par défaut, les équipements de sécurité Juniper Networks sont des homologues IKEv1.
Utilisez l’instruction version v2-only de configuration au niveau de la hiérarchie [edit security ike gateway gw-name] pour configurer IKEv2.
La version IKE s’affiche dans la sortie des commandes opérationnelles et show security ike security-associationsshow security ipsec security-associations CLI.
Les équipements Juniper Networks prennent en charge jusqu’à quatre propositions pour les négociations de Phase 2, ce qui vous permet de définir le degré de restriction d’une plage de paramètres de tunnel que vous acceptez. Junos OS fournit des jeux prédéfinis de propositions de phase 2 standard, compatibles et de base. Vous pouvez également définir des propositions de phase 2 personnalisées.
Comprendre la charge utile de configuration IKEv2
La charge utile de configuration est une option IKEv2 (Internet Key Exchange version 2) proposée pour propager les informations de provisionnement d’un répondeur à un initiateur. La charge utile de configuration IKEv2 est prise en charge uniquement avec les VPN basés sur le routage.
La RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), définit 15 attributs de configuration différents qui peuvent être renvoyés à l’initiateur par le répondeur. Tableau 1 décrit les attributs de configuration IKEv2 pris en charge sur les pare-feu SRX Series.
|
Type d’attribut |
Valeur |
Description |
Longueur |
|---|---|---|---|
|
INTERNAL_IP4_ADDRESS |
1 |
Spécifie une adresse sur le réseau interne. Plusieurs adresses internes peuvent être demandées. Le répondant peut envoyer jusqu’au nombre d’adresses demandées. |
0 ou 4 octets |
|
INTERNAL_IP4_NETMASK |
2 |
Spécifie la valeur du masque de réseau du réseau interne. Une seule valeur de masque de réseau est autorisée dans les messages de requête et de réponse (par exemple, 255.255.255.0) et elle doit être utilisée uniquement avec un attribut INTERNAL_IP4_ADDRESS. |
0 ou 4 octets |
|
INTERNAL_IP4_DNS |
3 |
Spécifie l’adresse d’un serveur DNS au sein du réseau. Plusieurs serveurs DNS peuvent être demandés. Le répondeur peut répondre avec zéro ou plusieurs attributs de serveur DNS. |
0 ou 4 octets |
|
INTERNAL_IP4_NBNS |
4 |
Spécifie l’adresse d’un serveur de noms NetBIOS (NBNS), par exemple un serveur WINS, au sein du réseau. Plusieurs serveurs NBNS peuvent être demandés. Le répondeur peut répondre avec zéro ou plusieurs attributs de serveur NBNS. |
0 ou 4 octets |
| INTERNAL_IP6_ADDRESS |
8 |
Spécifie une adresse sur le réseau interne. Plusieurs adresses internes peuvent être demandées. Le répondant peut envoyer jusqu’au nombre d’adresses demandées. |
0 ou 17 octets |
| INTERNAL_IP6_DNS |
10 |
Spécifie l’adresse d’un serveur DNS au sein du réseau. Plusieurs serveurs DNS peuvent être demandés. Le répondeur peut répondre avec zéro ou plusieurs attributs de serveur DNS. |
0 ou 16 octets |
Pour que le répondeur IKE fournisse des informations de provisionnement à l’initiateur, il doit acquérir ces informations à partir d’une source spécifiée, telle qu’un serveur RADIUS. Les informations de provisionnement peuvent également être renvoyées à partir d’un serveur DHCP via un serveur RADIUS. Sur le serveur RADIUS, les informations utilisateur ne doivent pas inclure de mot de passe d’authentification. Le profil de serveur RADIUS est lié à la passerelle IKE à l’aide de la aaa access-profile profile-name configuration au niveau de la hiérarchie [edit security ike gateway gateway-name].
Junos OS a amélioré la charge utile de configuration IKEv2 pour prendre en charge les fonctionnalitéssuivantes :
-
Prise en charge des pools d’adresses locales IPv4 et IPv6. Vous pouvez également attribuer une adresse IP fixe à un pair.
Lors de l’établissement d’un IKE, l’initiateur demande une adresse IPv4, une adresse IPv6, une adresse DNS ou une adresse WINS au répondeur. Une fois que le répondant a authentifié l’initiateur, il attribue une adresse IP à partir d’un pool d’adresses local ou via un serveur RADIUS. Selon la configuration, cette adresse IP est attribuée de manière dynamique à chaque connexion d’un homologue ou en tant qu’adresse IP fixe. Si le serveur RADIUS répond avec un pool tramé, Junos OS attribue une adresse IP ou des informations basées sur la configuration du pool local correspondant. Si vous configurez à la fois le pool d’adresses local et le serveur RADIUS, l’adresse IP allouée par le serveur RADIUS est prioritaire sur le pool local. Si vous configurez un pool d’adresses IP local et que le serveur RADIUS n’a renvoyé aucune adresse IP, le pool local attribue l’adresse IP à la demande.
-
Option supplémentaire,
noneintroduite pourauthentication-order. Reportez-vous à la section Ordre d’authentification (profil d’accès). -
Les messages de début et d’arrêt de la comptabilité RADIUS informent de l’état du tunnel ou de l’homologue au serveur RADIUS. Ces messages peuvent être utilisés à des fins de suivi ou de notification à des sous-systèmes tels qu’un serveur DHCP.
Assurez-vous que le serveur RADIUS prend en charge la comptabilisation des messages de démarrage ou d’arrêt. Assurez-vous également que les pare-feu SRX Series et le serveur RADIUS disposent des paramètres appropriés pour suivre ces messages.
-
L’introduction de la prise en charge d’IPv6 permet la mise en place de tunnels à double pile à l’aide de la charge utile de configuration. Pendant le processus de connexion, requêtes IKE pour les adresses IPv4 et IPv6. AAA n’autorise la connexion que si toutes les adresses demandées ont été attribuées avec succès. IKE met fin à la négociation si l’adresse IP demandée n’est pas allouée.
Dans un VPN basé sur le routage, les interfaces de tunnel sécurisé (st0) fonctionnent en mode point à multipoint ou point à point. L’attribution d’adresses via la charge utile de configuration IKEv2 est désormais prise en charge pour le mode point à multipoint ou point à point. Pour les interfaces point à multipoint, les interfaces doivent être numérotées et les adresses de la charge utile de configuration INTERNAL_IP4_ADDRESS le type d’attribut doivent se trouver dans la plage de sous-réseaux de l’interface point à multipoint associée.
Vouspouvez configurer un mot de passe commun pour les demandes de charge utile de configuration IKEv2 pour une configuration de passerelle IKE. Le mot de passe commun compris entre 1 et 128 caractères permet à l’administrateur de définir un mot de passe commun. Ce mot de passe est utilisé entre le pare-feu SRX Series et le serveur RADIUS lorsque le pare-feu SRX Series demande une adresse IP au nom d’un homologue IPsec distant à l’aide de la charge utile de configuration IKEv2. Le serveur RADIUS fait correspondre les informations d’identification avant de fournir des informations IP au pare-feu SRX Series pour la demande de charge utile de configuration. Vous pouvez configurer le mot de passe commun à l’aide de l’instruction config-payload-password configured-password de configuration au niveau de la hiérarchie [edit security ike gateway gateway-name aaa access-profile access-profile-name].
Le pare-feu SRX Series et le serveur RADIUS doivent avoir le même mot de passe configuré et le serveur RADIUS doit être configuré pour utiliser le protocole PAP (Password Authentication Protocol) comme protocole d’authentification. Sans cela, la mise en place de tunnels ne sera pas couronnée de succès.
Figure 7 affiche un flux de travail typique pour une charge utile de configuration IKEv2.
La fonctionnalité de charge utile de configuration IKEv2 est prise en charge pour les interfaces de tunnel sécurisé point à multipoint (st0) et les interfaces point à point. Les interfaces point à multipoint doivent être numérotées et les adresses fournies dans l’entité de configuration doivent se trouver dans la plage de sous-réseau de l’interface point à multipoint associée.
Comprendre le provisionnement de Pico Cell
La charge utile de configuration IKEv2 peut être utilisée pour propager des informations de provisionnement à partir d’un répondeur IKE, tel qu’un pare-feu SRX Series, vers plusieurs initiateurs, tels que des stations de base de cellules picocellulaires LTE dans un réseau cellulaire. Les pico cellules sont livrées en usine avec une configuration standard qui leur permet de se connecter au pare-feu SRX Series, mais les informations de provisionnement des pico cellules sont stockées sur un ou plusieurs serveurs de provisionnement au sein d’un réseau protégé. Les cellules pico reçoivent des informations d’approvisionnement complètes après avoir établi des connexions sécurisées avec les serveurs d’approvisionnement.
Le flux de travail nécessaire pour amorcer et provisionner une cellule pico et la mettre en service comprend quatre étapes distinctes :
-
Acquisition initiale des adresses : la picocellule est expédiée de l’usine avec les informations suivantes :
-
Configuration du tunnel de passerelle sécurisée vers le pare-feu SRX Series
-
Certificat numérique délivré par le fabricant
-
Nom de domaine complet (FQDN) des serveurs d’approvisionnement qui se trouvent dans le réseau protégé
La cellule pico démarre et acquiert une adresse à utiliser pour la négociation IKE à partir d’un serveur DHCP. Un tunnel est ensuite construit vers la passerelle sécurisée sur le pare-feu SRX Series à l’aide de cette adresse. Une adresse pour le trafic d’exploitation, d’administration et de gestion (OAM) est également attribuée par le serveur DHCP pour une utilisation sur le réseau protégé.
-
Provisionnement de la cellule Pico : à l’aide de l’adresse de trafic OAM qui lui est attribuée, la cellule pico demande ses informations de provisionnement (généralement un certificat d’opérateur, une licence, un logiciel et des informations de configuration) aux serveurs du réseau protégé.
Redémarrer : la cellule pico redémarre et utilise les informations de provisionnement acquises pour les rendre spécifiques au réseau et au modèle d’exploitation du fournisseur de services.
-
Fourniture de services : lorsque la cellule pico entre en service, elle utilise un certificat unique qui contient des valeurs de nom distinctif (DN) et de nom de sujet alternatif avec un nom de domaine complet pour construire deux tunnels vers la passerelle sécurisée sur le pare-feu SRX Series : l’un pour le trafic OAM et l’autre pour le trafic de données 3GPP (Third-Generation Partnership Project).
Voir également
Proposition IKE
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. Vous pouvez configurer une ou plusieurs propositions IKE. Chaque proposition est une liste d’attributs IKE pour protéger la connexion IKE entre l’hôte IKE et son homologue.
Pour configurer une proposition IKE, incluez l’instruction proposal et spécifiez un nom au niveau de la hiérarchie [edit security ike ] :
Politique IKE
Une stratégie IKE définit une combinaison de paramètres de sécurité (propositions IKE) à utiliser lors de la négociation IKE. Il définit une adresse homologue et les propositions nécessaires pour cette connexion. Selon la méthode d’authentification utilisée, elle définit la clé prépartagée (PSK) pour l’homologue ou le certificat local donné. Au cours de la négociation IKE, IKE recherche une stratégie IKE identique sur les deux homologues. L’homologue qui initie la négociation envoie toutes ses stratégies à l’homologue distant, qui tente de trouver une correspondance. Une correspondance est établie lorsque les deux stratégies des deux homologues ont une proposition qui contient les mêmes attributs configurés. Si les durées de vie ne sont pas identiques, la durée de vie plus courte entre les deux stratégies (de l’hôte et de l’homologue) est utilisée. La PSK configurée doit également correspondre à son homologue.
Tout d’abord, vous configurez une ou plusieurs propositions IKE ; puis vous associez ces propositions à une politique IKE.
Pour configurer une stratégie IKE, incluez l’instruction policy et spécifiez un nom de stratégie au niveau de la hiérarchie [edit security ike] :
Redéfinition des clés et réauthentification
Présentation
Avec IKEv2, la ressaisie et la réauthentification sont des processus distincts. La ressaisie établit de nouvelles clés pour l’association de sécurité IKE (SA) et réinitialise les compteurs d’ID de message, mais elle ne réauthentifie pas les homologues. La réauthentification vérifie que les homologues VPN conservent leur accès aux informations d’identification d’authentification. La réauthentification établit de nouvelles clés pour la SA IKE et les SA enfants ; Il n’est plus nécessaire de refaire les clés de toute SA IKE ou enfant en attente. Une fois que le nouvel IKE et les SA enfants sont créés, l’ancien IKE et les SA enfants sont supprimés.
La réauthentification IKEv2 est désactivée par défaut. Pour activer la réauthentification, configurez une fréquence de réauthentification comprise entre 1 et 100. La fréquence de réauthentification correspond au nombre de nouvelles clés IKE qui se produisent avant que la réauthentification ne se produise. Par exemple, si la fréquence de réauthentification configurée est égale à 1, la réauthentification se produit chaque fois qu’il y a une nouvelle clé IKE. Si la fréquence de réauthentification configurée est égale à 2, la réauthentification a lieu tous les deux renouvellements de clés IKE. Si la fréquence de réauthentification configurée est égale à 3, la réauthentification se produit tous les trois renouvellements de clés IKE, et ainsi de suite.
Vous configurez la fréquence de réauthentification avec l’instruction reauth-frequency au niveau de la hiérarchie [edit security ike policy policy-name]. La réauthentification est désactivée en définissant la fréquence de réauthentification sur 0 (valeur par défaut). La fréquence de réauthentification n’est pas négociée par les homologues et chaque pair peut avoir sa propre valeur de fréquence de réauthentification.
Fonctionnalités prises en charge
La réauthentification IKEv2 est prise en charge avec les fonctionnalités suivantes :
Initiateurs ou répondeurs IKEv2
Dead Peer Detection (DPD)
Routeurs virtuels et interfaces de tunnel sécurisé (st0) dans les routeurs virtuels
Traversée de la traduction d’adresses réseau (NAT-T)
Clusters de châssis en mode actif-actif et actif-passif pour les équipements SRX5400, SRX5600 et SRX5800
Mise à niveau logicielle en service (ISSU) sur les appareils SRX5400, SRX5600 et SRX5800
Mise à niveau ou insertion d’une nouvelle unité de traitement des services (USP) à l’aide de la procédure de mise à niveau du matériel en service (ISHU)
Limitations
Notez les mises en garde suivantes lors de l’utilisation de la réauthentification IKEv2 :
Avec NAT-T, il est possible de créer une nouvelle SA IKE avec des ports différents de l’ancienne IKE SA. Dans ce scénario, l’ancienne IKE SA peut ne pas être supprimée.
Dans un scénario NAT-T, l’initiateur derrière l’équipement NAT peut devenir le répondeur après une nouvelle authentification. Si la session NAT expire, le périphérique NAT peut rejeter de nouveaux paquets IKE susceptibles d’arriver sur un autre port. NAT-T keepalive ou DPD doit être activé pour maintenir la session NAT active. Pour AutoVPN, nous recommandons que la fréquence de réauthentification configurée sur les rayons soit inférieure à la fréquence de réauthentification configurée sur le hub.
En fonction de la fréquence de réauthentification, une nouvelle SA IKE peut être initiée par l’initiateur ou le répondant de la SA IKE d’origine. Étant donné que l’authentification et la configuration EAP (Extensible Authentication Protocol) nécessitent que la SA IKE soit initiée par la même partie que la SA IKE d’origine, la réauthentification n’est pas prise en charge avec l’authentification EAP ou la charge utile de configuration.
Authentification IKE (authentification basée sur des certificats)
Hiérarchie à plusieurs niveaux pour l’authentification des certificats
L’authentification basée sur un certificat est une méthode d’authentification prise en charge par les pare-feu SRX Series lors de la négociation IKE. Sur les grands réseaux, plusieurs autorités de certification (CA) peuvent émettre des certificats d’entité finale (EE) sur leurs terminaux respectifs. Il est courant d’avoir des autorités de certification distinctes pour chaque site, service ou organisation.
Lorsqu’une hiérarchie à un seul niveau est utilisée pour l’authentification basée sur les certificats, tous les certificats EE du réseau doivent être signés par la même autorité de certification. Tous les pare-feu doivent avoir le même certificat d’autorité de certification inscrit pour la validation du certificat pair. La charge utile de certificat envoyée lors de la négociation IKE contient uniquement des certificats EE.
Alternativement, la charge utile de certificat envoyée lors de la négociation IKE peut contenir une chaîne de certificats EE et CA. Une chaîne de certificats est la liste des certificats requis pour valider le certificat EE d’un pair. La chaîne de certificats inclut le certificat EE et tous les certificats d’autorité de certification qui ne sont pas présents dans l’homologue local.
L’administrateur réseau doit s’assurer que tous les homologues participant à une négociation IKE disposent d’au moins une autorité de certification de confiance commune dans leurs chaînes de certificats respectives. L’autorité de certification approuvée commune n’a pas besoin d’être l’autorité de certification racine. Le nombre de certificats dans la chaîne, y compris les certificats pour les EE et l’autorité de certification la plus élevée de la chaîne, ne peut pas dépasser 10.
La visualisationd’un homologue IKE configuré peut être effectuée avec un serveur d’autorité de certification spécifié ou un groupe de serveurs d’autorité de certification. Avec les chaînes de certificats, l’autorité de certification racine doit correspondre au groupe d’autorités de certification ou au serveur d’autorités de certification approuvé configuré dans la stratégieIKE.
Dans l’exemple de hiérarchie d’autorités de certification illustré à Figure 8, l’autorité de certification racine est l’autorité de certification approuvée commune à tous les périphériques du réseau. L’autorité de certification racine délivre des certificats d’autorité de certification aux autorités de certification d’ingénierie et de vente, qui sont identifiées comme Eng-CA et Sales-CA, respectivement. Eng-CA délivre des certificats d’AC aux AC de développement et d’assurance de la qualité, qui sont identifiés comme Dev-CA et Qa-CA, respectivement. L’hôte-A reçoit son certificat EE de Dev-CA tandis que l’hôte-B reçoit son certificat EE de Sales-CA.
Chaque terminal doit être chargé avec les certificats CA dans sa hiérarchie. L’hôte-A doit avoir des certificats Root-CA, Eng-CA et Dev-CA ; Les certificats Sales-CA et Qa-CA ne sont pas nécessaires. L’hôte B doit avoir des certificats d’autorité de certification racine et d’autorité de certification de vente. Les certificats peuvent être chargés manuellement dans un appareil ou enrôlés à l’aide du processus d’inscription de certificats simple (SCEP).
Chaque terminal doit être configuré avec un profil d’autorité de certification pour chaque autorité de certification de la chaîne de certificats. La sortie suivante montre les profils d’autorité de certification configurés sur l’hôte A :
admin@host-A# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url “www.example.net/scep/Eng/”;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url “www.example.net/scep/Dev/”;
}
}
}La sortie suivante montre les profils d’autorité de certification configurés sur l’hôte B :
admin@host-B# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Sales-CA {
ca-identity Sales-CA;
enrollment {
url “www.example.net/scep/Sales/”;
}
}
}Voir également
Configurer plusieurs types de certificats pour établir IKE et IPsec SA
Découvrez comment configurer et gérer plusieurs types de certificats.
Cet exemple montre comment configurer plusieurs types de certificats pour établir IKE et IPsec SA.
À partir de Junos OS version 22.4R1, vous pouvez établir des tunnels quel que soit le type de certificat utilisé sur l’initiateur et le répondeur si authentication-method est configuré comme certificates dans la proposition IKE à l’aide de la set security ike proposal ike_proposal_name authentication-method certificates commande.
Vous pouvez afficher le certificat enrôlé à l’aide de show security pki local-certificate certificate-id certificate-name detail la commande.
Vous pouvez vérifier le certificat inscrit à l’aide de la request security pki local-certificate verify certificate-id certificate-name commande.
Conditions préalables
Avant de commencer :
-
Assurez-vous d’avoir des certificats inscrits sur vos appareils, voir Inscription de certificats.
Vous pouvez vérifier les certificats inscrits sur vos appareils à l’aide de la
request security pki local-certificate certificate-id certificate-name detailcommande. -
Assurez-vous que le package IKE est installé, pour vérifier que le package IKE est installé, utilisez la
show version | match ikecommande opérationnelle.Si le package IKE n’est pas installé sur l’appareil, vous pouvez l’installer à l’aide de la commande opérationnelle , pour plus d’informations, reportez-vous à la section
request system software add optional://junos-ike.tgzActivation de l’ensemble de fonctionnalités VPN IPsec.
Présentation
Cet exemple configure plusieurs types de certificats pour établir IKE et IPsec SA entre le SRX_A et le SRX_B.
Dans cet exemple, nous avons inscrit le certificat RSA sur SRX_A et le certificat ECDSA sur les appareils SRX_B. Pour plus d’informations sur l’installation des certificats, consultez Inscription des certificats.
| Nom de l'appareil | Interface utilisée | Adresse de la passerelle IKE | Adresse IP locale de la passerelle IKE |
|---|---|---|---|
| SRX_A | ge-0/0/0 | 192.168.1.2 | 192.168.1.1 |
| SRX_B | ge-0/0/0 | 192.168.1.1 | 192.168.1.2 |
Topologie
La Figure 9 description de la topologie de plusieurs types de certificats prend en charge la configuration.
Configuration
Configuration de SRX_A
Configuration rapide de l’interface de ligne de commande
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 à la configuration de votre réseau, 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 interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24 set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 set interfaces st0 unit 1 family inet set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust host-inbound-traffic protocols all set security zones security-zone trust interfaces ge-0/0/1 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone untrust interfaces ge-0/0/0 set security zones security-zone VPN interfaces st0.1 set security policies from-zone VPN to-zone trust policy 1 match source-address any set security policies from-zone VPN to-zone trust policy 1 match destination-address any set security policies from-zone VPN to-zone trust policy 1 match application any set security policies from-zone VPN to-zone trust policy 1 then permit set security policies from-zone trust to-zone VPN policy 1 match source-address any set security policies from-zone trust to-zone VPN policy 1 match destination-address any set security policies from-zone trust to-zone VPN policy 1 match application any set security policies from-zone trust to-zone VPN policy 1 then permit set security policies default-policy deny-all set security ike proposal IKE_PROP authentication-method certificates set security ike proposal IKE_PROP dh-group group5 set security ike proposal IKE_PROP authentication-algorithm sha-256 set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc set security ike policy IKE_POL proposals IKE_PROP set security ike policy IKE_POL certificate local-certificate r0_rsa_crt set security ike gateway IKE_GW ike-policy IKE_POL set security ike gateway IKE_GW address 192.168.1.2 set security ike gateway IKE_GW external-interface ge-0/0/0 set security ike gateway IKE_GW local-address 192.168.1.1 set security ike gateway IKE_GW version v2-only set security ipsec proposal IPSEC_PROP protocol esp set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc set security ipsec policy IPSEC_POL proposals IPSEC_PROP set security ipsec vpn IPSEC_VPN bind-interface st0.1 set security ipsec vpn IPSEC_VPN ike gateway IKE_GW set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL set security ipsec vpn IPSEC_VPN establish-tunnels on-traffic
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 façon de procéder, consultez Présentation du mode de configuration CLI dans le Guide de l’utilisateur CLI.
Pour configurer plusieurs types de certificats afin d’établir IKE et IPsec SA :
-
Affichez les certificats inscrits sur vos appareils à l’aide de la
show security pki local-certificate certificate-id certificate-name detailcommande.Installez le certificat sur votre appareil si les certificats ne sont pas inscrits sur votre appareil. Pour plus d’informations, reportez-vous à la section Inscription de certificats.
-
Configurez les interfaces.
user@srxa# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24 user@srxa# set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 user@srxa# set interfaces st0 unit 1 family inet
-
Configurez les zones de sécurité et la stratégie de sécurité.
user@srxa# set security zones security-zone trust host-inbound-traffic system-services all user@srxa# set security zones security-zone trust host-inbound-traffic protocols all user@srxa# set security zones security-zone trust interfaces ge-0/0/1 user@srxa# set security zones security-zone untrust host-inbound-traffic system-services ike user@srxa# set security zones security-zone untrust interfaces ge-0/0/0 user@srxa# set security zones security-zone VPN interfaces st0.1 user@srxa# set security policies from-zone VPN to-zone trust policy 1 match source-address any user@srxa# set security policies from-zone VPN to-zone trust policy 1 match destination-address any user@srxa# set security policies from-zone VPN to-zone trust policy 1 match application any user@srxa# set security policies from-zone VPN to-zone trust policy 1 then permit user@srxa# set security policies from-zone trust to-zone VPN policy 1 match source-address any user@srxa# set security policies from-zone trust to-zone VPN policy 1 match destination-address any user@srxa# set security policies from-zone trust to-zone VPN policy 1 match application any user@srxa# set security policies from-zone trust to-zone VPN policy 1 then permit user@srxa# set security policies default-policy deny-all
-
Configurez la proposition IKE.
[edit] user@srxa# set security ike proposal IKE_PROP authentication-method certificates user@srxa# set security ike proposal IKE_PROP dh-group group5 user@srxa# set security ike proposal IKE_PROP authentication-algorithm sha-256 user@srxa# set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc
-
Configurez la stratégie IKE.
[edit] user@srxa# set security ike policy IKE_POL proposals IKE_PROP user@srxa# set security ike policy IKE_POL certificate local-certificate r0_rsa_crt
-
Configurez la passerelle IKE.
[edit] user@srxa# set security ike gateway IKE_GW ike-policy IKE_POL user@srxa# set security ike gateway IKE_GW address 192.168.1.2 user@srxa# set security ike gateway IKE_GW external-interface ge-0/0/0 user@srxa# set security ike gateway IKE_GW local-address 192.168.1.1 user@srxa# set security ike gateway IKE_GW version v2-only
-
Configurez la proposition IPsec.
[edit] user@srxa# set security ipsec proposal IPSEC_PROP protocol esp user@srxa# set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 user@srxa# set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc
-
Configurez la stratégie IPsec.
[edit] user@srxa# set security ipsec policy IPSEC_POL proposals IPSEC_PROP
-
Configurez le VPN IPsec.
[edit] user@srxa# set security ipsec vpn IPSEC_VPN bind-interface st0.1 user@srxa# set security ipsec vpn IPSEC_VPN ike gateway IKE_GW user@srxa# set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL user@srxa# set security ipsec vpn IPSEC_VPN establish-tunnels on-traffic
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes , show security ike et. show security ipsec Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@srxa# show interfaces
ge-0/0/0 {
description untrust;
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/0/1 {
description trust;
unit 0 {
family inet {
address 172.16.1.1/24;
}
}
}
st0 {
unit 1 {
family inet;
}
}
[edit]
user@srxa# show security ike
proposal IKE_PROP {
authentication-method certificates;
dh-group group5;
authentication-algorithm sha-256;
encryption-algorithm aes-128-cbc;
}
policy IKE_POL {
proposals IKE_PROP;
certificate {
local-certificate r0_crt_rsa;
}
}
gateway IKE_GW {
ike-policy IKE_POL;
address 192.168.1.2;
external-interface ge-0/0/0;
local-address 192.168.1.1;
version v2-only;
}
[edit]
user@srxa# show security ipsec
proposal IPSEC_PROP {
protocol esp;
authentication-algorithm hmac-sha-256-128;
encryption-algorithm aes-192-cbc;
}
policy IPSEC_POL {
proposals IPSEC_PROP;
}
vpn IPSEC_VPN {
bind-interface st0.1;
ike {
gateway IKE_GW;
ipsec-policy IPSEC_POL;
}
establish-tunnels on-traffic;
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration de SRX_B
Configuration rapide de l’interface de ligne de commande
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 à la configuration de votre réseau, 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 interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24 set interfaces ge-0/0/1 unit 0 family inet address 172.18.1.2/24 set interfaces st0 unit 1 family inet set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust host-inbound-traffic protocols all set security zones security-zone trust interfaces ge-0/0/1 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone untrust interfaces ge-0/0/0 set security zones security-zone VPN interfaces st0.1 set security policies from-zone VPN to-zone trust policy 1 match source-address any set security policies from-zone VPN to-zone trust policy 1 match destination-address any set security policies from-zone VPN to-zone trust policy 1 match application any set security policies from-zone VPN to-zone trust policy 1 then permit set security policies from-zone trust to-zone VPN policy 1 match source-address any set security policies from-zone trust to-zone VPN policy 1 match destination-address any set security policies from-zone trust to-zone VPN policy 1 match application any set security policies from-zone trust to-zone VPN policy 1 then permit set security policies default-policy deny-all set security ike proposal IKE_PROP authentication-method certificates set security ike proposal IKE_PROP dh-group group5 set security ike proposal IKE_PROP authentication-algorithm sha-256 set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc set security ike policy IKE_POL proposals IKE_PROP set security ike policy IKE_POL certificate local-certificate r1_crt_ecdsa384 set security ike gateway IKE_GW ike-policy IKE_POL set security ike gateway IKE_GW address 192.168.1.1 set security ike gateway IKE_GW external-interface ge-0/0/0 set security ike gateway IKE_GW local-address 192.168.1.2 set security ike gateway IKE_GW version v2-only set security ipsec proposal IPSEC_PROP protocol esp set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc set security ipsec policy IPSEC_POL proposals IPSEC_PROP set security ipsec vpn IPSEC_VPN bind-interface st0.1 set security ipsec vpn IPSEC_VPN ike gateway IKE_GW set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL set security ipsec vpn IPSEC_VPN establish-tunnels on-traffic
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 façon de procéder, consultez Présentation du mode de configuration CLI dans le Guide de l’utilisateur CLI.
Pour configurer plusieurs types de certificats afin d’établir IKE et IPsec SA :
-
Affichez les certificats inscrits sur vos appareils à l’aide de la
request security pki local-certificate certificate-id certificate-name detailcommande.Installez le certificat sur votre appareil si les certificats ne sont pas inscrits sur votre appareil. Pour plus d’informations, reportez-vous à la section Inscription de certificats.
-
Configurez les interfaces.
user@srxb# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24 user@srxb# set interfaces ge-0/0/1 unit 0 family inet address 172.18.1.2/24 user@srxb# set interfaces st0 unit 1 family inet
-
Configurez les zones de sécurité et la stratégie de sécurité.
user@srxb# set security zones security-zone trust host-inbound-traffic system-services all user@srxb# set security zones security-zone trust host-inbound-traffic protocols all user@srxb# set security zones security-zone trust interfaces ge-0/0/1 user@srxb# set security zones security-zone untrust host-inbound-traffic system-services ike user@srxb# set security zones security-zone untrust interfaces ge-0/0/0 user@srxb# set security zones security-zone VPN interfaces st0.1 user@srxb# set security policies from-zone VPN to-zone trust policy 1 match source-address any user@srxb# set security policies from-zone VPN to-zone trust policy 1 match destination-address any user@srxb# set security policies from-zone VPN to-zone trust policy 1 match application any user@srxb# set security policies from-zone VPN to-zone trust policy 1 then permit user@srxb# set security policies from-zone trust to-zone VPN policy 1 match source-address any user@srxb# set security policies from-zone trust to-zone VPN policy 1 match destination-address any user@srxb# set security policies from-zone trust to-zone VPN policy 1 match application any user@srxb# set security policies from-zone trust to-zone VPN policy 1 then permit user@srxb# set security policies default-policy deny-all
-
Configurez la proposition IKE.
[edit] user@srxb# set security ike proposal IKE_PROP authentication-method certificates user@srxb# set security ike proposal IKE_PROP dh-group group5 user@srxb# set security ike proposal IKE_PROP authentication-algorithm sha-256 user@srxb# set security ike proposal IKE_PROP encryption-algorithm aes-128-cbc
-
Configurez la stratégie IKE.
[edit] user@srxb# set security ike policy IKE_POL proposals IKE_PROP user@srxb# set security ike policy IKE_POL certificate local-certificate r1_crt_ecdsa384
-
Configurez la passerelle IKE.
[edit] user@srxb# set security ike gateway IKE_GW ike-policy IKE_POL user@srxb# set security ike gateway IKE_GW address 192.168.1.1 user@srxb# set security ike gateway IKE_GW external-interface ge-0/0/0 user@srxb# set security ike gateway IKE_GW local-address 192.168.1.2 user@srxb# set security ike gateway IKE_GW version v2-only
-
Configurez la proposition IPsec.
[edit] user@srxb# set security ipsec proposal IPSEC_PROP protocol esp user@srxb# set security ipsec proposal IPSEC_PROP authentication-algorithm hmac-sha-256-128 user@srxb# set security ipsec proposal IPSEC_PROP encryption-algorithm aes-192-cbc
-
Configurez la stratégie IPsec.
[edit] user@srxb# set security ipsec policy IPSEC_POL proposals IPSEC_PROP
-
Configurez le VPN IPsec.
[edit] user@srxb# set security ipsec vpn IPSEC_VPN bind-interface st0.1 user@srxb# set security ipsec vpn IPSEC_VPN ike gateway IKE_GW user@srxb# set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POL user@srxb# set security ipsec vpn IPSEC_VPN establish-tunnels immediately
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant les show interfacescommandes , show security ike et. show security ipsec Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@srxb# show interfaces
ge-0/0/0 {
description untrust;
unit 0 {
family inet {
address 192.168.1.2/24;
}
}
}
ge-0/0/1 {
description trust;
unit 0 {
family inet {
address 172.18.1.2/24;
}
}
}
st0 {
unit 1 {
family inet;
}
}
[edit]
user@srxb# show security ike
proposal IKE_PROP {
authentication-method certificates;
dh-group group5;
authentication-algorithm sha-256;
encryption-algorithm aes-128-cbc;
}
policy IKE_POL {
proposals IKE_PROP;
certificate {
local-certificate r1_crt_ecdsa384;
}
}
gateway IKE_GW {
ike-policy IKE_POL;
address 192.168.1.1;
external-interface ge-0/0/0;
local-address 192.168.1.2;
version v2-only;
}
[edit]
user@srxb# show security ipsec
proposal IPSEC_PROP {
protocol esp;
authentication-algorithm hmac-sha-256-128;
encryption-algorithm aes-192-cbc;
}
policy IPSEC_POL {
proposals IPSEC_PROP;
}
vpn IPSEC_VPN {
bind-interface st0.1;
ike {
gateway IKE_GW;
ipsec-policy IPSEC_POL;
}
establish-tunnels immediately;
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérifier SRX_A
Les exemples de sortie indiqués sont sur SRX-A.
But
Vérifiez l’état IPsec Phase 2.
Action
À partir du mode opérationnel, entrez la show security ike security-associations commande.
user@srxa> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 32 UP 6723643250f0f357 f6295f11b0d7c8ab IKEv2 192.168.1.2
À partir du mode opérationnel, entrez la show security ipsec security-associations commande.
user@srxa> show security ipsec security-associations Total active tunnels: 1 Total IPsec sas: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <500033 ESP:aes-cbc-192/sha256 0x5f156c1b 2750/ unlim - root 500 192.168.1.2 >500033 ESP:aes-cbc-192/sha256 0x7ea065e7 2750/ unlim - root 500 192.168.1.2
À partir du mode opérationnel, entrez la show security ike security-associations detail commande.
user@srxa> show security ike security-associations detail
IKE peer 192.168.1.2, Index 32, Gateway Name: IKE_GW
Role: Responder, State: UP
Initiator cookie: 6723643250f0f357, Responder cookie: f6295f11b0d7c8ab
Exchange type: IKEv2, Authentication method: RSA-signatures
Local gateway interface: ge-0/0/0.0
Routing instance: default
Local: 192.168.1.1:500, Remote: 192.168.1.2:500
Lifetime: Expires in 28165 seconds
Reauth Lifetime: Disabled
IKE Fragmentation: Enabled, Size: 576
Remote Access Client Info: Unknown Client
Peer ike-id: 192.168.1.2
AAA assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha256-128
Encryption : aes128-cbc
Pseudo random function: hmac-sha256
Diffie-Hellman group : DH-group-5
Traffic statistics:
Input bytes : 1346
Output bytes : 1887
Input packets: 3
Output packets: 4
Input fragmented packets: 2
Output fragmented packets: 3
IPSec security associations: 2 created, 0 deleted
Phase 2 negotiations in progress: 1
IPSec Tunnel IDs: 500033
Negotiation type: Quick mode, Role: Responder, Message ID: 0
Local: 192.168.1.1:500, Remote: 192.168.1.2:500
Local identity: 192.168.1.1
Remote identity: 192.168.1.2
Flags: IKE SA is created
IPsec SA Rekey CREATE_CHILD_SA exchange stats:
Initiator stats: Responder stats:
Request Out : 0 Request In : 0
Response In : 0 Response Out : 0
No Proposal Chosen In : 0 No Proposal Chosen Out : 0
Invalid KE In : 0 Invalid KE Out : 0
TS Unacceptable In : 0 TS Unacceptable Out : 0
Res DH Compute Key Fail : 0 Res DH Compute Key Fail: 0
Res Verify SA Fail : 0
Res Verify DH Group Fail: 0
Res Verify TS Fail : 0
À partir du mode opérationnel, entrez la show security ipsec security-associations detail commande.
user@srxa> show security ipsec security-associations detail
ID: 500033 Virtual-system: root, VPN Name: IPSEC_VPN
Local Gateway: 192.168.1.1, Remote Gateway: 192.168.1.2
Local Identity: ipv4(0.0.0.0-255.255.255.255)
Remote Identity: ipv4(0.0.0.0-255.255.255.255)
TS Type: proxy-id
Version: IKEv2
PFS group: N/A
DF-bit: clear, Copy-Outer-DSCP Disabled, Bind-interface: st0.1, Tunnel MTU: 0, Policy-name: IPSEC_POL
Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0
Multi-sa, Configured SAs# 0, Negotiated SAs#: 0
Tunnel events:
Thu Mar 09 2023 22:41:36: IPsec SA negotiation succeeds (1 times)
Location: FPC 0, PIC 0, KMD-Instance 0
Anchorship: Thread 1
Distribution-Profile: default-profile
Direction: inbound, SPI: 0x5f156c1b, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2895 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2286 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 32
Direction: outbound, SPI: 0x7ea065e7, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2895 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2286 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 32
À partir du mode opérationnel, entrez la show security pki local-certificate certificate-id r0_rsa_cr detail commande.
user@srxa> show security pki local-certificate certificate-id r0_rsa_crt detail
LSYS: root-logical-system
Certificate identifier: r0_rsa_crt
Certificate version: 3
Serial number:
hexadecimal: 0x0186a62478ae8f0cdd766eb38dbd53
decimal: 7923302907757301847007106226306387
Issuer:
Organization: juniper, Country: India, Common name: Root-CA
Subject:
Organization: juniper, Organizational unit: marketing, State: california, Locality: sunnyvale, Common name: r0, Domain component: juniper
Subject string:
DC=juniper, CN=r0, OU=marketing, O=juniper, L=sunnyvale, ST=california, C=us
Alternate subject: "r0@juniper.net", r0.juniper.net, 192.168.1.1
Cert-Chain: Root-CA
Validity:
Not before: 03- 3-2023 05:54 UTC
Not after: 06- 6-2027 12:36 UTC
Public key algorithm: rsaEncryption(2048 bits)
30:82:01:0a:02:82:01:01:00:b0:e5:53:8d:7e:20:fa:6b:21:c2:d1
2b:48:8f:af:c3:eb:8b:23:4a:f7:c5:1f:cf:2c:6a:b3:2e:8a:ef:1b
f7:97:aa:fd:1d:ab:1c:76:9b:40:a3:ac:bb:49:f6:93:f9:e1:4e:62
df:3d:ca:e5:d2:95:9c:a0:f4:2b:d7:7e:1d:20:94:69:a8:e4:cf:dc
15:90:4c:be:1d:d8:1c:52:08:3a:d1:05:a3:bb:2f:8f:31:0c:6b:21
ef:76:c3:c7:fb:be:4a:cb:da:cc:8d:04:3a:75:0c:eb:5d:e2:f6:13
50:fe:39:67:c0:77:2f:32:b0:5e:38:6f:9c:79:b3:5d:f3:57:f4:f8
42:f5:22:5b:6c:58:67:90:4e:1e:ec:6a:03:e2:c0:87:65:02:ca:da
6f:95:0a:8c:2a:fd:45:4f:3a:b5:ef:18:05:1c:54:e6:fe:45:bb:73
53:81:b2:c6:b7:36:36:57:6d:9c:d3:d9:80:e7:d6:85:92:74:32:88
16:01:03:27:57:76:8e:5e:d6:73:ac:bf:68:fd:6d:a1:2a:8f:f5:3a
29:b0:c9:44:9b:c8:46:c1:bf:c0:52:2a:f0:51:be:b5:f6:e1:f5:3e
96:1d:3a:42:29:28:d3:cf:60:b9:eb:24:04:47:d3:f1:3f:5e:38:fc
7f:33:f6:94:9d:02:03:01:00:01
Signature algorithm: sha256WithRSAEncryption
Fingerprint:
4d:f6:89:c5:d6:3c:74:73:db:3e:f6:4b:1e:26:6c:c1:1c:1d:a7:4d (sha1)
6b:1c:a8:1f:de:5a:9b:3e:d5:c4:85:29:af:3f:82:f2 (md5)
6b:7a:b5:d1:57:cf:75:9d:1f:63:b9:f6:49:e4:4e:b3:13:2c:83:f1:f7:25:44:6f:45:2f:0d:2f:ae:a8:80:85 (sha256)
Auto-re-enrollment:
Status: Disabled
Next trigger time: Timer not startedÀ partir du mode opérationnel, entrez la show security pki ca-certificate ca-profile Root-CA detail commande.
user@srxa> show security pki ca-certificate ca-profile Root-CA detail
LSYS: root-logical-system
CA profile: Root-CA
Certificate identifier: Root-CA
Certificate version: 3
Serial number:
hexadecimal: 0x00000440
decimal: 1088
Issuer:
Organization: juniper, Country: India, Common name: Root-CA
Subject:
Organization: juniper, Country: India, Common name: Root-CA
Subject string:
C=India, O=juniper, CN=Root-CA
Validity:
Not before: 06- 7-2022 12:36 UTC
Not after: 06- 6-2027 12:36 UTC
Public key algorithm: rsaEncryption(2048 bits)
30:82:01:0a:02:82:01:01:00:cd:9c:e6:9f:62:6c:49:15:c2:da:eb
8e:e6:e5:a1:88:40:d8:b5:2e:5b:1a:0e:de:96:d7:0b:19:f9:03:44
98:49:d5:cc:a8:90:2b:7f:1b:58:7b:1f:26:92:18:4c:2d:37:65:5c
9f:0f:6e:10:b5:34:6f:2d:b5:9c:27:3b:a6:b1:b5:a0:e2:a6:92:3d
e4:68:fe:5d:71:06:6f:ce:e6:0f:0f:e3:94:2a:23:57:98:a0:6a:9c
e0:52:a2:47:ff:ce:b0:47:bd:36:95:80:a7:af:d2:49:b1:5d:2a:3d
28:e4:95:06:b8:b3:d9:07:11:3c:13:af:c6:e2:51:08:22:82:2d:ec
4f:26:40:b0:b0:55:2d:6e:c0:c8:19:34:a7:99:5a:bc:58:98:69:ae
04:d6:6d:ec:4a:c9:55:a5:ff:00:cb:3b:02:85:fa:02:a1:5c:c1:9d
6d:44:b8:95:8f:77:c0:53:fc:7f:a4:09:a3:25:1c:4a:e2:9d:0c:81
08:b4:c8:b8:0d:bc:94:75:54:75:57:4f:d3:a4:17:0d:5d:1a:f3:c1
1d:5d:73:2f:fe:8b:cb:fc:1f:93:87:72:d6:be:df:86:d7:e6:d1:c7
0d:00:1a:6e:58:db:6a:1c:2f:1d:17:46:9a:f2:69:b4:21:db:08:5d
8d:ab:30:7d:7f:02:03:01:00:01
Signature algorithm: sha256WithRSAEncryption
Distribution CRL:
http://10.102.40.55:8080/crl-as-der/currentcrl-11.crl?id=11
Use for key: CRL signing, Certificate signing, Key encipherment, Digital signature
Fingerprint:
8b:84:60:2a:58:5b:80:f0:b9:ae:25:9f:67:3d:d6:81:ee:43:6c:d4 (sha1)
ab:ec:4d:fe:d4:04:9c:c9:79:1d:9a:33:4e:6d:78:f6 (md5)
9d:f0:c0:a0:93:74:11:53:d3:4d:2d:75:d3:60:37:5f:fb:b7:a9:67:42:cd:7c:3c:0e:0f:9b:58:36:3c:14:f5 (sha256)Vérifier SRX_B
Les exemples de sortie indiqués sont sur SRX-B.
But
Vérifiez l’état IPsec Phase 2.
Action
À partir du mode opérationnel, entrez la show security ike security-associations commande.
user@srxb> show security ike security-associations Index State Initiator cookie Responder cookie Mode Remote Address 56042 UP 6723643250f0f357 f6295f11b0d7c8ab IKEv2 192.168.1.1
À partir du mode opérationnel, entrez la show security ipsec security-associations commande.
user@srxb> show security ipsec security-associations Total active tunnels: 1 Total IPsec sas: 1 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <500230 ESP:aes-cbc-192/sha256 0x7ea065e7 2638/ unlim - root 500 192.168.1.1 >500230 ESP:aes-cbc-192/sha256 0x5f156c1b 2638/ unlim - root 500 192.168.1.1
À partir du mode opérationnel, entrez la show security ike security-associations detail commande.
user@srxb> show security ike security-associations detail
IKE peer 192.168.1.1, Index 56042, Gateway Name: IKE_GW
Role: Responder, State: UP
Initiator cookie: 6723643250f0f357, Responder cookie: f6295f11b0d7c8ab
Exchange type: IKEv2, Authentication method: ECDSA-384-signatures
Local gateway interface: ge-0/0/0.0
Routing instance: default
Local: 192.168.1.2:500, Remote: 192.168.1.1:500
Lifetime: Expires in 18995 seconds
Reauth Lifetime: Disabled
IKE Fragmentation: Enabled, Size: 576
Remote Access Client Info: Unknown Client
Peer ike-id: 192.168.1.1
AAA assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha256-128
Encryption : aes128-cbc
Pseudo random function: hmac-sha256
Diffie-Hellman group : DH-group-5
Traffic statistics:
Input bytes : 2934
Output bytes : 2379
Input packets: 10
Output packets: 9
Input fragmented packets: 3
Output fragmented packets: 2
IPSec security associations: 8 created, 3 deleted
Phase 2 negotiations in progress: 1
IPSec Tunnel IDs: 500230
Negotiation type: Quick mode, Role: Responder, Message ID: 0
Local: 192.168.1.2:500, Remote: 192.168.1.1:500
Local identity: 192.168.1.2
Remote identity: 192.168.1.1
Flags: IKE SA is created
IPsec SA Rekey CREATE_CHILD_SA exchange stats:
Initiator stats: Responder stats:
Request Out : 1 Request In : 2
Response In : 1 Response Out : 2
No Proposal Chosen In : 0 No Proposal Chosen Out : 0
Invalid KE In : 0 Invalid KE Out : 0
TS Unacceptable In : 0 TS Unacceptable Out : 0
Res DH Compute Key Fail : 0 Res DH Compute Key Fail: 0
Res Verify SA Fail : 0
Res Verify DH Group Fail: 0
Res Verify TS Fail : 0
À partir du mode opérationnel, entrez la show security ipsec security-associations detail commande.
user@srxb> show security ipsec security-associations detail
ID: 500230 Virtual-system: root, VPN Name: IPSEC_VPN
Local Gateway: 192.168.1.2, Remote Gateway: 192.168.1.1
Local Identity: ipv4(0.0.0.0-255.255.255.255)
Remote Identity: ipv4(0.0.0.0-255.255.255.255)
TS Type: proxy-id
Version: IKEv2
PFS group: N/A
DF-bit: clear, Copy-Outer-DSCP Disabled, Bind-interface: st0.1, Tunnel MTU: 0, Policy-name: IPSEC_POL
Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0
Multi-sa, Configured SAs# 0, Negotiated SAs#: 0
Tunnel events:
Thu Mar 02 2023 22:26:16: IPsec SA negotiation succeeds (1 times)
Location: FPC 0, PIC 0, KMD-Instance 0
Anchorship: Thread 1
Distribution-Profile: default-profile
Direction: inbound, SPI: 0x7ea065e7, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2633 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2002 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 56042
Direction: outbound, SPI: 0x5f156c1b, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2633 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2002 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (192 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Extended-Sequence-Number: Disabled
tunnel-establishment: establish-tunnels-on-traffic
IKE SA Index: 56042À partir du mode opérationnel, entrez la show security pki local-certificate certificate-id r1_crt_ecdsa384 detail commande.
user@srxb> show security pki local-certificate certificate-id r1_crt_ecdsa384 detail
LSYS: root-logical-system
Certificate identifier: r1_crt_ecdsa384
Certificate version: 3
Serial number:
hexadecimal: 0x0186a6254347a38063946d08595a55
decimal: 7923303152683216740296668848151125
Issuer:
Organization: juniper, Country: India, Common name: root-ecdsa-384
Subject:
Organization: juniper, Organizational unit: marketing, State: california, Locality: sunnyvale, Common name: r1_spk1, Domain component: juniper
Subject string:
DC=juniper, CN=r1_spk1, OU=marketing, O=juniper, L=sunnyvale, ST=california, C=us
Alternate subject: "r1_spk1@juniper.net", r1_spk1.juniper.net, 192.168.2
Cert-Chain: root-ecdsa-384
Validity:
Not before: 03- 3-2023 05:55 UTC
Not after: 06- 6-2027 13:21 UTC
Public key algorithm: ecdsaEncryption(384 bits)
04:c2:ba:19:dc:0d:62:a7:94:7b:9b:1d:4d:ff:a1:e1:44:b5:57:a7
cb:7d:33:6b:35:87:b8:e4:ca:44:b1:6c:6d:63:ae:6f:3c:31:7c:7e
65:99:b3:2d:a3:76:30:23:e5:0e:34:e1:28:54:d6:3e:d3:8b:de:b6
b9:45:05:82:6f:1d:20:b7:6f:3c:ce:a2:13:a2:b4:37:0b:db:35:1e
20:54:b5:06:9d:f8:7f:19:7b:c5:d7:7b:57:8b:28:31:d3
Signature algorithm: ecdsa-with-SHA384
Fingerprint:
9b:cb:5a:57:a8:60:a0:ee:5c:be:59:4c:db:35:39:d3:b7:29:ef:b1 (sha1)
ef:b5:e3:be:35:1b:6e:02:0b:61:11:a5:53:07:b4:89 (md5)
8f:86:d0:12:ea:bc:a8:81:a8:17:3a:f9:03:e4:91:57:20:9c:11:bc:a4:dd:d1:7f:d1:48:3f:5b:d9:fb:93:32 (sha256)
Auto-re-enrollment:
Status: Disabled
Next trigger time: Timer not started
s
À partir du mode opérationnel, entrez la show security pki ca-certificate ca-profile Root-CA detail commande.
user@srxb> show security pki ca-certificate ca-profile Root-CA detail
LSYS: root-logical-system
CA profile: Root-CA
Certificate identifier: Root-CA
Certificate version: 3
Serial number:
hexadecimal: 0x00000440
decimal: 1088
Issuer:
Organization: juniper, Country: India, Common name: Root-CA
Subject:
Organization: juniper, Country: India, Common name: Root-CA
Subject string:
C=India, O=juniper, CN=Root-CA
Validity:
Not before: 06- 7-2022 12:36 UTC
Not after: 06- 6-2027 12:36 UTC
Public key algorithm: rsaEncryption(2048 bits)
30:82:01:0a:02:82:01:01:00:cd:9c:e6:9f:62:6c:49:15:c2:da:eb
8e:e6:e5:a1:88:40:d8:b5:2e:5b:1a:0e:de:96:d7:0b:19:f9:03:44
98:49:d5:cc:a8:90:2b:7f:1b:58:7b:1f:26:92:18:4c:2d:37:65:5c
9f:0f:6e:10:b5:34:6f:2d:b5:9c:27:3b:a6:b1:b5:a0:e2:a6:92:3d
e4:68:fe:5d:71:06:6f:ce:e6:0f:0f:e3:94:2a:23:57:98:a0:6a:9c
e0:52:a2:47:ff:ce:b0:47:bd:36:95:80:a7:af:d2:49:b1:5d:2a:3d
28:e4:95:06:b8:b3:d9:07:11:3c:13:af:c6:e2:51:08:22:82:2d:ec
4f:26:40:b0:b0:55:2d:6e:c0:c8:19:34:a7:99:5a:bc:58:98:69:ae
04:d6:6d:ec:4a:c9:55:a5:ff:00:cb:3b:02:85:fa:02:a1:5c:c1:9d
6d:44:b8:95:8f:77:c0:53:fc:7f:a4:09:a3:25:1c:4a:e2:9d:0c:81
08:b4:c8:b8:0d:bc:94:75:54:75:57:4f:d3:a4:17:0d:5d:1a:f3:c1
1d:5d:73:2f:fe:8b:cb:fc:1f:93:87:72:d6:be:df:86:d7:e6:d1:c7
0d:00:1a:6e:58:db:6a:1c:2f:1d:17:46:9a:f2:69:b4:21:db:08:5d
8d:ab:30:7d:7f:02:03:01:00:01
Signature algorithm: sha256WithRSAEncryption
Distribution CRL:
http://10.102.40.55:8080/crl-as-der/currentcrl-11.crl?id=11
Use for key: CRL signing, Certificate signing, Key encipherment, Digital signature
Fingerprint:
8b:84:60:2a:58:5b:80:f0:b9:ae:25:9f:67:3d:d6:81:ee:43:6c:d4 (sha1)
ab:ec:4d:fe:d4:04:9c:c9:79:1d:9a:33:4e:6d:78:f6 (md5)
9d:f0:c0:a0:93:74:11:53:d3:4d:2d:75:d3:60:37:5f:fb:b7:a9:67:42:cd:7c:3c:0e:0f:9b:58:36:3c:14:f5 (sha256)Authentification des signatures dans IKEv2
Lisez cette rubrique pour en savoir plus sur la méthode d’authentification de signature dans IKEv2 et son fonctionnement dans Junos OS.
Le protocole Internet Key Exchange version 2 (IKEv2) prend en charge l’authentification basée sur des signatures qui utilise la cryptographie à clé publique. Dans IKEv2, l’authentification basée sur les signatures ne prend en charge qu’une seule méthode d’authentification par algorithme de signature. Par exemple, les homologues IKE utilisent une méthode d’authentification distincte pour chacune de ces signatures numériques : RSA, l’algorithme de signature numérique (DSA) et la courbe elliptique DSA (ECDSA). Chaque algorithme de hachage est lié à une signature pour l’authentification. Dans la configuration de proposition IKEv2, lorsque vous spécifiez la méthode d’authentification, l’appareil utilise cette méthode pour authentifier la source des messages IKEv2. Il est difficile pour l’homologue IKE de savoir quel algorithme de hachage est associé à la signature. Ce processus devient encore plus lourd avec l’introduction de chaque nouvel algorithme. Reportez-vous à la section Internet Key Exchange pour plus d’informations sur IKEv2.
Vous pouvez relever ces défis avec la méthode d’authentification de signature numérique basée sur RFC 7427. Cette méthode est plus générique que la méthode d’authentification basée sur la signature, car les homologues IKE peuvent utiliser n’importe lequel des algorithmes de signature pris en charge et négocier l’algorithme de hachage de signature. Poursuivez votre lecture pour en savoir plus sur l’authentification des signatures dans IKEv2.
Implémentation de l’authentification des signatures dans IKEv2
Outre la prise en charge de l’authentification basée sur les signatures par algorithme, Junos OS prend également en charge la méthode d’authentification par signature numérique décrite dans le document RFC 7427. Dans cette méthode, la charge utile d’authentification IKEv2 indique non seulement le type de clé publique, mais également l’algorithme de hachage que l’appareil utilise pour générer la signature. L’appareil utilise la notification SIGNATURE_HASH_ALGORITHM pour informer son homologue de la prise en charge de la norme RFC 7427 et fournir la liste des algorithmes de hachage pris en charge.
Pour utiliser cette fonctionnalité, vous devez configurer la méthode d’authentification par signature numérique sur votre appareil.Pour plus d’informations sur la méthode d’authentification par signature numérique, reportez-vous à la section proposal (Security IKE). Vous pouvez utiliser l’option signature-hash-algorithm de configuration pour définir les algorithmes de hachage de signature spécifiques qui doivent correspondre, dans l’ordre hiérarchique, à chacun des algorithmes de hachage de signature reçus. Si vous ne spécifiez pas l’algorithme de hachage de signature, l’appareil correspond à l’algorithme de hachage de signature reçu de la liste par défaut de tous les algorithmes de hachage pris en charge. Reportez-vous à la section Signature Hash Algorithm (Security IKE).
Dans Junos OS, la méthode d’authentification implique les étapes suivantes qui sont définies dans le flux de messages IKEv2. Pour plus d’informations, reportez-vous à la RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2).
-
Dans un premier temps, les deux homologues IKE s’informent mutuellement de la liste des algorithmes de hachage pris en charge. Votre appareil envoie la charge utile SIGNATURE_HASH_ALGORITHM dans le message IKE_SA_INIT à l’appareil homologue et reçoit une réponse. Les pairs négocient ensuite un algorithme de hachage de signature.
-
Dans le message IKE_AUTH, les pairs échangent la méthode d’authentification par signature numérique.
L’appareil utilise la méthode d’authentification par certificat par défaut dans l’un ou l’autre des scénarios suivants :
-
Le répondeur ne prend pas en charge la norme RFC 7427.
-
L’initiateur ne prend pas en charge l’algorithme de hachage reçu.
Avantages
-
Flexible : comprend les signatures numériques traditionnelles et nouvelles.
-
Facilité d’utilisation : s’intègre à l’infrastructure à clé publique (PKI) existante.
-
Solution robuste : effectue une meilleure vérification de l’identité par rapport à la méthode d’authentification basée sur les signatures, ce qui améliore la sécurité et la fiabilité globales des homologues IKE.
Voir également
Protection IKE contre les attaques DDoS
Le déni de service (DoS) est l’une des attaques les plus courantes et pourtant les plus graves sur un réseau VPN IPsec non sécurisé. Une attaque par déni de service (DoS) offre un moyen rapide et facile de s’emparer du réseau, car elle ne nécessite pas beaucoup d’intervention sur l’infrastructure réseau. Les attaquants choisissentcette méthode pour prendre le contrôle du réseau.
Que se passe-t-il en cas d’attaque par déni de service ?
L’attaquant tente d’inonder et de bloquer progressivement le réseau avec trop de trafic, épuisant les ressources réseau et prenant le contrôle des ressources de l’appareil telles que la mémoire et le processeur. Si l’attaquant tente de contrôler à l’aide de plusieurs systèmes orchestrés, en attaquant de manière synchrone une seule cible, on parle d’attaque DoS distribuée (DDoS).
- Vulnérabilités DDoS sur les implémentations IKE
- Protection contre les attaques DDoS
- Méthodes de surveillance des attaques DDoS
Vulnérabilités DDoS sur les implémentations IKE
Lorsque l’homologue distant (initiateur) envoie un message SA_INIT, l’homologue local (répondeur) répond et alloue de la mémoire pour la structure du message. Nous appelons la session une session IKE semi-ouverte jusqu’à ce que l’authentification se produise à l’aide du message IKE_AUTH. Une fois que les homologues ont établi une association de sécurité IKE (SA), la session devient une session IKE entièrement ouverte.
Pour comprendre les vulnérabilités DDoS IKEv2, examinons quelques-unes des façons dont un attaquant peut créer un vecteur d’attaque facile contre les IKE SA :
-
Envoyer un grand nombre de messages SA_INIT (sans messages IKE_AUTH) pour lesquels l’attaquant peut créer des structures d’association de sécurité IKE semi-ouvertes. L’attaque oblige l’appareil à utiliser les ressources et à manquer de mémoire.
-
Envoyez un grand nombre de paquets de IKE_AUTH de courrier indésirable avec la SPI_i et la SPI_r correctes sur l’initiateur et le répondeur, respectivement. L’appareilmanque de mémoire pendant qu’il tente de déchiffrer les paquets.
-
Envoyez des paquets SA_INIT en continu. L’appareilmanque de mémoire lorsqu’il tente de générer des clés pour les paquets chiffrés.
-
Envoyez un grand nombre de demandes de renouvellement de clé par seconde pendant les sessions IKE ouvertes complètes.
-
Envoyez un grand nombre de messages avec des identifiants de message (ID) distincts. Le périphérique met en file d’attente tous les messages IKE entrants et manque de mémoire.
Comment protéger les implémentations IKE
Nous fournissons une infrastructure robuste pour atténuer et surveiller les attaques DDoS pour les protocoles IKEv1 et IKEv2. Vous pouvez vous protéger contre les attaques sur les implémentations IKE lorsque votre pare-feu exécute le processus iked (dans le junos-ike package) pour le service VPN IPsec.
Pour plus d’informations sur la protection DDoS pour IKEv2, reportez-vous à la RFC 8019, Protection des implémentations IKEv2 (Internet Key Exchange Protocol Version 2) contre les attaques par déni de service distribué. Nousfournissons une protection similaire pour IKEv1 lorsque votre pare-feu exécute le service VPN IPsec à l’aide du processus iked. Nous ne prenons pas en charge le mécanisme de puzzle client présenté par la RFC.
Protection contre les attaques DDoS
Vous pouvez activer plusieurs mécanismes de défense contre les attaques DDoS pendant le processus de création de l’association de sécurité IKE. Ces mécanismes comprennent la configuration d’une limitation de débit et d’une période de conservation pour les SA IKE semi-ouvertes, ainsi qu’une gestion plus poussée des taux de change entrants pour les demandes de reclé. Nous fournissons les mesures suivantes pour assurer la protection contre les attaques DDoS sur les IKE SA :
- Mesures de protection pourles SA IKE ou semi-ouvertes :
-
Le répondeur n’autorise pas la configuration des SAIKE semi-ouvertes pendant une certaine durée. Vous pouvez définir cette limite de manière à ce que le répondeur ne configure pas les SA tant qu’il n’a pas atteint la durée du délai d’expiration. Pour plus de détails, reportez-vous à la section session (Security IKE) pour l’option
timeout. -
Vous pouvez définir une limite sur le nombre maximal de SA IKE semi-ouvertes autorisées sur le répondeur. Lorsque le nombre total de SA IKE semi-ouvertes atteint le nombre maximal, le répondeur rejette les nouvelles connexions pour les SA IKEv1 et IKEv2. Pour plus de détails, voir l’option dans
max-countsession (Security IKE). -
Le répondeur applique des valeurs seuils sur le nombre de sessions pour les SA IKE semi-ouvertes. Lorsque le nombre total de SA IKE semi-ouvertes atteint les valeurs seuils :
-
Dans le cas des IKEv2 SA, le répondeur appelle le mécanisme de cookie pour toute nouvelle connexion.
-
Dans le cas des SA IKEv1, le répondeur rejette les nouvelles connexions.
Pour plus d’informations, reportez-vous à la section et aux options de la
send-cookiereduce-timeoutsection session (Security IKE).thresholds -
-
Le répondeur peut ignorer les sessions en double. Pour plus de détails, reportez-vous à l’option
discard-duplicate.session (Security IKE) -
Vous pouvez définir des délais d’attente pour les phases d’échec d’authentification et d’échec d’initiation. Pour plus d’informations, reportez-vous aux sections session (Security IKE) pour les options
backoff-timeouts,init-phase-failureetauth-phase-failure.
-
-
Pour les SA IKE entièrement ouvertes :
-
Vous pouvez configurer des taux maximaux de demandes de renouvellement de clés entrantes pour limiter les demandes dans un scénario mis à l’échelle. Pour plus de détails, voir l’option dans
incoming-exchange-max-ratessession (Security IKE).
-
-
Le répondeur peut bloquer une session IKE entrante des homologues en fonction de l’ID IKE de l’homologue. Pour plus de détails, reportez-vous à la section blocklists (Security IKE).
-
Pour les passerelles dynamiques, vous pouvez définir une limite pour le nombre de connexions au niveau de la configuration de la passerelle IKE à l’aide de l’option
connections-limit. Pour plus d’informations, consultez Passerelle (IKE de sécurité).
Pour plus d’informations sur la configuration de ces options, consultez Configurer la protection contre les attaques DDoS IKE.
Nous ne prenons pas en charge :
-
Protection DDoS avec le service VPN IPsec basé sur le processus kmd.
-
Protection contre les attaques par codage de hachage et de certificat d’URL , car nous ne prenons pas en charge ces types d’encodage.
Méthodes de surveillance des attaques DDoS
Nous fournissons les mécanismes suivants pour surveiller les attaques DDoS :
-
Utilisez la
show security ike security-associationscommande pour répertorier toutes les associationsde sécurité IKE matures et non matures. Pour plus d’informations, consultez show security ike security-associations. -
Utilisez la
show security ike statscommande pour afficher les statistiques IKE globales du tunnel VPN IPsec, telles que les statistiques en cours, établies et expirées. Pour plus d’informations, consultez afficher les statistiques ike de sécurité. -
Utilisez la
show security ike active-peercommande pour afficher les détails des négociations IKE réussies avec les homologues distants. Pour plus d’informations, consultez show security ike active-peer. -
Utilisez la
show security ike peers in-progresscommande pour afficher les détails des IKE SA en cours, y compris les IKE SA semi-ouverts. Pour plus de détails, reportez-vous à la section show security ike peers. Vous pouvez également voir les détails des homologues bloqués, en échec et en attente à l’aide de cette commande. -
Utilisez la
clear security ike peerscommande pour effacer les homologues IKE qui sont en cours d’interruption, bloqués, en échec ou en cours. Pour plus de détails, reportez-vous à la section clear security ike peers. -
Pour supprimer une association de sécurité IKE existante avec des pairs qui doit être bloquée pour d’autres communications, utilisez la
clear security ike security-associationscommande. Pour plus d’informations, consultez clear security ike security-associations. -
Les messages du journal system (syslog) IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF et IKE_GATEWAY_PEER_FAILED fournissent des détails sur les négociations IKE bloquées, annulées et échouées avec les homologues distants, respectivement.
-
Pour plus de sécurité, Junos OS fournit aux utilisateurs des services de protection contre les attaques système basées sur les paquets, telles que le filtrage, le nombre de sessions et la limitation de débit. Pour plus de détails, reportez-vous à la commande show firewall et à l’instruction ids-option au niveau de la hiérarchie [
edit security screen ids-option screen-name].
Configurer la protection contre les attaques DDoS IKE
Consultez cette section pour comprendre comment configurer la protection contre les attaques DDoS sur le protocole IKE.
Conditions préalables
Avant de configurer la protection contre les attaques DDoS IKE, assurez-vous que vous remplissez les conditions préalables suivantes :
-
Pare-feu SRX Series qui prend en charge
junos-ikele package permettant d’exécuter le service VPN IPsec à l’aide du processus iked. -
Le pare-feu SRX Series qui sert de point de terminaison local (le répondeur) est accessible à l’homologue IKE distant (l’initiateur).
-
Stratégie IKE pouvant associer une liste de blocage IKE.
Les actions suivantes sont impliquées dans la configuration de la protection contre les attaques DDoS IKE :
-
Gérez les SA IKE semi-ouvertes entrantes.
-
Gérez les SA IKE entièrement ouvertes entrantes.
-
Configurez plusieurs méthodes de blocage afin de bloquer les sessions IKE entrantes de différents homologues et associez l’une des listes de blocage à un pair IKE.
Reportez-vous aux tâches suivantes pour configurer ces actions.
- Configurer la session IKE pour les SA IKE semi-ouvertes
- Configurer la session IKE pour les SA IKE ouvertes complètes
- Configurer les listes de blocage de session IKE
Configurer la session IKE pour les SA IKE semi-ouvertes
Présentation
Assurez-vous de remplir toutes les conditions préalables décrites ci-dessus.
Dans cette section, vous allez voir comment configurer les délais d’expiration, le nombre maximal et les seuils pour les SA IKE semi-ouvertes. Les modifications de configuration s’appliquent aux nouvelles sessions, tandis que les sessions existantes continuent d’utiliser les valeurs par défaut lorsqu’elles n’ont pas été configurées explicitement précédemment. La portée de ces configurations au niveau de la hiérarchie [edit security ike session half-open] s’applique au niveau global et non au niveau de l’homologue.
Configuration
-
Pour définir le paramètre de durée de vie du répondeur à l’aide de l’option
timeout seconds:[edit] user@host# set security ike session half-open timeout 150
Pendant cette période, le répondeur n’autorise pas la configuration des SA IKE semi-ouvertes tant qu’il n’a pas atteint la durée du délai d’expiration. L’initiateur peut continuer à avoir une durée de délai d’expiration de 60 secondes, quelle que soit la configuration du répondeur.
-
Pour définir le paramètre de nombre maximal de répondeurs à l’aide de l’option
max-count value:[edit] user@host# set security ike session half-open max-count 1000
L’option définit le nombre maximal de sessions IKE semi-ouvertes sur le répondeur. La valeur par défaut est 300, si vous ne le spécifiez pas. La
max-countconfiguration désactive tous les seuils. Dans ce cas, vous devez explicitement configurer des seuils pour les faire respecter. -
Spécifiez les différents types d’actions à l’aide de l’option
thresholdlorsque le nombre de sessions du répondeur atteint la limite.-
Pour définir le nombre minimum de sessions IKE semi-ouvertes afin d’appliquer l’action des cookies à l’aide de l’option
send-cookie count:[edit] user@host# set security ike session half-open threshold send-cookie 500
Cela spécifie la limite de seuil à partir de laquelle le répondeur demande aux homologues distants de retenter l’ouverture de la session avec un cookie renvoyé à l’homologue dans la réponse initiale. Ici, lorsque la limite du nombre de sessions IKE semi-ouvertes atteint 500, le processus iked utilise un mécanisme de cookie pour les nouvelles sessions IKE.
-
Pour définir le nombre minimum de sessions IKE semi-ouvertes afin d’appliquer une action de délai d’attente réduit à l’aide de l’option
reduced-timeout count timeout seconds:[edit] user@host# set security ike session half-open threshold reduce-timeout 600 timeout 100
Ceci spécifie la limite à partir de laquelle le processus iked réduit la durée de vie des nouvelles SA IKE semi-ouvertes. Une fois que le nombre de sessions IKE du répondeur semi-ouvert est inférieur au seuil, les sessions IKE du répondeur semi-ouvert utilisent à nouveau la valeur de délai d’expiration par défaut.
-
-
Pour définir l’option
discard-duplicateafin d’ignorer les sessions IKE semi-ouvertes en double sans envoyer de réponse à l’initiateur :[edit] user@host# set security ike session half-open discard-duplicate
Pour une demande d’initiation de session (SA_INIT) dupliquée qui provient du même homologue, avec un cookie d’initiateur différent pour lequel il n’y a pas de IKE SA pendant que la négociation est en cours, le répondeur ignore le paquet.
-
Vous pouvez définir les délais d’attente à l’aide de l’option
backoff-timeouts.Cela laisse un certain temps à l’homologue distant pour se retirer en cas d’échec de l’initiation d’une session, ce qui garantit que le même homologue ne peut pas initier une nouvelle session pendant cette période. Une fois le délai d’attente écoulé, l’homologue peut lancer une nouvelle session. Le lancement de la session peut échouer en deux phases : la phase d’initialisation et la phase d’authentification.
-
Pour définir le délai d’attente en cas de défaillance pendant la phase IKE_AUTH à l’aide de l’option
backoff-timeouts auth-phase-failure value:[edit] user@host# set security ike session half-open backoff-timeouts auth-phase-failure 150
Lorsque vous configurez
auth-phase-failure, tout homologue distant figurant sur la liste de blocage effectue la désactivation même si vous ne configurez pas la fermeture en tant qu’action pour la règle de liste de blocage cible. Le délai d’attente de l’interruption est celui configuré pourauth-phase-failure. Dans cet exemple, l’appareil lance une nouvelle session au bout de 150 secondes. Pour remplacer ce délai d’attente d’une règle particulière, vous pouvez configurer explicitement l’actionbackoffde la listerulede blocage en mentionnant le délai d’expiration à l’extrémité [edit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level. -
Pour définir le délai d’attente en cas de défaillance pendant la phase SA_INIT à l’aide de l’option
backoff-timeouts init-phase-failure value:[edit] user@host# set security ike session half-open backoff-timeouts init-phase-failure 160
Dans cet exemple, l’appareil lance une nouvelle session au bout de 160 secondes.
-
Configurer la session IKE pour les SA IKE ouvertes complètes
Présentation
Assurez-vous de remplir toutes les conditions préalables décrites ci-dessus.
Dans cette section, vous allez voir comment configurer différents taux de requêtes entrantes pour les SA IKE ouvertes complètes à l’aide de l’option incoming-exchange-max-rates au niveau de la hiérarchie [edit security ike session full-open].
Configuration
Configurez l’option incoming-exchange-max-rates permettant de définir les taux maximaux pour les différents échanges initiés par l’homologue distant après l’établissement d’une IKE SA. Vous pouvez configurer trois types de taux de change : rekey IKE, rekey IPsec et keepalive (également connu sous le nom de Dead Peer Detection).
-
Pour définir le taux maximal de recléage IKE initié par l’homologue entrant à l’aide de l’option
incoming-exchange-max-rates ike-rekey value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates ike-rekey 200/60
L’option s’applique à la recléation IKEv2 sur une base par homologue avec un homologue existant où une SA IKE est déjà présente.
-
Pour définir le débit maximal de recléage IPsec SA initié par l’homologue entrant à l’aide de l’option
incoming-exchange-max-rates ipsec-rekey value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates ipsec-rekey 100/60
La limite s’applique par tunnel.
-
Pour définir le taux maximum de keepalive initié par l’homologue entrant à l’aide de l’option
incoming-exchange-max-rates keepalive value:[edit] user@host# set security ike session full-open incoming-exchange-max-rates keepalive 60/60
La limite s’applique par pair.
Configurer les listes de blocage de session IKE
Présentation
Assurez-vous de remplir toutes les conditions préalables décrites ci-dessus.
Pour bloquer une session IKE entrante à partir d’homologues en fonction de l’ID IKE de l’homologue, vous devez configurer une ou plusieurs listes de blocage. Chaque liste de blocage contient une ou plusieurs règles. Chaque règle est associée à un critère de correspondance et à une action.
Tenez compte des critères suivants lors de la configuration des listes de blocage :
-
Les règles de liste de blocage s’appliquent aux nouvelles SA IKE en cours de négociation et n’affectent pas les SA IKE existantes. À l’étape de l’authentification par l’homologue, l’appareil applique les règles de liste de blocage.
-
L’ordre d’application des règles dépend de l’ordre dans lequel ces règles sont énumérées.
-
Configurez les critères de correspondance en fonction du rôle (initiateur ou répondeur), d’un type d’ID (adresse IPv4 ou IPv6, nom d’hôte, nom distinctif, ID de messagerie ou ID de clé) et d’un modèle d’ID qui est une expression régulière correspondant à l’ID IKE.
-
Vous pouvez configurer chaque règle avec un type d’ID. Cela vous permet de configurer différents ID IKE pour différentes règles au sein de la même liste de blocage.
-
Configurez une action pour ignorer ou rejeter la connexion homologue. En fonction de la correspondance, l’appareil applique une action. Si vous le souhaitez, vous pouvez définir le minuteur d’interruption à l’aide de ces actions.
-
Reportez-vous à la liste de blocage dans la stratégie IKE associée à la passerelle IKE.
-
Chaque passerelle IKE ne prend en charge qu’un seul type d’ID IKE distant. Si vous attachez une liste de blocage à une passerelle et que vous la configurez avec des règles contenant différents ID IKE, la passerelle s’appliquera et ne correspondra qu’aux règles dont le type d’ID IKE est le même que celui configuré pour la passerelle IKE.
-
Les métriques de taux de configuration du tunnel avec des listes de blocage attachées aux passerelles IKE sont basées sur le nombre de règles configurées dans les listes de blocage.
Dans cette section, vous allez voir comment configurer des listes de blocage et les associer à une stratégie IKE.
Configuration
-
Pour créer une liste de blocage avec plusieurs règles :
-
Créez une liste de blocage.
[edit] user@host# set security ike blocklists blocklist1 description block_from_remote
-
Créez une ou plusieurs règles.
[edit] user@host# set security ike blocklists blocklist1 rule rule1 description rule_1 user@host# set security ike blocklists blocklist1 rule rule2 description rule_2
Vous pouvez créer plusieurs listes de blocage de ce type et leurs règles.
-
-
Pour configurer les critères de correspondance et spécifier l’action :
-
Configurez les critères de correspondance pour le rule1 dans la liste blocklist1de blocage .
[edit] user@host# set security ike blocklists blocklist1 rule rule1 match role initiator user@host# set security ike blocklists blocklist1 rule rule1 match id-type hostname user@host# set security ike blocklists blocklist1 rule rule1 match id-pattern "peer.*\.example\.net" user@host# set security ike blocklists blocklist1 rule rule2 match role initiator user@host# set security ike blocklists blocklist1 rule rule2 match id-type user-at-hostname user@host# set security ike blocklists blocklist1 rule rule2 match id-pattern "hr.example.com"
Pour configurer des listes de blocage à l’aide d’un groupe d’ID IKE ou d’ID IKE partiels, utilisez le
id-pattern valueavec un suffixe ou un préfixe. Par exemple, vous pouvez utiliser la valeur *.example.com lorsque vous devez faire correspondre hr.example.com, finance.example.com admin.example.com. Dans la règle rule1, l’appareil recherche le nom d’hôte qui correspond au modèle peer.*\.example\.net. Voici peer.example.net, peer.1.example.net et peer.uplink.example.net sont quelques correspondances potentielles. Dans la règle rule2, l’appareil recherche l’adresse e-mail qui correspond au modèle hr.example.com. De même, vous pouvez configurer un autre critère de correspondance pour les autres règles en fonction de différentsid-typeouid-pattern. Ces modèles utilisent l’expression régulière standard. -
Spécifiez l’action d’une correspondance :
[edit] user@host# set security ike blocklists blocklist1 rule rule1 then reject user@host# set security ike blocklists blocklist1 rule rule1 then backoff 60 user@host# set security ike blocklists blocklist1 rule rule2 then discard user@host# set security ike blocklists blocklist1 rule rule2 then backoff 100
-
-
Pour associer une liste de blocage à un homologue IKE :
-
Configurez la liste blocklist1 de blocage dans la stratégie ike_policy1IKE .
[edit] user@host# set security ike policy ike_policy1 blocklist blocklist1
-
Exemple : Configuration d’un équipement pour la validation de la chaîne de certificats homologues
Cet exemple montre comment configurer un périphérique pour les chaînes de certificats utilisées pour valider les périphériques homologues lors de la négociation IKE.
- Conditions préalables
- Présentation
- Configuration
- Vérification
- Échec IKE et IPsec SA pour un certificat révoqué
Conditions préalables
Avant de commencer, demandez l’adresse de l’autorité de certification (CA) et les informations dont elle a besoin (comme le mot de passe d’appel) lorsque vous soumettez des demandes de certificats locaux.
Présentation
Cet exemple montre comment configurer un périphérique local pour les chaînes de certificats, inscrire des certificats d’autorité de certification et des certificats locaux, vérifier la validité des certificats inscrits et vérifier l’état de révocation du périphérique homologue.
Topologie
Cet exemple montre les commandes de configuration et de fonctionnement sur l’hôte A, comme illustré à la section Figure 10. Un profil d’autorité de certification dynamique est automatiquement créé sur l’hôte A pour permettre à l’hôte A de télécharger la CRL à partir de l’autorité de certification Sales et de vérifier l’état de révocation du certificat de l’hôte B.
La configuration VPN IPsec pour la négociation des phases 1 et 2 est illustrée pour l’hôte A dans cet exemple. L’appareil homologue (hôte-B) doit être correctement configuré pour que les options de phase 1 et de phase 2 soient négociées avec succès et que des associations de sécurité (SA) soient établies. Reportez-vous à la section Configuration d’ID IKE distants pour les VPN de site à site pour obtenir des exemples de configuration d’appareils homologues pour les VPN.
Configuration
Pour configurer un périphérique pour les chaînes de certificats :
- Configurer les profils d’autorité de certification
- Certificats d’inscription
- Configurer les options du VPN IPsec
Configurer les profils d’autorité de certification
Configuration rapide de l’interface de ligne de commande
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 à la configuration de votre réseau, 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 pki ca-profile Root-CA ca-identity CA-Root set security pki ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ set security pki ca-profile Root-CA revocation-check crl set security pki ca-profile Eng-CA ca-identity Eng-CA set security pki ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ set security pki ca-profile Eng-CA revocation-check crl set security pki ca-profile Dev-CA ca-identity Dev-CA set security pki ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ set security pki ca-profile Dev-CA revocation-check crl
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 façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer les profils d’autorité de certification :
Créez le profil d’autorité de certification pour l’autorité de certification racine.
[edit security pki] user@host# set ca-profile Root-CA ca-identity CA-Root user@host# set ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ user@host# set ca-profile Root-CA revocation-check crl
Créez le profil CA pour Eng-CA.
[edit security pki] user@host# set ca-profile Eng-CA ca-identity Eng-CA user@host# set ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ user@host# set ca-profile Eng-CA revocation-check crl
Créez le profil d’autorité de certification pour Dev-CA.
[edit security pki] user@host# set ca-profile Dev-CA ca-identity Dev-CA user@host# set ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ user@host# set ca-profile Dev-CA revocation-check crl
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security pki commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security pki
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Root/";
}
revocation-check {
crl ;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Eng/";
}
revocation-check {
crl ;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Dev/";
}
revocation-check {
crl ;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Certificats d’inscription
Procédure étape par étape
Pour inscrire des certificats :
Inscrivez les certificats d’autorité de certification.
user@host> request security pki ca-certificate enroll ca-profile Root-CA
user@host> request security pki ca-certificate enroll ca-profile Eng-CA
user@host> request security pki ca-certificate enroll ca-profile Dev-CA
Tapez yes à l’invite pour charger le certificat de l’autorité de certification.
Vérifiez que les certificats de l’autorité de certification sont inscrits dans l’appareil.
user@host> show security pki ca-certificate ca-profile Root-CA Certificate identifier: Root-CA Issued to: Root-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-14-2012 22:19 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Eng-CA Certificate identifier: Eng-CA Issued to: Eng-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-15-2012 01:02 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Dev-CA Certificate identifier: Dev-CA Issued to: Dev-CA, Issued by: C = us, O = example, CN = Eng-CA Validity: Not before: 08-15-2012 17:41 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)Vérifiez la validité des certificats d’autorité de certification inscrits.
user@host> request security pki ca-certificate verify ca-profile Root-CA CA certificate Root-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Eng-CA CA certificate Eng-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Dev-CA CA certificate Dev-CA verified successfully
Générez une paire de clés.
user@host> request security pki generate-key-pair certificate-id Host-A type rsa size 1024
Inscrivez le certificat local.
user@host> request security pki local-certificate enroll certificate-id Host-A ca-profile Dev-CA challenge-password example domain-name host-a.example.net email host-a@example.net subject DC=example,CN=Host-A, OU=DEV,O=PKI,L=Sunnyvale,ST=CA,C=US
Vérifiez que le certificat local est inscrit dans l’appareil.
user@host> show security pki local-certificate Issued to: Host-A, Issued by: C = us, O = example, CN = Dev-CA Validity: Not before: 09-17-2012 22:22 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(1024 bits)Vérifiez la validité du certificat local inscrit.
user@host> request security pki local-certificate verify certificate-id Host-A Local certificate Host-A verification success
Vérifiez le téléchargement de la liste de révocation de certificats pour connaître les profils d’autorité de certification configurés.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02
Configurer les options du VPN IPsec
Configuration rapide de l’interface de ligne de commande
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 à la configuration de votre réseau, 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 ike proposal ike_cert_prop_01 authentication-method rsa-signatures set security ike proposal ike_cert_prop_01 dh-group group5 set security ike proposal ike_cert_prop_01 authentication-algorithm sha1 set security ike proposal ike_cert_prop_01 encryption-algorithm aes-256-cbc set security ike policy ike_cert_pol_01 mode main set security ike policy ike_cert_pol_01 proposals ike_cert_prop_01 set security ike policy ike_cert_pol_01 certificate local-certificate Host-A set security ike gateway ike_cert_gw_01 ike-policy ike_cert_pol_01 set security ike gateway ike_cert_gw_01 address 192.0.2.51 set security ike gateway ike_cert_gw_01 external-interface ge-0/0/1.0 set security ike gateway ike_cert_gw_01 local-identity 192.0.2.31 set security ipsec proposal ipsec_prop_01 protocol esp set security ipsec proposal ipsec_prop_01 authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec_prop_01 encryption-algorithm 3des-cbc set security ipsec proposal ipsec_prop_01 lifetime-seconds 300 set security ipsec policy ipsec_pol_01 proposals ipsec_prop_01 set security ipsec vpn ipsec_cert_vpn_01 bind-interface st0.1 set security ipsec vpn ipsec_cert_vpn_01 ike gateway ike_cert_gw_01 set security ipsec vpn ipsec_cert_vpn_01 ike ipsec-policy ipsec_pol_01
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 façon de procéder, consultez Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur CLI.
Pour configurer les options du VPN IPsec :
Configurez les options de la phase 1.
[edit security ike proposal ike_cert_prop_01] user@host# set authentication-method rsa-signatures user@host# set dh-group group5 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm aes-256-cbc [edit security ike policy ike_cert_pol_01] user@host# set mode main user@host# set proposals ike_cert_prop_01 user@host# set certificate local-certificate Host-A [edit security ike gateway ike_cert_gw_01] user@host# set ike-policy ike_cert_pol_01 user@host# set address 192.0.2.51 user@host# set external-interface ge-0/0/1.0 user@host# set local-identity 192.0.2.31
Configurez les options de la phase 2.
[edit security ipsec proposal ipsec_prop_01] user@host# set protocol esp user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 300 [edit security ipsec policy ipsec_pol_01] user@host# set proposals ipsec_prop_01 [edit security ipsec vpn ipsec_cert_vpn_01] user@host# set bind-interface st0.1 user@host# set ike gateway ike_cert_gw_01 user@host# set ike ipsec-policy ipsec_pol_01
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant les show security ike commandes et show security ipsec . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security ike
proposal ike_cert_prop_01 {
authentication-method rsa-signatures;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike_cert_pol_01 {
mode main;
proposals ike_cert_prop_01;
certificate {
local-certificate Host-A;
}
}
gateway ike_cert_gw_01 {
ike-policy ike_cert_pol_01;
address 192.0.2.51;
external-interface ge-0/0/1.0;
}
[edit]
user@host# show security ipsec
proposal ipsec_prop_01 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 300;
}
policy ipsec_pol_01 {
proposals ipsec_prop_01;
}
vpn ipsec_cert_vpn_01 {
bind-interface st0.1;
ike {
gateway ike_cert_gw_01;
ipsec-policy ipsec_pol_01;
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Si la validation du certificat réussit lors de la négociation IKE entre équipements homologues, des associations de sécurité IKE et IPsec sont établies.
L’IKE SA est UP si le certificat est valide. La SA IKE est DOWN et l’SA IPSEC est formée si le certificat est révoqué, uniquement si la vérification de révocation est configurée sur l’appareil homologue
Vérification de l’état IKE Phase 1
But
Vérifiez l’état de la phase 1 de l’IKE.
Action
Entrez la show security ike security-associations commande à partir du mode opérationnel.
user@host> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
2090205 DOWN 285feacb50824495 59fca3f72b64da10 Main 192.0.2.51
Vérification de l’état IPsec Phase 2
But
Vérifiez l’état IPsec Phase 2.
Action
Entrez la show security ipsec security-associations commande à partir du mode opérationnel.
user@host> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/sha1 a4756de9 207/ unlim - root 500 192.0.2.51
>131073 ESP:3des/sha1 353bacd3 207/ unlim - root 500 192.0.2.51
Échec IKE et IPsec SA pour un certificat révoqué
Vérification des certificats révoqués
Problème
Si la validation du certificat échoue lors de la négociation IKE entre périphériques homologues, vérifiez que le certificat de l’homologue n’a pas été révoqué. Un profil d’autorité de certification dynamique permet à l’appareil local de télécharger la liste de révocation de certificats à partir de l’autorité de certification de l’homologue et de vérifier l’état de révocation du certificat de l’homologue. Pour activer les profils d’autorité de certification dynamiques, l’option revocation-check crl doit être configurée sur un profil d’autorité de certification parent.
Solution
Pour vérifier l’état de révocation du certificat d’un homologue :
Identifiez le profil d’autorité de certification dynamique qui affichera la CRL de l’appareil homologue en entrant la show security pki crl commande à partir du mode opérationnel.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02 CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sales-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02Le profil
dynamic-001de l’autorité de certification est automatiquement créé sur l’hôte A afin que l’hôte A puisse télécharger la liste de révocation de certificats à partir de l’autorité de certification de l’hôte B (Sales-CA) et vérifier l’état de révocation du certificat de l’homologue.Affichez les informations de la CRL pour le profil d’autorité de certification dynamique en entrant la show security pki crl ca-profile dynamic-001 detail commande à partir du mode opérationnel.
Entrer
user@host> show security pki crl ca-profile dynamic-001 detail CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sub11 Effective date: 09-19-2012 17:29 Next update: 09-20-2012 01:49 Revocation List: Serial number Revocation date 10647C84 09-19-2012 17:29 UTCLe certificat de l’hôte B (numéro de série 10647084) a été révoqué.
IKEv2 Fragmentation
Fragmentation des messages
La fragmentation des messages IKEv2, telle que décrite dans la RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, permet à IKEv2 de fonctionner dans des environnements où les fragments IP peuvent être bloqués et les homologues ne peuvent pas établir d’association de sécurité IPsec (SA). La fragmentation IKEv2 divise un message IKEv2 volumineux en un ensemble de messages plus petits afin qu’il n’y ait pas de fragmentation au niveau IP. La fragmentation a lieu avant que le message d’origine ne soit chiffré et authentifié, de sorte que chaque fragment est chiffré et authentifié séparément. Sur le récepteur, les fragments sont collectés, vérifiés, déchiffrés et fusionnés dans le message d’origine.
Pour que la fragmentation IKEv2 se produise, les deux homologues VPN doivent indiquer la prise en charge de la fragmentation en incluant la charge utile de notification IKEV2_FRAGMENTATION_SUPPORTED dans l’échange IKE_SA_INIT. Si les deux homologues indiquent la prise en charge de la fragmentation, c’est à l’initiateur de l’échange de messages de déterminer si la fragmentation IKEv2 est utilisée ou non.
Sur les pare-feu SRX Series, un maximum de 32 fragments est autorisé par message IKEv2. Si le nombre de fragments de message IKEv2 à envoyer ou à recevoir dépasse 32, les fragments sont abandonnés et le tunnel n’est pas établi. La retransmission de fragments de messages individuels n’est pas prise en charge
Configuration
Sur les pare-feu SRX Series, la fragmentation IKEv2 est activée par défaut pour les messages IPv4 et IPv6. Pour désactiver la fragmentation IKEv2, utilisez l’instruction disable au niveau de la hiérarchie [edit security ike gateway gateway-name fragmentation]. Vous pouvez également utiliser l’instruction size pour configurer la taille du paquet auquel les messages sont fragmentés ; la taille du paquet est comprise entre 500 et 1300 octets. Si size elle n’est pas configurée, la taille de paquet par défaut est de 576 octets pour le trafic IPv4 et de 1280 octets pour le trafic IPv6. Un paquet IKEv2 dont la taille est supérieure à la taille de paquet configurée est fragmenté.
Une fois que la fragmentation IKEv2 est désactivée ou activée ou que la taille du fragment de paquet est modifiée, les tunnels VPN hébergés sur la passerelle IKE sont arrêtés et les SA IKE et IPsec sont renégociées.
Avertissements
Les fonctionnalités suivantes ne sont pas prises en charge avec la fragmentation IKEv2 :
Découverte MTU de chemin.
SNMP.
Voir également
Politique IKE avec une autorité de certification de confiance
Cet exemple montre comment lier un serveur d’autorité de certification approuvé à une stratégie IKE de l’homologue.
Avant de commencer, vous devez disposer d’une liste de toutes les autorités de certification approuvées que vous souhaitez associer à la stratégie IKE de l’homologue.
Vous pouvez associer une stratégie IKE à un seul profil d’autorité de certification de confiance ou à un groupe d’autorités de certification de confiance. Pour établir une connexion sécurisée, la passerelle IKE utilise la stratégie IKE pour se limiter au groupe configuré d’autorités de certification (profils ca) lors de la validation du certificat. Un certificat émis par une source autre que l’autorité de certification approuvée ou le groupe d’autorités de certification approuvées n’est pas validé. S’il existe une demande de validation de certificat provenant d’une stratégie IKE, le profil d’autorité de certification associé à la stratégie IKE validera le certificat. Si une stratégie IKE n’est associée à aucune autorité de certification, le certificat est validé par défaut par l’un des profils d’autorité de certification configurés.
Dans cet exemple, un profil d’autorité de certification nommé root-ca est créé et un root-ca-identity est associé au profil.
Vous pouvez configurer un maximum de 20 profils d’autorités de certification que vous souhaitez ajouter à un groupe d’autorités de certification approuvées. Vous ne pouvez pas valider votre configuration si vous configurez plus de 20 profils d’autorités de certification dans un groupe d’autorités de certification approuvées.
Pour afficher les profils d’autorité de certification et les groupes d’autorités de certification approuvés configurés sur votre appareil, exécutez show security pki la commande.
user@host# show security ike
proposal ike_prop {
authentication-method rsa-signatures;
dh-group group2;
authentication-algorithm sha-256;
encryption-algorithm aes-256-cbc;
}
policy ike_policy {
proposals ike_prop;
certificate {
local-certificate SPOKE;
trusted-ca ca-profile root-ca;
}
}
La show security ike commande affiche le groupe de profils CA sous la stratégie IKE nommée ike_policy et le certificat associé à la stratégie IKE.
Voir également
Configuration d’un répondeur de tunnel d’établissement uniquement dans IKE
Cette rubrique montre comment configurer l’établissement de tunnels répondant uniquement dans Internet Key Exchange (IKE). Lancez les tunnels à partir de l’homologue distant et envoyez le trafic à travers tous les tunnels. Spécifie le moment où IKE est activé.
Sur les pare-feu SRX Series, l’option establish-tunnels prend en charge les valeurs et responder-onlyresponder-only-no-rekey au niveau de la [edit security ipsec vpn vpn-name] hiérarchie.
Ces options ne sont prises en charge que sur un VPN de site à site. Ces options ne sont pas prises en charge sur Auto VPN.
Les responder-only options et responder-only-no-rekey n’établissent aucun tunnel VPN à partir de l’appareil, de sorte que le tunnel VPN est initié à partir de l’homologue distant. Lorsque vous configurez responder-only, un tunnel établi redéfinit les clés IKE et IPsec en fonction des valeurs de durée de vie IKE et IPsec configurées. Lorsque vous configurez responder-only-no-rekey, un tunnel établi ne recrée pas de clé à partir de l’appareil et s’appuie sur l’homologue distant pour lancer la reclé. Si l’homologue distant ne lance pas de reclé, le démantèlement du tunnel se produit après l’expiration de la durée de vie du matériel.
Avant de commencer :
Comprendre comment établir un tunnel IPsec IKE AutoKey. Lire Présentation d’IPsec.
Pour configurer l’établissement d’un répondeur de tunnel uniquement dans IKE :
Comportement du répondeur IKEv2 spécifique à la plate-forme uniquement
Utilisez l’Explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à vos plateformes.
| Plate-forme | Différence |
|---|---|
| SRX Series |
|
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' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
responder-only-no-rekey les valeurs de responder-only l’option establish-tunnels au [edit security ipsec vpn vpn-name] niveau hiérarchique sont introduites sur la gamme SRX5000 dans Junos OS version 19.1R1.