HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Comment configurer un tunnel IPsec sur un routeur Cisco d'agence, en adressage dynamique, et sur une liaison de type RNIS
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Comment configurer un tunnel IPsec sur un routeur Cisco d'agence, en adressage dynamique, et sur une liaison de type RNIS  

by Hervé Schauer (05/12/2000)






Contexte

Soit une configuration de type classique avec :

  • Un site central avec une connexion permanente à l'Internet
  • Des routeurs d'agences
souhaitant dialoguer de manière chiffrée avec des tunnels IPsec.

Les routeurs d'agence sont des petits routeurs de type Cisco 800 par exemple. La connexion de ces routeurs est dynamique, au travers d'un ISP local en RNIS. L'adressage IP de ces routeurs est aussi dynamique, c'est aussi vrai si la connexion RNIS est remplacée par une connexion ADSL ou une connexion câble. Le tunnel IPsec est établi sur l'interface RNIS du routeur.

Sur le routeur central, le tunnel est établi sur l'interface externe ou sur l'interface de loopback qui peut être dans un adressage plus stable que l'interface externe.

Problème de l'authentification mutuelle

Sur les routeurs Cisco, pour réaliser l'authentification des équipements pour monter des tunnels IPsec, il est possible d'utiliser :

  • Les secrets partagés préalables (Pre-Shared-Keys) ;
  • Les clés publiques (chiffrement RSA) ;
  • Les certificats X.509 (signature RSA).

Les secrets partagés posent trois problèmes :

  • Les secrets partagés ne permettent pas une gestion à grande échelle de nombreuses agences.
  • L'identifiant est l'adresse IP de l'interface de connexion. Dans notre cas où l'adressage est dynamique, c'est inutilisable.
  • Le mot de passe est en clair dans la configuration du routeur Cisco. La commande "show conf" permet de voir le mot de passe en clair. Compte-tenu de la situation en agence du routeur, c'est un risque inacceptable.

Les clés publiques posent également un problème d'échelle : les clés publiques de tous les interlocuteurs devant être fournies manuellement au routeur, une gestion à grande échelle de nombreuses agences n'est pas possible.

Les certificats X.509 ne sont pas sujets aux restrictions précédentes car :

  • Ils ne sont pas liés à l'adresse IP utilisée par le routeur 
  • Ils sont échangés en ligne pendant la négociation IKE.

Problèmes des certificats

Les certificats X.509 posent deux problèmes :

  • La gestion des certificats;
  • La nécessité pour le routeur d'agence de connaître la date et l'heure pour vérifier le certificat du routeur central.

La gestion des certificats impose de disposer d'une autorité de certification. Cisco propose le protocole SCEP (Simple Certificate Enrollment Protocol), décrit sur http://www.ieng.com/warp/public/cc/pd/sqsw/tech/scep_wp.htm. Le protocole SCEP impose l'utilisation d'un produit commercial, il n'existe pas d'implémentation de référence librement accessible, ni d'implémentation en logiciel libre.

Problèmes des montées et descentes de tunnels IPsec

La coupure de la ligne RNIS dès qu'il n'y a plus de trafic, et la reconnections dès qu'il y a du trafic, provoquent un nombre élevé de demandes de montées de tunnels depuis les routeurs d'agence.

Le même routeur d'agence peut redemander une ouverture de tunnel plusieurs fois par jour avec des adresses IP différentes. Le problème est que lorsque la ligne RNIS est raccrochée, le tunnel IPsec n'est pas fermé proprement par IOS : il n'y a pas d'envoi de message SA delete. Il est donc possible que lorsque le routeur d'agence se reconnecte, le routeur central utilise encore la SA précédente alors que le routeur d'agence n'en a plus. Si le routeur d'agence a du trafic à envoyer, il renégocie les SA, sinon il reçoit du trafic sans connaître le SPI et on a l'erreur :

%CRYPTO-4-RECVD_PKT_INV_SPI

Solution pour le tunnel sur RNIS

La solution aux montées et descentes de tunnels IPsec est de faire correspondre la durée de vie des SA au trafic sur la ligne. Pour cela Cisco a ajouté une fonction propriétaire de keepalive dans le protocole d'échange de clés IKE, disponible depuis IOS 11.3(6)T ou 12.0.

crypto isakmp keepalive  

Avec les valeurs par défaut, le routeur va envoyer un keepalive toutes les 600 secondes pour vérifier que son interlocuteur est là. Si celui-ci ne réponds pas, il réessaye toutes les 2 secondes, 5 fois (valeurs en dur).

Cependant l'utilisation des keepalive va garder la ligne RNIS connectée en permanence. La solution serait alors de filtrer les keepalive, mais ceux-ci ne sont pas distinguables des autres paquets IKE. Il faudrait alors enlever IKE de l'ACL de l'interface de dialup afin que le trafic IKE ne déclenche plus la connexion RNIS. Mais dans ce cas on ne peut plus établir la ligne sur la réception de trafic à chiffrer.

La solution est de filtrer sur l'adresse source. Lorsque IKE est le premier paquet, l'interface externe du routeur n'a pas encore d'adresse IP, et donc l'adresse IP source est "0.0.0.0". Il suffit d'autoriser dans l'ACL de l'interface de dialup le protocole IKE, mais uniquement depuis l'adresse source "0.0.0.0". Le trafic IKE dû aux keepalive par la suite ayant comme adresse source l'adresse de l'interface, il ne provoquera pas la connexion RNIS si celle-ci est déconnectée.

interface bri0
    ip address negotiated
    dialer-group 1
!
dialer-list 1 protocol ip list 100
!
access-list 100 permit udp host 0.0.0.0 eq isakmp
access-list 100 permit udp host 192.70.106.165 eq isakmp
access-list 100 permit esp any host 192.70.106.165

Solution pour avoir la date et l'heure

La nécessité de connaître la date et l'heure pour vérifier les certificats est un problème, car, par souci de rentabilité extrême sur les routeurs d'entrée de gamme de Cisco, ceux-ci sont dépourvus d'horloge. Lorsque l'on redémarre le routeur, sa date est le 1er janvier 1993. Il refusera de valider les certificats émis en l'an 2000... La solution est d'apporter de l'extérieur l'heure sur le routeur. Cela est possible avec une horloge externe par l'interface série, mais c'est très coûteux.

interface aux 0
    ntp ref-clock

C'est aussi possible avec NTP.

Pour mettre le routeur à l'heure avec NTP il suffit de configurer NTP et d'interdire le chiffrement du trafic NTP. NTP n'a pas besoin d'être chiffré, car il intègre son propre mécanisme d'authenticité (non-configuré dans l'exemple).

ntp server 192.70.106.165 source bri0

Le routeur n'ayant pas d'horloge, au démarrage il peut arriver dans certaines version qu'il refuse son propre certificat si le besoin du tunnel IPsec lance IKE en même temps que NTP, avant d'avoir la date juste. La solution est de systématiquement récupérer son certificat auprès de l'autorité de certification. Cela permet aussi d'économiser l'espace mémoire.

crypto ca certificate query

Lorsque le routeur s'allume, NTP est lancé et le routeur se met à l'heure, le routeur récupère son certificat, et ensuite lance IKE.

Le problème est alors que NTP va faire sans arrêt du trafic et garder la ligne RNIS connectée.

Au démarrage du routeur, le trafic NTP n'est pas nécessairement le premier trafic, et donc l'utilisation du filtrage sur l'adresse source "0.0.0.0" comme avec IKE ne marche pas. Dans ce cas la solution est une ACL sur le temps : si la date est inférieure au 1er Janvier 2000 on autorise NTP, sinon on filtre le trafic NTP.

interface bri0
    ip address negotiated
    dialer-group 1
!
dialer-list 1 protocol ip list 101
!
Time-range NTP_startup end 12:00 1 January 2000
!
access-list 101 permit udp any eq ntp host 192.70.106.165 eq ntp time-range NTP_startup
access-list 101 deny any any

Au démarrage, la date est le 1er Janvier 1993 donc NTP provoque la connexion de la ligne RNIS, après 3 paquets NTP l'horloge du routeur est synchronisée et l'ACL ne laisse plus passer NTP.


Glossaire, Références et Remerciements

ACL :
Access-Control-List, liste de contrôle d'accès : ensemble de sélections d'adresse IP source, adresse IP destination, protocole, port source, et port destination, afin de sélectionner des trafics particuliers :"access-list" sur Cisco.
SA :
Security Association, Association de Sécurité, voir http://www.hsc.fr/ressources/veille/ipsec/papier/papier.html.fr#112
SPI :
Security Parameter Index, Index des Paramètres de Sécurité, voir http://www.hsc.fr/ressources/veille/ipsec/papier/papier.html.fr#112

Références

Remerciements

  • à Olivier Dupont de Cisco pour avoir eu l'idée de l'ACL sur le temps pour NTP
  • à Ghislaine Labouret, pour les tests, sa relecture et ses précieux conseils
Last modified on 18 November 2003 at 10:17:21 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants