Ldfa Posté(e) le 30 décembre 2019 Partager Posté(e) le 30 décembre 2019 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 = 1net.bridge.bridge-nf-call-iptables = 1net.bridge.bridge-nf-call-arptables = 0net.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/firewallIP=”192.168.0.19″ # the IP address of the host nodeTCPPORTS=”22 80 443 53 123 5900″ # TCP ports to openUDPPORTS=”53 123″ # UDP ports to openTCPPORTS_ATTACKPROTECTION=”" # TCP ports to open with brute force attack protectionDMZS=”192.168.0.24″ # IPs and blocks that should have full access to this VMKVMFULLACCESS=no # yes/no to enable/disable KVM machines full access Définitions des paramètres: IP: adresse IP du serveur ProxmoxTCPPORTS: Liste de ports TCP à ouvrirUDPPORTS: Liste de ports UDP ouvrirTCPPORTS_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 completKVMFULLACCESS: 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/firewallVMID=”101″ # the container’s ID#IP=”192.168.0.196″ # the IP address for this containerTCPPORTS=”22 80 443″ # TCP ports that should be openedUDPPORTS=”123″ # UPD ports that should be openedTCPPORTS_ATTACKPROTECTION=”" # TCP ports to open with brute force attack protectionDMZS=”" # IPs and blocks that should have full accessBANNED=”" # 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 ProxmoxTCPPORTS: Liste de ports TCP ouvertsUDPPORTS: Liste de ports UDP ouvertsTCPPORTS_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 completBANNED: 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 5060Ouvrir le port pour le trafic IAX2, par défaut UDP 4569Ouvrir 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 testFirewall will be stopped in 180sStarting firewall…Firewall: Purging and allowing all trafficFirewall: Setting default policies to DROPFirewall: Allowing access to HN 192.168.0.198TCP 80 443 53 123 5900UDP 53 123TCP with Attack Protection 22DMZS 192.168.0.24Firewall: Setting up Containers with full accessOpen Access for 192.168.0.46Firewall: Setting up containers firewallsFile:/etc/firewall.d/101.fwVM101 box1.example.comIP 192.168.0.196TCP 22 25 80 443 161 162 5500:5700File:/etc/firewall.d/102.fwVM102 box2.test.comIP 192.168.0.115TCP 22 25 80 443 161 162 5500:5700 33890TCP with Attack Protection 3389 Après 3 minutes: pve1:~# Stopping firewall…Firewall: Purging and allowing all trafficFirewall 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 22update-rc.d: warning: /etc/init.d/firewall.sh missing LSB informationupdate-rc.d: see 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 Afficher l’article complet Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.