Compte-rendu de TP

grubbsvroomΛογισμικό & κατασκευή λογ/κού

2 Ιουλ 2012 (πριν από 5 χρόνια και 1 μήνα)

327 εμφανίσεις

Fabien Locussol
Stephane Jean-Baptiste
Adrien Machado
Bruno Orgues
Année 2003
INGÉNIEURS 2000
Filière Informatique et Réseaux
3
ème
année
IP Sec
Sécurisation des réseaux IP
Compte-rendu de TP
Professeur responsable : M. JJ Bernard
Année 2003
I.
Présentation et généralités d'IP Sec
Le protocole IP Sec, développé par l'IETF, a pour but de sécuriser TCP/IP par
l'authentification et le chiffrement des paquets IP afin de protéger les transmissions de données. Ses
principales implémentations se retrouvent dans les logiciels et les matériels créant des VPN. Ipv6,
prochaine version IP, inclue les mécanismes d'IP Sec.
Il existe deux types de transformations de données permettant l'implémentation d'IP Sec :

Authentification Header (AH). Celle-ci identifie et protège les datagrammes IP et assure
une protection évitant de ré-envoyer une trame avec un numéro déjà utilisé. Une valeur
est calculée en fonction de la trame, et est ajoutée à celle-ci. A l'arrivée, on vérifie cette
valeur.

Encapsulating Security Payload (ESP). Cette transformation assure la confidentialité,
l'authentification et l'intégrité des données IP en les chiffrant selon les Security
Association (SA). Les transformations ESP chiffrent des parties de trames, et
éventuellement les encapsule dans d'autres trames.
Voici quelques termes utilisés lors de ce TP ainsi que leur explication :
Les Security Association (SA) :
Une SA définit les algorithmes utilisés pour transformer les données avec IP Sec. La
gestion des clefs pour IPsec n'est liée aux autres mécanismes de sécurité de IPsec que par le
biais des SA. Chaque association est identifiée de manière unique à l'aide de :

L'adresse de destination des paquets.


L'identifiant d'un protocole de sécurité (AH ou ESP).


Un index des paramètres de sécurité (SPI).
ISAKMP (Internet Security Association and Key Management Protocol) :
ISAKMP permet l'utilisation de plusieurs protocoles d'échange de clef et peut être
utilisé pour d'autres mécanismes de sécurité que ceux de IPsec. Dans le cadre de IPsec,
ISAKMP est associé à d’autres protocoles pour donner un protocole final du nom d'IKE
(voir ci-dessous).
IKE (Internet Key Exchange) :
IPsec fait appel à IKE pour établir une nouvelle SA. Ce protocole peut également
envoyer des alertes administratives en cas de tentative de connexion infructueuse.
II.
Objectifs du TP.
Le TP que nous avons effectué à pour but de sécuriser une liaison entre deux réseaux
locaux, en passant par un réseau non sécurisé. Le moyen utilisé était du créer un tunnel VPN
en utilisant IP Sec. Voici le schéma de fonctionnement :
Eth1
10.1.204.1
192.168.220.0/24
Eth0
192.168.220.207
Lan Emulé
10.1.204.0
Lan Emulé
10.1.207.0
Eth1
10.1.204.1
Tunnel IP Sec
Eth0
192.168.220.204
Chaque PC dispose de deux cartes réseau. La première (eth0) est connectée au réseau dit
"non-sécurisé" et possède une adresse du type 192.168.220.X. La seconde carte réseau est
considérée comme connectée à un réseau local (LAN émulé) qui sera relié à terme au réseau local
de l'autre PC. Cette carte a pour adresse 10.0.Y.1. Comme le montre le schéma, nous allons créer un
tunnel permettant de connecter les deux réseaux 10.0.Y.0.
Le logiciel nous permettant de faire de l'IP Sec lors de notre TP s'appelle Freeswan (Free
Secure Wan).
III.
Configuration
Voici à présent la configuration à effectuer sur chacune des machines.
Tout d'abord, il faut configurer les deux interfaces réseau :
pc07-59:~# ifconfig eth1 10.1.207.1 netmask 255.255.255.0
pc07-59:~# ifconfig eth0 192.168.220.207 netmask 255.255.255.0
Ensuite, afin d'éviter que le passage entre les deux cartes utilise des fonctions de filtrage et
pour que le forwarding fonctionne, nous allons modifier certains paramètres du noyau :
pc07-59:/proc/sys/net/ipv4# echo 1 > ip_forward
pc07-59:/proc/sys/net/ipv4# echo 0 > conf/eth0/rp_filter
pc07-59:/proc/sys/net/ipv4# echo 0 > conf/eth1/rp_filter
pc07-59:/proc/sys/net/ipv4# echo 0 > conf/ipsec0/rp_filter
Mise en place du forwarding.
Suppression des fonctions de filtrage
(cohérences dans le routage) pour
chaque interface.
Entrons maintenant dans la partie propre à IP Sec. Les deux fichiers de configuration d'IP
Sec sont /etc/ipsec.conf et /etc/ipsec.secrets. Le dernier fichier contient une clé qui permettra de
communiquer avec la machine distante. Ce fichier ne doit être lu que par les personnes habilitées
car il contient des informations sensibles. Voici la ligne que nous y mettons (la même clé pour les
deux machines).
: PSK 0x1234ebad
Le contenu du fichier /etc/ipsec.conf va permettre à IP Sec de choisir ses paramètres de
fonctionnement. Le fonctionnement du tunneling étudié est le suivant. Chaque machine du VPN
doit avoir une partie gauche et une partie droite. Pour la machine 207, la partie gauche sera elle-
même et donc le réseau LAN émulé 10.1.207.0. Sa partie droite est donc la machine distante, soit le
réseau 10.1.204.0, accessible depuis 192.168.220.204.
conn vpntp
left=192.168.220.207
leftsubnet=10.1.207.0/24
right=192.168.220.204
rightsubnet=10.1.204.0/24
auto=start
Nom de la connexion.
Machine de la partie gauche.
Machine de la partie droite.
Il est important que les deux machines de chaque côté du VPN aient la même configuration.
La copie du fichier de configuration suffirait car les deux ont le même côté droit et le même côté
gauche.
Nous vérifions que le tunnel fonctionne avec la commande traceroute.L’option -i désigne
l’interface à partir de laquelle il faut lancer la recherche :
pc07-59:~# traceroute -ieth1 10.1.204.1
traceroute to 10.1.204.1 (10.1.204.1), 30 hops max, 38 byte packets
1 10.1.204.1 (10.1.204.1) 1.280 ms 0.591 ms 0.492 ms
IV.
Analyse
Lors du lancement des démons ipsec (/etc/ipsec start) de chaque côté, des échanges de
trames ont lieu entre les deux machines pour se transmettre des clés de cryptage.
Tout d’abord, la première trame est une proposition de cryptage. La machine propose 4
types de cryptages. Dans cette capture (ethereal), on peut voir les propositions faites :
On peut voir ici les différentes propositions de la première machine. Les paramètres qui
changent selon les propositions sont le type de chiffrement (RSA, PSK), le group-value, qui
correspond à la valeur du groupe pour l’algorithme de Diffie Hellman (seuls les groupes 2 et 5 sont
implémentés) et le type d’authentification.
Ensuite, la machine distante renvoie sa réponse, généralement avec le cryptage le plus fort
pour les deux machines.
On s'aperçoit ici que la machine a choisi l'algorithme triple DES avec une méthode
d'authentification PSK.
Ensuite, on échange les clés de chiffrement :
Cette phase génère une association de sécurité IKE. Lorsque les clés sont échangées, toutes
les informations sont cryptées. La phase suivante correspond à l’échange de clés pour IP Sec
(Association de sécurité IP Sec). Cependant, on sait que les premières trames constituent des
échanges d’informations d’IP Sec. Ensuite, les données circulent de façon cryptée :
Si l’on veut obtenir des informations sur la connexion en cours du tunnel, il faut utiliser la
commande ipsec auto –status. On peut avoir différents renseignements :
000
000 "vpntp":
10.1.207.0/24===192.168.220.207...192.168.220.204===10.1.204.0/2
4
000 "vpntp": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 3
000 "vpntp": policy:
PSK+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK;
interface: eth0; erouted
000 "vpntp": newest ISAKMP SA: #13; newest IPsec SA: #14; eroute
owner: #14
000 "vpntp": ESP algorithms wanted: 11/000-1/000, 11/000-2/000,
000 "vpntp": ESP algorithms loaded: 11/000-1/128, 11/000-2/160,
Le chemin pris par le tunnel.
Les durées de vie de chaque
clé.
Les numéros de version de
chaque clé.
Les paramètres de l’ESP.
128 et 160 désignent des
longueurs de clés.
000 #12: "vpntp" STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 28234s
000 #12: "vpntp" esp.a09452b3@192.168.220.204
esp.c6c78f50@192.168.220.207 tun.100a@192.168.220.204
tun.1009@192.168.220.207
000 #11: "vpntp" STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 3034s
Temps qu’il reste avant le
changement de la clé.
A09452b3 correspond au
SPI (pour l’esp) sur la
machine 204.

Lorsque la connexion entre les machines se termine, des trames du type ISAKMP sont
échangées afin de mettre fin et de prévenir l’autre machine. Si la déconnexion s’effectue sans que la
machine n’ait été en mesure d’envoyer un message d’alerte, la machine distante garde les clés de
chiffrement jusqu’à la mort de ces dernières.
Nous avons essayé cette manipulation en déconnectant une des machines physiquement.
Nous avons ensuite arrêté le démon puis l’avons relancé après une minute, câble reconnecté. Voici
une partie du contenu de la commande ipsec auto –status de l’autre machine :
000
000 #12: "vpntp" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28234s
000 #12: "vpntp" esp.a09452b3@192.168.220.204 esp.c6c78f50@192.168.220.207
tun.100a@192.168.220.204 tun.1009@192.168.220.207
000 #11: "vpntp" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE
in 3034s
000 #14: "vpntp" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28381s;
newest IPSEC; eroute owner
000 #14: "vpntp" esp.7cbec741@192.168.220.204 esp.c6c78f51@192.168.220.207
tun.100c@192.168.220.204 tun.100b@192.168.220.207
000 #13: "vpntp" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE
in 3181s; newest ISAKMP
000 #5: "vpntp" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 26272s
000 #5: "vpntp" esp.16632609@192.168.220.204 esp.c6c78f4c@192.168.220.207
tun.1002@192.168.220.204 tun.1001@192.168.220.207
000 #4: "vpntp" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE
in 1072s
000 #7: "vpntp" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 27814s
000 #7: "vpntp" esp.49f3a8c7@192.168.220.204 esp.c6c78f4d@192.168.220.207
tun.1004@192.168.220.204 tun.1003@192.168.220.207
000 #6: "vpntp" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE
in 2614s
000 #10: "vpntp" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28223s
000 #10: "vpntp" esp.f07c34b2@192.168.220.204 esp.c6c78f4f@192.168.220.207
tun.1008@192.168.220.204 tun.1007@192.168.220.207
000 #9: "vpntp" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 27969s
000 #9: "vpntp" esp.f07c34b1@192.168.220.204 esp.c6c78f4e@192.168.220.207
tun.1006@192.168.220.204 tun.1005@192.168.220.207
000 #8: "vpntp" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE
in 2769s
On constate sur cette capture, que la machine a gardé l’ensemble des clés convenues lors de
la première communication. Chaque valeur (#11, #9, …) correspond à une clé différente. Elles ne
seront plus utilisées, mais sont valables jusqu’à leur renouvellement, qui sera impossible car la
session n’existe plus.
V.
Bonus
Puisque nous avons pu terminer le TP assez tôt, nous avons pu essayer de modifier les
durées de vie des différentes clés, afin qu’elles soient renouvelées plus souvent et donc que cela
procure une plus grande sécurité.
Nous avons donc modifié le fichier /etc/ipsec.conf en ajoutant ces lignes dans les paramètres
de la connexion :
ikelifetime=30s
keylife=60s// durées de vie
auth=ah // Auth en utilisant AH
rekeymargin=5s
Durées de vie des différentes clés.
Utilisation du protocole AH pour l’authentification.
Voici à présent le contenu de la commande ipsec auto –status lancée à quelques dizaines de
secondes de différence.
000 interface ipsec0/eth0 192.168.220.207
000
000 algorithm ESP encrypt: id=3, name=ESP_3DES
000 algorithm ESP encrypt: id=11, name=ESP_NULL
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD
000
000 "vpntp": 10.1.207.0/24===192.168.220.207...192.168.220.204===10.1.204.0/24
000 "vpntp": ike_life: 30s; ipsec_life: 60s; rekey_margin: 5s; rekey_fuzz: 100%; keyingtries: 3
000 "vpntp": policy:
PSK+ENCRYPT+AUTHENTICATE+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: eth0;
erouted
000 "vpntp": newest ISAKMP SA: #25; newest IPsec SA: #23; eroute owner: #23
000 "vpntp": ESP algorithms wanted: 3/000-1/000, 3/000-2/000,
000 "vpntp": ESP algorithms loaded: 3/168-1/128, 3/168-2/160,
000
000 #25: "vpntp" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 5s;
newest ISAKMP
000 #23: "vpntp" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in
0s; newest IPSEC; eroute owner
000 #23: "vpntp" ah.6ead112e@192.168.220.204 ah.acb7cdbf@192.168.220.207
esp.6ead112f@192.168.220.204 esp.acb7cdc0@192.168.220.207 tun.1010@192.168.220.204
tun.100f@192.168.220.207
Observons sur les captures ci-dessus et ci-dessous, les lignes commençant par "#xx".
000 interface ipsec0/eth0 192.168.220.207
000
000 algorithm ESP encrypt: id=3, name=ESP_3DES
000 algorithm ESP encrypt: id=11, name=ESP_NULL
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD
000
000 "vpntp": 10.1.207.0/24===192.168.220.207...192.168.220.204===10.1.204.0/24
000 "vpntp": ike_life: 30s; ipsec_life: 60s; rekey_margin: 5s; rekey_fuzz: 100%; keyingtries: 3
000 "vpntp": policy:
PSK+ENCRYPT+AUTHENTICATE+TUNNEL+PFS+DISABLEARRIVALCHECK; interface: eth0;
erouted
000 "vpntp": newest ISAKMP SA: #42; newest IPsec SA: #43; eroute owner: #43
000 "vpntp": ESP algorithms wanted: 3/000-1/000, 3/000-2/000,
000 "vpntp": ESP algorithms loaded: 3/168-1/128, 3/168-2/160,
000
000 #43: "vpntp" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in
51s; newest IPSEC; eroute owner
000 #43: "vpntp" ah.6ead113a@192.168.220.204 ah.acb7cdcb@192.168.220.207
esp.6ead113b@192.168.220.204 esp.acb7cdcc@192.168.220.207 tun.101c@192.168.220.204
tun.101b@192.168.220.207
000 #42: "vpntp" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 15s;
newest ISAKMP
000 #41: "vpntp" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_EXPIRE in 2s
000 #39: "vpntp" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 5s
000 #39: "vpntp" ah.6ead1138@192.168.220.204 ah.acb7cdc9@192.168.220.207
esp.6ead1139@192.168.220.204 esp.acb7cdca@192.168.220.207 tun.101a@192.168.220.204
tun.1019@192.168.220.207
On peut remarquer qu'à quelque temps d'écart, les numéros de clés ont changé. Les temps
d'expiration sont très courts (15 s, 2 s ou 5 s), ce qui correspond à l'échelle de temps donnée dans le
fichier ipsec.conf.
Cette capture (ethereal) met en valeur les renouvellements de clés. En effet, il suffit
d'observer les écarts de temps entre chaque groupe de trames ISAKMP pour voir les
renouvellements..