Déploiement de Proxmox VE 5 sur un serveur dédié – part 3

Posted by

Cet article fait partie d’une suite de 3 articles sur la mise en place de Proxmox VE et sa sécurisation et dont voici les adresses :

Nous avons donc à présent une belle infrastructure à disposition avec une VM PFSense en frontal et un niveau de sécurité relativement correct. Nous allons donc terminer par :

  • La configuration d’un accès distant sécurisé grâce à OpenVPN
  • L’adaptation des règles de filtrage pour que cela fonctionne

Mais avant cela, je vais juste faire un léger aparté pour vous montrer comment autoriser l’accès extérieur à un service d’une machine virtuelle.

Comme pour les parties précédentes, si des paramètres ne sont pas explicités, ils sont à laisser à leur valeur par défaut.

Publication de services sur l’internet du web

Imaginons que vous ayez quelques VMs qui vous fournissent des services de « Prod », et que pour des raisons qui vous sont propres, vous souhaitiez pouvoir y accéder sans passer par votre futur VPN … « Comment faire ? » me demanderiez-vous. « Et bien, vous répondrais-je … C’est très simple mon cher ami, grâce à notre magnifique infrastructure, l’ajout d’UNE SEULE règle suffira ! » (mouahaha)

Donc prenons le cas d’un serveur PLEX , au hasard, hébergé sur un NAS Synology virtualisé … son @IP est 192.168.9.10 et son port d’écoute est, par défaut, le TCP:32400.

  • Se rendre dans le menu Firewall > NAT puis cliquer sur « ADD«

Interface : WAN
Protocol : TCP
Destination : Any
Destination Port Range (From) : Other – 32400
Redirect target IP : 192.168.9.10
Redirect target port : Other – 32400
Description : Choisir un nom pour la règle (ex: Synology – Plex)

  • Valider avec « Save » puis « Apply Changes » pour recharger la configuration

Voilà, c’est tout !

Vous avez crée une règle de NAT qui renvoie toutes les requêtes arrivant sur le port TCP:32400 de votre interface WAN vers le port TCP:32400 de votre Plex ! Cerise sur le gâteau, vu que PFSense est bien conçu (et que vous n’avez pas modifié le paramètre « Filter rule association ») il vous a généré une règle de FW associée pour autoriser le flux de votre règle NAT.

Comme tous les services publiés sur votre IP public constituent des vecteurs potentiels d’attaque on va y allez « molo sur la mayo » (… vous connaissez cette expression ? Je crois que je viens de l’inventer … truc de fou … une fulgurance … Non sérieux quelqu’un connait ? … Euh oui pardon … ). Je disais donc que nous privilégierons évidemment un accès via le VPN que nous allons mettre en place …. genre maintenant, tout de suite.

Configuration d’accès distant sécurisé via OpenVPN

Je ne vais pas vous détailler l’action de chaque option, et je ne les connais pas toutes d’ailleurs, par contre si vous êtes intéressé, je vous encourage fortement à vous référer à ces sources :

Création de l’autorité de certification

  • Naviguer jusqu’à la liste des « CAs » via le menu System > Cert Manager :

Celle-ci est vide, nous allons donc créer une nouvelle entrée.

  • Cliquer sur le bouton « ADD » en bas à droite, puis renseigner comme suit :

Descriptive name : Nom choisi pour la CA
Method : Create an internal Certificate Authority

Une fois la méthode sélectionnée, l’encadré inférieur va changé

Key length : 2048 (longueur de la clé de chiffrement)
Digest Algorithm : SHA256 (méthode de hachage)
Lifetime : 3650 (durée de validité en jours)
Country Code : FR (Code ISO du pays d’émission du CA)

Les autres champs sont libres et à titre indicatif, évitez toutefois les infos trop personnelles/confidentielles. Choisissez simplement un « Common Name » un peu explicite pour pouvoir l’identifier facilement.

  • Cliquer sur « Save » et contempler le résultat :

Création du certificat serveur

  • Cliquer à présent sur l’onglet rouge « Certificates » où un certificat utilisé par la WebUI existe déjà, puis cliquer sur le bouton « ADD » pour en créer un nouveau :

Method : Create an internal Certificate Authority

Et là grosse surprise ! … Une fois la méthode sélectionnée, l’encadré inférieur va changé

Descriptive name : Nom choisi pour la certificat serveur
Certificate authority:  Sélectionner la CA crée juste avant (la seule normalement)
Key length : 2048
Digest Algorithm : SHA256
Certificate Type : Server Certificat (Qui a dit pourquoi ? … Toi => [] … tu sors)
Lifetime : 3650 (10 ans ça devrait suffire)

Les champs suivants sont normalement pré-remplis donc conservez les même valeurs que précédemment sauf pour « Common Name » bien sûr (Pourquoi ? … t’étais pas sorti toi ??!)

  • Valider avec le bouton « Save«

Création du certificat client

Alors là c’est tricky … attention … il va falloir relire le paragraphe précédent (oui y compris les vannes bidons) et refaire la même manip en changeant simplement :

Certificate Type : Client Certificat … \o/ 

Création du serveur VPN

  • Se rendre dans le menu VPN > OpenVPN, puis cliquer sur « ADD«

General Information

Server Mode : Remote Access (SSL/TLS + User Auth)

Avec ce mode vous aurez besoin des certificats sur le client mais devrez également saisir le login/password du user crée ci-dessus à chaque connexion du tunnel VPN. C’est une sécurité supplémentaire que vous pouvez désactiver en choisissant « Remote Access (SSL/TLS) »

Local Port : 2294

Rien d’obligatoire ici mais pour les même raison expliquées dans la 2e partie de l’article ça limite drastiquement l’efficacité de nombreux bots qui utilisent les ports standards.

Cryptographic Settings

TLS Authentication :  Laisser coché

La TLS est une couche supplémentaire d’authentification/chiffrement qui permet d’ajouter une seconde ligne de défense à SLL et à priori l’impact n’est pas significatif au niveau des performances. Libre à vous de lire la doc et de l’enlever en toute connaissance de cause si vous le souhaitez.

Description : Choisir un nom pour le serveur OpenVPN
Certificate authority:  Sélectionner la CA créée juste avant (toujours la seule normalement)
Server Certificate : Choisir le certificat serveur créé précédemment

Tunnel Settings

IPv4 Tunnel Network : 10.2.2.0/24

Conformément à notre schéma réseau, visible dans la 2e partie de l’article. Là aussi, libre à vous de choisir votre segment réseau, du moment que vous adaptez la suite à votre plan d’adressage.

Redirect Gateway : Cocher la case

Ce paramètre permet de forcer le client à utiliser le VPN en tant que passerelle par défaut dès qu’il est activé. Ce qui peut faire office de proxy sécurisé pour l’ensemble de votre trafic quand vous vous connectez depuis un Wifi Public par exemple. Si vous utilisez un client qui le permet (ex: TunnelBlick), vous pouvez laisser cette options décochée et l’activer au besoin coté client, en revanche l’ajout d’une option « push « route 192.168.9.0 255.255.255.0 » sera obligatoire.

Concurrent connections : 3

Facultatif, permet de limiter le nombre de client connectés en même temps.

Inter-client communication : Cocher la case

Si vous souhaitez que vos client puissent communiquer entre eux.

Disable IPv6 : Cocher la case

Client Settings

Dynamic IP : Cocher la case

  • Valider avec le bouton « Save«

Création de l'(unique) utilisateur

  • Se rendre dans le menu System > User Manager, puis cliquer sur « ADD«

Disabled : A cocher pour empêcher le user d’avoir le droit de se loguer sur la WebUI

En effet, le but est d’avoir un utilisateur dédié sans accès à l’interface. Ensuite choisissez un login, un password, un nom long (facultatif), une date d’expiration (si vous cherchez des ennuis, vu que vous vous demanderez dans quelques mois pourquoi ça ne fonctionne plus). Une fois le user crée, nous allons lui attribuer le certificat client que nous avons généré précédemment :

  • Cliquer sur le bouton « Edit user » (mais si, le petit crayon bleu à droite … l’autre droite)
  • Dans le cadre  « User Certificates« , cliquer sur « Add«

Method : Choose an existing certificate

Existing Certificates : Sélectionner votre certificat client qui doit être le seul non encore utilisé

Il ne vous reste plus qu’à sauvegarder la modification. L’idée est de créer un couple user/certificat client par personne (logique) voir par machine cliente, ça permet notamment pouvoir les révoquer individuellement au besoin. Enfin si vous avez besoin de plusieurs utilisateurs, créez leur un groupe dédié pour les ranger (c’est plus propre, on est pas des sauvages).

Configuration du/des client(s)

Afin de pouvoir accéder à notre tunnel, il faut maintenant récupérer :

  • La clé privé du certificat client crée précédemment
  • La clé publique de ce même certificat
  • Un modèle de configuration client d’OpenVPN et l’adapter

Je suis donc censé vous décliner la marche à suivre pour préparer des « kits » de configuration,  en fonction des options sélectionnées pour notre serveur, des spécificités de mise en forme de certificats pour les différents types de clients (Linux, MacOS, iOS, Android … voir Windows) et également pour chaque … ah ouai … mais non en fait.

Nous allons plutôt utiliser un des (nombreux) avantages de PFSense, à savoir son gestionnaire de paquets !

En effet, il existe plus d’une cinquantaine de packages (en release 2.3.4) qui permettent d’ajouter des fonctionnalités à notre Firewall. Pour ne rien gâcher, ils sont installables en un clic depuis l’interface Web et leurs paramètres sont sauvegardés automatique par le mécanisme de backup intégré de PFSense qui est un simple fichier XML.

Enfin, comble du bonheur, il en existe un qui fait exactement tout ce qui nous intéresse : openvpn-client-export !

  • Se rendre dans le menu System > Package Manager, puis cliquer sur l’onglet « Available Packages«
  • Taper « export » dans le champ de recherche, puis installer le paquet via le bouton « Install«

Vous pouvez aussi profiter d’une recherche manuelle pour parcourir les différents paquets disponibles.

Lien vers la documentation du package OpenVPN Client Export

  • Naviguer vers le menu VPN > OpenVPN, puis cliquer sur le nouvel onglet « Client Export »

Remote Access Server : Sélectionner le serveur VPN souhaité (le seul à priori)
Host Name Resolution :  Other

Le choix par défaut « Interface IP Address » va renseigner l’@IP locale de votre interface WAN (10.0.0.2) dans le fichier de configuration du client et quand vous essaierez de vous y connecter depuis internet ça marchera beaucoup moins bien. Le mieux est de sélectionner « Other » et de saisir directement votre IP publique ou votre nom de domaine (en cas d’utilisation de DynHost par exemple).

Use Random Local Port : Cocher la case (obligatoire si vous prévoyez plusieurs client en simultanés)

Scroller à présent vers le bas jusqu’au cadre OpenVPN Clients :

Il ne reste plus qu’à télécharger les configs qui vous intéresse !

Pour les utilisateurs de MacOS, je vous conseille le client VPN Tunnelblick. Une fois installé, télécharger la « Standard Configuration » au format « Archive« . Dézipper l’archive, ajouter le suffixe « .tblk » pour transformer le dossier en configuration pour Tunnelblick et enfin l’ouvrir pour la charger automatiquement dans l’application.

Une fois la/les configuration(s) installé(s) sur votre/vos client(s), il ne reste plus qu’à paramétrer les règles PFSense requises.

Configuration des flux

Autoriser l’accès du client au serveur VPN depuis internet

  • Naviguer vers le menu Firewall > Rules
  • Sélectionner l’onglet WAN puis ajouter une nouvelle règle avec « ADD«

Action : Pass
Interface :  WAN
Protocol : UDP
Source : Any
Destination : WAN adress
Destination Port Range (From) : 2294 (ou le port d’écoute choisi pour votre serveur)
Description : Renseigner le nom qui s’affichera pour la règle (ex: OpenVPN nomad access)

Autoriser l’accès du client en provenance du tunnel VPN aux LAN & WAN

  • Sélectionner l’onglet OpenVPN puis ajouter à nouveau une règle avec « ADD«

Action : Pass
Interface :  OpenVPN
Protocol : Any
Source : Network – 10.2.2.0/24
Destination : any

Ici on peut limiter l’accès des clients au seul LAN mais il faudra désactiver l’option « Redirect Gateway » du serveur et le VPN ne pourra plus être utilisé en tant que proxy Web.

Destination Port Range (From) : 2294 (ou le port d’écoute choisi pour votre serveur)
Description : Renseigner un nom pour la règle

  • Valider les changements via le bouton « Apply Changes«

Vous n’avez plus qu’à démarrer votre client VPN, renseigner votre login/pass et c’est parti !

THE END !

Voilà n’hésitez pas à commenter, poser des questions, faire une donation via PayPal si vous voulez supporter le blog avec les quelques euros qui trainent sur votre compte et surtout abonnez-vous à NoLife … à non c’est pas ça je m’égare … allez see u guys.


66 comments

  1. Bonjour, avant tout merci pour ce tutoriel qui fonctionne à merveille.

    J’ai une question concernant un besoin qui, je pense, pourra intéresser du monde :
    – Comment faire pour rendre un service accessible via une IP public (pfsense NAT 1:1 probablement) ?
    – Cela a déjà été abordé avec la question de l’IP failover (OVH) il me semble , « rediriger le trafic de cette IP vers le pfSense (exactement comme on le fait déjà pour l’IP publique du proxmox). »

    Quelle est la partie concernée ici :
    – sécurisation via iptables ?
    – routage et nat ?

    Merci encore et joyeuses fêtes !

  2. zwindler 10 décembre 2018
    Super merci beaucoup pour ce retour. Je vais refaire un environnement de zéro et je mettrai à jour le tuto dans la foulée avec toutes les remarques en commentaire pour plus de clarté.

    Bonjour Zwindler,
    Quitte à refaire un environnement de zéro et pour rebondir sur la remarque de jh pourquoi ne pas intégrer directement pfsense à la place de iptable + Reverse proxy pour atteindre les différents service web grâce à différents sous-domaines ?

    Cela sera surement plus digeste et plus user friendly, c’est la seule chose qui manque à ce superbe tuto je trouve :)

    Encore merci à toi pour ton investissement et bonne année !
    Jérémy

  3. Doublon avec l’autre article ;) du coup je copie colle ma réponse :

    On est d’accord, le script IPtables est difficilement compréhensible et débuggable.

    Le souci à tout passer sur pfsense, c’est justement que pfsense n’est pas en première ligne. Il y a l’hyperviseur d’abord… C’est tout le souci. On est obligé de le sécuriser lui car c’est lui qui est en frontal d’Internet.

    Ce que je pensais faire, c’était passer par le firewalling interne à Proxmox, a minima pour transférer tout le trafic utile vers le PFsense, puis gérer le firewalling dans pfsense ensuite (ou carrément se passer de pfsense ?).

  4. Bon la première solution qui fonctionne est de simplement bridger les VM/LXC sur vmbr0 en leur donnant l’IP/MAC (MAC virtuelle) fournit par OVH, cela rend pfsense complétement useless en tant que routeur (selon moi, dites si je me trompe) si ce n’est pour le l’accès VPN, cependant on perd en isolation car les VM/LXC passent devant le firewall.
    Néanmoins la version 5.3-6 de proxmox dispose d’une brique firewall sur 3 niveaux (datacenter, noeud, machine) on peut restreindre les accès comme bon nous semble via des security groups et la création de règles iptables, par exemple ouvrir uniquement les ports 80 et 443 si on héberge que du web.
    Je me pose maintenant deux questions :
    – L’infrastructure reste-t-elle sécurisée de cette façon ou vient-elle de se changer en véritable passoire ?
    – N’est-ce pas mieux en terme de performance que le trafic ne passe pas par une seule VM ? (dans le sens où tout le flux passait par pfsense avant)

  5. Bonjour,
    Merci pour ce tuto très bien écrit.
    En fait, comme Jack (1 avril 2018), Tout fonctionne bien, j’arrive a me connecter avec le VPN, par contre, une fois sur le VPN:
    – j’arrive à continuer à accéder à l’interface proxmox via son adresse publique xxx.xxx.xxx.xxx:8006
    – pas possible de me connecter sur la web UI de proxmox via 10.0.0.1:8006
    – ping 10.0.0.1, 192.168.9.1, 192.168.9.254 ne marche pas via le terminal du client après connection OpenVPN (mon PC loca).
    – ping 10.0.0.1 ok via ssh
    – ping 192.168.9.1 ok via la console proxmox
    Vous auriez une idée ?
    Merci d’avance

  6. Bonjour,

    J’ai créé deux installations identiques de Proxmox selon la procédure décrite et tout s’est bien passé.

    J’ai donc deux installations parallèles de PfSense dans les deux installations et j’ai créé avec succès un pont OPENVPN entre les deux sites, gràce à PfSense : les VMs d’un côté du « pont » sont dans le réseau 192.168.9.0 et les VMs de l’autre côté du « pont » sont dans le réseau 192.168.10.0. Tout fonctionne bien : les deux réseaux commmuniquent à travers le VPN.

    Voici mon problème : je souhaiterais faire communiquer maintenant le « host » Proxmox lui même avec l’adresse 192.168.9.1 ( vmbr2, voir schema réseau de Zwindler ) avec le « host » Proxmox 192.168.10.1 de l’autre côté du pont.

    Comment dois je faire le routage et quelles sont les regles du firewall Proxmox et/ou PfSense que je dois mettre en place ?

    Salutations
    Michel

  7. Bonjour,
    Déjà merci pour ce super tuto que j’utilise depuis plus de 1 an pour mes re-install proxmox. Sans jamais avoir eu de souci.
    Arf j’ai dit jamais…
    Hé oui aujourd’hui je rencontre une difficulté. tout fonctionnent a merveille coter VM/CT/pfsense. mais a partir du moment ou je lance le script iptables je ne peux presque plus rien faire sur la machine hote proxmox au niveau réseaux. Pour expliquer concrètement: je reboot la machine , je lance un apt update , sa se lance direct comme d’habitude. je lance le script iptable : apt update (wget ou tout autre commandes nécessitant le réseaux) sa reste a connexion pendant 1 ou 2 minutes , des-fois plus, voir même jusqu’au Timeout…. c’est complètement aléatoire est très embêtant….

    Je précise etre sous Proxmox 5.3.12. Install by OVH. Noyau d’origine.

    Merci d’avance pour votre aide.

  8. Bonjour,

    Merci pour ce tuto, j’ai tout suivi, tout fonctionne, j’ai activé le dhcp de pfsense, il fonctionne, mais au bout d’un certain temps, les vm perdent le reseau, comme si le lan était coupé. Les ip ne sont plus attribuées et même en forcant à la main ça ne fonctionne pas.
    Je ne trouve pas comment savoir ce qui cloche. Si je redemarre proxmox, ça remarche un certain temps.
    Est ce que vous auriez un conseil pour savoir d’où viens le problème ?
    Merci

  9. Bonjour,
    Pour commencer je tiens à vous remercier pour ce magnifique tuto.

    J’ai une question concernant l’accès à la gui est ce que c’est possible de la rendre accessible seulement à partir de PrivNet ?

    Merci

  10. Merci pour ce super tuto, vraiment impressionnant le niveau de détails.
    J’aurai voulu savoir si avec cette configuration il était possible d’avoir certaines VM avec une adresse IP publique particulière?
    Aujourd’hui on a le host des VM qui a une IP publique A et tout le reste est en réseau local. Est-ce qu’en conservant le firewall PFSense on peut avoir certaines VM avec une IP publique B tout en conservant le filtrage par le firewall?

  11. Hello. Bonne question !

    Là tout de suite, je n’ai pas la réponse, mais en effet ça me parait être un besoin légitime et il faudra creuser un peu pour trouver COMMENT le faire (il n’y a pas de raison que ça ne soit pas possible).

  12. Bonjour,
    Merci pour cette documentation très utile.
    De mon côté, tout a globalement fonctionné.

    Je cherche maintenant à installer SecurityOnion dans une VM. Je bloque sur comment sniffer l’interface principale. j’aurais voulu sniffer sur eno1 ou vmbr0. J’ai donc essayé avec daemonlogger en m’appuyant sur l’idée de : https://forum.proxmox.com/threads/network-setup-for-ids-aka-port-span-port-mirroring-sniffing.19312/

    J’ai donc créé une interface vmbr3 vers laquelle je comptais mirrorer les logs.

    auth vmbr3
    iface vmbr3 inet manual
    bridge_ports none
    bridge_stp off
    bridge_fd 0

    Ensuite, j’installe daemonlogger

    Maintenant, si je fait « daemonlogger -i eno1 -o vmbr3 »
    J’obtiens le résultat suivant :

    sniffing on interface eno1
    start_sniffing() device eno1 network lookup: eno1: no IPv4 address assigned
    ERROR: init_retrans() eth_open failed
    Fatal Error, Quitting..

    Si je fais « daemonlogger -i vmbr0 -o vmbr3 »
    J’obtiens
    sniffing on interface vmbr0
    ERROR: init_retrans() eth_open failed
    Fatal Error, Quitting..

    Quelqu’un aurait une idée ?
    Merci d’avance de votre attention.

  13. Je suppose que je fais quelque chose de mal. Mais lorsque je suis connecté au VPN je n’ai pas accès au DNS, j’ai bien accès à internet (testé avec adresse IP) et j’arrive à accéder au pfSense.
    Quelqu’un a déjà eu ce problème ?

    J’ai vu que General Setup dans le pfSense, il y a les serveurs DNS. Je les ai setté mais sans succès

  14. Je viens de résoudre mon problème, j’utilise un Mac et j’avais les DNS de SFR qui ne fonctionnent pas lors de l’utilisation du VPN. J’ai remplacé par les DNS de google et cela fonctionne

  15. Hello, j’ai remarqué qu’au bout d’un certain temps (de l’ordre de grandeur de la semaine) le firewall cesse de router le traffic en LAN.
    J’ai pas de règles dupliquées donc je ne pense pas que ça vienne de là. Le Proxmox fonctionne.
    Quand je reboot le firewall tout se met à fonctionner à nouveau.
    Je ne suis pas trop sûr de savoir par où commencer à diagnostiquer le problème?

    Merci

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.