Description :
La suite de cet article décrit un exemple pour sécuriser un lien (par exemple une connexion wifi ou une connection a votre Lan depuis Internet).
La connexion à notre point d'accès se fait au travers de pptp. pptp n'étant pas une panacée d'un point de vue sécurité, on rajoutera une couche d'IPsec (authentification ET chiffrement).
Les parametres de sécurités seront négocier entre notre serveur et les clients par le protocole IKE (v1) à travers Racoon, un daemon implémentant ce protocole.
L'authentification entre le client et le serveur se fera à 2 niveaux :
- IKE : via des certificats X509 qui authentifiera les deux machines.
- pptp/pppd : qui identifiera le client aupres du serveur et qui lui fournira une adresse IP (pré déterminée ou non)
1. Mise en place de PPTP
1.1 Configuration du serveur
- Principe de fonctionnement de pptpd
pptp est un protocole permettant de créer un lien point a point à travers un réseau IP.
- Installation du serveur pptpd
root # apt-get install pptpd ppp |
Simple non ?
/etc/pptpd.conf :
# Changes are effective when pptpd is restarted ppp /usr/sbin/pppd option /etc/ppp/pptpd-options localip 192.168.10.254 remoteip 192.168.10.1-16 |
/etc/pptpd.conf est le fichier principal de configuration du serveur. Pour nous il ne va contenir que les informations pour l'attribution dynamique d'adresses IP des clients et le nom du fichier des options à passer à pppd lors de l'établissement d'une connexion.
192.168.10.254 correspond à l'adresse locale du serveur pour la liaison point à point.
192.168.10.1-16 correspond au range d'adresses IP dans lequel pptpd tapera pour attribuer une adresse à un client.
/etc/ppp/pptp-options :
lock name server require-chap debug defaultroute ms-dns 192.168.1.254 |
Ce fichier est utilisé par pptpd lors d'une connexion entrante. Il contient les options fournies à pppd pour monter la liaison point à point. Dans notre cas il définit, le nom du server, la méthode d'authentification (require-chap), s'il indique au client de rajouter une route par défaut (defaultroute) ainsi qu'un dns (ms-dns 192.168.1.254).
L'option debug rend pppd très verbeux dans /var/log/syslog. Un petit
lors des tests est très utiles.
/etc/ppp/chap-secrets :
# Secrets for authentication using CHAP # local remote secret IP addresses client server "test" * client2 server "abracadra" 192.168.10.17 server client "test" - |
/etc/ppp/chap-secrets contient les information nécessaires pour l'authentification des clients ainsi que pour l'attribution d'une adresse IP.
Chaque ligne définit, pour un utilisateur donné (1er champ), le password (ou secret) ainsi que l'adresse IP à lui fournir (dernier champ). Si le dernier champ est *, alors pptpd fournira une adresse de son pool, si une adresse est spécifiée, alors pppd lui fournira cette adresse.
Remarque :
Si le fichier /etc/ppp/options est présent et non vide, il sera utiliser à la place de notre fichier de configuration /etc/ppp/pptp-options. Si vous avez une connexion ADSL (par exemple) utilisant ce fichier, reporter les options présentes de
/etc/ppp/options dans le fichier /etc/ppp/peers/votre_conf_de_connexion_adsl.
- pptpd.conf (5) manuel pour le fichier de configuration de pptpd.
- pptpd(5) manuel pour pptpd.
1.2 Configuration du client
- Installation des outils nécessaires :
Il nous faut un client pptp et pppd pour dialoguer avec notre serveur.
root # apt-get install pptp-linux ppp |
/etc/ppp/chap-secrets :
# Secrets for authentication using CHAP # local remote secret IP addresses client server "test" - |
/etc/ppp/chap-secrets contient les informations de login pour la connexion point a point avec pppd.
/etc/ppp/peers/pptp :
pty "pptp 192.168.1.254 --nolaunchpppd" hide-password noauth debug user "client" name "client" ipparam pptp usepeerdns defaultroute persist |
/etc/ppp/peers/pptp est le fichier contenant les options nécessaires à pppd pour monter sa connexion. La premiere ligne permet en réalité de lancer une connexion pptp avec notre serveur (192.168.1.254, on peut remplacer par un nom de machine).
Le reste des options sont des options classiques pour pppd (utilisation des dns fournis (usepeerdns), création d'une route par défaut (defaultroute), persistance de la connexion (persist), non-authentication du serveur (noauth), le nom de login (user).
Remarque :
Le serveur n'aura pas besoin de s'authentifier pour la connexion point a point car l'authentification que l'on utilisera dans la solution totale sera beaucoup plus forte (via IPsec et les certificats x509).
1.3 Test
1.3.1 Lancement du serveur
root # /etc/init.d/pptpd start |
1.3.2 Le client
root # ifconfig %<--- Skip eth0 and lo --- ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.10.2 P-t-P:192.168.10.254 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:68 (68.0 b) TX bytes:102 (102.0 b) |
Vérifier vos routes, vos dns et normalement ca devrait le faire. Essayer de pinguer quelques machines et vérifier avec ethereal que le
trafic passe bien encapsuler.
2. Mise en place d'IPsec
Bon une fois que l'on a une connectivité avec notre LAN et/ou internet, il faudrai un peu sécurisé la chose vue que l'on n'a rien utilisé pour chiffré pptp à part le CHAP pour ppp.
La solution que je vous propose est d'utiliser les fonctionnalités d'authentification et de chiffrement d'IPsec. C'est à dire en utilisant la crypto forte.
Pour l'authentification, je ne suis pas trop fan des pre-shared-key, mot de passe... Je propose donc d'utiliser les certificats x509. La sécurité de cette technique reposera sur votre habileté à :
- gérer correctement votre autorité de certification. Si quelqu'un peut l'utiliser à votre place, seul le CHAP protégera quelqu'un de se connecter à votre serveur (perso, la clé privée de ma CA est protéger par un mot de passe et stockée sur ma clé USB que je porte 99% du temps sur moi (certaine activité demande, quelques fois, de ne rien porter , même pas une clé USB autour de votre cou)
- gérer correctement votre ordinateur pour que personne ne récupère la clé de votre certificats. Mais de toute manière tout le monde sais protéger correctement son PC . Et merde...
2.1 Configuration de Racoon
2.1.1 Création des certificats
Création de l'autorité de certification
Une autorité de certification (CA) est l'un des éléments clés pour déterminer l'authenticité d'un certificat. Si l'on a confiance en cette CA, et qu'un certificat à été signer par cette CA, alors vous pouvez avoir confiance en ce certificat (pour faire simple).
Génération des clé RSA :
root # openssl genrsa -des3 -out cakey.pem 2048 Generating RSA private key, 2048 bit long modulus .......+++ ...............................................................................................................+++ e is 65537 (0x10001) Enter pass phrase for cakey.pem Verifying - Enter pass phrase for cakey.pem:
|
Génération du certificat de notre CA :
openssl req -new -x509 -days 3650 -key cakey.pem -out cacert.pem Enter pass phrase for cacert.pem: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:FR State or Province Name (full name) [Berkshire]:régionX Locality Name (eg, city) [Newbury]:VilleX Organization Name (eg, company) [My Company Ltd]:CompanyX Organizational Unit Name (eg, section) []:Security/PKI Common Name (eg, your name or your server's hostname) []:ca.XXX.org <skip ...>
|
Création des certificats
Ceci décrit le processus pour créer une clé et un certificat pour un hôte (client ou serveur) et signé par notre CA.
Génération d'une clé de taille 1024 :
root # genrsa -out xxxxx.org.key 1024 |
Génération d'un certificat demandant à être signer plus tard :
openssl req -new -key xxxxx.org.key -out xxxxx.org.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:. Organization Name (eg, company) [Internet Widgits Pty Ltd]:CompanyX Organizational Unit Name (eg, section) []:Security/PKI Common Name (eg, YOUR name) []:ca.XXX.org Email Address []:. Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: |
Pour les champs vides mettez .
Le point important est à "Common Name (eg, YOUR name)", mettez le nom de
votre machine. Pour les deux derniers champs ne rien mettre.
Signature par notre CA pour une durée de 1 an :
root # openssl x509 -req -days 365 -in xxxxx.org.csr -CA ./cacert.pem -CAkey cakey.pem -CAcreateserial -out xxxxx.org.crt |
openssl vous demandra le password de votre CA.
2.1.2 Installation et Configuration de racoon
Racoon est un daemon implémentant le protocol IKE qui est chargé de négocier les paramètres de sécurité avec notre serveur pour IPsec.
Ces paramètres pourraient être configurés manuellement.
root # apt-get install racoon ipsec-tools |
A la question réponder direct.
Racoon se configure au travers du fichier /etc/racoon/racoon.conf
/etc/racoon/racoon.conf :
# pour générer beaucoup beaucoup de log log debug2; # Fichier pour les pre-shared-key, inutile pour nous path pre_shared_key "/etc/racoon/psk.txt"; # path pour le répertoire contenant nos certificats path certificate "/usr/local/openssl/certs"; # Définition de la conf pour IKE, phase 1 # Pour un hôte anonyme (ici on pourrait spécifier un hôte distant par son # adresse. remote anonymous { # Mode possible à utiliser pour IKE exchange_mode main,aggressive,base; my_identifier asn1dn; # Cette configuration est faite pour un client (xxxxx.org) # Pour le serveur il suffit de changer le certificat et la clé # ci dessous. certificate_type x509 "xxxxx..org.crt" "xxxxx.org.key"; lifetime time 24 hour; passive off; # Paramètre de sécurité proposer pour cette phase proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2; } proposal_check obey; } # Parametres de sécurité acceptable par notre racoon sainfo anonymous { pfs_group 2; lifetime time 12 hour; encryption_algorithm 3des, des, rijndael; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate; }
|
Mise en place des certificats
Nos certificats (créés précédent) vont être mis dans /usr/local/openssl/certs. Si ce répertoire n'existe pas créer le,
accessible seulement a root.
La configuration du serveur et des clients est la même. Il faut le certificat de notre CA (pour que racoon puisse authentifier les certificats des peers) et le certificats de la machine (serveur ou client).
Donc pour le serveur, dans /usr/local/openssl/certs :
- déposer le certificat de notre CA (cacert.pem)
- déposer le certificat du serveur xxxxx.org.cert
- déposer la clé du serveur xxxxx.org.key
(donc pour un client, ce sera le certificat et la clé du client à mettre dans /usr/local/openssl/certs).
Reste une petite manipulation liée à racoon. En se placant dans /usr/local/openssl/certs faire la commande suivante pour tous certificats s'y trouvant (l'exemple étant fait pour celui de la CA) :
root # ln -s /usr/local/openssl/certs/cacert.pem /usr/local/openssl/certs/`openssl x509 -noout -hash -in /usr/local/openssl/certs/cacert.pem`.0 |
(tout sur la meme ligne)
2.2 Configuration des policies
/etc/ipsec.conf (version client) :
flush; spdflush; spdadd 0.0.0.0/0[any] 192.168.1.254/32[1723] tcp -P out ipsec esp/transport//require ah/transport//require ; spdadd 192.168.1.254/32[1723] 0.0.0.0/0[any] tcp -P in ipsec esp/transport//require ah/transport//require ; spdadd 0.0.0.0/0 192.168.1.254/32 47 -P out ipsec esp/transport//require ah/transport//require ; spdadd 192.168.1.254/32 0.0.0.0/0 47 -P in ipsec esp/transport//require ah/transport//require ; |
Pour les mettre en place il suffit de faire en root :
root # setkey -f /etc/ipsec.conf |
Celà met en place les politiques de sécurités.
Les deux premières lignes efffaces les politiques pré existantes, les deux suivantes mettent en place les politiques pour chiffrer ET authentifier le trafic pptp pour la création du tunnel point a point (trafic TCP vers le port 1723). Les deux dernières permettent de chiffrer ET authentifier le traffic GRE (protocole 47) utiliser pour notre liaison point a point.
Remarque :
Attention, elles seront effacées au prochain reboot !!!
/etc/ipsec.conf (version serveur) :
flush; spdflush; spdadd 192.168.1.254/32[1723] 0.0.0.0/0[any] tcp -P out ipsec esp/transport//require ah/transport//require ; spdadd 0.0.0.0/0[any] 192.168.1.254/32[1723] tcp -P in ipsec esp/transport//require ah/transport//require ; spdadd 192.168.1.254/32 0.0.0.0/0 47 -P out ipsec esp/transport//require ah/transport//require ; spdadd 0.0.0.0/0 192.168.1.254/32 47 -P in ipsec esp/transport//require ah/transport//require ; |
Le sens du trafic est inversé par rapport au client (sinon c'est identique)
Remarque :
Dans notre cas, notre serveur avait l'adresse 192.168.1.254. Il vous
faudra donc adapter les politiques suivant vos envies.
3. Test
Pour tester ce joli bordel :
- installer les politiques (setkey -f /etc/ipsec.conf)
- démarrer racoon (/etc/init.d/racoon start
- lancer le tunnel pptp (via pon pptp)
Il se peut que le tunnel ne soit pas monté du premier coup. Cela est dut à des timeout trop court du coté de pppd/pptp. En effet, le temps que ipsec se mette correctement en place, pptp/pppd peut être impatient. Cela est d'autant plus vrai à travers internet.
Version: "Ca marche chez moi"
Message édité par o'gure le 29-08-2010 à 15:46:10