Objectifs de certification

ENCOR 350-401

  • 2.2 Configure and verify data path virtualization technologies

    • 2.2.a VRF
    • 2.2.b GRE and IPsec tunneling

Framework IPSEC

IPSEC est un standard ouvert de l’IETF pour sécuriser les réseaux IP. Il protège et authentifie les paquets IP d’un origine à une destination grâce à des services de sécurité cryptographiques et à un ensemble de protocoles de transport. IPSEC est un plutôt un “Framework”, un cadre évolutif qui ne définit pas des protocoles spécifiques mais des possibilités de sécuriser le transport des données à travers les réseaux IPv4 et IPv6 sous-entendus publics.

1. Services de sécurité

Il assure les fonctions de sécurité suivantes :

ServiceDescriptionMéthode
Confidentilité des donnéesDes algorithmes de chiffrement confidentialisent le traficDES, 3DES, AES
Intégrité des donnéesEmpêche les attaques d’homme-du-milieu et s’assure que les données n’ont pas été modifiée lors de leur transportHMAC : MD5 ou SHA
Authentification de l’origineVérifie l’identité des pairs par un mécanisme d’authentificationPSK, certificats ou nonces RSA, signatures ECDSA
Protection anti-rejeu--
Gestion des clés secrètesAlgorithme de chiffrement asymétriqueDiffie-Hellman (DH) ou ECDH

2. Cadre de sécurité pour IP

IPSEC est un framework, un cadre, qui offre de nombreuses combinaisons protocolaires dans les fonctions citées. Aussi, il n’est pas un protocole en soit, mais plutôt de une combinaison d’entre eux avec des méthodes cryptographiques. La nature de ses composants peut évoluer en fonction des usages et du moment. Il vient compléter les protocoles IPv4 et IPv6 avec des fonctions de sécurité.

3. Protocoles de transport sécurisés

IPSEC propose deux protocoles de couche 3 pour encapsuler le trafic de manière sécurisée : AH (Authentication Header, IP51) et ESP (Encapsulating Security Payload, IP50).

3.1. AH (Authentication Header, IP51)

AH (Authentication Header, IP51) est le protocole de transport de la pile IPSEC (RFC 4302) qui assure l’intégrité, l’authentification et une protection anti-rejeu des données échangées. AH signe les paquets IP pour s’assurer que ceux-ci n’ont pas été modifiés lors de leur transport. Alors que L’Internet IPv4 est encore dominant aujourd’hui, AH ne supporte pas les routeurs NAT et le chiffrement de telle sorte qu’il peu déployé dans les réseaux d’entreprise.

3.2. ESP (Encapsulating Security Payload, IP50)

ESP (Encapsulating Security Payload, IP50) est le protocole de transport de la pile IPSEC qui est utilisé pour la confidentialité, l’authentification et l’anti-rejeu des échanges entre deux noeuds IP. ESP protège la charge initiale de couche 3 (qui comprend ou non l’en-tête IP) en le rendant illisible des tiers et en y ajoutant des nouveaux en-têtes dans le réseau public. ESP supporte les routeurs NAT et assure le chiffrement.

4. Modes de fonctionnement IPSEC

Authentication Header (AH) comme Encapsulating Security Payload (ESP) connaissent deux modes de fonctionnement :

  • le mode transport
  • le mode tunnel.

4.1. IPSEC Mode transport

Le mode transport protège uniquement la charge IP. Ce mode ne supporte pas les fonctions de réseaux “overlay” et routage des paquets sur base des en-têtes originaux.

4.2. IPSEC Mode tunnel

Le mode tunnel protège le paquet IP, sa charge et son en-tête original, et IPSEC ajoute des nouveaux en-têtes pour le transport ce qui autorise des fonctions d’overlay et de routage.

4.3. Comparaison des modes transport et tunnel en IPSEC ESP

Dans le diagramme suivant, le paquet original est entitèrement sécurisé (confidentiel et authentifié) en mode tunnel avec un nouvel en-tête IP.

IPSEC ESP en mode transport et en mode tunnel

5. Cryptographie

IPSEC supporte différentes méthodes pour le chiffrement, l’authentification et la gestion des clés.

5.1. Chiffrement symétrique

  • DES (56 bits) et 3DES sont dépréciés
  • AES 128, 192 et 256

5.2. Authentification HMAC

La fonction HMAC est assurée par des protocoles de chiffrement asymétriques :

  • md5 Message Digest 5
  • sha Secure Hash Standard
  • sha256 Secure Hash Standard 2 (256 bit)
  • sha384 Secure Hash Standard 2 (384 bit)
  • sha512 Secure Hash Standard 2 (512 bit)

5.3. Authentification des pairs

L’authentification des pairs est assurée par IKE grâce à différentes méthodes :

  • PSK
  • certificats RSA
  • nonces RSA
  • signatures ECDSA

5.4. Protection des clés

Un protcole asymétrique d’échange de clé comme Diffie-Hellman (DH) de décider d’une clé secrète de chiffriment symétrique dans un environnement de communication non sécurisé. Un groupe Diffie-Hellman (DH) fait référence à la longueur de la clé pour l’échange de clé. Il est recommandé d’implémenter les groupes Diffie-Hellman (DH) 14 et supérieurs.

  • 1 Diffie-Hellman group 1 (768 bit)
  • 2 Diffie-Hellman group 2 (1024 bit)
  • 5 Diffie-Hellman group 5 (1536 bit)
  • 14 Diffie-Hellman group 14 (2048 bit)
  • 15 Diffie-Hellman group 15 (3072 bit)
  • 16 Diffie-Hellman group 16 (4096 bit)
  • 19 Diffie-Hellman group 19 (256 bit ecp)
  • 20 Diffie-Hellman group 20 (384 bit ecp)
  • 21 Diffie-Hellman group 21 (521 bit ecp)
  • 24 Diffie-Hellman group 24 (2048 bit, 256 bit subgroup)

6. Transform Sets

Un “Transform set” est une combinaison de protocoles et d’algorithmes de sécurité que les pairs agréent durant la phase de négociation des SA. Dès qu’une correpondance est trouvée, celle-ci est choisie pour sécuriser le trafic AH ou ESP.

6.1. Transform Sets AH

  • ah-md5-hmac
  • ah-sha-hmac
  • ah-sha256-hmac
  • ah-sha384-hmac
  • ah-sha512-hmac

6.2. Transform Sets ESP de chiffrement

  • esp-aes
  • esp-gcm
  • esp-gmac
  • esp-aes 192
  • esp-aes 256
  • esp-des
  • esp-3des
  • esp-null
  • esp-seal

6.3. Transform Sets ESP d’authentification

  • esp-md5-hmac
  • esp-sha-hmac
  • esp-sha256-hmac
  • esp-sha384-hmac
  • esp-sha512-hmac

7. Etablissement d’une connexion IPsec

Lors de l’établissement d’une connexion IPsec, plusieurs opérations sont effectuées :

  • Etape 1 : Echange des clés
    • IKE phase 1
    • IKE phase 2
  • Etape 2 : Transfert de données ESP (ou AH)
Cycle d'un tunnel IPSEC

La première phase d’échange de clés peut être exécutée manuellement mais le protocole IKE (Internet Key Exchange) en version 1 ou en version 2 réalise une authentification pour établir une association de sécurité IPSEC (SA). Ce canal d’échange IKE est réalisé depuis et vers le port UDP 500 ISAKMP (Internet Security Association and Key Management Protocol).

7.1. IKEv1

IKEv1 définit deux phases dans la négociation de clés IKE et l’établissement d’une association de sécurité (SA).

La phase 1 établit une SA bidirectionnelle entre deux pairs IKE (ISAKMP SA). Elle existe en deux modes : main mode (en 6 messages) et aggressive mode (en 3 messages).

Durant cette première phase, des propositions de SA comportent les paramètres suivants et doivent correspondre sur chaque pair :

  • Algorithme de hash : MD5 (déprécié) ou SHA.
  • Algorithme de chiffrement : DES, 3DES (dépréciés) ou AES.
  • Méthode d’authentification : PSK (Pre-Shared Key) ou certificats numériques.
  • Groupe Diffie-Hellman (DH): Group 1, 2, 5 (dépriciés) et ainsi de suite.
  • Temps de vie (SA Lifetime) : Durée de vie du tunnel (par défaut 24 heures). C’est le seul paramètre qui peut être différent d’un pair à l’autre (en cas de différence, c’est la valeur la plus faible qui est choisie).

La phase 2 établit en 3 messages des SAs unidirectionnels bénéficant des ISAKMP SA établis lors de la phase 1.

7.2. IKEv2

IKEv2 est l’évolution d’IKEv1 avec les carctéristiques suivantes :

  • 4 messages plus efficients
  • Supporte des méthodes d’authentification EAP
  • Supporte des méthodes cryptographiques récentes

8. Solution VPN IPSEC et GRE over IPSEC

On trouve plusieurs types de déploiement de VPN IPSEC. Le seul véritablement inter-opérable est le modèle de tunnel Site-à-Site. On ira utilement relire la définition et les typologies de VPN.

Lab IPSEC ESP en mode tunnel et en mode transport avec GRE intégré au pare-feu ZBF

En mode “tunnel” entre deux sites, le paquet IP original est entièrement chiffré et un nouvel en-tête IP est fabriqué par IPSEC avec les adresses publiques des deux points en source et en destination.

Avec GRE, en mode “transport” ESP ne chiffre que la charge sans ajouter de nouvel en-tête IP. Mais quelle sera l’en-tête IP original non chiffré ? Celui que le tunnel GRE aura créé. Quelle sera la charge chiffrée ? Celle du tunnel GRE qui comprendra l’en-tête GRE et le paquet IP original. Cette configuration autorise le trafic multicast dans le tunnel.

On trouvera touefois d’autres implémentations des tunnels IPSEC qui supportent des fonctionnalités avancées comme DMVPN, FlexVPN ou des solutions propriétaires sur les gammes de pare-feu NG.

9. Configuration de tunnels VPN en Cisco IOS

Deux méthodes de configuration :

  • par Crypto-map
  • par profils de tunnel IPSEC sur interface tunnel GRE

9.1. Configuration par Crypto-map

  1. Créer un crypto-acl qui identifie le trafic du tunnel.
  2. Créer une ISAKMP policy pour la IKE SA.
  3. Configurer une clé partagée pour l’authentification ISAKMP.
  4. Créer un Transform Set qui indique le mode et les protocoles AH et ESP.
  5. Créer un Crypto-map qui indique la crypto-acl, l’adresse du pair et le Transform Set à utiliser.
  6. On applique le Crypto-map sur l’interafce externe.

9.2. Configuration par profils de tunnel IPSEC

  1. Créer une ISAKMP policy pour la IKE SA.
  2. Configurer une clé partagée pour l’authentification ISAKMP.
  3. Créer un Transform Set qui indique le mode et les protocoles AH et ESP.
  4. Créer un profil de tunnel IPSEC qui indique le Transform Set.
  5. Appliquer le profil de tunnel IPSEC sur l’interface du tunnel (commande tunnel protection ipsec profile ...)

9.3. Valeur par défaut

  • Algorithme de chiffrement : DES (56 bits)
  • Algorithme de hash : SHA1
  • Méthode d’authentication : RSA Signature
  • Groupe Diffie-Hellman : #1
  • SA lifetime : 86400 seconds

9.4. Configuration Pare-feu

  • ISKAMP : UDP 500
  • ESP : IP 50
  • AH : IP 51
  • GRE : IP 47

9.5. Configuration NAT

Le trafic entre les réseaux privés ne devrait pas être traduit.