Kimsufi on Zwindler's Reflection

Tutoriel Proxmox VE 8 - SDN en mode VXLAN avec des machines sur Internet

Sun, 30 Mar 2025 12:30:00 +0200

Préambule

Ce tutoriel est un genre de hors série dans ma suite d’articles sur Proxmox VE 8.

Dans la troisième partie qui est sortie il y a quelques jours, on s’est arrêté sur un cluster de machines distantes sur Internet.

Elles ne sont pas dans le même LAN, et pour tout dire, elles sont même distantes d’environ 100ms (et ça marche très bien).

A la fin de l’article, ça fonctionne, on a bien un réseau unique sur nos deux machines, avec un IPAM et un DHCP fonctionnel des deux côtés. Mais pour autant, les machines virtuelles qui sont sur des hôtes différents ne peuvent pas se parler directement et c’est quand même un peu dommage de ne pas avoir été au bout de l’exercice.

Plutôt que de réécrire cette partie, j’ai décidé de faire un petit aparté où je termine le travaille et teste la fonction VXLAN du SDN de proxmox VE, parce que OUI, ça peut fonctionner jusqu’au bout.

Prérequis

Je pars du principe que vous avez déjà deux (ou plus) machines au sein d’un même cluster Proxmox VE 8.

Si ce n’est pas le cas, vous êtes partis pour la lecture de ma suite d’articles (en cours d’écriture) sur le sujet (have fun!) :

Déploiement d’un cluster Proxmox VE 8 sur des serveurs dédiés (1/4)

Ces machines ne sont pas dans le même LAN (sinon pas forcément besoin de s’embêter avec du VXLAN, le SDN Simple peut suffire, comme on a fait dans la partie 3)

Problème

Ce qu’on veut faire, c’est créer un SDN qui passe par Internet, au point que les machines virtuelles croient être sur le même LAN.

On ne peut pas faire ça avec le SDN Simple, les VMs d’un hôte ne peuvent pas contacter les VMs d’un autre hôte distant sur Internet, même en étant dans le même SDN Simple et avec le même plan d’adressage.

Mais si on lit un peu plus loin dans la doc de PVE sur le SDN, on voit que c’est précisément le usecase mis en avant pour l’utilisation des SDN de type VXLAN :

The VXLAN plugin establishes a tunnel (overlay) on top of an existing network (underlay). This encapsulates layer 2 Ethernet frames within layer 4 UDP datagrams… […] You can, for example, create a VXLAN overlay network on top of public internet, appearing to the VMs as if they share the same local Layer 2 network

Petit souci cependant, en vrai, il ne vaut mieux pas le faire, car les trames ne sont pas chiffrées, et sur Internet, ce n’est vraiment pas la meilleure idée du monde…

Warning VXLAN on its own does does not provide any encryption. When joining multiple sites via VXLAN, make sure to establish a secure connection between the site, for example by using a site-to-site VPN.

En alternative, on aurait pu partir directement sur la version la plus complète / complexe du SDN de Proxmox VE : les EVPN Zones

The EVPN zone creates a routable Layer 3 network, capable of spanning across multiple clusters. This is achieved by establishing a VPN and utilizing BGP as the routing protocol.

Mais je n’ai pas envie de tremper avec BGP ici et je veux rester sur un truc simple. Cependant, c’est probablement l’option la plus “propre” pour un setup de production.

VXLAN donc, mais avec un VPN

Je ne vais pas me prendre la tête, on va monter un petit VPN avec wireguard à la mano. Il y a des tonnes d’outils de VPN sur le marché et des tonnes d’outils pour se faciliter la vie. Si vous voulez plus d’info sur Wireguard, je suis sûr que vous en trouverez plein, je mets juste ici le strict minimum pour que ça “juste marche”.

Sur les deux serveurs, installez wireguard, qui devraient être dans les dépôts debian par défaut :

apt update && apt install -y wireguard

Générez un couple de clé sur chaque machine :

wg genkey | tee privatekey | wg pubkey > publickey

Petite gymnastique mentale, on va écrire un fichier de configuration avec pour chaque serveur, la clé privée du serveur (fichier privatekey) sur lequel on est, mais la clé publique (fichier publickey) du serveur distant.

(Quand on y réfléchit, c’est évidement, mais je préfère insister)

Et il faut évidemment changer les adresses et les interfaces réseaux en fonction du serveur sur lequel on est de manière à ne pas avoir de conflit.

vi /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.30.1/24
ListenPort = 51820
PrivateKey = <clé privée du serveur local>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o <nom d'interface réseau> -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o <nom d'interface réseau> -j MASQUERADE
[Peer]
PublicKey = <clé publique du serveur distant>
Endpoint = <IP publique du serveur distant>:51820
AllowedIPs = 10.10.30.2/32

Note : vous pouvez aussi ajouter plus de nodes dans le VPN, il suffit d’ajouter plus de “Peer”.

On termine en démarrant le VPN et en vérifiant que les nodes se parlent entre eux :

systemctl enable wg-quick@wg0 --now

ping 10.10.30.1
ping 10.10.30.2

Configuration du SDN

Normalement, si vous avez suivi les articles précédents, vous avez déjà les prérequis, mais pour ceux qui ne l’auraient pas fait, je remets que dans le fichier /etc/network/interfaces, il est nécessaire d’ajouter en fin de fichier la ligne suivante (suivi d’un petit systemctl restart networking)

source /etc/network/interfaces.d/*

Ensuite, dans le menu Datacenter, ouvrir le sous menu SDN.

Dans le menu SDN/Zones, ajouter une zone de type “VXLan”. Deux points importants ici :

on doit renseigner la liste de tous les “peers”, ici les IPs de nos VPNs donc 10.10.30.1 et 10.10.30.2
on va devoir adapter la MTU. Par défaut, une trame, c’est 1500. Sauf que wireguard pour son encapsulation a diminué la MTU à 1420 et que l’encapsulation VXLAN en prend 50. On doit donc mettre 1370 pour éviter au mieux de la fragmentation, au pire, des paquets dropés

Si vous venez de lire l’article précédent, vous allez remarquer qu’ici, il n’y a pas de “coche” pour activer le DHCP sur la zone. C’est malheureusement parce que ce n’est pas disponible pour l’instant.

Currently only Simple Zones have support for automatic DHCP

Source : pve.proxmox.com/pve-docs/chapter-pvesdn.html#pvesdn_config_dhcp

Une fois que vous avez validé, allez dans le sous menu SDN/VNets, cliquez sur le bouton “Create” pour créer un réseau virtuel, puis le sélectionner une fois créé pour créer un sous réseau.

Une fois de plus, n’oubliez d’aller voir la partie DHCP, pour déclarer le range pour notre futur DHCP.

Une fois qu’on a bien tout validé, on voit qu’à côté de toutes ces nouvelles choses qu’on vient de créer, il y a une icône avec deux flèches jaunes et un statut à “New”.

Pour déployer ces modifications, on doit retourner dans le menu SDN du début, et cliquer sur Apply. Deux lignes “vxlan1” (une pour chaque serveur, en vrai) devraient apparaitre.

C’est tout ?

Et oui, c’est tout, franchement, j’aurai vraiment dû insister un peu avant de poster mon article précédent…

Pour s’en convaincre, il suffit de pop deux containers LXC (sans DHCP 🥲), un sur chaque serveur, et de voir s’ils se pingent.

It works!

Bon, ben… il ne me reste plus qu’à migrer toutes mes machines existantes sur le vnet VXLAN pour avoir enfin un cluster où les VMs se voient entre elles !!

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (3/4)

Tue, 25 Mar 2025 12:30:00 +0200

Note - cet article fait partie d’une suite d’articles :

On reprend de là où on en était : premiers pas dans l’UI

Dans le tutoriel précédent (que je vous invite à lire, si ça n’a pas été fait, sinon ça ne sera pas clair), on a configuré le stockage, le réseau et on a déployé notre première machine virtuelle pour nous assurer que tout fonctionne. Mais il reste encore pas mal de choses à explorer, notamment la mise en cluster, le SDN de proxmox VE, le firewall intégré, les sauvegardes, le monitoring…

On reprend donc de là où on en était, et on va installer un autre serveur (difficile de faire un cluster avec une seule machine).

Ce serveur a été réinstallé avec les mêmes procédures que le serveur dont je vous parle dans les parties 1 et 2, à ceci près que nous n’avons pas besoin de créer le bridge (vmbr0) car nous allons utiliser le SDN !!

Idéalement, il faut que toutes les machines du cluster aient les mêmes pools de storage puisque je le rappelle, cette configuration est censée être commune à tous les serveurs, car gérée au niveau “Datacenter” de notre cluster (même si on peut configurer des exceptions).

Création du cluster

La mise en cluster de machines Proxmox VE est un sujet que j’ai abondamment traité sur le blog, au point qu’il est d’ailleurs surtout connu de certains d’entre vous surtout pour ces articles ;-) :

Je ne vais donc pas y passer trop de temps. Sachez juste que :

c’est plus facile à faire depuis la version 6 parce qu’il n’y a plus besoin de monter un VPN entre les serveurs (corosync v3)
ça peut se faire en ligne de commande
dans tous les cas, il faut se loguer en root avec mot de passe lors de la mise en cluster

Très brièvement donc, on va sur le premier serveur, dans la Server View en haut à gauche, on sélectionne notre Datacenter, puis dans le menu Cluster.

On clique sur le bouton Create Cluster.

Note : ici, c’est simple, je n’ai que ma carte réseau, donc il n’y a pas de doute sur l’interface à utiliser. Cependant, dans le cas d’un serveur avec plus d’interfaces et plus de bridges (ou des VPNs comme on a dû le faire jusqu’en PVE 6), il faut bien choisir quelle interface sert au clustering.

On valide le formulaire :

À partir de ce moment-là, le serveur n’est plus en “standalone” et dispose de services systemd supplémentaires.

On a notamment un dossier /etc/pve qui est synchronisé entre tous les nodes (el famoso Proxmox Cluster File System) avec la configuration de chaque node et les fichiers de configuration des machines virtuelles. On a aussi le logiciel corosync, qui va régulièrement contacter tous les nodes du cluster pour s’assurer que tout le monde est bien vivant / accessible.

Rejoindre le cluster

Si on retourne voir le menu “Cluster”, on a maintenant des informations qui s’affichent sur notre cluster, à savoir son nombre de nœuds (ici un seul, normal). Cliquer sur le bouton Join information.

Une popup s’ouvre avec plusieurs informations à copier-coller qui nous seront demandées dans le menu de l’autre serveur, celui qui va rejoindre le cluster :

On se connecte donc sur l’interface graphique de notre second serveur Proxmox VE (mon Atom dans l’exemple), on va dans le même menu, mais au lieu de créer un nouveau cluster, on clique sur le bouton Join Cluster :

Petit coup de flip normalement, une fois que le node va rejoindre le cluster, vous allez perdre la main sur l’interface web et avoir un message d’erreur “401”. C’est “normal”, quand le serveur rentre dans le cluster, des services sont redémarrés et on passe d’un mode standalone à un mode clusterisé…

Pas de panique, un F5 devrait résoudre l’affaire (ou alors, connectez-vous au “premier” serveur du cluster).

On a maintenant un beau cluster :)

Split brain

Notez par contre que dans mon exemple, on n’a que 2 nodes, ce qui est plus que déconseillé quand on fait un cluster Linux (en vrai, un cluster en général). Si jamais le lien réseau tombe entre nos deux machines, elles n’auront aucun moyen de savoir si c’est un problème réseau (que se apelerio split brain) ou une panne d’un des nodes.

Pour éviter de tout péter en redémarrant des VMs des deux côtés (le cas le plus catastrophique dans un split brain), lorsque le quorum ne sera plus atteint, Proxmox VE passe les nodes qui n’ont pas de majorité en (quasi) “lecture seule”.

Et au cas où ce n’est pas clair, le quorum c’est la moitié des nodes +1, donc ici : 2/2+1 = 2… donc dès qu’on a plus un des deux nodes, on a plus le quorum.

Simple, basique.

Du coup, si jamais on coupe un node ou la communication entre les deux, vos VMs encore actives continueront à fonctionner (j’ai débattu de ça sur LinkedIn il y a quelques jours).

Par contre, il sera impossible de modifier la configuration du cluster, démarrer ou créer des VMs, etc.

La seule chose qu’on peut éventuellement faire qui ne soit pas “read only”, c’est arrêter des VMs, car ça n’induit aucun risque pour la cohérence des données. Mais vous ne pourrez pas les rallumer, vous êtes prévenus…

Pour la petite histoire, le débat sur LinkedIn, c’était “est-ce que ProxmoxVE coupe toutes les VMs en cas de split brain” et la réponse est évidemment non. Par contre, la plupart des actions sont bien bloquées.

Dans tous les cas, pour éviter ça, le mieux est d’avoir un nombre impair de nodes pour que le split brain ne puisse jamais arriver, ou éventuellement d’ajouter un vote complémentaire à l’aide d’une instance servant juste d’arbitre comme c’est expliqué dans mon vieil article de 2019 ou dans la doc officielle :

Configuration du SDN

Bon, c’est cool, on a un cluster de deux machines. Mais dans la configuration actuelle, la VM qu’on a créée dans la partie précédente ne peut pas migrer facilement d’un serveur à l’autre. En effet, on l’a attachée sur un bridge Linux (vmbr0) qui a son propre plan d’adressage réseau.

En cas de migration, il faudrait potentiellement démarrer la machine, changer l’adresse IP, revoir les iptables / règles de firewalling. C’est ce que je faisais jusqu’à présent, et dans le cas d’un PRA pour une infra de lab et un blog perso, c’est “OK”.

Une grosse nouveauté de la version 8.1, est l’activation d’un module “SDN” (Software Defined Network) qui est présent en test par les développeurs et quelques early adopters depuis la version 6.X, qui va nous permettre de gérer ça de manière centralisée depuis l’interface. Si vous voulez aller bouquiner la doc officielle, c’est ici :

pve.proxmox.com/pve-docs/chapter-pvesdn.html

Le seul prérequis qui va nous manquer est dnsmasq pour le DHCP, et la doc nous dit de lancer les commandes suivantes sur nos machines :

apt update
apt install dnsmasq
# disable default instance
systemctl disable --now dnsmasq

Et dans le fichier /etc/network/interfaces, il est aussi nécessaire d’ajouter en fin de fichier la ligne (suivi d’un petit systemctl restart networking)

source /etc/network/interfaces.d/*

Dans le menu Datacenter, ouvrir le sous menu SDN. On remarque qu’il existe déjà des SDNs de déclarés, mais il s’agit en fait des réseaux par défaut qu’on a déclaré dans les articles précédents :

Dans le menu SDN/Zones, ajouter une zone de type “Simple”. Il existe des zones plus complexes qui seront utiles dans des contextes de production avec des LANs non triviaux (VLAN, VXLan) mais dans notre cas, la Simple est suffisante.

Note : ne pas oublier de cocher la case advanced pour pouvoir activer le DHCP. OUI on va enfin avoir du DHCP pour nos machines virtuelles et nos containers.

Une fois de plus, n’oubliez d’aller voir la partie DHCP, pour déclarer le range pour notre futur DHCP.

Une fois qu’on a bien tout validé, on voit qu’à côté de toutes ces nouvelles choses qu’on vient de créer, il y a une icône avec deux flèches jaunes et un statut à “New”.

Pour déployer ces modifications, on doit retourner dans le menu SDN du début, et cliquer sur Apply. Deux lignes “sdn1” (une pour chaque serveur, en vrai) devraient apparaitre.

Fait rigolo, le SDN de Proxmox VE va rajouter des règles iptables qui devraient vous dire quelque chose si vous avez déroulé les précédents articles :

#version:5
auto vnet1
iface vnet1
address 10.10.20.1/24
post-up iptables -t nat -A POSTROUTING -s '10.10.20.0/24' -o vmbr0 -j SNAT --to-source 203.0.113.1
post-down iptables -t nat -D POSTROUTING -s '10.10.20.0/24' -o vmbr0 -j SNAT --to-source 203.0.113.1
post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
bridge_ports none
bridge_stp off
bridge_fd 0
ip-forward on

Et si maintenant, je recrée une autre machine virtuelle, mais que cette fois-ci au lieu de vmbr0, je choisis vnet1, je n’ai pas besoin de saisir l’adresse IP (puisque j’ai le SDN qui sert le DHCP) et elle a accès à Internet sans configuration supplémentaire.

Avec cette configuration cependant (SDN en mode Simple Zone), il ne sera toujours pas possible de faire communiquer les machines virtuelles entre elles. Ça sera possible avec des configurations plus complexes :

You can, for example, create a VXLAN overlay network on top of public internet, appearing to the VMs as if they share the same local Layer 2 network

Note : j’ai exploré les VXLAN depuis, et j’ai écrit un article complémentaire ici.

Conclusion

Je n’ai toujours pas terminé cette série, car j’ai encore des choses à dire sur la réplication SDN et le firewalling de Proxmox VE, les sauvegardes, le monitoring, mais une fois de plus, je dépasse déjà les 12000 signes. Il est donc temps de publier l’article et de commencer à écrire le suivant.

Et en attendant, have fun :)

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (2/3)

Mon, 17 Feb 2025 10:30:00 +0200

Note - cet article fait partie d’une suite d’articles :

On reprend de là où on en était : premiers pas dans l’UI

Dans le tutoriel précédent (que je vous invite à lire, si ça n’a pas été fait, sinon ça ne sera pas clair), on a choisi un serveur physique dédié chez un provider type OVHCloud ou Hetzner. On a ensuite installé Proxmox VE dans la dernière version (8.x), configuré quelques options de sécurité de base, ajouté des utilisateurs et des groupes.

On peut maintenant essayer de se connecter à l’UI. La première chose qui devrait vous frapper (💥 aïe !) c’est que la page d’administration est en HTTPS avec un certificat autosigné. On va commencer par régler ça.

Un truc assez frustrant avec Proxmox VE (mais c’est probablement pour de “bonnes raisons” que j’ignore) c’est que certaines opérations ne sont pas possibles à réaliser dans l’UI si vous vous connectez avec le compte admin zwindler@pve que nous avons créé dans le blog post précédent.

C’est typiquement vrai pour les mises à jour, la mise en cluster et la configuration et… pour la configuration des certificats (liste non exhaustive). Ici, on va donc devoir pour l’instant se connecter en root@pam et non pas en zwindler@pve…

Notez bien qu’il y a (pour l’instant) 2 “realms”, Linux PAM (pour root) et Proxmox VE Auth (pour l’admin).

Dans la barre de droite, on retrouve notre serveur, qui est pour l’instant tout seul dans son datacenter (on y reviendra plus tard). Il y a plusieurs vues dans l’UI de Proxmox VE, certaines choses sont difficiles à trouver quand on n’a pas ça en tête. Ici, je suis dans la “server view”, probablement la plus classique si vous venez du monde VMware. Dans ce menu, vous trouverez vos hyperviseurs et on pourra interagir avec chacun d’entre eux, comment ils sont configurés.

Une fois notre serveur sélectionné, on a donc le menu principal qui affiche de nombreux menus. Sélectionner System / Certificates.

On a de la chance, Proxmox VE est livré avec un module pour commander tout seul des certificats Let’s encrypt. Si vous avez votre propre certificat ça fonctionne aussi (bouton Upload Custom Certificate), bien entendu, mais je vais partir du principe que vous n’en avez pas, comme moi.

Dans la partie ACME, cliquer sur Add ACME Account pour enregistrer votre email et accepter les Terms Of Service (TOS) de Let’s Encrypt.

À partir de là, ajouter le FQDN de notre serveur en cliquant sur le bouton Add sous ACME. Le bouton était grisé tant que nous n’avions pas ajouté de compte.

Maintenant, on peut enfin commander le certificat en cliquant sur Order Certificates Now. Si tout se passe bien, le certificat sera correctement livré par Let’s Encrypt, et le serveur pve-proxy (qui sert le frontend de l’UI de Proxmox VE) devrait redémarrer, et votre page web se rafraîchir, avec un bon certificat cette fois-ci :).

Stockage / ZFS

Si vous lisez souvent mon blog et que je vous dis que je suis un fan inconditionnel de ZFS, vous ne serez pas surpris.

Et si vous avez bien lu l’article précédent, vous vous rappellerez que nous avons réduit la partition par défaut du template OVHcloud en LVM pour pouvoir faire une belle partition ZFS. Sauf que si on va dans la vue stockage, elle n’est malheureusement pas visible.

Petite subtilité de l’UI, le menu pour ajouter du stockage se retrouve au niveau du Datacenter et non de la configuration du serveur lui-même. En théorie, la gestion du stockage doit être identique sur tous les serveurs d’un même DC dans Proxmox VE, même si on peut passer outre ce principe et mettre en place des exceptions depuis de nombreuses versions déjà.

Dans Datacenter / Storage, cliquez sur Add, puis ZFS dans le menu déroulant qui s’affiche :

Sur les stockages de type ZFS, on ne peut stocker que les “Disk images” et les “Containers”, ce qui ne va pas nous arranger si nous voulons aussi stocker des ISOs, des templates ou des backups.

On pourra se contenter de les stocker sur le stockage par défaut “local”.

Mais on peut aussi “tricher” en se connectant sur le serveur en SSH, et en créant un dossier (/tank/data dans mon exemple), puis en créant un nouveau stockage de type Directory qui n’a pas de restriction sur les types de données.

Parlons un peu de ZFS

Je me suis pris la tête un nombre incalculable de fois avec des gens qui persistent raconter n’importe quoi sur ZFS, même après leur avoir expliqué.

C’est faux. Et archifaux. Euh…

non, il n’y a pas besoin d’avoir de la RAM ECC pour stocker des choses sur ZFS. D’abord, c’est une préconisation (un peu zélée probablement) faite par des gens qui ont conçu un filesystem extrêmement robuste. De très nombreuses prods fonctionnent avec ZFS sans RAM ECC. Ensuite, c’est surtout vrai si vous faites de la déduplication, car la perte d’un bloc peut avoir des conséquences catastrophiques dans ce genre de cas…
non, ZFS ne nécessite pas 1 Go de RAM par To de disque, là encore, c’est uniquement si vous activez la déduplication (pour stocker les tables de correspondance entre les hashes et les blocs).

En revanche, ce qui est exact, c’est que par défaut, ZFS va essayer d’utiliser 50% de la RAM disponible sur votre serveur et de s’en servir comme cache. Dans beaucoup de logiciels d’administration, y compris Proxmox VE, cette valeur va être beaucoup trop haute pour nous, car la RAM est une ressource précieuse sur un hyperviseur.

Ça ne veut pas dire que cette fonctionnalité est inutile. Avoir du cache quand on a de la RAM qui ne sert à rien, c’est toujours bien. Donc, on va réduire cette valeur pour éviter des conflits de ressources entre l’optimisation des performances de notre stockage et la quantité de VMs qu’on peut héberger.

# Restrict to 512MB
echo 536870912 | sudo tee -a /sys/module/zfs/parameters/zfs_arc_max

# Restrict to 4GB
echo 4294967296 | sudo tee -a /sys/module/zfs/parameters/zfs_arc_max

Note : cette commande sera à persister d’une manière ou d’une autre

Du réseau

Bon… j’ai essayé de repousser au maximum le moment où on arrive au réseau (parce que je déteste ça) mais à un moment, il va bien falloir s’y mettre…

Par défaut, notre serveur Proxmox VE est installé avec un bridge Linux qui va nous permettre de partager du réseau entre l’interface physique de notre serveur et nos machines virtuelles.

Ce setup fonctionne bien sur votre réseau local avec un DHCP et votre propre LAN IPv4 local ou si vous disposez d’une plage d’IP (que ce soit v6 ou v4) et de quoi les affecter aux machines virtuelles.

Malheureusement dans mon cas, je n’ai qu’une IPv4 (je pourrais activer l’IPv6 mais j’aurais d’autres problématiques et je préfère rester simple ici). Si je crée des VMs et que je les affecte sur le bridge, elles ne récupèreront pas d’IP et n’auront pas accès à Internet.

Il existe plusieurs façons de connecter les machines virtuelles au réseau extérieur. Si vous avez du temps, je vous conseille de lire avec attention le Wiki de Proxmox VE qui a une très bonne page qui liste les différentes possibilités.

pve.proxmox.com/wiki/Network_Configuration

Dans les précédents articles sur Proxmox VE 5 puis Proxmox VE 6, on avait fait des trucs compliqués à base de plusieurs bridges, de DMZ, de firewalling pfSense, et d’un script iptables de l’enfer.

Rien que d’y penser, je suis déjà épuisé.

Heureusement, il existe depuis plusieurs versions déjà un firewall intégré à Proxmox VE, ainsi qu’un SDN que je n’ai jamais pris le temps de découvrir et je pense que c’est le bon tuto pour le faire :).

On va donc se référer à la documentation officielle, et choisir le mode “Masquerading (NAT) with iptables”, mais avec un setup plus simple par rapport à précédemment.

Danger zone

La configuration de l’interface réseau peut en théorie se faire directement depuis l’UI plutôt qu’en allant modifier les fichiers de configuration (/etc/network/interfaces). Dans la vue du serveur, allez dans le menu System / Network :

Ici, on voit que je ne vous ai pas raconté de carabistouilles, et qu’on a bien un bridge avec notre interface physique (ici enp1s0).

(On a même une plage IPv6, oh là là 🙈 je n’ai aucune excuse… BREEEF, on va faire comme si on n’avait pas vu.)

On arrive maintenant au moment rigolo où on peut se couper la chique assez facilement. Je l’ai fait assez souvent et passer en rescue…

fun fun fun fun

L’idée ici, c’est donc de retirer l’interface du bridge, de configurer le réseau directement dessus, et de donner un réseau local pour nos VMs sur le bridge, tout en ajoutant les règles iptables pour faire le masquerading.

Tant qu’on ne cliquera pas sur le bouton Apply Configuration, on ne “risque” rien.

Le problème de l’UI est que nous n’allons pouvoir modifier QUE les IP, les gateway et les interfaces sur le bridge ou non. Sauf que pour réaliser le masquerading et que nos machines virtuelles accèdent à Internet, nous devons ajouter les fameuses règles iptables dont je vous parle juste avant et on ne peut pas le faire depuis l’UI.

Il va falloir rajouter les cinq dernières lignes dans la configuration du vmbr0…

cat /etc/network/interfaces
[...]
auto vmbr0
iface vmbr0 inet static
 address 10.10.10.1/24
 bridge-ports none
 bridge-stp off
 bridge-fd 0

 # à ajouter pour que le masquerading fonctionne
 post-up echo 1 > /proc/sys/net/ipv4/ip_forward
 post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o enp1s0 -j MASQUERADE
 post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o enp1s0 -j MASQUERADE
 post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
 post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

Attention : le point le plus important est de bien vérifier que l’interface de sortie (-o) a bien le bon nom. Ici, mon interface physique connectée à Internet est enp1s0, mais si la vôtre a un autre nom, il faut adapter.

De mon point de vue, l’UI n’est tout de même pas complètement inutile, car elle nous permet de faire le changement le plus délicat (échange des IP) avec le diff visuel et le bouton “apply config”. Les scripts post-up ont peu de chances de nous couper l’accès.

Premier test

On est loin d’avoir fini (ça ne rentrera pas dans cet article, de toute façon, donc autant brûler les étapes…). Mais je suis sûr que vous êtes impatients de lancer une VM et on devrait avoir quelque chose de fonctionnel, bien qu’incomplet.

On va donc faire un petit test rapide de notre setup pour vérifier qu’on a bien un hyperviseur fonctionnel a minima (c’est-à-dire sans clustering, sans SDN, sans firewall, sans monitoring, sans sauvegarde… sans rien, en fait).

J’ai commencé à faire joujou avec Talos Linux comme distribution Linux pour Kubernetes. Pour faire simple, je vais donc lancer l’install d’un Node Talos. Si elle arrive à s’enrôler dans l’interface Omni, ça veut dire que j’ai un hyperviseur fonctionnel, réseau inclus.

Une fois l’ISO généré sur le site de mon Omni (le control plane SaaS de Sidero Labs, l’éditeur de Talos Linux), on peut le pousser sur notre Proxmox VE.

Pour le faire, depuis notre serveur (donc pas au niveau Datacenter), on sélectionne un pool de stockage qui accepte les images ISO (si vous vous souvenez bien, notre pool ZFS ne le supporte pas par défaut), on choisit ISO Images, et on clique sur Upload pour téléverser l’ISO (comme on dit en bon français).

Une fois uploadé, on peut maintenant cliquer sur le bouton bleu en haut à droite Create VM.

À partir de là, le wizard de création de VM devrait vous prendre la main. Ça va être un peu verbeux, mais tous les menus sont utiles, quand on commence à bien connaître Proxmox VE. Je vous donne quand même le minimum :

Dans le premier menu, on ne va pas choisir sur quel nœud on installe la VM puisque pour l’instant, on n’en a qu’un… En revanche, on va devoir lui donner un ID (100 par défaut) unique pour tout le cluster. Idéalement, on lui donne aussi un petit nom. Moi, j’ai opté pour talos02 (car j’ai déjà un talos01 sur un autre serveur, vous avez vu comme je suis original ?).

Enfin, j’ai coché la case “Start at boot”, c’est le genre de truc relou quand on a oublié de le mettre et que l’hyperviseur redémarre (ça arrive)…

On peut donner des tags à nos VMs, elles auront de jolies pastilles de couleurs pour les distinguer :)

Dans le second menu (OS), on doit indiquer deux choses. D’abord, qu’on veut utiliser l’ISO qu’on vient de récupérer / uploader pour booter notre machine (il faut choisir le bon pool de stockage, par défaut, c’est “local” qui est sélectionné). On doit aussi donner le type d’OS pour des histoires de compatibilité de pilotes pour les périphériques virtuels. Ça fait belle lurette qu’on n’a plus trop besoin de ça, “6.X - 2.6” fonctionne pour tous les Linux récents (la sortie du kernel 2.6, c’est 2003 !).

Je saute System, dans Disks, on ajoute un disque sur le bon pool (donc pas local, mais bien celui en ZFS). Pour ma VM Talos 32 Go, c’est largement suffisant… À noter qu’il existe beaucoup d’options importantes ici pour tout ce qui est “optimisation” des lectures / écritures, mais on est largement au-delà du scope de cet article.

Je saute CPU et memory, l’important, c’est de surtout lui donner au moins 2 cores et 2 Go de RAM (au moins). On peut là aussi optimiser les performances CPU en activant les bons flags, mais là encore, on n’est plus dans le but de l’article donc je n’insiste pas.

Dans la partie network, on s’assure juste qu’on est bien branché sur le bon bridge (normalement si vous avez suivi l’article, on en a qu’un, vmbr0, donc on ne peut pas se tromper).

Et on vérifie que tout est OK. Protip, pour gagner cinq secondes dans votre vie, cliquez sur “Start after created”, ce qui permettra de démarrer la VM au plus vite après sa création.

It’s alive?

À ce stade, la VM devrait automatiquement booter sur le CD Talos et l’OS devrait s’installer sur le disque. Une fois prête, la machine va essayer de s’enrôler sur mon control plane Omni.

Et là, c’est le drame…

Car oui, je n’ai pas configuré de DHCP ni de SDN. Il faut donc aller configurer à la main la carte réseau virtuelle (ce qui n’est pas foufou), en appuyant sur F3 dans la console.

(Et en subissant un peu de QWERTY, mais c’est à ça qu’on reconnaît un bon sysadmin normalement : il sait faire du QWERTY dans les consoles)

Une fois le réseau configuré, la machine devrait quasiment instantanément commencer à se configurer…

… et à s’enrôler dans Omni :

Victoire !!

Enfin bon…

Enfin bon… oui, on a une VM fonctionnelle. Mais j’ambitionne qu’on aille quand même un peu plus loin avant de vraiment crier victoire.

Comme je l’ai dit plus haut, on a dû configurer le réseau de notre VM à la main, et on n’a encore ni clustering, ni firewalling, ni SDN, ni monitoring, ni sauvegarde… Mais on chatouille allègrement les 16 000 signes pour ce blog post, il est donc temps de raccrocher pour se dire “à la prochaine fois”.

Et en attendant, have fun :)

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (1/2)

Mon, 27 Jan 2025 20:00:00 +0000

Note - cet article fait partie d’une suite d’articles :

Introduction

Ceux qui suivent un peu le “lore” de ce blog savent que je suis un peu connu dans la communauté des bidouilleurs du dimanche pour avoir rédigé (ou co-rédigé) plusieurs tutos sur Proxmox VE. Je pense en particulier à deux suites d’articles sur Proxmox VE 5, puis Proxmox VE 6, pour créer de zéro un cluster de virtualisation avec Proxmox VE (et pfSense à l’époque).

C’est une nouvelle itération de ces tutos, basée cette fois-ci sur Proxmox VE 8, avec pas mal de choses qui changent et de nouvelles approches.

Le but ultime de cette suite d’articles est de disposer d’une plateforme de virtualisation avec Proxmox VE. Cette plateforme sera composée de plusieurs machines (idéalement 3, mais 2 ça fonctionne aussi), sécurisée, supervisée, hautement disponible, sauvegardée.

Il faudra suivre plusieurs articles pour y parvenir.

Postulats de départ

1- Je pars du principe que vous n’avez pas de machines pour le faire à la maison et que vous n’avez pas envie ou les moyens d’investir dans un homelab (même si ça peut être très rigolo, ça demande de l’investissement). Cependant, si vous avez des machines à la maison, une grande partie de l’article reste valide, une fois les machines installées.

2- Comme Proxmox VE est une plateforme de virtualisation, je pars aussi du principe que vous voulez disposer de machines dédiées (physique) et pas de machines virtuelles, pour justement pouvoir virtualiser des OS entiers sans trop de problèmes (même si on a toujours l’option “nested virt”, c’est moins glop).

Note : si vous n’avez pas besoin de virtualisation (exemple : pas de Windows ou d’OS un peu particulier), Proxmox VE est une super plateforme de containérisation, notamment grâce à LXC, qui permet de créer des containers Linux avec un OS entier, que vous pourrez gérer exactement comme une VM mais avec des performances bien meilleures (et quelques limitations dues au partage de kernel, mais c’est souvent suffisant). Vous pouvez aller lire mes articles sur LXC si ça vous intéresse.

3- J’aimerais attirer votre attention sur le fait que de nombreuses actions auraient pu être scriptées ou gérées via de “l’infrastructure as code”. C’est plus dans l’air du temps, car plus robuste et plus fiable. Cependant, l’intérêt de cet article est de faire “à la main” pour comprendre ce qu’on fait, pas à pas, pas juste vous fournir une infrastructure “clé en main” que vous ne saurez pas gérer au premier pépin.

Si vous cherchez des méthodes plus industrielles pour déployer des clusters de virtualisation, vous en trouverez sûrement plein sur Internet, de la part d’autres blogueurs (certains français, certains sont même des copains).

J’ai d’ailleurs moi-même plusieurs fois fait l’exercice avec Ansible ou Rudder par le passé, par exemple ici (note : ce code est obsolète) :

Maintenant que l’objectif et le contexte est clair pour tout le monde, on peut commencer :)

Choix des machines

Comme on a dit qu’on n’auto-héberge pas, il faut trouver un hébergeur qui propose des machines physiques. Idéalement, quelque chose de pas trop cher, ça serait bien pour commencer.

On va donc plutôt viser à trouver des machines peu onéreuses MAIS avec le support des instructions VT-x / AMD-v, ce qui est à peu près tous les CPUs qui fonctionnent encore aujourd’hui SAUF les Atom et les machines ARM type Raspberry.

Grosso modo, ça nous laisse les Kimsufi chez OVHCloud, les dédibox chez Scaleway et les machines chez Hetzner.

Chez Hetzner pour 45€, vous avez un i5 gen13, 64 Go de RAM et 2 SSD NVMe.

Chez OVHcloud, avec un peu de chance, vous pourrez tomber sur des machines autour des 15 - 20€ par mois avec du matériel plus ancien, mais largement suffisant pour ce qu’on va en faire.

Chez Scaleway, l’offre d’entrée de gamme est centrée sur les Atom Avoton ou de très vieux Xeon. L’Avoton C2750 reste une option valable, car c’est un octo-cores qui supporte le VT-x (contrairement au C2350, attention !). Mais bon, c’est du matoss de 2013 💀…

Pour les besoins de cet article, j’ai optimisé les coûts et je suis parti sur le serveur OVHcloud que je présente juste au-dessus (KS-GAME-LE), malheureusement uniquement disponible au Canada :(. Mais 8 threads et 16 Go de RAM pour 12€ TTC par mois, ce n’est vraiment pas cher payé.

Deux points noirs :

le stockage ridiculement petit pour de la virtualisation (seulement 240 Go, un seul disque)
la latence - presque 100 ms depuis chez moi, contre 11 ms pour mon autre machine chez Scaleway

64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=1 ttl=53 time=98.0 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=2 ttl=53 time=97.5 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=3 ttl=53 time=97.6 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=4 ttl=53 time=97.7 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=5 ttl=53 time=97.7 ms

Installation de l’OS

Une fois commandé, le serveur est relativement rapidement disponible dans votre “manager OVH”. On a un menu relativement intuitif pour installer directement Proxmox VE 8, quasiment à jour (les images fournies sont reconstruites très régulièrement avec toutes les mises à jour).

Pour lancer l’installation, on clique sur les “…” dans la partie Système d’exploitation (OS), puis on sélectionne l’install depuis un template OVH

On déroule la liste des types d’OS, on sélectionne Virtualisation, puis proxmox VE 8 (tant qu’à faire). J’ai aussi coché la case “Personnaliser la configuration des partitions”, parce que par défaut, l’installation d’OVH utilise du stockage de type “LVM thick” pour la majorité de l’espace disque, alors qu’on va utiliser les fonctionnalités avancées de ZFS pour la suite :

Avant de valider l’installation, n’oubliez pas de modifier son nom (Custom hostname) pour éviter d’avoir besoin de le faire post install, puis d’ajouter une clé publique SSH :

Premières tâches post-installation : upgrade et reboot

Il y a toute une petite série de trucs à faire quand on vient d’installer une machine, en particulier sur Proxmox VE, et on va essayer de se retenir de “vite vite” se connecter à l’interface graphique.

De toute façon, on ne pourra pas s’y connecter, à l’interface graphique de Proxmox VE…

Ah bon ???

Oui, car si on peut normalement se connecter avec l’utilisateur root de notre Linux, on ne va pas pouvoir dans le cas d’OVHcloud, tout simplement parce qu’on n’a PAS le mot de passe root. Heureusement qu’on a mis une clé SSH ;)

On y reviendra plus tard, on a plus urgent à faire.

La première chose que moi, j’ai faite, c’est d’ajouter tout de suite un record DNS de type A pour que l’IP de ma machine corresponde à un FQDN. Pour cet article, j’y ferai référence de la manière suivante :

hostname: myPVEhost
FQDN: proxmox.example.org
IP: 203.0.113.159

On se connecte donc sur l’IP de notre machine fraichement installée en SSH (root@IPmachine) et on va en profiter pour faire un peu de ménage.

La première chose à faire est de mettre à jour le serveur, idéalement suivi d’un reboot :

apt update && apt upgrade -y && reboot

Une fois le serveur revenu à la vie, on se reconnecte et active d’une manière ou d’une autre un système de mise à jour automatiques. Le plus simple c’est d’utiliser unattended-upgrades s’il n’est pas installé par défaut (il est possible qu’il y soit déjà) mais il existe des outils plus perfectionnés.

apt install unattended-upgrades

C’est pour la sécurité

Une fois que c’est fait, je vous conseille d’installer tout de suite CrowdSec. Ici, je me suis simplement basé sur la documentation officielle de crowdsec, pour ajouter le moteur de détection, le composant de remédiation (ici via iptables) :

CrowdSec.net - Installation Linux

curl -s https://install.crowdsec.net | sudo sh
apt install crowdsec

# vérifier que le service crowdsec fonctionne
systemctl status crowdsec
● crowdsec.service - Crowdsec agent
 Loaded: loaded (/lib/systemd/system/crowdsec.service; enabled; preset: enabled)
 Active: active (running) since Sun 2025-01-26 21:04:26 UTC; 1min 56s ago
 Process: 73830 ExecStartPre=/usr/bin/crowdsec -c /etc/crowdsec/config.yaml -t -error (code=exited, status=0/SUCCESS)
 Main PID: 73862 (crowdsec)
 Tasks: 13 (limit: 19059)
 Memory: 33.1M
 CPU: 2.571s
 CGroup: /system.slice/crowdsec.service
 ├─73862 /usr/bin/crowdsec -c /etc/crowdsec/config.yaml
 └─73877 journalctl --follow -n 0 _SYSTEMD_UNIT=ssh.service

Jan 26 21:04:23 myPVEhost systemd[1]: Starting crowdsec.service - Crowdsec agent...
Jan 26 21:04:26 myPVEhost systemd[1]: Started crowdsec.service - Crowdsec agent.

# installer le moteur de remédiation
apt install crowdsec-firewall-bouncer

Une fois que Crowdsec est opérationnel, on peut lui ajouter la collection “fulljackz/proxmox”, qu’il va falloir modifier (merci le super article de Julien Louis sur son blog slash-root.fr), qui va écouter les logs de la webUI pour détecter tout brute force et bannir ceux qui tenteraient de le faire :

cscli collections install fulljackz/proxmox
[...]
INFO Enabled fulljackz/proxmox
INFO Run 'sudo systemctl reload crowdsec' for the new configuration to be effective.

Le pattern écouté par le parser proxmox n’est pas/plus bon avec les nouvelles versions

Jan 26 21:23:14 myPVEhost pvedaemon[1250]: authentication failure; rhost=::ffff:203.0.113.159.78 user=coucou@pve msg=no such user ('coucou@pve')

On voit ici que Julien a rajouté le préfixe “::ffff:” dans la variable PVE_AUTH_FAIL du fichier /etc/crowdsec/parsers/s01-parse/proxmox-logs.yaml, mais quand je vois les cas de tests prévus dans la collection, j’ai l’impression que ce n’est pas nécessaire…

Dans tous les cas, on va créer un fichier /etc/crowdsec/acquis.d/proxmox.yaml pour que CrowdSec puisse commencer à analyser nos logs :

mkdir -p /etc/crowdsec/acquis.d/
cat > /etc/crowdsec/acquis.d/proxmox.yaml <<EOF
journalctl_filter:
 - _SYSTEMD_UNIT=pvedaemon.service
labels:
 type: syslog
EOF

On termine par recharger crowdsec et on regarde ~~le monde brûler~~ les scripts kiddies se faire bloquer.

systemctl reload crowdsec

cscli alerts list
╭────┬────────────────────┬───────────────────────────┬─────────┬──────────────────────────────────────────────────────────────┬───────────┬─────────────────────────────────────────╮
│ ID │ value │ reason │ country │ as │ decisions │ created_at │
├────┼────────────────────┼───────────────────────────┼─────────┼──────────────────────────────────────────────────────────────┼───────────┼─────────────────────────────────────────┤
│ 2 │ Ip:203.0.113.222 │ crowdsecurity/ssh-slow-bf │ IR │ 202468 Gloubi Bo ulgua Co. ( Private Joint Stock) │ ban:1 │ 2025-01-26 22:31:15.366187524 +0000 UTC │
╰────┴────────────────────┴───────────────────────────┴─────────┴──────────────────────────────────────────────────────────────┴───────────┴─────────────────────────────────────────╯

Dans la liste des petits trucs pénibles livrés de base avec Proxmox VE, il y avait avant le fait que Proxmox VE avait les dépôts apt entreprise sur toutes les installations, et il était nécessaire de préalablement les désactiver à la main avant de pouvoir faire les mises à jour.

C’était super pénible et les développeurs de Proxmox VE ont entendu (un peu) leur communauté et retiré cette obligation… pour la remplacer par une popup.

Alors, une popup, je veux bien ! C’est important de récompenser le travail des développeurs et de les soutenir. Mais est-ce que c’est vraiment nécessaire de le faire à chaque login ET à chaque fois qu’on rafraîchit la liste des packages à mettre à jour ?

C’est bien entendu une question rhétorique.

Évidemment, de nombreuses personnes ont trouvé plusieurs méthodes pour désactiver le code JS responsable. Big up à fabio pour sa version qui fonctionne bien.

sed -Ezi.bak "s/(function\(orig_cmd\) \{)/\1\n\torig_cmd\(\);\n\treturn;/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Note : si comme moi vous vous êtes déjà connecté une fois, il faudra aussi nettoyer le cache sinon la popup restera…

Création de groupes et d’utilisateurs pour l’interface graphique

Ok ok, on a fait plein de trucs, est-ce qu’on peut se connecter maintenant ???

Mais ouiiii, on peut. De toute façon, j’en suis déjà à presque 15000 signes, cet article est beaucoup trop long, il faut abréger.

Dernière étape dans cet article, on va créer un administrateur pour se connecter à l’UI et un utilisateur qui nous servira plus tard pour le monitoring.

# vous n'êtes pas **vraiment** obligé d'appeler l'admin "zwindler" vous savez ?
pveum group add admin -comment "System Administrators"
pveum acl modify / -group admin -role Administrator
pveum useradd zwindler@pve
pveum usermod zwindler@pve -group admin
pveum passwd zwindler@pve

# notre utilisateur de monitoring
pveum groupadd monitoring -comment 'Monitoring group'
pveum aclmod / -group monitoring -role PVEAuditor
pveum useradd pve_exporter@pve
pveum usermod pve_exporter@pve -group monitoring
pveum passwd pve_exporter@pve

Allez, c’est bon, vous avez assez patienté, vous pouvez vous connecter à votre Proxmox VE ! Rendez-vous sur :

https://@IPmachine:8006 ou
https://proxmox.example.org:8006

Note : pour l’instant, le certificat est autosigné et le navigateur va nous remonter une erreur. On peut accepter d’ignorer le problème pour l’instant.

N’oubliez pas de changer le “realm” de PAM (les utilisateurs unix, qu’on n’utilise pas ici) à “Proxmox” pour pouvoir utiliser l’administrateur qu’on vient de créer.

À bientôt pour la suite. Et en attendant, have fun!

Proxmox VE 6 + pfsense sur un serveur dédié (2/2)

Mon, 09 Mar 2020 11:49:55 +0000

Note de zwindler : cet article a été co-écrit par Charles Bordet, et se veut être une version à jour de cette suite d’articles écrits sur ce blog (mais avec des versions obsolètes de Proxmox et de PFSense). Merci à lui !

Dans l’article précédent, nous avons mis en place notre serveur Proxmox, l’avons sécurisé, puis avons téléchargé puis installé une machine virtuelle PFSense qui va nous faire office de point d’entrée unique.

Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Routage du trafic vers la PFSense

Comme nous l’avons déjà évoqué, l’hyperviseur est en première ligne. Et la PFSense est en 2e ligne et nos VMs, bien au chaud derrière.

L’objectif, c’est d’avoir la PFSense en 1e ligne. D’un point de vue purement réseau, l’hyperviseur va s’effacer en ne devenant rien de plus qu’un routeur.

La première chose à corriger, c’est qu’actuellement, il existe un raccourci qui permet de passer directement de l’hyperviseur aux VMs puisqu’ils sont tous sur le réseau LAN. Dans notre schéma mental, on ne veut pas que ce soit possible puisque tout doit passer par pfsense.

Essayez par exemple de pinger 192.168.9.10 depuis l’hyperviseur, ou de pinger 192.168.9.1 depuis la VM.

Sur l’hyperviseur, on va ajouter une route qui dit : Tous les paquets vers le LAN doivent passer par l’interface WAN de la PFSense. C’est cette règle qui nous permet de forcer tout le trafic à passer par la PFSense, comme si la PFSense était en frontal, avant d’arriver dans le LAN.

On crée un fichier /root/pfsense-route.sh` avec la commande suivante.

cat > /root/pfsense-route.sh << EOF
#!/bin/sh
## IP forwarding activation
echo 1 > /proc/sys/net/ipv4/ip_forward
## Rediriger les paquets destinés au LAN pour l'interface WAN de la PFSense
ip route change 192.168.9.0/24 via 10.0.0.2 dev vmbr1
EOF

Pour que ce fichier se lance automatiquement dès qu’on boot, on lance la commande chmod +x /root/pfsense-route.sh et on ajoutera à la fin du fichier /etc/network/interfaces la ligne post-up /root/pfsense-route.sh à la fin du bloc de configuration de vmbr2, juste avant le commentaire #LAN :

[...]
auto vmbr2
iface vmbr2 inet static
address 192.168.9.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up /root/pfsense-route.sh
#LAN

Si vous exécutez ce fichier /root/pfsense-route.sh, et que vous essayez de nouveau de ping l’hyperviseur depuis la VM, ou l’inverse, ça ne devrait plus aboutir. Cela signifie que le petit paquet essaye bien de passer par PFSense, et comme on lui a rien dit, PFsense drop sans mot dire.

Note: Ça veut aussi dire que notre beau tunnel SSH ne fonctionnera plus à terme (si vous avez choisi cette solution plutôt que la “VM rebond”)…

Si jamais, pour débugger, vous avez besoin de laisser passer le ping, on peut le réactiver de manière sélective dans PFSense.

Dans l’interface de la PFSense, on va commencer par aller dans Status / System Logs. Puis cliquez sur l’onglet Firewall. Le but ici c’est de vous montrer un moyen de débugger au cas où vous auriez des problèmes.

Sur cette page, vous verrez toutes les connexions bloquées par le pare-feu.

Si vous descendez dans la page, vous allez voir les pings qui ont été bloqués.

Cette vue est utile car elle vus permet de voir tout ce qui a été récemment bloqué. Les petits (-) et les petits (+) vont vous permettre d’ajouter rapidement des règles, respectivement pour dropper ou autoriser des connexions similaires que PFSense rencontrerait à l’avenir.

Si vous voulez tout faire vous même (car vous souhaitez comprendre et maitriser ce que vous faites), allez plutôt dans Firewall/Rules. Cliquez sur Add puis entrez les paramètres suivants :

Action : Pass
Interface : WAN
Address Family : IPv4
Protocol : ICMP
Source : Any
Destination : Any

Cette règle assez permissive permet d’autoriser tous les paquets en protocole ICMP. Une fois ajoutée, n’oubliez pas d’appliquer les changements. Puis réessayez de faire pinger vos machines. Le ping est de retour ! Mais il passe par la PFSense cette fois-ci.

Port forwarding de la PFSense

Maintenant que la base de notre script fonctionne, on va continuer à ajouter des règles iptables. Comme il est assez long, je vais vous l’expliquer et on va le remplir au fur et à mesure. Pour ceux qui veulent la version complète du fichier immédiatement, elle est disponible ici.

Note : Le gros souci avec iptables` et les règles de firewalling en général, c’est que même quand on est expert, si jamais vous vous êtes planté (ou que pour une raison ou pour une autre, les commandes que je donne ne sont pas 100% compatibles dans votre contexte il y a une petite subtilité) vous risquez de vous couper l’accès.

Un bon moyen de limiter ce genre de risque est de suivre la procédure suivante à chaque fois que vous faites une modification :

faire une copie datée des fichiers /etc/network/interfaces, /root/pfsense-route.sh et /root/iptables.sh avant toute modif
désactiver/supprimer les lignes avec le post-up /root/pfsense-route.sh et/ou /root/pfsense-route.sh dans /etc/network/interfaces, ce qui vous permettra de retrouver la main après une reboot
exécuter le script à la main une première fois, puis ne rebooter seulement que SI TOUT fonctionne (en testant de nouvelles connexions)

Si jamais vous vous êtes scié la jambe (ou la branche, ou tiré une balle dans le pied), un reboot et une restauration du fichier initial vous tirera d’affaire.

Note bis Ne lancez pas non plus ces instructions une par une. En effet, la première chose qu’on fait, par convention, c’est de TOUT dropper, pour re-autoriser ensuite au compte goûte. Donc si vous avez de grande chance de vous bloquer vous même.

1/6 Variables

Avant de commencer quoique ce soit, récupérez l’adresse IP publique de votre machine. On en aura besoin dans le script. Vous pouvez la trouver dans l’interface de votre Proxmox si elle est visible depuis votre hyperviseur, ou a minima dans l’interface de votre provider.

Ensuite, on l’exporte dans le bash pour qu’elle soit intégrée de manière transparente dans le futur script iptables.sh

export PUBIP=xx.xx.xx.xx

Faite ensuite la même chose pour le port que vous avez choisi dans le tuto précédent pour SSH (22 par défaut, mais le tuto précédent donne un port arbitraire, 22153)

export SSHPORT=22153

Puis créez la première partie du script en copiant collant simplement cette commande en entier dans un terminal (le cat` va copier proprement les lignes dans un fichier texte)

cat > /root/iptables.sh << EOF
#!/bin/sh
# ---------
# VARIABLES
# ---------
## Proxmox bridge holding Public IP
PrxPubVBR="vmbr0"
## Proxmox bridge on VmWanNET (PFSense WAN side)
PrxVmWanVBR="vmbr1"
## Proxmox bridge on PrivNET (PFSense LAN side)
PrxVmPrivVBR="vmbr2"
## Network/Mask of VmWanNET
VmWanNET="10.0.0.0/30"
## Network/Mmask of PrivNET
PrivNET="192.168.9.0/24"
## Network/Mmask of VpnNET
VpnNET="10.2.2.0/24"
## Public IP => Your own public IP address
PublicIP="${PUBIP}"
## Proxmox IP on the same network than PFSense WAN (VmWanNET)
ProxVmWanIP="10.0.0.1"
## Proxmox IP on the same network than VMs
ProxVmPrivIP="192.168.9.1"
## PFSense IP used by the firewall (inside VM)
PfsVmWanIP="10.0.0.2"
EOF

Cette première partie est inoffensive, on définit les variables. Ça permet d’éviter de ré-écrire des milliers de fois les mêmes adresses IPs et de rendre le script un peu plus lisible.

Point très important, vérifiez bien que le fichier contient bien votre adresse IP publique à la ligne qui commence par PublicIP=

2/6 DROP & start again !

Par contre, à partir de maintenant ça se gâte. Par défaut, on spécifie qu’on interdit tout. Tous les paquets sont droppés.

cat >> /root/iptables.sh << EOF
# ---------------------
# CLEAN ALL & DROP IPV6
# ---------------------
### Delete all existing rules.
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
### This policy does not handle IPv6 traffic except to drop it.
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP
# --------------
# DEFAULT POLICY
# --------------
### Block ALL !
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
# ------
# CHAINS
# ------
### Creating chains
iptables -N TCP
iptables -N UDP
# UDP = ACCEPT / SEND TO THIS CHAIN
iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP
# TCP = ACCEPT / SEND TO THIS CHAIN
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
# ------------
# GLOBAL RULES
# ------------
# Allow localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Don't break the current/active connections
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow Ping - Comment this to return timeout to ping request
iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
EOF

Ensuite, on crée des chaînes qui vont capturer toutes les nouvelles connexions TCP et UDP, respectivement. Et enfin, on ajoute des règles un peu de base :

On accepte les connexions localhost
On ne stoppe pas les connexions existantes. Comme votre connexion SSH par exemple.
On autorise les pings. Parce que c’est pratique pour débugger.

Si vous vous demandez ce qui se passerait si vous lanciez le script maintenant, il ne se passerait rien, tant que vous n’essayeriez pas d’ouvrir une nouvelle connexion (SSH par exemple), car on accepte les connexions déjà ouvertes. En revanches, toutes les nouvelles échoueraient…

Pas terrible, donc on continue…

3/6 INPUT

cat >> /root/iptables.sh << EOF
# --------------------
# RULES FOR PrxPubVBR
# --------------------
### INPUT RULES
# ---------------
# Allow SSH server
iptables -A TCP -i \$PrxPubVBR -d \$PublicIP -p tcp --dport ${SSHPORT} -j ACCEPT
# Allow Proxmox WebUI
iptables -A TCP -i \$PrxPubVBR -d \$PublicIP -p tcp --dport 8006 -j ACCEPT
EOF

Ces règles sont à propos de l’interface vmbr0, celle qui nous relie à Internet. On ajoute deux règles :

On autorise les nouvelles connexions sur le port SSH qui passent par vmbr0 et dont la destination est notre IP publique.
On autorise les nouvelles connexions sur le port 8006 qui passent par vmbr0 et dont la destination est notre IP publique.

Ça c’est seulement pour les paquets entrant, donc les personnes qui veulent initier une connexion avec nous.

Note : vérifiez bien que la ligne juste en dessous de # Allow SSH server contient bien le port que vous utilisez pour SSH (et qu’on a exporté dans la variable SSHPORT) !

Plus tard, on pourra même supprimer ces règles. À la place, on se connectera au VPN, et à partir de là on aura accès au SSH ou au Proxmox.

4/6 OUTPUT

Ensuite, on ajoute les paquets sortants :

cat >> /root/iptables.sh << EOF
### OUTPUT RULES
# ---------------
# Allow ping out
iptables -A OUTPUT -p icmp -j ACCEPT
### Proxmox Host as CLIENT
# Allow HTTP/HTTPS
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --dport 443 -j ACCEPT
# Allow DNS
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p udp --dport 53 -j ACCEPT
### Proxmox Host as SERVER
# Allow SSH
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --sport ${SSHPORT} -j ACCEPT
# Allow PROXMOX WebUI
iptables -A OUTPUT -o \$PrxPubVBR -s \$PublicIP -p tcp --sport 8006 -j ACCEPT
EOF

D’abord, on autorise les pings à sortir. Cette règle est redondante avec une autre précédente où on autorisait les pings dans tous les sens.

L’idée, c’est que la règle précédente est très permissive pour pouvoir debugger. Mais elle est pas censée rester pour toute la vie.

Par contre, autoriser un ping sortant, ça peut toujours servir à l’occasion, et ça pose zéro problème de sécurité.

Puis j’autorise les paquets HTTP et HTTPS à sortir. Ça c’est ce qui va nous donner accès à l’internet. D’ailleurs vous pouvez essayer. Envoyez un ping vers 1.1.1.1 avant d’entrer ces nouvelles règles, ça devrait être bloqué, puis ré-essayez après avoir entré ces nouvelles règles, et ça devrait marcher !

Cette règle vous servira par exemple à télécharger des images ISO ou à mettre à jour le serveur. Ce n’est pas cette règle qui sert à donner accès à l’internet au VM par contre.

Et c’est tout pour les règles output. Vous noterez que m4vr0x en avait ajouté pas mal plus. Je vous conseille d’en rajouter seulement si vous en avez besoin. De base, on est parcimonieux.

Par exemple les règles output pour le port SSH et le port 8006 ne sont pas nécessaires. En effet, on les accepte déjà dans INPUT, ce qui permet à votre ordinateur local d’initier une connexion avec le serveur. Une fois la connexion initiée, tous les paquets sont autorisés (c’est la règle qu’on avait ajouté dans les GLOBAL RULES). La plupart des règles concernent les nouvelles connexions.

5/6 FORWARD

Finalement, il ne reste plus qu’à dire qu’on route tout le trafic vers la PFSense :

cat >> /root/iptables.sh << EOF
### FORWARD RULES
# ----------------
### Redirect (NAT) traffic from internet
# All tcp to PFSense WAN except ${SSHPORT}, 8006
iptables -A PREROUTING -t nat -i \$PrxPubVBR -p tcp --match multiport ! --dports ${SSHPORT},8006 -j DNAT --to \$PfsVmWanIP
# All udp to PFSense WAN
iptables -A PREROUTING -t nat -i \$PrxPubVBR -p udp -j DNAT --to \$PfsVmWanIP
# Allow request forwarding to PFSense WAN interface
iptables -A FORWARD -i \$PrxPubVBR -d \$PfsVmWanIP -o \$PrxVmWanVBR -p tcp -j ACCEPT
iptables -A FORWARD -i \$PrxPubVBR -d \$PfsVmWanIP -o \$PrxVmWanVBR -p udp -j ACCEPT
# Allow request forwarding from LAN
iptables -A FORWARD -i \$PrxVmWanVBR -s \$VmWanNET -j ACCEPT
EOF

Le début est une règle de PREROUTING. Ça veut dire que l’action s’exécute sur le paquet avant toute autre chose. Par exemple, si José essaie de se connecter sur le port 3812 de votre Nextcloud, on veut pas forcément le dropper. Ce genre de décision sera le futur boulot de la PFSense. Sans la règle de pré-routing, le paquet serait droppé par défaut.

Donc à la place, on l’envoie… vers la PFSense.

Notez que cette règle s’applique SAUF pour les ports SSH et 8006, qui ont un traitement un peu particulier. De nouveau, plus tard, quand vous aurez mis le VPN, on pourra aussi supprimer ces règles.

Le paragraphe suivant va de pair avec ce qu’on vient de faire. En gros ça dit : Si un paquet est en transfert d’Internet vers la PFSense, alors on l’autorise. Et ça tombe bien, puisqu’on vient juste de dire que tous les paquets qui viennent d’Internet sont automatiquement transférés vers la PFSense.

Finalement, on fait aussi l’inverse. Tous les paquets qui sont en transfert depuis la PFSense (et donc qui se dirigent de toute vraisemblance vers Internet) sont acceptés aussi. La communication, ça va dans les deux sens.

Donc là, je résume : Un paquet vient d’Internet. On le pré-route vers la PFSense. On accepte ce transfert. La PFSense le reçoit. La PFSense va prendre une décision, par exemple l’envoyer vers une VM, recevoir une réponse, puis renvoyer ce paquet vers Internet. On accepte ce transfert de nouveau.

On a tout ce qu’il faut pour que les VMs aient accès à Internet.

6/6 MASQUERADE

SAUF ! Le port forwarding. La petite astuce en gros qui permet à une machine d’un réseau local à accéder à Internet sans avoir d’IP publique :

cat >> /root/iptables.sh << EOF
### MASQUERADE MANDATORY
# Allow WAN network (PFSense) to use vmbr0 public adress to go out
iptables -t nat -A POSTROUTING -s \$VmWanNET -o \$PrxPubVBR -j MASQUERADE
EOF

A partir de là, le script est prêt. Tentez de l’exécutez et si vous ne vous jetez pas dehors bravo vous avez gagné !

chmod +x /root/iptables.sh
/root/iptables.sh

Là maintenant votre LAN est raccordé à Internet.

Spécificité VirtIO

Sauf si… vous aviez choisi VirtIO comme modèle de carte réseau dans le tuto précédent.

Si vous pingez 1.1.1.1 depuis votre VM Ubuntu, vous allez réussir à joindre Internet. C’est un signe que les règles que nous avons mises fonctionnent bien. Mais… pourtant, l’accès à Internet ne va pas forcément marcher.

C’est un problème qui m’a cassé la tête pendant longtemps. Jusqu’à ce que je tombe sur ce thread au titre évocateur : “Quelqu’un a-t-il réussi à *** un *** de PFSense avec Proxmox (lien mort)”

En fait, la solution est documentée sur le site officiel de pfsense (lien mort, j’utilise Internet Archive)

La solution est donc d’aller dans System / Advanced / Networking au niveau des paramètres PFSense et de cocher la case Disable hardware checksum offload.

Et pouf, ça marche.

On est pas mal là ?

A partir de maintenant, vous pouvez vous amuser à regarder les logs du firewall de la PFSense et vous verrez toutes les gentilles personnes qui se font refouler.

On a bien avancé, mais il reste encore quelques petits détails à voir :

On doit toujours passer par une VM Ubuntu Desktop pour paramétrer la PFSense. Pas pratique.
Le Proxmox est accessible depuis Internet. Pas optimal niveau sécurité.
On ne sait pas comment servir un service depuis une VM qui soit accessible depuis Internet (un serveur nginx par exemple).
Et aussi comment servir un service pour des besoins internes (un serveur SSH par exemple).

On va voir comment résoudre tout ça dans la prochaine partie. Et puis après on verra comment mettre un VPN en place pour que ce soit bien sécurisé.

Hébergement de services

Mais je suis sûr que vous avez hâte d’utiliser le potentiel de votre hyperviseur dès maintenant ! En tout cas, moi j’avais hâte :D

Donc faisons-le, mais promettez-moi qu’après vous ferez les étapes pour mettre le VPN ;-p

Un serveur nginx sur Internet

Pour l’exemple ici, on va utiliser notre VM UbuntuDesktop. C’est vraiment pour l’exemple, parce que je pense que c’est mieux d’isoler les services. 1 VM = 1 service.

On va donc aller sur la VM, et dans le terminal on install nginx: sudo apt install nginx (faites un update d’abord).

Une fois l’installation faite, vérifiez que le serveur fonctionne bien en allant sur http://localhost à partir de la VM. Vous devriez voir l’écran de bienvenue de nginx.

Maintenant, on veut arriver à accéder à cette page depuis Internet. Depuis chez nous quoi. Pour ça, on va aller dans la configuration de la PFSense, et cliquer sur Firewall/NAT, puis ajouter :

Interface : WAN
Protocol : TCP
Destination : Any
Destination Port Range : 8001
Redirect target IP : 192.168.9.10
Redirect target port : 80
Description : Serveur nginx

Ici il faut bien avoir en tête qu’on se met du point de vue de la VM dans le LAN. Donc destination signifie la destination du paquet qui part de la VM. On veut qu’il arrive d’Internet, sur le port 8001. Ce choix de port est complètement libre.

Le Redirect target IP, c’est l’IP de la VM, ainsi que le port initial du serveur nginx. Là on n’a pas le choix par contre.

On valide et on applique les changements.

Vous remarquerez qu’une règle a automatiquement été ajoutée dans Firewall/Rules. Oui parce que c’est bien de mettre un NAT en place, mais si le port 80 n’est pas ouvert au niveau de la PFSense, les paquets ne passeront pas.

On attend une petite minute, et on essaie d’accéder : http://proxmox.example.org:8001.

Gagné !

Un serveur SSH sur l’internet privé

Bon, maintenant supposons qu’on veuille mettre en place un serveur SSH.

Oui parce que la console via l’interface de Proxmox, c’est ok, mais bon, autant utiliser le terminal dont on a l’habitude.

C’est différent du serveur nginx parce que cette fois-ci, on n’a pas besoin de le déployer publiquement. Moi je dis que si un service est réservé à un usage privé, il faut le laisser privé. Sinon on multiplie les angles d’attaque pour les méchants.

Donc là l’objectif c’est de pouvoir se connecter en SSH sur notre machine UbuntuDesktop à partir de l’hyperviseur. Donc oui, il faut d’abord SSH dans l’hyperviseur, et à partir de là, on SSH dans la VM. Trop d’étapes ? Plus tard, avec le VPN, vous pourrez directement SSH dans la machine sans cette étape intermédiaire.

Premièrement, installons le serveur SSH sur la VM Ubuntu : sudo apt install openssh-server. De base, il va écouter sur le port 22, et on va laisser ça comme ça.

Vous l’avez compris, il va falloir ouvrir le port sur la PFSense. Pas de NAT cette fois-ci, juste une ouverture de port. Donc dans Firewall/Rules :

Action : Pass
Interface : WAN
Address Family : IPv4
Protocol : TCP
Source : Single host = 10.0.0.1
Destination : LAN net (on pourrait se limiter à notre VM, mais on va probablement vouloir se connecter en SSH systématiquement à toutes les VMs)
Destination port Range : 22
Description : SSH pour les VMs

On valide, on applique les changements, on attend une petite minute, et on essaie depuis l’hyperviseur : ssh charles@192.168.9.10.

Timeout.

Ah !

Pourquoi ?

C’est là que je vous annonce que tout à la fin de ce tutorial, vous trouverez une section Comment débugger qui vous apprendra comment écouter des paquets et comprendre ce qui se passe sur vos machines. Voici un petit récap en attendant.

Un moyen de comprendre les flux de paquets, pourquoi ils sont bloqués, où est-ce qu’ils sont bloqués, etc., c’est d’utiliser la commande tcpdump qui permet de sniffer le trafic sur votre machine. Cette commande m’a énormément aider pour suivre le tuto de m4vr0x, donc je vous donne l’astuce aussi.

Un tcpdump -i vmbr1 -p tcp permet d’écouter sur l’interface WAN. Outre le bruit des méchants qui tapent à votre porte, on s’attend à voir des paquets SSH aller de 10.0.0.1 vers 192.168.9.10. Il n’en est rien. Ça veut dire quoi ? Ça veut dire que les paquets ne partent même pas de la machine. Pourquoi ? …

Les iptables ! Mais oui. On n’a jamais dit qu’on acceptait de faire sortir des paquets sur le port 22.

Une autre astuce de tonton : Dans le fichier iptables qu’on avait créé, vous pouvez rajouter l’instruction suivante : iptables -A OUTPUT -p tcp -o vmbr1 -j LOG.

Placez-la avant les instructions qui bloquent tout (donc vers le début du fichier). Ça vous permettra d’enregistrer tout le trafic qui correspond à l’instruction (en l’occurrence, ici, les paquets sortants en TCP sur l’interface vmbr1), et donc de voir ce qui est bloqué et ce qui ne l’est pas. Les logs s’enregistrent dans /var/log/syslog.

Ici, tout simplement, on va dire qu’on autorise les paquets à sortir sur l’interface vmbr1. Rajoutez à la fin du fichier iptables ces quelques lignes :

cat >> /root/iptables.sh << EOF
# --------------------
# RULES FOR PrxVmWanVBR
# --------------------
### Allow being a client for the VMs
iptables -A OUTPUT -o \$PrxVmWanVBR -s \$ProxVmWanIP -p tcp -j ACCEPT
EOF

(Promis, on y touche plus)

Ici, vous avez peut-être deux questions qui vous viennent à l’esprit.

On avait pas déjà l’ensemble du trafic qui était autorisé de l’hyperviseur vers la PFSense ?! Alors, oui, mais seulement en FORWARD. On avait mis une règle qui acceptait tous les paquets qui provenaient d’Internet et qui étaient transférés vers la PFSense. Là, dans ce cas, on accepte tous les paquets en provenance de l’hyperviseur vers la PFSense.

Pourquoi on ne limite pas au port 22 ? C’est un peu brutal cette ouverture générale non ? C’est vrai. L’idée, c’est de ne pas avoir à toucher à ce fichier dès qu’on veut rajouter un service. On sous-traite la gestion des autorisations à la PFSense. Et comme c’est seulement les connexions qui sont issues de l’hyperviseur, donc les communications internes, ce n’est pas gênant.

De nouveau, le VPN résoudra ce genre de problèmes.

À présent, essayez de vous connecter en SSH depuis l’hyperviseur vers la VM, et ça marche !

Accéder à la PFSense depuis Internet

Dernier petit point important avant de passer au VPN : Comment accéder à la PFSense depuis votre laptop sans utiliser cette VM qui lag du cul ? (Oui bon désolé mais là j’écris ce tutorial en étant en Asie et ma VM est en Allemagne, c’est horrible le lag !)

~~C’est très simple. On va juste ouvrir le port HTTPS sur la PFsense. Ajoutons la règle suivante :~~

~~Action : Pass~~
~~Interface : WAN~~
~~Address Family : IPv4~~
~~Protocol : TCP~~
~~Source : Any~~
~~Destination : This firewall (self)~~
~~Destination Port Range : HTTPS~~
~~Description : Accès à la PFSense depuis Internet~~

~~À présent, si vous vous connectez sur https://example.org, vous pourrez accéder à la PFSense.~~

Note de zwindler : On préférera plutôt ajouter une règle similaire à la précédente qui autorise 10.0.0.1 à accéder à 192.168.9.254 sur le port 443. Ceci nous permettra de refaire marcher notre tunnel SSH (qui ne marche plus depuis qu’on a ajouté la route en tout début de ce 2ème article) pour avoir la console pfsense en local sur votre machine Linux ou Windows.

Sécuriser les services privés avec un VPN

Bon, c’est bien tout ça. On est presque au bout.

Mais il reste des problèmes :

J’aime pas trop avoir cette PFSense accessible par n’importe qui (zwindler: “moi non plus”). Y’a que moi qui en ai besoin après tout.
Pareil pour l’hyperviseur Proxmox, que ce soit au niveau de l’accès SSH ou de l’interface web.
Et puis c’est chiant pour SSH dans une VM. Il faut faire 2 étapes. C’est long 2 étapes !

Woh woh.. calmos ! Le VPN va résoudre tous ces problèmes.

L’idée c’est qu’on va créer un nouveau réseau virtuel : 10.2.2.0/24. La PFSense sera dans ce réseau virtuel. Et on va pouvoir se connecter dans ce réseau virtuel, de telle sorte que notre laptop aura une IP privée du type 10.2.2.2 (le 10.2.2.1 sera réservé à la PFSense).

À partir de là, modulo 2-3 changements, on pourra accéder au LAN à travers la PFSense. Et évidemment, il n’y a que nous qu’on aura le droit de se connecter au VPN. Et le truc super cool, c’est que la PFSense rend cette création de VPN su-per-sim-ple. Allez, c’est parti ! Déjà, il faut créer des certificats.

Création de l’autorité de certification

Dans la PFSense, on clique sur System/Cert. Manager. puis Ajouter :

Descriptive Name : L’autorité de Certification
Method : Create an internal Certificate Authority
Key length : 2048 (note de zwindler: MINIMUM, n’hésitez pas à mettre 4096)
Digest Algorithm : sha256
Lifetime : 3650
Common Name : example.org (changez pour le nom de votre autorité)
Country Code : FR

Création du certificat pour le serveur

Maintenant on clique sur l’onglet « Certificates », puis Ajouter :

Method : Create an internal Certificate
Descriptive Name : Le serveur VPN
Certificate authority : Choisissez votre autorité de certification nouvellement créée
Key length : 2048 (note de zwindler: MINIMUM, n’hésitez pas à mettre 4096)
Digest Algorithm : sha256
Lifetime : 3650
Common Name : vpn.example.org (changez pour le nom du serveur VPN)
Certificate Type : Server Certificates

Création du certificat pour le client

On recrée un nouveau certificat, mais changer le type à la fin :

Method : Create an internal Certificate
Descriptive Name : Le client VPN
Certificate authority : Choisissez votre autorité de certification nouvellement créée
Key length : 2048 (note de zwindler: MINIMUM, n’hésitez pas à mettre 4096)
Digest Algorithm : sha256
Lifetime : 3650
Common Name : vpn-client.example.org (changez pour le nom du client VPN)
Certificate Type : User Certificates

C’est fini pour la création de certificats !

Création du serveur VPN

On va dans VPN/OpenVPN et Ajouter :

Server mode : Remote Access (TLS + User Auth)
Protocol : UDP
Interface : WAN
Local Port : 18223 : De nouveau, on change le port par défaut.
Description : Mon VPN
TLS Configuration : Activé
Peer Certificate Authority : Choisissez votre autorité de certification
Server Certificate : Choisissez le certificat pour le serveur
DH Parameter Length : Note de zwindler - n’hésitez pas à passer à 4096
Encryption Algorithm : N’hésitez pas à choisir un peu plus que le choix par défaut AES-128
IPv4 Tunnel Network : 10.2.2.0/24
Redirect IPv4 Gateway : Activé. Cette case vous permettra d’accéder à l’internet à travers le VPN. Sinon, vous pouvez spécifier le réseau local auquel vous souhaitez accéder avec le VPN (192.168.9.0/24 dans notre cas).
Concurrent connections : 3. Une pour l’ordi, une pour le téléphone, et une pour un attaquant. Non je déconne :D Mettez 2. Ou en tout cas, mettez le nombre correspondant au nombre d’appareils que vous connecterez simultanément.
Compression : Disable Compression. Conseillé pour ne pas être sensible aux attaques VORACLE.
Push Compression : Cochez la case. Ne pas cocher cette case m’empêchait de me connecter via mon laptop sous linux. Mais ça marchait avec Android. Cocher juste la case et épargnez-vous le mal de crâne.
Dynamic IP : Cochez la case.

Et voilà ! Maintenant il nous faut un utilisateur et on pourra se connecter.

Création de l’utilisateur pour le VPN

Dans System/User manager, cliquez sur Ajouter.

Disabled : On ne coche pas la case.
Username : charles
Password : xxx

Enregistrer. Puis retournez éditer l’utilisateur et ajoutez-lui le certificat client que nous avons créé plus tôt. Dans User Certificates, cliquez sur Ajouter, puis :

Method : Choose an existing certificate
Existing Certificate : Le Client VPN

On enregistre.

Configuration du client

On est bon ! On peut facilement exporter un fichier de configuration pour automatiquement configurer votre client VPN, que ce soit sous Windows, Mac, Linux, Android, ou votre machine à café intelligente. Oui oui, il est conseillé de connecter vos objects connectés à un VPN si vous souhaitez y accéder à distance. Ce sont de vraies passoires de sécurité.

On va dans System/Package Manager, puis Available Packages, et on cherche export.

Puis on install openvpn-client-export. On retourne dans VPN/OpenVPN, et on trouve le nouvel onglet Client Export.

Remote Access Server : Mon VPN
Host Name Resolution : Other puis on renseigne l’IP publique de notre serveur.
Use Random Local Port : On coche la case.

On enregistre et on scrolle jusqu’en bas.

Ici on a plein de possibilités d’exports.

Moi je prends le Most Clients parce que ça marche chez moi.

Voilà voilà.

Ensuite, sur mon ordinateur local, qui est un Ubuntu, je vais dans la configuration Réseau, et je clique sur le petit + à côté de VPN. Je choisis “Import from file…” et j’importe le fichier que je viens juste de télécharger. Il vous faudra peut-être installer le client openvpn d’abord, si vous n’avez pas l’option.

Normalement, tout est déjà pré-rempli, sauf, le username et le password. Entrez ceux de l’utilisateur qu’on a créé plus tôt.

Et voili voiloù !

Ça marche chez vous ?

Parce que chez moi, pas encore…

Ah oui. Toujours ces histoires de pare-feu. C’est ennuyant à la fin.

Ouverture des chakras

Il y a deux modifications à faire.

Imaginez un paquet du VPN. Il arrive sur votre serveur. Il demande son chemin pour aller vers son réseau, c’est-à-dire 10.2.2.0/24. Que lui dit la table de routage ?

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 xx.xx.xx.xx 0.0.0.0 UG 0 0 0 vmbr0
10.0.0.0 0.0.0.0 255.255.255.252 U 0 0 0 vmbr1
xx.xx.xx.xx 0.0.0.0 255.255.255.224 U 0 0 0 vmbr0
192.168.9.0 10.0.0.2 255.255.255.0 UG 0 0 0 vmbr1

En gros : retourne chez toi.

On va rajouter une route pour le VPN. Retournez dans le fichier /root/pfsense-route.sh` et rajoutez cette ligne :

## Rediriger les paquets destinés au VPN pour l'interface WAN de la PFsense
ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1

Ensuite, exécuter le fichier. Assurez-vous que la route est bien correcte avec netstat -r -n.

Là on dit aux paquets destinés au réseau VPN d’aller vers la PFSense. Elle saura bien quoi en faire. Est-ce qu’on doit modifier les iptables ? Non, les paquets en transfert qui viennent d’Internet sont déjà acceptés.

Alors c’est bon ?

Non.

Il faut que la PFSense accepte ces paquets aussi. Dans l’interface, on rajoute deux règles. La première dit d’accepter les paquets en UDP qui sont à destination de la PFSense sur le port du VPN :

Action : Pass
Interface : WAN
Address Family : IPv4
Protocol : UDP
Source : Any
Destination : WAN net
Destination port range : 18223 (mettez le port du VPN)
Description : Accès au VPN depuis Internet

Maintenant, vous pouvez tester le VPN. Vous devriez pouvoir vous connecter et aussi accès à Internet en étant connecté. Oubliez pas d’activer les changements après avoir créé la règle, ça m’arrive tout le temps.

Ah oui en fait non, vous n’allez pas avoir accès à Internet. On n’a pas autorisé les paquets qui proviennent du VPN. On ajoute cette nouvelle règle :

Action : Pass
Interface : OpenVPN
Address Family : IPv4
Protocol : Any
Source : Network - 10.2.2.0/24
Destination : Any
Description : Accès à Internet depuis le VPN

Et voilà ! À présent, depuis le VPN, vous avez accès à :

Internet
Les services du WAN, c’est-à-dire la PFSense et le Proxmox (et le SSH vers Proxmox)
Le réseau LAN. Tapez par exemple 192.168.9.10 dans votre navigateur, et vous tomberez sur le serveur nginx qu’on a déployé plus tôt.

C’est pas beau ça ?

Bravo ! C’est un solide travail que vous avez fait pour en arriver là.

Le VPN vous sauvera

On pourrait s’arrêter là.. Sauf que. J’ai pas arrêté de vous dire tout le long du tuto que « Tel truc sera résolu quand on aura le VPN ». Eh bien il est temps de résoudre ces problèmes.

Protéger la PFSense

Déjà, la PFSense. À l’heure actuelle, elle est disponible sur les internets mondiaux. Si vous allez voir les logs, vous verrez plein d’individus qui s’y heurtent. C’est pas forcément très rassurant.

Et puis, est-ce qu’on a vraiment besoin d’avoir l’interface disponible à la vue de tout le monde ? Bien sûr que non.

Alors supprimez-moi cette règle qu’on avait ajouté :

Dans le doute, vous pouvez seulement désactiver la règle en cliquant sur le ✓. Ça vous évitera de la recréer complètement si vous vous êtes planté quelque part.

Vous n’aurez plus accès en tapant https://example.org mais plutôt l’IP du LAN : https://192.168.9.254. Pour changer le domaine, il faudra mettre en place un serveur DNS interne.

Si vous retournez dans les logs, vous n’en verrez pas moins. Vous en verrez encore plus même ! Puisqu’à présent, vous verrez le blocage du port 443.

Protéger l’interface web du Proxmox

Là, on va faire pareil, mais un peu différent. À l’heure actuelle, on accède à l’interface web de Proxmox sans passer par la PFSense.

À la place, on va :

Rediriger le port 8006 vers la PFSense (en supprimant l’exception dans les iptables). Ceci annulera l’accès depuis Internet.
Autoriser d’accéder au port 8006 du serveur proxmox depuis la PFSense. Ceci activera l’accès depuis le VPN.

Dans le fichier des iptables, on va éditer la ligne suivante :

iptables -A PREROUTING -t nat -i $PrxPubVBR -p tcp --match multiport ! --dports 21153,8006 -j DNAT --to $PfsVmWanIP

On supprime tout simplement le 8006. Et on exécute le fichier. À présent, vous n’avez plus accès à l’interface web Proxmox du tout ! Oh, et on peut aussi supprimer ces lignes là : la règle qui accepte les paquets sur 8006 aussi, cette ligne-là :

iptables -A TCP -i $PrxPubVBR -d $PublicIP -p tcp --dport 8006 -j ACCEPT
iptables -A OUTPUT -o $PrxVmWanVBR -s $ProxVmWanIP -p tcp -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

Autrement dit :

On arrête d’accepter les pings dans tous les sens
On arrête d’accepter les paquets entrant sur 8006
On arrête d’accepter les paquets sortant sur le port SSH

Rappelez-vous que le serveur Proxmox n’est pas une VM ordinaire. C’est une VM avec un fichier iptables ! Il faut juste qu’on lui dise d’accepter les paquets qui viennent de la PFSense. Par où ? Par vmbr1. Rappelez-vous qu’on a condamné l’accès vmbr2. Voici la règle à rajouter dans les iptables :

iptables -A TCP -i $PrxVmWanVBR -d $ProxVmWanIP -p tcp --dport 8006 -j ACCEPT

Exécutez le fichier. À présent, vous pouvez accéder à https://10.0.0.1:8006.

Est-ce qu’on a besoin d’ajouter une règle dans PFSense ? Non ! On a déjà une règle qui dit : Depuis le VPN, on a accès à tout.

Protéger le SSH du Proxmox

Bon. Là, on pourrait faire exactement la même opération pour protéger le SSH du Proxmox. De telle sorte qu’il ne soit accessible que depuis le VPN.

Mais ça devient un peu dangereux… Qu’est-ce qui se passe si vous perdez accès au VPN ? Genre vous supprimez la config par erreur. Ou votre ordi meurt et vous n’avez pas backup la config ?

Vous allez passer un sale dimanche.

Alors il est toujours possible de résoudre le problème si votre provider vous donne un accès à la console. Je sais que chez Hetzner, c’est possible gratuitement pendant 3 heures. Mais il faut prendre rendez-vous, c’est un peu galère.

C’est pourquoi mon choix est de garder l’accès SSH sur Internet. Par contre, il faut être bien sûr d’avoir activé fail2ban.

Ah ? On me dit dans l’oreillette que le script iptables efface toutes les règles de fail2ban. Oops.

À la fin du script des iptables, on rajoute l’instruction suivante : service fail2ban restart.

Dernière petite chose : Le script iptables ne se lance pas automatiquement au boot. Donc si le Proxmox redémarre, pouf on perd toutes nos règles. C’est beta.

Pour résoudre ça, on va lancer apt install iptables-persistent`. Suivez les consignes, et à présent les règles persisteront après un reboot.

Par contre, si jamais vous changez le fichier des iptables, alors lancez l’instruction iptables-save > /etc/iptables/rules.v4.

Nettoyage des règles superflues

Maintenant qu’on a le VPN, on peut supprimer quelques règles dans la PFSense.

Autoriser les pings ? Finis les pings ! On supprime.
NATer le serveur nginx ? Oui bon ça ok on garde.
Autoriser le SSH pour les VMs ? Plus besoin ! Le VPN a accès à tout automatiquement.
Accès au VPN depuis Internet ? Euuh oui ça on garde !

Au final, voici mes règles (en gris clair celles qui sont désactivées) :

Petite checklist pour vérifier que tout marche bien :

Depuis le VPN :

On a accès à la PFSense sur https://192.168.9.254
On a accès au Proxmox sur https://10.0.0.1:8006
On a accès au serveur web nginx sur http://192.168.9.10
On a accès au serveur web nginx sur l’IP publique et port 8001.
On peut se connecter en SSH à charles@192.168.9.10

Hors du VPN :

Pas d’accès à la PFSense sur https://example.org
Pas d’accès au Proxmox sur https://example.org:8006
On a accès au serveur web nginx sur l’IP publique et port 8001.
On ne peut pas se connecter en SSH à charles@192.168.9.10

Checks ? Checks !

Comment débugger

Je ne m’attends pas forcément à ce que TOUT marche dans ce tutorial.

Ça marche pour moi.

Mais vous avez une machine différente, vous êtes dans le turfu, vous avez un provider différent, vous êtes peut-être même gaucher, qui sait ! Ça me paraît plus important de vous apprendre à vous débrouiller par vous-même que vous donner une liste d’instructions à copier/coller, et puis que quand ça ne marche pas vous soyez coincé.

Je présente donc dans cette section les outils que j’ai appris et que j’ai trouvé très utiles pour débugger.

Sniffer vos paquets

Quand vous essayez de pinger un serveur, ou juste de vous y connecter, et que ça ne marche pas, c’est frustrant.

Le pointeur clignote, il se passe rien, et vous savez qu’il ne va rien se passer. Juste si vous attendez 1 minute ou 2, vous allez voir un joli “Timeout”.

Ça peut être parce que le paquet s’est perdu, parce qu’il a été mangé par un pare-feu, ou même parce que le service auquel vous tentez d’accéder est hors ligne. Pour comprendre le cheminement d’un paquet, on peut utiliser tcpdump.

L’option -i permet de spécifier l’interface sur laquelle vous écoutez. Par exemple : tcpdump -i vmbr0.

L’option -p permet de spécifier le protocole que vous écoutez. Par exemple : tcpdump -p udp.

Et l’option port permet de spécifier le port. Par exemple : tcpdump port 22.

Vous allez voir, ou non, si un paquet sort ou entre de chez vous ou non. S’il ne sort pas, il est en toute vraisemblance bloqué par iptables ou le pare-feu de la machine sur laquelle vous êtes.

Vous pouvez utiliser cette instruction sur l’hyperviseur, sur une VM, et aussi sur la PFSense.

Loggez les iptables

Est-ce que le script iptable est en train de dropper les paquets que vous envoyez ?

Rajouter une instruction dans votre script avant l’instruction qui potentiellement droppe votre paquet. Par exemple, ajoutez :

iptables -A OUTPUT -o vmbr1 -s 10.0.0.1 -p tcp -j LOG

En gros l’idée c’est de remplacer la fin (ACCEPT) par LOG. Et ensuite les logs s’afficheront dans /var/log/syslog.

Utilisez les logs de PFSense

Dans l’interface de la PFsense, vous pouvez aller dans Status / System Logs, puis Firewall, pour voir toutes les connexions bloquées. La vôtre apparaît ? Il faudrait peut-être créer une règle. La vôtre n’apparaît pas ? Alors soit elle est passée, soit elle n’est même pas arrivée sur la PFSense.

Au passage, en cliquant sur le petit +, vous pouvez facilement ajouter une règle qui concerne spécifiquement la connexion qui a été bloquée.

Si vous suspectez qu’elle est passée, alors regardez par où elle est partie en sniffant les paquets de la machine. Soit avec tcpdump, soit en allant dans Diagnostics/Packet Capture.

Ah oui, et si vous venez juste de mettre à jour les règles du pare-feu.. donnez-lui quelques minutes. Ça m’est arrivé de me casser la tête sur un problème, de décider d’y revenir plus tard, et quand je suis revenu, le problème était résolu comme par magie. Il fallait juste attendre un peu.

Un problème avec le VPN ? Les logs sont dans Status / System Logs, puis OpenVPN.

Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Mon, 02 Mar 2020 07:35:00 +0000

Note de zwindler : cet article a été co-écrit par Charles Bordet, et se veut être une version à jour de cette suite d’articles écrits sur ce blog (mais avec des versions obsolètes de Proxmox et de PFSense). Merci à lui !

Introduction

Je me présente rapidement : je m’appelle Charles, je suis data scientist, et j’utilise le serveur dont je vais vous décrire l’installation pour mes analyses de données et mes outils professionnels. Mais avant de commencer, retournons un peu en arrière.

Note de zwindler : vous pouvez sauter l’intro et passer directement à l’architecture si vous voulez).

Il y a un peu plus d’un an, je souscrivais pour la première fois à un VPS. Mon objectif ? Sortir de l’écosystème Google en auto-hébergeant mes propres services.

J’avais déjà eu l’occasion d’utiliser des serveurs sur EC2, mais de manière très ponctuelle et plutôt limitée. J’avais besoin d’une grosse machine pour faire des calculs et 2 jours plus tard je coupais tout. Rien à voir avec l’hébergement continu, performant et sécurisé de services comme un Nextcloud, un Gitlab, et autres applis web que je voulais m’auto-fournir. C’était avant tout un test pour moi.

Est-ce que j’allais trouver dans le monde de l’open source suffisamment de bonnes alternatives, et est-ce que j’allais réussir à les héberger ?

Bilan au bout d’un an : J’en suis plutôt content. J’ai beaucoup appris et j’ai remplacé quasi tous les services Google.

Sauf que… Mes services sont répartis sur plusieurs VPS, et c’est un peu le bordel. Et puis j’ai pas de backups, à part ceux proposés par Hetzner. Mes bases de données ne sont pas répliquées. Et puis.. niveau sécurité, y’avait rien.

C’est à ce moment-là que je suis retourné sur le blog qui tout au début m’avait permis de démarrer (un certain Dryusdan), et j’ai trouvé cet article : Installer un cluster hyperconvergé avec Proxmox, Ceph, Tinc, OpenVSwitch. C’est marrant parce que je ne comprenais rien à ce titre, mais il m’a servi de nouveau point de départ. De fil en aiguille, je suis tombé sur l’article de m4vr0x : Déploiement de Proxmox VE 5 sur un serveur dédié – part 1.

Et là, j’ai compris. Proxmox allait me servir à démarrer/arrêter mes propres VPS de manière complètement flexible, et en plus m4vr0x me présentait un tuto détaillé étape par étape pour avoir une infrastructure robuste et sécurisée.

Top !

J’ai commencé le tutoriel, et puis je me suis rapidement aperçu que ce que j’avais à l’écran n’était pas strictement identique aux étapes décrites par m4vr0x. Mon plus gros problème, c’est que je ne comprenais rien à ce que je faisais. C’est quoi une gateway ? Un routeur ? iptables ? Une masquerade ?

Si c’est votre cas aussi, j’ai pris un cours de réseau sur OpenClassrooms que je vous conseille très fortement si vous aussi vous avez l’impression d’avoir loupé un trimestre à la fac et que iptables n’était même pas parmi les langues étrangères proposées.

Et deux mois plus tard… ça y est : j’ai mis en place mon serveur dédié avec l’hyperviseur Proxmox, sécurisé par PFSense. Certains services sont accessibles sur Internet, et d’autres seulement via le VPN privé, selon l’usage. Et mon objectif du jour, c’est de reprendre le tutoriel de m4vr0x, le remettre au goût du jour de 2020, et aussi de détailler les étapes où je me suis retrouvé bloqué, afin que vous ne le soyez pas.

Mon gros problème quand j’ai commencé à rentrer dans ce monde de l’administration système, c’était le langage. Imaginez lire le code des impôts. Vous comprenez rien. Par contre, quand vous allez sur service-public.fr, on vous explique la loi avec des termes plus simples de tous les jours. Cet article, je l’adresse aussi à mon moi d’il y a deux mois qui ne comprenait rien à ces termes.

Prêt ? C’est parti !

L’architecture

Sans surprise, je vais reprendre l’architecture proposée par m4vr0x et son magnifique schéma :

Ça c’est notre objectif final qu’on détaillera un peu plus tard.

Proxmox VE

Proxmox, c’est une solution d’hyperviseur, de virtualisation, qui s’installe sur un serveur dédié. À la place d’avoir une Debian classique, vous avez une Debian légèrement modifiée qui vous donne Proxmox. Donc Proxmox, c’est avant tout un OS.

C’est opensource et gratuit.

Ce que j’aurais aimé qu’on me dise dès le début, c’est que Proxmox, c’est un peu comme VMware ou VirtualBox. On l’installe, et ensuite on peut créer des machines virtuelles dont on configure les composants comme on veut.

PFSense

PFSense, c’est aussi un OS complet, cette fois-ci basé sur FreeBSD, qui va nous servir de pare-feu, de routeur, et aussi de VPN. Je suis sûr qu’il y a plein d’autres choses qu’on peut faire avec PFSense.

Au début, je me demandais pourquoi utiliser PFSense alors que jusqu’ici j’utilisais toujours ufw qui était pas mal. En plus, Proxmox propose lui aussi des fonctionnalités de pare-feu.

Déjà un intérêt c’est que PFSense filtre les paquets avant qu’ils arrivent sur la VM. Alors que ufw (ou iptables, c’est pareil) regarde les paquets une fois qu’ils sont sur la VM. Subtile différence.

Ensuite, c’est une solution complète avec une belle interface qui va faire plus qu’un firewall basique.

La PFSense permet d’isoler le réseau local (LAN) qui va contenir toutes les VMs d’Internet.
La PFSense a une belle interface qui permet d’aller voir les logs, extraire les paquets (très utile pour débugger !), et paramétrer tout ce qui a besoin de l’être.
La PFSense est remplie d’outils utiles : Routeur, serveur DHCP, VPN, DNS, et sûrement d’autres que je ne comprends pas mais qui seront utiles plus tard pendant la vie d’adulte.

Le hardware

Pas de comparaison de différents providers ici.

Pour ma part, j’utilise Hetzner depuis le début, et c’est eux que j’ai choisi pour mon serveur dédié, notamment via le Server Auction.

J’ai pris une grosse machine avec :

un Intel Xeon E5-1650V3
2 HDD de 4 To
256 Go de RAM
1 IP publique (pas de failover pour le moment mais ça ne change strictement rien à ce tuto)

Tout ça pour environ 85€/mois. Bon plan ? Mauvais plan ? En vrai j’en sais trop rien. Je tenais à avoir beaucoup beaucoup de RAM parce que j’en ai régulièrement besoin pour mes analyses de données.

Le seul hic c’est que comme le serveur est hébergé en Allemagne, quand je me connecte au VPN tout l’internet passe en allemand.

L’installation

Hetzner ne propose pas directement d’image Proxmox, ce qui est un peu dommage. Les pages d’aide proposent de partir d’une Debian et d’upgrader vers Proxmox tout à la main. Franchement pas évident.

Heureusement, il existe une image non officielle que j’ai utilisée et avec laquelle tout s’est très bien passé.

Pour ça, il suffit de démarrer le serveur en mode Rescue (on peut l’activer à tout moment dans l’interface).

Une fois connecté en SSH, on accède aux images avec l’utilitaire installimage. Dans la liste des OS proposés, choisissez « Other (!!NO SUPPORT!!) ». Oui hein c’est pas très rassurant tous ces points d’exclamation. Mais faites-moi confiance.

C’est là que les images Proxmox apparaissent. J’en ai 3 pour Jessie, Strech, et Buster, qui correspondent respectivement à Debian 8, 9, et 10. Évidemment on va prendre Buster.

Ensuite, un éditeur va s’ouvrir pour choisir la configuration du Proxmox.

HARD DISK DRIVE(S)

Ici je ne touche à rien, je monte mes deux HDDs :

DRIVE1 /dev/sda
DRIVE2 /dev/sdb

SOFTWARE RAID

Ici je laisse les valeurs par défaut aussi, ce qui me donne un Software RAID 1 :

SWRAID 1
SWRAIDLEVEL 1

HOSTNAME

Ici, on demande spécifiquement un FQDN. Par exemple : proxmox.example.org. Vous pouvez d’ailleurs dès maintenant paramétrer vos DNS pour qu’ils redirigent vers ce FQDN.

PARTITIONS

Et finalement, la partie la plus marrante, on crée les partitions.

L’idée c’est d’avoir une partition pour le boot, et une partie pour LVM (Logical Volume Management). Moi ce que je comprends c’est que LVM est un système de partitionnement qui est plus flexible que la méthode traditionnelle et donc plus adaptée pour ce qu’on veut faire.

Ensuite, dans la partie LVM, je mets une partition swap et tout le reste pour mon utilisation future.

Au final, ça donne :

PART /boot ext3 512M
PART lvm vg0 all
LV vg0 swap swap swap 2G
LV vg0 root / ext4 all

OPERATING SYSTEM IMAGE

Là on change rien. Hetzner a déjà pré-rempli avec l’image Proxmox qu’on souhaite utiliser.

Pour sortir de ce fichier, on peut faire F10. Bon ça marche pas chez moi, à la place j’ai le menu « File » de ma console qui se déroule. Du coup je fais deux fois Échap et ça marche aussi. On enregistre évidemment.

Et l’installation va se faire toute seule.

Si vous avez fait une bêtise, pas d’inquiétude. Redémarrez le serveur en mode Rescue et placez-vous sur la case départ (vous ne toucherez rien du tout par contre). Une fois l’installation terminée, redémarrez, puis vous aurez accès à l’interface de Proxmox à l’adresse https://proxmox.example.org:8006 (changez avec votre FQDN bien entendu !).

Première ligne de sécurité

Le serveur SSH

Votre serveur est up et déjà des petits malins frappent à la porte. S’il y a un truc que j’ai appris ces deux derniers mois, c’est qu’il y a des tonnes de bots dont le seul objectif est de parcourir toutes les IPv4 (ça se fait en quelques heures) et de toquer à la plupart des ports classiques.

Maintenant imaginez qu’un bot tombe sur un prompt où on lui demande un mot de passe. Que va-t-il faire ? Bruteforcer le mot de passe bien sûr !

J’ai redémarré mon serveur à 06:39:35, et à 06:40:09 je recevais ma première attaque.

La première chose que je fais, c’est sécuriser le serveur SSH :

Je crée un nouvel utilisateur principal avec un accès sudo
J’interdis de se connecter directement à root en SSH
J’interdis de se connecter avec un mot de passe en SSH
Je change le port du SSH. Prenez un port aléatoire après 1000 (en général je regarde l’heure qu’il est et ça me donne un numéro de port)

Pour la dernière règle (changer le port), c’est optionnel car ce n’est pas de la sécurité en soit (ça n’arrêtera pas un attaquant), mais ça va drastiquement réduire le « bruit de fond », la plupart des bots ne cherchant que les ports par défaut.

Voici les commandes :

# adduser tomtom
# usermod -aG sudo tomtom
# su - tomtom
# mkdir ~/.ssh
# chmod 700 ~/.ssh
# vim ~/.ssh/authorized_keys # là j'ajoute ma clé SSH
# chmod 600 ~/.ssh/authorized_keys

Puis je modifie le fichier /etc/ssh/sshd_config avec les options suivantes :

Port 21153
PermitRootLogin no
PasswordAuthentication no

Et puis on redémarre le serveur SSH : /etc/init.d/ssh restart.

Pro tip : Assurez-vous bien de pouvoir vous connecter avec l’utilisateur que vous venez de créer. Sinon, vous êtes bon pour reprendre de zéro :D

Juste avec ça, vous devriez voir le nombre d’attaques dans /var/log/auth.log drastiquement se réduire.

Mais ça ne suffit pas et ça ne protège pas d’une attaque bruteforce. Pour ça, il va falloir installer fail2ban. Cet outil va lire les logs, identifier un attaquant (quelqu’un qui essaie de forcer la porte d’entrée) et bannir son IP. On peut le configurer pour le SSH mais aussi pour plein d’autres outils !

On l’installe avec apt install fail2ban. Puis on crée un nouveau fichier /etc/fail2ban/jail.local avec la configuration suivante :

[DEFAULT]
bantime = 84600
findtime = 600
maxretry = 3
destemail = tomtom@example.org
sendername = Fail2ban
action = %(action_mwl)s
[sshd]
enabled = true
port = 21153

En fait c’est surtout la dernière partie qui est obligatoire. Il faut activer l’outil pour le SSH, et spécifier le port que vous avez modifié précédemment. Et n’oubliez pas de redémarrer le service : systemctl restart fail2ban.

Testez alors si ça marche en essayant de vous connecter depuis une autre IP que la votre. Bah oui, sinon vous allez vous bannir vous-même. Donc utilisez un VPN ou bien connectez-vous en premier sur un serveur distant, et depuis ce serveur distant, essayez de vous faire bannir.

Comment voir si ça marche ? Regardez les logs /var/log/auth.log et /var/log/fail2ban.log.

Configurer votre serveur SMTP

Normalement vous devriez recevoir des emails de la part de fail2ban (avec la configuration ci-dessus).. si vous avez configuré postfix, qui vient de base avec Proxmox.

Si vous avez suivi jusque là, il y a de bonnes chances pour que vous n’y ayez pas encore touché. Là on le fait pour fail2ban, mais Proxmox peut aussi vous notifier de certains événements importants, donc c’est une étape importante, pas seulement pour fail2ban.

Lancez donc un dpkg-reconfigure postfix et choisissez les options suivantes :

Internet Site.
System mail name = proxmox.example.org.
Postmaster mail recipient = tomtom.
Other destinations to accept mail from : Laissez les valeurs par défaut, c’est-à-dire : proxmox, proxmox.example.org, proxmox.example.org, localhost.example.org, localhost.
Force synchronous updates on mail queue? Non.
Local networks = On laisse par défaut.
Mailbox size limit = 0
Local address extension character = +
Internet Protocols = all

La console va vous parler, puis redémarrez le service avec systemctl restart postfix.

L’interface Proxmox

Ensuite j’aime bien créer encore un autre utilisateur, qui lui n’aura pas d’accès sudo, et qui sera réservé à Proxmox.

Après avoir tapé adduser proxmox, il faudra vous connecter en root sur l’interface Proxmox et ajouter l’utilisateur dans Datacenter / Permissions / Users. Pour lui donner des accès, vous pouvez taper les commandes suivantes (tirées de la documentation : User Management) :

pveum groupadd admin -comment "System Administrators"
pveum aclmod / -group admin -role Administrator
pveum usermod proxmox@pam -group admin

Vous pouvez restreindre ces accès à tout moment.

Pendant que vous êtes connectés avec root, vous pouvez aussi en profiter pour placer un certificat Let’s Encrypt et éviter d’avoir l’avertissement du navigateur pour le HTTPS. Plus de détails ici : Signez l’UI de Proxmox VE avec Let’s Encrypt, c’est (encore plus) trivial

Voilà.

Maintenant, on n’aura plus besoin de root. On peut se déconnecter et tout faire avec le nouvel utilisateur.

Et voilà ! Maintenant, on a une belle interface, ouverte à l’internet entier, avec un petit écran de logi… hein quoi ? Eh ouais, on peut se faire bruteforce le Proxmox là ! D’ailleurs c’est peut-être en train d’arriver en ce moment même !

Retour sur fail2ban

Cette étape est un peu optionnelle dans le sens où dans le futur, on pourra bloquer l’ouverture de Proxmox sur le monde réel et ne pouvoir y accéder que depuis le VPN.

Mais j’ai tendance à penser qu’on n’est jamais trop prudent…

Retournez dans le fichier /etc/fail2ban/jail.local et ajoutez la configuration suivante :

[proxmox]
enabled = true
port = https,http,8006
filter = proxmox
logpath = /var/log/daemon.log
maxretry = 3
# 1 hour
bantime = 3600

Et on ajoute la partie suivante dans le fichier /etc/fail2ban/filter.d/proxmox.conf (voir la doc officielle) :

[Definition]
failregex = pvedaemon\[.*authentication failure; rhost=<HOST> user=.* msg=.*
ignoreregex =

Cette deuxième partie, elle sert justement à repérer les messages d’erreurs causés par les méchants qui essaient de se connecter.

Et on oublie pas de redémarrer fail2ban.

Là pour tester c’est un peu plus compliqué que pour le SSH, mais par exemple vous pouvez essayer de le faire depuis votre téléphone (pas sur la connexion wifi hein !).

Bon. On a bien avancé. Mais on n’a pas fait grand chose non plus.

Configuration du réseau

Dans cette partie, mon objectif est vraiment de reprendre exactement le schéma de m4vr0x :

Le truc de base à garder en tête, c’est qu’en frontal, on a l’hyperviseur. C’est incontournable.

On doit forcément passer par l’hyperviseur pour atteindre une VM.

Du coup, si notre pare-feu EST une VM, ben… ça casse un peu tout le délire. C’est un peu comme si le gardien du château était au fond du jardin.

C’est pour ça que notre objectif, ça va être de router automatiquement TOUT le trafic vers la VM pare-feu. Donc vers la PFSense.

En temps normal, on devrait avoir la PFSense en frontal, et derrière elle on aurait le réseau local.

C’est pourquoi la PFSense est connectée à deux réseaux :

Le WAN, aka Internet
Le LAN, tout le réseau local avec les VMs qui sont derrières PFSense

Entre les deux, il y a la PFSense.

En routant la totalité du trafic de l’hyperviseur vers la PFSense, c’est un peu comme si la PFSense était en frontal (alors qu’en vrai c’est proxmox le frontal sur Internet). Et ce petit router tout le trafic automatiquement se traduira en une LONGUE série d’instructions iptables.

Paramétrage des interfaces virtuelles

Déjà, on crée les réseaux WAN et LAN. Connectez-vous sur votre interface Proxmox https://proxmox.example.org:8006 (avec votre utilisateur spécial, pas le root !), cliquez sur votre node, puis System > Network :

Sur son tuto, m4vr0x avait 2 interfaces (2 NIC on dit). Moi avec Hetzner j’en ai qu’une. Au début j’ai cru que c’était game over pour moi. En fait non, 1 seule suffit. C’est comme pour lotus.

Juste un petit conseil. On fait un petit backup des interfaces comme elles ont été configurées par le provider d’abord : cp /etc/network/interfaces /etc/network/interfaces.bak.

On crée un premier bridge en cliquant sur Create/Linux Bridge et on remplit comme suit :

Name : vmbr0
IPv4/CIDR : Choisissez l’IP qui était auparavant sur votre interface NIC. En gros c’est votre IP publique. Il faut aussi ajouter le CIDR.
Gateway (IPv6) : Idem, choisissez la Gateway qui était sur l’interface NIC.
IPv6/CIDR : Idem que pour l’IPv4. J’ai pris le choix d’en mettre une, comme Hetzner m’en a fourni une. Je me dis qu’en 2020 y’a plus d’IPv4 disponible, donc y’a un moment va falloir s’y mettre.
Gateway (IPv6) : Idem.
Autostart : On coche.
VLAN aware : On laisse décoché.
Bridge ports : Là vous mettez le nom de votre première interface. Celle dont vous avez extrait l’IP et la Gateway.
Comment : Internet.

Si jamais vous ne savez pas ce que c’est que le CIDR ou la Gateway, c’est là que je vous recommande très chaudement le cours d’OpenClassrooms que je citais au début. Franchement, vous n’en ressortirez que plus compétent sur les réseaux et ce sont quelques heures investies qui vous en feront gagner beaucoup d’autres plus tard.

Je remets discrètement le lien ici : Apprenez le fonctionnement des réseaux TCP/IP

Et si vous avez juste oublié comment calculer le CIDR à partir de votre masque, vous pouvez utiliser cette table de correspondance.

Là, si vous validez, vous aller avoir un message d’erreur. Il faut au préalable supprimer les infos IP/Gateway de l’interface du NIC. En plus si vous laissez l’IP sur le NIC et le bridge, vous allez avoir des problème (j’en sais quelque chose).

Pour être 100% honnête, je ne suis pas sûr que ce bridge soit indispensable. Je ne vois pas trop ce qu’il apporte de plus par rapport à directement utiliser l’interface NIC. Là c’est un peu comme si on mettait une double porte pour rentrer chez soi.

Ensuite, un deuxième bridge. Celui-ci sera un bridge « virtuel », ça veut dire qu’il ne sera connecté sur aucune réelle interface NIC. On va avoir un premier bridge virtuel qui donnera sur le réseau WAN, et un deuxième bridge virtuel qui donnera sur le réseau LAN. C’est une manière de créer des réseaux privés distincts.

Imaginez qu’on crée une première porte virtuelle qui mène vers le monde de WAN, et une deuxième porte virtuelle qui mène vers le monde de ~~Jumanji~~ LAN.

Pour ce deuxième bridge, on rentre :

Name : vmbr1
IPv4/CIDR : 10.0.0.1/30.
Comment : WAN

m4vr0x rentrait la valeur « WAN » dans bridge port. Mais en fait 1) je crois que ça n’était pas utile, et 2) Proxmox 6 vous empêche d’assigner une interface qui n’existe pas. Si vous tenez vraiment à le faire, il faudra éditer à la main le fichier /etc/network/interfaces.

Je le mets quand même dans Comment parce que c’est utile pour s’en rappeler.

Pour l’IP, on utilise un CIDR = 30 pour être sûr de n’avoir que 2 IPs de disponible. Oui, on évite de se donner une plage avec des millions d’IPs si on n’en a pas besoin. Là, si jamais un brigan arrive à se relier je-ne-sais-comment au réseau WAN, eh bien il ne pourra pas avoir d’IP.

Et finalement le dernier bridge :

Name : vmbr2
IPv4/CIDR : 192.168.9.1/24.
Comment : LAN

Ici c’est un peu pareil, mais on se laisse la possibilité d’avoir 256 IPs, puisqu’on ne sait pas combien de machines virtuelles on va avoir exactement.

~~Allez, on valide en cliquant sur Reboot tout en haut de l’interface.~~

Bonne nouvelle, il n’est maintenant plus forcément nécessaire de redémarrer entièrement l’hôte en cas de modification des interfaces réseaux. Si vous installez le package ifupdown2 (via un petit apt install), vous pourrez cliquer sur la case Apply Configuration dans le menu Network pour prise en compte à chaud des modifications !

C’est peut-être le moment de vous montrer une petite astuce si jamais vous vous êtes planté. En fait, quand j’ai suivi le tuto de m4vr0x, j’ai réussi à m’enfermer dehors de mon serveur une bonne dizaine de fois.

La solution, pour Hetzner, c’est de passer en mode Rescue, puis de monter le volume LVM en suivant les instructions de cette page d’aide. Par exemple, l’idée ça pourrait être de remettre le fichier /etc/network/interfaces dans son état initial.

L’idée, c’est que même si j’ai l’impression que mon tutorial est fail-proof, je suis sûr qu’il ne l’est pas. C’est probablement impossible de l’être. Par contre, on peut apprendre les outils pour réparer nos conneries. Et ça nous rend confiant pour essayer des trucs.

Bon allez. On vérifie son contenu de /etc/network/interfaces et on passe à la suite :

auto lo
iface lo inet loopback
iface lo inet6 loopback
auto enp4s0
iface enp4s0 inet manual
up route add -net xx.xx.xx.xx netmask 255.255.255.224 gw xx.xx.xx.xx dev enp4s0
auto vmbr0
iface vmbr0 inet static
address xx.xx.xx.xx
netmask 27
gateway xx.xx.xx.xx
bridge-ports enp4s0
bridge-stp off
bridge-fd 0
#Internet
iface vmbr0 inet6 static
address xx:xx:xx::xx
netmask 64
gateway fe80::1
auto vmbr1
iface vmbr1 inet static
address 10.0.0.1
netmask 30
bridge-ports none
bridge-stp off
bridge-fd 0
#WAN
auto vmbr2
iface vmbr2 inet static
address 192.168.9.1
netmask 24
bridge-ports none
bridge-stp off
bridge-fd 0
#LAN

Notez que j’ai une règle de routage au début avec la ligne qui commence par up route add. Cette ligne était déjà là avant, alors je n’y ai pas touché.

Déploiement de PFSense

On va télécharger la dernière version sur le site : PFSense. Moi j’ai pris une architecture AMD64 et l’ISO.

Évidemment on vérifie le checksum. Ça sert à rien de passer des heures sur la sécurité si on télécharge un fichier trafiqué. Je suis sympa je vous donne même la commande : openssl dgst -sha256 Downloads/pfSense-CE-2.4.4-RELEASE-p3-amd64.iso.gz.

Puis on l’upload dans le volume de stockage local sur l’interface de Proxmox.

Si comme moi vous avez une connexion un peu pourrite, on peut aussi le télécharger directement sur le serveur :

cd /var/lib/vz/template/iso
wget https://frafiles.pfsense.org/mirror/downloads/pfSense-CE-2.4.5-RELEASE-amd64.iso.gz
openssl dgst -sha256 pfSense-CE-2.4.5-RELEASE-amd64.iso.gz
gunzip pfSense-CE-2.4.5-RELEASE-amd64.iso.gz

Et pouf l’ISO va apparaître dans votre interface.

Maintenant on lance une VM (et pas un CT).

General

Node : Choisissez votre node.
VM ID : On peut laisser la valeur par défaut (100 normalement).
Name : PFSense.

Use CD/DVD disc image file (iso) : Storage = local et ISO image est le fichier qu’on vient d’uploader.
Guest OS = Other

System

Graphic card : ~~VMware compatible~~ Default
SCSI Controller : VirtIO SCSI

Hard Disk

Bus/Device : VirtIO Block / 0.
Storage : local.
Disk size : 8 GB.
Format : QEMU

CPU

Sockets : 1
Cores : 2

Note de zwindler : Charles conseillait une carte graphique « VMware compatible », mais à l’usage, je trouve que celle par défaut offre un meilleur rendu

Si vous voulez vous pouvez mettre plus de cœurs. Je ne pense pas que ça change grand chose étant donné que la VM ne va pas être gourmande du tout.

Memory

Memory : 512.

Idem, vous pouvez mettre plus, mais pour commencer vous pouvez très bien mettre cette valeur et l’augmenter plus tard si le besoin s’en fait ressentir.

Network

Bridge : vmbr1
Model : Intel E1000 ou VirtIO

Pour ce dernier point, ça dépend si vous aimez les problèmes ou non. Intel E1000 semble fonctionner. VirtIO aussi mais sous certaines conditions. En fait, je me suis retrouvé avec des VM qui pouvaient pinger Internet mais les requêtes tcp/udp ne passaient pas. Ça m’a rendu fou.

On y reviendra. Moi j’ai pris VirtIO.

Pour l’instant, on valide.

La PFSense a besoin d’être connectée à 2 interfaces réseau : Le WAN et le LAN. Bah oui puisque c’est justement elle qui va faire le lien entre les deux interfaces. Pour l’instant, elle n’est connectée que à vmbr1, qui correspond au WAN.

Cliquez sur la VM, puis Hardware, et « Add/Network Device ». Choisissez vmbr2 et le même modèle que vous aviez choisi pour vmbr1.

Maintenant on peut démarrer la VM.

Installation de PFSense

En allant sur Console, vous allez pouvoir afficher l’écran de la machine.

Choisissez Install pfSense.

Ensuite, on vous demande votre disposition clavier. Vous pouvez sélectionner ce que vous voulez, de toute façon après il vous remet en qwerty (sympa).

Pour le partitionnement, choisissez Auto: Guided Disk Setup, sauf si vous savez ce que vous faites. Les choses vont alors se faire toutes seules, jusqu’à :

Dites-lui non, puis rebootez. Après le reboot, choisissez de ne pas configurer de VLAN :

Pour la WAN interface, choisissez l’interface vtnet0, qui est l’équivalent de vmbr1. Pour la LAN interface, choisissez l’interface vtnet1, qui est l’équivalent de vmbr2.

On arrive alors sur le menu principal de la PFSense. Ce menu bien moche, c’est l’écran d’accueil. Oui oui. Rassurez-vous, plus tard on aura une interface web bien plus jolie. Pour l’instant, tapez 2 pour assigner des adresses IP à vos interfaces :

Pour le WAN, on va lui donner :

DHCP : no
IPv4 : 10.0.0.2
Subnet bit count : 30
Upstream gateway address : 10.0.0.1
DHCP6 : no
IPv6 : Rien (appuyez sur Entrée)

Do you want to revert HTTP as the webConfigurator protocol? no

 L’écran principal va réapparaître. De nouveau on tape 2, et cette fois-ci on configure le LAN :

IPv4 : 192.168.9.254
Subnet bit count : 24
Upstream gateway address : Rien (appuyez sur Entrée)
IPv6 : Rien (appuyez sur Entrée)
Activer le serveur DHCP : No
Do you want to revert HTTP as the webConfigurator protocol? no

Finalement, on nous annonce que le webConfigurator est disponible à l’adresse https://192.168.9.254. On va donc s’y connecter pour continuer la configuration.

… Quoi ? … Ça ne marche pas ? … Sûr ? … C’est con …

Oui je reprends les blagues de m4vr0x, et alors :D ?

Bon l’idée c’est juste qu’on a un réseau local ici, donc non on ne peut pas y accéder depuis Internet. Il faut être dans le LAN pour y accéder. Les machines qui sont dans le LAN sont l’hyperviseur et la PFSense. Et les deux.. n’ont pas d’interface graphique.

Petit debugging tip. Normalement, là où vous en êtes, vous devriez être capable de pinger l’hyperviseur depuis la PFSense. À partir du menu principal, tapez 7 puis l’IP de l’hyperviseur (10.0.0.1). Le ping devrait fonctionner.

Par contre, si vous essayez de pinger la PFSense, ça ne va pas marcher. En effet, par défaut, la PFSense est inaccessible depuis le WAN. Parce que le WAN, c’est Internet, c’est le monde dangereux. Dans notre cas particulier, le WAN c’est seulement l’hyperviseur pour l’instant, mais plus tard, tout le trafic d’Internet viendra de l’interface du WAN.

Donc quand on ping depuis la PFSense, ça marche parce que c’est la PFSense qui initie la connexion, donc en face on sait qu’on a un copain, donc on accepte sa réponse de ping.

Mais quand on ping vers la PFSense, ça ne marche pas parce qu’elle ne vous connaît pas et elle ne parle pas aux inconnus.

J’ai mis des semaines à comprendre ça, et de nombreuses personnes s’en plaignaient dans les commentaires, donc ça me semblait important de faire cette parenthèse.

Accéder à la console de PFsense

Du coup, comment on va accéder à cette interface web ?

A partir de là, vous avez plusieurs solution. La plus simple est, en attendant qu’on ait un accès direct au réseau local des VM via un VPN par exemple, on peut simplement faire un tunnel SSH.

Pour se faire, lancez la commande suivante depuis votre PC :

ssh tomtom@IP_PUB_PROXMOX -L 8443:192.168.9.254:443

Une fois la commande lancée, l’UI de PFsense sera accessible à l’URL https://localhost:8443 tant que le tunnel sera opérationnel. Ça peut suffire. Sous Windows, vous pouvez faire la même chose avec Putty (ou n’importe quel autre client SSH un peu évolué).

La deuxième option est de créer une machine virtuelle dans le réseau LAN qui disposera d’une interface graphique. Par exemple, une simple Ubuntu Desktop, qui nous servira de poste de rebond. Téléchargeons-la directement depuis le serveur :

cd /var/lib/vz/template/iso
wget http://releases.ubuntu.com/18.04.4/ubuntu-18.04.4-desktop-amd64.iso

Puis, on crée une nouvelle VM avec le paramétrage suivant.

General

Node : Choisissez votre node.
VM ID : On peut laisser la valeur par défaut (101 normalement).
Name : UbuntuDesktop.

Use CD/DVD disc image file (iso) : Storage = local et ISO image est le fichier qu’on vient d’uploader.
Guest OS = Linux 5.x

System

Graphic card : ~~VMware compatible~~
SCSI Controller : VirtIO SCSI

Hard Disk

Bus/Device : VirtIO Block / 0.
Storage : local.
Disk size : 25 GB.
Format : QEMU

Note de zwindler : Charles conseillait une carte graphique « VMware compatible », mais à l’usage, je trouve que celle par défaut offre un meilleur rendu

On peut mettre moins de storage mais il faut garder à l’idée que c’est une VM temporaire de toute façon. Une fois que tout sera en place, on pourra la détruire.

CPU

Sockets : 1
Cores : 4

Memory

Memory : 4096.

Pareil, on peut mettre moins de mémoire RAM.

Network

Bridge : vmbr2
Model : Intel E1000 ou VirtIO

Là évidemment on se plante pas ! La VM et toutes les autres VM qu’on créera seront toujours sur le vmbr2, donc le LAN ! Et là vous êtes content d’avoir écrit WAN ou LAN en commentaires du bridge puisque ça vous évite de vous perdre.

De toute façon, si vous vous branchez sur le WAN, il n’y aura pas d’IP disponible.

Je passe sur les détails de l’installation de Ubuntu, elle n’est vraiment pas compliquée.

Ce qui est important, c’est de vous paramétrer une IP, étant donné qu’il n’y a pas de serveur DHCP pour vous en assigner une automatiquement.

Allez dans les Paramètres puis choisissez Réseau. Activez la connexion, et dans les paramètres, l’onglet IPv4, rentrez les paramètres suivants :

IPv4 Method = manuel
Address = 192.168.9.10
Netmask = 255.255.255.0
Gateway = 192.168.9.254
DNS = 1.1.1.1

Et là, c’est bon !

Comment ça l’accès internet ne marche pas ?!

Évidemment qu’il ne marche pas ! Suivez un peu. On a une VM qui est connectée au réseau LAN seulement. Le réseau LAN est-il relié à Internet ? Seulement à travers la PFSense. Et comme la PFSense bloque tout, on n’a pas accès.

Par contre, vous devriez être capable de pinger l’hyperviseur et la PFSense avec ping 192.168.9.1 et ping 192.168.9.254.

Et finalement, vous allez même pouvoir vous connecter à l’interface web de la PFSense en ouvrant une page web et en tapant https://192.168.9.254/.

Accéder à la console de PFsense

Cette interface n’est pour le moment accessible que depuis le réseau local (ou depuis votre tunnel si vous avez choisi cette voie). Et heureusement, parce que par défaut, les identifiants sont :

Username = admin
Password = pfsense

Au démarrage, l’appli vous propose un wizard de configuration. Suivez simplement les consignes.

Hostname : Correspond à la partie avant le domaine. Par exemple, dans proxmox.example.org, l’hostname c’est proxmox.
Domain : Et le domaine, c’est l’autre partie restante.
DNS : 1.1.1.1

Le reste peut être laissé par défaut, jusqu’à l’étape 4 sur l’interface WAN. Normalement tout est bien pré-rempli. Toutefois, détail important, il faut désactiver la case Block RFC1918 Private Networks.

Cette option permet de bloquer les paquets qui parviennent d’un réseau privé d’entrer par l’interface WAN. Un réseau privé, c’est un réseau dont l’IP commence par 10, 172.16, ou 192.168. Et comme notre WAN est justement sur un réseau privé, eh bien cette option bloque tout.

En temps normal, le WAN correspond à Internet. Dans notre cas spécifique, ce n’est pas le cas, et on doit donc décocher cette case.

Continuez puis finissez par changer le mot de passe de l’admin. À la fin, on vous propose de vérifier si une mise à jour. Vous pouvez essayer…

… sauf que vous n’avez toujours pas accès à l’internet sur votre VM ! (suivez un peu)

Il reste maintenant la partie la plus fun : Envoyer tout le trafic sur la PFSense, configurer PFSense et déployer une application.

Et vous l’aurez dans dans le prochain épisode !

Proxmox VE 6 + pfsense sur un serveur dédié (2/2)

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

Tue, 25 Jul 2017 11:55:18 +0000

Note : Cette suite d’articles de 2016 écrite par M4vr0x a été remis à jour par Charles et moi. Je vous conseille d’aller lire celui ci plutôt, qui sera plus en phase avec les versions actuelles. Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

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 connaît ? … 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 :

Documentation officielle d’OpenVPN
Article « OpenVPN Remote Access Server » du Wiki de PFSense
Un très bon tuto francophone qui détaille bien les options … lui ;-)

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][2]. 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 address
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 traînent sur votre compte et surtout abonnez-vous à NoLife … ah non c’est pas ça je m’égare … allez see u guys.

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

Tue, 18 Jul 2017 12:00:32 +0000

Note : Cette suite d’articles de 2016 écrite par M4vr0x a été remis à jour par Charles et moi. Je vous conseille d’aller lire celui ci plutôt, qui sera plus en phase avec les versions actuelles. Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

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 :

Après avoir déployé Proxmox, nous allons poursuivre la mise en œuvre de notre infrastructure de Labs sur notre serveur dédié, en procédant aux étapes suivantes :

Sécuriser l’OS
Paramétrer les interfaces via la WebUI de Proxmox
Installer la VM PFSense
Utiliser l’iptables de l’hyperviseur pour router et sécuriser les flux

Basic hardening

Je vous conseille TRÈS VIVEMENT (non en fait c’est obligatoire) d’appliquer les bonnes pratiques élémentaires en matière de sécurisation listées dans ce très bon article rédigé par OVH et qui détaille tous les points ci-dessous.

Si vous voulez creuser un peu plus, regardez également du coté des outils d’audit du genre de Lynis (ex rkhunter), c’est simple à utiliser et ça vous donnera plein de pistes sur des vulnérabilités potentielles : Doc d’installation officielle

Voilà, pour ma part, ce que j’ai mis en place :

Changement du mot de passe root

Si vous avez utilisé un mot de passe simple pour éviter les risques d’erreurs lors de la configuration (comme évoqué dans la part 1), on se connecte via SSH et on paramètre un VRAI password.

Mise à jour du système

Toujours une bonne habitude à prendre avant de commencer, même si à l’heure où j’écris ces lignes la version 5 de Proxmox est sortie depuis seulement quelques jours. Rien de compliqué, on est sur une Debian :

apt-get update; apt-get upgrade

Création d’utilisateur

La création d’un utilisateur « lambda », autre que root, est fortement recommandée. Par défaut l’authentification du portail de Proxmox se base sur PAM donc vous pourrez vous loguer avec, après l’avoir ajouté dans la WebUI.

Configuration du serveur SSH

Désactivez l’accès root et privilégiez le recours au user évoqué ci-dessus puis utilisez une élévation de privilège de type su ou sudo.

Installation de Fail2ban

Là aussi indispensable, il s’installe en une commande, il est déjà configuré avec un grand nombre de règles par défaut qui parsent vos différents log et bannissent toutes les @IP concernées. D’ailleurs, si vous n’êtes pas convaincu de son utilité, je vous mets un (petit) extrait de mon auth.log juste avant son installation :

Voilà, voilà … contrairement à notre ami de Nanjing qui a effectué 161 tentatives en 32h avec des logins plus ou moins improbables … nous on se marre moins tout de suite !!

Au passage, voilà un article sur la configuration de Fail2ban de l’hébergeur Digital Ocean (Ils en font d’ailleurs beaucoup d’intéressants je vous encourage à écumer leurs tutos)

Changement du port d’écoute du serveur SSH

Alors là attention, aucun doute sur la pertinence de la mesure, cela vous permettra d’éviter la grande majorité des tentatives d’accès non autorisées car la plupart des bots se contentent de scanner les ports par défauts des principaux services. Par contre si vous faites ça, vous allez devoir adapter le port SSH dans le script iptables que je vous fournis pas la suite et les tentatives d’intrusion sur le port 22 seront redirigés directement sur le PFSense, ce qui n’est pas forcément mieux. Bref à vous de voir, pour ma part je reste sur le port par défaut mais avec un Fail2ban bien configuré.

Configuration du réseau

Voici le plan réseau de l’infrastructure que nous allons mettre en place (cliquez pour agrandir) :

Le but est de rediriger la totalité du trafic entrant sur l’adresse IP public du serveur vers l’interface WAN du PFSense. Cela permet de gérer la sécurisation et le routage des flux simplement, directement depuis PFSense et surtout en évitant d’avoir à doubler chaque règles de filtrage sur l’iptables.

Paramétrage des interfaces virtuels

Cela peut se faire directement via la WebUI de Proxmox, Les réglages seront simplement automatiquement retranscrits dans le fichier « /etc/network/interfaces« .

Se connecter à l’interface d’administration

Via un navigateur, on se rend en HTTPS sur l’IP public via le port 8006 (https://@IP_PUBLIC_IP:8006). Si vous souhaitez signer vos certificats pour éviter le genre de message que vous allez rencontrer, n’hésitez pas à lire ce superbe article de Zwindler

Sélectionner votre node dans la colonne de gauche, puis naviguer dans System > Network

Vous devriez avoir deux interfaces, en01 et en02 (ou eth0 et eth1 chez Kimsufi), qui correspondent aux deux ports physiques de la carte réseau ainsi qu’une interface virtuel, vmbr0 bridgé sur eno1 qui est l’interface active.

On peut d’ailleurs voir à quoi cela correspond en affichant notre fichier de configuration :

cat /etc/network/interfaces

Qui devrait contenir ceci :

auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno2 inet manual
auto vmbr0
iface vmbr0 inet static
address xx.xx.xx.xx
netmask 255.255.255.0
gateway xx.xx.xx.xx
bridge_ports eno1
bridge_stp off
bridge_fd 0

On voit que l’interface eno1 est configuré en « manual », sans adresse IP puisque elle est « portée » par vmbr0, et qu’eno2 n’est pas utilisée.

Création des bridges Linux

On reprend en configurant conformément au schéma ci-dessus :

Cliquer sur « Create » et sélectionner « Linux Bridge«

Le réseau « VmWanNET » (10.0.0.0/30) sera donc volontairement choisit pour limiter à deux le nombre d’adresses atribuables, celle-ci et le WAN du PFSense. Ici pas de bridge sur une interface réelle pour la vmbr1 puisque « WAN » n’existe pas au niveau de l’hyperviseur, mais cela facilitera la correspondance lors du paramétrage de PFSense.

Cliquer (à nouveau) sur « Create » et sélectionner (encore) « Linux Bridge«

Cette fois on configure l’interface vmbr2 qui fera parti du réseau « PrivNET » (192.168.9.0/24), et qui sera utilisée plus tard par l’interface « LAN » du PFSense :

IP address : 192.168.9.1
Subnet mask : 255.255.255.0
Bridges Ports : LAN

Une fois terminé, cela donne :

Rebooter l’hyperviseur

Il suffit de cliquer sur « Restart » en haut à droite. C’est impératif pour prendre en compte proprement les modifications, c’est pas moi qui le dis, c’est marqué au dessus de l’encadré affichant le log : « Pending changes (Please reboot to activate changes) » … allez promis c’est la seule fois où ce sera nécessaire.

Après le redémarrage, vous pouvez vérifier le contenu du fichier « interfaces » :

auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno2 inet manual
auto vmbr0
iface vmbr0 inet static
address xx.xx.xx.xx
netmask 255.255.255.0
gateway xx.xx.xx.xx
bridge_ports eno1
bridge_stp off
bridge_fd 0
auto vmbr1
iface vmbr1 inet static
address 10.0.0.1
netmask 255.255.255.252
bridge_ports WAN
bridge_stp off
bridge_fd 0
auto vmbr2
iface vmbr2 inet static
address 192.168.9.1
netmask 255.255.255.0
bridge_ports LAN
bridge_stp off
bridge_fd 0

Je vous conseille de le conserver quelques part puisque en cas de réinstallation, un simple copier/coller suivi d’un reboot vous permettra de tout reconfigurer rapidement. Nous poursuivrons le paramétrage et la sécurisation par la suite.

Déploiement de PFSense

Création de la VM

Télécharger l’ISO de PFSense

Rendez-vous sur le site officiel pour récupérer la dernière version stable de la Community Edition, de type « install« , au format ISO et pour archi AMD64 (64bits). On sélectionne ensuite le volume de stockage souhaité, ici « local« , puis on clique sur Content > Upload

Mais on peut également, surtout si votre débit d’upload est poussif, la télécharger directement depuis le serveur dans le répertoire des ISOs :

cd /var/lib/vz/template/iso
wget [lien mort, aller sur https://pfsense.org/]
gunzip pfSense-CE-2.3.4-RELEASE-amd64.iso.gz

Créer la VM pour PFSense

Voilà les paramètres que j’utilise, ceux qui n’y figure pas sont laissés par défaut :

Linux/Other OS types : Other OS types

CD/DVD

Use CD/DVD disc image file (iso)

Storage : local
ISO image : pfSense-CE-2.3.4-RELEASE-amd64.iso

Hard Disk

Bus/Device : VirtIO / 0
Storage : local
Size : 8 GB
Format : QEMU (qcow2)

CPU

Sockets : 1
Cores : 2
Type : Défaut (kvm64)

Memory

Mémoire fixe avec ballooning activé

Taille : 2048 MB

Network

Bridged mode (Accès par pont)

Bridge : vmbr1
Model Intel E1000

/!\ Pour la carte réseau SURTOUT pas de VirtIO sans installer le driver requis /!\
Pour plus détails ici

Créer la seconde interface réseau

Assurez-vous d’être dans la « Server View » dans le menu en haut à gauche, puis sélectionnez votre VM PFSense nouvellement crée. Enfin, cliquez sur Hardaware > Add > Network Device

La configuration est la même que pour la première mais pontée sur vmbr2.

Installation de l’OS

Démarrer la VM via le bouton « Start »
Ouvrir une console VNC avec le bouton « Console »

Laisser le boot se terminer, si ce n’est pas encore fait, jusqu’à voir s’afficher le premier écran de l’installeur :

Libre à vous de choisir les réglages qui vous conviennent, valider avec le dernier choix du menu.

Choisir « Quick/easy Install »

Valider à nouveau et l’installation se lance
Sélectionner le choix par défaut « Standard Kernel«
Autoriser le reboot

Vérifiez le boot order de la VM pour bien démarrer sur le disque local, vous pouvez également éjecter l’ISO.

Configuration des interfaces

Une fois la VM redémarrée, vous arrivez sur le menu principal de la console de PFSense :

Taper « 1 » (pas trop fort) pour assigner les interfaces, puis configurer comme suit :

 - Paramétrage des VLANs : No (n)
 - WAN interface name : em0
 - LAN interface name : em1
 - Optional 1 interface name : Aucun (appuyer sur entrée)
 - Valider (avec y) si :
WAN -> em0
LAN -> em1

De retour dans menu général taper « 2 » pour configurer les @IP des interfaces

Taper "1" pour le WAN (em0 - static)
- DHCP : No (n)
- @IP : 10.0.0.2
- Masque : 30
- Gateway : 10.0.0.1
- DHCP6 : No (n)
- WAN IPv6 address : Aucune (appuyer sur entrée)
- HTTP revert : No (n)
 - Valider (avec entrée) si :
IPv4 WAN address => 10.0.0.2/30

A nouveau « 2 » pour configurer les @IP des interfaces

Taper "2" pour le LAN (em1 - static)
- @IP : 192.168.9.254
- Masque : 24
- Gateway : Aucune (appuyer sur entrée)
- @IPv6 : Aucune (appuyer sur entrée)
- DHCP server : No (n)
- HTTP revert : No (n)
 - Valider (avec entrée) si :
IPv4 LAN address => 192.168.9.254/24

Rebooter la VM en tapant « 5 » puis « y »
A l’issue, taper « 7 » pour tester le ping vers 10.0.0.1 (l’adresse de vmbr1) et ainsi vérifier la connectivité au sein du VmWanNET

Finalisation via la WebUI

Se connecter à la WebUI via un navigateur à l’adresse https://192.168.9.254 …

… Quoi ? … Ça ne marche pas ? … Sûr ? … C’est con …

Bon pour ceux qui suivent encore, félicitations ! Pour les autres, l’interface LAN de PFSense n’est pour l’instant pas accessible depuis l’extérieur … et c’est tant mieux car le password et le login sont toujours ceux par défaut. La solution la plus simple est donc de créer une VM avec n’importe quel OS, du moment qu’il possède une interface graphique et un navigateur web (et que ce n’est pas un Windows). Une Ubuntu Desktop, à télécharger sur le site officiel, fera parfaitement l’affaire.

Je ne vais pas revenir sur la création de la VM, sachez juste que 5 Go de disque et 512 Mo de RAM suffisent. N’oubliez pas de bridger la carte réseau sur vmbr2 pour accéder au réseau LAN. Vous pouvez également, une fois la VM crée, modifier le paramètre Hardware > Display en « VMWare compatible » c’est qui vous permettra de disposer d’autres résolutions plus confortable que le minuscule 800×600.

Une fois l’OS installé, il faut tout de même paramétrer le réseau manuellement puisque nous n’avons pas (encore) de serveur DHCP fonctionnel :

- IP : 192.168.9.10 (Peu importe tant qu'on reste dans 192.168.9.0/24)
- Netmask : 255.255.255.0
- Gateway : 192.168.9.254
- DNS : 8.8.8.8

Se connecter à la WebUI via un navigateur à l’adresse https://192.168.9.254 (non mais vraiment cette fois)

Username : admin
Password : pfsense

Suivez le (White) Wizard

Rapport à ma VM PFsense qui se nomme Olorin … pertinent pour un pare-feu …

« You Shall Not Pass ! » … ok si vous l’avez toujours pas j’abandonne.

Choisir un hostname (non pas celui-là, c’est le mien) et le(s) serveur(s) DNS souhaité(s)
Valider ou modifier le FQDN du serveur NTP

Pour la suite rien à modifier en principe puisque nous avons fait les réglages via la console précédemment.

Vérifier la configuration de l’interface WAN

IP Address : 10.0.0.2
Subnet Mask : 30
Upstream Gateway : 10.0.0.1

Vérifier la configuration de l’interface LAN

LAN IP Address : 192.168.9.254
Subnet Mask : 24

Changer le mot de passe administrateur
Recharger la configuration et l’accueil du dashboard s’affiche

Configuration du réseau (suite)

Routage et NAT

Particulièrement pour cette partie, je vous encourage à garder le plan réseau à portée de vue.

Pour l’instant, le WAN du PFSense communique bien avec le vmbr1 ,normal me direz vous, ils sont sur le même segment réseau et WAN est ponté sur vmbr1 dans Proxmox. Maintenant nous allons faire le nécessaire pour pouvoir sortir sur internet depuis la patte WAN du PFSense et donc également depuis le LAN par la suite.

Pour cela, créer un petit script sur le serveur Proxmox

vi /root/kvm-networking-up.sh

Coller les lignes suivantes :

#!/bin/sh
## IP forwarding activation
echo 1 &amp;amp;amp;gt; /proc/sys/net/ipv4/ip_forward
# Point PFSense WAN as route to VMs
ip route change 192.168.9.0/24 via 10.0.0.2 dev vmbr1
# Point PFSense WAN as route to VPN
ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1

Comme indiqué dans les commentaires :

La première ligne active le routage
La deuxième indique au serveur de sortir par vmbr1 puis de passer par le WAN du PFSense pour communiquer avec les VMs. Cela permet d’isoler vmbr2 du reste de « PrivNET », cette sécurité sera renforcée, lors de la configuration d’iptables par un blocage complet des flux sur vmbr2.
Même chose pour la dernière mais pour communiquer avec le(s) client(s) du VPN que nous configurerons dans la suite de l’article.

Puis pour qu’il soit lancé automatiquement au boot, lors du démarrage de vmbr1 :

Lui permettre de s’exécuter

chmod +x /root/kvm-networking-up.sh

Paramétrer son appel dans le fichier « interfaces »

vi /etc/network/interfaces

Ajouter la ligne en gras à la fin du bloc de configuration du bridge vmbr2 :

[...]
auto vmbr1
iface vmbr1 inet static
address 10.0.0.1
[...]
auto vmbr2
iface vmbr2 inet static
[...]
bridge_fd 0

post-up /root/kvm-networking-up.sh

Comme je vous ai promis qu’on ne rebooterait plus au début de cette article, on va simplement l’exécuter manuellement pour cette fois :

/root/kvm-networking-up.sh

[Edit zwindler]M4vr0x a oublié qu’il a déplacé une règle IPtable pour rediriger le traffic de l’IP externe vers le pfsense… La ligne suivante ne marche pas encore, mais à l’étape d’après[/Edit]

Relancer la console VNC du PFSense et taper « 7 » pour vérifier le ping vers l’internet (genre 8.8.8.8)

Sécurisation de l’hyperviseur via iptables

Voilà on a presque terminé mais pendant qu’on s’amusait, et malgré les mesures prises au début de ce tuto, une armée de bots (et pas que des chinois), des hordes de BlackHat ainsi que l’intégralité de la NSA, du GCHQ et de … l’ANSSI ? … se tirent la bourre pour essayer de pénétrer sur votre petit serveur sans défense.

Je n’aurais donc que trois choses à dire :

Si vous ne savez pas ce qu’est le GCHQ, il faut absolument lire ce magnifique article !
Si vous ne savez pas ce qu’est la NSA … là je ne peux plus rien pour vous
Nous n’allons pas mourir sans combattre et nous allons au moins … essayer de les ralentir !

Création des règles

Nous allons créer un script pour exécuter toutes les commandes iptables requises. Je vous encourage à ne pas automatiser son lancement au boot avant d’être totalement sûr que tout fonctionne bien.

Pour ceux qui ont pris iptables en deuxième langue au collège, je vous donne directement le contenu du script (à copier sur le serveur Proxmox) :

Pour les autres, je vous conseille de bien lire (et comprendre tant qu’à faire) ce qui suit jusqu’à la fin avant de vous lancer. J’ai commenté quasiment chaque ligne mon script le plus explicitement possible, donc je vais simplement vous expliquer le rôle de chacune des parties :

_VARIABLES _: On commence par la variabilisation des noms de bridges, des @IP et des réseaux. Cela vous permettra de l’adapter rapidement à votre configuration si elle diffère. Quoi qu’il en soit, il faut absolument définir la variable « PublicIP » avec celle de votre serveur.

CLEAN ALL & DROP IPV6 : Ensuite on supprime toutes les règles existantes.

Petit point d’attention, le script, légèrement bourrin, flush toutes les tables et supprime toutes les chaines personnalisées vides à chaque exécution. Si vous voulez éviter ça, pour garder votre/vos chaines Fail2ban existantes par exemple, je vous conseille de plutôt spécifier les tables et chaines à nettoyer.

DEFAULT POLICY : On positionne les polices par défaut à DROP : tout ce qui ne sera pas explicitement autorisé sera interdit (comme à l’armée … \o/ ça faisait longtemps).

CHAINS : On crée des chaines personnalisées pour éviter la répétition des options.

GLOBAL RULES : Elles permettent les communications from/to l’interface locale, préservent les connections déjà actives et autorisent la réponse au ping.

_RULES FOR PrxPubVBR _: On passe à la configuration des flux pour l’interface bridge vmbr0, c’est ici que tout se joue.

L’idée est simple, on ne va autoriser que les services du Proxmox auxquels on souhaite pouvoir accéder depuis internet via l’IP public (donc le moins possible). TOUS les autres flux seront redirigés sur l’interface WAN du PFSense ce qui nous permettra, comme expliqué au début, d’éviter une pénible gestion de deux firewall chaînés. Une fois que le VPN sera configuré on pourra d’ailleurs désactiver l’accès externe à la WebUI. Pour le SSH on pourra garder un accès de secours en cas de problème avec le futur VPN.

_RULES FOR PrxVmWanVBR _: Pour vmbr1, c’est très simple, on autorise seulement les connexions, en provenance du LAN des VMs et du/des client(s) VPN, à sshd et l’interface web de Proxmox.

RULES FOR PrxVmPrivVBR : Pour vmbr2, encore mieux, on laisse tout fermé !

De plus, comme paramétré précédemment, aucune route ne passe par ce bridge. C’est un moyen simple et assez efficace d’isoler au maximum cette interface du réseau auquel elle appartient. Le mieux aurait été d’utiliser une configuration similaire au mode « promiscuous » des Vswitchs d’ESX mais je n’ai pas trouvé d’équivalent pour KVM. Une autre solution utilisant la seconde interface physique du serveur est à l’étude par mon expert en sécurité et fera peut être l’objet d’un article spécifique ou d’une MAJ future. D’ailleurs j’en profite :

Merci Nico, Merci Zwindler !

La clusterisation de nos cerveaux (non ce n’est pas sale) m’a fait gagner beaucoup de temps :-D

Et voilà ! (avec l’accent américain) Vous avez bien bossé et vous disposez d’une infra totalement fonctionnelle et relativement bien sécurisé, GG !

Il nous restera bien sûr à configurer les règles adéquates sur PFSense pour les services de vos futures VMs auxquels vous souhaiterez accéder depuis l’extérieur et configurer un serveur VPN afin d’y accéder directement au chaud depuis votre nouveau LAN.

Nous allons voir tout ça dans la troisième et dernière partie de cette article par ici.

Kimsufi on Zwindler's Reflection

Tutoriel Proxmox VE 8 - SDN en mode VXLAN avec des machines sur Internet

Préambule

Prérequis

Problème

VXLAN donc, mais avec un VPN

Configuration du SDN

C’est tout ?

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (3/4)

On reprend de là où on en était : premiers pas dans l’UI

Création du cluster

Rejoindre le cluster

Split brain

Configuration du SDN

Conclusion

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (2/3)

On reprend de là où on en était : premiers pas dans l’UI

Stockage / ZFS

Parlons un peu de ZFS

Du réseau

Danger zone

Premier test

It’s alive?

Enfin bon…

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (1/2)

Introduction

Postulats de départ

Choix des machines

Installation de l’OS

Premières tâches post-installation : upgrade et reboot

C’est pour la sécurité

Nagging popup

Création de groupes et d’utilisateurs pour l’interface graphique

Proxmox VE 6 + pfsense sur un serveur dédié (2/2)

Routage du trafic vers la PFSense

Port forwarding de la PFSense

1/6 Variables

2/6 DROP & start again !

3/6 INPUT

4/6 OUTPUT

5/6 FORWARD

6/6 MASQUERADE

Spécificité VirtIO

On est pas mal là ?

Hébergement de services

Un serveur nginx sur Internet

Un serveur SSH sur l’internet privé

Accéder à la PFSense depuis Internet

Sécuriser les services privés avec un VPN

Création de l’autorité de certification

Création du certificat pour le serveur

Création du certificat pour le client

Création du serveur VPN

Création de l’utilisateur pour le VPN

Configuration du client

Ouverture des chakras

Le VPN vous sauvera

Protéger la PFSense

Protéger l’interface web du Proxmox

Protéger le SSH du Proxmox

Nettoyage des règles superflues

Comment débugger

Sniffer vos paquets

Loggez les iptables

Utilisez les logs de PFSense

Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Introduction

L’architecture

Proxmox VE

PFSense

Le hardware

L’installation

Première ligne de sécurité

Le serveur SSH

Configurer votre serveur SMTP

L’interface Proxmox

Retour sur fail2ban

Configuration du réseau

Paramétrage des interfaces virtuelles

Déploiement de PFSense