Checklist de seguridad de Proxmox: 2FA, RBAC, cortafuegos, actualizaciones y acceso remoto seguro

Modelo de amenazas en una página: qué estás defendiendo

Proxmox es un plano de gestión, no solo un hipervisor. Si un atacante entra en Proxmox, no solo obtiene una VM.
Obtiene la capacidad de montar discos, hacer snapshots y exfiltrar datos, leer la salida de la consola (hola, secretos), adjuntar ISOs y
cambiar la configuración de red. “Root en el host” es catastrófico; “admin en la interfaz” suele ser equivalente.

Qué suele salir mal

• Interfaz de gestión expuesta (8006) a Internet, a veces con autenticación por contraseña y sin 2FA.
• Operadores con permisos excesivos (“solo dales PVEAdmin para que hagan su trabajo”) que se vuelven permanentes.
• Suposiciones sobre el cortafuegos: la gente piensa que el cortafuegos del datacenter está “activado” porque la UI tiene una casilla.
• Evasión de parches porque “no podemos reiniciar”. Spoiler: puedes, o reiniciarás a las 3 a.m. durante un incidente.
• Atajos de acceso remoto: SSH desde cualquier lugar, jump boxes compartidos o, peor aún, cuentas compartidas.

Prioridades de endurecimiento (opinión)

1. Haz la planeación de gestión inaccesible desde redes no fiables. VPN o red de administración dedicada.
2. Imponer 2FA para todos los humanos. Tokens para la automatización.
3. Usar RBAC correctamente: mínimo privilegio, roles explícitos y separación entre “operar VMs” y “cambiar el clúster.”
4. Activar y verificar el cortafuegos en la capa adecuada, con deny por defecto donde importe.
5. Parchear con un plan: ventanas de mantenimiento previsibles, actualizaciones escalonadas y disciplina de reinicios.

Idea parafraseada de Werner Vogels (confiabilidad/operaciones): “Todo falla eventualmente; diseña asumiendo fallos, no asumiendo perfección.”
Esa es la energía que quieres aquí.

Hechos y contexto interesantes (para que dejes de cometer errores de 2008)

• Hecho 1: El puerto de gestión por defecto de Proxmox VE es 8006, y a los escáneres les encanta porque es consistente y ruidoso.
• Hecho 2: El cortafuegos de Proxmox no es “solo iptables.” Compila reglas y las gestiona; necesitas verificar las reglas efectivas en el host.
• Hecho 3: RBAC en Proxmox se basa en rutas. Los permisos se heredan por el árbol de objetos (datacenter → nodo → VM), lo cual es potente y fácil de sobredimensionar.
• Hecho 4: Los tokens de API existen por una razón: la automatización no debe iniciar sesión como humano. Los tokens se pueden delimitar y rotar con menos drama.
• Hecho 5: Las redes de gestión se volvieron un patrón estándar en los 2000 porque los errores con VLANs de administración eran menos costosos que “flota completa comprometida”.
• Hecho 6: “SSH solo con contraseña” sobrevivió más tiempo del que debería por conveniencia. La conveniencia no es un control; es una responsabilidad.
• Hecho 7: La cultura de empaquetado de Debian favorece la estabilidad, pero las correcciones de seguridad llegan con frecuencia. “Stable” no es “estático”.
• Hecho 8: El tráfico de clúster (Corosync) tiene necesidades muy diferentes al tráfico de la UI web; tratarlo como tráfico normal de usuario es una gran manera de provocar caídas.

Listas de verificación / plan paso a paso (haz esto, no intuiciones)

Día 0–1: Detener la hemorragia

1. Bloquea el acceso público a 8006 y a SSH en el perímetro. Si no puedes, no tienes un plano de gestión: tienes una API pública.
2. Activa 2FA para todos los usuarios interactivos. Sin excepciones para cuentas “temporales”.
3. Audita usuarios/tokens. Elimina cuentas obsoletas, rota secretos, elimina inicios de sesión compartidos.
4. Confirma el estado del cortafuegos (datacenter + nodo) y verifica las reglas efectivas en el host.
5. Línea base de parches: actualiza todos los nodos con correcciones de seguridad; programa reinicios.

Semana 1: Hazlo aburrido

1. Define roles RBAC para trabajos comunes (operador VM, operador de backups, admin de almacenamiento, admin de clúster).
2. Isola la gestión en una red de administración o VPN, y enlaza servicios a ella donde sea práctico.
3. Endurece SSH (claves, sin login root, redes origen restringidas).
4. Registro y alertas: rastrea fallos de autenticación, cambios de configuración y descartes del cortafuegos.

Mes 1: Reduce el radio de impacto

1. Separación de funciones: cambios en la membresía del clúster y cambios de almacenamiento deben limitarse a un conjunto pequeño de personas.
2. Prueba las rutas de restauración y asegura el almacenamiento de backups; los backups son el primer objetivo de exfiltración tras los datos primarios.
3. Documenta runbooks para respuesta a incidentes: dispositivo 2FA perdido, cuenta comprometida, reconstrucción de nodo.

2FA que realmente reduce el riesgo (y no deja a los admins fuera)

2FA no es mágico. Es un cinturón de seguridad: no previene accidentes; evita que un mal día se convierta en un día catastrófico.
Usa TOTP o WebAuthn según tu cultura y herramientas. En la práctica, TOTP es lo más sencillo de desplegar. WebAuthn es mejor cuando la organización
ya entiende las llaves de seguridad y el ciclo de vida de dispositivos.

Reglas que aplico en producción

• 2FA obligatorio para todas las cuentas humanas con acceso a la UI o a la shell.
• No hay cuentas compartidas. Las cuentas compartidas convierten las auditorías en ficción.
• Existe un mecanismo de emergencia, pero es feo: procedimiento sellado, almacenado fuera de línea y usado con registro en papel.
• La automatización usa tokens de API, no inicios de sesión con contraseñas. Los tokens se rotan; a los humanos se les sanciona por incrustar contraseñas en scripts.

Chiste 1: 2FA es como usar hilo dental: todo el mundo está de acuerdo en que es buena idea, y luego “empiezan la próxima semana” durante tres años.

Modos de fallo para planificar

• Dispositivo perdido: si no tienes un flujo de recuperación, tu “mejora de seguridad” se convierte en tiempo de inactividad.
• Deriva de tiempo: TOTP falla si la hora del host es incorrecta. NTP no es opcional.
• Malware que registra pantalla o portapapeles: 2FA no arregla endpoints comprometidos. Solo eleva la barrera.

RBAC: diseño de permisos para personas que cometerán errores

La trampa con RBAC de Proxmox es que es potente y engañosamente simple. Asignas un rol a un usuario en una ruta, y se hereda.
Dos meses después, alguien se pregunta por qué un contratista puede modificar almacenamiento en todos los nodos. Respuesta: porque le diste permisos en /.

Patrón de diseño RBAC que funciona

• Usa grupos para personas. Asigna roles a grupos, no a individuos. Los individuos van y vienen; los grupos representan política.
• Usa rutas estrechas. Asigna operadores de VM en /vms o pools específicos, no en /.
• Separa “operar” de “cambiar infraestructura”. Iniciar/detener VMs no es lo mismo que añadir almacenamiento o unir nodos a un clúster.
• Limita el acceso a auditoría/logs. Los logs contienen secretos más a menudo de lo que crees (cloud-init user-data, salida de consola, tokens en variables de entorno).

Roles que vale la pena definir (ejemplos)

• Operador VM: iniciar/detener, acceso a consola, snapshot (tal vez), pero sin almacenamiento ni cambios de red.
• Operador de backups: ejecutar/monitorizar backups, restaurar en un pool de cuarentena, pero no modificar la red de producción.
• Admin de almacenamiento: configuración de almacenamiento, replicación, trabajos de limpieza. Sin permiso para cambiar la autenticación de usuarios.
• Admin de clúster: raro. Puede cambiar la membresía del clúster, la configuración de corosync, y mantenimiento de nodos.

Si no puedes explicar un rol en una frase, no es un rol. Es un cubo.

Cortafuegos para Proxmox: host, datacenter y “no expongas la interfaz”

El cortafuegos de Proxmox puede ser excelente. También puede ser un placebo si no entiendes qué se aplica realmente.
La postura de seguridad nunca debe depender de una casilla en una GUI. Necesitas defensa en profundidad: cortafuegos perimetral, aislamiento de red de gestión
y controles a nivel host.

Reglas de entrada innegociables

• UI de gestión (8006): solo desde la red de administración / VPN.
• SSH (22): solo desde la red de administración / bastión.
• Tráfico de clúster: solo entre nodos en la red del clúster (y no lo hagas NAT).
• Backends de almacenamiento (NFS, iSCSI, Ceph, etc.): solo entre los participantes correctos. No “any to any”.

Deny por defecto donde importa

El modelo más seguro es deny por defecto en las interfaces de gestión, con permisos explícitos. Para bridges de VM, la historia depende de tu modelo de tenants.
Si ejecutas cargas internas y confías en tus políticas este-oeste, puedes ser menos estricto. Si eres multi-tenant,
asume que alojas adversarios creativos.

No confundas “puede hacer ping” con “es seguro”

La accesibilidad ICMP te dice casi nada. Los atacantes no necesitan ping. Necesitan un socket alcanzable y un error.
Tu trabajo es hacer que el socket no sea alcanzable desde sitios donde no debería existir.

Actualizaciones y mantenimiento: parchea rápido sin apostar la disponibilidad

La disciplina de parches es un problema cultural disfrazado de técnico. La parte técnica es fácil: apt updates, reiniciar cuando haga falta,
migrar VMs, repetir. La parte cultural es más difícil: lograr que la dirección acepte que el tiempo de inactividad planificado es más barato que el tiempo de inactividad sorpresa.

Estrategia de parches en producción que escala

• Actualizaciones escalonadas: nunca actualices todos los nodos a la vez. Un nodo primero, luego el resto.
• Ventana de mantenimiento: aunque sea solo una hora semanal. Lo predecible vence a lo heroico.
• Política de reinicios: actualizaciones de kernel implican reinicio. Sí, puedes posponer; no deberías hacerlo indefinidamente.
• Prueba después de actualizar: quórum del clúster, montajes de almacenamiento, arranque de VMs, backups y reglas de cortafuegos.

Chiste 2: “No reiniciamos producción” es una gran política—hasta que tu kernel reinicia producción por ti en el peor momento posible.

Actualizaciones de seguridad vs actualizaciones de funcionalidades

Sepáralas mentalmente. Las actualizaciones de seguridad tienen urgencia. Las de funcionalidades requieren escrutinio. En la práctica en Proxmox, a menudo harás ambas vía apt,
así que tu proceso debe incluir una comprobación rápida de sanidad. Si eres alérgico al cambio, también eres alérgico a la seguridad.

Acceso remoto seguro: VPN, bastiones y buenas prácticas SSH

La única forma segura de administrar Proxmox de forma remota es reducir el número de lugares desde los que la gestión es alcanzable.
“Permitido desde Internet pero protegido por un gestor de contraseñas” no es una estrategia. Es una confesión.

Patrones preferidos (elige uno, no improvises)

1. VPN a una red de administración: el modelo operativo más simple. Los admins se autentican en la VPN y luego acceden a Proxmox de forma privada.
2. Bastión / jump host: SSH al bastión con autenticación fuerte y luego salto a nodos Proxmox. Acceso a la UI mediante reenvío de puerto o proxy interno.
3. Red de gestión dedicada accesible solo desde on-prem o VPN: el modelo “enterprise aburrido”, por una buena razón.

Reglas de endurecimiento SSH que no arruinan tu vida

• Sólo claves, sin autenticación por contraseña.
• Sin login root vía SSH. Usa sudo con usuarios auditados.
• Limita IPs origen a subredes de administración.
• Cuenta administrativa separada por persona; usa grupos y reglas sudo.

Acceso a la UI web sin abrir al mundo

Si debes acceder a la UI de forma remota, hazlo mediante VPN. Si no puedes, coloca un proxy inverso con autenticación fuerte y lista de IPs permitidas
y acepta que has añadido complejidad. La complejidad no es un control, pero puede ser un control compensatorio si lo operas bien.

Tareas de auditoría con comandos: qué ejecutar, qué significa, qué decides

Estas son tareas reales de operador. Ejecútalas en cada nodo (o centralmente donde se indique). Para cada una: comando, salida de ejemplo, qué significa,
y la decisión que tomas.

Task 1: Verify Proxmox version and cluster state

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/9355359f (running kernel: 6.8.12-2-pve)
proxmox-ve/8.2.0 (running kernel: 6.8.12-2-pve)
pve-kernel-6.8/6.8.12-2

Qué significa: Estás en PVE 8.2.x con un kernel específico. Si distintos nodos muestran versiones menores diferentes, estás en terreno “funciona hasta que no”.

Decisión: Alinea versiones en todo el clúster antes de depurar comportamientos extraños o desplegar nuevas funcionalidades.

Task 2: Check cluster health and quorum

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 10:14:22 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Qué significa: El quórum está sano. Si aparece Quorate: No, no cambies la configuración del clúster; estás a un error de causar una indisponibilidad.

Decisión: Si no hay quórum, arregla la red entre nodos primero; pospón actualizaciones y reinicios.

Task 3: Confirm NTP/time sync (2FA depends on it)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:14:42 UTC
           Universal time: Sun 2025-12-28 10:14:42 UTC
                 RTC time: Sun 2025-12-28 10:14:41
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: El reloj está sincronizado. Si no lo está, las fallas de TOTP y problemas TLS aparecen como fantasmas.

Decisión: Si no está sincronizado, arregla NTP antes de desplegar o imponer 2FA.

Task 4: List users and identify local vs realm accounts

cr0x@server:~$ pveum user list
┌──────────────┬─────────┬───────────────────────┬────────────┬────────┬──────────────┐
│ userid       │ enable  │ expire                │ firstname  │ lastname│ email        │
╞══════════════╪═════════╪═══════════════════════╪════════════╪════════╪══════════════╡
│ root@pam     │ 1       │                       │            │        │              │
│ alice@pam    │ 1       │                       │ Alice      │ Ops    │              │
│ bob@pve      │ 1       │ 2026-01-31 00:00:00   │ Bob        │ Eng    │              │
└──────────────┴─────────┴───────────────┴────────────┴────────┴──────────────┘

Qué significa: Tienes usuarios en diferentes realms (@pam, @pve). Existen expiraciones; úsalas para contratistas.

Decisión: Deshabilita o expira cuentas que no correspondan a una persona activa con un ticket.

Task 5: Check 2FA/TOTP configuration for a user

cr0x@server:~$ pveum user get alice@pam
enable: 1
expire: 0
firstname: Alice
lastname: Ops
groups: ops
keys:
totp:
  enabled: 1
  issuer: pve
  realm: pam

Qué significa: TOTP está habilitado para el usuario. Si aparece enabled: 0, aún puede iniciar sesión solo con contraseña a menos que impongas la política externamente.

Decisión: Exige 2FA para usuarios interactivos; crea un método de emergencia auditable.

Task 6: Review groups and role assignments (RBAC audit)

cr0x@server:~$ pveum group list
┌────────────┬────────┬─────────────┐
│ groupid    │ comment│ users       │
╞════════════╪════════╪═════════════╡
│ ops        │        │ alice@pam   │
│ vm-ops     │        │ bob@pve     │
└────────────┴────────┴─────────────┘

cr0x@server:~$ pveum acl list
┌────────────┬──────────┬───────────────┬───────────┐
│ path       │ type     │ ugid          │ roleid    │
╞════════════╪══════════╪═══════════════╪═══════════╡
│ /          │ group    │ ops           │ PVEAdmin  │
│ /vms       │ group    │ vm-ops        │ PVEVMAdmin│
└────────────┴──────────┴───────────────┴───────────┘

Qué significa: El grupo ops tiene PVEAdmin en /, lo que equivale efectivamente a “modo dios”. Esto es una sobreasignación común.

Decisión: Mueve roles amplios fuera de /. Da PVEAdmin solo a un pequeño grupo de administradores de clúster y limita los demás a pools/rutas.

Task 7: Inspect API tokens (automation hygiene)

cr0x@server:~$ pveum user token list alice@pam
┌───────────────┬────────┬──────────────┬──────────┐
│ tokenid       │ enable │ expire       │ privsep  │
╞═══════════════╪════════╪══════════════╪══════════╡
│ backup-bot    │ 1      │ 2026-03-01   │ 1        │
└───────────────┴────────┴──────────────┴──────────┘

Qué significa: Existen tokens y privsep está activado (bien). Hay fecha de expiración (mejor).

Decisión: Rota tokens según un calendario; deshabilita tokens que no estén ligados a un flujo de trabajo controlado.

Task 8: Confirm Proxmox firewall is enabled (datacenter and node)

cr0x@server:~$ pvesh get /cluster/firewall/options
{ "enable": 1, "policy_in": "DROP", "policy_out": "ACCEPT", "log_level_in": "info" }

cr0x@server:~$ pvesh get /nodes/pve1/firewall/options
{ "enable": 1, "policy_in": "DROP", "policy_out": "ACCEPT", "log_level_in": "info" }

Qué significa: El cortafuegos está habilitado y la política de entrada por defecto es DROP. Si está deshabilitado en alguna capa, las reglas pueden no aplicarse donde crees.

Decisión: Si la entrada está en ACCEPT en interfaces de gestión, cámbialo y permite explícitamente las subredes administrativas necesarias.

Task 9: Verify effective listening services and bind addresses

cr0x@server:~$ ss -lntp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:8006       0.0.0.0:*     users:(("pveproxy",pid=1520,fd=6))
LISTEN 0      4096   0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=1042,fd=3))
LISTEN 0      4096   127.0.0.1:85       0.0.0.0:*     users:(("pvedaemon",pid=1400,fd=12))

Qué significa: La UI y SSH escuchan en todas las interfaces (0.0.0.0). Eso no es automáticamente incorrecto, pero eleva el riesgo: el cortafuegos y el aislamiento de red deben ser correctos.

Decisión: Si puedes, liga la gestión a una interfaz administrativa; de lo contrario impón listas de permiso de entrada estrictas.

Task 10: Check actual firewall rules on the host (truth serum)

cr0x@server:~$ nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    ip saddr 10.50.0.0/24 tcp dport { 22, 8006 } accept
    ip saddr 10.50.0.0/24 icmp type echo-request accept
    counter log prefix "PVE-DROP " drop
  }
}

Qué significa: Drop por defecto, permite explícito desde la subred administrativa a SSH/UI. Esto es lo que quieres: legible, mínimo y aplicable.

Decisión: Si la política es accept o faltan reglas, corrige la configuración del cortafuegos y verifica aquí—no solo en la UI.

Task 11: Verify SSH config isn’t quietly permissive

cr0x@server:~$ sshd -T | egrep '^(passwordauthentication|permitrootlogin|pubkeyauthentication|allowusers|allowgroups)'
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Qué significa: La autenticación por contraseña está desactivada; el login root está desactivado; la autenticación por clave está activa. Si aparece passwordauthentication yes, estás invitando a fuerza bruta si está expuesto.

Decisión: Desactiva la autenticación por contraseña y restringe fuentes; luego prueba el acceso con una segunda sesión abierta.

Task 12: Check for pending reboots after kernel/security updates

cr0x@server:~$ [ -f /var/run/reboot-required ] && echo "reboot required" || echo "no reboot required"
reboot required

Qué significa: Estás corriendo con un riesgo de descoordinación kernel/usuarios y correcciones de seguridad sin aplicar que requieren reinicio.

Decisión: Programa migración y reinicio en la siguiente ventana. No dejes esto meses sin atender.

Task 13: See what updates are pending (before you surprise yourself)

cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,40p'
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-manager pve-kernel-6.8 proxmox-widget-toolkit
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Qué significa: La simulación del upgrade muestra lo que cambiará. Si ves cambios en corosync o libc, planifica reinicios y una secuencia cuidadosa.

Decisión: Aprueba el cambio en tu plan de mantenimiento; haz staging en un nodo primero.

Task 14: Validate management UI TLS certificate state (avoid self-inflicted distrust)

cr0x@server:~$ openssl s_client -connect 127.0.0.1:8006 -servername pve1 -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = pve1
issuer=CN = pve1
notBefore=Sep  1 00:00:00 2025 GMT
notAfter=Sep  1 00:00:00 2035 GMT

Qué significa: Estás usando un certificado autofirmado (issuer igual que subject). Está bien internamente si lo confías/distribuyes; es descuidado si expones la UI externamente.

Decisión: Mantén la UI interna. Si debes exponerla, termina TLS correctamente con un certificado gestionado y autenticación fuerte delante.

Task 15: Check auth failures in logs (attack surface reality check)

cr0x@server:~$ journalctl -u pveproxy --since "24 hours ago" | egrep -i 'authentication|login|failed' | tail -n 10
Dec 28 08:41:12 pve1 pveproxy[1520]: authentication failure; rhost=198.51.100.23 user=root@pam
Dec 28 08:41:14 pve1 pveproxy[1520]: authentication failure; rhost=198.51.100.23 user=admin@pve

Qué significa: Alguien está golpeando. Si esa IP no es tu VPN/bastión, tu plano de gestión es alcanzable desde redes no confiables.

Decisión: Arregla el enrutamiento/cortafuegos ahora. Luego considera bloquear en el perímetro; los bloqueos en host son un vendaje, no una armadura.

Task 16: Confirm only expected subnets can reach the UI from a remote vantage point

cr0x@server:~$ nc -vz -w2 10.10.10.11 8006
nc: connect to 10.10.10.11 port 8006 (tcp) failed: Connection refused

Qué significa: Desde este punto de vista, la UI no es alcanzable. “Connection refused” o “timed out” es lo que quieres desde redes no administrativas.

Decisión: Si el puerto está abierto desde redes generales, corrige ACLs y valida de nuevo desde varias redes.

Guía rápida de diagnóstico (primeras/segundas/terceras comprobaciones)

Cuando “algo de seguridad” se rompe, suele romper el acceso. Cuando el acceso se rompe, la gente entra en pánico y empieza a desactivar controles.
Este playbook está diseñado para evitar que “arregles” la seguridad apagándola.

Escenario A: El admin no puede iniciar sesión en la UI

1. Comprueba la sincronización de tiempo (fallos TOTP/WebAuthn suelen ser deriva de reloj). Ejecuta timedatectl. Si no está sincronizado, arregla NTP y prueba de nuevo.
2. Comprueba la accesibilidad desde la red correcta. ¿Estás en la VPN/VLAN administrativa? Valida con nc -vz pve1 8006.
3. Revisa los logs de pveproxy para errores de autenticación vs TLS vs bloqueos de red (journalctl -u pveproxy).

Escenario B: Operaciones de clúster lentas o fallando después de cambios en el cortafuegos

1. Comprueba el quórum (pvecm status). Si el quórum es inestable, detén los cambios.
2. Revisa la conectividad inter-nodos en la red del clúster (ping es insuficiente; verifica puertos relevantes si los conoces y revisa descartes).
3. Inspecciona contadores/logs de nftables (nft list ruleset, luego busca contadores de drop). Si ves descartes entre IPs de nodos, arregla reglas de allow.

Escenario C: Sospechas que la UI está expuesta públicamente

1. Revisa logs por IPs externas que golpean endpoints de autenticación (journalctl -u pveproxy).
2. Confirma bind/listen (ss -lntp). Escuchar en 0.0.0.0:8006 no prueba exposición, pero aumenta el riesgo.
3. Verifica controles de perímetro: ¿puede una ubicación no administrativa alcanzar 8006? Si sí, bloquéalo en perímetro y en el host.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Los códigos 2FA “nunca funcionan” para varios usuarios

Causa raíz: Deriva de tiempo en el nodo (o en clientes), NTP desactivado o problemas del reloj del host de virtualización.

Solución: Activa NTP, verifica que timedatectl muestre sincronización y vuelve a inscribir si es necesario. No bajes requisitos de autenticación para “arreglar” esto.

2) Síntoma: Un operador puede borrar almacenamiento o cambiar la red “por accidente”

Causa raíz: Rol RBAC asignado en / o uso de roles integrados demasiado amplios por conveniencia.

Solución: Crea grupos y ACLs acotadas en rutas/pools específicos; reserva PVEAdmin para un pequeño grupo de admins de clúster.

3) Síntoma: Cortafuegos activado, pero el puerto 8006 sigue siendo alcanzable desde todas partes

Causa raíz: Cortafuegos activado en datacenter pero desactivado en el nodo, reglas aplicadas a la interfaz equivocada, o un cortafuegos/NAT upstream que elude expectativas.

Solución: Verifica opciones de datacenter y nodo con pvesh. Confirma reglas efectivas con nft list ruleset. Arregla ACLs de perímetro.

4) Síntoma: El clúster se vuelve inestable tras “endurecer reglas de cortafuegos”

Causa raíz: Bloquear tráfico corosync/knet entre nodos, o mezclar redes de gestión y clúster con reglas asimétricas.

Solución: Permite explícitamente el tráfico inter-nodos del clúster en la interfaz del clúster. Valida la estabilidad del quórum antes y después de los cambios.

5) Síntoma: Tras actualizaciones, las VMs se migran pero el rendimiento cae

Causa raíz: Desajuste kernel/controlador, cambios en ajustes offload de NIC, o impacto en la ruta de almacenamiento; también puede ser que un nodo ahora es “diferente”.

Solución: Alinea versiones entre nodos. Revisa dmesg, versiones de drivers de NIC y salud del almacenamiento. Aplica cambios gradualmente la próxima vez.

6) Síntoma: Se pierde acceso SSH tras endurecer

Causa raíz: Desactivar autenticación por contraseña antes de distribuir claves, IPs restringidas incorrectamente o bloqueo por cortafuegos.

Solución: Mantén una consola root activa (iLO/IPMI/KVM) antes de cambios SSH. Aplica listas de permitidos con cuidado y prueba con una segunda sesión abierta.

7) Síntoma: Los backups funcionan pero las restauraciones fallan durante un incidente

Causa raíz: No se probaron restauraciones; permisos/rutas de almacenamiento de backups cambiaron; claves de cifrado no disponibles; o objetivos de restauración bloqueados por RBAC.

Solución: Prueba restauraciones trimestralmente (como mínimo). Guarda claves en un sistema controlado. Asegura que operadores de backups puedan restaurar en un entorno de cuarentena.

Tres mini-historias corporativas desde el terreno

Historia 1: El incidente causado por una suposición incorrecta

Una empresa mediana ejecutaba un clúster Proxmox de tres nodos para servicios internos: runners de CI, algunas bases de datos y un «jump box temporal»
que se volvió permanente porque todo lo temporal se vuelve permanente. Tenían un cortafuegos de última generación en el perímetro y creían que la UI de gestión
“no estaba expuesta”. Nadie podía señalar una regla, pero todos apuntaban a una creencia.

Una auditoría empezó después de que un proveedor pidiera una lista de IPs permitidas. El equipo de seguridad hizo un escaneo desde fuera y encontró el puerto 8006 abierto.
No “filtrado”. Abierto. El cortafuegos perimetral tenía una regla de NAT por conveniencia durante una migración remota meses antes, y nadie la quitó.
La UI era alcanzable con solo autenticación por contraseña para un par de cuentas legacy.

La línea temporal del evento no fue dramática. Un bot golpeó la UI, probó nombres de usuario comunes, encontró una cuenta con un patrón de contraseña antiguo y entró.
Una vez dentro, no necesitó exploits de kernel. Usó la UI como un admin: descargó backups de VM, montó discos y creó un nuevo usuario privilegiado.
La “compromiso del hipervisor” fue realmente “compromiso del plano de control”.

La recuperación fue dolorosa porque el modelo mental del equipo era erróneo. Seguían investigando vulnerabilidades de VM mientras el atacante operaba el plano de control.
La solución fue también aburrida: quitar exposición pública, imponer 2FA, rotar credenciales y añadir una checklist de control de cambios para reglas de NAT.
Luego admitieron la causa raíz real: asumir que la configuración del cortafuegos coincidía con el diagrama de arquitectura.

Historia 2: La optimización que salió mal

Otra organización buscaba “menos fricción” para los operadores. Centralizaron el acceso poniendo la UI de Proxmox detrás de un proxy inverso interno,
luego abrieron el proxy a una red corporativa más amplia para que on-call pudiera acceder desde cualquier parte de la VPN de la empresa. También añadieron un flujo tipo SSO
por conveniencia. Funcionó. Hasta que no funcionó.

El proxy se convirtió en un único punto de falla y en un único punto de compromiso. Durante una actualización rutinaria del proxy, los ajustes TLS cambiaron y algunos clientes
empezaron a fallar. Los operadores, bajo presión, comenzaron a evitar el proxy exponiendo 8006 directamente de forma temporal “solo por esta noche”.
Ese estado temporal vivió lo suficiente como para aparecer en logs como un flujo constante de intentos de autenticación desde redes que nunca debían tocar la gestión.

Mientras tanto, el proxy ocultaba IPs de origen a menos que estuviera cuidadosamente configurado, lo que dificultó auditar inicios de sesión sospechosos. El equipo había efectivamente cambiado
un límite de seguridad claro por una capa de conveniencia que exigía su propia excelencia operativa. No contrataron personal para esa excelencia.

La solución eventual fue simplificar: acceso a la UI solo vía un segmento VPN administrativo dedicado; sin alcance corporativo amplio. Mantuvieron el proxy internamente para algunos
flujos, pero lo eliminaron como “característica de seguridad.” La lección fue clara: las capas de conveniencia son sistemas, y los sistemas necesitan responsables.

Historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo pequeño que operaba Proxmox para un producto SaaS tenía un hábito que parecía casi anticuado: una ventana de mantenimiento semanal con un runbook escrito.
Cada miércoles parchaban un nodo, migraban cargas, reiniciaban si era necesario y luego pasaban al siguiente nodo. Registraban lo que cambiaba y lo que observaban.
No era glamouroso. Era fiable.

Una semana aplicaron actualizaciones y notaron que pvecm status mostraba advertencias intermitentes de quórum durante las migraciones. Porque siempre comprobaban
la salud del clúster después de cada nodo, lo detectaron temprano. La causa fue un puerto de switch que hacía flap en la red del clúster—no relacionado con el parche, pero revelado por la rutina.

Pausaron el despliegue, arreglaron el problema físico y reanudaron. Sin impacto al cliente. El ingeniero on-call incluso durmió.
La victoria de seguridad no fue solo “parchearon”. Fue que su proceso hizo visibles las anomalías antes de que se convirtieran en incidentes.

Las prácticas aburridas no reciben aplausos presupuestarios, pero sí evitan reuniones presupuestarias con expresiones faciales incómodas.

Preguntas frecuentes

1) ¿Debo exponer alguna vez Proxmox puerto 8006 a Internet si uso 2FA?

No. 2FA reduce el riesgo de toma de cuentas; no reduce el riesgo de exposición del servicio. Mantén 8006 en una red administrativa o detrás de VPN/bastión.

2) ¿RBAC de Proxmox es suficiente, o aún necesito controles de usuarios de Linux?

Necesitas ambos. RBAC gobierna acciones en API/UI de Proxmox. Usuarios Linux/SSH gobiernan acceso al host. Trata el acceso shell del host como privilegio superior al acceso solo UI.

3) ¿Cuál es el mínimo viable de “acceso remoto seguro”?

Una VPN a una subred administrativa, con reglas de cortafuegos permitiendo 22 y 8006 solo desde esa subred, más 2FA para inicios de sesión UI y claves SSH para shell.

4) ¿Cómo manejo el acceso de emergencia cuando 2FA es obligatorio?

Crea una cuenta de emergencia dedicada con controles fuertes: credenciales almacenadas fuera de línea, lista de IPs permitidas, uso monitorizado y procedimiento documentado.
Úsala solo para recuperar acceso y luego rótala.

5) ¿Los tokens de API son más seguros que las contraseñas?

Usualmente sí, porque pueden delimitarse, rotarse y revocarse sin interrumpir una cuenta humana. Pero trata los tokens como secretos: protégelos, registra su uso
y expíralos.

6) ¿Necesito fail2ban en Proxmox?

Si tu plano de gestión está correctamente aislado, fail2ban es opcional. Si sospechas exposición, fail2ban puede reducir el ruido, pero no sustituye arreglar la exposición.

7) ¿Qué política de cortafuegos debo usar: DROP o REJECT?

Para interfaces de gestión, prefiere DROP para reducir señales. Para conveniencia interna en resolución de problemas, REJECT puede ser útil. Elige uno deliberadamente y documéntalo.

8) ¿Con qué frecuencia debo parchear los nodos Proxmox?

Semanal o quincenal es una cadencia sana para la mayoría de entornos, con capacidad de acelerar para avisos de seguridad urgentes. La clave es consistencia y staging.

9) Si aisle la gestión en una VLAN, ¿sigo necesitando el cortafuegos de Proxmox?

Sí. Las VLANs reducen exposición; los cortafuegos reducen el radio de impacto cuando fallan límites VLAN, hay mala configuración o un sistema interno está comprometido.

10) ¿Cuál es el mayor “riesgo silencioso” en la seguridad de Proxmox?

Permisos demasiado amplios que permanecen. La mayoría de organizaciones no son hackeadas por un genio; resultan dañadas por la conveniencia de ayer.

Próximos pasos que puedes ejecutar esta semana

1. Demuestra que la gestión no está expuesta: desde una red no administrativa, confirma que 8006 y 22 son inalcanzables. Si son alcanzables, corrige reglas de perímetro inmediatamente.
2. Activa 2FA para todos los humanos. Arregla NTP primero. Crea un flujo documentado de acceso de emergencia.
3. Sprint de limpieza RBAC: lista ACLs, elimina PVEAdmin de / excepto para un pequeño grupo admin, y acota todo lo demás.
4. Verifica la efectividad del cortafuegos: revisa configuración vía pvesh y la realidad vía nft list ruleset.
5. Parchea con staging: simula actualizaciones, actualiza un nodo, verifica quórum y flujos críticos, luego avanza.
6. Endurece SSH con cuidado: solo claves, sin login root, fuentes restringidas; conserva acceso a consola mientras haces cambios.
7. Escribe los dos runbooks que necesitarás: “dispositivo 2FA perdido” y “cuenta administrativa comprometida.” Los incidentes no esperan documentación.

El objetivo no es construir una fortaleza impenetrable. Es que el acceso de gestión a Proxmox sea intencionadamente escaso, los permisos intencionadamente estrechos
y los cambios intencionadamente rutinarios. El resto es solo Linux.