Operem clústers de Proxmox VE amb emmagatzematge Ceph en producció, repartits en diversos datacenters, des de molt abans que migrar de VMware es posés de moda. I en tot aquest temps hem après una cosa incòmoda: la majoria de les guies de "hardening de Proxmox" són llistes d'ordres sense criteri. Et diuen què tocar, però no què importa de debò ni què és postureig de seguretat que només et complica la vida.
Això no és aquella llista. És el que apliquem nosaltres a cada clúster que posem en producció sobre Proxmox VE 9.2 (Debian 13.5, kernel 7.0), ordenat pel que de debò mou l'agulla. Si només has de fer tres coses, fes les tres primeres.
1. L'accés: 2FA a root@pam i comptes nominals (no negociable)
Proxmox porta 2FA de sèrie. No hi ha excusa per no fer-lo servir. La regla que seguim:
- ✓2FA obligatori a
root@pam, i aquest usuari no es fa servir per al dia a dia. És el trenca-vidres. - ✓Comptes nominals per a cada administrador, també amb 2FA. Si algú marxa, li revoques el compte, no canvies la contrasenya de root per a tot l'equip.
- ✓SSH del host: només clau,
PermitRootLogin prohibit-passwordiPasswordAuthentication no. El panell web i l'SSH són dues superfícies diferents; totes dues es tanquen.
Això no és gens glamurós, però el 90% dels incidents que ens arriben de tercers comencen per un accés mal posat, no per un 0-day exòtic.
2. Tokens d'API amb privilegi mínim
Aquí és on gairebé tothom fica la pota: creen un token d'API amb permisos de root "perquè funcioni" i el deixen allà per sempre.
Quan integrem un clúster amb una eina externa —monitoratge, backup, automatització— creem un usuari dedicat i un token de només lectura amb el rol integrat PVEAuditor, no un token amb permisos d'administrador. Si l'eina només necessita llegir l'estat del clúster, no li donis permís per aturar una VM. Sembla obvi; gairebé mai no es fa.
3. Firewall: denegar per defecte, i segmenta les xarxes de Ceph
El firewall de Proxmox treballa en tres nivells (datacenter, node, VM). La nostra postura:
- ✓Deny per defecte al datacenter, i obrir explícitament el que cal (el 8006 del panell, SSH, Corosync entre nodes).
- ✓El panell d'administració no s'exposa a Internet. S'hi arriba per VPN o per xarxa de gestió. Punt.
- ✓Si fas anar Ceph —i si t'ho prens seriosament, el fas anar— separa el trànsit en VLANs: gestió, xarxa de VMs, Corosync i Ceph, cadascun al seu lloc. La xarxa cluster de Ceph (replicació) i la public no s'han de barallar amb Corosync pel mateix cable. Quan Corosync perd latència perquè la replicació de Ceph li està menjant l'ample de banda, el clúster comença a expulsar nodes, i a les 3 de la matinada no ve de gust descobrir això.
4. fail2ban i el soroll de fons
Tan bon punt un host treu el cap a Internet, comença a rebre intents de login automatitzats. fail2ban vigilant l'SSH i el panell de Proxmox talla aquest soroll i, de passada, et deixa uns logs molt més nets per quan de debò hagis d'investigar alguna cosa. És barat de posar i treu molt de soroll.
5. AppArmor i enduriment del kernel
Proxmox ve amb AppArmor; assegura't que està en enforcing, no en complain. I apliquem un joc de paràmetres sysctl d'enduriment (protecció de la pila de xarxa, kptr_restrict, restricció de dmesg, etc.). No és màgia, és reduir superfície: cada cosa que apagues és una cosa menys que algú pot fer servir.
Un apunt de la 9.2: incorpora filtratge seccomp per bloquejar escalades de privilegis via sockets AF_ALG en contenidors. Si fas servir LXC, ja el tens de sèrie —una raó més per estar actualitzat.
6. Backups: xifratge en client i immutabilitat (o no és un backup)
Un backup que un atacant pot esborrar o llegir no és un backup, és un consol. Amb Proxmox Backup Server:
- ✓Xifratge en client: les dades surten xifrades del host. Si algú accedeix al PBS, veu soroll.
- ✓Backups immutables: que ni un administrador compromès ni un ransomware puguin esborrar els punts de restauració dins de la seva finestra de retenció.
I el que no es prova, no existeix: verifiquem restauracions de forma periòdica. Un backup no verificat és una hipòtesi.
7. Pedaços: unattended-upgrades per al que és crític
Mantenir el clúster actualitzat és avorrit i per això no es fa. Configurem unattended-upgrades per als pedaços de seguretat crítics, i planifiquem les actualitzacions majors (com el salt a la 9.2) en finestra, amb els nodes d'un en un i l'ok-to-stop de Ceph mirat abans de tocar res.
El que NO fem (i per què)
Tan important com la llista és el que en deixem fora:
- ✗No convertim el host en un búnquer inservible. La seguretat que impedeix operar acaba desactivada pel mateix equip. L'equilibri és la feina.
- ✗No perseguim el 100% d'un benchmark CIS a cegues. Els benchmarks són un punt de partida, no un objectiu. Hi ha controls que en un hipervisor de virtualització no aporten res i sí que trenquen coses.
- ✗No confiem en la "seguretat per obscuritat". Canviar el port de l'SSH no és hardening; és maquillatge.
Un extra de la 9.2 que sí que canvia coses
La 9.2 porta WireGuard i BGP com a protocols de fabric a la pila SDN, amb route maps i prefix lists per a un filtratge fi. Per a qui munta xarxes de veritat entre seus, això és rellevant: pots construir el fabric del clúster amb les mateixes eines amb què ja fas l'enrutament de la resta de la teva xarxa, en comptes d'amb un apany a part. Nosaltres ja vivíem a WireGuard i BGP; tenir-ho natiu a Proxmox ens treu peces del mig.
En curt
El hardening de Proxmox no és una llista de 40 ordres que executes una vegada. És un grapat de decisions ben posades —accessos, privilegi mínim, xarxa segmentada, backups que aguanten— i una disciplina de mantenir-les. La resta és soroll.
Fonts (dades de versió, verificades): Proxmox VE 9.2 (21-maig-2026): Debian 13.5, kernel 7.0, CRS dinàmic, SDN amb WireGuard/BGP, seccomp AF_ALG en contenidors — proxmox.com; bones pràctiques de hardening PVE 9 — HomeSecExplorer Proxmox-Hardening-Guide.
Poses Proxmox en producció i vols que algú ho revisi abans que sigui tard?
A everyWAN dissenyem, desplegem i operem entorns Proxmox VE amb Ceph en producció. Et revisem el disseny i el hardening abans que sigui el disseny qui et revisi a tu.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN