IPsec et VPN

IPsec est un protocole de s´ecurit´e inclus dans la couche IP elle-mˆeme. Il est d´efini dans la RFC 2401. Ce paragraphe aborde bri`evement la question du point de vue du protocole et de sa place dans la pile Arpa, tout en lais-sant volontairement dans un certain flou les aspects li´es `a la cryptographie, clairement absents des objectifs de ce cours¹⁰.

IPsec dans quel but ?

IPsec est un point de passage oblig´e pour tout administrateur de r´eseau qui souhaite mettre en place une politique de s´ecurit´e. D’ailleurs, pour faire le lien avec le paragraphe qui pr´ec`ede, pr´ecisons qu’IPsec encapsul´e dans IP (formellement, un tunnel) porte un nom, le VPN (“ Virtual Private Net-work ”) ! Nous avons examin´e comment un tunnel accroˆıt l’´etendue d’un r´eseau au travers d’autres r´eseaux. Ajouter Ipsec introduit, entre autres, une dimension de s´ecurit´e tr`es utilis´ee pour relier des machines - ou des r´eseaux - physiquement localis´es n’importe o`u il y a un acc`es IP, en r´eseaux virtuels s´ecuris´es ! C’est pour cette raison qu’Ipsec est un artefact incontournable de la panoplie s´ecuritaire sur les r´eseaux.

Nous aurions pu conclure le chapitre sur IP page 43 par cette constatation que le protocole IP est lisible par tout le monde y compris par les indiscrˆets et que quasiment n’importe quel “ bricoleur ” peut forger de faux datagrammes (“ fake datagram ”) pour empoisonner un r´eseau, voire d´etourner les services d’une machine. Ainsi, tout ce qui renforce la s´ecurit´e IP est une bonne chose, surtout `a l’heure des r´eseaux “ wifi ” dont les limites de port´ee ne sont pas maˆıtrisables.

IPsec renforce la s´ecurit´e d’IP sur plusieurs points :

Confidentialit´e Les donn´ees d’IP (protocole de transport et donn´ees ap-plicatives) sont crypt´ees, donc normalement non inspectables avec tout outil d’analyse de r´eseau.

Authentification La source du datagramme ne peut ˆetre qu’un seul

´emetteur, et non un interm´ediaire non pr´evu.

Int´egrit´e La totalit´e des donn´ees est prot´eg´ee par une somme de contrˆole (checksum), travail normalement d´evolu `a la couche de transport mais qui au niveau d’IP permet d’´ecarter tout datagramme qui aurait ´et´e modifi´e pendant son transport.

Dispositif “ anti-rejeux ” pour ´eviter les attaques du type “ man-in-the-middle ” consistants `a capturer un ou plusieurs datagrammes (crypt´es) dans le but de les envoyer `a nouveau pour b´en´eficier du mˆeme effet produit que l’envoi initial.

10Les RFCs donn´ees page 195 sont le bon point de d´epart pour se documenter sur les aspects cryptographiques d’IPsec

IPsec et VPN 181

IPsec en r´esum´e

Ipsec (RFC 2401) est un assemblage de quatre protocoles :

ESP (“ Encapsulating Security Payload ”) est d´efini par la RFC 2406. Il assure laconfidentialit´epar l’usage d’algorithmes de cryptage comme

“ DES ” (RFC 2405) , “ 3DES ” (RFC 2451), “ CAST-128 ” (RFC 2144) ou encore “ blowfish ” (RFC 2451), la liste n’est pas exhaustive. . . Il faut juste noter qu’il s’agit d’algorithmes bas´es sur l’existence un secret partag´e (manuellement dans un fichier ou cr´ee dynamiquement avec IKE, voir plus bas) entre les parties qui ´echangent des messages, et non sur l’´echange d’une clef publique. Cette remarque a un impact sur la mani`ere avec laquelle on doit les configurer !

AH (“ Authentication Header ”) est d´efini par la RFC 2402. Il assure l’authentification, c’est `a dire qu’il cherche `a certifier que les deux couches IP qui dialoguent sont bien celles qu’elles pr´etendent ˆetre, puis l’int´egrit´e des donn´ees par le calcul d’un checksum. Il faut noter que ce dernier travail empi`ete largement sur les attributions de la couche de transport mais se justifie compte-tenu des exigences inh´erentes au fonctionnement d’IPsec.

IPcomp (“ IP payload compression ”) sert `a compresser les donn´ees avant de les crypter. Son action est rendue n´ecessaire pour tenter de compenser la perte de la place occup´ee par les en-tˆetes ajout´es. Bien entendu IPcomp peut ˆetre utilis´e seul.

IKE (“ Internet Key Exchange ”) est d´efini par la RFC 2409. Ce protocole n’est pas formellement indispensable au bon fonctionnement d’IPsec mais lui apporte un m´ecanisme d’´echange de clefs, au d´emarrage des

´echanges et au cours du temps. Ainsi la clef de chiffrement n’est plus d´efinie de mani`ere statique dans un fichier mais change continuellement au cours du temps, ce qui est meilleur du point de vue de la s´ecurit´e.

Du point de vue de l’administration syst`eme et r´eseau, la mise en place de ce protocole passe par l’usage d’un daemon¹¹, par exemple racoon, et par une ouverture de port UDP (isakmp/500) suppl´ementaire dans le filtrage du r´eseau. Une n´egociation d´ecrite dans la RFC 2409 se d´eroule entre les hˆotes qui doivent dialoguer, ce qui entraine une certaine la-tence au d´ebut des ´echanges.

Les 32 bits de l’adresse IP de destination¹² permettent th´eoriquement d’exprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de figures sont tous th´eoriquement possibles, les impl´ementations d’IPsec ne supportent que l’unicast. La cons´equence est importante sur le d´eploiement d’IPsec, il est effectu´e “ point `a point ” plutˆot que g´en´eralis´e pour tout un r´eseau.

11Voir page 250 pour le fonctionnement desdaemons

12R´evision possible page 33

Ce travail est inclus dans ce qui est nomm´e “ politique de s´ecurit´e ” dans la RFC 2401.

Pour AH comme pour ESP, l’ajout de donn´ees vient se placer entre l’en-tˆete IP et les donn´ees.

Les deux protocoles peuvent ˆetre uti-lis´es ensembles ou s´eparement, c’est un choix qui rel`eve de la politique de s´ecurit´e. Pour en tenir compte, la n´egociation qui a lieu lors de l’´etablissement d’IPsec repose sur ce que la RFC appelle des SA (“ Secu-rity Association ”).

Une SA est formellement un tri-plet unique constitu´e d’un index unique , le SPI

figure X.04 : En-tˆetes d’IP-sec

(“ Security Parameter Index ”) sorte de num´ero d’identification IP suppl´ementaire¹³ inclus dans l’en-tˆete AH ou ESP, de l’adresse IP du des-tinataire et du protocole ESP ou d’AH. Si les deux protocoles doivent ˆetre utilis´es, il faut n´egocier deux SAs.

Comment utiliser IPsec ?

Aux deux protocoles AH et ESP, s’ajoutent deux mani`eres d’utiliser IP-sec, soit directement d’une machine `a une autre, on parle alors de “ mode transport ” soit encore en l’encapsulant dans un tunnel comme vu au para-graphe 2 page 176 et on parle de “ mode tunnel ”, plus connu sous le vocable

“ VPN ”.

La RFC 2401 indique que toute impl´ementation se r´eclamant d’IPsec doit supporter les 4 associations qui suivent.

La s´ecurit´e entre deux hˆotes qui supporte IPsec, au travers l’Internet, en mode transport ou en mode tun-nel. Les datagrammes peuvent avoir les structures suivantes :

figure X.05 : Association 1

Internet

IPsec et VPN 183 Remarque : En mode tunnel pour ce premier cas il n’y a pas d’obligation

du support d’AH et ESP simultan´ement. Quand ils sont appliqu´es tous les deux, il faut d’abord appliquer ESP, puis AH aux datagrammes.

figure X.06 : Association 2

AH et/ou ESP

Le mode tunnel est le seul requis ici. Nous avons donc une struc-ture de datagramme qui a ces formes possibles :

Mode tunnel

[IP2][AH][IP1][Transport][Data]

[IP2][ESP][IP1][Transport][Data]

C’est la combinaison des deux premiers cas, on ajoute la s´ecurit´e entre les hˆotes terminaux `a celle d´ej`a apport´ee par les routeurs.

La propagation du trafic de type ISAKMP (protocole IKE) au travers les routeurs est un plus.

figure X.07 : Association 3

Internet G=passerelle

*=Supporte IPsec AH et/ou ESP H=hote

figure X.08 : Association 4

dialup/ppp

Ce dernier cas est celui d’un poste isol´e qui se raccorde par exemple `a l’intranet de son entreprise via un modem ou un acc`es IP non sˆur, et qui utilise un proto-cole non crypt´e comme AppleTalk, ou PoP, par exemple.

Le mode tunnel est seul requis entre l’hˆote H1 et la passerelle G1. Ensuite, entre H1 et H2 on revient au premier cas.

Impl´ementation d’IPsec

L’impl´ementation d’IPsec sur les machines FreeBSD et NetBSd est issue du projet KAME¹⁴ et est ainsi fortement li´e au d´eveloppement de la pile IPv6.

Les protocoles AH, ESP et IPcomp sont inclus dans le noyau directement.

La gestion des clefs s’effectue via une commande externe, setkey qui pilote une table de gestion des clefs situ´ee elle aussi dans le noyau, grˆace `a des socket de typePF KEY

Les clefs sont soit plac´ees de mani`ere semi-d´efinitive dans le fichier de configuration d’ipsec lui-mˆeme (par exemple /etc/ipsec.conf soit confi´ee aux bons soins d’un programme externe qui se charge de les cr´ee et de les propager `a l’aide du protocole IKE. Quelques daemonssavent faire cela, no-tammentracoon du projet KAME.

Si nous reconsid´erons la figure X.03 les machines A et B jouent le rˆole des passerelles G1 et G2 de la figure X.06 (association 2). Les fichiers de configuration IPsec pourraient ˆetre :

Sur la machine A

spdadd IP(A) IP(B) any -P out ipsec esp/tunnel/192.168.249.1-192.168.249.2/require;

spdadd IP(B) IP(A) any -P in ipsec esp/tunnel/192.168.249.2-192.168.249.1/require;

spdadd est une instruction de la commande setkey. Il faut d´efinir sa politique de s´ecurit´e, c’est `a dire ce que l’on souhaite en entr´ee (in), en sortie (out) puis un choix de protocole (esp, ah, ipcomp), un mode (tunnel ici) avec l’entr´ee et la sortie du tunnel, enfin un niveau d’usage (requireici indique que tous ´echanges doivent utiliser IPsec).

Sur la machine B

spdadd IP(B) IP(A) any -P out ipsec esp/tunnel/192.168.249.2-192.168.249.1/require;

spdadd IP(A) IP(B) any -P in ipsec esp/tunnel/192.168.249.1-192.168.249.2/require;

La clef de cryptage ne figure pas dans ce fichier car l’exemple utilise IKE pour cela, `a l’aide de l’outil racoon.

Enfin, un excellent document de configuration se trouve sur le site du projet NetBSD :

http ://www.netbsd.org/Documentation/network/ipsec/

14http ://www.kame.net/