Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1531 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  IPsec + pptp pour sécuriser une connexion wifi/mettre en place 1 VPN

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

IPsec + pptp pour sécuriser une connexion wifi/mettre en place 1 VPN

n°725188
l0ky
Posté le 04-09-2005 à 20:35:27  profilanswer
 

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 ?

 
  • Configuration

/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

tail -f /var/log/syslog

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.

 


  • Documentation

- 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

 
  • Configuration

/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 # pon pptp


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 [:mrbrelle], 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 [:dawao]. 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.

 
  • Installation :

root # apt-get install racoon ipsec-tools


A la question réponder direct.

 


  • Configuration :


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" [:dawao]


Message édité par o'gure le 29-08-2010 à 15:46:10
mood
Publicité
Posté le 04-09-2005 à 20:35:27  profilanswer
 

n°725189
l0ky
Posté le 04-09-2005 à 20:35:56  profilanswer
 

Réservé, au cas zou

n°725193
Mjules
Modérateur
Parle dans le vide
Posté le 04-09-2005 à 20:43:36  profilanswer
 

sympa le tuto :jap:
 
juste une question, ya une raison particulière pour utiliser ipppd (pppd pour ISDN/RNIS) et pas pppd ?


---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. |  Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
n°725195
l0ky
Posté le 04-09-2005 à 20:45:04  profilanswer
 

aucune [:ootransparent]
c'est bien pppd (je vais de ce pas corriger [:cupra]
(c'était quand je cherchais le nom exact du package)


Message édité par l0ky le 04-09-2005 à 20:47:47
n°725206
l0ky
Posté le 04-09-2005 à 21:06:27  profilanswer
 

Pour être tout à fait juste, il y a un seul truc qui ne marche pas :
 
 Quand le client termine sa connexion (poff pptp par exemple), celà ferme bien chez lui son tunnel mais pas au niveau du serveur :/
Quelqu un saurait d'où sa vient ?
 
Pour l'instant la simple piste que j'envisage serait de mettre des options pour que le serveur coupe la connexion quand il n'y a plus de traffic pendant un certain temps. J'ai pas encore testé (pas eut le temps). Mais si quelqu un a une autre solution...


Message édité par l0ky le 04-09-2005 à 21:06:43
n°725228
Je@nb
Kindly give dime
Posté le 04-09-2005 à 21:49:22  profilanswer
 

Et un certificat signé par cacert se serait pas mal à la place des auto signé non ? http://www.cacert.org/

n°725233
l0ky
Posté le 04-09-2005 à 22:02:19  profilanswer
 

Tu veux que les certificats des clients soient signer par cacert ?
Donc on mettrait le certificat root de cacert à racoon pour qu'il puisse vérifier l'authenticité des  certificats des clients ?
=> dans ce cas là n'importe qui pourrait se faire signer un certificat par cacert et s'authentifier convenablement par racoon (apres il y a les infos de login pour ppp mais bon)
 
:/
 
=> En étant moi même mon CA je distribue les certificats clients, signés par MA CA, aux personnes voulant utiliser mon serveur.


Message édité par l0ky le 04-09-2005 à 22:02:48
n°725268
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 04-09-2005 à 22:49:56  profilanswer
 

[:drapo]
 
(moi j'ai utilisé openvpn avec auth + chiffrement :love:)


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
n°726568
Gf4x3443
Killing perfection
Posté le 07-09-2005 à 19:27:41  profilanswer
 

[:drapo]
 
Dans mon établissement on utilise aussi ce systeme.
 
Merci pour le tuto  :jap:

n°726950
Kytrix
Posté le 08-09-2005 à 18:33:24  profilanswer
 

heuu c'est normal que ça soit aussi compliqué ?  
je veux dire on peut pas faire plus simple :S
 
et est-il possible de connecter un client depuis windows.
 
 
merci :)

mood
Publicité
Posté le 08-09-2005 à 18:33:24  profilanswer
 

n°726953
l0ky
Posté le 08-09-2005 à 18:38:48  profilanswer
 

Oui il y a possibilité de faire plus simple, si tu as seulement 2 ou 3 clients distants tu peux jarter pptp pour faire du tunneling avec IPsec, mais tu perds l'attribution automatique des routes, dns, et adresse IP.
Tu peux également enlever racoon pour la négociation automatique des parametres de sécurité de IPsec et les mettres à la main, sur le serveur et sur les  
 
Windows supporte pptp, par contre je n'ai pas testé avec IPsec

n°726957
black_lord
Modérateur
Truth speaks from peacefulness
Posté le 08-09-2005 à 18:46:21  profilanswer
 

faudrait demander à Jowile, c'est un pro de ce genre de choses :o


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  IPsec + pptp pour sécuriser une connexion wifi/mettre en place 1 VPN

 

Sujets relatifs
supprimer un user id d'une clef gnupg, pour mettre a jour le serveur[Debian] Connexion freebox
sécuriser un hébergement quels chmod ou htaccess ?Linux, WiFi, Nintendo DS et Sony PSP
sécuriser SNMPMise en réseau Wifi
transformer une carte wifi en APWIFI et KAELLA incompatible ?
question wifi - mise en place d'un point d'acces 
Plus de sujets relatifs à : IPsec + pptp pour sécuriser une connexion wifi/mettre en place 1 VPN


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR