Operamos clústeres de Proxmox VE con almacenamiento Ceph en producción, repartidos en varios datacenters, desde mucho antes de que migrar de VMware se pusiera de moda. Y en todo este tiempo hemos aprendido una cosa incómoda: la mayoría de las guías de "hardening de Proxmox" son listas de comandos sin criterio. Te dicen qué tocar, pero no qué importa de verdad ni qué es postureo de seguridad que solo te complica la vida.
Esto no es esa lista. Es lo que aplicamos nosotros a cada cluster que ponemos en producción sobre Proxmox VE 9.2 (Debian 13.5, kernel 7.0), ordenado por lo que de verdad mueve la aguja. Si solo vas a hacer tres cosas, haz las tres primeras.
1. El acceso: 2FA en root@pam y cuentas nominales (no negociable)
Proxmox trae 2FA de serie. No hay excusa para no usarlo. La regla que seguimos:
- ✓2FA obligatorio en
root@pam, y ese usuario no se usa para el día a día. Es el rompe-cristales. - ✓Cuentas nominales para cada administrador, también con 2FA. Si alguien se va, revocas su cuenta, no cambias la contraseña de root para todo el equipo.
- ✓SSH del host: solo clave,
PermitRootLogin prohibit-passwordyPasswordAuthentication no. El panel web y el SSH son dos superficies distintas; las dos se cierran.
Esto no es glamuroso, pero el 90% de los incidentes que nos llegan de terceros empiezan por un acceso mal puesto, no por un 0-day exótico.
2. Tokens de API con privilegio mínimo
Aquí es donde casi todo el mundo mete la pata: crean un token de API con permisos de root "para que funcione" y lo dejan ahí para siempre.
Cuando integramos un cluster con una herramienta externa —monitorización, backup, automatización— creamos un usuario dedicado y un token de solo lectura con el rol integrado PVEAuditor, no un token con permisos de administrador. Si la herramienta solo necesita leer el estado del cluster, no le des permiso para apagar una VM. Parece obvio; casi nunca se hace.
3. Firewall: por defecto denegar, y segmenta las redes de Ceph
El firewall de Proxmox trabaja en tres niveles (datacenter, nodo, VM). Nuestra postura:
- ✓Deny por defecto en el datacenter, y abrir explícitamente lo que hace falta (8006 del panel, SSH, Corosync entre nodos).
- ✓El panel de administración no se expone a Internet. Se llega por VPN o por red de gestión. Punto.
- ✓Si corres Ceph —y si estás en serio, lo corres— separa el tráfico en VLANs: gestión, red de VMs, Corosync y Ceph, cada uno en lo suyo. La red cluster de Ceph (replicación) y la public no deben pelearse con Corosync por el mismo cable. Cuando Corosync pierde latencia porque la replicación de Ceph le está comiendo el ancho de banda, el cluster empieza a expulsar nodos, y a las 3 de la mañana no te apetece descubrir eso.
4. fail2ban y el ruido de fondo
En cuanto un host asoma a Internet, empieza a recibir intentos de login automatizados. fail2ban vigilando el SSH y el panel de Proxmox corta ese ruido y, de paso, te deja logs mucho más limpios para cuando de verdad tengas que investigar algo. Es barato de poner y quita mucho ruido.
5. AppArmor y endurecimiento del kernel
Proxmox viene con AppArmor; asegúrate de que está enforcing, no en complain. Y aplicamos un juego de parámetros sysctl de endurecimiento (protección de la pila de red, kptr_restrict, restricción de dmesg, etc.). No es magia, es reducir superficie: cada cosa que apagas es una cosa menos que alguien puede usar.
Un apunte de la 9.2: incorpora filtrado seccomp para bloquear escaladas de privilegios vía sockets AF_ALG en contenedores. Si usas LXC, ya lo tienes de serie —una razón más para estar actualizado.
6. Backups: cifrado en cliente e inmutabilidad (o no es un backup)
Un backup que un atacante puede borrar o leer no es un backup, es un consuelo. Con Proxmox Backup Server:
- ✓Cifrado en cliente: los datos salen cifrados del host. Si alguien accede al PBS, ve ruido.
- ✓Backups inmutables: que ni un administrador comprometido ni un ransomware puedan borrar los puntos de restauración dentro de su ventana de retención.
Y lo que no se prueba, no existe: verificamos restauraciones de forma periódica. Un backup no verificado es una hipótesis.
7. Parches: unattended-upgrades para lo crítico
Mantener el cluster actualizado es aburrido y por eso no se hace. Configuramos unattended-upgrades para los parches de seguridad críticos, y planificamos las actualizaciones mayores (como el salto a la 9.2) en ventana, con los nodos de uno en uno y el ok-to-stop de Ceph mirado antes de tocar nada.
Lo que NO hacemos (y por qué)
Tan importante como la lista es lo que dejamos fuera:
- ✗No convertimos el host en un búnker inusable. Seguridad que impide operar acaba desactivada por el propio equipo. El equilibrio es el trabajo.
- ✗No perseguimos el 100% de un benchmark CIS a ciegas. Los benchmarks son un punto de partida, no un objetivo. Hay controles que en un hipervisor de virtualización no aportan y sí rompen cosas.
- ✗No confiamos en "seguridad por oscuridad". Cambiar el puerto del SSH no es hardening; es maquillaje.
Un extra de la 9.2 que sí cambia cosas
La 9.2 trae WireGuard y BGP como protocolos de fabric en la pila SDN, con route maps y prefix lists para filtrado fino. Para quien monta redes de verdad entre sedes esto es relevante: puedes construir el fabric del cluster con las mismas herramientas con las que ya haces el enrutado del resto de tu red, en vez de con un apaño aparte. Nosotros ya vivíamos en WireGuard y BGP; tenerlo nativo en Proxmox nos quita piezas de en medio.
En corto
El hardening de Proxmox no es una lista de 40 comandos que ejecutas una vez. Es un puñado de decisiones bien puestas —accesos, privilegio mínimo, red segmentada, backups que aguantan— y una disciplina de mantenerlas. Lo demás es ruido.
Fuentes (datos de versión, verificados): Proxmox VE 9.2 (21-may-2026): Debian 13.5, kernel 7.0, CRS dinámico, SDN con WireGuard/BGP, seccomp AF_ALG en contenedores — proxmox.com; buenas prácticas de hardening PVE 9 — HomeSecExplorer Proxmox-Hardening-Guide.
¿Pones Proxmox en producción y quieres que alguien lo revise antes de que sea tarde?
En everyWAN diseñamos, desplegamos y operamos entornos Proxmox VE con Ceph en producción. Te revisamos el diseño y el hardening antes de que sea el diseño el que te revise a ti.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN