Mon réseau

Mon réseau d’entreprise

16.1 Le serveur OpenVPN

Précédent   Suivant

À l’IUT, Le TP openvpn est présenté à la section 6.1.

Le service OpenVPN permet de fournir un accès sécurisé au dessus d’un réseau non fiable comme Internet. Il faut commencer par mettre en place un serveur OpenVPN. La figure 16.1 illustre l’architecture globale. Le serveur OpenVPN va fournir l’accès à des ordinateurs internes, potentiellement des serveurs.

Les clients peuvent être de deux types : poste nomade ou routeur d’accès. Le poste nomade est, par exemple, le portable d’un employé. Le routeur d’accès peut fournir la connectivité entre les ordinateurs dans plusieurs sites de l’entreprise.

(image)

Fig. 16.1 : L’architecture OpenVPN.

Comme il n’y a pas de gestion compliquée de la licence du logiciel, il est possible d’utiliser des machines virtuelles sur un PC nomade en cas de besoin.

(image)Il est possible d’installer un client openVPN sur de nombreux systèmes d’exploitation. Néanmoins OpenVPN ne pourra pas protéger le réseau de l’entreprise si un poste nomade est corrompu.

16.1.1 Faisons autorité

Le paquet openvpn recommande le paquet easy-rsa. Celui-ci fournit l’architecture de confiance.

(image)La sécurité d’OpenVPN repose sur la cryptographie. Les clefs présentes sur le serveur fournissant l’autorité de confiance permettent de créer des accès facilement, il faut donc que cet ordinateur soit particulièrement bien protégé.

Le paquet easy-rsa doit être installé, il fournit les commandes facilitant la gestion des différentes clefs. Pour commencer, il faut créer un répertoire dédié à la gestion des clefs. Avec une Debian Buster, c’est la commande suivante : 

arno@joe:~$ make-cadir RT
arno@joe:~$ ls
RT
arno@joe:~$ ls RT
easyrsa openssl-easyrsa.cnf   vars   x509-types
arno@joe:~$

Il faut se déplacer dans ce répertoire. Le fichier vars contient des variables qu’il faut adapter à l’usage. 

set_var EASYRSA_REQ_COUNTRY      "FR"
set_var EASYRSA_REQ_PROVINCE     "PACA"
set_var EASYRSA_REQ_CITY         "Marseille"
set_var EASYRSA_REQ_ORG          "Intl Students of RTLum"
set_var EASYRSA_REQ_EMAIL        "me@RTlum.net"
set_var EASYRSA_REQ_OU           "Osaka4ever"

Il faut alors initialiser l’infrastructure : 

arno@joe:~/RT$ ./easyrsa init-pki

Note: using Easy-RSA configuration from: ./vars

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /home/arno/RT/pki
arno@joe:~/RT$ openssl rand -out pki/.rnd -hex 256

La commande de création du fichier .rnd ne devrait pas être utile longtemps.

Dans cette version, il faudra protéger obligatoirement la clef privée de l’autorité par une phrase de passe. 

arno@joe:~/RT$ ./easyrsa build-ca

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d     10 Sep 2019

Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
Generating RSA private key, 2048 bit long modulus (2 primes)
.........+++++
.........................................................................+++++
e is 65537 (0x010001)
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.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:RTlum

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/arno/RT/pki/ca.crt

arno@joe:~/RT$

Le répertoire pki contient :

ca.crt

le certificat de l’autorité, il faut être sûr que ce fichier est le bon fichier, il peut être lu par tous ;

ca.key

la clef secrète de l’autorité, elle doit être protégée en lecture.

16.1.2 Mise en place du serveur

La station d’autorité ne sert qu’à certifier les clefs. Tous les autres fichiers sont générés sur la machine cible, voire pour la machine cible. Si les fichiers sont générés par un autre ordinateur, il faudra les transférer de manière sécurisée.

Nous commençons par les paramètres Diffie–Hellman. Ceux-ci sont utilisés pour éviter que les sessions enregistrées par un malveillant puisse être déchifrées dans le futur si les clefs sont dérobées. 

arno@joe:~/RT$   ./easyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
....ceci prend un certain temps...(ici 2mn)
DH parameters of size 2048 created at /home/arno/RT/pki/dh.pem

Le fichier généré pourrait être renommé pour contenir dans le nom la taille : 

$   mv dh.pem dh-2048.pem

Après, nous générons les clefs pour le serveur : 

arno@joe:~/RT$ ./easyrsa gen-req joe nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
Generating a RSA private key
.............+++++
.........................+++++
writing new private key to '/home/arno/RT/pki/private/joe.key.Rb6CshJgRp'
-----
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.
-----
Common Name (eg: your user, host, or server name) [joe]:

Keypair and certificate request completed. Your files are:
req: /home/arno/RT/pki/reqs/joe.req
key: /home/arno/RT/pki/private/joe.key

La commande utilise les paramètres suivants :

gen-req

génère une demande de certificat ;

joe

le nom court du serveur ;

nopass

pas de chiffrement de la clef.

Deux fichiers sont créés : la clef secrète et la demande de certificat. Ce certificat doit être transféré sur l’autorité de certification, puis importé (commande easyrsa import-req) dans la base. Si les fichiers sont générés sur le même ordinateur, il n’y a pas la partie importation. La clef peut être directement signée : 

arno@joe:~/RT$   ./easyrsa sign-req server joe

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d   10 Sep 2019



You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject=
    commonName                 = joe



Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
Using configuration from /home/arno/RT/pki/safessl-easyrsa.cnf
Enter pass phrase for /home/arno/RT/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'joe'
Certificate is to be certified until Mar 20 18:09:08 2024 GMT (1080 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/arno/RT/pki/issued/joe.crt

Les fichiers cryptographiques sont générés, il faut configurer le serveur. Pour cela, récupérer le fichier de configuration d’exemple : 

# cd /usr/share/doc
# cd openvpn/examples/sample-config-files/
# cp server.conf.gz /etc/openvpn
# cd /etc/openvpn
# gzip -d server.conf.gz
# mv server.conf joe.conf

Il faut récupérer les fichiers cryptographiques :

ca.crt

le certificat de l’autorité ;

laurel.crt

le certificat de laurel, signé par l’autorité ;

laurel.key

la clef privée, générée par laurel (protégée en lecture) ;

dh2048.pem

les données Diffie-Hellman, générées par laurel et renommé avec la longueur de clef utilisée.

Et en créer un dernier qui limite des attaques DDOS. 

# cd /etc/openvpn/
# openvpn --genkey --secret ta.key

Il faut alors modifier le fichier de configuration joe.conf du répertoire /etc/openvpn pour inclure les définitions des fichiers cryptographique. Il peut être utile de modifier l’adresse du réseau privé. Le serveur peut alors être lancé. S’il n’y a pas d’erreurs alors le lancement réussi. 

root@joe:/etc/openvpn# openvpn joe.conf
Mon Apr 5 20:20:06 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
Mon Apr 5 20:20:06 2021 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Mon Apr 5 20:20:06 2021 Diffie-Hellman initialized with 2048 bit key
Mon Apr 5 20:20:06 2021 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 5 20:20:06 2021 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 5 20:20:06 2021 ROUTE_GATEWAY 10.33.101.250/255.255.255.0 IFACE=enp0s31f6 HWADDR=18:66:da:46:72:3b
Mon Apr 5 20:20:06 2021 TUN/TAP device tun0 opened
Mon Apr 5 20:20:06 2021 TUN/TAP TX queue length set to 100
Mon Apr 5 20:20:06 2021 /sbin/ip link set dev tun0 up mtu 1500
Mon Apr 5 20:20:06 2021 /sbin/ip addr add dev tun0 local 10.9.0.1 peer 10.9.0.2
Mon Apr 5 20:20:06 2021 /sbin/ip route add 10.9.0.0/24 via 10.9.0.2
Mon Apr 5 20:20:06 2021 Could not determine IPv4/IPv6 protocol. Using AF_INET
Mon Apr 5 20:20:06 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Apr 5 20:20:06 2021 UDPv4 link local (bound): [AF_INET][undef]:1194
Mon Apr 5 20:20:06 2021 UDPv4 link remote: [AF_UNSPEC]
Mon Apr 5 20:20:06 2021 MULTI: multi_init called, r=256 v=256
Mon Apr 5 20:20:06 2021 IFCONFIG POOL: base=10.9.0.4 size=62, ipv6=0
Mon Apr 5 20:20:06 2021 IFCONFIG POOL LIST
Mon Apr 5 20:20:06 2021 Initialization Sequence Completed

C’est bien de vérifier, par un reboot, que le serveur démarre correctement au lancement de l’ordinateur.

16.1.3 Mise en place d’un client

Nous allons présenter ici la mise en place d’un client GNU/Linux. L’installation est similaire sur tous les systèmes raisonables. Une application pour téléphone mobile est disponible sur F-Droid. L’utilisation d’un système privateur rend caduque la sécurité apportée par OpenVPN.

Il faut commencer par générer la clef pour le client de manière similaire au serveur. 

arno@joe:~/RT$ ./easyrsa gen-req jack nopass
...
Common Name (eg: your user, host, or server name) [jack]:

Keypair and certificate request completed. Your files are:
req: /home/arno/RT/pki/reqs/jack.req
key: /home/arno/RT/pki/private/jack.key

Ensuite, signer le certificat : 

arno@joe:~/RT$   ./easyrsa sign-req client jack

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019
Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/arno/RT/pki/issued/jack.crt

Les certificats (ca.crt et jack.crt) doivent être envoyés sur le client. Ensuite, configurer le client. Il faut récupérer le fichier d’exemple d’OpenVPN (client.conf) en le renommant et en l’installant dans /etc/openvpn.

Il faut installer les fichiers dans le répertoire /etc/openvpn et modifier les déclarations dans le fichier jack.conf.

ca.crt

le certificat d’autorité ;

jack.crt

le certificat du client :

jack.key

la clef du client.

Et ajouter le fichier ta.key depuis le serveur. Enfin, la dernière modification consiste à indiquer au client l’adresse ou le nom du serveur. Cela se fait en modifiant la directive remote. dans le fichier de configuration. 

# The hostname/IP and port of the server.
remote joe 1194

Ensuite, il faut lancer OpenVPN. Si tout s’est bien passé, alors l’interface tun0 apparaît. 

3: tun0:  ...
    link/none
    inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever

Le client et le serveur OpenVPN peuvent alors communiquer de manière sécurisée. Mais juste entre eux. Le serveur est souvent le routeur d’accès et n’est pas directement utilisé. Il est intéressant de pouvoir offrir un accès aux serveurs internes à l’entreprise, c’est-à-dire derrière le serveur OpenVPN.

16.1.4 Accès privé au réseau

Si le serveur OpenVPN est le routeur d’accès d’un site de l’entreprise, alors il y a un ou plusieurs réseaux internes. Un réseau d’entreprise est souvent constitué d’une DMZ, accessible depuis presque tout l’Internet, des stations protégées contre un accès extérieur et des serveurs internes, considérés comme inaccessibles depuis Internet.

Le serveur OpenVPN, étant à l’intérieur du site de l’entreprise, peut avoir accès aux serveurs internes et le transmettre aux clients. C’est ce que nous allons mettre en place.

Nous supposons que le serveur a accès à un réseau privé, par exemple : 10.105.2.1/24. Ce réseau n’a pas besoin d’être directement connecté à ce routeur, le réseau peut aussi ne pas être hébergé par l’entreprise. Pour que le client puisse se connecter vers ce réseau en utilisant la connexion OpenVPN, il faut que le serveur pousse la route en question. Le client, utilisera alors cette route. Cela se fait en modifiant le serveur pour ajouter la ou les routes désirées. Le fichier de configuration dispose d’une section adaptée où les routes seront rajoutées. 

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
push "route 10.105.2.1 255.255.255.0"

Puis relancer le serveur OpenVPN. Il faut aussi relancer le client. La route vers le réseau poussé apparaît alors. 

ip route
default via 10.33.105.250 dev eth0
10.105.2.0/24 via 10.8.0.5 dev tun0
10.33.105.0/24 dev eth0 proto kernel scope link src 10.33.105.3

Le service VPN est en place. Le VPN peut être considéré comme un routeur, toutes les stratégies de routages peuvent être mises en place. En particulier, il est possible de router tout le trafic de sortie du poste nomade par le serveur VPN pour se protéger des agences de surveillance. Nous avons vu l’utilisation des phrases de passe pour protéger les clefs secrètes du vol du fichier. Cette protection peut s’étendre facilement à tous les fichiers en chiffrant le disque dur.

Précédent   Suivant