Centre Génie Industriel et Informatique (G2I) MISE EN PLACE D UN RESEAU PUBLIC D ACCUEIL SECURISE AU SEIN D UN RESEAU D ETABLISSEMENT HETEROGENE

Transcription

1 Centre Génie Industriel et Informatique (G2I) MISE EN PLACE D UN RESEAU PUBLIC D ACCUEIL SECURISE AU SEIN D UN RESEAU D ETABLISSEMENT HETEROGENE P. JAILLON, M. ROELENS, X. SERPAGGI Avril 2006 RAPPORT DE RECHERCHE

2 Les rapports de recherche du Centre G2I de l'ensm-se sont disponibles en format PDF sur le site Web de l'ecole G2I research reports are available in PDF format on the site Web of ENSM-SE Centre G2I Génie Industriel et Informatique Division for Industrial Engineering and Computer Sciences (G2I) Par courier : By mail: Ecole Nationale Supérieure des Mines de Saint-Etienne Centre G2I 158, Cours Fauriel SAINT-ETIENNE CEDEX 2 France

3 Mise en place d un réseau public d accueil sécurisé au sein d un réseau d établissement hétérogène P. Jaillon, M. Roelens, X. Serpaggi Centre de Génie Industriel et d Informatique École Nationale Supérieure des Mines de Saint-Etienne 10 avril 2006 Résumé Le but de ce document est de présenter une méthode que nous avons mise en place pour permettre à tout utilisateur disposant d un ordinateur portable, de se connecter à un réseau en libre accès et de rejoindre son réseau privé de manière sécurisée. En pratique, une personne accédant avec son portable à un des espaces publics équipés, quel que soit son système d exploitation (Windows, Mac OSX, Linux) va être capable de se connecter au réseau sans encombre et ainsi obtenir les services basiques qui y sont offerts (accès web) ; mais en plus, s il dispose des éléments d authentification requis, il pourra se connecter directement dans son propre sous-réseau (réseau du laboratoire ou du service auquel il appartient). Ce service sera valable quel que soit le moyen de connexion, filaire ou sans fil type WiFi, ce dernier étant celui qui nous a poussé à nous pencher sur cette problématique. L utilisateur n aura donc plus à se soucier de savoir où il se trouve, quelle adresse internet il devra utiliser, et quels doivent être ses paramètres réseau. 1

4 Table des matières 1 Introduction 4 2 Outils et protocoles IPsec (IP Secure) IKE (Internet Key Exchange) Gestion des certificats X openssl Formats d échange L2TP (Layer 2 Tunneling Protocol) PPP (Point to Point Protocol) Architecture du réseau Le réseau Invités Interconnexion avec les réseaux privés de l établissement Interconnexion avec les réseaux d accueil Mode de fonctionnement Résumé Fonctionnement détaillé Routage Mise en place sous Windows XP SP2 (client) Mode secret partagé Utilisation des certificats X Mise en place sous Mac OSX (client) Mode secret partagé sous OSX 10.3 Panther Utilisation de certificats X509 sous OSX 10.4 Tiger Mise en place sous Linux (client) IPsec et IKE avec un noyau Mode secret partagé Utilisation de certificats X IPsec et IKE avec un noyau Mode secret partagé Utilisation de certificats X L2TP PPP Mise en place sous Solaris 10 (serveur) IPsec Fichier /etc/inet/ipsecinit.conf IKE Mode secret partagé Utilisation de certificats X Roaring-Penguin L2TP

5 7.3.1 Fichier l2tp.conf PPP Configuration réseau Mise en place sous CISCO IOS (serveur) Serveur d authentification RADIUS Configuration du routeur CISCO Configuration de gnu radius

6 1 Introduction Notre objectif est de proposer une architecture de réseau qui puisse permettre à un utilisateur disposant d un ordinateur portable, de pouvoir rejoindre un réseau de manière sécurisée depuis n importe quel endroit (ou en tous cas, un nombre important d endroits «publics») équipé de l établissement. Ce travail a été appliqué au réseau Invités et au réseau WiFi de l école nationale supérieure des mines de Saint-Etienne. Il y a en fait deux grandes catégories d utilisateurs, et donc d utilisations : soit l utilisateur nomade est une personne extérieure à l établissement (vacataire, participant à une réunion de travail, conférencier) ; son souhait est alors simplement de pouvoir accéder à un nombre restreint de services comme l accès à un serveur DNS, l accès à Internet (HTTP et HTTPS), la connexion à distance sécurisée (SSH) ; soit l utilisateur nomade est un membre de l établissement, qui se déplace temporairement avec son poste de travail usuel (ou un poste «commun») en un lieu «public» (pour faire un cours dans un amphi, pour assister à une conférence ou une réunion...) ; son souhait est alors de pouvoir se trouver dans une configuration identique à celle de son poste habituel (accès à ses serveurs de fichiers, de messagerie, d applications...). Dans les deux cas, la politique de sécurité de l établissement ne doit pas être mise en cause. En pratique, une personne arrivant dans une salle avec son portable, quel que soit son système d exploitation (Windows, Mac OSX, Linux) doit être capable de se connecter au réseau sans encombre. Mieux, il sera directement connecté dans son propre sous-réseau (réseau du laboratoire ou du service auquel il appartient). Ceci sera valable quel que soit le moyen de connexion, filaire (Ethernet) ou sans fil type WiFi, ce dernier étant ce qui nous a poussé à nous pencher sur cette problématique. FIG. 1 Principe général Afin d obtenir un confort d utilisation, il est souhaitable que l utilisateur n ait pas à se soucier de savoir où il se trouve, quelle adresse internet il doit utiliser, et quels doivent être ses paramètres réseau. 4

7 2 Outils et protocoles Pour réaliser ceci, nous avons été amené à utiliser plusieurs outils sur les différentes plate-formes, mettant en œuvre plusieurs protocoles. 2.1 IPsec (IP Secure) Remarque : nous nous plaçons dans le cadre d une utilisation d IPv4 uniquement, bien que rien ne s oppose à l usage IPv6. Le protocole IPsec 1 [7] permet de créer un canal chiffré (au niveau IP) entre deux interfaces réseaux. Ceci est entièrement transparent pour les applications utilisant ces interfaces à chacune des extrémités du canal. Il y a deux modes possibles : le mode tunnel, dans lequel de nouvelles interfaces réseau sont créées et c est à travers ces interfaces qu a lieu la communication (IP dans IP). Ce mode sert essentiellement à la réalisation de VPN (Virtual Private Network) dans le cadre de la communication de réseau à réseau ; le mode transport, qui masque les trames IP originales pour recréer les siennes. Les interfaces réseau restent les mêmes. C est ce mode que nous utilisons, car nous n avons pas besoin de masquer les adresses réseau. Dans les deux modes, IPsec offre : le protocole AH[5] (Authentication Header) qui rend le protocole IP robuste au vol de session et insensible à certains dénis de service, mais sans chiffrer les données transportées (elles sont cependant signées et ne sont donc pas altérables) ; le protocole ESP[6] (Encapsulating Security Payload) où les données sont chiffrées et signées. 2.2 IKE (Internet Key Exchange) Le protocole IPsec, afin d assurer une bonne sécurité, doit vérifier l identité des parties en communication et, pour chiffrer la session, a besoin d échanger entre ces parties une clé de session. En fait, IPsec délègue à une application externe ces deux tâches : cette application porte le nom générique d IKE pour Internet Key Exchange[3]. Les IKE utilisent deux grandes méthodes pour cet échange : la vérification de la possession d un secret commun (échangé préalablement), que l on nomme preshared key ; l utilisation de certificats X509. Certains IKE peuvent proposer d autres moyens, comme l utilisation de couples de clefs publique et privée. Les IKE que nous avons utilisés sont : RACOON sous Mac OSX et Linux 2.6, pluto sous Linux 2.4 et in.iked sous Solaris. Sous Windows, l IKE est intégré à la couche réseau et n a pas de nom spécifique. 1 Cette notation est celle donnée dans le RFC

8 2.3 Gestion des certificats X509 Cette partie sera beaucoup plus détaillée dans un rapport (à venir...) sur la meilleure façon de gérer une infrastructure de clefs publiques (ou Public Key Infrastructure, plus communément PKI). Nous supposons ici que nous disposons d une autorité de certification 2 commune pour les clients et les serveurs, ce qui est plus simple à gérer. La procédure de génération standard d un certificat consiste à : générer le couple clef privée / clef publique du demandeur ; générer une demande de signature de certificat (certificate signing request ou CSR) pour le demandeur ; faire signer électroniquement la CSR par l autorité de certification et fournir le certificat ainsi généré au demandeur. Rappelons que le certificat contient la clef publique du demandeur. Il existe une autre fonctionnalité intéressante : la possibilité de révoquer un certificat émis par l autorité (lorsqu on suspecte une compromission de ce certificat). La façon dont cette liste de révocation est utilisée par les IKE est en fait dépendante des implémentations : il est donc indispensable de se reporter aux manuels de ces divers IKE. Nous verrons dans la section un exemple de cette gestion openssl openssl est un ensemble d outils permettant de gérer une autorité de certification : il permet d accomplir toutes les phases décrites précédemment. Il permet également de gérer les listes de révocation (cette fonction sera décrite dans la partie concernant le serveur). La plupart des commandes de openssl utilisent un fichier de configuration général pour l autorité de certification, que l on appelle ici myca.cnf. Un certain nombre d informations doivent être précisées dans ce fichier de configuration pour les certificats à destination des serveurs telles que les attributs AlternateName, keyusage... Les diverses données (clefs, certificats, CSR) sont stockées sous forme ASCII dans des fichiers texte, utilisant un format appelé PEM. Les diverses étapes à réaliser sont précisées ci-après. Attention : il ne faut pas les utiliser telles quelles sans avoir bien compris ce que ces commandes réalisent! Génération du couple de clefs privée et publique On doit utiliser la sous-commande genrsa de la commande openssl, comme dans l exemple suivant : openssl genrsa -des3 -out host.key.pem 2048 Le couple de clefs est stocké dans le fichier host.key.pem, il est chiffré en triple- DES avec un mot de passe que la commande réclame (ne pas l oublier). Attention : la clef privée générée est l élément fondamental de construction de l architecture de sécurité! On 2 Certification Autority en anglais, communément abrégé par CA 6

9 doit tout faire pour en préserver son intégrité et sa confidentialité, sous peine de se retrouver dans une situation de compromission du certificat. Génération de la CSR On doit cette fois-ci utiliser la sous-commande req de la commande openssl, comme dans l exemple suivant : openssl req -config myca.cnf -new -key host.key.pem \ -out host.csr.pem Cette commande interactive va demander de renseigner un certain nombre d éléments qui vont constituer le distinguished name c est-à-dire l identifiant unique qui sera associé à la clef publique. La CSR est stockée au format PEM dans le fichier host.csr.pem. Signature de la CSR et création du certificat On doit utiliser la sous-commande ca de la commande openssl, comme dans l exemple suivant : openssl ca -config myca.cnf -infiles host.csr.pem \ -out host.crt.pem Il s agit ici de la véritable création du certificat : celle-ci ne doit pas être accomplie à la légère par l autorité de certification, qui doit vérifier l identité du demandeur, l usage qui sera fait du certificat Formats d échange Le format PEM des clefs et des certificats générés par openssl n est pas toujours directement exploitable par les outils de gestion des divers systèmes. Il existe pour ce faire des formats d échange, qui permettent de transporter dans un seul fichier le(s) certificat(s) d autorité de certification, les clefs et les certificats des parties impliquées. Par exemple, les outils mmc sous Windows et Trousseau d accès sous Max OSX utilisent tous deux un format appelé PKCS12 permettant d importer les éléments indispensables pour tout client : sa clef privée et son certificat associé, ainsi que les éventuels certificats des autorités de certification nécessaires. La commande openssl permet de générer ce fichier comme dans l exemple ci-après : openssl pkcs12 -export -in host.crt.pem -certfile ca.crt.pem \ -inkey host.key.pem -name "host" -out host.p12 Dans cette commande, host.crt.pem est le certificat fabriqué pour cette machine, host.key.pem la clef privée correspondante, ca.crt.pem le certificat de l autorité de certification et host.p12 le fichier dans le format d échange. Le nom qui est donné par 7

10 l option -name est un nom d usage : lors de l opération d importation, c est ce nom qui est utilisé par le logiciel de gestion des certificats pour désigner ce couple certificat et clef. 2.4 L2TP (Layer 2 Tunneling Protocol) L2TP [9], successeur IETF 3 des protocoles de tunneling 4 propriétaires comme ATMP 5 (Ascend/Lucent), L2F 6 (CISCO ), PPTP 7 (Microsoft), etc., a été normalisé dans le RFC 2661 (Août 1999). Il permet le transport en mode tunnel de trames PPP (voir plus loin) par dessus un réseau de transit de manière aussi transparente que possible pour les applications et les utilisateurs. D un point de vue technique, le protocole L2TP utilise le protocole UDP, sur le port Précisons quelques termes utilisés pour caractériser les différents points d accroche de ce tunnel. Le LAC ou L2TP Access Concentrator, est en quelque sorte le client L2TP. C est l entrée du tunnel du point de vue de l utilisateur. Ça peut-être, soit un équipement spécialisé, soit une partie du client L2TP de votre système (le LAC est alors confondu avec votre ordinateur). On peut également trouver le nom de NAS (Network Access Server) pour désigner un LAC. Le LNS ou L2TP Network Server, est le serveur L2TP. C est le point de sortie du tunnel et c est à lui que le LAC va se connecter pour créer ce tunnel. Le LNS est donc une interface entre le réseau auquel l utilisateur veut se connecter (typiquement le réseau de son entreprise), et le réseau dans lequel le tunnel va exister (typiquement, le réseau Internet). Plusieurs LAC peuvent se connecter à un même LNS. On peut également trouver le nom de HGW (Home GateWay) pour désigner un LNS. 2.5 PPP (Point to Point Protocol) Le protocole PPP est celui qui va nous permettre de créer effectivement le canal de communication entre les deux parties qui désirent converser. En fait, il va pouvoir faire un peu plus en affectant une adresse IP à la machine itinérante, qui appartiendra au réseau destination et ce, de telle façon que tout soit transparent pour le système d exploitation de la machine itinérante. Autant, pour ce qui concerne IPsec et L2TP, la notion de client/serveur est assez floue (les deux concepts étant pratiquement mélangés pour ces protocoles), autant pour PPP, le principe s applique pleinement. Le canal de communication PPP s établit donc entre le LNS et la machine mobile. Le LAC lui, se trouve entre les deux. Le canal PPP dépasse donc du tunnel L2TP. En pratique, dans notre cas, le LAC et la machine cliente étant confondus, le canal PPP et le tunnel L2TP sont pratiquement identiques. 3 Internet Engineering Task Force ( 4 orthographe nord-américaine utilisée dans le RFC 5 Ascend Tunneling Management Protocol 6 Layer Two Forwarding 7 Point-to-Point Tunneling Protocol 8

11 Pour que tout cela fonctionne, il faut donc disposer, du côté du LNS, d un serveur PPP qui soit capable de recevoir les appels entrants et de les traiter : en n acceptant que les clients correctement authentifiés (mécanisme d identifiant/mot de passe). en leur affectant une adresse IP ; cette adresse étant soit fixe, soit choisie dynamiquement dans un pool/une plage d adresses ; en fournissant les données propres à une connexion confortable au réseau (DNS, route par défaut). PPP supporte de nombreux protocoles d authentification tel que PAP 8, CHAP 9 ou MS- CHAP. En général on a tendance à préférer CHAP à PAP car il ne laisse pas circuler de mots de passe en clair sur la ligne (il s agit de répondre correctement à un challenge envoyé par le serveur pour apporter la preuve que l on est bien en possession du secret partagé). Dans notre cas, nous lui préférerons l utilisation de PAP car : toutes les communications transitent dans un canal IPsec qui est déjà crypté ; nous ne souhaitons pas maintenir sur le serveur la liste de mots de passe en clair, ce qui serait imposé par CHAP ; d un point de vue pratique, PAP, lorsque l on utilise l option login de PPP nous permet d utiliser l authentification Unix standard (login/password). Malgré tout, si une personne malveillante réussit à écouter le tunnel L2TP (en cassant la protection IPsec), elle verra passer en clair les identifiants et mots de passe. 3 Architecture du réseau Décrivons maintenant l architecture du réseau répondant à nos besoins (voir la figure 2). 3.1 Le réseau Invités Il est donc proposé de constituer, dans tous les lieux publics de l établissement, un unique réseau Invités. Ce réseau est unique au sens IP : afin de disposer d un nombre suffisant d adresses dans ce réseau pour les utilisateurs nomades, on peut utiliser le réseau non routable de classe A (le réseau ) ou l un des réseaux non routables de classe B (dans la plage à ). En terme de technologie de liaison, on peut utiliser aussi bien de la technologie filaire (prises RJ45 disponibles dans les lieux publics) que de la technologie sans fil (WiFi). Le fait d avoir un seul réseau permet de diminuer le nombre nécessaire de bornes d accès, ainsi que les problèmes d interférence entre réseaux WiFi multiples. Du point de vue des services disponibles sur ce réseau, on doit notamment trouver : DHCP un serveur permettant de fournir à la demande des adresses dans le réseau Invités, ainsi que les informations de configuration du réseau comme le masque de réseau, la route par défaut, l adresse du serveur DNS... ; comme le réseau Invités est unique, on peut se contenter d un seul serveur DHCP ; 8 Password Authentication Protocol 9 Challenge Handshake Authentication Protocol 9

12 DNS un serveur de noms de domaines, qui peut être un simple relais applicatif (faisant office de cache) vers le service DNS de l Internet ; si besoin, on peut avoir plusieurs de ces relais (pour une meilleure disponibilité) ; HTTP/HTTPS un simple relais applicatif vers l Internet ; SSH ce service ne requiert pas de serveur sur le réseau Invités. 3.2 Interconnexion avec les réseaux privés de l établissement Ce réseau Invités doit être relié au reste du réseau de l établissement, par l intermédiaire du firewall. C est ce firewall qui est chargé de transcrire les adresses en sortie du réseau de l établissement (technologie NAT), donc également pour le réseau Invités. Pour une configuration de sécurité optimale, il est souhaitable que la machine réalisant les services DNS et proxy HTTP soit «en coupure» entre le réseau Invités et le firewall ; en effet, cette machine doit disposer de prérogatives particulières sur le firewall (autorisation de sortie en protoles DNS, HTTP, HTTPS), et il n est pas souhaitable qu une machine usurpant l adresse IP de ce serveur obtienne ces prérogatives. FIG. 2 architecture générale du réseau Invités 3.3 Interconnexion avec les réseaux d accueil Pour réaliser l intégration d un poste du réseau Invités dans l un des réseaux de l établissement (administration ou recherche), on doit disposer les machines faisant office de LNS entre ces réseaux : un LNS, techniquement parlant, est ainsi une machine dotée d au moins deux interfaces, l une dans le réseau Invités, l autre dans le réseau d accueil. 10

13 On aurait pu également disposer des serveurs LNS dans le réseau Invités, ces LNS réalisant alors la connexion IPsec par l intermédiaire du firewall. Mais on ne gagne pas grand chose en terme de sécurité (le firewall doit laisser passer un trafic sans pouvoir analyser son contenu) tout en augmentant la charge de ce firewall. Notons également que si l on dispose d un LNS avec plus de deux interfaces, on peut utiliser un seul LNS pour réaliser l interconnexion avec plusieurs réseaux d accueil, ce qui limite alors le nombre et la charge d administration de ces LNS. 3.4 Mode de fonctionnement Résumé En fin de compte, qu obtient-on? La situation est résumée sur le schéma 3. réseau public (LAN, Wifi) réseau privé LAC LNS l2tpd if0 Canal IPsec (mode transport) ife l2tpd ifi liaison l2tp pty UDP:1701 pty pppd pppd pppk ppp0 FIG. 3 Schéma d encapsulation des différents protocoles La situation initiale est : le LNS dispose d une interface interne (ifi) sur le réseau privé, et d une interface externe (ife) sur le réseau public (LAN ou Wifi) ; le LAC dispose d une interface (if0) sur le réseau public ; Après établissement des connexions, la situation finale est la suivante : le LAC dispose d une interface point à point (ppp0) reliée à l interface point à point du LNS (pppk) sur le réseau privé : de ce fait, le LAC fait désormais partie intégrante de ce réseau privé. Le LNS peut bien sûr servir de relais pour des LAC multiples : il crée à la demande les interfaces pppk, chaque interface étant reliée à un LAC. Mais le serveur L2TP sur le LNS est unique. 11

14 3.4.2 Fonctionnement détaillé Une fois cette architecture mise en place, comment se passe une liaison entre applications (une requête sur un serveur NFS du réseau privé, par exemple)? La cascade des traitements est la suivante : l application prépare son paquet (UDP ou TCP, en ce qui concerne NFS), transmis à la couche réseau IP ; dans le mécanisme de routage local au LAC, ce paquet IP est à destination du réseau privé, donc routé vers l interface ppp0 ; le démon pppd du LAC reçoit ce paquet, l encapsule en PPP, le transmet (par liaison interne sur pty) au démon l2tpd ; le démon l2tpd du LAC reçoit le paquet PPP, l encapsule en L2TP (UDP sur port 1701), et l émet à destination du LNS ; le paquet UDP est transmis à la couche réseau, qui est IPsec dans ce cas (liaison sur le réseau public) ; en mode transport, le contenu du paquet est chiffré (les adresses IP du LAC et du LNS sont par contre conservées), et le paquet IPsec est transmis à l interface (physique) sur ce réseau if0 (trame Ethernet ou trame Wifi) ; la trame arrive sur le LNS par l interface externe ife puis remonte dans la couche réseau, qui est IPsec, et donne donc lieu à vérification du paquet ; si l authentification réussit, le paquet est transmis à la couche supérieure, qui est UDP sur port 1701, donc vers le démon l2tpd du LNS ; après vérification, le démon l2tpd du LNS désencapsule le paquet interne (paquet PPP), qui est transmis (par liaison interne sur pty) au démon pppd concerné (rappel : il peut y avoir plusieurs démons pppd, mais chaque liaison L2TP est identifiée par un numéro de tunnel et un numéro de session dans le protocole) ; le démon pppd du LNS désencapsule le paquet PPP et transmet le contenu (paquet IP à destination du serveur) sur l interface pppk ; ce paquet étant à destination du réseau privé, il est transféré vers l interface physique interne ifi (NB : ceci nécessite que le routage soit activé entre les interfaces du LNS). Le retour est effectué selon la même procédure, en sens inverse Routage Le mécanisme de routage doit être quelque peu explicité : le LAC dispose donc de deux interfaces, l une dans le réseau public, l autre dans le réseau privé ; il faut absolument interdire le routage entre ces deux interfaces, sous peine de créer un «cheval de Troie» permettant d entrer sous forme chiffrée qui plus est dans le réseau privé! en ce qui concerne la route par défaut, on peut utiliser la route par défaut du réseau privé (ou de façon plus générale, la même politique de routage que le réseau privé, excepté le réseau public directement accessible par l interface if0, bien sûr) ; le LNS dispose de ses deux interfaces initiales, plus toutes les interfaces point à point créées à la demande des LAC ; il faut, là encore et pour les mêmes raisons, interdire le routage entre l interface externe et les autres interfaces ; on doit par contre autoriser globalement le routage entre l interface interne et les interfaces point à point, afin que toutes les machines du réseau privé qu elles soient physiquement sur ce réseau privé ou reliées par le réseau public puissent communiquer entre elles ; 12

15 enfin, pour le réseau privé, il faut bien comprendre que cette architecture entraîne que des machines appartenant du point de vue IP à ce réseau privé, sont accessibles pour les autres machines internes par les interfaces point à point du LNS ; pour ce faire, on peut utiliser la fonctionnalité de proxy-arp du démon pppd ; ainsi, lorsque l interface PPP est créée, le démon ajoute une entrée dans la table ARP du LNS, associant l adresse IP du LAC et l adresse MAC de l interface interne (ifi) : cette entrée est alors disponible pour les autres machines du réseau privé qui veulent établir une communication avec ce LAC. 4 Mise en place sous Windows XP SP2 (client) Avec Windows XP SP2, les éléments nécessaires sont installés dans le système et il va juste nous suffire de cocher les bonnes cases aux bons endroits pour que tout se mette à marcher. Comme toujours avec Micro$oft, il ne s agit ici que de la théorie Mode secret partagé Pour un fonctionnement de IPsec avec "secret partagé", la configuration est assez simple, et nécessite d être connecté en mode «Administrateur». dans le Panneau de configuration, choisir la catégorie Connexions réseau et internet, puis l icône Connexions réseau ; dans le menu Gestion du réseau, choisir Créer une nouvelle connexion, ce qui lance un «Assistant Nouvelle Connexion» ; le premier écran permet de choisir le type de configuration de la connexion, ce qui nous intéresse est une «connexion au réseau d entreprise» ; le second écran permet de choisir le type de réseau, qui est un «réseau privé virtuel» (ou VPN) ; le troisième écran permet de donner un nom à cette connexion, on peut par exemple la nommer Accès au réseau d accueil ; sur le quatrième écran, il faut choisir de «ne pas établir la connexion initiale» puisque nous utilisons le support de notre accès LAN (WiFi ou Ethernet) ; sur le cinquième et dernier écran, nous fournissons l adresse du serveur L2TP (adresse du LNS) et nous en avons terminé (si on le souhaite, on peut cocher la case créant un raccourci sur le bureau). L assistant ouvre alors la fenêtre de connexion de cette nouvelle interface (disponible maintenant dans le menu "connexions réseau"). il faut alors renseigner nom d utilisateur et mot de passe, ces paramètres sont à destination de PPP et dans notre cas doivent correspondre à un compte utilisateur valide dans le réseau d accueil. ce n est pas encore terminé, car avant de se connecter, il faut donner quelques renseignements supplémentaires, ce qui se fait en cliquant sur le bouton «Propriétés». On obtient alors une série d onglets (voir figure 4) à compléter : Général cet onglet permet de spécifier l adresse IP de notre serveur L2TP (LNS) ; on peut également cocher la case Afficher une icône dans la zone de notification une fois connecté ; 13

16 FIG. 4 Onglets de configuration de la connexion Options on trouve ici quelques options sans beaucoup d importance telles que Indiquer l état d avancement durant la connexion (utile pour déboguer), ou Demander un nom, un mot de passe, un certificat, etc. ; Gestion réseau il faut compléter cet onglet avant celui qui s appelle «sécurité» car certains paramètres de sécurité dépendent de choix faits ici ; en particulier, on sélectionne dans la liste qui est offerte le type du VPN que l on compte utiliser, qui est VPN L2TP IPsec dans notre cas et on peut également sélectionner les services qui pourront être routés dans le tunnel (TCP/IP, services Windows,...) ; Sécurité (il faut compléter l onglet Gestion réseau avant celui-ci, certaines options en dépendant) sur le serveur L2TP nous avons décidé d utiliser PAP comme protocole d authentification, il est de ce fait nécessaire de le configurer de manière explicite : cocher la case "Avancés (paramètres personnalisés)" et cliquer sur le bouton "Paramètres..." qui vient de s activer. pour le choix du Cryptage de données, choisir dans la liste «cryptage optionnel (connecter même s il n y a pas de cryptage)» (dans notre cas, la liaison est chiffrée par IPsec, c est imposé par le serveur) ; pour le choix de la Sécurité à l ouverture de session, choisir «Autoriser ces protocoles», puis cocher la case "Mot de passe non crypté (PAP)" et décocher toutes les autres cases. lors de la validation de cet onglet, si vous voyez apparaître un message d alerte indiquant que PAP est dangereux, c est que vous n avez pas encore renseigné l onglet "Gestion réseau" (recommencez l étape précédente). Pour un accès IPsec avec secret partagé, sélectionnez "Paramètres IPsec", cocher la case "secret partagé" et spécifier une clef valide. Cette clef est à spécifier en 14

17 ASCII ou si elle est en hexadécimal, précédez-la de 0x (par exemple test ou 0x ). Avancé c est ici que se règlent les principaux problèmes de sécurité : la première chose est de ne surtout pas partager cette connexion internet, le risque étant ici d offrir l accès à votre réseau d accueil à tout le réseau Invités (cela déroge à notre politique de sécurité et cette machine transforme notre gateway en passoire...) ; la seconde est de protéger ce poste client des accès directs (partage de fichier par exemple) depuis le réseau Invités en activant le firewalling de XP. c est maintenant fini, vous pouvez démarrer la connexion, et si tout a bien été rempli, la connexion s établit! La dernière remarque que nous avons à faire concerne la gestion des proxies. XP gère un proxy par connexion en plus de la configuration générale ; un message obscur vous indiquant d ailleurs que dans le cas présent le proxy ne sera pas utilisé. Il est donc nécessaire de configurer explicitement le proxy pour notre connexion VPN L2TP (Outil, Options Internet, onglet Connexions). 4.2 Utilisation des certificats X509 Maintenant que nous avons une machine qui se connecte correctement à notre LNS en utilisant un secret partagé, la seule modification que nous allons avoir à faire dans la configuration de la connexion va consister à ne plus utiliser ce secret. Il nous suffit donc de décocher la case "secret partagé" de la fenêtre "Paramètres IPsec" (voir l onglet sécurité décrit au paragraphe précédent). A partir de cet instant, Windows XP va tenter de s authentifier auprès du LNS en utilisant sa base de données de certificats. On rappelle que, pour une bonne sécurité, l authentification voulue par IPsec est réciproque : le LAC doit pouvoir vérifier l identité du LNS, et pour ce faire, doit disposer du certificat de l autorité de certification qui a délivré le certificat du LNS ; le LNS doit pouvoir vérifier l identité du LAC, et pour ce faire, le LAC doit disposer d un certificat (et de la clef privée associée!) délivré par une autorité connue du LNS. Sous Windows XP, ces opérations nécessitent l installation de certificats «système» (ce ne sont pas des informations spécifiques de l utilisateur), et l outil permettant de les réaliser s appelle la Microsoft management console (mmc). Cet outil prend en charge le format d échange PKCS12, permettant de regrouper toutes les informations voulues comme indiqué au paragraphe 2.2. Le lancement du programme mmc doit se faire en mode administrateur, soit dans une console, soit à partir du menu Exécuter. Une fois ce programme lancé : sélectionnez le menu Fichier, article Ajouter/supprimer un composant logiciel enfichable ; une fenêtre s ouvre ; cliquer sur Ajouter (on ne peut rien faire d autre) : une fenêtre s ouvre (encore) ; sélectionner Certificats, cliquer sur Ajouter ; une fenêtre s ouvre (la troisième...) ; choisir "Le compte de l ordinateur" ; pour IPsec, les certificats identifient la machine, et non l utilisateur qui s en sert ; cliquer sur Terminer : la fenêtre se ferme (et d une) ; 15

18 cliquer ok (on a maintenant une entrée Certificat (ordinateur seul)) ; cliquer ok : la fenêtre se ferme ; dans la fenêtre principale de mmc, déployer l entrée Certificats ; sélectionner Personnel au début de la liste ; l accès au menu Action/Toutes les Tâches/Importer... déclenche l exécution de l assistant d importation des certificats. Lorsque vous êtes arrivé sur l écran Fichier à importer, sélectionner le fichier PKCS12 (suffixe.p12) contenant les certificats relatifs au poste concerné, passez aux écrans suivants, fournissez les mots de passe qui vous sont réclamés. Lorsque vous atteignez l écran Magasin de certificats, sélectionnez l option Sélectionnez automatiquement le magasin de certificats selon le type de certificat et passez à la suite. FIG. 5 Interface graphique de la console de management Après avoir actualisé l affichage (menu Action/Actualiser), le dossier Personnel contient le certificat (avec sa clef privée) que vous venez d importer (voir la figure 5). Vous pouvez consulter les informations relatives à ce certificat en double-cliquant dessus. Dans notre cas, nous avons aussi importé le certificat de notre autorité de certification, vous pouvez en consulter le contenu dans le premier dossier Autorités de certifications racines. 5 Mise en place sous Mac OSX (client) Sous Mac OSX, il n y a aucun logiciel supplémentaire à installer : tout est déjà intégré au système d exploitation. Comme nous sommes sur une base Unix BSD, RACOON est ici utilisé pour l IKE. La machine n a pas de programme particulier pour gérer L2TP, la notion de plugins a été rajoutée à pppd par Apple et c est ce dernier qui se charge de la négociation du tunnel. Malheureusement, comme souvent chez le constructeur à la pomme, les commandes modifiées ne sont pas documentées... 16

19 5.1 Mode secret partagé sous OSX 10.3 Panther L interface graphique offerte par OSX est simple, elle est accessible par l utilitaire du dossier "Applications" appelé "Connexion à Internet". Une fois l application lancée, l interface permet de créer un "VPN L2TP" (cliquer sur l icône) et de le configurer. Le menu "Configuration", article "Modifier les configurations..." permet d avoir accès à l ensemble des paramètres (IPsec, L2TP et PPP) et de les sauvegarder. Les informations que l on y trouve sont les suivantes (voir figure 6) : Description permet de nommer la configuration ; Adresse serveur est l adresse du serveur L2TP à contacter (le LNS) ; Nom du compte, pour spécifier à pppd le nom de l utilisateur qui veut se connecter ; Authentification (avec mot de passe), le mot de passe pour l utilisateur spécifié, dans notre cas il s agira du mot de passe associé au compte de l utilisateur tel que défini dans le NIS, l annuaire LDAP ou le fichier passwd du serveur ; Secret partagé est le secret partagé pour IPsec (mode pre-shared key 10 ). FIG. 6 Interface de configuration du VPN (Mac OSX 10.3) Une fois tous les éléments correctement renseignés, il suffit de cliquer sur le bouton "Se connecter" pour établir une liaison chiffrée avec le LNS et rejoindre son réseau d accueil. Un certain nombre de paramètres vont être positionnés automatiquement (l adresse IP dans le réseau d accueil, la route par défaut et normalement le DNS), il reste par contre à renseigner les proxies et les éventuels domaines de recherche. Ces derniers éléments de configuration se font pour la connexion VPN qui est accessible dans les «Préférences Système» à la rubrique «Réseau». Apple nous cache derrière cette devanture interactive la création de la configuration de RACOON. L application interactive crée le fichier <@IP_LNS>.conf dans le répertoire /etc/racoon/remote/ et puis démarre le processus RACOON (ou lui envoie un signal SIGHUP si celui-ci est déjà lancé). RACOON inclut alors ce nouveau fichier dans sa configuration (directive include "/etc/racoon/remote/*.conf"; qui est présente dans 10 Dans la version 10.3 (panther), seul le mode d authentification par secret partagé fonctionne avec l interface graphique. Nous verrons que la version 10.4 (tiger) permet la gestion par certificats. 17

20 le fichier /etc/racoon/racoon.conf). De plus, une politique de communication est automatiquement ajoutée pour refléter la nécessité de chiffrer les communications avec le serveur L2TP. On peut consulter cette politique avec la commande setkey. # setkey -DP [1701] [49316] udp in ipsec esp/transport//require spid=68 seq=1 pid=1907 refcnt= [49316] [1701] udp out ipsec esp/transport//require spid=67 seq=0 pid=1907 refcnt=1 On peut remarquer que Apple restreint le chiffrement aux seules données UDP circulant entre la machine locale, port source utilisé par le client L2TP (ici le processus pppd) et le serveur L2TP port destitnation Noter encore qu il y a une politique pour chaque sens de la connexion réseau. Voici un exemple du contenu du fichier de configuration qui est créé par Connexion à Internet : remote { exchange_mode main; doi ipsec_doi; situation identity_only; shared_secret use "plain text secret"; nonce_size 16; lifetime time 3600 sec; initial_contact on; support_mip6 on; proposal_check obey; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo address /32 [49254] 17 address /32 [1701] 17 { lifetime time 3600 sec; encryption_algorithm aes, 3des; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate; } 18

21 sainfo address /32 [49254] 17 address /32 [0] 17 { encryption_algorithm aes, 3des; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate; } Le RACOON disponible sous OSX est une version modifiée par Apple, disposant d une directive supplémentaire (shared_secret dans l exemple ci-dessus) qui n est évidement pas décrite dans les pages de manuel et dont l objectif semble être de n avoir à intervenir que dans un seul fichier lors de la création de la configuration. Si l on explore les sources de RA- COON diffusées par OPENDARWIN 11, on se rend compte que la directive shared_secret peut admettre d autre types de paramètres : remoteconf.h:int secrettype;/*type of secret [use,key,keychain]*/ RACOON utilisant la première configuration disponible lors de la négociation IKE, cela nous permet sans trop de difficulté d avoir une authentification par certificat : il suffit de créer une configuration ad-hoc et de lui donner un nom tel que RACOON en vienne à l utiliser en premier (l expérience montre que votre fichier doit apparaître après celui qui a été créé automatiquement lorsque vous faites un ls -l /etc/racoon/remote/*.conf pour qu il soit utilisé). Les informations à renseigner pour que ce mode d authentification fonctionne sont les mêmes que pour Linux (cf. la section page 25). 5.2 Utilisation de certificats X509 sous OSX 10.4 Tiger Avec cette version du système, différents utilitaires ont évolué, et certains d entre eux offrent de nouvelles fonctionnalités. En particulier, il est possible, grâce à la nouvelle version de Connexion à Internet, de configurer l authentification IPsec par des certificats, ce que nous allons détailler. Cette nouvelle interface présente les différences suivantes : le champ Authentification est précisé en champ Authentification des utilisateurs ; les méthodes d authentification des utilisateurs sont complétées (certificat, Kerberos), mais nous continuons d utiliser le mot de passe ; on dispose d un champ intitulé Authentification des machines, offrant comme précédemment le secret partagé, mais aussi le certificat ; il suffit de cocher cette case, et de cliquer sur le bouton Choisir afin de choisir le certificat d identification de la machine..., mais encore faut-il avoir un tel certificat (sinon, l interface signale qu elle n en a trouvé aucun)! Le LAC doit donc disposer d un certificat "machine". Il est bien sûr nécessaire que l autorité de certification qui va signer ce certificat soit reconnue par le LNS : idéalement, c est la même autorité de certification qui signe le certificat du LNS et ceux des LAC. Pour que l interface graphique «trouve»ce certificat (lorsque l on clique sur le bouton Choisir) et la clef privée associée, ils doivent être impérativement installés dans le keychain

22 FIG. 7 Interface de configuration du VPN (Mac OSX 10.4 Tiger) System (pour simplifier, sous Mac OSX, un keychain est un ensemble de ressources d authentification protégé par un unique moyen : mot de passe le plus souvent). Le plus simple est, comme sous Windows XP, d utiliser un fichier d échange PKCS12 (voir la génération d un tel fichier au paragraphe 2.2) et de l installer avec l utilitaire "Trousseau d accès" après avoir rendu le répertoire /Library/Keychains/ et le fichier System.keychain qu il contient writable par le groupe admin (dont vous faites partie puisque vous êtes administrateur). Mais ce n est pas tout : il faut également que RACOON accepte (reconnaisse) le certificat présenté par le LNS. Il faut pour cela respecter les points suivants : premièrement, ce qui est classique, RACOON doit disposer (dans l un des keychains) du certificat racine de l autorité de certification qui a signé le certificat du LNS ; ceci permet au LAC de vérifier la validité du certificat et donc l identité de ce LNS ; deuxièmement, le certificat du LNS doit avoir une extension Subject Alternative Name qui doit impérativement contenir des valeurs de la forme DNS:server_name, OSX vérifiant que cette information est bien la même que celle que l on a renseigné dans la fenêtre, champ "Adresse du serveur". Attention : on ne peut pas ici désigner le serveur par son adresse IP! troisièmement, comme nous ne sommes pas arrivés à faire accepter à RACOON une adresse IP pour désigner le LNS (surtout vérifier qu il s agit bien du bon serveur...) et comme le réseau Invités ne dispose pas de serveur DNS, nous avons dû rajouter une entrée de type machine au serveur Netinfo local. Pour ce faire, il faut employer l utilitaire "Gestionnaire NetInfo" et créer une nouvelle entrée dans la liste machine et définir les propriétés name et ip_address. Normalement, une fois toutes ces contraintes respectées, il n y a plus qu à cliquer sur le bouton Se connecter pour se retrouver dans notre réseau d accueil. 20

23 6 Mise en place sous Linux (client) 6.1 IPsec et IKE avec un noyau 2.4 Linux 2.4 ne possède pas de support natif pour IPsec, il va donc falloir en ajouter un. Deux implantations sont aujourd hui disponibles : Strongswan et OPENSWAN. Le monde n étant définitivement pas parfait, l une est bien documentée et l autre offre plus de fonctionnalités. Nous avons choisi d ajouter OPENSWAN 12 à notre système. L installation est simple mais nécessite la présence des sources du kernel. Les éléments installés sont un module pour le kernel (ipsec.o désigné sous le vocable de KLIPS - pour Kernel Linux IPsec), les commandes utilisateurs (pluto et ipsec), les scripts de démarrages ainsi que les fichiers de configuration. ipsec est la commande qui permet de gérer IPsec (démarrer, arrêter les chiffrements, activer un tunnel particulier...). pluto est le démon en charge de la négociation des «security associations» (il est l équivalent de racoon ou de in.iked). OPENSWAN est l un des projets qui a succédé à Freeswan. Il a hérité d un certain nombre de travers de son glorieux ancêtre dont un, et non des moindres, va nous poser quelques problèmes : rien n a été fait pour faciliter l usage du mode transport de IPsec. La configuration de OPENSWAN est centralisée dans le fichier /etc/ipsec.conf. Nous donnons ici les configurations pour une connexion avec un secret partagé et avec authentification par certificats X509. Seule la partie de la configuration relative au mode connexion est différente (conn LNS). Le fichier de configuration /etc/ipsec.conf contient une partie commune aux deux modes de connexion : # /etc/ipsec.conf - strongswan IPsec configuration file # version 2.0 # conforms to second version of ipsec.conf specification config setup interfaces="ipsec0=eth1" conn %default type=transport left= La ligne interfaces="ipsec0=eth1" a pour effet de supprimer la mise en place automatique de route par défaut par OPENSWAN (routes qui perturbent le fonctionnement du mode transport), mais en contre partie, il ne nous est plus possible de disposer implicitement de notre adresse IP

24 6.1.1 Mode secret partagé Il faut alors ajouter dans le fichier /etc/ipsec.conf : conn LNS # preshared keys right= authby=secret auto=add Le secret partagé est quant à lui conservé dans le fichier /etc/ipsec.secrets, sous la forme : : PSK "le secret partagé" # le secret qui sert pour toutes # les connexions : PSK "le secret partagé" Attention : ce secret partagé étant stocké en clair, il est indispensable d en protéger l accès! Il faut donc le faire appartenir à root, avec droits de lecture et d écriture exclusifs pour le propriétaire Utilisation de certificats X509 Pour ce mode d authentification, il est nécessaire de fournir à pluto les certificats nécessaires (celui de la machine et celui de l autorité de certification). Ils doivent être stockés dans les répertoires appropriés : /etc/ipsec.d/certs/ pour le certificat de la machine, /etc/ipsec.d/private/ pour la clef privée de la machine, /etc/ipsec.d/cacerts/ pour les autorités de certifications reconnues. conn LNS # X509 authentication leftcert=me.cert.pem right= rightid="c=fr, O=EMSE, CN=lns" authby=rsasig auto=add On indique dans le fichier /etc/ipsec.secrets quelle est la clef privée (et éventuellement le mot de passe permettant son utilisation) associée au certificat utilisé pour identifier la machine. :RSA me.key.pem "key password if required" Attention : on retrouve ici les contraintes de sécurisation. Si la clef privée est stockée en clair, il faut en restreindre au maximum l accès (appartenance à root, droits de lecture et 22

25 d écriture exclusifs pour le propriétaire). Si la clef privée est stockée cryptée, c est le mot de passe stocké dans le fichier /etc/ipsec.secrets qui doit être protégé. La commande pour activer la communication chiffrée est : ipsec auto --up LNS Il ne nous reste plus qu à activer L2TP pour rejoindre notre réseau d accueil. 6.2 IPsec et IKE avec un noyau 2.6 IPsec est intégré en natif au noyau 2.6, il nécessite éventuellement un paramétrage du noyau et l intégration des différents algorithmes de chiffrement (en tant que module ou intégré au noyau) : -> Device Drivers -> Networking support -> Networking options <*> PF_KEY sockets... <M> IP: AH transformation <M> IP: ESP transformation <M> IP: IPComp transformation <M> IP: tunnel transformation -> Cryptographic API --- HMAC support <M> Null algorithms... <M> MD5 digest algorithm... <M> DES and Triple DES EDE cipher algorithms <M> Blowfish cipher algorithm... <M> AES cipher algorithms (i586)... <M> CRC32c CRC algorithm Setkey Du côté espace utilisateur, c est l utilitaire setkey(8) qui permet de gérer les règles à appliquer entre les différentes adresses Internet mises en jeu. Dans notre cas, on ne définit que les politiques de sécurité. Tout le reste est fait par IKE (algorithmes de chiffrement et génération des clefs). En fait, setkey permet uniquement de dire que «Si je veux aller de la machine à la machine , ma politique de sécurité m oblige à utiliser IPsec dans le mode transport. De même, si je veux aller de la machine à la machine , une autre 23

26 politique de sécurité m oblige à utiliser IPsec en mode transport.» Il n est donc rien dit à ce niveau quant à l authentification des parties. L utilitaire setkey se configure en général à l aide du fichier /etc/ipsec.conf. On peut, de toutes façons, utiliser n importe quel fichier en le passant en paramètre avec le sélecteur -f. Par exemple, la commande : setkey -f /home/r2d2/setkey.conf prendra comme fichier de configuration, le fichier /home/r2d2/setkey.conf. Le format de ce fichier est décrit dans la page de manuel de setkey(8) et contient les descriptions des politiques de sécurité (et d autres choses dans le cas général, mais ici, ce ne sont que les politiques de sécurité spd, pour security policy database qui nous intéressent). Par exemple, ce qui suit est un fichier de configuration de setkey valide : #!/usr/sbin/setkey -f # Fichier /etc/ipsec.conf flush; spdflush; # Security policies spdadd any -P out ipsec esp/transport//require; spdadd any -P in ipsec esp/transport//require; Les deux premières lignes qui ne sont pas des commentaires signifient que setkey doit vider (flush) les tables déjà présentes : ceci est une considération de prudence, permettant d éviter des erreurs ultérieures difficiles à détecter... Ensuite, arrive la description des politiques proprement dites. Il suffit de bien respecter le fait qu il faut une définition par sens de transport. Le mot clé any signifie que l on peut utiliser n importe lequel des protocoles présents dans /etc/protocols. Le reste est assez évident (se reporter à la page de manuel de setkey(8) pour des explications complémentaires). Une fois que nos politiques sont définies, il faut s authentifier auprès de l autre extrémité : c est le travail de RACOON. RACOON L IKE est géré par RACOON qui se charge donc de négocier des clefs pour l authentification des deux bouts de la liaison. RACOON nécessite que la partie politiques de sécurité d IPsec ait été activée au préalable. RACOON propose les deux méthodes classiques pour l authenfication : l utilisation d un secret partagé, ou l utilisation de certificats. La configuration de RACOON se fait dans le fichier racoon.conf, se trouvant en général dans le répertoire /etc/racoon. 24