Pffff IPSec la blague... Saviez-vous que dans le monde sérieux des entreprises qui gèrent des succursales, des partenaires et des tiers mainteneurs, IPSec est une réalité ? Peut-être que pour vous ce n'est pas le cas. D'autres solutions d'interconnexions sont pour vous plus abordables, plus simples à mettre en place. Peut-être aussi que pour vous IPsec est réservé à une élite... Ce n'est pas faux... IPSec est peut-être obscur, les solutions sont souvent chères ou difficiles à mettre en place, voire les deux à la fois. Mais ce qui est certain, c'est que c'est une solution propre, bien ficelée et surtout interopérable, aujourd'hui indispensable pour interconnecter son réseau avec d'autres. Avec OpenBSD, vous avez maintenant la possibilité de mettre en place simplement une solution au top. Allez, suis-moi maraud, on va leur montrer de quel bois on se chauffe à ces Juniper, Cisco et autres Enterasys.

1. Récupération, installation et compilation d'IPSec pour OpenBSD

Ne cherchez pas, il n'y a rien à faire en dehors d'installer OpenBSD sur la plate-forme de son choix (x86, amd64, macppc, zaurus, sparc...). IPSec est supporté de base. Simple non ?

2. Directement dans le vif du sujet qui brûle

Premier contact avec IPSec sur OpenBSD 4.0 : ... de bon augure n'est-ce pas ?

3. IPSec fwwwwwWwwou FLASHBACK !

IPSec, quand on n'est pas ingénieur, ça fait peur. En fait, ça fait peur même aux ingénieurs. IPsec est un protocole imaginé par des collèges de normalisation qui ont voulu se faire plaisir : le résultat, c'est un machin complexe, sûrement trop complexe, qui oblige à être vigilant <... suite du blabla classique qui accompagne IPsec...>. Mais bon, dans ce monde merveilleux des lutins IP, il n'y a pas encore de meilleure solution [1]. OpenBSD a ainsi été le premier système d'exploitation à inclure de base IPSec en 1997. En effet, en cette deuxième partie des années 1990, les législations concernant les moyens de chiffrement et leur exportation étaient relativement sévères, en particulier aux États-Unis. Le projet OpenBSD basé au Canada et déjà très intéressé par l'intégration de ce genre d'outil a tout naturellement occupé cette place. Mais, presque dix ans après, quoi de neuf ? Eh bien, pas grand-chose, en dehors d'une bonne interopérabilité entre les différentes implémentations libres ou commerciales. D'habitude, c'est là que je me mange : " ouais, c'est mort, maintenant il y a mieux, il y a OpenVPN (lecteur, insère ici ta solution de VPN SSL préférée) ". Ok, donc je disais l'interopérabilité... (là, généralement, les plus relous continuent avec OpenVPN et leur client multiplateforme). Et là je dis : " stop, ton OpenVPN tu le connectes comment aujourd'hui au Juniper ou au checkpoint de la Megacorp avec laquelle tu dois travailler ? ". Bon et sinon IPSec... " Ipsec, c'est une paire de... protocoles, l'ESP (Encapsulating Security Payload) et l'AH (Authentication Header) qui fournissent les services pour sécuriser IP : la confidentialité, l'intégrité, l'authenticité, la protection... ". Après cela, on en sait un peu plus de ce que sont " AH ", " ESP ", les " SA ", les " SPI ", le mode tunnel, le mode transport, les " Lifetimes ". On découvre isakmpd(8) et aussi un exemple de configuration qui conceptualise un peu tout ça avec la mise en place d'un VPN (Virtual Private Network ou Réseau Privé Virtuel). Mais rassurez-vous, lecteur, pour le moment la seule chose que l'on doit retenir, c'est simplement que l'on veut mettre en place ce VPN.

4. Un VPN IPSec en 5 min ?

Qu'est-ce qu'un VPN ? D'après Wikipédia, un VPN est un réseau virtuel, car il relie deux réseaux " physiques " (réseaux locaux) par une liaison non fiable (par exemple, Internet) et privée, car seuls les ordinateurs des réseaux locaux, de part et d'autre du VPN, peuvent " voir " les données. Avec IPSec, on peut monter un VPN avec le protocole ESP en mode tunnel. Par contre, pour éviter toute confusion et pour que les choses soient bien claires, quand on parle ici de monter un VPN IPSec, on parle bien de mettre en place une solution pour interconnecter deux réseaux, c'est-à-dire une solution de passerelle à passerelle. Depuis la version 3.8 d'OpenBSD, une commande magique a fait son apparition : ipsecctl(8). Elle a gentiment écarté l'ancienne commande ipsecadm qui vient de disparaître du système. L'idée d'ipsecctl est de configurer un VPN IPSec de la même manière que l'on configure un firewall pf avec pfctl... tout un programme. Résultat : aujourd'hui, grâce à OpenBSD, on peut mettre IPSec entre toutes les mains. Ce que j'ai oublié de dire, c'est que si vous voulez m'accompagner dans les travaux pratiques qui suivent, il ne vous faudra non pas installer un OpenBSD, mais installer deux machines sous OpenBSD. J'en vois qui ricanent déjà : " ah, elle est belle l'intéroperabilité ".

4.1 Le plan d'attaque

L'idée est de faire communiquer les deux réseaux IP " A " et " B " à travers les passerelles " Coker " et " Spud ", connues respectivement avec les adresses IP " 1.1.1.1 " et " 2.2.2.2 " sur un réseau ressemblant étrangement à Internet, mais en bien plus dangereux encore.

4.2 Première étape : configurons IPSec

Sur Coker : Sérieusement, pour les utilisateurs de pf, cela ne vous rappelle-t-il pas quelque chose ? Sur Spud :

4.3 Deuxième étape : installons de bons secrets

Pas de VPN sans secrets... Un des meilleurs alliés d'IPSec, c'est le certificat numérique X509 et OpenBSD ne déroge pas à cette règle. Toutefois, tout le monde ne disposant pas de certificats X509, la solution de repli était en général d'utiliser de bons vieux mots de passe (ou secret partagé ou PreShared Key). OpenBSD propose cependant en plus une solution intermédiaire. A l'installation du système, un couple de clefs publique/privée a été généré dans le répertoire /etc/isakmpd/private/. L'idée est de distribuer la clef publique, un peu comme on a l'habitude de le faire pour SSH, aux machines avec lesquelles nous allons monter des connexions IPSec. Bref, on oublie tout de suite les mises en place de tunnels avec des mots de passe comme " test " et " toto " sous le seul prétexte que cela est plus simple et qu'il ne s'agit que d'un test... Quoique même ça, avec ipsecctl, c'est encore plus simple... Donc, copions le fichier /etc/isakmpd/private/local.pub de Spud vers le fichier /etc/isakmpd/pubkeys/ipv4/2.2.2.2 sur Coker et de copier le fichier /etc/isakmpd/private/local.pub de Coker vers le fichier /etc/isakmpd/pubkeys/ipv4/1.1.1.1 sur Spud. La démarche est identique avec des FQDN plutôt que des adresses IP (exemple avec aflab.est.une.loutre.gcu.info ou hr.assume.gcu-squad.org). On aurait ainsi utilisé le fichier /etc/isakmpd/pubkeys/fqdn/aflab.est.une.loutre.gcu.info sur Coker. Il faudra cependant aussi le spécifier dans /etc/ipsec.conf à l'aide des mots clefs " srcid " et " dstid " pour qu'ipsecctl retrouve ses petits (ike esp from 192.168.1.0/24 to 192.168.2.0/24 peer 2.2.2.2 srcid aflab.est.une.loutre.gcu.info dstid hr.assume.gcu-squad.org).

4.4 Troisième étape : on lance IPSec

Sur Coker : Sur Spud : Maintenant, il ne reste plus qu'à monter et tester le VPN à coup de ping(8) entre les réseaux 192.168.1.0/24 et 192.168.2.0/24. On peut aussi vérifier l'état des tunnels sur chacune des passerelles avec ipsecctl et/ou netstat. Sur Coker : Ou encore...

4.5 Dernière étape : on garde tout cela en mémoire

Oui on va quand même s'arranger pour qu'au prochain démarrage, le VPN soit monté automatiquement, parce que, bon, il ne faudrait pas avoir à refaire tout ça... Donc sur Spud et Coker, on fait : Bravo, c'est terminé, vous avez mis en place un VPN IPsec en cinq minutes entre deux passerelles OpenBSD et en utilisant, pour les puristes, IKE avec des clefs asymétriques : alors vous trouvez ça encore compliqué IPSec ?

5. ipsecctl et isakmpd, copains comme cochons

Là, vous allez me dire que c'est un peu normal que ça marche aussi facilement entre deux OpenBSD. On peut faire la même chose presque aussi simplement avec n'importe quelle autre solution IPSec. Eh bien, c'est que vous avez manqué l'essentiel... Revenons un peu sur ipsecctl et notre ligne d'ipsec.conf. Déjà, on aurait pu mettre en place un tunnel manuel, en utilisant à la place d'" ike " le mot clef " flow ". Cependant, je ne serais pas en ce moment en train de vous expliquer la magie s'opérant entre ipsecctl et isakmpd... Pour la littérature... isaknpd(8), isaknpd.conf(5) et idaknpd.policy(5). Bon, alors rapidement, IKE est un protocole d'échange de clefs utilisé aujourd'hui par IPSec. isakmpd, c'est le nom du démon qui gère IKE sur OpenBSD, et isakmpd.conf et isakmpd.policy sont les fichiers utilisés pour le configurer. Le mot clef " ike " dans le fichier ipsec.conf indique à ipsecctl qu'il doit gérer le démon isakmpd. ipsecctl et ipsec.conf deviennent alors une véritable couche d'abstraction aux fichiers de configuration isakmpd.conf et isakmpd.policy, qui, soit dit en passant, en ont bien besoin. Notez que c'est aussi pour cette raison que nous avons démarré isakmpd avec l'option -K. C'est elle qui indique à isakmpd que comme ipsecctl mène la danse, il n'a pas besoin de charger quoi que ce soit. Cependant, tous les paramètres d'isakmpd ne sont pas (encore ?) gérés par ipsecctl. Donc, dans certains cas, il faut encore travailler simultanément avec ipsecctl et un isakmpd.conf minimal. Mais, en attendant, comparons... Une configuration d'isakmpd qui ressemblait, avant, à ça... ...ressemble maintenant à ça : C'est quand même plus compréhensible... Imaginons que l'on ait des centaines de tunnels à gérer comme c'est souvent le cas sur des équipements centraux, eh bien, on appréciera tout de suite l'amélioration apportée par l'outil. C'est un peu comme, et loin de moi l'idée de lancer un troll puant, comparer des jeux de règles Netfilter à des jeux de règles pf. Je suis sûrement un peu idiot, mais j'ai toujours du mal à comprendre les jeux de règles Netfilter. Et si, toutefois, on a des doutes sur le travail réalisé par ipsecctl ou que l'on a beaucoup d'affinités avec l'ancienne méthode, on a la possibilité de visualiser nos jeux de règles IPSec dans un format isakmpd.conf : Maintenant vous avez remarqué que, dans ce précédent exemple, la configuration est plus compliquée que celle que nous avons utilisée pour monter notre VPN en cinq minutes : ??nous y avons en particulier précisé les algorithmes à utiliser. Car, en effet, si par défaut on ne précise pas certains paramètres, ipsecctl va en choisir de solides pour nous (par exemple AES-256, SHA2-256). C'est très bête, tout le monde aurait pu le faire et pourtant, au bout de dix ans, c'est le genre d'idée qui change tout. Je rajouterai qu'en plus ça rentre complètement dans la philosophie d'OpenBSD : ??mais vraiment, pourquoi n'ont-ils pas fait ça avant ?

6. Et si ça ne marche pas ?

Justement, je parlais d'huîtres... On a de la chance, de base sous UNIX et en particulier sous OpenBSD, on a plein de trucs pour débugger les problèmes de tuyauterie IPSec. Avec -d, on positionne isakmpd en debug, -DA=XX permet de faire varier le nombre et la qualité des informations à afficher. Le -v permet de détailler. 500 pour voir le protocole IKE, esp pour voir l'ESP et 4500 pour voir IPSec encapsulé dans UDP (NAT-T). ou encore enc0 pour rappel, c'est la pseudo interface liée à IPSec. Cette commande permet donc de regarder ce qui se passe à l'intérieur du tunnel. Le -I peut être extrêmement pratique pour vérifier l'état du tunnel directement depuis la passerelle. On y trouve de bonnes informations sur l'implémentation d'isakmpd dans OpenBSD (il faut cependant avoir récupéré les sources). De quoi se retourner plusieurs fois le cerveau...

7. Une cerise sur un gâteau : sasyncd

Un jour de mars 2005 est tombé ceci dans le CVS du projet OpenBSD : Log Message: Directory /cvs/src/usr.sbin/sasyncd added to the repository. sasyncd ? Oui sasyncd(8), voyons... le démon de synchronisation d'IPSec. Pourquoi synchroniser IPSec ? Pour la même raison que l'on synchronise les états d'un firewall, pour éviter de se retrouver avec des utilisateurs déconnectés et des applications plantées si quelque chose de triste arrive à notre passerelle IPSec. Mais, à vrai dire, synchroniser les informations des tunnels IPSec actifs (les " SA " ou " Security Association ") ne sert pas à grand-chose tout seul. En revanche, synchroniser quand on utilise en parallèle un mécanisme de haute disponibilité réseau comme CARP(4), cela devient une tuerie. Je ne m'attarderai pas trop longtemps sur CARP. Cependant, pour les lecteurs qui ne connaissent pas encore ce protocole, il s'agit d'un mécanisme qui permet de partager une même adresse IP virtuelle entre plusieurs équipements sur un même LAN (ou réseau local). Un des équipements voit son interface CARP désignée, en fonction de paramètres, comme " MASTER " et les interfaces CARP des autres équipements se positionnent en " BACKUP ". C'est l'équipement possédant l'interface CARP à l'état " MASTER ", qui utilisera l'interface IP virtuelle associée. Enfin, des événements externes peuvent avoir des effets sur les interfaces CARP et ainsi entraîner l'élection d'un nouveau " MASTER ". En mars 2005, il était cependant encore un peu tôt, et c'est seulement avec OpenBSD 4.0 que sasyncd est devenu réellement intéressant, plus robuste et plus agile. Avec l'arrivée " du compteur de dégradation " de CARP (carpdemote) contrôlable en userland, sasyncd a gagné un peu de pouvoir. Par exemple, en mode préemptif (preempt), une interface CARP ne rebasculera à l'état " MASTER " qu'après avoir complètement synchronisé ses " SA " [2][3][4]. Il est devenu agile comme un pfsync, je vous dis ! Renseignons-nous un peu… sasyncd(8) et sasycnd.conf(5).

7.1 Le nouveau plan

Nous allons tester CARP et sasyncd dans un scénario très basique en s'appuyant sur notre TP de tout à l'heure. Nous allons ajouter la machine Pinpin à notre configuration, machine qui devra travailler de concert avec Coker en partageant des interfaces CARP en mode préemptif et en synchronisant ses SA avec cette dernière. Notez que l'interface 1.1.1.1 est devenue une interface virtuelle CARP.

7.2 Configurons CARP

Sur Coker : Je saute volontairement la configuration des autres interfaces pour me concentrer sur les aspects spécifiques de sasyncd. Sur Pinpin :

7.3 Configurons sasyncd

Sur Coker : Sur Pinpin : Sur les deux machines : Pensez qu'il faudra relancer isakmpd, s’il a été arrêté depuis. Pensez aussi à partager les règles ipsec.conf entre les deux machines. De même, assurez-vous d'avoir bien installé le couple de clefs plublique/privée de Coker sur Pinpin, sinon la passerelle en face va nous snober. Enfin, il faut aussi partager toutes les clefs publiques identifiant les autres passerelles.

7.5 Verdict : coupable

Si tout s'est bien passé sur Pinpin et Coker, on peut voir ça en double : Bref, il n'y a plus qu'à couper le fil...

Conclusion

ipsecctl est l'outil qui manquait et qui aurait peut-être dû arriver plus tôt. Mon avis est que c'est une bonne nouvelle pour IPSec, qui avait bien besoin d'être dépoussiéré et remis au goût du jour, (lire " simplifié "). Maintenant, il faut espérer qu'ipsecctl prenne le même chemin que pf, ou, rêvons encore un peu plus, qu'OpenSSH soit porté sur d'autres plateformes. Avec sasyncd, c'est bien plus le travail d'horloger qui est ici intéressant. En fait, tout s'emboîte à merveille dans OpenBSD, de bgpd à ospdf, de pf à pfsync en passant par CARP. sasyncd n'est ici qu'une pièce supplémentaire au puzzle. Cependant, il a aussi l'inconvénient de complexifier quelque peu la configuration de la passerelle IPSec. Mais franchement, avouez que sasyncd, c'est quand même le genre de fonctionnalité qui vous fait regarder certains équipements réseau hors de prix comme des bouses infâmes... Références [1] http://www.schneier.com/paper-ipsec.html [2] http:www.undeadly.org/cgi?action=article&sid=20060621160000 [3] http:www.oreillynet.com/pub/a/sysadmin/2006/10/26/openbsd-40.html?page=1 [4] http://www.openbsd.org/faq/pf/fr/carp.html