VPN IPSec Sous Gnu-Linux
VPN IPSec Sous Gnu-Linux
VPN IPSec Sous Gnu-Linux
Sommaire
1. Fonctionnement................................................................................2
1.1. Mode de transport..........................................................................2
1.2. Les composantes d'IPSec................................................................3
1.3. L'change des cls.........................................................................4
1.4. Informations complmentaires : accs distances par les utilisateurs...5
1.4.1. Authentification IPSec de la phase 1...........................................5
1.4.2. Xauth.....................................................................................5
1.4.3. Hybrid auth.............................................................................5
1.4.4. Mode de configuration ISAKMP...................................................6
2. Implmentation Linux........................................................................6
2.1. IPSec-tools (KAME-tools)................................................................6
2.1.1. Installation..............................................................................6
2.1.2. Configuration de base...............................................................7
2.1.3. Configuration avec cls automatique par IKE et certificats pour
utilisateur itinrant (serveur et client Linux)...........................................17
2.1.4. Connexion et dconnexion au VPN............................................23
2.2. Problme de NAT, de fragmentation et de delai de connexion.............24
2.2.1. NAT......................................................................................24
2.2.2. Fragmentation.......................................................................25
2.2.3. Delai de connexion.................................................................25
2.3. Et iptables dans tout a.................................................................25
2.3.1. La passerelle IPSec machine 1.................................................25
2.3.2. La passerelle IPSec machine 2.................................................27
2.3.3. En plus sur les passerelles IPSec..............................................27
2.3.4. En plus sur le client................................................................27
1.Fonctionnement
1.1. Mode de transport
IPSec est un protocole dfini par l'IETF permettant de scuriser les changes au niveau de la
couche rseau. Il s'agit en fait d'un protocole apportant des amliorations au niveau de la
scurit au protocole IP afin de garantir la confidentialit, l'intgrit et l'authentification des
changes.
Il ne peut donc pas masquer les adresses pour faire croire un rseau
LAN virtuel entre les deux LAN relis
cela ne garantie donc pas non plus de ne pas utiliser des options Ips non
voulues
le
o les paquets descendent dans la pile jusqu' la couche IP et c'est la couche IP qui
passe ses donnes la couche IPSec. Il y a donc une entte IP encapsule dans
les donnes IPSec et une entte IP relle pour le transport sur Internet (on
pourrait imaginer que ce transport se fasse sur de l'IPX ou NetBIOS puisqu'il
n'y a pas de contrainte dans ce mode)
o il ne gre pas la confidentialit : les donnes sont signes mais pas cryptes
o en mode tunnel, c'est l'ensemble du datagramme IP encapsul dans ESP qui est
crypt et subit les vrifications suivantes. On peut donc se passer de AH.
Security Assocation (SA) dfinit l'change des cls et des paramtres de scurit. Il
existe une SA par sens de communication. Les paramtres de scurit sont les suivants
:
La SAD (Security Association Database) stocke les SA afin de savoir comment traiter
les paquets arrivant ou partant. Elles sont identifies par des triplets :
La SPD (Security Policy Database) est la base de configuration de IPSec. Elle permet
de dire au noyau quels paquets il doit traiter. C'est sa charge de savoir avec quel SA
il fait le traitement.
En
rsum, le SPD indique quels paquets il faut traiter et le SAD indique comment il faut traiter
un paquet slectionn.
o la seconde permet de mettre en place IPSec avec ses paramtres et une SA par
sens de communication. Les donnes changes sont protges par le canal mis
en place dans la phase 1.
La phase 1 d'IPSec fait parti du protocole IKE (IPSec Key Exchange) gr par le dmon
racoon. Son but est d'authentifier les machines en prsence (client et serveur) afin de dfinir
une cl matre pour scuris la phase 2 d'IPSec. Le but de la phase 2 est, quant elle, de
driver les cls utilises
les cls prpartags. Plus difficile maintenir mais rapide mettre en place. Moins
sr.
les certificats.Plus facile maintenir et moins rapide mettre en place. Plus sr.
1.4.2. Xauth
Xauth est une extension IKE qui se passe aprs la phase 1 et ajoute une authentification
login/mot de passe scuris par la phase 1 (mot de passe pas en clair).
L'authentification hybride est une autre extension IKE qui rend la phase 1 asymtrique.
Durant la phase 1, la passerelle VPN peut utiliser un certificat alors que l'utilisateur distant n'a
pas besoin de s'authentifier. Aprs la phase 1, on est donc dans la situation suivante :
la passerelle VPN ne sait pas rellement si elle parle au bon client ou un hacker
Aprs la phase 1, un change Xauth peut intervenir pour authentifier de faon sr l'utilisateur
distant. Ensuite la phase 2 peut commencer.
Le niveau de scurit de IPSec + Xauth + Hybrid est peu prs quivalent une
authentification par mot de passe en SSH.
2.Implmentation Linux
Il existe plusieurs implmentation de IPSec dans Linux suivant la version du noyau :
Pour utiliser IPSec en natif dans Linux, il faut avoir compiler son noyau avec les options ( y)
(le critre de recherche dans config-noyau est indiqu entre parenthses) :
Network support
o PF_KEY sockets (NET_KEY)
o AH transformation (INET_AH)
Cryptographic API, en vrac : HMAC, Null, MD5, SHA1, DES et Triple DES, AES
(CRYPTO_*)
Pour vrifier qu'une option critre est incluse dans le noyau ou dans un module de celui-ci :
./configure --with-kernel-headers=/lib/modules/2.6.X/build/include
make
make install
on cre un script pour dfinir les paramtres IPSec mettre dans la SAD (Security
Association Database) et dans la SPD (Security Policy Database) :
o SAD
o SPD
le sens du traffic
d'authentification est un nombre (dcimal ou hexa) dont la taille en bits dpend de l'algo de
hachage. algo_hash peut tre choisi parmi : hmac-md5, hmac-sha1, keyed-md5, keyed-
sha1, hmac-sha256, hmac-sha384, hmac-sha512, hmac-ripemd160, aes-xcbc-mac ou tcp-md5.
Suivant la valeur de ce dernier, la taille de la cl peut tre diffrente (md5 : 128bits, sha1 :
160bits...)
iii.Politique de scurit
(1)Paquets entrants
Une politique de scurit a la forme suivante pour les paquets entrants (applique sur la
machine 1) :
esp/mode/src-dst/require
ah/mode/src-dst/require;
(2)Paquets sortants
Une politique de scurit a la forme suivante pour les paquets sortants (applique sur la
machine 1) :
esp/mode/src-dst/require
ah/mode/src-dst/require;
A noter que sur la machine 2, il est prfrable de mettre une rgles dans laquelle
IP_pub_machine1 et IP_pub_machine2 sont inverss et o IN est mis la place de
OUT.
Note : vous pouvez remplacer les cls par des cls gnres par vous mme avec
Voici un exemple de fichier de configuration statique pour le mode tunnel entre une machine
1 et une machine 2 qui permettent de relier les rseaux 1 et 2 (les diffrences sont en rouge).
On remarquera que l'on utilise que ESP car en mode tunnel, ce protocole assure la fois
l'encryptage et l'authentification. Attention, seuls les paquets entre une machine du rseau 1 et
du rseau 2 seront encrypts. Par contre, si on envoit un ping de IP_pub_machine1
IP_pub_machine2, il sera en clair car aucunes des IP IP_pub_machine1 et IP_pub_machine2
ne font parties des IP des rseau 1 et 2.
Sur la machine 1 :
#!/usr/sbin/setkey -f
# ESP SAs doing encryption using 192 bit long keys (168 + 24 parity)
# and authentication using 128 bit long keys
add IP_pub_machine1IP_pub_machine2 esp 0x201 -m tunnel -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;
# Security policies
spdadd adresse_reseau1 adresse_reseau2 any -P out ipsec
esp/tunnel/IP_pub_machine1-IP_pub_machine2/require;
#il peut tre ncessaire pour kernel >= 2.6.10 et ipsec-tools < 0.5
#!/usr/sbin/setkey -f
# ESP SAs doing encryption using 192 bit long keys (168 + 24 parity)
# and authentication using 128 bit long keys
add IP_pub_machine1IP_pub_machine2 esp 0x201 -m tunnel -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;
# Security policies
spdadd adresse_reseau1 adresse_reseau2 any -P in ipsec
esp/tunnel/IP_pub_machine1-IP_pub_machine2/require;
#il peut tre ncessaire pour kernel >= 2.6.10 et ipsec-tools < 0.5
On peut vrifier que les paquets partent et reviennent bien encrypts sur une IP_interne1
avec tcpdump host IP_pub_machine2 sur la machine 2:
le ping : on voit bien que l'on envoie pas le paquet echo-request en clair. On
remarquera que l'adresse de destination n'est pas celle de la machine IP_interne1. En
effet, cette adresse se trouve dans le paquet IP crypt dans les donnes ESP. Il y a bien
un tunnel crypt entre IP_pub_machine2 et IP_pub_machine2
le pong : on voit un paquet crypt arriver et on voit bien un paquet ICMP echo-reply
remonter. On rappelle que le mode tunnel encapsule l'entte IP relle dans les donnes
de ESP, ESP tant lui-mme encapsul dans un paquet IP entre les deux bout du tunnel
ce qui fait que l'on croit recevoir deux paquets alors ce n'en est qu'un : on reoit les
donnes ESP cryptes qui sont dcryptes et repasses la couche IP :
Note : vous pouvez remplacer les cls par des cls gnres par vous mme avec
/dev/urandom par exemple.
Voici un exemple de fichier de configuration statique pour le mode transport entre une
machine 1 et une machine 2. Attention, le mode transport assure l'encryptage ESP et
l'authentification AH entre les machines 1 et 2 mais absolument pas entre les rseaux 1
et 2.
Sur la machine 1 :
#!/sbin/setkey -f
flush;
spdflush;
0xc0291ff014dccdd03874d9e8e4cdf3e6;
0x96358c90783bbfa3d7b196ceabe0536b;
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;
# Security policies
esp/transport//require
ah/transport//require;
esp/transport//require
ah/transport//require;
#!/usr/sbin/setkey -f
flush;
spdflush;
0xc0291ff014dccdd03874d9e8e4cdf3e6;
0x96358c90783bbfa3d7b196ceabe0536b;
0x201 -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;
# Security policies
esp/transport//require
ah/transport//require;
esp/transport//require
ah/transport//require;
On peut vrifier que les paquets partent et reviennent bien encrypts sur machine1 avec
tcpdump host machine2 :
le ping : on voit bien que l'on envoie pas le paquet echo-request en clair
le pong : on voit un paquet crypt arriver et on voit bien que ce n'est pas le paquet
ICMP echo-reply en clair :
Pour plus d'informations sur les configurations avec IPSec-tools, voir http://www.ipsec-
howto.org/x299.html.
Si le protocole IKE et son serveur racoon gnrent les cls la vole et les SA pour la SAD, il
ne gre pas les rgles de police de scurit mettre dans la SPD. Et cela est vident, comment
pourrait-t-il savoir ce que veut l'admin et entre quoi et quoi se fait l'encryptage.
i.Installation de ipsec-tools
Si vous souhaitez utilisez l'authentification hybride entre deux machines Linux (comme le
montre la configuration suivante), il vous sera ncessaire de disposer d'un noyau 2.6 et de
compiler les ipsec-tools dans une version suprieure 0.5.2 (version package dans
Debian Sarge, par exemple, mais qui ne contient pas ce type d'authentification hybride). Pour
cela, il vous sera ncessaire d'installer les paquets suivants :
[root]# cd ipsec-tools-*
--sysconfdir=/etc/racoon -localstatedir=/var \
--prefix=/usr
[root]# make
[root]# cd ipsec-tools-*
--prefix=/usr
[root]# make
Il peut tre ncessaire de gnrer une autorit de certification maison pour signer ses propres
certificats. Un certificat CA n'est rien de plus qu'un certificat autosign :
[root]# cd /dossier/de/stockage
Cette commande vous demande une passphrase pour protger la cl prive cre.
[root]# chmod 600 certs/*.key
[root]# openssl req -days 3650 -x509 -key certs/ca.key -new -out
certs/ca.crt
Cette dernire commande vous demandera des informations sur le certificat de l'autorit CA
cre et la passphrase pour dcrypter la cl prive de l'autorit.
Ensuite, on va conserver ces deux cls afin de signer tous les certificats que l'on va gnrer
par la suite.
Note : le Common Name est celui du fichier, par exemple CN = client_ipsec, certificat
client_ipsec.crt. De plus, Organization Name doit tre le mme pour le certificat CA et
pour les certificats des clients et du serveur.
Il faut gnrer un certificat pour toutes les machines qui vont communiquer (par exemple avec
une cl de 1024 bits) :
Il ne faut pas donner de passphrase car racoon ne sait pas les dcrypter.
Le certificat gnr se trouve alors dans le fichier fichier.crt et la cl prive dans fichier.key.
Chaque machine doit avoir sa propre cl prive, son certificat et la certificat de la CA dans
son rpertoire /etc/certs/ (root:root 660) . Il doit aussi avoir le certificat des htes distants
auxquels il se connecte.
le certificat de la CA : ca.crt
sa cl prive et son certificat : serv_ipsec.key (root:root 600) et serv_ipsec.crt
le certificat de la CA : ca.crt
sa cl prive et son certificat : client_ipsec.key (root:root 600) et client_ipsec.crt
v.Configuration de racoon
Le dmon racoon sert grer le protocole IPSec pour le mettre en place automatiquement par
IKE. Il peut se lancer par racoon -f /etc/racoon/racoon.conf ou
/etc/init.d/racoon start.
(1)Serveur
[root]# cp
/usr/share/doc/racoon/examples/samples/roadwarrior/server/phase1-down.sh
/etc/racoon/
exchange_mode aggressive;
#certificat du serveur et cl prive
certificate_type x509 "serv_ipsec.crt" "serv_ipsec.key";
#certificat de l'autorit de certification
ca_type x509 "ca.crt";
#indique d'utiliser le CN des certificats pour s'identifier
my_identifier asn1dn;
#obir la proposition de jeu de cryptage des clients
proposal_check obey;
#gnrer les rgles IPSec la connexion des clients
generate_policy on;
#permet de traverser une passerelle NAT entre le serveur et le
client
nat_traversal on;
#indique le dlai de rgnration des cls
dpd_delay 20;
#indique que l'on peut fragmenter les paquets IKE et autres
ike_frag on;
#indique un script pour nettoyer la connexion la dconnexion
script "/etc/racoon/phase1-down.sh" phase1_down;
#proposition de jeu de cryptage aux clients pour la phase 1
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method hybrid_rsa_server;
dh_group 2;
}
}
(2)Client
[root]# cp
/usr/share/doc/racoon/examples/samples/roadwarrior/server/*.sh /etc/racoon/
Si vous voulez ne pas avoir taper votre mot de passe Xauth chaque connexion, vous
pouvez le mettre dans le fichier des cls prpartages.
IP_serveur_VPN
(4)Notes
Note : les certificats qu'il soit au format PEM ou au format .key/.pub doivent absolument tre
dcrypt (et donc lisible uniquement par l'utilisateur sous lequel tourne racoon) car racoon n'a
Note pour Windows : les certificats pour Windows sont au format PKCS#12 :
vi.Dmarrage
pour se connecter
pour se dconnecter
Il vous sera alors ncessaire de donner votre mot de passe tel que dfinit dans /etc/passwd sur
le serveur VPN.
Si le client se trouve derrire une passerelle assurant le NAT tel que c'est souvent le cas
lorsque l'on a un rseau local et une passerelle pour accder au net, vous ne pourrez pas
utiliser IPSec directement. En effet, les paquets sont encapsul dans des paquets ESP (au
dessus de IP) qui par dfinition ne possde pas de port est sont donc trs difficile NATer.
Dans ce cas, on utilisera NATT afin d'encapsuler les paquets ESP dans des paquets UDP pour
passer les passerelles.
De plus, il peut arriver que l'change IKE ne se fasse pas si le port UDP du NAT change du
fait de la faible persistance des associations de NAT dans les passerelles. Il peut donc tre
utile de faire des envoie de paquets vide pour faire persister l'association NAT sur la
passerelle traverse.
timer {
2.2.2. Fragmentation
La fragmention intervient lorsque l'on utilise, par exemple, une liaision DSL qui suppose par
dfaut que les paquets UDP ne sont pas de grande taille. La fragmentation va donc arriver
plus frquemment dans un IPSec NAT.
la fragmentation des paquets IKE lors de l'tablissement des cls IPSec. On peut
choisir la fragmentation IKE qui est une extension de ce protocole
la fragmentation des paquets ESP lors des communications. Dans ce cas, il faut
simplement fragmenter les paquets IP encapsuler dans ESP pour faire des paquets
UDP/ESP de plus petite taille.
Il peut arriver que la connexion entre le client et le serveur ne soit pas trs fiable et donc que
des dconnexions arrivent. Pour cela, on peut forcer le serveur IKE renouveller les cls
rgulirement.
NOTE : la configuration suivante est valable uniquement pour le mode Tunnel. Le mode
transport un intrt limit dans le VPN.
Si l'on veut limiter le forward aux paquets crypts, il est ncessaire de marquer les paquets esp
et/ou ah entrants :
#ESP
#AH
IP_pub_machine2-j ACCEPT
Ensuite, il faut autoriser le traffic entre les deux rseaux internes (si les paquets sont crypts) :
#active le forwarding
Enfin, il faut indiquer la machine 1, la route vers le rseau interne 2. Note, si la machine 1
n'est pas la passerelle par dfaut du rseau 1, il faut indiquer une route vers la machine 1 sur la
passerelle par dfaut :
La configuration est la mme mais dans l'autre sens : on inverse adresse_rseau1 par
adresse_rseau2, etc...
Le client est considr avec la configuration prcdente mais sans les rgles de forward.