View source for VPN par la pratique OpenVPN Stunnel

You do not have permission to edit this page, for the following reasons:
The action you have requested is limited to users in one of the groups: Autoconfirmed users, Administrators.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page.
[[Category:Sécurité]]

= VPN par la pratique =
Par [[Utilisateur:Jiel|Jiel]] et [[Utilisateur:amnesiak|Tony]]

== 1.1 OpenVPN : Installation et création ==

===1. Installation d'OpenVPN===

Comme nous n'avons pas Internet sur nos clients/serveurs de test, on [[Software-soft_gere-installation_logiciel|installe]] OpenVPN à la main sur notre [[Essayer_GNU/Linux_sans_l'installer|Live CD]] [[Install-index#Ubuntu|Ubuntu]] :

<div class="code">
 root@ubuntu:~/tp_VPN# dpkg -i openvpn_2.0.6-1_i386.deb
 Selecting previously deselected package openvpn.
 (Reading database ... 76142 files and directories currently installed.)
 Unpacking openvpn (from openvpn_2.0.6-1_i386.deb) ...
 Setting up openvpn (2.0.6-1) ...
 Restarting virtual private network daemon:.
</div>
 
A noter que si l'on avait eu un accès au net, la technique suivante aurait suffit :
<div class="code">
 apt-get update && apt-get install openvpn
</div>

===2. Préparation du serveur===

On prépare les certificats et les clefs :

<div class="code">
 root@ubuntu:~/tp_VPN# cd /usr/share/doc/openvpn/examples/easy-rsa/2.0
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0# gzip -d pkitool.gz
</div>

On décompresse les outils pour générer les clefs :

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0# chmod 777 pkitool
</div>

On donne tous les droits au repertoire pkitool :

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0# source ./vars
 NOTE: If you run ./clean-all, I will be doing a rm -rf on /usr/share/doc/openvpn/examples/easy-rsa/2.0/keys
 root@ubuntu:/usr/share/doc/openvpn/examples/
</div>

On exécute le script vars et charge les variables d'environnement :

<div class="code">
 easy-rsa/2.0# ./clean-all
</div>

On génère le certificat du CA. Ce certificat permettra de signer le certificat de tous nos clients et celui du serveur. Grâce à lui, on pourra rajouter autant de clients qu'on le souhaite pour se brancher sur notre serveur.

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ./build-ca
 Generating a 1024 bit RSA private key
 ................++++++
 ......++++++
 writing new private key to 'ca.key'
 -----
 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) [US]:FR
 State or Province Name (full name) [CA]:94
 Locality Name (eg, city) [SanFrancisco]:Creteil
 Organization Name (eg, company) [Fort-Funston]:Paris12
 Organizational Unit Name (eg, section) []:Master2SSI
 Common Name (eg, your name or your server's hostname) [Fort-Funston CA]:ABC
 Email Address [me@myhost.mydomain]:root@localhost
 root@ubuntu:/usr/share/doc/openvpn/examples/
 </div>

On génère maintenant le certificat pour le serveur :

<div class="code">
 easy-rsa/2.0# ./build-key-server server1
 Generating a 1024 bit RSA private key
 .................................++++++
 ..++++++
 writing new private key to 'server1.key'
 -----
 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) [US]:FR
 State or Province Name (full name) [CA]:94
 Locality Name (eg, city) [SanFrancisco]:Creteil
 Organization Name (eg, company) [Fort-Funston]:Paris12
 Organizational Unit Name (eg, section) []:Master2SSI
 Common Name (eg, your name or your server's hostname) [server1]:server1
 Email Address [me@myhost.mydomain]:
 
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:
 Using configuration from /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
 Check that the request matches the signature
 Signature ok
 The Subject's Distinguished Name is as follows
 countryName           :PRINTABLE:'FR'
 stateOrProvinceName   :PRINTABLE:'94'
 localityName          :PRINTABLE:'Creteil'
 organizationName      :PRINTABLE:'Paris12'
 organizationalUnitName:PRINTABLE:'Master2SSI'
 commonName            :PRINTABLE:'server1'
 emailAddress          :IA5STRING:'me@myhost.mydomain'
 Certificate is to be certified until Mar 26 02:30:21 2018 GMT (3650 days)
 Sign the certificate? [y/n]:y
  
 1 out of 1 certificate requests certified, commit? [y/n]y
 Write out database with 1 new entries
 Data Base Updated
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0#
</div>

===3. Vérification du certificat===

On vérifie le certificat créé pour le serveur server1 (on fera de même pour celui du client1 quand il sera créé) :

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0# openssl x509 -in keys/server1.crt -noout -text
 Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 1 (0x1)
         Signature Algorithm: md5WithRSAEncryption
         Issuer: C=FR, ST=94, L=Creteil, O=Paris12, OU=Master2SSI, CN=ABC/emailAddress=root@localhost
         Validity
            Not Before: Mar 28 02:30:21 2008 GMT
            Not After : Mar 26 02:30:21 2018 GMT
         Subject: C=FR, ST=94, L=Creteil, O=Paris12, OU=Master2SSI, CN=server1/emailAddress=me@myhost.mydomain
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
             RSA Public Key: (1024 bit)
                 Modulus (1024 bit):
                     00:ee:d5:69:63:88:68:3e:54:27:b0:cd:34:88:66:
                     1f:8f:b5:4f:3d:ca:72:c0:67:09:82:2c:1c:4a:f4:
                     66:11:8d:e7:33:f4:26:8d:9f:c1:61:54:72:98:b9:
                     b8:a3:b4:7f:42:6a:7f:28:71:48:f9:5a:b5:e9:11:
                     38:7f:20:97:e2:d3:2c:86:2d:98:d2:07:4b:18:5b:
                     ff:4f:30:24:74:86:a4:35:3b:bd:94:dc:67:af:8c:
                     35:6a:41:4a:dc:94:cd:34:a9:49:54:75:1c:73:d2:
                     ee:bd:12:78:ec:64:62:1a:09:d5:d0:70:1f:1e:fb:
                     16:b3:fe:25:be:77:15:f3:df
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             Netscape Cert Type:
                 SSL Server
             Netscape Comment:
                 OpenSSL Generated Server Certificate
             X509v3 Subject Key Identifier:
                 AA:43:74:87:31:76:63:D5:04:97:62:40:13:F7:9E:AB:15:34:19:C3
             X509v3 Authority Key Identifier:
                 keyid:67:92:22:44:BC:33:B9:C8:FF:69:96:11:C5:39:0D:64:03:29:DF:60
                 DirName:/C=FR/ST=94/L=Creteil/O=Paris12/OU=Master2SSI/CN=ABC/emailAddress=root@localhost
                 serial:E7:B7:58:95:0C:72:DA:ED
 
             X509v3 Extended Key Usage:
                 TLS Web Server Authentication
             X509v3 Key Usage:
                 Digital Signature, Key Encipherment
     Signature Algorithm: md5WithRSAEncryption
         b2:e9:fe:fd:78:c8:5d:da:e0:34:db:91:f6:43:27:53:59:02:
         53:07:c0:ec:f9:ca:73:82:5d:62:db:d4:88:56:f5:72:b4:1b:
         c3:3d:c4:a3:59:b2:c2:8d:9f:62:85:8f:5c:c9:4c:a9:f5:27:
         f9:17:cb:30:23:37:35:c0:72:56:5c:5a:f9:72:c9:28:b3:9f:
         fd:b7:d1:9f:e4:a0:e2:1c:e4:33:c5:86:b2:8c:46:aa:18:2a:
         72:9a:3f:2d:49:d4:74:f6:8a:18:99:fa:7a:94:fa:29:a2:5a:
         21:07:70:e1:fc:fd:70:05:1a:99:47:d7:4b:05:7d:ba:0c:7e:
         42:1a
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0#
</div>

===4. Création du certificat du client===

On crée un certificat client SSL, pour le groupe qui va se connecter sur notre serveur. On s'y prend exactement comme pour créer le certificat pour le serveur.

<div class="code">
 easy-rsa/2.0# ./build-key-server client1
 Generating a 1024 bit RSA private key
 .................................++++++
 ..++++++
 writing new private key to 'client1.key'
 -----
 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.
 -----
 State or Province Name (full name) [CA]:94
 Locality Name (eg, city) [SanFrancisco]:Creteil
 Organization Name (eg, company) [Fort-Funston]:Paris12
 Organizational Unit Name (eg, section) []:Master2SSI
 Common Name (eg, your name or your server's hostname) [client1]:client1
 Email Address [me@myhost.mydomain]:
 
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:
 Using configuration from /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
 Check that the request matches the signature
 Signature ok
 The Subject's Distinguished Name is as follows
 countryName           :PRINTABLE:'FR'
 stateOrProvinceName   :PRINTABLE:'94'
 localityName          :PRINTABLE:'Creteil'
 organizationName      :PRINTABLE:'Paris12'
 organizationalUnitName:PRINTABLE:'Master2SSI'
 commonName            :PRINTABLE:'client1'
 emailAddress          :IA5STRING:'me@myhost.mydomain'
 Certificate is to be certified until Mar 26 02:41:30 2018 GMT (3650 days)
 Sign the certificate? [y/n]:y
  
 
 1 out of 1 certificate requests certified, commit? [y/n]y
 Write out database with 1 new entries
 Data Base Updated
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0#
</div>

===5. Création des paramètres de Diffie-Hellman===

On crée les paramètres Diffie-Hellman :

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ./build-dh
 Generating DH parameters, 1024 bit long safe prime, generator 2
 This is going to take a long time
 ...................................................................+............
 ................................................................+...............
 .........+.................+.......+............................................
 .+..............................................................................
 ....+............................................................+..............
 ................................................................................
 .......++*++*++*
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0#
</div>

===6. Copie des clefs dans le répertoire d'OpenVPN===
On copie les fichiers ainsi créés dans le répertoire /etc/openvpn :

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/easy-rsa/2.0# cp -r keys /etc/openvpn/
</div>

== 1.2 OpenVPN : configuration ==

On regarde les fichiers d'exemples. On copie server.conf dans /etc/openvpn :

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/sample-config-files# cp server.conf.gz /etc/openvpn/
 root@ubuntu:/usr/share/doc/openvpn/examples/sample-config-files#
</div>

On décompresse :

<div class="code">
 root@ubuntu:/usr/share/doc/openvpn/examples/sample-config-files# cd /etc/openvpn/
 root@ubuntu:/etc/openvpn# gzip -d server.conf.gz
 root@ubuntu:/etc/openvpn#
</div>

On édite ensuite ensuite le fichier de conf d'OpenVPN pour le serveur.

<div class="code">
 port 1194
 proto udp
 dev tun
 
 ca /etc/openvpn/keys/ca.crt
 cert /etc/openvpn/keys/server1.crt
 key /etc/openvpn/keys/server1.key # à garder bien secrête
 
 dh /etc/openvpn/keys/dh1024.pem
  
 server 10.8.0.0 255.255.255.0
 comp-lzo
 persist-key
 persist-tun
 status openvpn-status.log
 verb 3
</div>

===A) Configuration du client===

On vérifie les fichiers d'exemples :

<div class="code">
 root@ubuntu:/etc/openvpn# cd /usr/share/doc/openvpn/examples/sample-config-files/
 root@ubuntu:/usr/share/doc/openvpn/examples/sample-config-files# cp client.conf /etc/openvpn/
 root@ubuntu:/usr/share/doc/openvpn/examples/sample-config-files# cd /etc/openvpn
 root@ubuntu:/etc/openvpn#
</div>

On édite client.conf en rajoutant l'adresse du serveur VPN.

<div class="code">
 client
 dev tun
 proto udp
 
 remote ip_du_server 1194
 
 resolv-retry infinite
 nobind
 persist-key
 persist-tun
 
 ca /etc/openvpn/keys/ca.crt
 cert /etc/openvpn/keys/client1.crt
 key /etc/openvpn/keys/client1.key
 
 comp-lzo
 verb 3
</div>

===B) Distribution de certificats===

On lance le serveur :

<div class="code">
 root@ubuntu:/etc/openvpn# mv server.conf openvpn.conf
 root@ubuntu:/etc/openvpn# /etc/init.d/openvpn start
 Starting virtual private network daemon: client(OK) openvpn(OK).
</div>

Une fois le client connecté, on obtient des informations sur lui en consultant /etc/openvpn/openvpn-status.log :

<div class="code">
 localhost openvpn # cat openvpn-status.log 
 OpenVPN CLIENT LIST
 Updated,Sun Dec 17 17:21:15 2006
 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
 ABC,88.169.118.169:34322,8851,9928,Sun Dec 17 17:18:29 2006
 ROUTING TABLE
 Virtual Address,Common Name,Real Address,Last Ref
 10.8.0.6,ABC,88.169.118.169:34322,Sun Dec 17 17:21:01 2006
 GLOBAL STATS
 Max bcast/mcast queue length,0
 END
</div>

Le fichier ipp.txt est quant à lui, vide chez le client et contient ABC,10.8.0.4 chez le serveur.
On essaie de capturer sur l'interface sur laquelle partent nos paquets, ici, des pings:

<div class="code">
 17:36:58.100540 IP monclient.openvpn >    88.169.118.169.34322: UDP, length 125
         0x0000:  4500 0099 0000 4000 4011 be9c 5372 5939  E.....@.@...SrY9
         0x0010:  58a2 766a 04aa 8612 0085 8135 302e 335e  X.vj.......50.3^
         0x0020:  c78b ee3d 8792 ce09 da12 2207 5e06 40dd  ...=......".^.@.
         0x0030:  d2d1 8460 3e98 8c6e def3 e5af 28eb ec62  ...`>..n....(..b
         0x0040:  fb06 cd23 22b9 3e04 3e4d 58c2 4d4a 4ed1  ...#".>.>MX.MJN.
 17:36:58.186103 IP 88.169.118.169.34322 > monclient.openvpn: UDP, length 125
         0x0000:  4500 0099 0000 4000 3711 c79c 58a2 766a  E.....@.7...X.vj
         0x0010:  5372 5939 8612 04aa 0085 6cae 30e3 834f  SrY9......l.0..O
         0x0020:  ad50 8cd8 b076 aa7b d241 05c4 9727 3253  .P...v.{.A...'2S
         0x0030:  ac79 26b4 d5fb 1238 1775 b717 ebca 3a6d  .y&....8.u....:m
         0x0040:  3936 c20d 0608 be9b 4a2d fc18 94f9 f1fb  96......J-......
</div>
		 
C'est bien entendu chiffré, mais c'est bon de le vérifier (on voit un paquet UDP, mais les données ne nous sont pas compréhensibles).

Après avoir effectué quelques tests de connectivité avec ping, on remarque quelques «choses» intéressantes avec les outils classiques au niveau serveur :

<div class="code">
 localhost openvpn # arp -a
 localhost openvpn # route
 Table de routage IP du noyau
 Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
 '''10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0'''
 local312.lnsta1 *               255.255.255.255 UH    0      0        0 ppp0
 '''10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0'''
 192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
 192.168.10.0    *               255.255.255.0   U     0      0        0 eth1
 loopback        *               255.0.0.0       U     0      0        0 lo
 default         local312.lnsta1 0.0.0.0         UG    0      0        0 ppp0
</div>

On constate que notre table de cache ARP est vide et que notre table de routage a obtenu quant à elle de nouvelles routes permettant de passer dans le tunnel.

===C) Mode pont (Bridge)===

On modifie les fichiers de configurations clients et serveur en remplaçant dev tun par dev tap.

On re-pratique les tests précédents :

<div class="code">
 localhost openvpn # route
 Table de routage IP du noyau
 Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
 local232.lnfny1 *               255.255.255.255 UH    0      0        0 ppp0
 10.8.0.0        *               255.255.255.0   U     0      0        0 tap0
 192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
 192.168.10.0    *               255.255.255.0   U     0      0        0 eth1
 loopback        *               255.0.0.0       U     0      0        0 lo
 default         local232.lnfny1 0.0.0.0         UG    0      0        0 ppp0
</div>

La table de routage s'est un peu allégée.

Le mode pont nous permet d'agir directement au niveau de la couche 2. Le client se fait attribuer une IP lorsqu'il se connecte, mais il pourrait très bien avoir une conectivité IPv6 ou demander son IP à un serveur DHCP.

Le fichier ipp.txt n'a pas changé. Le fichier openvpn-status.log a quelque peu changé, et montre maintenant de nouvelles informations, telle l'adresse MAC du client :

<div class="code">
 OpenVPN CLIENT LIST
 Updated,Sun Dec 17 17:48:58 2006
 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
 ABC,88.169.118.169:34393,5264,6927,Sun Dec 17 17:42:51 2006
 ROUTING TABLE
 Virtual Address,Common Name,Real Address,Last Ref
  8a:e5:8c:0a:a5:a6,ABC,88.169.118.169:34393,Sun Dec 17 17:42:53 2006
 GLOBAL STATS
 Max bcast/mcast queue length,1
 END
</div>

Notre table ARP nous informe que l'on a bien accès à la couche 2 :

<div class="code">
 localhost openvpn # arp -a
 ? (10.8.0.4) at 8A:E5:8C:0A:A5:A6 [ether] on tap0
</div>

La capture du flux sur tap0 nous montre les échanges de requète ARP, explique pourquoi la table ARP se remplit.

Ce type de tunnel est donc parfait pour tout ce qui nécessite des protocoles au dessus de la couche 2, comme IPX par exemple. Avant, quand nous n'étions pas en mode pont, ce n'était pas possible de mettre des protocoles de niveau 3 dans notre tunnel.

===D) Poussée de routes vers le client===

Cette configuration force le client à passer tout son trafic sortant à l'intérieur du VPN. Cela permet de sécuriser de manière totale sa connexion. En point négatif, on pourra remarquer que cela augmente la latence du client (puisqu'il doit maintenant passer par le VPN pour sortir) et peut aussi limiter son débit.

On édite server.conf pour "pousser" les routes vers la machine du client, on rajoute la ligne suivante :

<div class="code">
 push "redirect-gateway def1"
</div>

Il faut aussi rajouter au serveur des règles pour activer le NAT si on veut que le client puisse sortir vers l'extérieur. En voici un exemple:

<div class="code">
 iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
</div>

==2) VPN applicatif : Stunnel & SSH (ou tunneling de ports)==

===Stunnel 3.X===

Si on fonctionne sur un ancien système, il est probable que l'on ait une ancienne version de stunnel. La version 4.0 a apporté de nombreux changements, dont un changement total de la façon de le lancer. La nouvelle version lit dans un fichier, tandis que l'ancienne prenait tous ses arguments en ligne de commande.
Pour plus d'information, se réferrer à l'URL suivante [http://www.freebsddiary.org/stunnel-v3-to-v4.php Upgrading to stunnel 4] (en anglais).

===Stunnel 4.X===

====Principe et utilité====

Cet outil sert dans plusieurs cas :
* quand on est sur un réseau non sûr et que l'on souhaite se connecter par exemple sur un serveur mail externe en POP afin d'y relever son courrier électronique
* quand on a un serveur utilisant pour communiquer le protocole TCP et que l'on veut lui adjoindre la fonctionnalité SSL afin que son trafic soit chiffré

Stunnel est une sorte de proxy, il fonctionne comme suit :
client (en clair) <=> Stunnel (sur la machine client) <=> Stunnel (sur un hôte de confiance ou directement sur le serveur)<=> leserveur (en clair)

Ainsi, tout l'échange entre le client et le serveur est sécurisé par stunnel.

Comme tout transite avec SSL, on pourra constater que la capture du trafic sur l'interface de sortie du client que la communication est totalement chiffrée.

====Côté serveur====

Nous allons ici nous employer a protéger un serveur HTTP qui n'a pas de connexion HTTPS. Le fichier de configuration /etc/stunnel/stunnel.conf ressemble à ce qui suit :

<div class="code">
 # Sample stunnel configuration file by Michal Trojnara 2002-2005
 # Some options used here may not be adequate for your particular configuration
 # Please make sure you understand them (especially the effect of chroot jail)
 
 # Certificate/key is needed in server mode and optional in client mode
 cert = /etc/stunnel/stunnel.pem
 key = /etc/stunnel/stunnel.key
 
 # Some security enhancements for UNIX systems - comment them out on Win32
 # chroot = /chroot/stunnel/
 setuid = stunnel
 setgid = stunnel
 # PID is created inside chroot jail
 pid = /var/run/stunnel/stunnel.pid
 
 # Some performance tunings
 socket = l:TCP_NODELAY=1
 socket = r:TCP_NODELAY=1
 #compression = rle
 
 # Workaround for Eudora bug
 #options = DONT_INSERT_EMPTY_FRAGMENTS
 
 # Authentication stuff
 #verify = 2
 # Don't forget to c_rehash CApath
 # CApath is located inside chroot jail:
 #CApath = /certs
 # It's often easier to use CAfile:
 #CAfile = /etc/stunnel/certs.pem
 # Don't forget to c_rehash CRLpath
 # CRLpath is located inside chroot jail:
 #CRLpath = /crls
 # Alternatively you can use CRLfile:
 #CRLfile = /etc/stunnel/crls.pem
 
 # Some debugging stuff useful for troubleshooting
 #debug = 7
 output = /var/log/stunnel.log
 
 # Use it for client mode
 #client = yes
 
 # Service-level configuration
 
 #[pop3s]
 #accept  = 995
 #connect = 110
 
 #[imaps]
 #accept  = 993
 #connect = 143
 
 #[ssmtp]
 #accept  = 465
 #connect = 25
 
 [https]
 accept  = 443
 connect = serveur_a_proteger:80
 TIMEOUTclose = 0
</div>

Ici, on va donc dire d'écouter sur le port 443 un client stunnel afin de pouvoir se brancher de manière sécurisée sur le port 80 de ce site.

====Côté client====

On édite le fichier de configuration de stunnel pour le client, c'est à dire /etc/stunnel/stunnel.conf.

<div class="code">
 client = yes    # on est le client
 #foreground = no
 
 [443]
 accept = localhost:80    # port en clair
 connect = IP_serveur_stunnel:443    # serveur et son port SLL
</div>

Ensuite on lance stunnel par la commande :

<div class="code">
 [root@mamachine ssl]# stunnel /etc/stunnel/stunnel.conf
</div>

On voit que ça a marché :

<div class="code">
 [root@mamachine ssl]# netstat -l -t -n|grep :80
 tcp        0      0 127.0.0.1:80                0.0.0.0:*                   LISTEN
</div>

Pour vraiment faire un vrai tunnel sécurisé, et que le client soit sûr que le serveur soit digne de confiance, le serveur aurait pu donner au client son certificat. Le client aurait juste eu à rajouter dans son fichier stunnel.conf la ligne suivante :

<div class="code">
 cert = /etc/stunnel/server.pem
</div>

====Analyse du trafic====

Avec l'aide Wireshark (ex-Ethereal), lorsqu'on capture un échange HTTP complet, on ne voit pas le trafic HTTP. Soit on a commencé la capture au début de l'échange et on voit que l'on a du SSL, soit on a commencé la capture au cours de l'échange et Wireshark ne voit que du TCP.

===SSH===

On utilise maintenant le même mécanisme mais en utilisant le protocole SSH.

====Côté serveur ====

Il est très probable que le serveur SSH de notre distribution soit déjà directement bien configuré. Si on a un problème pour la suite, il faut penser à vérifier que l'on a activé le TCP port forwarding en rajoutant la ligne suivant dans son sshd_config (celui-ci est normalement activé par défaut si rien n'est précisé):

<div class="code">
 AllowTcpForwarding yes
</div>

====Côté client ====

On va tenter de faire un tunnel via SSH. On choisit un port non privilégié (supérieur à 1024), ici on a pris 6712. On va ensuite demander au serveur SSH de nous rediriger le trafic d'un serveur choisi, ici le serveur web www.linuxfr.org.

<div class="code">
 [root@client ssl]# ssh -l luser -L 6712:www.linuxfr.org:80 serveur_ssh.tld
 Warning: Permanently added '80.114.69.57' (RSA) to the list of known hosts.
 Password:
 Last login: Sun Dec 17 20:21:06 2006 from localhost
 luser@remotehost ~ $ ls
</div>

La connexion au serveur SSH a marché. On lance un navigateur web sur localhost:6712, et on est immédiatement redirigé sur la page d'accueil de linuxfr.org. On peut vérifié que le tunnel a bien marché aussi avec la commande netstat :

<div class="code">
 [root@client openvpn]# netstat -l -t -n | grep :6712
 tcp        0      0 127.0.0.1:6712              0.0.0.0:*                   LISTEN
 tcp        0      0 ::1:6712                    :::*                        LISTEN
 [root@client openvpn]#
</div>

====Analyse de trafic ====

On ne peut pas voir de trafic HTTP avec Wireshark, tout est chiffré.

===WGET et tunneling SSH===

On va essayer de récupérer avec wget l'image qui est en haut à gauche du site linuxfr.org (un manchot) :

<div class="code">
 [root@client tmp]# wget <nowiki>127.0.0.1:6712/images/top_bar_left_logo.png</nowiki>
 --21:07:48--  <nowiki>http://127.0.0.1:6712/images/top_bar_left_logo.png</nowiki>
            => `top_bar_left_logo.png'
 Connexion vers 127.0.0.1:6712...connecté.
 requête HTTP transmise, en attente de la réponse...302 Found
 Emplacement: <nowiki>http://linuxfr.org/ images/top_bar_left_logo.png</nowiki> [suivant]
 --21:07:49--  <nowiki>http://linuxfr.org/ images/top_bar_left_logo.png</nowiki>
            => `top_bar_left_logo.png'
 Résolution de linuxfr.org... 212.27.33.225
 Connexion vers linuxfr.org|212.27.33.225|:80...connecté.
 requête HTTP transmise, en attente de la réponse...200 OK
 Longueur: 20,474 (20K) [image/png] 
 
 100%[=============================================================================================================>] 20,474        --.--K/s
 
 21:07:49 (240.57 KB/s) - « top_bar_left_logo.png » sauvegardé [20474/20474]
 
 [root@client tmp]#
</div>

On a bien récupéré l'image et on peut la visionner. Wget est passé chez le client par le port 6712, au début. Puis, il s'est vu donné l'IP du site de linuxfr.org pour télécharger. C'est pourquoi il nous affiche qu'il a téléchargé sur linuxfr.org. Ainsi, seul le début de la requète est passé par le tunnel. Le reste de la transaction s'est effectuée en clair.

===Tunneling SSH de port distant===

<div class="code">
 [root@client tmp]# ssh -l user -R le_port_ouvert_a_distance:l_IP_de_l_hote_a_contacter:le_port_du_serveur_a_contacter le_serveur_distant
 Password:
 Last login: Sun Dec 17 21:22:21 2006 from localhost
 user@localhost ~ $
</div>

Ainsi, toutes les requêtes sur le_server_distant:le_port_ouvert_a_distance seront ramenées à la machine qui aura établi la connexion SSH, et celle-ci transférera à son tour ses connexions vers l_IP_de_l_hote_a_contacter:le_port_du_serveur_a_contacter.

L'explication de la page de manuel SSH:
<div class="code">
     -R [bind_address:]port:host:hostport
             Specifies that the given port on the remote (server) host is to
             be forwarded to the given host and port on the local side.  This
             works by allocating a socket to listen to port on the remote
             side, and whenever a connection is made to this port, the connec-
             tion is forwarded over the secure channel, and a connection is
             made to host port hostport from the local machine.
</div>

Cette fonctionnalité permet par exemple de donner un accès à des machines à l'intérieur d'un réseau.

===Authentification forte SSH par clés===

Une possibilité de SSH est l'authentification par clef.
Celle-ci permet:
* de s'authentifier avec une clef, ce qui augmente la sécurité entre le client serveur, car ce dernier peut ensuite exiger que tous les clients aient une clef pour se loguer (deux éléments requis au lieu d'un seul)
* de s'authentifier de manière automatique, facilitant ainsi la mise en place de script

Il faut au préalable créer une clef:

<div class="code">
 ~/$ ssh-keygen -t dsa
 Generating public/private dsa key pair.
 Enter file in which to save the key (/home/user/.ssh/id_dsa):./maclef
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved in ./maclef.
 Your public key has been saved in ./maclef.pub.
 The key fingerprint is:
 f2:aa:d0:9e:4e:95:ff:29:f3:3b:ac:fc:0f:2d:b4:ef user@localhost
</div>

Ici, si vous entrez une passphrase, celle-ci sera demandée à chaque login. Si vous décidez de ne pas en mettre, cela permettra l'authentification sans login (pensez à protéger votre clef!).

Ensuite, il suffit d'envoyer la clef publique sur le serveur :

<div class="code">
 ssh-copy-id -i lecheminverslaclefPUBLIQUE IP_DU_SERVEUR
</div>

Vous aurez ainsi le plaisir de pouvoir vous loguer grâce à cette clef de la manière suivante :

<div class="code">
 ssh -i lecheminverslaclefPRIVEE IP_DU_SERVEUR
</div>

===Conclusions ===

* Avec le tunneling SSH, on a rien à configurer (avant il fallait éditer le fichier stunnel.conf). Il faut juste que le client possède un client SSH.
* Par SSH on a l'avantage d'avoir une authentification par mot de passe (avec stunnel le client aurait peut cependant exiger d'avoir le certificat du serveur).
* Un inconvénient est que les ports locaux qu'on utilise pour les transferts (ici 6712) sont accessibles par tous les utilisateurs éventuels de la machine, e.g. les passerelles.

<br/>
<br/>
'''<b>[[Reseau-index|@ Retour à la rubrique Réseau et sécurité]]</b>'''

{{Copy|2006, 2010|[[Utilisateur:Jiel|Jiel Beaumadier]] et [[Utilisateur:amnesiak|Tony Cheneau]]|FDL}}
Templates used on this page:
Return to VPN par la pratique OpenVPN Stunnel.
Retrieved from "https://lea-linux.org/documentations/VPN_par_la_pratique_OpenVPN_Stunnel"