Hardening Proxmox: guía práctica de seguridad paso a paso
Proxmox VE llega con SSH root activo, firewall desactivado y sin ningún segundo factor. Esto es lo que aplico en cada nodo nuevo para reducir la superficie de ataque sin complicarme la vida.
Si acabas de instalar Proxmox, esto te toca
Acabas de instalar Proxmox VE, la interfaz web carga en el puerto 8006 y ya puedes crear VMs. Todo funciona. El problema es lo que no ves: root habilitado por SSH, firewall desactivado, certificado autofirmado y la gestión expuesta en la misma red que el resto de tus cacharros. Así sale Proxmox de fábrica, y es perfectamente razonable para los primeros diez minutos.
El lío empieza cuando quieres acceder desde fuera de casa, o cuando tu homelab crece y decides que merece la pena protegerlo en serio. Ahí es donde mucha gente improvisa: abre un puerto, añade una regla de firewall a medias, o simplemente cruza los dedos. Si estás en ese punto, o si ya tienes Proxmox expuesto y te pregunta qué deberías haber hecho antes, este post va exactamente de eso.
No hay fórmula mágica ni pasos que eliminen el riesgo por completo, pero sí hay una serie de ajustes concretos que reducen mucho la superficie de ataque. Son los mismos que aplico en mi propio setup cada vez que monto un nodo nuevo. Te los cuento con los comandos reales, la versión de PVE sobre la que los he probado y, cuando algo tiene trampa, lo digo.
Por qué importa
Acceso root, limitado
Crea un usuario PVE con rol granular y deshabilita el login root directo. Menos superficie, mismo control.
2FA desde PVE 7.0
Activa TOTP o WebAuthn en la UI web. Un token extra bloquea accesos aunque te roben la contraseña.
Backups cifrados
PBS cifra con AES-256-GCM y la clave la gestionas tú en cliente. Los snapshots sin PBS no cifran por defecto.
Red de gestión aislada
Mete la UI del puerto 8006 en una VLAN dedicada usando Linux bridges. Sin hardware extra, con mucho menos ruido externo.
El estado por defecto: qué viene (y qué no) activo tras la instalación
Proxmox VE llega con una instalación limpia y funcional. En minutos tienes la web UI corriendo en el puerto 8006 y tus primeras VMs listas para crear. El problema es que esa comodidad inicial viene con varios defaults que conviene revisar antes de exponer el nodo a algo más que tu red local de casa.
Lo que viene activo tras una instalación limpia en PVE 7.x/8.x:
- Login root por SSH: habilitado
- Interfaz web en el puerto 8006/tcp con certificado autofirmado
- Firewall del nodo y de las VMs: desactivado en todos los niveles
Lo que no viene de serie:
- fail2ban
- 2FA de ningún tipo
- Cifrado en snapshots ni backups
Esta guía recorre lo que aplico en cada nodo nuevo que instalo. No es el checklist definitivo ni promete blindar nada contra todo; hardening reduce la superficie de ataque, no elimina el riesgo. Pero son pasos razonables para un homelab expuesto o un servidor sin equipo de seguridad detrás.
SSH y usuarios: el primer frente
Deshabilitar el login directo de root por SSH
Root con SSH abierto es el combo que aparece en el primer barrido de cualquier herramienta de escaneo. En /etc/ssh/sshd_config (PVE 7.x y 8.x), cambiar esta línea:
PermitRootLogin noDespués reiniciar el servicio:
systemctl restart sshdAntes de hacer esto, asegúrate de tener un usuario alternativo funcional con acceso al nodo. Si te quedas sin acceso SSH y no tienes consola física o IPMI, lo pasas mal.
Crear un usuario operacional en el realm PVE
Proxmox tiene su propio sistema de usuarios, desacoplado del sistema operativo subyacente. Puedes crear usuarios en el realm pve con roles granulares: PVEAdmin para gestión completa, PVEAuditor para solo lectura, o roles personalizados si quieres afinar más los permisos.
Desde la CLI en PVE 8.x:
pveum useradd javi@pve --comment "Usuario operacional"
pveum passwd javi@pve
pveum aclmod / -user javi@pve -role PVEAdminCon esto, root queda reservado para emergencias desde consola física o IPMI, no para el trabajo diario. Deshabilitar el login root directo y usar un usuario PVE con rol limitado es uno de los cambios con mejor ratio esfuerzo/impacto de esta lista.
El firewall integrado de Proxmox: activarlo y configurarlo
El firewall integrado de Proxmox opera en tres niveles independientes: datacenter, nodo y VM/CT. Los tres vienen desactivados por defecto. Activarlos no equivale a tener un firewall perimetral dedicado —no lo es, y no debe confundirse con uno— pero añade una capa de control para tráfico entre segmentos internos y limita qué puertos quedan expuestos en el nodo.
Activar a nivel datacenter y nodo
Primero en Datacenter → Firewall → Options → Firewall: Yes, y después lo mismo en cada nodo.
Las reglas básicas que aplico siempre a nivel de nodo:
- Permitir 22/tcp únicamente desde mi segmento de gestión
- Permitir 8006/tcp únicamente desde mi segmento de gestión
- Política de entrada: DROP por defecto
Firewall por VM
Cada VM puede tener su propio firewall que hereda la política del datacenter. Para VMs con servicios expuestos, activo el firewall por VM y defino solo los puertos necesarios. Una VM con Nginx no necesita nada más que 80 y 443 abiertos hacia exterior.
Una aclaración que vale la pena repetir: el firewall de Proxmox no reemplaza a un firewall perimetral. Si tienes tráfico norte-sur sensible, sigue necesitando pfSense, OPNsense o similar delante del nodo.
2FA en la web UI: TOTP y WebAuthn
Desde PVE 7.0, Proxmox soporta dos factores nativos: TOTP y WebAuthn. TOTP funciona con cualquier app estándar —Aegis, Bitwarden, Google Authenticator—. WebAuthn permite llaves físicas tipo YubiKey o el autenticador integrado del navegador.
La configuración es por usuario, desde la web UI en User Settings → Two Factor → Add. Yo uso TOTP para los usuarios del realm pve del día a día.
Un detalle que aprendí a las malas: si habilitas 2FA para un usuario y pierdes el segundo factor, necesitas acceso root a la consola para resetear la configuración. Guarda el código de backup en un gestor de contraseñas, no en el propio nodo.
fail2ban: proteger SSH y la API web
fail2ban no viene preinstalado, pero está disponible en los repos de Debian sin complicaciones. Protege tanto el acceso SSH como la interfaz web de Proxmox, que también expone intentos de autenticación fallidos a través del puerto 8006.
Instalación en PVE 7.x/8.x:
apt install fail2banConfiguración básica en /etc/fail2ban/jail.local para SSH:
[sshd]
enabled = true
port = 22
maxretry = 5
bantime = 3600Para la web UI de Proxmox existen filtros de la comunidad que monitorizan /var/log/daemon.log buscando intentos fallidos contra el API de PVE. En mi nodo más expuesto, fail2ban bloquea entre 20 y 50 IPs distintas cada día. Sin él, esos intentos llegan directamente al servicio sin ningún freno.
Backups cifrados con Proxmox Backup Server
Los snapshots y backups de Proxmox no cifran por defecto. Si alguien accede al almacenamiento donde guardas los archivos de backup, tiene acceso directo a los datos de las VMs sin pasos adicionales.
Proxmox Backup Server (PBS) soporta cifrado AES-256-GCM gestionado en cliente. Esto significa que la clave de cifrado no sale del nodo origen: PBS almacena datos ya cifrados y no puede descifrarlos sin la clave. Para activarlo en un storage job:
- En el cliente PVE: Datacenter → Storage → tu storage PBS
- Activa la opción de cifrado y genera (o importa) la clave
- Guarda la clave en un lugar seguro fuera del nodo — si pierdes el nodo y la clave a la vez, los backups son inaccesibles
Una cosa que tardé en tener clara: el cifrado de PBS no afecta a los snapshots locales de ZFS o LVM. Esos quedan en claro en el storage local. Si necesitas cifrado local también, toca gestionarlo a nivel de sistema de ficheros con ZFS native encryption o LUKS.
Aislar la red de gestión: VLANs sin hardware adicional
El acceso a la web UI y al SSH de Proxmox no debería compartir red con las VMs de usuario ni con la red doméstica general. Con Linux bridges y un switch gestionado básico —o incluso con VLANs en software—, puedes aislar el tráfico de gestión sin necesitar hardware extra.
La idea básica: configurar el bridge principal como VLAN-aware y asignar la IP de gestión de Proxmox a una VLAN dedicada. En /etc/network/interfaces (PVE 8.x):
auto vmbr0
iface vmbr0 inet static
address 10.10.10.1/24
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yesDesde ahí, cada VM recibe su VLAN tag en la configuración de su interfaz de red. El tráfico de gestión queda en su propio segmento y las VMs no ven directamente la IP del hipervisor.
Si solo tienes un switch no gestionado, la alternativa más sencilla es restringir el acceso a 8006 y 22 por IP de origen usando las reglas del firewall integrado de Proxmox. No es tan limpio como una VLAN física, pero reduce la exposición de forma efectiva sin tocar el hardware de red.
Preguntas frecuentes
Q: ¿Por qué Proxmox instala con root SSH habilitado por defecto?
A: Es una decisión de accesibilidad para el instalador inicial, no una buena práctica permanente. En cuanto termines la instalación, lo primero es deshabilitar el login root directo por SSH y crear un usuario con privilegios limitados; en PVE 8.x esto se gestiona desde Datacenter → Permissions → Users con el realm 'Proxmox VE'.
Q: ¿Vale el firewall integrado de Proxmox para proteger el nodo?
A: El firewall de Proxmox (nodo y VM) está desactivado por defecto y, aunque es útil para segmentar tráfico entre VMs, no sustituye a un firewall perimetral dedicado. Úsalo como capa adicional, no como única barrera, y actívalo explícitamente en Datacenter → Firewall después de revisar las reglas para no quedarte sin acceso.
Q: ¿Cuándo merece la pena montar una VLAN solo para gestión de Proxmox?
A: Desde el primer día si tienes más de un dispositivo en red. Aislar la interfaz de gestión (puerto 8006) en una VLAN dedicada evita que cualquier equipo comprometido en tu red principal pueda alcanzar la UI o el API. Con Linux bridges en Proxmox puedes hacerlo sin hardware adicional, solo necesitas un switch gestionable.
Q: ¿Qué pasa si no activo 2FA en la interfaz web de Proxmox?
A: La UI en el puerto 8006 queda protegida solo por contraseña, que es un vector de ataque fácil si el puerto es accesible desde fuera. Proxmox soporta TOTP y WebAuthn desde PVE 7.0; activar cualquiera de los dos en Datacenter → Two Factor reduce drásticamente el riesgo de acceso no autorizado, especialmente si el nodo tiene IP pública o semipública.
Q: ¿Cómo protejo los backups si caen en manos equivocadas?
A: Por defecto, los snapshots y backups de Proxmox no cifran el contenido. Si usas Proxmox Backup Server, activa el cifrado en el cliente: PBS usa AES-256-GCM con la clave gestionada en tu lado, lo que significa que ni el propio servidor de backup puede leer los datos sin ella. Es la opción más limpia para homelab con datos sensibles.
Deja una respuesta