La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Sécurité des Réseaux: VPN (Virtual Private Networks)

Présentations similaires


Présentation au sujet: "Sécurité des Réseaux: VPN (Virtual Private Networks)"— Transcription de la présentation:

1 Sécurité des Réseaux: VPN (Virtual Private Networks)

2 Agenda VPN ? VPN Technologies Access, Intranet, Extranet VPNs VPN Exemples

3 Agenda Concevoir, installer et configurer des réseaux privés virtuels (VPN) sécurisés Utiliser le tunneling pour créer des liens privé étendus sur les réseaux publiques partagés Sécuriser les VPN à l'aide des protocoles IPsec (IP Security Protocols)

4 Introduction DEFINITION : Un VPN (Virtual Private Network) est un service offrant une connexion sécurisée via un réseau public (tel qu'Internet, Frame Relay..etc). Historiquement, on est passé du VPN de niveau 2 (ATM, X25, FrameRelay) à des VPN de niveau 3 (IPSEC). Le VPN IP impose la mise en place d'un canal dédié

5 Introduction Ce canal peut être implémenté de différentes manières : L2TP (niveau 2 du modèle OSI) ou IPSec (niveau 3) ou PPTP (Microsoft) ou GRE (Generic Routing Encapsulation permettant de créer un réseau VPN dédié) ou L2F (protocole Cisco). On peut rajouter du cryptage au niveau de ce canal : DES(56 bits), 3DES (168 bits), CET (technologie de cryptage propre à Cisco), IDEA (utilisé pour PGP) ou AES (128, 192 ou 256bits).

6 Vue d'ensemble d'IPSec IPSec A été défini lors des spécifications d'IPv6. Selon la RFC IETF RFC2401: "Protocole de sécurité au sein de la couche réseau. Ce protocole est développé pour fournir un service de sécurité à base de cryptographie, permettant de garantir l'authentification, l'intégrité, le contrôle d'accès et la confidentialité des données." D'une manière plus commune : IPSec = formatage de trame permettant le chiffrement des données au niveau IP.

7 12-7 Type Remote access VPN Application Mobile users Télétravailleurs Alternative RTC ISDN Intranet VPN Extranet VPN Site-to-site Internal connectivity Leased line Frame Relay Business-to-business External connectivity Fax Mail Time Universel access, lower cost Benefices Extend connectivity, lower cost e-commerce ON a 3 Types de VPNs:

8 12-8 VPN Architectures et Technologies Access VPN Client–Initiated NAS–Initiated Client–Initiated NAS–Initiated Intranet / Extranet VPN Intranet / Extranet VPN IP Tunnel Virtual Circuit MPLS IP Tunnel Virtual Circuit MPLS GRE, IPsec, MPLS ServiceArchitectures Protocoles daccès VPN Technologies daccès VPN L2F/L2TP, IPsec, PPTP Dial, ISDN, DSL, Mobile IP, Mobile IP, FR, ATM, IP ou IP+ATM Mobile IP, FR, ATM, IP ou IP+ATM

9 Vue d'ensemble d'IPSec IPSec fournit les services suivants : - Confidentialité des données : pas de décryptage possible au milieu du canal - Intégrité des données : pas de modification des données pendant le transport - Authentification de l'origine des données : verifie adresse IP source... C'est ce que l'on appelle la non-répudiation - Anti-rejeu : pas de possibilité de rejouer des paquets afin de s'infiltrer dans une communication. Ceci est basé sur la vérification des numéros de séquences.

10 Vue d'ensemble d'IPSec IPSec est basé sur l'un des 2 principaux protocoles : - AH (Authentication Header) - ESP (Encapsulation Security Payload) Ipsec fonctionne en Mode tunnel/Mode transport: Le mode tunnel correspond au cas ou au moins l'un des 2 peers IPSec se comporte comme une gateway/passerelle IPSec, qui décrypte/encrypte, mais les paquets ne lui sont pas directement destinés.

11 Vue d'ensemble d'IPSec Exemple de IPsec en Mode TUNNEL : - Cas ou les 2 peers sont des gateways (Routeur VPN) : si on fait un VPN LAN TO LAN => les deux peers encryptent et décryptent tour à tour, mais les paquets sont destinés aux LAN inside quils protègent. Le mode transport est utilisé quand on fait du VPN entre 2 hosts (2 Serveurs, 2 PC,...), ou entre un host et une gateway qui dans ce cas se comporte comme un simple host. Exemple : - PC à PC - Serveur à PC - Serveur à Serveur

12 IKE (Internet Key Exchange) IKE (Internet Key Exchange) IKE est un protocole servant à IPSec : - authentification des peers IPSec, – négociation des SA(Security Associations) IKE et IPSec, établissement des clefs pour les algorithmes d'encryption utilisés par IPSec.

13 AH (Authentication Header) : (IP:51) AH (Authentication Header) : (IP:51) AH fournit l'authentification et l'intégrité des données, mais pas la confidentialité (encryption des données). L'authentification est assurée par la création d'une signature ou digest avec MD5. En option, AH peut aussi fournir l'anti-rejeu.

14 AH (Authentication Header) : (IP:51) Plus de détails sur AH protocol: Intégrité du paquet dans son intégralité (sauf le TTL bien sûr qui diminue à chaque routeur). Par contre pas de cryptage des données => pas de confidentialité. Paquet d'origine : IP Header + Data 1 - A l'aide de MD5 ou SHA-1 on fait un hash du [IP Header + data] => production d'un AH Header => Nouveau paquet : IP Header + AH + Data 2 - Le paquet est transmis à l'autre peer IPSec 3 - L'autre peer hash le IP Header + Data du paquet venant de lui arriver. Il en extrait le AH header, puis compare les 2 hash. 1 bit de différence suffit à rendre le paquet invalidé.

15 ESP (Encapsulating Security Payload) : (IP:50) ESP (Encapsulating Security Payload) : (IP:50) Fournit les mêmes services que AH, mais en plus, assure la confidentialité des données. Cette confidentialité est basée sur l'utilisation d'un algorithme dit "symétrique" : DES (56-bits), 3DES. ESP Ne prend pas en compte l'en-tête IP dans l'intégrité du paquet. En d'autre termes, il n'y a pas de hash de la partie IP Header.

16 mode transport Si on est en mode transport (mode bout en bout) : On chiffre le "reste du paquet (autres headers + payloads)" avec la clef secrète génèrée, et on rajoute au paquet un header ESP. Le paquet IPsec devient donc : IP Header + Header ESP + le reste du paquet (autres headers H4+ payloads) crypté

17 Agenda Si on est en mode tunnel (les peers IPSec jouant le rôle de gateway IPSec): De nouveaux IP Headers sont ajoutés lors du routage des paquets, mais TOUT le paquet origine est crypté avec la secret key => le IP Header d'origine est conservé intacte dans la partie cryptée. Le paquet devient donc : New Ip Header + ESP Header + Crypté[Ip Header origine + le reste du paquet (autres headers + payloads)] => ESP -> confidentialité car on a chiffrement des données -> plus grande consommation de CPU.

18 12-18 IPsec 3 types de Paquets IPsec IPsec Tunnel Original IP Layer DataIP HDR encrypted ESP Tunnel Mode (RFC 2406) IPsec Encrypted session Original IP Layer encrypted Data ESP Transport Mode (RFC 2406) IPsec Authenticated session Original IP Layer IP HDRDataAH HDR AH Protocol (RFC 2402) IP HDRDataIP HDRData IP HDRESP HDR IP HDRDataIP HDRDataIP HDRDataIP HDRData New IP HDR

19 12-19 IPsec Définitions des 3 Normes IPsec Authentication Header (AH) RFC 2402 Authentication Header (AH) RFC 2402 Provides authentication of sender and receiver Low byte overhead No impact on QoS/CoS options Minimal impact on performance Provides authentication of sender and receiver Low byte overhead No impact on QoS/CoS options Minimal impact on performance Encapsulation Secure Payload (ESP) Transport Mode RFC 2406 Encapsulation Secure Payload (ESP) Transport Mode RFC 2406 Moderate byte overhead Maintains all Layer 2/3 QoS info (IP TOS bits, MAC, IP addresses, etc) Provides confidentiality Moderate byte overhead Maintains all Layer 2/3 QoS info (IP TOS bits, MAC, IP addresses, etc) Provides confidentiality IPsec ProtocolDefinitionLimitations Résumé Encapsulation Secure Payload (ESP) Tunnel Mode RFC 2406 Encapsulation Secure Payload (ESP) Tunnel Mode RFC 2406 Moderate overhead Lose all Layer 4+ QoS info (ports, flows, applications, etc.) Decreased performance due to en/decryption End systems must be IPsec capable Moderate overhead Lose all Layer 4+ QoS info (ports, flows, applications, etc.) Decreased performance due to en/decryption End systems must be IPsec capable No confidentiality (no encryption) No traffic analysis protection No confidentiality (no encryption) No traffic analysis protection Additional bandwidth consumption (overhead) Lose all Layer 4+ QoS info Decreased performance of network devices that initiate/terminate tunnel due to en/decryption Additional bandwidth consumption (overhead) Lose all Layer 4+ QoS info Decreased performance of network devices that initiate/terminate tunnel due to en/decryption Provides both confidentiality and protection from traffic analysis Maintains Layer 2/3 QoS info Can be transparent to end systems! Provides both confidentiality and protection from traffic analysis Maintains Layer 2/3 QoS info Can be transparent to end systems! Does not actually segregate traffic to provide VPNs, but may be used in conjunction with ESP to authenticate partners, customers, etc. Provides confidentiality of packet data, but not source and destination addresses. Both end systems must be IPsec capable since no tunneling is done. Most complete security but highest cost (overhead and decreased performance of network devices). Most VPNs will use this method so that the gateway/firewall is the only IPsec needed on their Intranet.

20 12-20 Step 4 POP with NAS POP with NAS IPsec Access VPN ISDN POTS Corporate Intranet LCP negotiation (PPP setup) NAS issues CHAP challenge CHAP Response / CHAP Auth-OK Internet Key Exchange (IKE) Security Association is setup between client and gateway to negotiate tunnel protocols and authentication methods IPsec Tunnel Internal IP layer functionality is passed through tunnel with Corporate Intranet IP Client Gateway/Firewall PPP IP IPsec Tunnel Step 2 Step 3 PPP setup with ISPs NAS Clients software now uses the IPsec ESP Tunnel with the corporate gateway to pass the corporate, internal IP connectivity through the ISP(s)s IP network(s) Certificate Authority AAA DNS/DHCP Layer 3 Tunnel is setup and authenticated with home gateway using IKE Layer 3 Tunnel is setup and authenticated with home gateway using IKE Step 1 Identity Certification PPP IP

21 DES DES => Chiffrement des blocs de 64 bits avec une clé de 56 bits. 3DES => Les données à crypter sont segmentées en blocs de 64 bits. Puis on crypte chaque bloc 3 fois (d'où le 3 de DES) avec une clef de 56-bits différente à chaque process. 3DES = 3 processus DES en cascade avec 3 clefs de 56 bits => clef « totale » de 168 bits.).

22 DES/3DES et AES DES/3DES et AES = Algorithmes de chiffrement à clé secrète DES/3DES Inventé à l'origine par IBM. Algorithmes de chiffrement « par blocs » : les messages sont chiffrés par blocs entiers (de 64 bits dans le cas de DES et 3DES). Terminologie : on parle de : - CYPHERTEXT pour désigner des données cryptées ; - CLEARTEXT pour désigner des données passant en clair (non cryptées).

23 AES AES (Advanced Encryption Standard) : nouveau standard de chiffrement Il constitue le remplaçant du DES/3DES. Cet algorithme a été développé par 2 universitaires Belges (Rijmen et Daemen). Il s'agit comme pour DES/3DES, d'un algorithme de chiffrement par blocs.

24 AES Les blocs sont ici de 128 bits (contrairement à DES/3DES où les blocs ne sont que de 64 bits). Les clés de chiffrement sont soit de 128, 192, ou 256 bits. Contrairement à DES, AES ne comporte que des opérations arithmétiques simples ce qui a pour conséquence de ne pas nécessiter l'utilisation de composant hardware pour le chiffrement/de- chiffrement, et offre des performances supérieures (AES est considéré comme 3 fois plus rapide que 3DES sur plate-forme identique).

25 Diffie-Hellman Diffie-Hellman et RSA : Cryptographie à clef publique Ce concept révolutionna le monde de la cryptographie. DH est un protocole de cryptographie à clefs publiques. Il permet à 2 peers d'établir une clef secrète partagée utilisée par les algorithmes d'encryption (DES, MD5,...) Cet établissement de clef partagée se faisant via un canal non sécurisé (ex : Internet).

26 Diffie-Hellman DH est utilisé au sein d'IKE pour établir les clefs de sessions. RSA (Rivest, Shamir, and Adelman Signature) Les inventeurs : Rivest, Shamir et Adleman, en RSA est un mécanisme cryptographique à clefs publiques utilisé pour l'authentification. D'une manière courante, IKE utilise DH pour déterminer les clefs secrètes de chaque peer IPSec. L'échange DH peut être authentifié avec une signature ou une pre-shared key suivant l'algorithme RSA.

27 HASHING DIGEST ? HASHING : MD5 (128bits) / SHA-1(168bits) = Signature = hashing crypté avec clef privé de l'utilisateur A Utilisé pour certifier l'intégrité et l'authenticité d'un document. Le résultat est un digest de taille fixe. Les mots Resume et digest représentent la même chose.. Caractéristiques du digest : - Impossibilité de reconstruire les données à partir du digest ; - Si un bit des données change, le digest résultant sera très différent de l'originel (= effet d'avalanche).

28 HASHING DIGEST ? Exemple : Utilisateur A (émettant le message) : 1. Message1 -> Processus de hashing (MD5 ou SHA1) -> Resume1 2. Message1 + Resume1 + clef privée A -> Message1 crypté Utilisateur B (recevant le message) : 3. Décryptage du message1 avec la clef publique de A => Message1 + Resume1 4. On passe le message1 dans le hashage => Resume2 Si Resume1 = Resume2, alors le message est intègre = non modifié.

29 MD5 (Message Digest 5) Il s'agit d'un algorithme de hashage utilisé pour authentifié les données. Un algorithme de hashage est un mécanisme d'encryption prenant en entrée un message de taille arbitraire, et produisant un message de taille fixe (appelé Resume ou Digest). IKE, AH et ESP utilisent MD5 pour les processus d'authentification. Le digest est toujours de taille fixe : 128 bits dans le cas de MD5. SHA-1 (Secure Hash Algorithm-1) Un équivalent de MD5, mais plus sûr... Le digest est toujours de taille fixe : 168 bits dans le cas de SHA-1.

30 Mécanisme DE ESP Mécanisme de ESP : Peer 1: Le peer 1 possède une Clef A + une clef secrète (shared secret) incorporée au niveau de l'algorithme. => avec ça on crypte le texte. Le texte clair est envoyé à l'autre peer via ESP (rappel, il n'y a pas d'encryption avec AH, donc DES n'est utilisé que dans le cas d'ESP!!) Peer 2: Il possède la même clef A et le même secret partagé.

31 Comment s'opère la méthode DH Comment s'opère la méthode DH Prenons le cas classique de 2 utilisateurs : BOB et ALICE 1 - Bob choisit un grand nombre premier (noté P) 2 - Alice fait de même (son nombre sera noté Q) ====================================== ============================== 3 - Bob envoie P à Alice 4 - Alice envoie son nombre Q à Bob ====================================== ============================== 5 - Bob génère une racine primitive (à l'aide de P et Q) : G 6 - Alice fait de même. Cette racine est identique à celle de Bob. On la note donc G aussi.

32 Agenda 7 - Bob choisit un nombre Xa (clef privée) dans une liste de valeurs exponentielles Soit la liste est codée sur 768 bits => DH groupe 1 Soit cette liste est codée sur 1024 bits => DH groupe Alice fait de même : nombre Xb (clef privée) ====================================== ============================== 9 - Bob génère sa clef publique : Ya = reste de la division entière = G exp (Xa) * modulo (P) 10 - Alice fait de même : Yb = G exp (Xb) * modulo (P) ====================================== ============================== 11 - Bob envoie sa clef publique (Ya) à Alice 12 - Alice envoie sa clef publique (Yb) à Bob Nota : Bob et Alice conservent leur clef privée respective. Cette clef n'est bien sur jamais donnée !

33 Agenda 13 - Bob génère la clef intermédiaire de cryptage : ZZa = Yb exp (Xa) * modulo (P) 14 - Alice fait de même : ZZb = Ya exp (Xb) * modulo (P) AVEC DH : ZZa = ZZb !!!! ================================ ================================ ==== 15 - Bob génère la clef secrète partagée. Cette clef est dérivée de ZZ en utilisant DES ou un algorithme HMAC 16 - Alice fait de même. Cette clef commune est soit codé sur 56 bits si on utilise DES, soit sur 168 bits si on utilise 3DES

34 Agenda Bilan : Toute la solidité de cet algorithme repose sur le choix de Xa et Xb (les clefs privées). Plus l'espace de nombre, pour ce choix, est grand, mieux c'est. Il existe 5 groupes d'espaces de choix => 5 groupes DH : Dans un espace pris le long d'une courbe exponentielle : - DH groupe 1 => espace codé sur 768 bits - DH groupe 2 => espace codé sur 1024 bits - DH groupe 3 => espace codé sur 2048 bits

35 Agenda La clef ZZ est appelée : clef de cryptage. C'est elle qui sera utilisée pour l'établissement du canal IKE puis IPSec. Attention : On voit bien que DH n'EST PAS UNE METHODE DE CRYPTAGE. C'est une méthode d'échange de clefs. Tout passe en clair dans l'algorithme DH => attaque MAN IN THE MIDDLE !! Il faut donc, pendant DH, utiliser RSA avec un certificat ou une pre-shared key pour crypter les échanges de clef de cryptage !

36 Combien a t on de clefs dans un transfert IPSec ? Combien a t on de clefs dans un transfert IPSec ? - Une clef privée (X) qui n'est jamais partagée. Elle est utilisée pour signer les messages. - Une clef publique qui est partagée (= commune = Y). Elle est utilisée par l'autre peer pour vérifier la signature. - Une clef secrète partagée (dérivée de ZZ) qui est utilisée, pour crypter les données, de manière combinée avec un algorithme de cryptage (DES, 3DES,...).

37 Vue d'ensemble d'IKE Vue d'ensemble d'IKE Introduction IKE ? IKE négocie les SA (Security Associations) pour IPSec (RFC 2409) IKE négocie les IPSec security associations (SAs). Ce processus nécessite que les systèmes IPSec s'authentifient entre eux et établissent les clefs IKE (= ISAKMP) partagées.

38 Vue d'ensemble d'IKE En d'autres termes, IKE = Schéma de chiffrement comment va se faire l'échange des informations entre les différents peers d'un VPN. Schématiquement : IKE = ISAKMP (RFC 2408) + Oakley (RFC 2412) ISAKMP = protocole pour la négociation préalable à l'établissement des associations de sécurité (SA). Oakley = détermine le mécanisme pour l'échange automatique des clés.

39 Agenda IKE démarre donc avant IPSEC !!! On a 1 tunnel IKE en premier, puis un tunnel IPSec ensuite. Ce dernier étant issu des négociations IKE préalables. SA ? SA = Security Associations = descriptif des process (algorithme, clefs, méthodes d'échanges,...) qui seront utilisé par chaque peer d'un VPN. = objet décrivant tous les éléments qui caractérisent la communication.

40 Agenda IKE Phase 1 = premier tunnel = ISAKMP IKE crée un canal crypté et authentifié entre les 2 peers. Cette phase est nommée IKE Security Association. C'est DH qui est l'algorithme principal de cette phase. Les sessions ISAKMP utilisent UDP (source ET destination port = 500) Les résultats de l'établissement d'une session ISAKMP sont des SAs ISAKMP (bidirectionnelles).

41 Agenda ISAKMP établit tous les SAs IPSEC à la demande. Une session ISAKMP est authentifiée : - Soit par une clef partagée (pre-shared key) - Soit par RSA signature et chiffrement. De plus une session ISAKMP est chiffrée (DES) pour l'échange des clefs de session. => phase 1 = authentification des peers + établissement de la policy IKE => génération d'une SA BIDIRECTIONNELLE par peer.

42 IKE Phase 2 = deuxième tunnel = OAKLEY IKE Phase 2 = deuxième tunnel = OAKLEY IKE négocie les SA IPSec, et génère le matériel IPSec. Chaque peer doit donner ses préférences en matière d'algorithmes d'échange et de cryptage (c'est que l'on appelle les transform-set ). C'est aussi pendant cette phase que les peers établissent le type de trafic respectif devant être crypté.

43 IKE Phase 2 = deuxième tunnel = OAKLEY Lors de cette phase 2, une nouvelle utilisation de DH est faite ou alors les clefs utilisées pendant cette seconde phase seront dérivées de celles négociées lors de la phase 1. => phase 2 = négociation des paramètres IPSec => génération par peer de 2 SA : 1 SA pour les flux entrants 1 SA pour les flux sortants Ces 2 SA sont donc UNIDIRECTIONNELLES

44 La 1 ere méthode Plus spécifiquement, avec IKE Phase 1 LAuthentification utilise 2 méthodes : –- Pre-shared keys = une clef commune entrée manuellement dans la configuration de chaque peer. –Les 2 peers s'authentifient en s'envoyant et utilisant un challenge lié à la fameuse clef partagée.

45 La 2 eme méthode La 2 eme méthode utilise un certificat numérique que chacun signe avec sa clef privée (format X.509) authentifié par une signature RSA. Dans cette architecture tri-parties (les 2 peers + l'autorité de certification ayant délivré ET signé les certificats présents sur chaque peer), chaque peer reçoit un certificat propre émanant d'une autorité de certification. Chaque peer signe alors son certificat avec sa clef privée et crypte avec sa clef publique(elle même ayant au préalable été signée par l'autorité de certification), puis l'envoie à l'autre peer.

46 IKE Policy IKE Policy : Détermination de la politique ISAKMP= – IPSec SA : une politique ISAKMP définie une combinaison de paramètres de sécurité utilisés durant la négociation ISAKMP. –Pour qu'il y ait communication IPSec possible, il faut que les 2 peers trouvent un accord sur une politique ISAKMP commune.

47 IKE phase 1 IKE Policy : Une politique ISAKMP contient : * Algorithme d'encryption : DES/3- DES * Algorithme de hashing : MD5/SHA-1 * IKE SA Lifetime = durée de vie des SA IKE : secondes, ou moins.

48 IKE phase 2 IKE phase 2 : - Négociation des algorithmes IPSec = transform-set : ESP-DES,... - Cette négociation est protégée grâce à la SA IKE prédéfinie. - Identification des peers par adresse IP ou bien nom (FQDN) ; - Détermination des adresses IP des hôtes qui doivent communiquer en crypté ;

49 IKE phase 2 - Établissement des IPSec security associations : – soit de manière manuelle (pas conseillé), – soit via IKE (conseillé), dans ce dernier cas, il faut spécifier ipsec-isakmp. -Ces IPSec SAs sont périodiquement renégociées afin d'augmenter le niveau de sécurité. -De plus on peut forcer le fait que les clefs de sessions IPSec seront nouvelles à chaque fois, ou simplement dérivées des clefs négociées en IKE phase 1. Cette dernière fonctionnalité est appelée PFS ( Perfect Forward Secrecy).

50 IKE phase 2 - Établissement des IPSec security associations : – Le contenu d'une IPSec SA est le suivant : –- Adresse IP du peer d'en face ; –- Identifiant de VPN (SPI = Security Parameter Index) –- Algorithmes IPSec : AH/ESP + rien ou HMAC-MD5/HMAC-SHA-1 ; –- Mode (Tunnel ou Transport) ; –- Clef de session ; –- Attributs supplémentaires (Lifetime = durée de vie des clefs de session,...)

51 RESUME IKE IPsec Les différentes étapes d'une connexion IPSec : Une communication IPSec peut se découper en 3 étapes et 2 tunnels. –Etape 1 = Tunnel 1 = Tunnel IKE –IKE Phase 1 : Authentification des peers + negociation des SA IKE + montage du tunnel crypté pour la négociation des SA IPSec en phase2.

52 RESUME IKE IPsec Etape 2 = Tunnel 2 = Tunnel IPSec : –IKE Phase 2 : négociation des paramètres des SA IPSec + mise en place de ces SA sur chaque peer. Etape 3 :Transfert des données. –Les données sont transférées entre les peers IPSec en utilisant les paramètres IPSec + les clefs enregistrées au niveau des SA.

53 IPSec IPSec comporte normalement 2 protocoles (AH et ESP). Suivant que l'on utilise AH ou ESP on pourra faire du VPN au travers des devices faisant de la NAT. - AH (Authentication Header) = IP:51, –permettant l'authentification de la source + anti rejeu + intégrité. Dans ce cas le hashing (MD5 ou SHA-1) est fait sur tout le paquet, IP headers compris (sauf bien sur les champs naturellement variables : TTL,...). – Ce mode est incompatible avec la NAT qui change le AH Header et cause ainsi le rejet du paquet par le peer IPSec.

54 IPSec IPSec comporte normalement 2 protocoles (AH et ESP). - ESP (Encapsulation Security Payload) = IP:50, ESP fournit, en plus de AH, la confidentialité grâce à l'encryption au niveau IP. L'algorithme par défaut est DES (56 bits) ou 3DES. Ce protocole supporte la NAT car le hashing (utilisé pour l'intégrité) ne prend pas en compte l'en-tête IP. Ainsi la NAT peut changer le Header IP, et pourtant le paquet sera accepté par le peer IPSec. Le petit moins, c'est que qu'en ESP, il n'y a pas de protection de l'entité IP.

55 REMARQUE SUR VPN et NAT ATTENTION : l'utilisation d'ESP permet que les peers VPN fassent de la NAT. Cependant, dans le cas ou c'est un élément en amont du peer qui fait de la NAT, le fait d'utiliser ESP ne suffit pas ! Imaginons le cas suivant : Vous avez au sein de votre entreprise un device servant de peer VPN pour des itinérants (par exemple un firewall avec module VPN). Les itinérants utilisent en général un client VPN pour accéder à votre réseau interne via le device VPN. Quand vos itinérants sont directement connectés à Internet (via RTC, ADSL,RNIS ),... pas de problème !

56 REMARQUE SUR VPN et NAT Par conter si vos itinérants se rendent chez un partenaire qui possède lui un routeur ou un firewall faisant de la NAT, çà ne marchera plus !!! En effet, le device du partenaire faisant de la NAT, il ré-écrit le header IP du paquet envoyé par vos itinérants. Votre device faisant du VPN accepte bien le paquet entrant à destination du LAN, mais la réponse venant de votre réseau interne sera destinée au device ayant officiellement envoyé le 1er paquet... donc celui qui a écrit le header IP. Dans ce cas, on voit bien que c'est le device de NAT du partenaire, et non votre itinérant ! Le paquet ne reviendra donc jamais à votre itinérant !

57 Agenda Le problème vient du fait qu'IPSec ne possède pas la notion de port indispensable en cas de NAT afin que le device (faisant la NAT) sache reconnaître et distinguer les connexions.

58 Agenda Questions & Réponses


Télécharger ppt "Sécurité des Réseaux: VPN (Virtual Private Networks)"

Présentations similaires


Annonces Google