Guide de l'utilisateur de configuration des paramètres de sécurité CISCO SD-WAN

Par souci de simplification et de cohérence, la solution Cisco SD-WAN a été rebaptisée Cisco Catalyst SD-WAN. De plus, à partir de Cisco IOS XE SD-WAN version 17.12.1a et de Cisco Catalyst SD-WAN version 20.12.1, les modifications de composants suivantes sont applicables : Cisco vManage vers Cisco Catalyst SD-WAN Manager, Cisco vAnalytics vers Cisco Catalyst SD-WAN Analytics, Cisco vBond vers Cisco Catalyst SD-WAN Validator et Cisco vSmart vers Cisco Catalyst SD-WAN Controller. Consultez les dernières notes de version pour une liste complète de toutes les modifications apportées au nom de la marque des composants. Pendant la transition vers les nouveaux noms, certaines incohérences peuvent être présentes dans la documentation en raison d'une approche progressive des mises à jour de l'interface utilisateur du produit logiciel.

Cette section décrit comment modifier les paramètres de sécurité du plan de contrôle et du plan de données dans le réseau superposé Cisco Catalyst SD-WAN.

Configurer les paramètres de sécurité du plan de contrôle, sur

Configurer les paramètres de sécurité du plan de données, sur
Configurez les tunnels IPsec compatibles IKE, sur

Désactivez les algorithmes de chiffrement SSH faibles sur Cisco SD-WAN Manager, sur

Configurer les paramètres de sécurité du plan de contrôle

Par défaut, le plan de contrôle utilise DTLS comme protocole qui assure la confidentialité sur tous ses tunnels. DTLS fonctionne sur UDP. Vous pouvez modifier le protocole de sécurité du plan de contrôle en TLS, qui s'exécute sur TCP. La principale raison d'utiliser TLS est que, si vous considérez le contrôleur Cisco SD-WAN comme un serveur, les pare-feu protègent mieux les serveurs TCP que les serveurs UDP. Vous configurez le protocole de tunnel du plan de contrôle sur un contrôleur Cisco SD-WAN : vSmart(config)# security control protocol tls Avec cette modification, tous les tunnels du plan de contrôle entre le contrôleur Cisco SD-WAN et les routeurs et entre le contrôleur Cisco SD-WAN et Cisco SD-WAN Manager utilisent TLS. Les tunnels du plan de contrôle vers Cisco Catalyst SD-WAN Validator utilisent toujours DTLS, car ces connexions doivent être gérées par UDP. Dans un domaine avec plusieurs contrôleurs Cisco SD-WAN, lorsque vous configurez TLS sur l'un des contrôleurs Cisco SD-WAN, tous les tunnels du plan de contrôle de ce contrôleur vers les autres contrôleurs utilisent TLS. Autrement dit, TLS a toujours la priorité sur DTLS. Cependant, du point de vue des autres contrôleurs Cisco SD-WAN, si vous n'avez pas configuré TLS sur eux, ils utilisent TLS sur le tunnel du plan de contrôle uniquement vers ce contrôleur Cisco SD-WAN, et ils utilisent des tunnels DTLS vers tous les autres contrôleurs Cisco SD-WAN. Contrôleurs Cisco SD-WAN et à tous leurs routeurs connectés. Pour que tous les contrôleurs Cisco SD-WAN utilisent TLS, configurez-le sur chacun d'eux. Par défaut, le contrôleur Cisco SD-WAN écoute sur le port 23456 les requêtes TLS. Pour modifier cela : vSmart(config)# security control tls-port number Le port peut être un numéro compris entre 1025 et 65535. Pour afficher les informations de sécurité du plan de contrôle, utilisez la commande show control connections sur le contrôleur Cisco SD-WAN. Par exempleampchier : vSmart-2# affiche les connexions de contrôle

Configurer DTLS dans Cisco SD-WAN Manager

Si vous configurez Cisco SD-WAN Manager pour utiliser TLS comme protocole de sécurité du plan de contrôle, vous devez activer la redirection de port sur votre NAT. Si vous utilisez DTLS comme protocole de sécurité du plan de contrôle, vous n’avez rien à faire. Le nombre de ports transférés dépend du nombre de processus vdaemon exécutés sur Cisco SD-WAN Manager. Pour afficher des informations sur ces processus et sur le nombre de ports en cours de transfert, utilisez la commande show control summary qui montre que quatre processus démons sont en cours d'exécution :

Pour voir les ports d'écoute, utilisez la commande show control local-properties : vManage# show control local-properties

Cette sortie montre que le port TCP d'écoute est 23456. Si vous exécutez Cisco SD-WAN Manager derrière un NAT, vous devez ouvrir les ports suivants sur le périphérique NAT :

23456 (base – port de l'instance 0)

23456 + 100 (base + 100)
23456 + 200 (base + 200)

23456 + 300 (base + 300)

Notez que le nombre d'instances est le même que le nombre de cœurs que vous avez attribués à Cisco SD-WAN Manager, jusqu'à un maximum de 8.

Configurer les paramètres de sécurité à l'aide du modèle de fonctionnalité de sécurité

Utilisez le modèle de fonctionnalité de sécurité pour tous les périphériques Cisco vEdge. Sur les routeurs périphériques et sur Cisco SD-WAN Validator, utilisez ce modèle pour configurer IPsec pour la sécurité du plan de données. Sur Cisco SD-WAN Manager et Cisco SD-WAN Controller, utilisez le modèle de fonctionnalité de sécurité pour configurer DTLS ou TLS pour la sécurité du plan de contrôle.

Configurer les paramètres de sécurité

Dans le menu Cisco SD-WAN Manager, choisissez Configuration > Modèles.

Cliquez sur Modèles de fonctionnalités, puis cliquez sur Ajouter un modèle.
Note Dans Cisco vManage version 20.7.1 et versions antérieures, les modèles de fonctionnalités sont appelés fonctionnalités.
Dans la liste Appareils dans le volet de gauche, choisissez un appareil. Les modèles applicables au périphérique sélectionné apparaissent dans le volet de droite.

Cliquez sur Sécurité pour ouvrir le modèle.
Dans le champ Nom du modèle, saisissez un nom pour le modèle. Le nom peut comporter jusqu'à 128 caractères et ne peut contenir que des caractères alphanumériques.

Dans le champ Description du modèle, saisissez une description du modèle. La description peut comporter jusqu'à 2048 XNUMX caractères et ne peut contenir que des caractères alphanumériques.

Lorsque vous ouvrez pour la première fois un modèle de fonctionnalité, pour chaque paramètre ayant une valeur par défaut, la portée est définie sur Par défaut (indiquée par une coche) et le paramètre ou la valeur par défaut est affiché. Pour modifier la valeur par défaut ou saisir une valeur, cliquez sur le menu déroulant Portée à gauche du champ de paramètre et choisissez l'une des options suivantes :

Tableau 1 :

Paramètre Portée

Description de la portée

Spécifique au périphérique (indiqué par une icône d'hôte)

Utilisez une valeur spécifique à l'appareil pour le paramètre. Pour les paramètres spécifiques à l'appareil, vous ne pouvez pas saisir de valeur dans le modèle de fonctionnalité. Vous saisissez la valeur lorsque vous attachez un appareil Viptela à un modèle d'appareil.

Lorsque vous cliquez sur Spécifique au périphérique, la zone Entrer la clé s'ouvre. Cette boîte affiche une clé, qui est une chaîne unique qui identifie le paramètre dans un CSV file que vous créez. Ce file est une feuille de calcul Excel contenant une colonne pour chaque clé. La ligne d'en-tête contient les noms de clés (une clé par colonne), et chaque ligne suivante correspond à un périphérique et définit les valeurs des clés de ce périphérique. Vous téléchargez le CSV file lorsque vous attachez un appareil Viptela à un modèle d'appareil. Pour plus d’informations, consultez Créer une feuille de calcul de variables de modèle.

Pour modifier la clé par défaut, tapez une nouvelle chaîne et déplacez le curseur hors de la zone Enter Key.

ExampLes paramètres spécifiques à l'appareil sont l'adresse IP du système, le nom d'hôte, la localisation GPS et l'ID du site.

Paramètre Portée	Description de la portée
Global (indiqué par une icône de globe)	Entrez une valeur pour le paramètre et appliquez cette valeur à tous les appareils. ExampLes paramètres que vous pouvez appliquer globalement à un groupe de périphériques sont le serveur DNS, le serveur Syslog et les MTU d'interface.

Configurer la sécurité du plan de contrôle

Note
La section Configurer la sécurité du plan de contrôle s'applique uniquement au gestionnaire Cisco SD-WAN et au contrôleur Cisco SD-WAN. Pour configurer le protocole de connexion du plan de contrôle sur une instance du gestionnaire Cisco SD-WAN ou un contrôleur Cisco SD-WAN, choisissez la zone Configuration de base. et configurez les paramètres suivants :

Tableau 2 :

Paramètre Nom

Description

Protocole

Choisissez le protocole à utiliser sur les connexions du plan de contrôle à un contrôleur Cisco SD-WAN :

• DTLS (DatagRAM Transport Layer Security). C'est la valeur par défaut.

• TLS (sécurité de la couche de transport)

Contrôler le port TLS

Si vous avez sélectionné TLS, configurez le numéro de port à utiliser :Gamme: 1025 à 65535Défaut: 23456

Cliquez sur Enregistrer

Configurer la sécurité du plan de données
Pour configurer la sécurité du plan de données sur un validateur Cisco SD-WAN ou un routeur Cisco vEdge, choisissez les onglets Configuration de base et Type d'authentification et configurez les paramètres suivants :

Tableau 3 :

Paramètre Nom	Description
Temps de retouche	Spécifiez la fréquence à laquelle un routeur Cisco vEdge modifie la clé AES utilisée sur sa connexion DTLS sécurisée au contrôleur Cisco SD-WAN. Si le redémarrage progressif OMP est activé, le temps de nouvelle saisie doit être au moins deux fois supérieur à la valeur du temporisateur de redémarrage progressif OMP.Gamme: 10 à 1209600 secondes (14 jours)Défaut: 86400 24 secondes (XNUMX heures)
Fenêtre de relecture	Spécifiez la taille de la fenêtre de relecture glissante. Valeurs: 64, 128, 256, 512, 1024, 2048, 4096, 8192 paquetsDéfaut: 512 paquets
IPsec saisie par paire	Ceci est désactivé par défaut. Cliquez sur On pour l'allumer.

Paramètre Nom

Description

Type d'authentification

Sélectionnez les types d'authentification dans Authentification Liste, puis cliquez sur la flèche pointant vers la droite pour déplacer les types d'authentification vers le Liste sélectionnée colonne.

Types d'authentification pris en charge à partir de Cisco SD-WAN version 20.6.1 :

• esp: active le cryptage Encapsulated Security Payload (ESP) et la vérification de l’intégrité sur l’en-tête ESP.

• ip-udp-esp : Active le cryptage ESP. En plus des contrôles d'intégrité sur l'en-tête ESP et la charge utile, les contrôles incluent également les en-têtes IP externes et UDP.

• ip-udp-esp-no-id: ignore le champ ID dans l'en-tête IP afin que Cisco Catalyst SD-WAN puisse fonctionner en conjonction avec des périphériques non Cisco.

• aucun: désactive la vérification de l'intégrité des paquets IPSec. Nous ne recommandons pas d'utiliser cette option.

Types d'authentification pris en charge dans Cisco SD-WAN version 20.5.1 et versions antérieures :

• ah-non-id: Activez une version améliorée de AH-SHA1 HMAC et ESP HMAC-SHA1 qui ignore le champ ID dans l’en-tête IP externe du paquet.

• ah-sha1-hmac: Activez AH-SHA1 HMAC et ESP HMAC-SHA1.

• aucun: Sélectionnez aucune authentification.

• sha1-hmac: Activez ESP HMAC-SHA1.

Note Pour un périphérique Edge exécuté sur Cisco SD-WAN version 20.5.1 ou antérieure, vous avez peut-être configuré des types d'authentification à l'aide d'un Sécurité modèle. Lorsque vous mettez à niveau le périphérique vers Cisco SD-WAN version 20.6.1 ou ultérieure, mettez à jour les types d'authentification sélectionnés dans le Sécurité modèle aux types d'authentification pris en charge à partir de Cisco SD-WAN version 20.6.1. Pour mettre à jour les types d'authentification, procédez comme suit :

1. Dans le menu Cisco SD-WAN Manager, choisissez Configuration >

Modèles.

2. Cliquez Modèles de fonctionnalités.

3. Trouver le Sécurité modèle à mettre à jour et cliquez sur… et cliquez Modifier.

4. Cliquez Mise à jour. Ne modifiez aucune configuration.

Cisco SD-WAN Manager met à jour le Sécurité modèle pour afficher les types d’authentification pris en charge.

Cliquez sur Enregistrer.

Configurer les paramètres de sécurité du plan de données

Dans le plan de données, IPsec est activé par défaut sur tous les routeurs et, par défaut, les connexions de tunnel IPsec utilisent une version améliorée du protocole Encapsulated Security Payload (ESP) pour l'authentification sur les tunnels IPsec. Sur les routeurs, vous pouvez modifier le type d'authentification, le délai de nouvelle saisie IPsec et la taille de la fenêtre anti-relecture IPsec.

Configurer les types d'authentification autorisés

Types d'authentification dans Cisco SD-WAN version 20.6.1 et versions ultérieures
À partir de Cisco SD-WAN version 20.6.1, les types d'intégrité suivants sont pris en charge :

esp : cette option active le cryptage Encapsulated Security Payload (ESP) et la vérification de l'intégrité sur l'en-tête ESP.
ip-udp-esp : Cette option active le cryptage ESP. En plus des contrôles d'intégrité sur l'en-tête ESP et la charge utile, les contrôles incluent également les en-têtes IP externes et UDP.
ip-udp-esp-no-id : Cette option est similaire à ip-udp-esp, cependant, le champ ID de l'en-tête IP externe est ignoré. Configurez cette option dans la liste des types d'intégrité pour que le logiciel Cisco Catalyst SD-WAN ignore le champ ID dans l'en-tête IP afin que le logiciel Cisco Catalyst SD-WAN puisse fonctionner conjointement avec des périphériques non Cisco.
none : Cette option désactive la vérification de l'intégrité des paquets IPSec. Nous ne recommandons pas d'utiliser cette option.

Par défaut, les connexions par tunnel IPsec utilisent une version améliorée du protocole Encapsulated Security Payload (ESP) pour l'authentification. Pour modifier les types d'intégrité négociés ou pour désactiver le contrôle d'intégrité, utilisez la commande suivante : Integrity-type { none | ip-udp-esp | ip-udp-esp-no-id | surtout }

Types d'authentification avant la version 20.6.1 de Cisco SD-WAN
Par défaut, les connexions par tunnel IPsec utilisent une version améliorée du protocole Encapsulated Security Payload (ESP) pour l'authentification. Pour modifier les types d'authentification négociés ou pour désactiver l'authentification, utilisez la commande suivante : Device(config)# security ipsec ignition-type (ah-sha1-hmac | ah-no-id | sha1-hmac | | none) Par défaut, IPsec les connexions par tunnel utilisent AES-GCM-256, qui fournit à la fois le cryptage et l'authentification. Configurez chaque type d'authentification avec une commande de type d'authentification ipsec de sécurité distincte. Les options de commande correspondent aux types d’authentification suivants, répertoriés du plus fort au moins fort :

Note
Le sha1 dans les options de configuration est utilisé pour des raisons historiques. Les options d'authentification indiquent dans quelle mesure la vérification de l'intégrité des paquets est effectuée. Ils ne précisent pas l'algorithme qui vérifie l'intégrité. À l'exception du chiffrement du trafic multicast, les algorithmes d'authentification pris en charge par Cisco Catalyst SD WAN n'utilisent pas SHA1. Cependant, dans Cisco SD-WAN version 20.1.x et versions ultérieures, la monodiffusion et la multidiffusion n'utilisent pas SHA1.

ah-sha1-hmac permet le cryptage et l'encapsulation à l'aide d'ESP. Cependant, en plus des contrôles d'intégrité sur l'en-tête ESP et la charge utile, les contrôles incluent également les en-têtes IP externes et UDP. Par conséquent, cette option prend en charge un contrôle d’intégrité du paquet similaire au protocole Authentication Header (AH). Toute l'intégrité et le cryptage sont effectués à l'aide d'AES-256-GCM.
ah-no-id active un mode similaire à ah-sha1-hmac, cependant, le champ ID de l'en-tête IP externe est ignoré. Cette option prend en charge certains périphériques SD-WAN non Cisco Catalyst, notamment le NAT Apple AirPort Express, qui présentent un bogue qui entraîne la modification du champ ID dans l'en-tête IP, un champ non modifiable. Configurez l'option ah-no-id dans la liste des types d'authentification pour que le logiciel Cisco Catalyst SD-WAN AH ignore le champ ID dans l'en-tête IP afin que le logiciel Cisco Catalyst SD-WAN puisse fonctionner conjointement avec ces périphériques.

sha1-hmac permet le cryptage ESP et la vérification de l'intégrité.
none ne correspond à aucune authentification. Cette option ne doit être utilisée que si elle est requise pour un débogage temporaire. Vous pouvez également choisir cette option dans les situations où l’authentification et l’intégrité du plan de données ne posent pas de problème. Cisco ne recommande pas d'utiliser cette option pour les réseaux de production.

Pour plus d’informations sur les champs de paquets de données affectés par ces types d’authentification, consultez Intégrité du plan de données. Les appareils Cisco IOS XE Catalyst SD-WAN et les appareils Cisco vEdge annoncent leurs types d'authentification configurés dans leurs propriétés TLOC. Les deux routeurs de chaque côté d'une connexion tunnel IPsec négocient l'authentification à utiliser sur la connexion entre eux, en utilisant le type d'authentification le plus fort configuré sur les deux routeurs. Par exempleample, si un routeur annonce les types ah-sha1-hmac et ah-no-id, et qu'un deuxième routeur annonce le type ah-no-id, les deux routeurs négocient pour utiliser ah-no-id sur la connexion tunnel IPsec entre eux. Si aucun type d'authentification commun n'est configuré sur les deux homologues, aucun tunnel IPsec n'est établi entre eux. L'algorithme de chiffrement sur les connexions tunnel IPsec dépend du type de trafic :

Pour le trafic monodiffusion, l'algorithme de chiffrement est AES-256-GCM.
Pour le trafic multidiffusion :
Cisco SD-WAN version 20.1.x et versions ultérieures : l'algorithme de chiffrement est AES-256-GCM

Versions précédentes – l'algorithme de chiffrement est AES-256-CBC avec SHA1-HMAC.

Lorsque le type d'authentification IPsec est modifié, la clé AES du chemin de données est modifiée.

Modifier la minuterie de retouche

Avant que les appareils Cisco IOS XE Catalyst SD-WAN et les appareils Cisco vEdge puissent échanger du trafic de données, ils établissent un canal de communication authentifié sécurisé entre eux. Les routeurs utilisent des tunnels IPSec entre eux comme canal et le chiffrement AES-256 pour effectuer le cryptage. Chaque routeur génère périodiquement une nouvelle clé AES pour son chemin de données. Par défaut, une clé est valide pendant 86400 24 secondes (10 heures) et la plage de minuterie va de 1209600 secondes à 14 XNUMX XNUMX secondes (XNUMX jours). Pour modifier la valeur du minuteur de rekey : Device(config)# security ipsec rekey seconds La configuration ressemble à ceci :

sécurité ipsec rekey secondes !

Si vous souhaitez générer immédiatement de nouvelles clés IPsec, vous pouvez le faire sans modifier la configuration du routeur. Pour ce faire, émettez la commande request security ipsecrekey sur le routeur compromis. Par exempleample, la sortie suivante montre que la SA locale a un indice de paramètre de sécurité (SPI) de 256 :

Une clé unique est associée à chaque SPI. Si cette clé est compromise, utilisez la commande request security ipsec-rekey pour générer immédiatement une nouvelle clé. Cette commande incrémente le SPI. Dans notre example, le SPI passe à 257 et la clé qui lui est associée est désormais utilisée :

Numéro de périphérique : demande de sécurité ipsecrekey
Appareil # afficher IPSec local-sa

Une fois la nouvelle clé générée, le routeur l'envoie immédiatement aux contrôleurs Cisco SD-WAN à l'aide de DTLS ou TLS. Les contrôleurs Cisco SD-WAN envoient la clé aux routeurs homologues. Les routeurs commencent à l'utiliser dès qu'ils le reçoivent. Notez que la clé associée à l'ancien SPI (256) continuera à être utilisée pendant une courte période jusqu'à expiration. Pour arrêter immédiatement d'utiliser l'ancienne clé, exécutez la commande request security ipsec-rekey deux fois, de suite. Cette séquence de commandes supprime à la fois les SPI 256 et 257 et définit le SPI sur 258. Le routeur utilise ensuite la clé associée du SPI 258. Notez cependant que certains paquets seront abandonnés pendant une courte période jusqu'à ce que tous les routeurs distants apprennent la nouvelle clé.

Modifier la taille de la fenêtre anti-relecture

L'authentification IPsec offre une protection anti-relecture en attribuant un numéro de séquence unique à chaque paquet d'un flux de données. Cette numérotation séquentielle protège contre la duplication des paquets de données par un attaquant. Avec la protection anti-relecture, l'expéditeur attribue des numéros de séquence croissants de manière monotone, et la destination vérifie ces numéros de séquence pour détecter les doublons. Comme les paquets n'arrivent souvent pas dans l'ordre, la destination maintient une fenêtre glissante de numéros de séquence qu'elle acceptera.

Les paquets dont les numéros de séquence se trouvent à gauche de la plage de la fenêtre glissante sont considérés comme anciens ou en double, et la destination les supprime. La destination suit le numéro de séquence le plus élevé qu'elle a reçu et ajuste la fenêtre glissante lorsqu'elle reçoit un paquet avec une valeur plus élevée.

Par défaut, la fenêtre glissante est définie sur 512 paquets. Il peut être défini sur n’importe quelle valeur comprise entre 64 et 4096 2, soit une puissance de 64 (c’est-à-dire 128, 256, 512, 1024, 2048 4096, XNUMX XNUMX ou XNUMX XNUMX). Pour modifier la taille de la fenêtre anti-relecture, utilisez la commande replay-window en précisant la taille de la fenêtre :

Numéro de fenêtre de relecture IPSec de sécurité du numéro de périphérique (config)

La configuration ressemble à ceci :
Numéro de fenêtre de relecture IPSec de sécurité ! !

Pour améliorer la qualité de service, des fenêtres de relecture distinctes sont conservées pour chacun des huit premiers canaux de trafic. La taille de la fenêtre de relecture configurée est divisée par huit pour chaque canal. Si la QoS est configurée sur un routeur, ce routeur peut subir un nombre d'abandons de paquets plus important que prévu en raison du mécanisme anti-relecture IPsec, et la plupart des paquets abandonnés sont légitimes. Cela se produit parce que la QoS réorganise les paquets, en accordant un traitement préférentiel aux paquets de priorité plus élevée et en retardant les paquets de priorité inférieure. Pour minimiser ou éviter cette situation, vous pouvez procéder comme suit :

Augmentez la taille de la fenêtre anti-relecture.
Concevoir le trafic sur les huit premiers canaux de trafic pour garantir que le trafic au sein d'un canal ne soit pas réorganisé.

Configurer les tunnels IPsec compatibles IKE
Pour transférer en toute sécurité le trafic du réseau superposé vers un réseau de service, vous pouvez configurer des tunnels IPsec qui exécutent le protocole Internet Key Exchange (IKE). Les tunnels IPsec compatibles IKE fournissent l'authentification et le cryptage pour garantir un transport sécurisé des paquets. Vous créez un tunnel IPsec compatible IKE en configurant une interface IPsec. Les interfaces IPsec sont des interfaces logiques et vous les configurez comme n'importe quelle autre interface physique. Vous configurez les paramètres du protocole IKE sur l'interface IPsec et vous pouvez configurer d'autres propriétés d'interface.

Note Cisco recommande d'utiliser IKE version 2. À partir de la version Cisco SD-WAN 19.2.x, la clé pré-partagée doit avoir une longueur d'au moins 16 octets. L'établissement du tunnel IPsec échoue si la taille de la clé est inférieure à 16 caractères lorsque le routeur est mis à niveau vers la version 19.2.

Note
Le logiciel Cisco Catalyst SD-WAN prend en charge IKE version 2 tel que défini dans la RFC 7296. Une utilisation des tunnels IPsec consiste à permettre aux instances de VM de routeur vEdge Cloud exécutées sur Amazon AWS de se connecter au cloud privé virtuel (VPC) d'Amazon. Vous devez configurer IKE version 1 sur ces routeurs. Les appareils Cisco vEdge prennent uniquement en charge les VPN basés sur les routes dans une configuration IPSec, car ces appareils ne peuvent pas définir de sélecteurs de trafic dans le domaine de chiffrement.

Configurer un tunnel IPsec
Pour configurer une interface de tunnel IPsec pour le trafic de transport sécurisé à partir d'un réseau de service, vous créez une interface IPsec logique :

Vous pouvez créer le tunnel IPsec dans le VPN de transport (VPN 0) et dans n'importe quel VPN de service (VPN 1 à 65530, sauf 512). L'interface IPsec a un nom au format ipsecnumber, où le nombre peut être compris entre 1 et 255. Chaque interface IPsec doit avoir une adresse IPv4. Cette adresse doit être un préfixe /30. Tout le trafic du VPN qui se trouve dans ce préfixe IPv4 est dirigé vers une interface physique du VPN 0 pour être envoyé en toute sécurité via un tunnel IPsec. Pour configurer la source du tunnel IPsec sur le périphérique local, vous pouvez spécifier soit l'adresse IP de l'interface physique (dans la commande tunnel-source-interface) ou le nom de l'interface physique (dans la commande tunnel-source-interface). Assurez-vous que l'interface physique est configurée en VPN 0. Pour configurer la destination du tunnel IPsec, spécifiez l'adresse IP du périphérique distant dans la commande tunnel-destination. La combinaison d'une adresse source (ou d'un nom d'interface source) et d'une adresse de destination définit un seul tunnel IPsec. Un seul tunnel IPsec peut exister qui utilise une adresse source (ou un nom d'interface) et une paire d'adresses de destination spécifiques.

Configurer une route statique IPsec

Pour diriger le trafic du VPN de service vers un tunnel IPsec dans le VPN de transport (VPN 0), vous configurez une route statique spécifique à IPsec dans un VPN de service (un VPN autre que VPN 0 ou VPN 512) :

vEdge(config)#vpn identifiant-vpn
vEdge (config-vpn) # ip ipsec-route préfixe/longueur interface vpn 0
numéroipsec [numéroipsec2]

L'ID VPN est celui de n'importe quel service VPN (VPN 1 à 65530, à l'exception de 512). préfixe/longueur est l'adresse IP ou le préfixe, en notation décimale à quatre points, et la longueur du préfixe de la route statique spécifique à IPsec. L'interface est l'interface du tunnel IPsec dans VPN 0. Vous pouvez configurer une ou deux interfaces de tunnel IPsec. Si vous en configurez deux, le premier est le tunnel IPsec principal et le second est la sauvegarde. Avec deux interfaces, tous les paquets sont envoyés uniquement au tunnel principal. Si ce tunnel échoue, tous les paquets sont alors envoyés au tunnel secondaire. Si le tunnel principal réapparaît, tout le trafic est renvoyé vers le tunnel IPsec principal.

Activer IKE version 1
Lorsque vous créez un tunnel IPsec sur un routeur vEdge, IKE version 1 est activé par défaut sur l'interface du tunnel. Les propriétés suivantes sont également activées par défaut pour IKEv1 :

Authentification et chiffrement : chiffrement CBC standard avancé AES-256 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA1 pour plus d'intégrité.

Numéro de groupe Diffie-Hellman : 16
Intervalle de saisie : 4 heures
Mode d'établissement SA – Principal

Par défaut, IKEv1 utilise le mode principal IKE pour établir des SA IKE. Dans ce mode, six paquets de négociation sont échangés pour établir la SA. Pour échanger seulement trois paquets de négociation, activez le mode agressif :

Note
Le mode agressif IKE avec des clés pré-partagées doit être évité autant que possible. Sinon, une clé forte pré-partagée doit être choisie.

vEdge(config)# vpn vpn-id interface numéro ipsec ike

vEdge(config-ike)# mode agressif

Par défaut, IKEv1 utilise le groupe Diffie-Hellman 16 dans l'échange de clés IKE. Ce groupe utilise le groupe MODP (More Modular Exponential) de 4096 2 bits lors de l'échange de clés IKE. Vous pouvez modifier le numéro de groupe en 1024 (pour MODP 14 2048 bits), 15 (MODP 3072 XNUMX bits) ou XNUMX (MODP XNUMX XNUMX bits) :

vEdge(config)# vpn vpn-id interface numéro ipsec ike

vEdge(config-ike)# numéro de groupe

Par défaut, l'échange de clés IKE utilise le chiffrement CBC standard de chiffrement avancé AES-256 avec l'algorithme de code d'authentification de message de hachage à clé HMAC-SHA1 pour garantir l'intégrité. Vous pouvez modifier l'authentification :

vEdge(config)# vpn vpn-id interface numéro ipsec ike

vEdge(config-ike)# suite de chiffrement

La suite d'authentification peut être l'une des suivantes :

aes128-cbc-sha1 : chiffrement CBC standard avancé AES-128 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA1 pour l'intégrité

aes128-cbc-sha2 : chiffrement CBC standard avancé AES-128 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA256 pour l'intégrité
aes256-cbc-sha1 : chiffrement CBC standard avancé AES-256 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA1 pour l'intégrité ; c'est la valeur par défaut.
aes256-cbc-sha2 : chiffrement CBC standard avancé AES-256 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA256 pour l'intégrité

Par défaut, les clés IKE sont actualisées toutes les heures (1 3600 secondes). Vous pouvez modifier l'intervalle de nouvelle saisie sur une valeur comprise entre 30 secondes et 14 jours (1209600 1 XNUMX secondes). Il est recommandé que l'intervalle entre les nouvelles saisies soit d'au moins XNUMX heure.

vEdge(config)# vpn vpn-id interface numéro ipsec comme
vEdge(config-ike)# secondes de retouche

Pour forcer la génération de nouvelles clés pour une session IKE, émettez la commande request ipsec ike-rekey.

vEdge(config)# vpn vpn-id interfaceipsec numéro ike

Pour IKE, vous pouvez également configurer l'authentification par clé pré-partagée (PSK) :

vEdge(config)# vpn vpn-id interface numéro ipsec ike
vEdge(config-ike)# password password est le mot de passe à utiliser avec la clé pré-partagée. Il peut s'agir d'une chaîne ASCII ou hexadécimale de 1 à 127 caractères.

Si le homologue IKE distant nécessite un ID local ou distant, vous pouvez configurer cet identifiant :

vEdge(config)# vpn vpn-id interface numéro ipsec ike type d'authentification
vEdge(config-authentication-type)# identifiant local
vEdge(config-authentication-type)# identifiant d'identification à distance

L'identifiant peut être une adresse IP ou n'importe quelle chaîne de texte de 1 à 63 caractères. Par défaut, l’ID local est l’adresse IP source du tunnel et l’ID distant est l’adresse IP de destination du tunnel.

Activer IKE version 2
Lorsque vous configurez un tunnel IPsec pour utiliser IKE version 2, les propriétés suivantes sont également activées par défaut pour IKEv2 :

Authentification et chiffrement : chiffrement CBC standard avancé AES-256 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA1 pour plus d'intégrité.

Numéro de groupe Diffie-Hellman : 16
Intervalle de saisie : 4 heures

Par défaut, IKEv2 utilise le groupe Diffie-Hellman 16 dans l'échange de clés IKE. Ce groupe utilise le groupe MODP (More Modular Exponential) de 4096 2 bits lors de l'échange de clés IKE. Vous pouvez modifier le numéro de groupe en 1024 (pour MODP 14 2048 bits), 15 (MODP 3072 XNUMX bits) ou XNUMX (MODP XNUMX XNUMX bits) :

vEdge (config) # vpn vpn-id interface ipsecnumber ike
vEdge(config-ike)# numéro de groupe

vEdge (config) # vpn vpn-id interface ipsecnumber ike
vEdge(config-ike)# suite de chiffrement

La suite d'authentification peut être l'une des suivantes :

aes128-cbc-sha1 : chiffrement CBC standard avancé AES-128 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA1 pour l'intégrité
aes128-cbc-sha2 : chiffrement CBC standard avancé AES-128 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA256 pour l'intégrité
aes256-cbc-sha1 : chiffrement CBC standard avancé AES-256 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA1 pour l'intégrité ; c'est la valeur par défaut.

aes256-cbc-sha2 : chiffrement CBC standard avancé AES-256 avec l'algorithme de code d'authentification des messages de hachage à clé HMAC-SHA256 pour l'intégrité

Par défaut, les clés IKE sont actualisées toutes les 4 heures (14,400 30 secondes). Vous pouvez modifier l'intervalle de nouvelle saisie sur une valeur comprise entre 14 secondes et 1209600 jours (XNUMX XNUMX XNUMX secondes) :

vEdge (config) # vpn vpn-id interface ipsecnumber ike

vEdge(config-ike)# secondes de retouche

Pour forcer la génération de nouvelles clés pour une session IKE, émettez la commande request ipsec ike-rekey. Pour IKE, vous pouvez également configurer l'authentification par clé pré-partagée (PSK) :

vEdge (config) # vpn vpn-id interface ipsecnumber ike

vEdge(config-ike)# password password est le mot de passe à utiliser avec la clé pré-partagée. Il peut s'agir d'une chaîne ASCII ou hexadécimale, ou d'une clé chiffrée en AES. Si le homologue IKE distant nécessite un ID local ou distant, vous pouvez configurer cet identifiant :
vEdge (config) # vpn vpn-id interface numéro ipsec ike type d'authentification
vEdge(config-authentication-type)# identifiant local

vEdge(config-authentication-type)# identifiant d'identification à distance

L'identifiant peut être une adresse IP ou n'importe quelle chaîne de texte de 1 à 64 caractères. Par défaut, l’ID local est l’adresse IP source du tunnel et l’ID distant est l’adresse IP de destination du tunnel.

Configurer les paramètres du tunnel IPsec

Tableau 4 : Historique des fonctionnalités

Fonctionnalité Nom	Informations sur la version	Description
Cryptographique supplémentaire	Cisco SD-WAN version 20.1.1	Cette fonctionnalité ajoute la prise en charge de
Prise en charge algorithmique pour IPSec		HMAC_SHA256, HMAC_SHA384 et
Tunnels		Algorithmes HMAC_SHA512 pour
		sécurité renforcée.

Par défaut, les paramètres suivants sont utilisés sur le tunnel IPsec qui transporte le trafic IKE :

Authentification et cryptage — Algorithme AES-256 en GCM (mode Galois/compteur)
Intervalle de nouvelle saisie : 4 heures

Fenêtre de relecture : 32 paquets

Vous pouvez modifier le chiffrement sur le tunnel IPsec en chiffrement AES-256 en CBC (mode de chaînage de blocs de chiffrement, avec HMAC utilisant l'authentification de message de hachage à clé SHA-1 ou SHA-2 ou en null avec HMAC en utilisant SHA-1 ou Authentification des messages de hachage à clé SHA-2, pour ne pas chiffrer le tunnel IPsec utilisé pour le trafic d'échange de clés IKE :

vEdge (config-interface-ipsecnumber)# ipsec

vEdge(config-ipsec)# suite de chiffrement (aes256-gcm | aes256-cbc-sha1 | aes256-cbc-sha256 | aes256-cbc-sha384 | aes256-cbc-sha512 | aes256-null-sha1 | aes256-null-sha256 | aes256-null-sha384 | aes256-null-sha512)

vEdge (config-interface-ipsecnumber)# ipsec

vEdge(config-ipsec)# secondes de retouche

Pour forcer la génération de nouvelles clés pour un tunnel IPsec, émettez la commande request ipsec ipsec-rekey. Par défaut, le Perfect Forward Secrecy (PFS) est activé sur les tunnels IPsec, pour garantir que les sessions passées ne seront pas affectées si les futures clés sont compromises. PFS force un nouvel échange de clés Diffie-Hellman, en utilisant par défaut le groupe de modules principaux Diffie-Hellman de 4096 XNUMX bits. Vous pouvez modifier le paramètre PFS :

vEdge (config-interface-ipsecnumber)# ipsec

vEdge(config-ipsec)#paramètre pfs parfait-forward-secrecy

pfs-setting peut être l’un des éléments suivants :

group-2 : utilisez le groupe de module premier Diffie-Hellman de 1024 XNUMX bits.

group-14 : utilisez le groupe de module premier Diffie-Hellman de 2048 XNUMX bits.
group-15 : utilisez le groupe de module premier Diffie-Hellman de 3072 XNUMX bits.
group-16 : utilisez le groupe de module premier Diffie-Hellman de 4096 XNUMX bits. C'est la valeur par défaut.
aucun : désactivez PFS.

Par défaut, la fenêtre de relecture IPsec sur le tunnel IPsec est de 512 octets. Vous pouvez définir la taille de la fenêtre de relecture sur 64, 128, 256, 512, 1024 2048, 4096 XNUMX ou XNUMX XNUMX paquets :

vEdge (config-interface-ipsecnumber)# ipsec
vEdge(config-ipsec)# numéro de fenêtre de relecture

Modifier la détection IKE Dead-Peer

IKE utilise un mécanisme de détection d'homologue mort pour déterminer si la connexion à un homologue IKE est fonctionnelle et accessible. Pour implémenter ce mécanisme, IKE envoie un paquet Hello à son homologue, et celui-ci envoie un accusé de réception en réponse. Par défaut, IKE envoie des paquets Hello toutes les 10 secondes, et après trois paquets non reconnus, IKE déclare le voisin mort et détruit le tunnel vers le homologue. Par la suite, IKE envoie périodiquement un paquet Hello au homologue et rétablit le tunnel lorsque l'homologue revient en ligne. Vous pouvez modifier l'intervalle de détection d'activité sur une valeur comprise entre 0 et 65535 0, et vous pouvez modifier le nombre de tentatives sur une valeur comprise entre 255 et XNUMX.

Note

Pour les VPN de transport, l'intervalle de détection d'activité est converti en secondes à l'aide de la formule suivante : Intervalle pour le numéro de tentative de retransmission N = intervalle * 1.8N-1Par exempleample, si l'intervalle est défini sur 10 et que les tentatives sont effectuées sur 5, l'intervalle de détection augmente comme suit :

Tentative 1: 10 * 1.81-1= 10 secondes
Tentative 2: 10 * 1.82-1= 18 secondes
Tentative 3: 10 * 1.83-1= 32.4 secondes
Tentative 4: 10 * 1.84-1= 58.32 secondes
Tentative 5: 10 * 1.85-1= 104.976 secondes

vEdge(config-interface-ipsecnumber)# nombre de tentatives d'intervalle de détection d'homologue mort

Configurer d'autres propriétés d'interface

Pour les interfaces de tunnel IPsec, vous pouvez configurer uniquement les propriétés d'interface supplémentaires suivantes :

vEdge(config-interface-ipsec)# mtu octets
vEdge (config-interface-ipsec) # tcp-mss-adjust octets

Désactivez les algorithmes de chiffrement SSH faibles sur Cisco SD-WAN Manager

Tableau 5 : Tableau de l'historique des fonctionnalités

Fonctionnalité Nom	Informations sur la version	Fonctionnalité Description
Désactivez les algorithmes de chiffrement SSH faibles sur Cisco SD-WAN Manager	Cisco vManage version 20.9.1	Cette fonctionnalité vous permet de désactiver les algorithmes SSH plus faibles sur Cisco SD-WAN Manager qui peuvent ne pas être conformes à certaines normes de sécurité des données.

Informations sur la désactivation des algorithmes de chiffrement SSH faibles sur Cisco SD-WAN Manager
Cisco SD-WAN Manager fournit un client SSH pour la communication avec les composants du réseau, notamment les contrôleurs et les périphériques de périphérie. Le client SSH fournit une connexion cryptée pour un transfert de données sécurisé, basé sur divers algorithmes de cryptage. De nombreuses organisations nécessitent un cryptage plus puissant que celui fourni par SHA-1, AES-128 et AES-192. À partir de Cisco vManage version 20.9.1, vous pouvez désactiver les algorithmes de chiffrement plus faibles suivants afin qu'un client SSH n'utilise pas ces algorithmes :

SHA-1
AES-128
AES-192

Avant de désactiver ces algorithmes de chiffrement, assurez-vous que les périphériques Cisco vEdge, le cas échéant, sur le réseau, utilisent une version logicielle ultérieure à Cisco SD-WAN version 18.4.6.

Avantages de la désactivation des algorithmes de chiffrement SSH faibles sur Cisco SD-WAN Manager
La désactivation des algorithmes de chiffrement SSH plus faibles améliore la sécurité des communications SSH et garantit que les organisations utilisant Cisco Catalyst SD-WAN se conforment aux réglementations de sécurité strictes.

Désactivez les algorithmes de chiffrement SSH faibles sur Cisco SD-WAN Manager à l'aide de la CLI

Dans le menu Cisco SD-WAN Manager, choisissez Outils > Terminal SSH.
Choisissez le périphérique Cisco SD-WAN Manager sur lequel vous souhaitez désactiver les algorithmes SSH plus faibles.
Saisissez le nom d'utilisateur et le mot de passe pour vous connecter à l'appareil.
Entrez en mode serveur SSH.
- vmanage(config)#système
- vmanage (système de configuration) # serveur ssh
Effectuez l'une des opérations suivantes pour désactiver un algorithme de chiffrement SSH :
- Désactivez SHA-1 :
gérer (config-ssh-server) # pas de kex-algo sha1
gérer (config-ssh-server)# commit
Le message d'avertissement suivant s'affiche : Les avertissements suivants ont été générés : « system ssh-server kex-algo sha1 » : AVERTISSEMENT : assurez-vous que tous vos Edge exécutent la version de code > 18.4.6 qui négocie mieux que SHA1 avec vManage. Sinon, ces bords pourraient devenir hors ligne. Procéder? [oui, non] oui
- Assurez-vous que tous les périphériques Cisco vEdge du réseau exécutent Cisco SD-WAN version 18.4.6 ou ultérieure et saisissez oui.
- Désactivez AES-128 et AES-192 :
- vmanage(config-ssh-server)# pas de chiffrement aes-128-192
- vmanage (config-ssh-server)# commit
  Le message d'avertissement suivant s'affiche :
  Les avertissements suivants ont été générés :
  « Chiffrement du serveur SSH système aes-128-192 » : AVERTISSEMENT : assurez-vous que tous vos Edge exécutent la version de code > 18.4.6 qui négocie mieux qu'AES-128-192 avec vManage. Sinon, ces bords pourraient devenir hors ligne. Procéder? [oui, non] oui
- Assurez-vous que tous les périphériques Cisco vEdge du réseau exécutent Cisco SD-WAN version 18.4.6 ou ultérieure et saisissez oui.

Vérifiez que les algorithmes de chiffrement SSH faibles sont désactivés sur Cisco SD-WAN Manager à l'aide de la CLI

Dans le menu Cisco SD-WAN Manager, choisissez Outils > Terminal SSH.
Sélectionnez le périphérique Cisco SD-WAN Manager que vous souhaitez vérifier.
Saisissez le nom d'utilisateur et le mot de passe pour vous connecter à l'appareil.
Exécutez la commande suivante : show running-config system ssh-server
Confirmez que le résultat affiche une ou plusieurs commandes qui désactivent les algorithmes de chiffrement plus faibles :
- pas de chiffre aes-128-192
- pas d'algo kex sha1

Documents / Ressources

CISCO SD-WAN Configurer les paramètres de sécurité [pdf] Guide de l'utilisateur
SD-WAN Configurer les paramètres de sécurité, SD-WAN, Configurer les paramètres de sécurité, Paramètres de sécurité

Références

Manuel d'utilisation

CISCO SD-WAN Configurer les paramètres de sécurité

Configurer les paramètres de sécurité