IPsec + pptp pour sécuriser une connexion wifi/mettre en place 1 VPN
IPsec + pptp pour sécuriser une connexion wifi/mettre en place 1 VPN - réseaux et sécurité - Linux et OS Alternatifs
Marsh Posté le 04-09-2005 à 20:43:36
sympa le tuto 
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.
Marsh Posté le 04-09-2005 à 20:45:04
aucune ![[:ootransparent]](https://forum-images.hardware.fr/images/perso/ootransparent.gif "[:ootransparent]")
c'est bien pppd (je vais de ce pas corriger ![[:cupra]](https://forum-images.hardware.fr/images/perso/cupra.gif "[:cupra]")
(c'était quand je cherchais le nom exact du package)
Message édité par l0ky le 04-09-2005 à 20:47:47
Marsh Posté le 04-09-2005 à 21:06:27
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
Marsh Posté le 04-09-2005 à 21:49:22
Et un certificat signé par cacert se serait pas mal à la place des auto signé non ? http://www.cacert.org/
Marsh Posté le 04-09-2005 à 22:02:19
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
Marsh Posté le 04-09-2005 à 22:49:56
![[:drapo]](https://forum-images.hardware.fr/images/perso/drapo.gif "[:drapo]")
(moi j'ai utilisé openvpn avec auth + chiffrement 
)
---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Marsh Posté le 07-09-2005 à 19:27:41
Dans mon établissement on utilise aussi ce systeme.
Merci pour le tuto
Marsh Posté le 08-09-2005 à 18:33:24
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 
Marsh Posté le 08-09-2005 à 18:38:48
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
Marsh Posté le 08-09-2005 à 18:46:21
faudrait demander à Jowile, c'est un pro de ce genre de choses 
---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
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 SNMP
- Mise en réseau Wifi
- transformer une carte wifi en AP
- WIFI et KAELLA incompatible ?
- question wifi - mise en place d'un point d'acces
Marsh Posté le 04-09-2005 à 20:35:27
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 :
1. Mise en place de PPTP
1.1 Configuration du serveur
pptp est un protocole permettant de créer un lien point a point à travers un réseau IP.
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
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.
- pptpd.conf (5) manuel pour le fichier de configuration de pptpd.
- pptpd(5) manuel pour pptpd.
1.2 Configuration du client
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 # 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é à :
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 :
(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 :
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