VPN
Source : https://vpn.karolak.fr/#reseau-entreprise
Introduction
Le réseau d'entreprise
Le réseau d'une entreprise évolue en même temps qu'elle. Le réseau qui relie les équipements au sein d'un site géographique est généralement la propriété de l'entreprise; tandis que les interconnexions entre les sites empruntent généralement des infrastructures publiques plus ou moins sécurisées.
On appelle VPN (Virtual Private Network) l'ensemble des techniques permettant d'étendre le réseau de l'entreprise en préservant la confidentialité des données. Une interconnexion VPN permet alors de connecter les réseaux de l'entreprise au travers des réseaux publics, pour moins cher, tout en conservant les garanties de sécurité nécessaires.
Les solutions VPN apportent général les bénéfices suivants :
- Authentification par clef publique
- Confidentialité des échanges (chiffrement)
- Confidentialité à posteriori en cas de compromission des secrets cryptographiques
- Transport de paquets destiné à un réseau privé via un réseau public
Le principal inconvénient porte sur les performances; Internet ne possède pas les garanties de qualité de service d'un réseau dédié. L'encapsulation et le chiffrement ont un coût en matière de performances.
Principes
On distingue en général deux types de besoins pour les connexions au réseau d'entreprise :
- Les connexions d'un employé au réseau
- Les connexions entre deux branches de l'entreprise.
En effet, si l’objectif est similaire, et si les moyens techniques mis en jeu sont souvent les mêmes, les différences conceptuelles entre ces deux types d’accès font qu’on utilisera le plus souvent des solutions différentes pour gérer ces deux cas.
Client-Serveur
La connexion d'un employé utilise une approche de type client-serveur. Le serveur est un concentrateur VPN central sur lequel chaque employé se connecte, obtenant après authentification l'accès aux ressources de l'entreprise. Les clients de ce serveur ne peuvent généralement pas communiquer entre eux, hormis via une ressource du réseau. La connexion du réseau d'une filiale au siège peut parfois s'effectuer selon ce principe; de grandes entreprises très centralisées peuvent reposer sur un modèle en étoile.
Cela peut ressembler à de la connexion d'employés, mais à double sens : le réseau central peut accéder aux réseaux périphériques, pour de l'administration par exemple. Ce modèle est peu performant lorsque deux filiales veulent communiquer entre elles, puisque tout doit passer par le centre.
Interconnexion
Dans d'autres entreprises, ce modèle n'est pas viable, si par exemple l'entreprise est répartie en sites de tailles égales, et on ne sait plus trop où définir un serveur.
La connexion entre plusieurs entités peut s'avérer complexe :
Dès que l'on dépasse les 3 entités, l'égalité entre les noeuds n'est plus assurée, et on doit en désigner certains comme serveurs. Heureusement, certains protocoles VPNS fonctionnent selon un principe décentralisé. Dans ce cas, la configuration se fait de façon identique sur chaque équipement. On a alors un meilleur équilibre.
L'interconnexion de n noeuds nécessite n(n-1)/2 liens.
Dans tous les cas, il faut que la topologie du VPN reflète l'entreprise.
Tunnels
Dans chacun des cas cités, un VPN permet d'établir un tunnel; soit entre deux réseaux, soit entre un poste et un réseau.
Un tunnel est une connexion réseau virtuelle dont le trafic est en réalité dirigé vers une autre interface réseau après avoir subi un traitement, généralement une encapsulation et le chiffrement des informations contenues dans la trame.
L'encapsulation permet de masquer la véritable destination d'une trame dans le cas où celle-ci serait à destination d'un réseau privé, la plupart des entreprise utilisant des adresses IPv4 privées pour leurs réseaux internes. Sans VPN, une trame à destination d'un réseau privé nepeut pas circuler sur Internet.
Une trame qui circule via VPN est donc encapsulée, et éventuellement (généralement) chiffrée. Au niveau de l'OS, une interface virtuelle sert à rendre transparent le traitement de la trame; ainsi, n'importe quelle application peut fonctionner sans avoir connaissance du VPN. On peut bien sûr enchaîner les tunnels,
Dimensionnement
L'encapsulation, en particulier quand elle est couplée à du chiffrement, présente un certain coût en ressources. C'est pourquoi des équipements VPN sont souvent dédiés, ou cohabitent avec des firewalls réseau qui consomment peu de ressources. Le coût de l'encapsulation est rarement limitant pour peu que l'on utilise des serveurs récents. Un serveur bas de gamme encaissera sans problèmes 10 Mbps de trafic chiffré, un serveur un peu plus performant et équipé de cartes réseau haut de gamme pourra assurer des connexions entre réseaux plus rapides (au dessus de 100 Mbps). Ces limites apparaissent en revanche beaucoup plus vite sur des équipements dédiés possédant des processeurs de faible puissance.
On peut noter que certains serveurs ou équipements peuvent être dotés de puces d'accélération cryptographique, qui assurent le support d'un ou plusieurs mécanismes de chiffrement, et décharge considérablement le CPU.
Les solutions
OpenSSH
OpenSSH est le logiciel le plus utilisé pour l’export de console, il est utilisé sur près de 90% des serveurs de type UNIX dans le monde, pour les tâches d’administration. Au fil des années, OpenSSH s’est étoffé de nombreuses fonctionnalités qui permettent de l’utiliser bien au delà de la classique « console réseau » que tous les administrateurs UNIX connaissent bien. Précisons qu’il ne s’agit pas à proprement parler d’une solution de VPN « traditionnelle », mais elle fournit les mêmes services à plus petite échelle.
Redirection de port
La fonctionnalité alternative la plus connue de OpenSSH. Une fois connecté à un serveur via une connection SSH, un client peut demander à ce que le serveur lui transmette des connexions vers d'autres machines, à la manière d'un proxy, via une encapsulation. L'une des principales applications de cette technique est de sécuriser un protocole qui ne l'est initialement pas, comme VNC.
Le serveur, ici, n'est pas accessible depuis Internet car VNC n'est pas sûr. Il est cependant accessible depuis un serveur passerelle SSH, lui-même accessible depuis le net. Le client va donc s'authentifier auprès du serveur SSH, puis ouvrira une connexion VNC qui sera en clair entre le serveur et la passerelle SSH, puis chiffrée de la passerelle à l'utilisateur.
Une autre possibilité est l'ouverture d'un proxy dynamique. Une fois connecté, le client peut utiliser le serveur SSH comme un proxy SOCKS et s'en servir pour relayer les connexions web vers la plupart des services réseau; notamment les mails, la navigation web, etc. Cette possibilité ne se limitant pas à un seul serveur à la fois, elle se rapproche d'un VPN.
Ces application de OpenSSH sont utiles dans certains cas et offrent certains avantages par rapport à un VPN (notamment le prix); cependant elles sont vites limitées, et réservées aux utilisateurs avertis.
Tunnel sécurisé
Les techniques vues précédemment sont en général utilisées pour connecter un utilisateur au réseau. OpenSSH propose une solution d'interconnexion entre réseaux plus robuste : la redirection d'interfaces.
Celle-ci permet de partager une carte réseau virtuelle entre deux machines. Il s'agit d'une solution plus souple car l'ensemble des capacités de Linux sont accessibles (routage, filtrage, HA, etc). L'ensemble des trames réseau envoyées sur cette carte virtuelle, dans un sens comme dans l'autre, réapparaît sur l'autre machine, après avoir été chiffré et transmis au travers de la connexion SSH.
Cette technique permet de monter rapidement un VPN entre deux machines UNIX, pour un besoin ponctuel. Elle est cependant peu utilisée pour de l'interconnexion définitive, au profit de solutions plus interopérables et configurables.
OpenSSH offre donc des possibilités de VPN réduites, pratiques pour une mise en place d’accès rapide. Cependant l’absence de connexion avec un annuaire ou d’intégration dans une PKI rend le déploiement de OpenSSH à grande échelle difficile.
OpenVPN
OpenVPN est le fer de lance de la catégorie des VPN "SSL". Ce genre de VPNs utilise mécanismes du chiffrement SSL/TLS pour authentifier et chiffrer les connexions. OpenVPN se base sur OpenSSL, principale implémentation libre du protocole SSL/TLS, tant en terme de qualité que d'adoption, et s'appuie sur des routines de chiffrement et de vérification d'identité pour assurer une très bonne sécurisation des données. L'utilisation d'OpenVPN requiert une PKI X509, comme tout systèmes basé sur SSL/TLS. L'avantage est de pouvoir réutiliser une PKI existante, le certificat personnel d'un utilisateur lui permettant de s'authentifier auprès du VPN.
Principe
OpenVPN est une solution très complète qui propose plusieurs modes de fonctionnement, d'encapsulation et d'authentification. Son point fort est sa capacité à fonctionner presque sans configuration à partir du moment où l'on possède une PKI. Cela le rend très attractif pour la mise en place d'une solution dans le cadre d'une solution de connexion à distance pour les employés d'une entreprise.
Poste à réseau
Les avantages de OpenVPN en mode poste à réseau sont multiples :
- Intégration immédiate dans une PKI x509
- Ne nécessite qu'un flux réseau sur le port 1194 (TCP ou UDP); les clients peuvent donc se trouver derrière un NAT.
- Possibilité de traverser les proxies HTTPS, par exemple pour une utilisation depuis un réseau d'entreprise.
- Possibilité de configurer le serveur pour tester la validité des certificats selon n'importe quel critère (LDAP, AD, RADIUS, etc)
- Disponible sous Windows, MAC, UNIX
Réseau à réseau
OpenVPN peut également s'adapter à ce genre de configurations.
OpenVPN est particulièrement adapté aux configurations poste à réseau, mais il est également utilisable en interconnexion de réseaux.
Dans ce cas de figure, son principal problème est sa dissymétrie, comme évoqué en début de ce livre blanc : il est indispensable de désigner une machine « cliente » et une machine « serveur » ce qui n’a pas vraiment de sens dans une interconnexion un pour un. Cette dissymétrie se retrouve aussi bien au niveau de la connexion proprement dire (si TCP est utilisé) que au niveau de l’authentification (le serveur vérifie l’identité du client). De plus l’administration est considérablement alourdie car il est nécessaire d’écrire un fichier de configuration par serveur distant sur chaque nœud, et d’ouvrir un port du firewall pour chaque connexion côté serveur. Par exemple pour interconnecter complètement 6 nœuds il y a 15 connexions, donc 15 ouvertures de port à faire, et ainsi de suite.
OpenVPN en mode réseau à réseau n’est donc adapté qu’à de petites infrastructures, et on lui préférera IPsec dès que le nombre de réseaux à interconnecter dépassera 4 ou 5.
IPSec
Introduction
Les VPN de type IPSec n'utilisent pas SSL, mais des protocoles de niveau 3 : ESP et AH.
ESP est un protocole assurant la confidentialité et l'intégrité des trames. Il est plus utilisé que AH qui, lui, n'assure pas l'intégrité du niveau 3, ce qui permet de l'utiliser dans des situation de type NAT (où le niveau 3 du paquet est modifié pendant le trajet). En pratique, la plupart des solutions IPSec en mode client à réseau implémentent le NAT-T (traversée de NAT), qui encapsule le trafic ESP dans des datagrammes UDP, leur permettant ainsi de traverser les passerelles réseau.
Il existe deux modes d'utilisation d'IPSec : le mode transport, et le mode tunnel.
Le mode transport ne nous intéresse pas trop : il permet simplement de chiffrer le trafic entre deux machines à partir du niveau 4. Ce mode est donc idéal quand le routage est fait en amont et que les échanges réseau ont lieu sur un canal de communication non sécurisé. Une utilisation typique de ce mode est la protection d'un réseau WiFi, ou d'un VPN MPLS. Voici le fonctionnement du mode transport :
- Un paquet a été routé à destination d'une machine protégée par IPSec
- Les données (Niveau 4) sont chiffrées et encapsulées dans un paquet ESP
- Celui-ci est envoyé à la destination
- La destination reçoit le paquet en provenance d'une source protégée par IPSec
- La destination déchiffre le paquet et le traite.
L'autre mode d'IPSec est le mode tunnel : il permet d'encapsuler toute une trame à partir du niveau 3. Chaque tunnel possède une adresse "de sortie", vers laquelle est envoyé l'ensemble du trafic. Voici le fonctionnement détaillé de ce mode :
- Un paquet arrive à l'entrée du tunnel, à destination du réseau de sortie
- La destination et les données (niveau 3) du paquet sont chiffrés et encapsulés dans un nouveau paquet ESP
- Ce paquet est chiffré et envoyé à l'autre extrémité du tunnel
- Cette dernière reçoit le paquet en provenance de l'entrée du tunnel IPSec
- La sortie du tunnel déchiffre le paquet et l'envoie à sa destination d'origine
On voit bien que le mode tunnel permet de "coller" virtuellement deux réseaux disjoints, alors que le mode transport ne permet que d'assurer la sécurité des données remises. On est bien dans un cas de réseau privé virtuel. Il existe un préjugé selon lequel IPSec n'est qu'un protocole de VPN; en réalité, il s'agit simplement d'un protocole de sécurisation des échanges; cependant, il permet, dans un de ses modes, de créer un VPN.
Généralités
IPsec est un protocole complexe, qui nécessite l’utilisation de multiples secrets cryptographiques dont la configuration est bien trop lourde pour être gérée facilement par un administrateur : il faudrait qu’il intervienne à chaque établissement de session. C’est pourquoi on utilise généralement un troisième protocole, IKE, pour automatiser une grande partie de la négociation. IKE permet de négocier l’établissement de tous les paramètres du tunnel en se basant sur :
- Un mot de passe partagé
- Un certificat x509
- Une clef publique (similaire à SSH)
- D'autres critères selon les implémentations (mdp, etc)
IPSec possède quelques sérieux avantages comparé aux autres solutions présentées ici :
- Le protocole est un standard industriel, il est implémenté dans de nombreux équipements réseaux de différentes constructeurs. Le choix de IPsec est donc un gage d’interopérabilité y compris avec des solutions propriétaires.
- Le protocole est mature et très répandu, ses implémentations sont éprouvées.
- En termes réseau, le protocole fonctionne sur un port bien défini quel que soit le nombre de clients, il suffit donc d'ouvrir le firewall une seule fois pour supporter tous les futurs tunnels. IPSec se prête bien à de gros équipements centraux comportant des centaines de tunnels.
...cela dit :
- La configuration est complexe, même avec IKE
- Au sein d’une même implémentation, la configuration est souvent simplifiée. En revanche dès que l’on souhaite se connecter à une implémentation différente il faut configurer tous les paramètres explicitement.
- Certaines implémentations proposent des fonctionnalités avancées qui ne sont pas disponibles dans d’autres (notamment pour l’authentification).
MPLS
MultiProtocol Label Switching
Dans les réseaux informatiques et les télécoms, MPLS est un mécanisme de transport de données basé sur la commutation d'étiquettes (ou Labels) qui sont insérés à l'entrée du réseau MPLS et retirés à la sortie. À l'origine, cette insertion s'opère entre les couches 2 et 3 afin de transporter des protocoles comme IP. C'est pourquoi PLS est qualifié de protocole de couche "2,5".
Ce protocole a évolué pour fournir un service unifié de transport de données pour les clients en utilisant une technique de commutation de paquets. MPLS peut être utilisé pour transporter pratiquement tout type de trafic, par exemple la voix ou des paquets IPv4, IPv6 et même des trames Ethernet ou ATM. Il permet d’acheminer sur une unique infrastructure différents types de trafic tout en respectant les contraintes de fonctionnement associées.
https://www.youtube.com/watch?v=U1w-b9GIt0k
https://www.youtube.com/watch?v=4QGRLgIq8iA
Pour résumer rapidement, on peut dire que MPLS permet de faire de la commutation de paquets grâce à des lables (représentés par des numéros), plutôt que par du routage IP classique. Cela permet de faire abstraction de la couche IP et de gagner en souplesse et en performance.
Une grande tendance au début des années 2000 en matière de VPN a consisté à utiliser des réseaux MPLS. Sa souplesse autorise l'utilisation de fonctionnalités au niveau trames et paquets.
MPLS met en place des tunnels, appellés LSP (Label Switching Path) qui ne sont que des circuits virtuels et offrent en outre une qualité de service. Les VPN MPLS sont plutôt mis en place par des opérateurs (FAIs) que par des clients. Par défaut, ils ne mettent pas de chiffrement en oeuvre, c'est pourquoi il peut être intéressant de mettre IPSec en oeuvre par dessus afin de sécuriser les échanges.
Outils d'administration
Comme pour les firewalls, il existe des outils intégrés permettant de mettre en oeuvre plus facilement des VPN. La plupart des distribution Firewall, comme IPCop ou PfSense, proposent une interface pour la mise en palce de VPN via plusieurs protocoles, le plus souvent OpenVPN et IPSec. Ces outils facilitent l'administration au quotidien et facilitent la mise en place d'un VPN pour un administrateur qui ne connaît pas toutes les subtilités d'un protocole comme IPSec. Cela dit, pour les gros sites comportant des centaines de tunnels, l'utilisation de scripts ou de macros pour générer les configurations s'avèreras souvent plus efficace qu'un interface cliquable.
Exemples d'architectures
PME
Le premier exemple sera une petite entreprise disposant d’une seule implantation. L’entreprise a externalisé une partie de ses ressources informatiques dans un datacenter, mais n’a pas les moyens d’un lien d’interconnexion dédié. De plus, l’entreprise souhaite permettre à certains de ses employés de travailler à distance.
Voici le schéma de la situation :
Côté hébergeur, le seul équipement de routage disponible est un routeur Cisco, compatible IPsec. Côté local, l’entreprise utilise une passerelle Linux servant de routeur et pare-feu. Le choix de IPsec pour l’interconnexion entre les deux réseaux est donc naturel. Cependant, il aurait été possible d’utiliser un des serveurs hébergés pour servir de passerelle pour une autre solution de VPN, telle que OpenVPN. Mais cette solution compliquerait légèrement le routage.
Pour la connexion des employés mobiles au réseau, il est également possible d’utiliser un client Cisco pour se connecter directement à la plate-forme hébergée, et mettre en place une deuxième solution de VPN pour la connexion au réseau interne.
Cependant, pour une plus grande souplesse, l’entreprise a choisi OpenVPN, et ce pour plusieurs raisons :
- Les employés n'ont qu'un logiciel client à gérer
- OpenVPN permet une gestion fine des droits d'accès en consultant l'annuaire de l'entreprise
- OpenVPN permet de router le trafic aussi bien vers le réseau interne que vers le réseau hébergé à travers le tunnel IPSec d'interconnexion.
Cette solution présente quelques inconvénients :
- Elle est dépendante de l'état de la connexion de l'entreprise à Internet
- Si le client accède à la plateforme hébergée, les trames réseau font un aller retour entre internet et le routeur, ce qui est consommateur de bande passante.
Voici la solution finale :
Cette solution nous permet de constater deux choses :
- Elle montre qu’on peut mettre en place, sur le même équipement, des fonctions de filtrage, de routage et de VPN. C’est un cas relativement classique surtout dans les petites entreprises où une seule machine fait office de passerelle. Des produits intégrés comme IPCop ou pfSense se prêtent très bien à ce rôle.
- Elle montre que deux technologies de VPN peuvent cohabiter sur une même machine.
Toutes les solutions de VPN ne sont pas cumulables par nature sur un même équipement. Selon que l'encapsulation est effectuée à telle ou telle étape du traitement des trames, il peut y avoir des conflits. Dans la pratique, les solutions essayent de limiter leur impact et de se reposer sur des infrastructures standard (interfaces virtuelles, routage...). En pratique, OpenVPN et IPSec peuvent cohabiter sur une même machine, cela dit le routage des trames en provenance d'OpenVPN vers IPSec demande une configuration subtile.
Grandes entreprises
Dans ce deuxième exemple, on s’intéresse à une entreprise plus importante possédant :
- Un siège hébergeant des applications métier.
- Plusieurs agences, dont certaines hébergent leurs propres applications.
- Une filiale à l’étranger qui ne permet pas la mise en place d’un lien réseau dédié.
- Des employés en déplacement ou en télétravail susceptibles de se connecter au réseau (leur poste, les applications, etc.).
- Un prestataire qui assure la maintenance de certaines applications.
- Un réseau Wifi au siège, pour les visiteurs et les employés en réunion.
La mise en place de différents VPN permet de répondre aux besoins suivants :
- VPN 1 : Interconnecter les réseaux d’agence en garantissant la sécurité des transmissions.
- VPN 2 : Connecter la filiale au réseau à travers Internet
- VPN 3 : Permettre aux employés de se connecter au réseau
- VPN 4 : Permettre au prestataire de se connecter aux serveurs dont il a la charge
- VPN 5 : Permettre aux utilisateurs du Wifi de se connecter aux applications internes de façon sécurisée.
Chacun de ces VPN a des objectifs différents :
| Authentification | Confidentialité | Accès LAN | |
| 1 | x | ||
| 2 | x | x | |
| 3 | x | x | x |
| 4 | x | x | |
| 5 | x | x |
La solution retenue :
On peut à présent évoquer les détails :
VPN 1 : Interconnexion d’agences sur un lien dédié
Il s’agit plus d’un cas d’école que d’un réel besoin, la présence d’un lien dédié permet d’éliminer la plupart des problèmes d’interconnexion, en particulier de routage, que l’on peut rencontrer habituellement sur Internet.
Cependant, par sécurité, il est préférable de protéger par un VPN les données qui circulent entre les filiales, afin d’être certain que les échanges ne sont pas espionnés ou pire, altérés, par une personne s’étant introduite dans un local technique avec un analyseur de trames par exemple.
Le besoin est donc relativement facile à satisfaire, il s’agit d’un candidat désigné pour IPsec en mode transport : pas de modification des adresses réseau puisqu’on reste sur le réseau privé de l’entreprise, et pas de problématique d’authentification complexe.
VPN 2 : Interconnexion d’agences via Internet
Il s’agit cette fois d’un cas courant : la protection des données circulant sur Internet est une nécessité, et il est indispensable d’utiliser de l’encapsulation de paquets pour pouvoir router entre deux réseaux privés.
Ici encore, le choix est rapide : IPsec en mode tunnel est tout désigné. De plus l’interopérabilité de IPsec fait que si la filiale provient d’un rachat, les chances de s’interconnecter facilement avec les équipements existants sont très élevées.
VPN 3 : Connexion des employés mobiles
Comme nous l’avons déjà évoqué, ce type de VPN est assez différent des deux premiers : en effet les clients n’ont pas d’IP fixe, et souhaitent seulement accéder à des ressources et non rendre leurs propres ressources accessibles. D’autre part, il doit être possible d’authentifier chaque connexion bien qu’elles proviennent d’IP inconnues à l’avance, et il faut pouvoir anticiper les problèmes tels que le vol de matériel.
OpenVPN permet de répondre à ces besoins, en s’intégrant facilement dans la PKI de l’entreprise (ou en fournissant les outils pour créer une PKI s’il n’en existe pas), et en permettant une authentification forte : le client devra d’une part posséder un certificat valide, et d’autre part fournir son login et son mot de passe au moment de la connexion pour être accepté. De plus, des contrôles au niveau de l’annuaire permettront de restreindre l’accès aux membres d’un groupe prédéterminé.
Tous ces mécanismes sont présents dans OpenVPN et ne demandent que très peu de configuration : il suffit d’écrire quelques courts scripts pour mettre en place les contrôles côté serveur. Cette architecture permet de changer facilement le mode d’authentification en fonction des besoins, par exemple en cas de changement d’annuaire, ou si l’on souhaite intégrer la notion de plage horaire.
Cette solution présente cependant un inconvénient : OpenVPN nécessite un logiciel installé sur les postes client (il est cependant multi-plateformes et léger), et n’est équipements tels que les PDA.
VPN 4 : Connexion temporaire avec un prestataire de services
Ce cas est similaire au VPN 3 : on souhaite permettre l’accès à des ressources internes depuis l’extérieur. La courte durée de vie de cet accès, et la relation entre les deux intervenants font qu’un système client-serveur est adapté. On a choisi OpenVPN car la configuration réseau est plus simple : il n’y a qu’un port à ouvrir en entrée pour l’entreprise, et un port à ouvrir en sortie pour le prestataire. De plus le prestataire peut garder son certificat X.509 et le réutiliser pour une future intervention sur un autre serveur.
On notera qu’un tunnel SSH est parfois suffisant pour ce type d’utilisation, et partage les avantages de OpenVPN en termes de facilité de mise en place, mais est plus compliqué à manipuler pour le prestataire.
VPN 5 : Wifi sécurisé
On oublie trop souvent que les réseaux Wifi sont par nature très difficiles à sécuriser : l’ensemble du trafic peut être intercepté par n’importe quelle station, et les protocoles de sécurité les plus répandus (WEP et WAP) souffrent de failles qui les rendent pratiquement inutiles et créent l’illusion de la sécurité. Les protocoles de sécurisation plus sérieux, comme WPA-Entreprise sont pour leur part difficiles à mettre en place.
Un VPN permet de protéger efficacement le trafic sur un réseau Wifi. Il s’agit d’une méthode alternative peu employée mais très robuste. En effet alors que les solutions telles que WEP tentent de sécuriser les couches inférieures de la transmission (1 et 2), un VPN se place légèrement plus haut (généralement la couche 3 voire 4 pour IPsec en mode transport). De plus, au plan cryptographique, les algorithmes des VPN sont beaucoup plus fiables et la phase d’authentification, qui est le talon d’Achille de la sécurité Wifi, est beaucoup plus sûre.
Ce cas de figure reprend donc à l’identique les principes du VPN 3, à la différence que le réseau intermédiaire n’est plus Internet mais le réseau Wifi de l’entreprise, et que le point de sortie du VPN n’est plus au cœur du réseau mais limité aux serveurs d’application.
On notera que cette solution est celle utilisée dans certaines salons sur la sécurité informatique pour protéger les réseaux Wifi contre la curiosité des participants.
Mise en place d'OpenVPN
Mon serveur OpenVPN se trouve sur une debian 9. Rien de spécial.
Doc :
https://community.openvpn.net/openvpn/wiki/HOWTO
Installation
sudo apt install openvpn
Configuration
Copie des fichiers nécessaires
Par défaut, les fichiers dont on a besoin sont éparpillés aux quatre vents tels des petites feuilles de printemps :3
Je vais recopier le nécessaire dans /etc/openvpn :
cp -r /usr/share/easy-rsa /etc/openvpn/
cp -r /usr/share/doc/openvpn/examples/sample-config-files /etc/openvpn
-
- Ce dossier "examples" contient un ensemble de fichiers d'exemple, il est plutôt utile.
easy-rsa
On va utiliser easy-rsa pour générer une CA, des clefs serv, et des clefs client. Easy-rsa est un ensemble de scripts, normalement installé en même temps qu'OpenVPN. La doc oublie ici quelques subtilités.
cd /etc/openvpn/easy-rsa
- Ouvrir le fichier vars avec un éditeur de texte, et adapter les points suivants :
- KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, KEY_EMAIL
- Enregistrer, quitter.
- Le dossier contient divers fichier nommés openssl-<version>. Il n'as pas la version 1.1.0 (actuelle), du coup je prend celui pour la version 1.0 :
cp openssl-1.0.0.cnf openssl.cnf
-
. ./vars
-
./clean-all
-
./build-ca
-
- La dernière commande construit le CA. Aucune commande ne doit renvoyer un message d'erreur. Les clefs générées vont dans dossier "keys" de easy-rsa.
- On va créer nos clefs :
./build-key-server server
-
-
- On peut laisser la plupart des paramètres en défaut. Il faut, pour toutes les clefs, s'assurer du Common Name (server pour le serveur, client1, etc) et dire oui à "Sign the certificate?" et "1 out of 1 certificate requests certified, commit? [y/n]".
- On fait la même pour les clients : ./build-key client1
./build-key client2
-
-
- etc.
- On peut mettre des mdp sur les clefs en utilisant à la place build-key-pass
- On génère les paramètre Diffie-Hellman :
./build-dh
-
- Attention, c'est long et ça demande beaucoup au processeur.
On a désormais toutes nos clefs dans le dossier keys :
| Filename | Needed By | Purpose | Secret |
| ca.crt | server + all clients | Root CA certificate | NO |
| ca.key | key signing machine only | Root CA key | YES |
| dh{n}.pem | server only | Diffie Hellman parameters | NO |
| server.crt | server only | Server Certificate | NO |
| server.key | server only | Server Key | YES |
| client1.crt | client1 only | Client1 Certificate | NO |
| client1.key | client1 only | Client1 Key | YES |
| client2.crt | client2 only | Client2 Certificate | NO |
| client2.key | client2 only | Client2 Key | YES |
| client3.crt | client3 only | Client3 Certificate | NO |
| client3.key | client3 only | Client3 Key | YES |
La dernière étape est de copier les clefs vers les machines qui en ont besoin de façon sécurisée. Bien sûr, on aurait pu faire notre PKI nous-même, ce qui aurait permis aux client de faire sa clef lui-même et de la faire signer avec une CSR. Mais bon, c'est plus rapide comme ça.
Fichier Serveur
Pour rappel, on a récupéré des fichiers d'exemples; ils contiennent entre autre un fichier d'exemple serveur nommé server.conf.gz. Il est possible de le copier dans le dossier server et de le modifier. Je vais pour ma part m'en inspirer et faire le fichier moi-même, qui contient les éléments suivants :
###Configuration de mon serveur OpenVPN #/etc/openvpn/server/monserveur.conf #Commentaire ;Commentaire ### #Ce fichier est un premier jet et est inspiré du fichier par défaut fourni par OpenVPN #Dans le doute, il est recommandé d'utiliser le fichier par défaut ### #Port d'écoute classique port 1194 #Utilisation d'UDP proto udp #Creation d'une interface de type tunnel (IP) #On pourrait aussi faire une interface type bridge ethernet, mais ce n'est pas le cas ici dev tun ###Certificats #Certificats générés grâce à easy-rsa #On a notre propre PKI #CA : Le certificat de mon autorité ca /etc/openvpn/server/servkeys/ca.crt #Cert : le certif de mon serveur (public) cert /etc/openvpn/server/servkeys/server.crt #Clef : la clef privée de mon serv (secret) key /etc/openvpn/server/servkeys/server.key #Diffie-Hellman : On a généré des paramètres DH dh /etc/openvpn/server/servkeys/dh2048.pem #Réseau IP : On configure ici le réseau privé utilisé par nos clients #Ce doit être un réseau privé avec une @ rzo inutilisée dans notre LAN #Le server prend la première adresse (ici 10.0.8.1), les clients ont les autres adresses server 10.8.0.0 255.255.255.0 #On garde un enregistrement des client <-> IP virtuelles; #Si le serveur redémarre les clients récupèreront leur adresse. ifconfig-pool-persist ipp.txt #On peut transmettre des routes vers des réseaux privés situés derrière le VPN #Aux clients. Attention, ces réseaux privés devront savoir comment répondre aux clients #(Ils auront besoin de connaître la route vers eux). ;push "route 192.168.10.0 255.255.255.0" #On peut décommenter la directive ci-dessous pour autoriser les clients à parler entre eux ;client-to-client #On peut décommenter la directive ci-dessous pour que les clients puissent tous utiliser le même certif. #Ce n'est pas sécurisé, chaque client devrait avoir un certif contenant son propre common name. ;duplicate-cn #La directive suivante envoie des messages types ping pour s'assurer que chaque côté de la connexion est bien vivant. #Ici, ping toutes les 10 secondes, et on suppose que l'autre est mort au bout de 120 secondes. keepalive 10 120 #On peut améliorer la sécurité avec un HMAC firewall, qui aide contre les DDOS et les UDP port flooding. #La clef est à générer avec : #openvpn --genkey --secret ta.key #Le serveur et le client doivent avoir une copie de la clef. #Le second paramètre doit être 0 sur le serveur et 1 sur le client. tls-auth /etc/openvpn/server/servkeys/ta.key 0 #Ce fichier est secret #On choisit un algorithme de chiffrement. #La configuration client doit contenir la même chose. #Le client/server en version 2.4 négociera automatiquement en AES-256-GCM avec TLS. #Voir ncp-cipher dans le man. cipher AES-256-CBC #On peut avoir de la compression à partir d'OpenVPN 2.4 (avant ça, c'est une autre option que je ne détaillerais pas ici) #On "push" l'option au client ;compress lz4-v2 ;push "compress lz4-v2" #Nombre max de clients max-clients 100 #À utiliser sur les systèmes non-Windows pour réduire les droits de l'utilisateur système OpenVPN user nobody group nogroup #L'option persist essaye d'éviter l'accès à des ressources innaccessibles après un restart persist-key persist-tun #Génère un petit log toutes les minutes montrant l'état des connexions actuelles status openvpn-status.log # By default, log messages will go to the syslog (or # on Windows, if running as a service, they will go to # the "\Program Files\OpenVPN\log" directory). # Use log or log-append to override thi s default. # "log" will truncate the log file on OpenVPN startup, # while "log-append" will append to it. Use one # or the other (but not both). ;log openvpn.log ;log-append openvpn.log # Set the appropriate level of log # file verbosity. # # 0 is silent, except for fatal errors # 4 is reasonable for general usage # 5 and 6 can help to debug connection problems # 9 is extremely verbose verb 3 #Signaler au client si le serveur redémarre pour qu'il se reconnecte automatiquement explicit-exit-notify
Avant de le tester, je vais recopier les clefs nécessaires dans le dossier approprié :
mkdir /etc/openvpn/server/servkeys
cd /etc/openvpn/easy-rsa/keys
cp server.* dh2048.pem ca.crt ../server/servkeys/
cd ../server/servkeys
openvpn --genkey --secret ta.key
Je vais ensuite pouvoir le tester en mode debug, juste pour voir si tout se passe bien. Pour le moment, je n'ai pas de client, et je n'ai même pas encore vérifié le pare-feu; il s'agit juste de tester les fichier de configuration. Je lance la commande suivante depuis le dossier server :
openvpn monserveur.cfg
Je ne dois pas avoir de messages d'erreur.
Configuration client
Je vais ensuite passer au fichier de configuration client. Encore une fois, je pars du fichier d'exemple fourni par OpenVPN. Celui-ci ne varie pas trop, par rapport au fichier serveur.
#Fichier client pour OpenVPN : monclient.conf #On spécifie le rôle client #Mode tunnel ;dev tap dev tun #On utilise UDP proto udp #Adresse du serveur suivie du port #On peut en avoir plusieurs pour du load balancing remote 192.168.1.16 1194 ;remote my-server-2 1194 #Utile si load balancing ;remote-random #Tant que l'on est pas connecté au serveur, on essaye de s'y connecter resolv-retry infinite # La plupart des clients n'ont pas besoin de s'atatcher à un port en particulier nobind # On enlève les droits système après initialisation (Non-Windows uniquement) user nobody group nogroup #On persiste sur certains paramètres après un restart persist-key persist-tun #Utile si on passe par un proxy ;http-proxy-retry # retry on connection failures ;http-proxy [proxy server] [proxy port #] #Utile sur les réseaux WiFi qui dupliquent les paquets ;mute-replay-warnings #Certificat de l'autorité, certificat et clef client (chemin relatif ou absolu) ca ca.crt cert client1.crt key client1.key # Verify server certificate by checking that the # certicate has the correct key usage set. # This is an important precaution to protect against # a potential attack discussed here: # http://openvpn.net/howto.html#mitm # # To use this feature, you will need to generate # your server certificates with the keyUsage set to # digitalSignature, keyEncipherment # and the extendedKeyUsage to # serverAuth # EasyRSA can do this for you. remote-cert-tls server #Clef TLS (commune au client et au serveur) tls-auth ta.key 1 #Choix de l'algorithme cipher AES-256-CBC #Ici, pas de compression #comp-lzo # verbosité verb 3 # Couper les messages répétitifs ;mute 20
Tests
Une fois cela fait, je peux copier mon fichier client ainsi que les clefs appropriées sur un client. Ensuite, je démarre le serveur puis le client :
- openvpn monserveur.conf
- openvpn monclient.conf
Si les deux renvoie "Initialization Sequence complete", c'est bon.
Pour Le serveur démarré automatiquement :
If you install OpenVPN via an RPM or DEB package on Linux, the installer will set up an initscript. When executed, the initscript will scan for .conf configuration files in /etc/openvpn, and if found, will start up a separate OpenVPN daemon for each file.
Ce serait bien si c'était vrai, mais ça ne l'est pas. Il faut d'abord faire ceci sur le server:
sudo vim /etc/default/openvpn #Décommenter : AUTOSTART="all" systemctl daemon-reload systemctl restart openvpn
Après ça, les fichiers de configuration présents dans /etc/openvpn seront lancés.
Et pour charger simplement un fichier client :
openvpn --config fichier.ovpn
Authentification du client non pas par clef, mais par mdp
Pour utiliser ce mode d'authentification, la différence n'est pas énorme. Le serveur doit garder ses clefs pour établir le tunnel, dans tous les cas. Le client, lui, n'en a plus besoin. Il y'a quelques changements :
- Fichier serveur, je rajoute à la fin :
#Utilisation du plugin auth-pam pour identifier les clients plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so login #On ne demande pas de certificat au client client-cert-not-required #Pour des raison d'indexation... username-as-common-name
Par défaut, le plugin authentifie les utilisateurs sur le fichier shadow (les utilisateurs Linux, en somme). Apparement, on peut le brancher sur un LDAP ou un RADIUS, mais ce n'est pas l'objet ici. La directive "client-cert-not-required" est requise, sans quoi on passerais sur de la 2FA (login + clef).
- Côté client, on a un peu plus de changements :
Je commence par virer les clefs client, qui ne servent plus à rien :
#Certificat de l'autorité, certificat et clef client ca ca.crt #cert client1.crt #key client1.key
Et je rajoute la ligne suivante :
#Le client s'authentifie par login/mdp auth-user-pass
Je peux ensuite refaire mes tests. Dans la configuration actuelle, le client aura besoin pour se connecter de :
- Son fichier de configuration client
- Le CA du serveur
- La clef commune TLS (ta.key), que je peux éventuellement enlever des deux fichiers de configuration.
MA CONFIG AU FINAL
Rien de plus côté clefs. Je mets ma configuration finale qui fonctionne ici :
Serveur :
###Configuration de mon serveur OpenVPN #/etc/openvpn/server/monserveur.conf #Commentaire ;Commentaire ### #Ce fichier est un premier jet et est inspiré du fichier par défaut fourni par OpenVPN #Dans le doute, il est recommandé d'utiliser le fichier par défaut ### #Port d'écoute classique port 1194 #Utilisation d'UDP proto udp #Creation d'une interface de type tunnel (IP) #On pourrait aussi faire une interface type bridge ethernet, mais ce n'est pas le cas ici dev tun ###Options réseau push "dhcp-option DNS 1.1.1.1" push "dhcp-option DNS 8.8.8.8" push "redirect-gateway def1 bypass-dhcp" #Serveur en tant que gateway push "remote-gateway 10.8.0.1" ###Certificats #Certificats générés grâce à easy-rsa #On a notre propre PKI #CA : Le certificat de mon autorité ca /etc/openvpn/server/servkeys/ca.crt #Cert : le certif de mon serveur (public) cert /etc/openvpn/server/servkeys/server.crt #Clef : la clef privée de mon serv (secret) key /etc/openvpn/server/servkeys/server.key #Diffie-Hellman : On a généré des paramètres DH dh /etc/openvpn/server/servkeys/dh2048.pem #Réseau IP : On configure ici le réseau privé utilisé par nos clients #Ce doit être un réseau privé avec une @ rzo inutilisée dans notre LAN #Le server prend la première adresse (ici 10.0.8.1), les clients ont les autres adresses server 10.8.0.0 255.255.255.0 #On garde un enregistrement des client <-> IP virtuelles; #Si le serveur redémarre les clients récupèreront leur adresse. ifconfig-pool-persist ipp.txt #On peut transmettre des routes vers des réseaux privés situés derrière le VPN #Aux clients. Attention, ces réseaux privés devront savoir comment répondre aux clients #(Ils auront besoin de connaître la route vers eux). ;push "route 192.168.10.0 255.255.255.0" #On peut décommenter la directive ci-dessous pour autoriser les clients à parler entre eux ;client-to-client #On peut décommenter la directive ci-dessous pour que les clients puissent tous utiliser le même certif. #Ce n'est pas sécurisé, chaque client devrait avoir un certif contenant son propre common name. ;duplicate-cn #La directive suivante envoie des messages types ping pour s'assurer que chaque côté de la connexion est bien vivant. #Ici, ping toutes les 10 secondes, et on suppose que l'autre est mort au bout de 120 secondes. keepalive 10 120 #On peut améliorer la sécurité avec un HMAC firewall, qui aide contre les DDOS et les UDP port flooding. #La clef est à générer avec : #openvpn --genkey --secret ta.key #Le serveur et le client doivent avoir une copie de la clef. #Le second paramètre doit être 0 sur le serveur et 1 sur le client. #tls-auth /etc/openvpn/server/servkeys/ta.key 0 #Ce fichier est secret #On choisit un algorithme de chiffrement. #La configuration client doit contenir la même chose. #Le client/server en version 2.4 négociera automatiquement en AES-256-GCM avec TLS. #Voir ncp-cipher dans le man. cipher AES-256-CBC #On peut avoir de la compression à partir d'OpenVPN 2.4 (avant ça, c'est une autre option que je ne détaillerais pas ici) #On "push" l'option au client ;compress lz4-v2 ;push "compress lz4-v2" #Nombre max de clients max-clients 100 #À utiliser sur les systèmes non-Windows pour réduire les droits de l'utilisateur système OpenVPN user nobody group nogroup #L'option persist essaye d'éviter l'accès à des ressources innaccessibles après un restart persist-key persist-tun #Génère un petit log toutes les minutes montrant l'état des connexions actuelles status openvpn-status.log # By default, log messages will go to the syslog (or # on Windows, if running as a service, they will go to # the "\Program Files\OpenVPN\log" directory). # Use log or log-append to override thi # "log" will truncate the log file on OpenVPN startup, # while "log-append" will append to it. Use one # or the other (but not both). ;log openvpn.log ;log-append openvpn.log # Set the appropriate level of log # file verbosity. # # 0 is silent, except for fatal errors # 4 is reasonable for general usage # 5 and 6 can help to debug connection problems # 9 is extremely verbose verb 3 #Signaler au client si le serveur redémarre pour qu'il se reconnecte automatiquement explicit-exit-notify #AUTH # plugin /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so login client-cert-not-required username-as-common-name
Client :
#Fichier client pour OpenVPN : monclient.conf #LOGIN : justine #MOT DE PASSE : Prevert77 #On spécifie le rôle client #Mode tunnel ;dev tap dev tun #On utilise UDP proto udp #Adresse du serveur suivie du port #On peut en avoir plusieurs pour du load balancing remote 54.164.115.189 ;remote my-server-2 1194 #Utile si load balancing ;remote-random #Tant que l'on est pas connecté au serveur, on essaye de s'y connecter resolv-retry infinite # La plupart des clients n'ont pas besoin de s'atatcher à un port en particulier nobind # On enlève les droits système après initialisation (Non-Windows uniquement) user nobody group nogroup #On persiste sur certains paramètres après un restart persist-key persist-tun #Utile si on passe par un proxy ;http-proxy-retry # retry on connection failures ;http-proxy [proxy server] [proxy port #] #Utile sur les réseaux WiFi qui dupliquent les paquets ;mute-replay-warnings #Certificat de l'autorité, certificat et clef client (chemin relatif ou absolu) ca ca.crt #cert client1.crt #key client1.key # Verify server certificate by checking that the # certicate has the correct key usage set. # This is an important precaution to protect against # a potential attack discussed here: # http://openvpn.net/howto.html#mitm # # To use this feature, you will need to generate # your server certificates with the keyUsage set to # digitalSignature, keyEncipherment # and the extendedKeyUsage to # serverAuth # EasyRSA can do this for you. remote-cert-tls server #Clef TLS (commune au client et au serveur) #tls-auth ta.key 1 #Choix de l'algorithme cipher AES-256-CBC #Ici, pas de compression #comp-lzo # verbosité verb 3 # Couper les messages répétitifs mute 20 #Auth par login/mdp auth-user-pass
NE PAS OUBLIER :
Le routage sur le serveur :
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE