Rubriques Connexes
À propos des négociations VPN IPSec
Les périphériques situés aux extrémités d'un tunnel VPN IPSec sont des pairs IPSec. Lorsque deux pairs IPSec veulent créer une connexion VPN entre eux, ils échangent une série de messages relatifs au chiffrement et à l'authentification, et tentent de s'accorder sur toute une série de paramètres différents. Ce processus est connu sous le nom de négociations VPN. Un périphérique dans la séquence de négociation est l'initiateur et l'autre le répondeur.
Les négociations VPN sont effectuées en deux phases : la Phase 1 et la Phase 2.
Phase 1
L'objectif principal de la phase 1 est la mise en place d'un canal chiffré sécurisé par l'intermédiaire duquel deux pairs peuvent négocier la phase 2. Lorsque la phase 1 se termine avec succès, les pairs passent rapidement aux négociations de phase 2. Si la phase 1 échoue, les périphériques ne peuvent entamer la phase 2.
Phase 2
L'objectif des négociations de phase 2 est que les deux pairs s'accordent sur un ensemble de paramètres qui définissent le type de trafic pouvant passer par le VPN et sur la manière de chiffrer et d'authentifier le trafic. Cet accord s'appelle une association de sécurité.
Les configurations de phase 1 et 2 doivent correspondre pour les périphériques situés aux extrémités du tunnel.
Négociations de phase 1
Dans les négociations de phase 1, les deux pairs échangent des informations d'identification. Les périphériques se reconnaissent et négocient pour définir un ensemble commun de paramètres de phase 1 à utiliser. Lorsque les négociations de phase 1 sont terminées, les deux pairs disposent d'une association de sécurité (SA) de phase 1. Cette SA est valable pour un certain laps de temps. Après l'expiration de la SA de phase 1, si les deux pairs doivent terminer à nouveau les négociations de phase 2, ils doivent aussi reprendre les négociations de phase 1.
Les négociations de phase 1 comprennent les étapes suivantes :
- Les périphériques échangent des informations d'identification.
Les informations d'identification peuvent être un certificat ou des clés pré-partagées. Les deux points de terminaison de la passerelle doivent utiliser la même méthode d'informations d'identification. Si l'un des pairs utilise une clé pré-partagée, l'autre pair doit aussi utiliser une clé pré-partagée. Les deux clés doivent correspondre. Si l'un des pairs utilise un certificat, l'autre pair doit aussi utiliser un certificat.
- Les périphériques se reconnaissent.
Chaque périphérique fournit un identificateur de Phase 1, pouvant être une adresse IP, un nom de domaine, des informations de domaine ou un nom X500. La configuration VPN de chacun des pairs contient l'identificateur de phase 1 du périphérique local et à distance. Les configurations doivent correspondre.
- Avec IKEv1, les pairs décident d'utiliser le Mode Principal ou le Mode Agressif.
Avec IKEv1, les négociations de phase 1 peuvent utiliser l'un des deux modes suivants : le Mode Principal ou le Mode Agressif. Le périphérique qui lance les négociations IKE (l'initiateur) envoie soit une proposition de mode normal ou une proposition de mode agressif. Le répondeur peut rejeter la proposition s'il n'est pas configuré pour utiliser ce mode. Le mode agressif, pour sa part, est moins sécurisé mais y gagne en rapidité par rapport au mode principal.
Lorsque vous utilisez le mode agressif, le nombre d'échanges entre deux points de terminaison est moins important que si vous utilisiez le mode principal, et l'échange dépend surtout des types d'ID utilisés par les deux périphériques. Le mode agressif ne garantit pas l'identité du pair. Le mode Principal garantit l'identité des deux pairs, mais ne peut être utilisé que si les deux côtés possèdent une adresse IP statique.
- Les pairs s'accordent sur les paramètres de phase 1.
- Utilisation du parcours NAT — cette option est toujours activée pour IKEv2
- Envoi de messages de conservation d'activité IKE (uniquement pour IKEv1 entre deux Firebox)
- Utilisation de la détection DPD (Dead Peer Detection) (RFC 3706) — cette option est toujours activée pour IKEv2.
- Les pairs s'accordent sur les paramètres de transformation de phase 1.
Les paramètres de transformation comportent un ensemble de paramètres d'authentification et de chiffrement, ainsi que le laps de temps maximal pour la SA de phase 1. Les paramètres de transformation de phase 1 doivent correspondre exactement à une transformation de phase 1 sur le pair IKE. À défaut, les négociations IKE échouent.
Les éléments que vous pouvez définir dans les transformations sont les suivants :
- Authentification — Type d'authentification (SHA1, SHA2 ou MD5). SHA2 est plus sécurisé que SHA1 ou MD5.
- Chiffrement — Type d'algorithme de chiffrement (DES, 3DES ou AES). L'AES est le chiffrement le plus sécurisé qui soit.
- Vie de la SA — Le délai avant l'expiration de l'Association de Sécurité de Phase 1.
- Groupe de Clés — Le groupe de clés Diffie-Hellman.
Avec IKEv2, les paramètres de transformation de phase 1 sont partagés par toutes les passerelles BOVPN dont la passerelle distante possède une adresse IP dynamique.
SHA-2 n'est pas pris en charge sur les périphériques XTM
Négociations de phase 2
Après l'achèvement des négociations de phase 1 par les deux pairs IPSec, les négociations de phase 2 débutent. Le but des négociations de Phase 2 est d'établir la SA de Phase 2 (parfois nommée SA IPSec). Les SA IPSec sont un ensemble de spécifications de trafic qui indiquent au périphérique le trafic à envoyer sur le VPN et la manière de le chiffrer et de l'authentifier. Dans les négociations de phase 2, les deux pairs s'accordent sur un ensemble de paramètres de communication. Lorsque vous configurez le tunnel BOVPN dans Policy Manager ou dans Fireware Web UI, vous définissez les paramètres de Phase 2.
Comme les pairs utilisent les associations de sécurité de Phase 1 pour sécuriser les négociations de Phase 2 et que vous définissez les paramètres SA de Phase 1 dans les paramètres de passerelle BOVPN, vous devez spécifier la passerelle à utiliser pour chaque tunnel.
Les négociations de phase 2 comprennent les étapes suivantes :
- Les pairs utilisent les SA de phase 1 pour sécuriser les négociations de phase 2.
Les négociations de phase 2 ne peuvent débuter qu'après l'établissement des associations de sécurité de phase 1.
- Les pairs échangent leurs identificateurs de phase 2 (ID).
Les ID de phase 2 sont toujours envoyés par paire lors d'une proposition de phase 2 : l'un indique quelles adresses IP derrière le périphérique local peuvent envoyer du trafic via le VPN, et l'autre indique quelles adresses IP derrière le périphérique distant peuvent envoyer du trafic via le VPN. Cette connexion est également appelée une route de tunnel. Vous pouvez définir les ID de Phase 2 pour le pair local et le pair distant en tant qu'adresse IP hôte, adresse IP réseau ou plage d'adresse IP.
- Les pairs s'accordent pour l'utilisation ou non de la confidentialité Perfect Forward Secrecy (PFS).
La confidentialité PFS définit la méthode de dérivation des clés de phase 2. Lorsque la confidentialité PFS est sélectionnée, les pairs IKE doivent utiliser la confidentialité PFS. Sinon, le renouvellement des clés de Phase 2 échoue. La confidentialité PFS garantit que si une clé de chiffrement utilisée pour protéger les transmissions de données est compromise, un attaquant parvient uniquement à accéder aux données protégées par cette clé et non par les clés supplémentaires. Si les pairs s'accordent à utiliser la confidentialité PFS, ils doivent également s'accorder sur le groupe de clé Diffie-Hellman à utiliser pour la confidentialité PFS.
- Les pairs s'accordent sur une proposition de phase 1.
La proposition de phase 2 contient les adresses IP pouvant envoyer du trafic par l'intermédiaire du tunnel, ainsi qu'un groupe de chiffrement et des paramètres d'authentification. Fireware XTM envoie ces paramètres dans une proposition de phase 2. La proposition contient l'algorithme à utiliser pour authentifier les données, l'algorithme à utiliser pour chiffrer les données et indique la fréquence de création de nouvelles clés de chiffrement de phase 2.
Les éléments que vous pouvez définir dans une proposition de phase 2 sont les suivants :
Type
Pour un réseau BOVPN manuel, vous pouvez sélectionner le type de protocole à utiliser : AH (Authentication Header) ou ESP (Encapsulating Security Payload). L'ESP permet l'authentification et le chiffrement des données. L'AH permet l'authentification, mais pas le chiffrement des données. Nous vous recommandons d'opter pour l'ESP. Les réseaux BOVPN gérés et Mobile VPN with IPSec utilisent toujours l'ESP.
Authentification
L'authentification garantit que les informations reçues soient exactement les mêmes que les informations envoyées. Vous pouvez configurer les pairs de manière à utiliser les algorithmes SHA1 ou MD5 pour authentifier mutuellement leurs messages IKE. SHA1 est plus sécurisé.
Chiffrement
Le chiffrement garantit la confidentialité des données. Vous pouvez sélectionner les chiffrements DES, 3DES, ou AES. L'AES est le chiffrement le plus sécurisé qui soit.
Forcer l'expiration de la clé
Pour garantir la modification périodique des clés de chiffrement de phase 2, activez toujours l'expiration de la clé. Plus la période d'utilisation d'une clé de chiffrement de phase 2 est longue, plus nombreuses seront les données qu'une personne mal intentionnée pourra collecter pour organiser une attaque de la clé.