{{tag>}} ======IPSec====== IPSec est un standard de l'IETF qui emploie des mécanismes de chiffrement de niveau 3 (réseau) afin d'assurer : * l'**authentification** (signature) * la **confidentialité** (chiffrement) et * l'**intégrité des données** (hashage) =====Théorie===== Il existe plusieurs modes : * **mode tunnel** = dans ce cas on ajoute à la fois les headers ESP mais aussi une nouvelle entête IP * **mode transport** = en mode PTP, seul l'entête ESP est ajouté ; les adresses IPs sont conservées intactes et non chiffrées ====IKE==== **Internet Key Exchange** permet la négociation des paramètres de sécurité et l'établissement des clés authentifiées ; il utilise udp/500. * **ISAKMP** : protocole de négociation d'une politique de sécurité ainsi que d'échange de clés * **Oakley** : protocole d'échange de clés * **Skeme** : protocole d'échange de clés ===Les 2 phases=== * **phase 1** : son but est d'authentifier les peers IPsec et d'établir un canal sécurisé entre eux, afin de permettre les échanges IKE : * authentification des peers * négociation de la politique de sécurité pour établir une IKE SA (association de sécurité IKE) * établissement d'un canal sécurisé grâce à un échange de clé (Diffie-Hellman) Il existe 2 modes pour la phase 1 : **main mode** (6 paquets) et **agressive mode** (3 paquets). * **phase 2** : son but est de négocier les SAs pour monter le tunnel IPsec : * négociation des paramètres de sécurité (comme le tranform-set) * établissement d'une IPsec SA, protégée par la précédente SA de la phase 1 * périodiquement renégocie la SA ; renouvellement de la clé partagée Il n'existe qu'un seul mode pour la phase 2 : le **quick mode**. Lors de la négociation, le peer qui initie l'IKE envoie ses paramètres de sécurité et la machine d'en face doit chercher un matche parmi les siens. Il choisit par ordre de priorité les paramètres communs pour le chiffrement, le hash, l'authentification et les paramètres DH. * **Diffie-Hellman** : protocole de génération de clé partagée. Il ne permet pas de vérifier l'identité de chaque paire, donc il est vulnérable à une attaque de type [[http://fr.wikipedia.org/wiki/Man-in-the-middle|man-in-the-middle]]. * **ESP** (Encapsulating Security Payload) permet le chiffrement, l'authentification et l'intégrité des données ; IP proto n°50 * **AH** (Authentication Header) est un mécanisme d'authentification et d'intégrité des données ; IP proto n°51 AH utilise HMAC, une fonction de hashage avec une clé secrète. * **SA** (Security Associaion) : définit une politique d'IPsec incluant des clés partagés, mise en œuvre entre 2 machines. Sur une machine donnée, un tunnel établit un SA IPsec par sens (en revanche les SAs d'IKE sont bidirectionnels) ; ces SAs sont identiques sur la machine d'en face (le peer). Un SA est identifié par un SPI, une destination et un protocole (ESP ou AH). * **SPI** (Security Parameter Index) : un index SPI est associé à chaque SA par le gestionnaire de tunnel IPsec. * **SPD** (Security Policy Database) : database sur chaque machine qui contient : * l'algorithme de chiffrement * l'algorithme d'authentification * le mode (tunnel ou transport) * la durée de vie de la clé (exprimée en temps ou en volume de données transférées) * **SAD** (Security Association Database) : database sur chaque machine qui contient : * l'IP destination * le SPI * le protocole (ESP ou AH) Une SA est une compilation des données de ces 2 databases. * **RRI** (Reverse Route Injection) : une route statique est créé sur le serveur Cisco Easy VPN pour l'IP interne de chaque client VPN. Cela permet de les injecter ensuite dans l'IGP. **Méthodes d'authentification** : * couple nom d'utilisateur/mot de passe * OTP (One Time Password) * Biométrie * clé partagée * certificats numériques **Algorithmes de chiffrements symétriques** : on utilise la même clé pour chiffrer et déchiffrer * DES (Data Encryption Standard) ; vulnérable car basé sur des clés de 56 bits * 3DES (3 chiffrements DES à la suite) * AES (Advanced Encryption Standard) ; clés de 128, 192 ou 256 bits **Algorithmes de chiffrement asymétriques** : paire de clés publique et privée * RSA (Rivest Shamir Adleman) ; on peut utiliser différentes longueurs de clés ; il est recommandé aujourd'hui d'utiliser des clés de 1024, 2048 ou 4096 bit (parano) **Méthodes de hashage** : * HMAC (Hash-based Message Encryption Code) * MD5 (Message Digest 5) * SHA-1 (Secure Hash Algorithme 1) ====PKI==== **PKI** (Public Key Infrastructure) est un système servant à authentifier une clé publique d'une entité. Elle repose sur une relation de confiance entre une autorité de certification (**CA** pour //Certificate Authority//) et la personne qui cherche l'authenticité d'une clé publique. ====NAT Traversal==== IPSec est un protocole qui se base sur les adresses IPs de bout en bout ; il ne fonctionne donc pas si l'on modifie ces IPs. C'est le cas quand fait du NAT/PAT par exemple. Le **NAT Traversal** est un mécanisme d'encapsulation d'IPSec dans un datagramme udp/4500 (par défaut). C'est une bidouille qui permet à l'IPSec de traverser les équipements qui font du NAT, mais augmente de ce fait l'overhead des paquets. =====Mise en place d'IPsec===== Mise en place d'un tunnel IPSec entre 2 routeurs R1 et R2. ====Définition de la policy ISAKMP==== (Phase 1) Les politiques ISAKMP sont définies globalement et donc utilisables par tous les tunnels configurés sur le routeur. Leur utilisation se fait séquentiellement, par ordre croissant, en fonction de leur priorité ("1" dans l'exemple qui suit). Dès qu'une politique matche celle du peer, c'est elle qui est utilisée. On y définit le type d'authentification, l'algorithme de hashage, l'algorithme de chiffrement et le groupe Diffie-Hellman. crypto isakmp policy 1 authentication pre-shared hash sha encryption aes 128 group 2 Puis on indique la clé partagée ainsi que l'adresse du bout du tunnel (IP du peer). crypto isakmp key LaCleSecrete address 172.16.171.2 ====Définition de la crypto map==== Définition du ''transform-set'' qui spécifie la politique de sécurité d'IPsec (algorithme de chiffrement + d'authentification + autres paramètres facultatifs) : crypto ipsec transform-set TS-aes_sha esp-aes 128 esp-sha-hmac ! ! paramètre facultatifs mode transport Définition de la crypto map = associer un transform-set à un peer et à une ACL (cf plus bas) : crypto map VPN_To_R2 10 ipsec-isakmp set peer 172.16.171.2 match address 101 set transform-set TS-aes_sha set pfs group2 Définition de l'access-list qui spécifie quel trafic sera envoyé dans le tunnel (= domaine de chiffrement). access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 ====Appliquer la crypto map sur une interface==== interface se0/0 ip address 172.16.171.1 255.255.255.0 crypto map VPN_To_R2 =====Tunnel GRE over IPSec===== L'encapsulation GRE et celle employée par défaut pour les interfaces tunnel chez Cisco (équivaut à ''tunnel mode gre ip'') Soient R1 et R2 2 routeurs reliés par leur interface fa0/1 (10.2.4.1 et 10.2.4.2/24) ; on monte un tunnel GRE entre eux (10.1.4.1 et 10.1.4.2/24) et un tunnel IPSec par dessus. Sur R1 : crypto isakmp policy 1 encryption 3des authentication pre-share group 2 ! crypto isakmp key secretkey address 10.2.4.2 crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac ! crypto map SDM_CMAP_1 1 ipsec-isakmp set peer 10.2.4.2 set transform-set ESP-3DES-SHA match address 101 ! interface Tunnel0 ip address 10.1.4.1 255.255.255.0 ip mtu 1420 tunnel source FastEthernet0/1 tunnel destination 10.2.4.2 tunnel path-mtu-discovery crypto map SDM_CMAP_1 ! interface FastEthernet0/1 description Vers R2 ip address 10.2.4.1 255.255.255.0 duplex full speed 100 crypto map SDM_CMAP_1 ! ip route 0.0.0.0 0.0.0.0 Tunnel0 ip route 10.2.4.2 255.255.255.255 FastEthernet0/1 ! access-list 101 remark SDM_ACL Category=4 access-list 101 permit gre host 10.2.4.1 host 10.2.4.2 =====Redondance / Failover===== Il existe plusieurs méthodes pour mettre en place une redondance en cas de perte de lien, de défaillance matérielle ou de problème sur le réseau //unsecure// traversé par le tunnel. ====DPD + IPsec Backup peer==== * **DPD** (Dead Peer Detection) est un mécanisme natif d'IKE qui permet de détecter un problème sur le tunnel IPsec ; il est désactivé par défaut. Le DPD **on-demand** permet de ne vérifier que le peer est up que lorsque le routeur a du trafic à envoyer vers lui, ce qui réduit sa charge CPU. * **Cisco IOS Keepalive Feature** est un mécanisme similaire au DPD mais propriétaire Cisco. * L'IGP qui tournent sur un tunnel GRE over IPsec permet de détecter si le peer/neighbor tombe grâce aux "HELLO" du protocole de routage. On configure le DPD avec la commande suivante : ''**crypto isakmp keepalive** //seconds// [//retries//] [**periodic** | **on-demand**]'' Les secondes vont de 10 à 3600 et indique l'intervalle d'envoi des keepalive ; les retries, en secondes aussi, définissent le temps entre 2 tentatives si la précédente à échoué (par défaut 2 secondes). periodic et on-demand (par défaut) définissent le comportement des keepalive : périodiques (régulièrement toutes les x secondes) ou en fonction du trafic émis (s'il n'y a pas de trafic, pas d'envoi de keepalive). Quand le DPD détecte le peer IKE down, il va supprimer les SA IKE et IPSec de ce peer. S'il a un second peer déclaré dans la crypto map, il renégocie un tunnel avec ce dernier : crypto isakmp keepalive 10 3 crypto map CM 10 ipsec-isakmp set peer 10.0.0.1 default set peer 10.0.1.1 Le DPD est configuré pour envoyer des keepalive toutes les 10 secondes avec 3 //retries//. Pour vérifier que le DPD est activé (dans cet exemple là ce n'est pas le cas) : debug crypto isakmp [...] Jan 21 08:16:25: dpd enable: 0000, dpd periodic enable : 0000 Liens : * [[http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_ipsec_dead_peer.html|IPsec Dead Peer Detection Periodic Message Option]] sur cisco.com ====HSRP et RRI==== On peut mettre en place un tunnel IPsec sur une IP **HSRP** virtuelle ; pour cela on doit configurer le HSRP sur cette interface, et déclarer la crypto-map avec l'identifiant HSRP ainsi : crypto map VPN_To_R2 redundancy idHSRP ''idHSRP'' correspond à la directive ''name'' du HSRP, qui doit être appliquée sur l'interface de routage de cette façon : standby 1 name idHSRP Bien sur, c'est l'IP HSRP virtuelle qui doit être renseignée comme destination dans la conf du peer. Le **RRI** consiste à l'injection, par le master HSRP, d'une route statique dans l'IGP afin de forcer les flux par lui. On le met en place dans la crypto map par l'utilisation d'une **crypto dynamic-map** : crypto dynamic-map DM 10 reverse-route crypto map CM 10 ipsec-isakmp dynamic DM ====HSRP + SSO==== Les méthodes précédentes de failover sont sans état (stateless) car quand un peer passe down, le tunnel doit être réétabli. Il existe des solutions dites statefull qui permettent de partager un tunnel dans un environnement virtuel, partagé entre 2 machines par site. Cela permet de ne pas réétablir le tunnel et de reprendre "à chaud" la transmission des données chiffrées. SSO est un protocole de synchronisation d'associations de sécurité ISAKMP et IPsec entre des routeurs HSRP. Déclaration de la crypto map sur l'interface de routage avec le paramètre **stateful** : crypto map CM redundoncy idHSRP stateful Définition de la crypto map : crypto dynamic-map DM 10 set transform-set TS reverse-route ! crypto map CM 10 ipsec-isakmp dynamic DM ! redundancy inter-device scheme standby idHSRP Configuration du SSO avec le protocole SCTP (Steam Control Transmission Protocol) : ipc zone default association 1 protocol sctp local-port 12345 local-ip 10.1.1.1 retransmit-timeout 300 10000 path-retransmit 10 assoc-retransmit 20 remote-port 12345 remote-ip 10.1.1.2 ====Accélération matérielle==== Sur certains châssis on peut utiliser des modules d'accélération hardware ; c'est le cas des cartes AIM sur les châssis 3825 ou des carte SPA pour les châssis 650X. Dans ce dernier exemple si on utilise des tunnels GRE + IPsec il peut être intéressant dans certains cas de forcer la prise en charge des tunnels GRE chiffrés par la carte supervisor : ! prise en charge de la crypto par la carte SPA crypto engine gre vpnblade ! ! prise en charge par la carte supervisor crypto engine gre supervisor =====Vérifs===== show crypto isakmp key show crypto isakmp sa show crypto isakmp policy show crypto session detail show crypto engine connection active ====État des tunnels==== show crypto session Crypto session current status Interface: Vlan80 Session status: UP-ACTIVE Peer: 192.168.0.78/500 IKE SA: local 192.168.0.75/500 remote 192.168.0.78/500 Active IPSEC FLOW: permit 47 host 192.168.0.75 host 192.168.0.78 Active SAs: 2, origin: crypto map Session status (source : [[http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_ipsvm.html#wp1042935|IP Security VPN Monitoring]]) : ^Tunnel Status ^IKE SA ^IPSec SA^ |UP-ACTIVE |Exist, active |Exist (flow exists)| |UP-IDLE |Exist, active |None (flow exists)| |UP-IDLE |Exist, active |None (no flow)| |UP-NO-IKE |Exist, inactive|Exist (flow exists)| |UP-NO-IKE |None |Exist (flow exists)| |DOWN-NEGOTIATING|Exist, inactive|None (flow exists)| |DOWN-NEGOTIATING|Exist, inactive|None (no flow)| |DOWN |None |None (flow exists)| |DOWN |None |None (no flow)| Plus de détails : on précise l'adresse ip du peer pour n'afficher que son tunnel ; on récupère avec cette commande le mode IPSec (tunnel ou transport), les compteurs in/out, les SAs, etc. Router1#show crypto ipsec sa peer 10.1.1.1 interface: Vlan2784 Crypto map tag: cm100, local addr 10.0.0.1 protected vrf: (none) local ident (addr/mask/prot/port): (10.0.0.1/255.255.255.255/47/0) remote ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0) current_peer 10.1.1.1 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 2949679701, #pkts encrypt: 2949679701, #pkts digest: 2949679701 #pkts decaps: 1599171374, #pkts decrypt: 1599171374, #pkts verify: 1599171374 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 10.0.0.1, remote crypto endpt.: 10.1.1.1 path mtu 1500, ip mtu 1500 current outbound spi: 0xDA4B403D(3662364733) PFS (Y/N): Y, DH group: group5 inbound esp sas: spi: 0x3988518B(965235083) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } conn id: 8079, flow_id: :6079, sibling flags 80000240, crypto map: cm100 sa timing: remaining key lifetime (k/sec): (911080/3215) IV size: 8 bytes replay detection support: N Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xDA4B403D(3662364733) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } conn id: 8080, flow_id: :6080, sibling flags 80000240, crypto map: cm100 sa timing: remaining key lifetime (k/sec): (3101942/3215) IV size: 8 bytes replay detection support: N Status: ACTIVE outbound ah sas: outbound pcp sas: Autres commandes, en vrac : show crypto engine accel stat slot x/y detail et/ou show crypto ipsec sa ! show crypto ace polo detail show int tunnel351 stats show crypto vlan show crypto engine accelerator statistic all show ip int tu351 ! clear crypto engine accelerator counter all clear crypto session local 10.4.101.97 ====Renégocier un tunnel spécifique==== * Trouver le peer (l'IP de l'interface tunnel de l'équipement distant) : sh ip arp vlan 80 Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.0.78 21 0013.c37c.e940 ARPA Vlan80 Internet 192.168.0.75 - 0000.0c07.d34d ARPA Vlan80 Internet 192.168.0.74 - 0007.ec74.d4f0 ARPA Vlan80 Les "Age" = "-" sont les @ MAC locales, ici une adresse logique (HSRP) et une physique (celle du routeur). Le peer est donc le 192.168.0.78. * Puis on renégocie le tunnel : clear crypto session remote 192.168.0.78 =====Liens===== * [[http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml|Configuring a GRE Tunnel over IPSec with OSPF]] chez cisco * [[http://www.hsc.fr/ressources/articles/ipsec-tech/index.html.fr|Présentation technique d'IPsec]] * [[http://www.cisco.com/en/US/docs/ios/12_3t/secur/command/reference/sec_s2gt.html|Security Commands: show crypto isakmp key through subject-name]] En vrac, des liens destinés à comprendre et debugger l'IPSec : * [[http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftprefrg.html|Pre-fragmentation For Ipsec VPNs]] * [[http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtIPSctm.html|IPSec Virtual Tunnel Interface]] * [[http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-3s/Sharing_IPSec_with_Tunnel_Protection.html|Sharing IPSec with Tunnel Protection]] * [[http://www.cisco.com/en/US/docs/interfaces_modules/shared_port_adapters/configuration/6500series/76ovwvpn.html|Overview of the IPsec VPN SPA]] * [[http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml|Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC]] (white paper) * [[http://www.cisco.com/en/US/docs/interfaces_modules/shared_port_adapters/configuration/6500series/76cfvpnb.html|Configuring IPsec VPN Fragmentation and MTU]] * [[http://www.cisco.com/en/US/docs/ios/12_2/security/command/reference/srfipsec.html|IPSec Network Security Commands]]