Le durcissement de Proxmox commence par un état d’exploitation précis : quels accès de management existent, quels réseaux sont critiques, quelles dépendances de chemins de stockage existent ? Ce chapitre fournit une directive pratique et approfondie pour les administrateurs, ingénieurs système, opérateurs et prestataires IT, avec des contrôes concrets, des étapes de mise en œuvre, des pièges typiques et des stratégies de repli testées.
Durcissement de Proxmox : préciser le modèle de menace : qui, comment et quoi protéger
Un modèle de menace réaliste est la base de tout durcissement. Posez au minimum : qui a besoin d’accès GUI/API ? Quels comptes d’automatisation utilisent des API‑Tokens ? Les hosts de management sont‑ils accessibles via VPN ou directement ? Documentez aussi les vecteurs d’attaque tels que les API‑Tokens volés, les jump‑hosts compromis ou le mouvement latéral depuis un réseau de VM.
Termes expliqués brièvement : API (Application Programming Interface) est l’interface pilotée par programme ; Corosync est le protocole de communication de cluster de Proxmox ; Ceph est un backend de stockage distribué. Si vous maîtrisez ces concepts, vous comprenez pourquoi une GUI fermée est peu utile si les ports du cluster restent ouverts.
Segmentation, Break‑Glass et gestion du changement
Séparer clairement les réseaux Management, Storage et VM
Isolez le Management (GUI/API/SSH), le Storage (NFS/iSCSI/Ceph) et le trafic VM dans des VLANs/subnets distincts. Cela empêche des VMs compromises d’atteindre directement le cluster ou le stockage. Les pièges fréquents sont les bridges partagés ou l’absence de tags VLAN sur les bridges de l’hyperviseur, rendant les adresses IP de management visibles.
Break‑Glass et voies de repli testées
Définissez au minimum deux voies de repli : console locale/IPMI et un jump‑host testé avec une IP Always‑Allow dans le pare‑feu. Avant d’activer le Default‑DROP, documentez les étapes pour une ouverture temporaire : désactiver pve‑firewall, ajuster une règle de pare‑feu, rediriger le port SSH. Exécutez ces opérations en conditions réelles au moins une fois.
pve‑firewall : architecture, règles et activation sécurisée
La pve‑firewall est un élément central du durcissement de Proxmox. Elle opère sur plusieurs niveaux — Datacenter, Node et VM/CT — et génère en fin de compte des règles nftables/iptables sur les hôtes. Concevez les règles en blocs fonctionnels : Cluster/Corosync, Storage, Management, Monitoring.
Corosync & communication de cluster
Corosync utilise, dans les installations standards, des ports UDP pour le trafic de quorum et de heartbeat (p. ex. 5404/5405). Si ces connexions sont bloquées par le pare‑feu, des nœuds sortent du quorum et les services deviennent instables. Créez des règles autorisant Corosync entre les sous‑réseaux du cluster, et testez latence/perte de paquets avec ping/iperf.
# Prüfen, ob Corosync läuft und UDP-Ports offen sind
systemctl status corosync
ss -uanp | grep -E '5404|5405'
# Testweise UDP-Pakete senden (nur in Lab/mit Absprache)
echo test | nc -u -w1 node2.example.org 5405Autoriser proprement les accès Storage
Les protocoles de stockage utilisent des ports typiques : NFS (2049), iSCSI (3260) et Ceph (Mon 6789, OSD 6800–7300). N’ouvrez que les ports réellement utilisés par votre architecture de stockage. Les clusters Ceph requièrent souvent une accessibilité bidirectionnelle entre OSDs et monitors ; une configuration de pare‑feu incomplète provoque des erreurs de rebalance et une latence élevée.
Ordre pratique pour l’activation
- Recenser : ports, interfaces, noms DNS.
- Ajouter les règles : autoriser Cluster & Storage.
- Restreindre progressivement le Management : GUI/API/SSH uniquement depuis les sources d’administration.
- Activer la journalisation et la limitation de débit (rate‑limiting).
- Définir la politique par défaut sur DROP ; surveiller le monitoring.
Diagnostic du pare‑feu et scénarios d’erreur typiques
Syndromes fréquents après une mauvaise configuration du pare‑feu : split de cluster, messages de quorum indistincts, migrations interrompues ou timeouts de stockage. Le dépannage commence par des vérifications des services et du réseau.
# Service- und Netzwerkstatus prüfen
systemctl is-active pveproxy pvedaemon pvestatd corosync
journalctl -u pve-firewall -n 200 --no-pager
ss -tulpen | sed -n '1,200p'
# Temporäre Deaktivierung für Test (Node-lokal)
systemctl stop pve-firewall || trueModifiez toujours les règles de façon contrôlée : utilisez les Audit‑Logs, notez les horodatages et l’auteur. Cela permet de retracer plus rapidement l’origine d’un problème.
Sécurisation de l’API et de l’interface Web : TLS, Tokens, MFA
L’API Proxmox (pveproxy) permet l’automatisation et est fonctionnellement équivalente à la GUI — elle nécessite donc les mêmes mesures de protection : transmission chiffrée, authentification forte et RESTriction réseau.
Contrôles TLS et monitoring
Vérifiez régulièrement les certificats : date d’expiration, SAN/noms DNS, confiance de l’AC sur les clients admin. Évitez les contournements tels que « insecure_skip_verify » dans les checks de monitoring ; si le monitoring ne peut pas valider, la solution consiste à améliorer la gestion des certificats.
# Zertifikat schnell prüfen
openssl s_client -connect pve.example.org:8006 -servername pve.example.org </dev/null | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256API‑Tokens und Least‑Privilege
Pour l’automatisation, utilisez des API‑Tokens avec des droits limités plutôt que des mots de passe personnels. Séparez les comptes administrateurs interactifs des comptes de service. Les Tokens doivent faire l’objet d’une rotation et d’une documentation dans la gestion des changements.
# Beispiel: pvesh nutzt die API ohne separate Tokens zur schnellen Abfrage
echo 'Nodes:'
pvesh get /nodesMFA et WebAuthn
Mettez en place l’authentification à deux facteurs (par ex. TOTP ou WebAuthn/U2F), quand c’est possible. La MFA protège les sessions interactives contre les mots de passe volés ; elle ne remplace cependant pas la RESTriction réseau ni la gestion des Tokens.
Durcissement de SSH et déploiements sécurisés
SSH est le point d’accès clé. Le durcissement réduit les attaques par force brute, améliore l’auditabilité et minimise le risque lié à la compromission du compte root.
Mise en œuvre progressive
- Inventaire : quels comptes utilisent SSH ? Où sont situés les authorized_keys ?
- Obligation : au moins un compte par nœud utilisant une clé fonctionnelle et une console locale disponible pendant les tests.
- Modifier la configuration : PasswordAuthentication no, PermitRootLogin no, LogLevel VERBOSE.
- Déploiement échelonné : nœud par nœud, monitoring après chaque modification.
# /etc/ssh/sshd_config (empfohlen, Auszug)
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
LogLevel VERBOSE
AllowGroups proxmox-adminsPrévoyez toujours un plan de retour : la console locale/IPMI peut annuler des modifications, sinon risque de verrouillage administratif.
Fail2ban, RESTrictions IP et scénarios NAT
Fail2ban aide contre les tentatives de connexion répétées, mais il doit être utilisé avec prudence dans des environnements avec NAT ou des proxys où plusieurs administrateurs partagent la même IP. Mettez en place des jeux d’IP en whitelist pour les jump hosts et les points de supervision automatisés.
# Fail2ban-Status prüfen
systemctl status fail2ban
fail2ban-client status sshd
# Beispiel: Whitelist in /etc/fail2ban/jail.d/proxmox.conf
# ignoreip = 10.0.0.5 192.168.100.0/24Vérifications d’audit, détection de dérive et contrôle automatisé
Le hardening n’est pas une action ponctuelle. Les audits automatisés détectent tôt la dérive de configuration et allègent la charge des opérations.
Contrôles essentiels (mensuels)
- État des patches: pveversion -v et révision du Kernel.
- Ports ouverts & sockets d’écoute: ss -tulpen.
- Statut du pare-feu & politique par défaut: pve-firewall status et nft list ruleset.
- Politique SSH: sshd -T.
- Consistance temporelle: timedatectl et journaux NTP/SNTP.
- Tests de sauvegarde/RESTauration: RESTauration complète en test isolé.
# Basis-Checks als Skript (Auszug)
pveversion -v; uname -a
ss -tulpen
pve-firewall status
sshd -T | egrep 'passwordauthentication|permitrootlogin' || true
timedatectl statusDétection de la dérive et journal des modifications
Utilisez la réplication de /etc/pve (pmxcfs‑Filesystem) et consignez les changements. Un simple diff avant/après maintenance évite les surprises. Transférez les journaux Journald vers un SIEM/central Syslog afin que les événements d’audit ne soient pas perdus.
Remarques spécifiques à VMware (migration et exploitation)
Beaucoup d’environnements Proxmox se situent dans le contexte de migrations depuis VMware. Lors du hardening, des questions spécifiques apparaissent : conversion des disques, mapping réseau et timeouts de stockage. Tenez compte de ces points lors de la fermeture des réseaux de management.
Pièges typiques en contexte VMware
- Format du disque : après qm importdisk ou conversion qemu‑img, vérifiez si les UUID des disques VM et les adaptateurs SCSI sont correctement mappés.
- Réseau : traduire les concepts vSwitch/DVSwitch en bridges/VLANs — un mauvais mapping de bridge peut exposer des routes de management.
- Stockage : les timeouts iSCSI/NFS sont fréquents lors des migrations ; ouvrez les ports de stockage nécessaires et augmentez éventuellement temporairement les timeouts pendant la migration.
Astuce de dépannage : si, après la migration, des réseaux manquent, vérifiez ‚qm config ‚ et comparez les entrées de bridge avec l’inventaire des bridges de l’hôte (ip -br a).
Runbook: hardening progressif avec plan de test
Un déploiement sécurisé comprend des tests, des points d’observation et des étapes de retour claires :
- Documenter l’état initial (ports, services, topologie de stockage).
- Test en labo : simuler les règles dans un cluster de test.
- Stage : appliquer les règles nœud par nœud, activer le monitoring.
- Production : activer la politique DEFAULT-DROP après 48–72 h d’exploitation sans incident.
- Revue : rapport d’audit et leçons apprises.
Supervision, journalisation et alertes
Centralisez les logs système, configurez des alertes pour les pertes Corosync, les timeouts de stockage, les arrêts de pve‑firewall et les tentatives SSH répétées. Les alertes doivent être explicites : p. ex. Corosync Quorum Lost — déclencher le runbook.
Conclusion
Le hardening de Proxmox est un processus continu avec une priorisation claire : segmentation, sécurisation des communications de cluster et de stockage, RESTriction progressive des accès API/GUI/SSH et contrôles d’audit établis. Planifiez chaque étape avec tests, monitoring et plan de retour documenté. Surtout lors de migrations depuis VMware et avec du stockage distribué, on constate que des règles de pare‑feu incomplètes et des modifications SSH non vérifiées entraînent des pannes plus rapidement que prévu. La séquence et les vérifications décrites ici réduisent le risque sans compromettre la disponibilité opérationnelle.
FAQ
L’interface Proxmox‑GUI (Port 8006) doit‑elle être accessible depuis Internet ?
Non. La Web‑GUI et l’API offrent de vastes possibilités d’administration. Il vaut mieux que l’accès soit possible exclusivement depuis un réseau de gestion isolé, via VPN ou un jump‑host. Si l’accès externe est inévitable, il doit être soumis à des couches de protection en amont (VPN, authentification forte, réseaux sources RESTrictifs, surveillance).
Que se passe‑t‑il si la pve‑firewall est activée sans préparation ?
Souvent, le trafic de cluster ou de stockage échoue parce que des règles nécessaires font défaut. Les conséquences sont des alertes de quorum, des migrations bloquées ou des timeouts de stockage. Par conséquent : autorisez d’abord explicitement le cluster et le stockage, ensuite RESTreignez le management et ne définissez Default‑DROP qu’en dernier.
Fail2ban suffit‑il comme protection pour les accès Proxmox ?
Fail2ban est une couche additionnelle utile contre les tentatives répétées, mais ne remplace pas la segmentation réseau, les règles de pare‑feu ni l’authentification forte. Dans des environnements NAT/Proxy, Fail2ban peut même poser problème si de nombreux utilisateurs se trouvent derrière une même IP.
Comment durcir SSH sans se verrouiller hors du système ?
Avant de désactiver les connexions par mot de passe, assurez‑vous qu’au moins un compte administrateur utilise l’authentification par clé. Utilisez sshd -t pour vérifier avant le redémarrage et conservez une seconde session ouverte. Testez les modifications d’abord sur un nœud et déployez‑les par étapes.
Quels contrôles d’audit sont les plus importants au quotidien ?
Des vérifications régulières du niveau de patch, des ports ouverts, de l’état du pare‑feu et de la politique SSH (pas de connexion par mot de passe, pas de login root) sont essentielles. En complément : cohérence NTP, tests de RESTauration de sauvegarde et journaux de changements traçables (diffs dans /etc/pve).
Exploitation, intégrations et risques : perspectives élargies
Outre le durcissement du pare‑feu, de l’API et du SSH, il convient d’examiner les processus opérationnels et les intégrations, car des risques négligés s’y cachent souvent. Trois domaines sont particulièrement critiques : la gestion des secrets, le cycle de vie des certificats/firmware et les modifications automatisées issues des pipelines CI/CD.
Gestion des secrets & des tokens
Les API‑tokens et clés de service sont des outils puissants — mais aussi des cibles attractives pour les attaques. Évitez les tokens longue durée dans des configurations en clair. Intégrez votre automatisation Proxmox dans une vault centralisée de secrets (par ex. HashiCorp Vault ou une PKI interne) et imposez la rotation des tokens ainsi que la séparation des rôles.
# Exemple : liste des API‑tokens (n'exécuter que localement en tant qu'admin)
pvesh get /access/tokens
# Utilisez le résultat comme liste de référence pour vos entrées dans la vaultPourquoi : les tokens peuvent être exposés via des sauvegardes, des logs CI ou des playbooks mal configurés. Risque : un token compromis permet des actions automatisées sur des VM sans connexion interactive.
PKI, certificats et renouvellement progressif
Une gestion centralisée des certificats réduit les risques d’indisponibilité dus aux certificats TLS expirés. Planifiez les renouvellements progressifs de sorte que tous les nœuds ne chargent pas simultanément de nouveaux certificats — sinon vous risquez une perte de communication du cluster. Automatisez les contrôles et les alertes sur les dates d’expiration, et ne vous contentez pas d’échantillonnages manuels.
# Vérification des certificats sur plusieurs hôtes (extrait)
for host in pve1 pve2 pve3; do
echo "Checking $host"
openssl s_client -connect ${host}:8006 -servername ${host} /dev/null | openssl x509 -noout -enddate
doneFirmware, hors‑bande et durcissement IPMI/Redfish
Les contrôleurs de management (IPMI/Redfish) sont des surfaces d’attaque indépendantes. Segmentez les réseaux OOB, activez StrongAuth et maintenez les mises à jour du firmware de façon automatisée. Documentez les identifiants Break‑Glass séparément de l’inventaire normal et testez la restauration OOB au moins tous les six mois.
Automatisation, CI/CD et contrôle des changements
Si des Playbooks exécutent directement des modifications sur Proxmox, les tests et les déploiements Canary doivent faire partie du processus. Effectuez des vérifications synthétiques (p. ex. démarrage/arrêt de VM, montage de stockage) en staging et instrumentez les rollbacks : les Playbooks doivent pouvoir annuler les modifications de manière idempotente.
SLOs, monitoring et escalade
Définissez des SLOs mesurables pour la santé du cluster (disponibilité du quorum), la latence du stockage et les temps de réponse des API. Des alarmes sans étapes de runbook claires génèrent du bruit ; associez les alertes à des diagnostics automatisés (collecte des logs, pveproxy health, corosync status) et à un chemin d’escalade clair.
Ces operationalisations comblent le fossé entre le durcissement technique et une exploitation fiable : celui qui gère les secrets, automatise les certificats et contrôle les changements réduit sensiblement le risque résiduel.
La sécurisation du Proxmox Firewall et de l’API Proxmox est également importante pour ce sujet. L’article replace ces aspects de façon compréhensible et montre ce qui importe au quotidien.