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

Posted by

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

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://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 https://frafiles.pfsense.org/mirror/downloads/pfSense-CE-2.3.4-RELEASE-amd64.iso.gz
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 :

OS
 - 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 => https://forum.pfsense.org/index.php?topic=72907.0

  • 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 > /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 :

  1. Si vous ne savez pas ce qu’est le GCHQ, il faut absolument lire ce magnifique article !
  2. Si vous ne savez pas ce qu’est la NSA … là je ne peux plus rien pour vous
  3. 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 chainé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 provenace 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.

199 comments

  1. Bonjour, j’ai le même problème que IDMontchat avec un PFSense qui n’arrive plus a faire sa résolution de noms DNS Lookup Failed lorsque je ping google.fr
    Quelqu’un a-t-il déjà eut le problème et surtout compris comment le résoudre ?
    Merci d’avance

  2. Bonjour,

    Je viens de suivre le tuto ou gardant les mêmes configurations !
    Arriver à l’étape du ping de google depuis pfsense rien…

    Pouvez vous m’aider ?

  3. Bonsoir,

    Tout d’abord merci beaucoup pour ces tutos hyper instructifs pour un novice en sysadmin comme moi qui installe un serveur pour bidouiller :)

    J’ai deux questions cependant :

    J’ai vu que Proxmox possédait un firewall intégré : pourquoi ne pas l’utiliser au lieu de passer par des iptables longues comme le bras ? C’est potentiellement beaucoup plus facile a gérer via la webUI en plus.
    Et pourquoi ne pas avoir ajouté un reverse proxy devant les VM en sortie de vmbr2 (j’ai cru comprendre que ça rajoutait encore une couche de sécurité).

    Merci pour vos éclaircissements !

  4. Très bonne remarque.

    Je me demande si M4vr0x l’a écrit ou pas dans l’article ?

    Quoiqu’il en soit, l’idée à la base, c’était d’avoir vraiment une infrastructure qui ressemble à ce qu’on pourrait faire en entreprise, à ceci près que le composant Firewall est généralement externe.
    Le fait d’avoir une VM séparée dédiée au rôle firewall permet d’avoir une plus grande isolation.
    Le deuxième avantage, c’est que PFsense est beaucoup plus flexible/puissant en terme de règles de FWalling que celui de Proxmox, plus basique.
    Enfin, PFsense ajoute des fonctionnalités supplémentaires que M4vr0x (l’auteur du post) et moi utilisons, comme le serveur OpenVPN ou le DHCP par exemple.

    Pour autant, je reconnais que cela ajoute pas mal de complexité, notamment la partie IPtables pour rediriger l’ensemble du trafic sur le FW (pour simuler la séparation hyperviseur/FW alors que tout est dans la même boite). On pourra effectivement très bien se satisfaire d’un Proxmox avec le firewall intégré et un reverse proxy en frontal. Ca dépend vraiment de ton besoin, en fait.

  5. Merci pour ta réponse zwindler.

    Pour préciser ma remarque par rapport au firewall mon idée était de conserver le pfsense car hyper pratique de bien des cotés (vpn etc), et de remplacer les règles « iptables » qui protègent le Proxmox par le firewall intégré à Proxmox.

    Entre temps j’ai posé la question au sysadmin de ma boite qui m’a répondu que ça revenait probablement au même car Proxmox étant une distrib linux, les règles de son firewall seront de toute manière transformées en iptables (bon a part que gérer des règles en WebUI c’est un peu plus digeste que de vilaines lignes de commandes pour le quidam moyen :P).

    Il a bon ? Et du coup je peux essayer de retranscrire les iptables au niveau du firewall de Proxmox sans perdre en sécu ? (sous réserve de ne pas faire d’erreurs bien sur :P)

  6. Bonjour,
    Je viens d’essayé de suivre le tuto, mais je rencontre un problème pour la création des réseaux.
    Lorsque je souhaite créer un nouveau Bridge et que dans le formulaire je saisi « Wan » dans « Bridge Port », j’obtiens le message  » bridge ‘vmbr1’ – unable to find bridge port ‘Wan’ (500) ».
    Donc, soit j’ai loupé une étape soit ça à changé.
    zwindler, aurais-tu une idée ?

    Merci d’avance pour ton aide.
    Nono

  7. Salut à tous,

    D’abord, merci pour ce tuto vraiment pas mal détaillé.

    J’ai juste un petit commentaire à faire :
    Si comme moi après l’application du script pour l’iptables (à faire sur proxmox), vous ne parvenez plus a résoudre des URL, que ce soit avec apt ou ping ou wget, il faut désactiver l’IPv6 comme ceci en root :
    sysctl -w net.ipv6.conf.all.disable_ipv6=1
    sysctl -w net.ipv6.conf.default.disable_ipv6=1

    Une fois OK, vous pourrez a nouveau résoudre des adresses DNS :)

    Bonne journée ;)

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

    Merci encore

  9. Je répond à mon prôpre message précédent :
    « Bonjour, j’ai le même problème que IDMontchat avec un PFSense qui n’arrive plus a faire sa résolution de noms DNS Lookup Failed lorsque je ping google.fr
    Quelqu’un a-t-il déjà eut le problème et surtout compris comment le résoudre ?
    Merci d’avance »

    le problème venais de la VM de pfsense qui n’avait pas assez de cœurs attribués (2). Depuis que j’en ai mis 4 je n’ai plus de déco.

  10. Bonjour,

    J’ai bien suivi toutes les indications du script contenant les règles iptables.

    Par contre j’ai eu un problème de ping dans le subnet 192.168.9.0 pour lequel je cherche une explication :

    Après le démarrage de proxmox et vérification de l’application correcte du script kvm-networking-up.sh dans /etc/network/interfaces et execution manuelle du script iptables fourni dans l’article, je n’arrivais plus à faire le ping suivant : depuis une vm 192.168.9.20 vers PfSense 192.168.9.254 ( c’était ok avant l’applicaion du script fourni ).

    Pour trouver l’origine du problème, j’ai démarré proxmox et exécuté le script iptables fourni, instruction par instruction :

    J’ai trouvé qu’en commentant la ligne suivante, le script complet ne produisait ensuite plus ce problème :

    iptables -P FORWARD DROP

    Que s’est il passé pour que un ping à l’intérieur du subnet 192.168.9.0 soit perturbé à ce point ?

    Salutations
    Michel

  11. Bonjour,

    Pour étayer ma question, je joins les deux parties divergentes dans la sortie de la commande « iptables -L », après l’application du script de l’article :

    Avec le script original de l’article :

    Chain FORWARD (policy DROP)
    target prot opt source destination
    ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
    ACCEPT tcp — anywhere 10.0.0.2
    ACCEPT udp — anywhere 10.0.0.2
    ACCEPT all — 10.0.0.0/30 anywhere
    PVEFW-FORWARD all — anywhere anywhere

    Le même script, mais sans la ligne « iptables -P FORWARD DROP » :

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination
    ACCEPT all — anywhere anywhere ctstate RELATED,ESTABLISHED
    ACCEPT tcp — anywhere 10.0.0.2
    ACCEPT udp — anywhere 10.0.0.2
    ACCEPT all — 10.0.0.0/30 anywhere
    PVEFW-FORWARD all — anywhere anywhere

    Salutations
    Michel

  12. Bonjour,
    Je vous remercie pour le descriptif complet.
    J’ai suivi à la lettre (sauf que mon adressage est différent, mon LAN derrière le Pfsense est en 172.17.0.0/16)

    J’ai besoin de partager un espace de stockage important entre Proxmox et certains de mes conteneurs LXC. Pour celà j’ai configuré un partage NFS (le serveur est le proxmox lui-même pour ne pas avoir à gérer l’espace de stockage du partage dans une VM ou un conteneur dont le disque ne pourrait pas être réduit facilement par la suite).
    Du coup je galère un peu à placer la bonne règle IPtable pour autoriser NFS (donc les ports 111 et 2049) sur vmbr2 / ProxVmPrivIP (172.17.0.1)

    J’ai tenté ceci :
    iptables -A INPUT -i $PrxVmPrivVBR -s 172.17.0.0/16 -p udp -m multiport –sports 111,2049 -j ACCEPT
    iptables -A OUTPUT -o $PrxVmPrivVBR -d 172.17.0.0/16 -p udp -m multiport –sports 111,2049 -j ACCEPT

    Mais ça ne fonctionne pas bien mieux.
    – J’ai besoin d’aide pour formuler peut être mieux mes iptables d’une part,
    – d’autre part je ne sait pas où bien les placer dans le script. Ligne 162 ?
    # ———————–
    # RULES FOR PrxVmPrivVBR
    # ———————–
    ICI ?

    NO RULES => All blocked !!! <– yes sir ! That’s my problem for now :)

    Merci de votre aide

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

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

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

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

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

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

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

  15. Disons que pfsense a pour lui la simplicité de son interface et surtout la flexibilité de ses packages. Effectivement on peut s’en passer, mais quitte à rester user-friendly je trouve qu’il a sa place ;)
    Ton idée me parait bien, on redirige tous le traffic « utile » sur le PFsense et on bloque le reste avec le firewall de Proxmox, un petit coup de reverse proxy pour chaque VM et le tour est joué.
    D’ailleurs j’isolerais également tous les services web type messagerie/serveur web dans un sous-réseau dédié et le reste des applis type plex/nextcloud etc dans un autre sous réseau sans accès depuis l’extérieur (avant de tomber sur le port de redirection bon courage ^^).

  16. Très bon tuto mais lorsque je veux créer le Vmbr1 il me dit que WAN n’existe pas… Ai-je loupé quelque chose ?

    Merci

  17. Bonjour,

    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.

    Vous avez suivi cette étape ?

  18. oui mais cela lorsque l’on crée l’interface. Moi il me refuse carément de la créer car il dit bridge vmbr1 – unable to find bridge WAN (500) et il ne me crée rien du tout… Il ne me demande donc pas le reboot

  19. et pour terminer lorsque j’edite le fichier interfaces et reboot le serveur les vmbr1 et 2 aparaissent bien. Je crée ma VM PFSense avec les memes parametres. La creation et le link vmbr1 ok
    et lorsque je demarre la vm j’ai l’erreur :

    Virtual Environment 5.3-5

    Rechercher
    Machine Virtuelle 100 (PFSense) sur le nœud monnouveaupc

    Vue Dossier
    Logs
    ()
    no physical interface on bridge ‘vmbr1’
    kvm: network script /var/lib/qemu-server/pve-bridge failed with status 6400
    TASK ERROR: start failed: command ‘/usr/bin/kvm -id 100 -name PFSense -chardev ‘socket,id=qmp,path=/var/run/qemu-server/100.qmp,server,nowait’ -mon ‘chardev=qmp,mode=control’ -chardev ‘socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5’ -mon ‘chardev=qmp-event,mode=control’ -pidfile /var/run/qemu-server/100.pid -daemonize -smbios ‘type=1,uuid=cb830758-092d-4484-8425-6455b51b80f1’ -smp ‘2,sockets=1,cores=2,maxcpus=2’ -nodefaults -boot ‘menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg’ -vnc unix:/var/run/qemu-server/100.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 2048 -device ‘pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f’ -device ‘pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e’ -device ‘vmgenid,guid=4512ae97-2a91-4c40-95f4-ea403ea243a8’ -device ‘piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2’ -device ‘usb-tablet,id=tablet,bus=uhci.0,port=1’ -device ‘VGA,id=vga,bus=pci.0,addr=0x2’ -device ‘virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3’ -iscsi ‘initiator-name=iqn.1993-08.org.debian:01:3860b97a99fd’ -drive ‘file=/var/lib/vz/template/iso/pfSense-CE-2.4.4-RELEASE-p1-amd64.iso,if=none,id=drive-ide2,media=cdrom,aio=threads’ -device ‘ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200’ -device ‘virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5’ -drive ‘file=/dev/pve/vm-100-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=native,detect-zeroes=on’ -device ‘scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100’ -netdev ‘type=tap,id=net0,ifname=tap100i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on’ -device ‘virtio-net-pci,mac=2E:89:03:07:0A:75,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300’ -machine ‘type=pc » failed: exit code 1

  20. Bonjour,
    Pourrais-tu expliquer brièvement comment mettre en place un reverse proxy sur cette architecture exacte ?

    Par exemple pour atteindre :
    – la VM1 depuis internet en tapant : plex.zwindler.fr
    – la VM2 depuis internet en tapant : shinken.zwindler.fr

    Tu le met en place sur le Firewall ou tu rajoute une autre machine virtuelle dans l’architecture spécialement pour le reverse proxy ?
    Merci d’avance !!

    John

  21. Bonjour,

    Avec la 5.3.11 impossible de créer la Wan&Lan sans être lié avec une interface physique … ???
    Une idée ?

  22. Bonjour, Super tuto, et tout fonctionne parfaitement !, serais-ce possible d’avoir un tuto pour ajouté d’autres ip public static a ce setup ci svp.

    Merci

  23. @J-luc : même problème, résolu en éditant directement le fichier /etc/network/interfaces
    Attention, j’ai deux serveur chez Kimsufi (même modèle) mais le nom de la carte réseau n’était pas le même, donc bien bien faire attention à ce point sous peine de crasher son serveur et être bon pour une reinstall.

  24. Bonjour,
    très bon tutorials, ça m’a beaucoup aidé à mettre en place mon infra.
    J’ai un petit soucis pour mettre en place un ipsec entre mon lan et un lan distant.J’ai suivi le tutorial de netgate.
    le tunnel est up, je peux pinger depuis 192.168.9.xx et faire des ssh sur le lan distant (172.27.xxx.yyy), par contre ni le ping ni le ssh ne marche de l’autre côté. est ce qu’il y a qcq chose de particulier à rajouter (rules, iptables…?.
    Merci

  25. Salut,
    j’aimerai savoir si ton WAN de ton serveur est sur quel range d’ip car j’ai pas bien compris.

    Réseau: 192.168.1.0/24

    Proxmox:
    – enp4so (Care réseau) , sont bridge est vmbr0 (192.168.1.20 / enp4s0)
    – vmbr1 : 10.0.0.1/30 > WAN
    – vmbr2: 192.168.9.1 / 24 > LAN

    Y’aura t’il pas un problème sur ce point ?

  26. Merci M4vr0x !!!
    C’est Nico (celui du merci à la fin qui ne fait rien de sale avec son cerveau même clusterisé …)
    Je n’ai tjrs pas de wiki perso, et mes backups … enfin bref au top de retrouver toutes ces infos en ligne, ça juste marche et je n’ai fait aucun effort hormis m’ouvrir une bière et faire du copier coller et apprécier cette petite nostalgie en relisant le script iptables.
    Bon tu me connais et je vais bien finir par en faire (des efforts) et je conseille de passer l’host en mode sans IP publique et de transférer l’IP publique sur la première VM = pfsense, ou autre dans mon cas …
    pas d’ip = pas de problème mais bon trop la flemme de lancer l’accès iLO.
    Merci Encore !!!

  27. Hello,
    Bravo pour cet article et merci beaucoup !
    J’ai suivi ces deux premières partie et une fois à la fin, je me suis rendu compte que le trafic n’était pas redirigé vers la VM PfSense, j’ai tenté de ping 10.0.0.2 depuis l’hote Proxmox mais ca ne fonctionne pas, en revanche, dans l’autre sens, ca fonctionne sans problème, est-ce normal ?

  28. Hello,
    Déjà merci beaucoup pour cet article. Je rencontre un petit problème, après avoir finit complètement ces deux parties, impossible d’accéder à ma VM PfSense depuis internet. Je me suis donc dit que ça devait venir des règles Iptables, et j’ai tenté de pinger ma VM depuis l’hote Proxmox, mais la impossible, le ping fonctionne dans l’autre sens sans soucis, mais depuis 10.0.0.1 vers 10.0.0.2 ca échoue, est-ce normal ?

  29. Bonjour,

    Merci @m4vr0x pour cet excellent tuto!
    J’ai eventuellement une petite suggestion d’amélioration (a moins que quelqu’un d’autre ne l’ai deja siganlé, j’avoue n’avoir pas lu les 180 commentaires précédents :-) ):
    En installant les règles iptables de façon violente avec iptables -F, on désactive le filtrage intelligent sur ssh de fail2ban.
    Pour le réactiver, il suffit d’ajouter la commande suivante a la fin du script iptables.sh:
    service fail2ban restart

    Et pendant que j’y suis, le tuto n’explique pas comment activer le script iptables.sh au boot. En ce qui me concerne je l’ai simplement copié dans le répertoire if-pre-up.d:
    cp /root/iptables.sh /etc/network/if-pre-up.d/iptables
    chmod a+x /etc/network/if-pre-up.d/iptables

    En hopant que ca help…
    Olivier

  30. Salut !
    J’ai suivi ton tuto quelques mois déjà, cela fonctionne très bien sur un host Kimsufi.
    Cependant j’essaie de joindre depuis l’hyperviseur une machine qui se trouve sur le LAN (remontée de statistiques du serveur Proxmox).
    Proxmox dispose de l’@IP 192.168.9.1 qui est théoriquement sur le même LAN mais je ne parviens pas à joindre les autres machines qui sont connectées au bridge vmbr2.
    Les VM connectées au vmbr2 communiquent parfaitement entre elles.
    Est-ce à voir avec IPtables ou plutôt du routage ?
    Je suis preneur de pistes ^^

  31. Salut @Dough, as tu pu résoudre ton problème de communication depuis l’hyperviseur, j’ai la même problématique ?

    Merci d’avance.

  32. Non je n’y suis pas parvenu.
    Je peux y arriver en changeant la route comme suit : ip route change 192.168.0.0/24 via 192.168.0.1 dev vmbr2
    En fait je me demande si il ne faut pas paramétrer quelque chose côté pfSense avec la route énoncée dans l’article (?)

  33. Bonjour @Dough et @Loucas,
    Pour permettre la communication depuis l’hyperviseur vers le bridge vmbr2, il faut effectivement corriger le routage qui peut par defaut se trouver dirirge vers vmbr1 au lieu de vmbr2. Ci apres l’etat du routage avant la correction:

    $ netstat -rn 
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    0.0.0.0         91.121.87.254   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
    10.2.2.0        10.0.0.2        255.255.255.0   UG        0 0          0 vmbr1
    91.121.87.0     0.0.0.0         255.255.255.0   U         0 0          0 vmbr0
    192.168.9.0     10.0.0.2        255.255.255.0   UG        0 0          0 vmbr1
    

    On voit que la route vers le subnet 192.168.9.0/24 est envoyee vers vmbr1 au lieu de vmbr2.

    Pour corriger ce type de probleme, d’abord utiliser la commande ip route list pour identifer la regle de routage erronee, puis la supprimer avec ip route del (sans chercher, simplement en copiant/collant apres le del le resultat affiché par list), et ensuite ajouter la bonne regle avec ip route add (il suffit de changer le bridge et le subnet), et ensuite le ping nous confirme que ca marche:

    ip route del 192.168.9.0/24 via 10.0.0.2 dev vmbr1

    ip route add 192.168.9.0/24 via 192.168.9.1 dev vmbr2

    ping 192.168.9.254

    PING 192.168.9.254 (192.168.9.254) 56(84) bytes of data.
    64 bytes from 192.168.9.254: icmp_seq=1 ttl=64 time=0.501 ms
    64 bytes from 192.168.9.254: icmp_seq=2 ttl=64 time=0.247 ms

    <br />La deuxieme correction utile a mon avis consiste a autoriser la connexion ssh sortante depuis l'hyperviseur vers les le LAN des vm. En effet l'interdire n'ajoute pas variment de securite, puisque quiconque a acces a l'hyperviseur a deja partie gagnee et peut ajouter la regle en question (IMHO).
    Voici donc la fin du script  `iptables.sh` qui corrige ce point:
    

    ———————–

    RULES FOR PrxVmPrivVBR

    ———————–

    All blocked except ssh from hypervisor to LAN

    iptables -A OUTPUT -o $PrxVmPrivVBR -s $ProxVmPrivIP -p tcp –dport 22 -j ACCEPT
    « `

    En hopant que ca aide…

    Olivier.

  34. Bonsoir,
    Je suis un peu surpris par les 2048MB de RAM alloués dans le tutp a la vm pfSense. Sur une petite KS avec seulement 8GB de RAM ca ne laisse pas grand chose pour le reste…
    Quelqu’un a deja essaye des valeurs plus petites et confirmé que c’est insuffisant?
    Par exemple 1GB? 768MB ?? Moins? En ajoutant du swap?
    Sur la page officielle de doc on trouve par exemple les infos suivantes:
    The minimum hardware requirements for pfSense 2.4.4-RELEASE-p10 are:
    – CPU 600 MHz or faster
    – RAM 512 MB or more
    – 4 GB or larger disk drive (SSD, HDD, etc)
    – One or more compatible network interface cards
    – Bootable USB drive or CD/DVD-ROM for initial installation

    suivi d’un avertissement:
    The minimum requirements are not suitable for all environments; see Hardware Sizing Guidance for details.
    Et dans le guide sus-mentionné en avertissement, on trouve cette info concernant la memoire requise en fonction du nombre connexions (en fonction des etats, mais sachant qu’il y a 2 etats par connexion):
    It is safer to overestimate the requirements. Based on the information above, a good estimate would be that 100,000 states consume about 100 MB of RAM, or that 1,000,000 states would consume about 1 GB of RAM.
    Donc pour 50,000 connexions ouvertes, il faut prevoir 100MB de RAM.
    2GB semble donc necessaires seulement pour 1 millions de connexions… Mais là il faudra peut-etre penser a lacher la kimsufi a 8GB RAM et un debit max de 100Mbits pour un bon gros Xeon et un interface wan a 10Gb, non?
    Olivier

  35. Merci @Olivier
    Au final c’est exactement ce que j’avais réalisé, en ouvrant même tout sur la règle iptables (pas de filtre protocole) : tout est Ok ^^
    C’est clair que si l’accès HV est gagné au final tout est accessible quoiqu’il arrive.

    Pour la mémoire allouée à pfSense je pense que tu peux démarrer à 1Go sans problème et augmenter si vraiment le besoin se fait ressentir.
    Sur mes dédiés j’ai 16+Go de RAM, mes VM pfSense ont 2Go de RAM et n’en utilisent même pas 45%.
    Sur mon HomeLab la VM pfSense n’a que 1Go de RAM et est à tout juste 55% et pourtant je pense qu’il gère bien plus de traffic que mes dédiés ^^

  36. Salut,
    Au lieu d’installer une machine ubuntu desktop pour seulement acceder a l’ihm de pfsense :
    simplement faire un tunnel ssh depuis votre poste ( ssh -D 8080 root@ipproxmox , ou putty pour windows)
    changer les parametre du proxy socks (127.0.0.1:8080) de votre navigateur , et tapez sur : https://iplandupfsense.

  37. Ce guide est une bonne base pour une première approche avec Proxmox et pfSense, malgré tout le passage avec la flopée de règles iptables m’interpèlle.

    En soit c’est le rôle de pfSense de gérer la partie réseau, pas de l’hyperviseur Proxmox (qui gère la partie système). Donc est-ce qu’on ne pourrait pas transposer tout cela vers pfSense? (question réthorique)

    Maintenant vraie question: est-ce que quelqu’un (qui a suivi ce guide ou vient à passer par là) l’a déjà fait? Sinon je m’y colle.

  38. Hello,

    Merci pour le retour. Effectivement, la complexité des règles iptables sont un point qui remonte régulièrement. J’en ai parlé avec M4vr0x et il a dit à demi mot qu’il allait retravailler une version plus à voir et surtout avec du networking plus simple. On ne pourra pas TOUT transposer vers pfsense. Il faut bien que le trafic entrant (et sortant) de l’hyperviseur passe par l’hyperviseur avant d’être servi à pfSense. Mais on peut grandement simplifier, c’est certain.

    Je vais donc le tanner jusqu’à ce qu’il le fasse ahahah ;)

  39. Bonjour,

    j’ai suivi tout ce tuto avec beaucoup de plaisir !
    Personnellement j’utilise un sous-domaine géré par cloudflare donc j’ai dû configurer pfsense pour cette partie en plus

    En revanche j’ai un soucis: mon sous-domaine du coup pointe par défaut sur pfsense (ca c’est logique) et j’aurai voulu activer le certificat let’s encrypt sur l’hyperviseur avec l’ouverture du port 80

    Mais là pas moyen de s’en sortir malgré l’ajout des règles dans iptables et l’ouverture dans le firewall pfsense –> pas moyen d’accéder au compte ACME ou de télécharger des templates
    Une idée ?

  40. bonjour,

    j’ai la meme configuration que vous mais par contre j’arrive pas à aller sur internet depuis mon LAN (echec ping 8.8.8.8)

    il y’a t(il quelques choses à corriger ?

  41. Pour ceux qui n’arrivent pas à sortir (par exemple ping 8.8.8.8) depuis les machines du LAN, il faut faire une règle Outbound NAT. J’ai remarqué que sur les dernières versions de PFsense, l’automatisation des règles Outbound ne se faisaient pas. Du coup, il faut créer la règle en manuel :
    WAN // Réseau privé // * // * // * // WanAdress // *

Leave a Reply

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

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