Consultant Informatique Réseau et Internet

7 avril 2010

Proxmox: Installer le firewall proxmoxfirewall

Proxmox n’intègre pas de Firewall par défaut. Cette article propose une solution simple pour mettre en oeuvre un firewall élémentaire mais suffisant dans la plupart des cas.Le firewall proposé dans cet article utilise netfilter/iptables inclus dans tous les noyaux linux récents. La configuration est effectuée à l’aide d’un script (firewall.sh) et de quelques fichiers de configuration (hostnode.conf et *.fw).  Cette solution ne requière aucune connaissance préalable concernant netfilter/iptables car la définition des règles est réalisée à l’aide de fichiers de configuration simple qui permettent, en principe, de répondre aux besoins les plus courants.

Cet article a été rédigé à partir de Proxmox 1.5.

update Proxmox 2.0:

Pour les VM KVM, il faut autoriser iptables pour les bridges dans /etc/sysctl.d/pve.conf, puis rebooter le serveur.

net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0

Les fichiers à utiliser sont inclus dans l’archive “proxmoxfirewall.tar”, disponible ici:

http://www.philten.com/download/proxmoxfirewall

Le package contient les fichiers suivants:

  • firewall.sh: script du gestion de firwall
  • hostnode.conf: configuration du serveur Proxmox (Host Node)
  • 101.fw: fichier de configuration de la VM 101. A copier pour chaque VM installée sur le serveur (102.fw,103.fw,…)

Syntaxe des fichiers de configuration

Fichier [/etc/firewall.d/hostnode.conf]:

Ce fichier permet de définir les règles de firewall concernant le host node (serveur Proxmox)

# This file is required and is processed by /etc/init.d/firewall
IP=”192.168.0.19″                      # the IP address of the host node
TCPPORTS=”22 80 443 53 123 5900″        # TCP ports to open
UDPPORTS=”53 123″                       # UDP ports to open
TCPPORTS_ATTACKPROTECTION=”"  # TCP ports to open with brute force attack protection
DMZS=”192.168.0.24″                             # IPs and blocks that should have full access to this VM
KVMFULLACCESS=no                        # yes/no to enable/disable KVM machines full access

Définitions des paramètres:

IP: adresse IP du serveur Proxmox
TCPPORTS: Liste de ports TCP à ouvrir
UDPPORTS: Liste de ports UDP ouvrir
TCPPORTS_ATTACKPROTECTION: Liste de ports TCP à ouvrir, mais avec une protection contre les attaques par force brute.
DMZS: Liste des IP sources devant disposer d’un accès complet
KVMFULLACCESS: Valeurs possibles “yes” ou “no”.
Si “yes”, tous les paquets à destination des VMs KVM seront autorisés. Il est dans ce cas recommandé d’installer un firewall au niveau des VMs KVM.
Si “no”, les paquets à destination des VMs KVM seront traités selon les règles définies dans les fichiers *.fw correspondants.

Remarques:

  • Attention !!!
    Si le fichier [hostnode.conf] n’est pas renseigné correctement vous pouvez perdre tout accès au serveur Proxmox après l’activation du firewall
  • Les ports ouverts avec le paramètre TCPPORTS_ATTACKPROTECTION sont limités à 5 connexions (acceptées ou refusées) par minute et par IP source. Au delà, une période d’une minute sans tentative de connexion est nécessaire pour ré-initialiser le compteur. En conséquence, si un ordinateur distant tente de se connecter en continue, par exemple 10 fois par seconde, après 5 connexions toutes les tentatives de connexion suivantes seront refusées (car il faut un delai de 1 minute sans tentative de connexion pour ré-initialiser le compteur).
  • La protection offertes par TCPPORTS_ATTACKPROTECTION est adaptée aux connexions SSH, mais pas aux connexions HTTP ou HTTPS car une page web génère souvent bien plus de 5 connexions par minutes.
  • Les IPs sources spécifiées dans DMZS sont prioritaires face aux règles indiquées dans TCPPORTS_ATTACKPROTECTION. Donc, si vous spécifiez l’IP de votre bureau dans DMZS et le port 22 dans TCPPORTS_ATTACKPROTECTION, vous ne serez pas soumis à la limitation des 5 connexions par minute.

Fichiers [/etc/firewall.d/*.fw]:

Ce fichier permet de définir les règles de firewall des VMs.

Vous devez créer un fichier par VMs. Les VMs OpenVZ n’ayant pas de fichier “.fw” associé ont tous les ports ouverts. Les VMs KVM n’ayant pas de fichier “.fw” associé ont tous les ports ouverts ou fermés, en fonction du paramètre KVMFULLACCESS du fichier hostnode.conf.

# This file is processed by /etc/init.d/firewall
VMID=”101″                      # the container’s ID#
IP=”192.168.0.196″      # the IP address for this container
TCPPORTS=”22 80 443″       # TCP ports that should be opened
UDPPORTS=”123″          # UPD ports that should be opened
TCPPORTS_ATTACKPROTECTION=”"  # TCP ports to open with brute force attack protection
DMZS=”"                         # IPs and blocks that should have full access
BANNED=”"                       # IPs and blocks that should be entirely blocked from the container’s services

Définitions des paramètres:

VMID: VMID de la VM tel que défini dans Proxmox (101,102,103,…)
IP: adresse IP du serveur Proxmox
TCPPORTS: Liste de ports TCP ouverts
UDPPORTS: Liste de ports UDP ouverts
TCPPORTS_ATTACKPROTECTION: Liste de ports TCP ouvert, mais avec une protection contre les attaques par force brute. Un maximum de 5 connexions par minute est autorisée. Au delà, une période d’une minute sans tentative de connexion est nécessaire pour réinitialiser le compteur.
DMZS: Liste des IP sources ayant un accès complet
BANNED: Liste des IP sources n’ayant aucun accès

Remarques:

  • Il n’y a aucun filtrage sur les paquets sortants. Tous les paquets émis par le host node sont autorisés.
  • Les ports TCP et UDP  53 nécessaires aux résolutions DNS est systématiquement autorisé (inutile de le spécifier dans les fichiers de configuration)
  • Pour définir une plage de ports, utiliser “:” (ex: 5000:5500 pour les ports 5000 à 5500)

Fichier [/etc/init.d/firewall.sh]:

Le fichier “firewall.sh” est le script qui permet le contrôle du firewall. Les commandes disponibles sont:
  • start
  • stop
  • restart
  • status
  • test (désactive le firewall automatiquement après 3 minutes)

Procédure d’installation

1. Télécharger et décompresser le fichier compressé sur votre serveur Proxmox:

Télécharger l’archive:

# cd
# wget http://www.philten.com/download/proxmoxfirewall/proxmoxfirewall-[version].tar

Décompresser l’archive:

# tar -xvf proxmoxfirewall-[version].tar

2. Copier le fichier script “firewall.sh” dans “/etc/init.d/”

# mv ./firewall.sh /etc/init.d

3. Rendre “firewall.sh” executable

# chmod +x /etc/init.d/firewall.sh

4. Créer le répertoire “/etc/firewall.d” devant contenir les fichiers de configuration

# mkdir /etc/firewall.d

5. copier et configurer le fichier de configuration du host node:

# cp ~/hostnode.conf /etc/firewall.d/hostnode.conf

Le fichier fourni est un bon point de départ, mais il vous faut :

  • Renseigner le paramètre “IP=” avec l’adresse IP de votre host node (en cas d’erreur, vous risquez de perdre tout accès réseau au serveur)
  • Si votre accès SSH n’utilise pas le port 22, modifier le paramètre TCPPORTS (ou TCPPORTS_ATTACKPROTECTION) en conséquence.

6. créer un fichier de configuration pour chaque VM

L’exemple ci-dessous suppose qu’il existe trois VM à protéger: 101,102 et 103

# cp ~/101.fw /etc/firewall.d/101.fw
# cp ~/101.fw /etc/firewall.d/102.fw
# cp ~/101.fw /etc/firewall.d/103.fw

Le fichier fourni est un bon point de départ, mais, pour chaque VM il vous faut renseigner les paramètres suivants:

  • IP_ADDRESS avec l’IP de la VM
  • CTID avec l’identifiant VMID de la VM
  • CTNAME avec un nom de votre choix pour la VM
  • TCPPORTS avec les ports TCP à ouvrir en fonction des applications executées dans le VM. Dans le cas d’une VM Linux probablement le port 22 pour SSH, et dans le cas d’une VM Windows probablement le port 3389 pour RDP. Par exemple, pour un serveur web il faudra ajouter 80 (HTTP) et 443 (HTTPS).

Remarques

  • Il n’y a aucun filtrage sur les paquets sortants. Tous les paquets émis par les VMs sont autorisés.
  • Serveur FTP:
    Si votre VM héberge un serveur FTP qui doit être accessible en mode passif (c’est en général le cas), il vous faut:
    - utiliser un serveur FTP qui offre la possibilité de définir la plage de ports passifs à utiliser (par exemple 5000 à 5500) . Sous Windows, je recommande “filezilla server”, à défaut le service FTP de IIS peut être paramétré via la base de registre (cf références).
    - ajouter la plage de ports FTP passifs dans TCPPORTS, sans oublier le port 21 servant aux commandes FTP. (ex: TCPPORTS=”22 21 5000:5500″)
  • Serveur Asterisk:
    Ouvrir le port pour le trafic SIP, par défaut UDP 5060
    Ouvrir le port pour le trafic IAX2, par défaut UDP 4569
    Ouvrir les ports pour le trafic RTP, par défaut UDP 10000 à 20000 ou tel que défini dans /etc/asterisk/rtp.conf
  • Pour les VMs disposant de plusieurs adresses IPs, vous devez créer un fichier “.fw” par IP. Par exemple: 101_IP1.fw et 101_IP2.fw.

7. Tester votre configuration

Une fois votre configuration initiale terminée, vous pouvez tester votre firewall avec l’option “test” qui à pour effet de désactiver automatiquement le firewall après 3 minutes.

# /etc/init.d/firewall.sh test

exemple:

pve1:~# /etc/init.d/firewall.sh test
Firewall will be stopped in 180s
Starting firewall…
Firewall: Purging and allowing all traffic
Firewall: Setting default policies to DROP
Firewall: Allowing access to HN 192.168.0.198
TCP 80 443 53 123 5900
UDP 53 123
TCP with Attack Protection 22
DMZS 192.168.0.24
Firewall: Setting up Containers with full access
Open Access for 192.168.0.46
Firewall: Setting up containers firewalls
File:/etc/firewall.d/101.fw
VM101 box1.example.com
IP 192.168.0.196
TCP 22 25 80 443 161 162 5500:5700
File:/etc/firewall.d/102.fw
VM102 box2.test.com
IP 192.168.0.115
TCP 22 25 80 443 161 162 5500:5700 33890
TCP with Attack Protection 3389

Après 3 minutes:

pve1:~# Stopping firewall…
Firewall: Purging and allowing all traffic
Firewall stopped

Commencer par vérifier que votre session SSH fonctionne toujours, un simple “ls” fera l’affaire.

Veillez à garder cette session ouverte durant vos tests car en cas de problème elle pourra se révéler bien utile, par exemple pour désactiver le firewall.

Ensuite, tentez d’ouvrir une autre session SSH avec une autre instance de Putty. Si vous parvenez a vous logguer sans problème, tout va bien et vous pouvez souffler.

Vérifier maintenant le bon fonctionnement des applications utilisant les ports laissés ouverts, comme l’accès web à l’interface Proxmox, et les applicatifs exécutés dans les machines virtuelles. En cas de problème, corriger les fichiers de configuration, et relancer le firewall en mode “test”.

8. Démarrer le firewall au boot du serveur

Pour que le firewall démarre automatiquement au boot du serveur, utiliser la commande “update-rc.d”:

# update-rc.d firewall.sh defaults 21 22

Exemple:

pve1:~# update-rc.d firewall.sh defaults 21 22
update-rc.d: warning: /etc/init.d/firewall.sh missing LSB information
update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
Adding system startup for /etc/init.d/firewall.sh …
/etc/rc0.d/K22firewall.sh -> ../init.d/firewall.sh
/etc/rc1.d/K22firewall.sh -> ../init.d/firewall.sh
/etc/rc6.d/K22firewall.sh -> ../init.d/firewall.sh
/etc/rc2.d/S21firewall.sh -> ../init.d/firewall.sh
/etc/rc3.d/S21firewall.sh -> ../init.d/firewall.sh
/etc/rc4.d/S21firewall.sh -> ../init.d/firewall.sh
/etc/rc5.d/S21firewall.sh -> ../init.d/firewall.sh

9. Si vous avez perdus tout accès SSH au serveur Proxmox

Si vous perdez l’accès au serveur Promox tout n’est pas perdu et vous avez plusieurs solutions pour récupérer l’accès au serveur:
Si vous avez un accès physique au serveur:

  • Connectez-vous à la console et corrigez

Si vous n’avez pas d’accès physique au serveur (serveur dédiés OVH):

  • Firewall lancé en mode test: attendre 3 minutes qu’il se désactive automatiquement.
  • Firewall lancé en mode normal, mais sans démarrage au boot installé: lancé un reboot hard (à partir du Manager OVH). Pour mémoire, les reboot hard sont, de manière générale, à éviter car ils ne sont pas sans risque. Un reboot hard peut provoquer une corruption du système de fichiers et, dans le pire des cas, aboutir à un serveur qui ne boot plus (heureusement c’est assez rare). A noter qu’un reboot hard provoque, en général, une reconstruction des partitions RAID.
  • Firewall lancé en mode normal, avec démarrage au boot activé: Via le Manager OVH, rebooter en mode rescue pro, monter la partition root du disque dur et desactiver le boot automatique du firewall. Rebooter en mode HDD.
Références
A Faire:
dans hostnode.conf:
Ajouter l’option OPENVZFULLACCESS
Ajouter l’option VMFULLACCESS   => KVMFULLACCESS=yes et  OPENVZFULLACCESS=yes

11 commentaires

  1. Bonjour

    Un commentaire pour juste vous remercier. Trouver ce genre de tutoriel en français n’est pas aisé. Merci beaucoup.

    Commentaire par kimaidou — 14 avril 2010 @ 10:20

  2. Très intéressant et ca fonctionne bien, j’étais parti pour faire une règle iptable sur chaque vm + l’host et ces scripts me facilite la tâche.
    Merci beaucoup.

    Commentaire par Sino — 7 juin 2010 @ 23:31

  3. [...] Quelques liens intéressants à suivre [...]

    Ping par Projet serveur virtualisation | My Blog — 5 août 2010 @ 9:17

  4. Hello.

    With latest configuration OVH for Bridge, if KVMFULLACCESS=no KVM nodes closed to internet.

    Commentaire par Abkrim Mateos — 3 septembre 2010 @ 17:52

  5. Uf course i speak on use IP Internet, not local IP.

    Commentaire par Abkrim Mateos — 3 septembre 2010 @ 17:53

  6. I get problem.

    Problem it’s for NODES KVM with more that one IP on model bridge OVH.

    Only IP on firewall work. Others IP don’t work.

    Commentaire par Abkrim Mateos — 4 septembre 2010 @ 6:18

  7. Il y a deux erreurs aux lignes 161 et 162 du fichier
    firewall.sh : $UPDORTS au lieu de $UDPORTS .

    Sans cette correction la gestion des ports UDP des VM n’est pas pris
    en compte (ni même affiché).

    Commentaire par phil — 29 décembre 2010 @ 9:02

  8. Bonjour,

    J’ai vu ceci à la fin de votre tutoriel :
    A Faire:
    dans hostnode.conf:
    Ajouter l’option OPENVZFULLACCESS
    Ajouter l’option VMFULLACCESS => KVMFULLACCESS=yes et OPENVZFULLACCESS=yes

    Allez vous les implémenter ?
    Proxmox est en version 1.7, je vais tester votre firewall dessus et vous donner du feedback si vous le désirez.

    Cordialement,

    Commentaire par stephane — 31 janvier 2011 @ 18:12

  9. Des retours sur Proxmox 1.7 ?
    Je teste aussi

    Commentaire par Nico — 11 février 2011 @ 12:46

  10. Merci pour ce firewall.

    Une question peut être bête, DMZS=”192.168.0.24″ je dois laisser cette IP ou il en mettre une autre ou aucune peut être ?
    Petite précision j’ai un hôte et des VM accessible par IP failover.

    Commentaire par Nico — 21 février 2011 @ 19:39

  11. Bonjour,

    sur proxmox 1.7 j’ai eu des difficultés à faire marcher le TCP with Attack Protection.
    J’ai résolu le pb en supprimant, dans le code, le -j ACCEPT de la première ligne et en créant une nouvelle règle pour ACCEPT après la règle DROP.

    Merci en tout cas pour ces scripts qui marchent très bien.

    Commentaire par Alexandre — 14 mars 2011 @ 18:41

Flux RSS des commentaires de cet article.

Désolé, les commentaires sont fermés pour le moment.

Propulsé par WordPress