Seguridad Proxmox: los 5 errores de acceso que convierten tu laboratorio en una brecha

Algunos datos (y algo de historia) que explican por qué falla el acceso

Los errores de seguridad alrededor del control de acceso en Proxmox no son aleatorios. Son un conjunto repetible de hábitos—muchos heredados de eras de infraestructura anteriores, mentalidad de “solo para el laboratorio” o de equipos que aprendieron administración Linux antes de que modelar amenazas fuera algo que la gente hiciera antes de la llamada de incidente.

• Dato 1: La UI web de Proxmox VE (pveproxy) históricamente venía por defecto accesible en TCP/8006 desde dondequiera que el host fuera alcanzable. Eso es conveniente en un laboratorio y temerario en una red enrutada.
• Dato 2: El modelo de permisos de PVE no es un detalle menor: es RBAC con roles, usuarios, grupos y ACLs. Muchas brechas empiezan por ignorarlo y ejecutar todo como root@pam.
• Dato 3: El concepto de “plano de gestión” se volvió corriente porque a los atacantes les encantan los planos de control. Controlar el hipervisor vence a comprometer invitados: una credencial puede convertirse en muchas VMs.
• Dato 4: La autenticación en dos factores empezó como una función de consumo y pasó a operaciones cuando la reutilización de contraseñas y el phishing dejaron de ser “raros”. Los portales de administración sin 2FA ahora son una anomalía—para los atacantes, una agradable.
• Dato 5: La proliferación de claves SSH es una versión moderna de dejar llaves de repuesto bajo el felpudo. Las claves tienden a sobrevivir a empleados, laptops y a las VMs para las que se crearon.
• Dato 6: Las VLANs se popularizaron para reducir dominios de broadcast y segmentar redes; no son, por sí solas, un límite de seguridad si rutas entre ellas están abiertas con firewall permisivo.
• Dato 7: Los sistemas en clúster cambian el radio de daño. Un nodo comprometido a menudo es un peldaño hacia una disrupción en todo el clúster, especialmente cuando la confianza entre nodos no está restringida.
• Dato 8: “Las copias de seguridad son seguridad” es medio cierto. Las copias son también una vía de acceso de alto valor: si un atacante puede borrarlas o cifrarlas, tu plan de recuperación se vuelve arte interpretativo.

Una cita para mantener prioridades claras. Esta es una idea parafraseada de Gene Kim (autor DevOps/operaciones): Mejorar la fiabilidad es principalmente mejorar el sistema, no individuos heroicos.
Aplica eso al control de acceso: deja de confiar en “admins cuidadosos” y construye bordes de protección.

Error #1: Exponer la UI y la API de Proxmox como si fuera un blog personal

Si TCP/8006 es accesible desde redes que no controlas completamente, estás jugando a la ruleta. Sí, Proxmox usa TLS. No, eso no es lo mismo que “seguro en Internet.” La UI es un plano de control de administración.
El atacante no necesita explotar algún bug exótico del hipervisor. Solo necesita que te autentiques una vez en el lugar equivocado, reutilices una contraseña o dejes una cuenta habilitada.

La mayor idea equivocada: “Es solo mi laboratorio.” Los laboratorios se convierten en producción como los niños en adolescentes: miras hacia otro lado cinco minutos y de pronto tienen opiniones y presupuesto.

Qué significa realmente “expuesto”

Expuesto no es solo “IP pública.” Es “alcanzable desde cualquier lugar al que no le entregarías con confianza un cable de consola físico.”
Eso incluye: Wi‑Fi corporativo plano, la subred VPN “temporal” compartida con contratistas, tu VLAN de juegos porque tenías prisa, o un reverse proxy que termina TLS y reenvía /api2 porque pareció interesante.

Qué hacer en su lugar

• Poner la gestión de PVE en una red de gestión dedicada (interfaz separada o VLAN) con reglas de ingreso estrictas.
• Permitir UI/API solo desde un jump host de admins o una subred VPN en la que confíes realmente.
• Si debes usar un reverse proxy, trátalo como un componente crítico de seguridad (autenticación, MFA, endurecimiento, registro). Si no, no lo hagas.

Broma #1: Poner la UI de Proxmox en Internet abierto es como dejar la llave de tu casa bajo el felpudo. Funciona genial hasta que otra persona leyó el mismo blog de seguridad doméstica.

Error #2: Usar root como conductor diario

Root no es una identidad. Root es una capacidad. Cuando inicias sesión en la UI como root@pam para operaciones rutinarias, estás combinando “administración” y “superusuario en todas partes” en un único dominio de fallo.
Así es como pequeños accidentes se convierten en grandes, y cómo el phishing se convierte en control de infraestructura.

Modos de fallo

• Phishing/reutilización de credenciales: una cuenta equivale a todo.
• Ambigüedad en auditoría: “root lo hizo” no es una pista de auditoría; es un encogimiento de hombros en forma de logs.
• Error operativo: pensabas reiniciar una VM; borraste una configuración de almacenamiento. Root lo hizo rápido.

Haz esto: usuarios admin + límites de privilegio

Crea cuentas de administrador con nombre, usa roles RBAC y reserva root para casos de emergencia. Si necesitas acciones a nivel root, otórgalas deliberadamente—preferiblemente a un rol, no a la cuenta personal de larga duración de alguien.

Si piensas “pero solo soy yo,” estás poniendo a prueba el futuro. El tú del futuro cuenta como una persona distinta. El tú pasado ciertamente también.

Error #3: Usar “una cuenta admin” en lugar de RBAC y separación

Los permisos de Proxmox son potentes y algo infrautilizados. El anti‑patrón común es gestionar una organización pequeña (o laboratorio) como un equipo de un solo usuario: un administrador, credenciales compartidas y acceso que se filtra entre nodos, pools y almacenamiento.

Qué separar (separación mínima viable)

• Admins humanos vs automatización (tokens API para máquinas, MFA para humanos).
• Gestión de clúster vs gestión de VMs (no todos deben añadir almacenamiento o modificar redes).
• Operadores de backup vs operadores de VM (los derechos de restauración son poderosos; los derechos de borrado son peligrosos).
• Workloads de inquilinos incluso en homelabs—especialmente si ejecutas servicios “para amigos y familia”.

Qué te ofrece RBAC

El principio de menor privilegio no es paranoia. Es minimizar el radio de daño de fallos normales:
un portátil comprometido, un token subido a un repo, una cuenta de contratista dejada habilitada o un becario aprendiendo qué significa “Datacenter” en la UI.

Error #4: Tokens, claves y secretos sin ciclo de vida

A los laboratorios les encantan los secretos estáticos. A los entornos corporativos también, pero fingen que no. El patrón de brechas es consistente: se crea un token para un script, el script funciona, el token se olvida y más tarde se convierte en la puerta de entrada más limpia.

Ofensores típicos

• Tokens API con permisos amplios y sin proceso de caducidad.
• Claves SSH copiadas a múltiples laptops de admins, todas autorizadas en todas partes.
• Credenciales de backup que también pueden eliminar copias.
• Autenticación básica en reverse proxy almacenada en config management en texto plano sin rotación.

Mejor: pensar en el ciclo de vida

Cada credencial debe tener un propietario, un alcance, un método de almacenamiento y una historia de rotación. Si no puedes responder esas cuatro preguntas, no es una credencial. Es un incidente futuro.

Broma #2: Los tokens caducados son como la leche caducada: desagradable, pero al menos lo notas. Los tokens que nunca caducan son como la leche que parece bien hasta que deja de serlo.

Error #5: Confundir “tiene firewall” con “está segmentado”

Un host Proxmox puede tener reglas de firewall y aun así estar abierto en la práctica. ¿Por qué? Porque la segmentación es una decisión de arquitectura, no una casilla marcada.
Si tu interfaz de gestión, tráfico de VM, tráfico de almacenamiento y tráfico de clúster comparten el mismo espacio L2/L3, has construido un entorno donde el compromiso se propaga de forma natural.

Cómo debería verse la segmentación

• Red de gestión: UI/API/SSH. Solo dispositivos admin o jump hosts pueden alcanzarla.
• Red de clúster: tráfico corosync. Membresía estricta. Preferir VLAN aislada o NICs dedicadas.
• Red de almacenamiento: NFS/iSCSI/Ceph. Solo endpoints de almacenamiento y hosts, no VMs al azar.
• Redes de VM: múltiples VLANs/bridges basadas en zonas de confianza.

Por qué importa para el control de acceso

A los atacantes les gusta el movimiento lateral más que el acceso inicial. Si una VM comprometida puede hablar con el plano de gestión del host, no es “compromiso de una VM.” Es el paso uno.
Mantén el radio de daño lo suficientemente pequeño como para que tu respuesta a incidentes tenga la posibilidad de ser aburrida.

Guía de diagnóstico rápido: qué comprobar primero, segundo, tercero

Cuando algo se siente “raro” en la seguridad de acceso—solicitudes de inicio de sesión inesperadas, comportamiento extraño de la UI, nodos que se inician o detienen, backups que fallan—no te apresures. Ejecuta una triage rápida con un orden estable de operaciones.
Esta guía optimiza para atrapar rápidamente las fallas comunes de alto impacto.

Primero: confirma exposición y puntos de entrada

• ¿Es TCP/8006 alcanzable desde sitios que no debería?
• ¿SSH es alcanzable en la interfaz de gestión desde subredes no confiables?
• ¿Hay reverse proxies o reenvíos de puertos en el camino?

Segundo: valida controles de identidad

• ¿Los admins usan cuentas con nombre o root?
• ¿Se aplica 2FA para admins humanos?
• ¿Existen tokens para automatización y están con scope?

Tercero: inspecciona logs por pruebas, no por sensaciones

• Intentos de login recientes y fallos (UI y SSH).
• Cambios de permisos, usuarios nuevos, tokens nuevos.
• Cambios en el firewall, cambios en interfaces de red.

Cuarto: comprueba segmentación y límites de confianza

• ¿Pueden las VMs alcanzar IPs de gestión?
• ¿Pueden VLANs no administradoras alcanzar corosync o redes de almacenamiento?
• ¿Son accesibles los endpoints de backup desde redes de tenants?

Si encuentras un problema serio (UI expuesta, SSH root abierto, sin 2FA), detente y arréglalo antes de continuar. “Solo voy a terminar de comprobar todo” es como las brechas consiguen capítulos extras.

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

1) Síntoma: Pico de intentos de login en logs, UI se siente lenta

Causa raíz: Web UI expuesta a una red amplia; stuffing automático de credenciales o escaneo.

Solución: Restringir TCP/8006 con firewall de host y ACLs aguas arriba. Mover la gestión a una subred dedicada. Añadir 2FA y limitación de tasa vía un camino de acceso administrativo adecuado (VPN/jump host).

2) Síntoma: “root@pam” se usa para todo, sin rendición de cuentas

Causa raíz: Cultura de conveniencia, sin diseño RBAC, sin política de break‑glass.

Solución: Crear usuarios admin con nombre, aplicar 2FA, deshabilitar SSH con contraseña para root y reservar root solo para consola/emergencias.

3) Síntoma: Scripts de automatización funcionan… hasta que se filtra un token

Causa raíz: Tokens API de larga vida almacenados en texto plano, permisos demasiado amplios.

Solución: Crear tokens API con scope por carga de trabajo, almacenarlos en un gestor de secretos (o al menos en archivos legibles por root), rotarlos regularmente y eliminar privilegios como Sys.Modify a menos que sean necesarios.

4) Síntoma: Un compromiso de VM se convierte en compromiso del host

Causa raíz: Red plana; las VMs pueden alcanzar el plano de gestión o endpoints de almacenamiento; políticas de firewall permisivas.

Solución: Segregar redes, bloquear VM→gestión por defecto y permitir explícitamente solo los flujos este‑oeste requeridos.

5) Síntoma: Las copias de seguridad desaparecen o quedan inutilizables tras un incidente

Causa raíz: Credenciales de backup permiten eliminación, almacenamiento de backups alcanzable desde todas partes, sin inmutabilidad/retención forzada.

Solución: Separar rol de operador de backups, restringir alcance de red, aplicar retención y prevenir borrados por defecto.

6) Síntoma: Inestabilidad del clúster tras cambios de “endurecimiento”

Causa raíz: Reglas de firewall aplicadas sin entender tráfico corosync/clúster; bloqueo de puertos requeridos o rutas multicast/unicast.

Solución: Aplicar cambios incrementalmente, validar comunicaciones del clúster primero, mantener una vía de acceso fuera de banda y probar en un nodo antes del despliegue general.

Tareas prácticas: comandos, salida esperada y decisiones

Estas son tareas prácticas que puedes ejecutar en un nodo Proxmox (o en tu jump host) para responder a una pregunta cada una: “¿Es esto seguro?” y “¿Qué hago después?”
Los comandos asumen un host Proxmox VE basado en Debian. Ajusta nombres de interfaces y subredes para que coincidan con tu entorno.

Tarea 1: Confirma qué está escuchando en el host (y dónde)

cr0x@server:~$ sudo ss -lntp
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=1234,fd=6))
LISTEN 0      128    0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=987,fd=3))
LISTEN 0      4096   127.0.0.1:85       0.0.0.0:*     users:(("pvedaemon",pid=1100,fd=10))

Qué significa la salida: pveproxy está ligado a 0.0.0.0:8006, así que es alcanzable en todas las interfaces que enrutan al host.

Decisión: Si el host tiene alguna interfaz que no sea de gestión, restringe el acceso usando reglas de firewall o enlaza los servicios de gestión a una IP de gestión vía diseño de red (preferido: alcance solo gestión).

Tarea 2: Valida el estado del firewall del host en Proxmox

cr0x@server:~$ sudo pve-firewall status
Status: enabled/running

Qué significa la salida: El marco de firewall de PVE está activo.

Decisión: “Habilitado” no es “configurado.” Continúa: verifica políticas y reglas. Si está deshabilitado, actívalo y asegúrate de tener acceso fuera de banda antes de endurecer reglas.

Tarea 3: Inspecciona las reglas efectivas del firewall (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 ip saddr 10.10.10.0/24 accept
    tcp dport 8006 ip saddr 10.10.10.0/24 accept
    counter drop
  }
}

Qué significa la salida: Drop por defecto con permisiones explícitas para SSH y 8006 solo desde 10.10.10.0/24. Esta es la forma que deseas.

Decisión: Si ves policy accept o permisos amplios (como ip saddr 0.0.0.0/0), ajústalos. Si faltan reglas, implémentalas en el host y en el firewall aguas arriba.

Tarea 4: Prueba de alcanzabilidad desde una red no admin (validación externa)

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

Qué significa la salida: Desde el punto de prueba, el servicio no es alcanzable (refused o timeout son aceptables según la política).

Decisión: Si conecta, tienes un problema de exposición. Arregla ACLs/redantes/firewalls antes de “simplemente añadir 2FA.” Defensa en profundidad, no en sensaciones.

Tarea 5: Verifica qué usuarios existen en Proxmox y sus realms

cr0x@server:~$ sudo pveum user list
Userid             Enable Expire Firstname Lastname Email Comment
root@pam           1             -        -        -     -
alice@pve          1             Alice    Admin    -     human admin
ci-bot@pve         1             -        -        -     automation

Qué significa la salida: Usuarios existen en distintos realms (PAM, PVE). Esto te dice si aún vives la vida de solo root@pam.

Decisión: Si root es la única identidad admin habilitada, crea admins con nombre y restringe el uso de root. Si la automatización usa una cuenta humana, muévela a un token.

Tarea 6: Listar tokens API (buscar puertas olvidadas)

cr0x@server:~$ sudo pveum user token list ci-bot@pve
Tokenid     Privsep  Expire Comment
deploy      1        0      used by pipeline
oldscript   0        0      legacy

Qué significa la salida: Existen tokens; Expire 0 típicamente significa “sin expiración establecida.” Privsep 1 es mejor que 0 porque separa permisos del token respecto al usuario.

Decisión: Elimina tokens “legacy”. Rota los activos. Asegura que la separación de privilegios esté habilitada y que las ACLs se apliquen por alcance del token.

Tarea 7: Auditar ACLs (quién puede hacer qué, dónde)

cr0x@server:~$ sudo pveum acl list
Path            Userid         Roleid
/               alice@pve      Administrator
/vms/100        ci-bot@pve     PVEVMAdmin

Qué significa la salida: alice@pve tiene admin a nivel datacenter (grande). ci-bot@pve está limitado a la ruta de una VM (buen patrón).

Decisión: Quita roles amplios de la automatización. Haz el scope explícito (por VM, pool o path de recurso). Considera dividir admin de datacenter en roles separados para almacenamiento/red/clúster.

Tarea 8: Comprobar configuración SSH para login root

cr0x@server:~$ sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication'
permitrootlogin prohibit-password
passwordauthentication no
pubkeyauthentication yes

Qué significa la salida: Root puede iniciar sesión solo mediante claves; las contraseñas están deshabilitadas (buena línea base). Idealmente, el login root es no a menos que requieras break‑glass vía consola.

Decisión: Si passwordauthentication yes o permitrootlogin yes, arréglalo ahora. Si mantienes login por clave para root, limita las claves y gestionalas.

Tarea 9: Encontrar qué claves están autorizadas para root (chequeo de proliferación de claves)

cr0x@server:~$ sudo wc -l /root/.ssh/authorized_keys
12 /root/.ssh/authorized_keys

Qué significa la salida: Doce claves. No es automáticamente incorrecto, pero rara vez es correcto en un entorno pequeño.

Decisión: Elimina claves obsoletas, aplica cuentas con nombre y deja de dar acceso “root a todo el mundo.” Considera un jump host con accesos de corta duración.

Tarea 10: Inspeccionar eventos de autenticación recientes (SSH y PAM)

cr0x@server:~$ sudo journalctl -u ssh -S "24 hours ago" | tail -n 20
Feb 04 08:11:32 pve1 sshd[22101]: Failed publickey for root from 203.0.113.50 port 51234 ssh2: RSA SHA256:...
Feb 04 08:11:37 pve1 sshd[22104]: Failed password for invalid user admin from 203.0.113.50 port 51261 ssh2
Feb 04 08:14:02 pve1 sshd[22210]: Accepted publickey for alice from 10.10.10.25 port 49152 ssh2: ED25519 SHA256:...

Qué significa la salida: Ves intentos de escaneo desde una IP pública y un login exitoso desde la subred de gestión.

Decisión: Si ves escaneos públicos repetidos, verifica rutas de exposición. Si logins exitosos ocurren desde subredes inesperadas, trátalo como posible incidente y ajusta el ingreso inmediatamente.

Tarea 11: Inspeccionar logs de tareas de Proxmox para acciones administrativas

cr0x@server:~$ sudo tail -n 25 /var/log/pve/tasks/index
UPID:pve1:0002A1B3:0F3A2B1C:65C0F5E2:vzstart:100:alice@pve:
UPID:pve1:0002A1D8:0F3A2C90:65C0F61A:aclmod:/:root@pam:
UPID:pve1:0002A1F2:0F3A2D10:65C0F640:useradd::root@pam:

Qué significa la salida: Cambios administrativos fueron realizados por root@pam. Eso es una señal de alerta para la rendición de cuentas y a menudo indica comportamiento de “sesión de consola compartida”.

Decisión: Migra operaciones rutinarias a cuentas con nombre. Mantén una regla estricta: los cambios root requieren ticket/notas, incluso en un laboratorio.

Tarea 12: Validar configuración de red corosync y membresía

cr0x@server:~$ sudo pvecm status
Cluster information
-------------------
Name:             labcluster
Config Version:   5
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Feb 04 09:02:11 2026
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Qué significa la salida: El clúster está sano y usa autenticación segura. Esta es tu línea base antes de tocar el firewall alrededor del tráfico de clúster.

Decisión: Si el quórum es inestable o faltan nodos, no procedas con cambios de firewall agresivos. Arregla la red del clúster primero o “asegurarás” el clúster hasta dejarlo en downtime.

Tarea 13: Comprobar qué interfaces llevan tráfico de gestión y VM

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.10/24
vmbr0            UP             192.168.50.10/24
vmbr1            UP             172.16.20.10/24

Qué significa la salida: Tienes redes distintas. Si eno1 (gestión) está separada de los bridges de VM, vas por buen camino.

Decisión: Si gestión y VMs comparten el mismo bridge, rediseña. Si no puedes rediseñar hoy, bloquea los subnets de VM de alcanzar 8006/22 como medida de emergencia.

Tarea 14: Verificar que las VMs no puedan alcanzar el plano de gestión del host (prueba rápida desde el host)

cr0x@server:~$ sudo tcpdump -ni eno1 tcp port 8006 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
0 packets captured

Qué significa la salida: No se observó tráfico a 8006 en la NIC de gestión durante la ventana de captura. No es prueba definitiva, pero es una señal útil.

Decisión: Si ves IPs del subnet VM golpeando 8006, tienes una falla de segmentación. Implementa bloqueo en el firewall del host y en el límite L3.

Tarea 15: Identificar si las copias de seguridad son alcanzables desde redes no confiables

cr0x@server:~$ sudo ss -lntp | egrep '(:8007|:9022|:22|:2049)'
LISTEN 0      4096   0.0.0.0:8007   0.0.0.0:* users:(("proxmox-backup-proxy",pid=1444,fd=10))
LISTEN 0      128    0.0.0.0:9022   0.0.0.0:* users:(("proxmox-backup-api",pid=1401,fd=9))

Qué significa la salida: Los servicios de Proxmox Backup Server escuchan en todas las interfaces.

Decisión: Restringe estos puertos a subredes de clientes/admin de backup únicamente. Las copias de seguridad son parte de tu perímetro de seguridad, no una misión secundaria.

Tarea 16: Comprobar sincronización horaria (dependencia silenciosa de la seguridad de acceso)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-04 09:10:22 UTC
           Universal time: Tue 2026-02-04 09:10:22 UTC
                 RTC time: Tue 2026-02-04 09:10:22
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa la salida: El reloj está sincronizado. Esto importa para correlación de logs, validez de tokens y líneas temporales de incidentes.

Decisión: Si la hora está desviada o NTP inactivo, arréglalo antes de intentar interpretar “¿cuándo sucedió ese login?” entre nodos.

Tres micro-historias corporativas del departamento “esto pasó”

Micro-historia 1 (suposición equivocada): “La UI no es pública, está detrás de NAT”

Una empresa mediana ejecutaba un clúster Proxmox para servicios internos. El equipo era competente, estaba ocupado y le gustaba la frase “está detrás de NAT.” La interfaz de gestión vivía en una subred de servidores que era “solo interna.”
Luego la empresa se expandió. Se activó una VPN site‑to‑site y se añadió una red de partner para simplificar un proyecto conjunto. El enrutamiento se hizo más fácil. La seguridad, más difusa.

Nadie actualizó el modelo de amenazas porque nadie tenía uno por escrito. Proxmox TCP/8006 se volvió alcanzable desde una subred del partner. No intencionalmente. Solo como efecto colateral de “hagamos que la red funcione.”
Una semana después, sus logs mostraron un goteo de intentos fallidos de login desde una IP en el rango del partner. No parecía Internet, así que no disparó alarmas.

El acceso inicial no fue mágico. Un administrador había usado una contraseña compartida (sí, todavía) por “conveniencia temporal.” Esa contraseña apareció en un volcado de credenciales ligado a un servicio completamente distinto.
Una vez que el atacante tuvo acceso a la UI, no necesitó exploits de kernel. Creó un usuario privilegiado nuevo, montó un ISO y usó una VM invitada como punto de escalada.

El postmortem no trató de bugs de Proxmox. Trató de la suposición equivocada de que “rutas internas equivalen a rutas de confianza.” La solución fue aburrida y decisiva:
la gestión se movió a una subred dedicada, UI/API solo desde el jump host, 2FA obligatorio y las credenciales compartidas pasaron a ser una falta grave para scripts y una oportunidad de formación para humanos.

Micro-historia 2 (optimización que salió mal): “Pongamos la UI detrás de un reverse proxy”

Otra organización quería “una única vista.” Ya tenían un stack de reverse proxy para apps, con certificados automatizados y dashboards bonitos.
Alguien propuso poner Proxmox detrás también. URLs limpias, TLS centralizado, patrones de acceso consistentes. A todos les encanta la consistencia, hasta que es consistentemente errónea.

El proxy era alcanzable desde más sitios que la red de gestión original, porque servía aplicaciones internas generales. El control de acceso vivía en la capa de proxy, que mantenía otro equipo diferente del de virtualización.
El equipo de virtualización asumió que el equipo del proxy manejaba la auth. El equipo del proxy asumió que Proxmox manejaba la auth. Ambos tenían parte de la razón. Ninguno tenía la responsabilidad completa.

El problema real: un cambio de configuración introdujo una omisión de autenticación para un patrón de ruta específico. No fue malicioso; fue un ajuste de “permitir health checks” que se copió y pegó.
De repente, la API de Proxmox tenía exposición parcial no autenticada a redes internas. No suficiente para dominar el clúster al instante, pero sí suficiente para enumerar. La enumeración es cómo los ataques dirigidos dejan de ser ruidosos.

Lo detectaron porque un ingeniero de seguridad hizo un escaneo rutinario y preguntó, educada y repetidamente, por qué la API del hipervisor respondía diferente a lo esperado.
La solución fue retirar Proxmox del proxy general, mantener acceso de gestión en un modelo VPN+jump host y exigir que cualquier futuro proxy del plano de gestión pase por una revisión de seguridad con listas de rutas explícitas.

La optimización no es gratuita. Centralizar reduce trabajo repetitivo e incrementa el radio de daño. Hazlo solo cuando puedas garantizar propiedad, revisión y registro con la misma calidad que el sistema que estás frontalizando.

Micro-historia 3 (práctica aburrida pero correcta): “La política de jump host que a nadie le gustaba”

Una empresa grande gestionaba múltiples clústeres Proxmox para cargas de trabajo edge. La política era irritantemente estricta: sin acceso directo a la UI salvo desde un jump host endurecido; MFA requerido; sin SSH desde laptops; tokens con scope por servicio; revisiones de logs semanales.
Los ingenieros se quejaban. Algunos intentaron rodearla. Seguridad dijo no. Francamente, no era popular.

Entonces un workstation de desarrollador fue comprometida vía un exploit de navegador. El atacante consiguió acceso a redes internas, cosechó un montón de claves SSH e intentó pivotar hacia infraestructura.
En la mayoría de los casos, ahí es donde la historia se vuelve cara.

Pero las claves no funcionaron contra hosts Proxmox porque SSH solo era alcanzable desde la subred del jump host. La UI tampoco era alcanzable.
El atacante entonces trató de acceder al jump host, se topó con MFA y se estancó. Pasó a objetivos más fáciles: servicios de desarrollo, entornos de prueba, sistemas de bajo valor.

El incidente aún dolió—los endpoints comprometidos siempre duelen—pero no se convirtió en “hipervisores tomados.” Esa política aburrida mantuvo las joyas de la corona detrás de una puerta que el atacante no pudo abrir en silencio.
La reunión post‑incidente fue del tipo raro donde el equipo se fue con menos trabajo, porque los controles “molestos” resultaron ser el seguro más barato.

Listas de verificación / plan paso a paso

Paso a paso: asegurar accesos sin dejarte fuera

1. Confirma tu vía de escape: asegúrate de tener consola física/IPMI/iDRAC o un camino KVM‑over‑IP. Si no lo tienes, no procedas con cambios agresivos de firewall.
2. Inventario de puntos de entrada: lista puertos en escucha (ss -lntp) y mapea a interfaces (ip -br addr).
3. Define la subred de gestión: elige una red admin (ejemplo: 10.10.10.0/24) y documéntala.
4. Restringe UI/API: permitir TCP/8006 solo desde la subred admin/jump host. Bloquear todo lo demás.
5. Restringe SSH: permitir TCP/22 solo desde la subred admin. Deshabilitar auth por contraseña. Deshabilitar login root donde sea posible.
6. Deja de usar identidades compartidas: crea cuentas admin con nombre. Mueve humanos a login con MFA.
7. Implementa RBAC: crea roles para operaciones de VM, operaciones de almacenamiento y auditoría/revisión de logs. Evita admin a nivel datacenter salvo que sea necesario.
8. Corrige la automatización: usa tokens API por pipeline/servicio, con scope mínimo. Almacena tokens de forma segura y rótaos.
9. Segmenta redes: gestión, VM, almacenamiento, clúster. Si no puedes, usa reglas de firewall para forzar aislamiento lógico.
10. Protege backups: restringe puertos de backup, separa credenciales, evita borrados por defecto y prueba procedimientos de restauración.
11. Activa y revisa logs: comprueba logs SSH, tareas de Proxmox y logs de firewall. Hazlo semanalmente.
12. Haz una pasada de validación: prueba alcanzabilidad desde una red no admin y confirma que falle para 8006/22.

Lista de control de acceso (imprimible en tu mente)

• UI/API accesible solo desde jump host o subred VPN confiable.
• Sin SSH por contraseña. Sin SSH root directo (o controlado como break‑glass).
• Usuarios admin con nombre y MFA; sin credenciales compartidas.
• Automatización usa tokens API con separación de privilegios y ACLs con scope.
• Las redes de VM no pueden alcanzar interfaces de gestión.
• Backups con acceso separado, credenciales separadas y eliminación protegida.
• Logs revisados regularmente; intentos de auth sospechosos son accionables, no decorativos.

Preguntas frecuentes

1) ¿Está bien exponer alguna vez Proxmox TCP/8006 a Internet si uso contraseñas fuertes?

No. Las contraseñas fuertes reducen un riesgo. No reducen el escaneo, phishing, robo de tokens por navegador, bugs de UI o reutilización de credenciales con el tiempo.
Pon la UI detrás de una VPN o jump host y restringe el ingreso a nivel de red.

2) ¿Puedo simplemente cambiar el puerto de 8006 a otro?

Cambiar el puerto reduce ruido, no riesgo. Los atacantes escanean rangos y hacen fingerprinting de servicios. Si confías en la oscuridad del puerto, te sentirás seguro hasta que no lo estés.
Haz restricción de acceso adecuada en su lugar.

3) ¿Debería deshabilitar root por completo?

En Linux, root existe. La pregunta es cómo se usa. Trata a root como break‑glass: acceso por consola, emergencias, cambios controlados.
Para operaciones diarias, usa cuentas con nombre y RBAC.

4) ¿Cuál es la configuración mínima de RBAC que realmente ayuda?

Crea al menos: un rol de admin para cambios a nivel de clúster, un rol de operador de VM para acciones diarias sobre VMs y un rol de operador de backups.
Luego scopea roles a paths de recursos (por pool o rango de VMs) en lugar de dar derechos a nivel datacenter por defecto.

5) ¿La segmentación por VLAN es suficiente para bloquear una VM comprometida de alcanzar la gestión?

Solo si el enrutamiento entre VLANs está estrictamente controlado. En muchos laboratorios, el enrutamiento inter‑VLAN está abierto “porque es cómodo.”
Usa reglas de firewall en límites L3 y, cuando sea posible, mantén la gestión en una red a la que las VMs no puedan enrutar en absoluto.

6) ¿Los tokens API son más seguros que almacenar usuario y contraseña para automatización?

Sí, cuando se usan correctamente. Los tokens pueden tener scope y rotarse y separarse de privilegios de usuario.
Pero un token con permisos amplios y sin ciclo de vida es solo una contraseña con mejor marca.

7) ¿Cómo sé si alguien está haciendo brute‑force contra mi Proxmox o SSH?

Busca intentos de auth fallidos repetidos en journalctl -u ssh y en logs de autenticación/tareas de Proxmox.
También vigila uso inusual de CPU en pveproxy y rangos de IP origen inusuales. Luego arregla la exposición; no solo bloquees una IP.

8) ¿Y usar un reverse proxy con SSO delante de Proxmox?

Se puede hacer, pero es fácil hacerlo peligrosamente. Añades una dependencia crítica: si el proxy enruta mal o omite auth para una ruta, tu plano de control queda expuesto.
Mantén el plano de gestión en un camino de acceso dedicado salvo que puedas garantizar endurecimiento, propiedad y auditoría de la pila de proxy.

9) Si activo 2FA, ¿puedo relajar las restricciones de red?

No. 2FA es una capa, no un reemplazo de los límites de red. Restringe la alcanzabilidad primero, luego añade 2FA para humanos y scopea tokens para automatización.
Las capas son cómo sobrevives a la falla de una sola capa.

10) ¿Cómo encajan las copias de seguridad en el control de acceso?

Las copias de seguridad son un plano de control para la recuperación. Si los atacantes pueden acceder o borrarlas, pueden negociar usando tus propios datos.
Coloca servicios de backup en redes restringidas, minimiza derechos de borrado y prueba restauraciones bajo la suposición de que las credenciales de producción están comprometidas.

Próximos pasos que puedes hacer esta semana

Si tu entorno Proxmox es un laboratorio hoy, trátalo como si fuera a importar mañana. Porque importará.
Aquí tienes un orden práctico que te ofrece reducción rápida de riesgo sin un rediseño de un mes.

1. Mata la exposición: restringe TCP/8006 y TCP/22 a tu subred admin/jump host únicamente.
2. Deja de usar root para trabajo rutinario: crea cuentas admin con nombre y migra hábitos.
3. Activa MFA para humanos: no lo debates hasta el próximo trimestre.
4. Arregla identidad de automatización: reemplaza credenciales humanas compartidas por tokens con scope.
5. Segmenta o bloquea: asegura que las VMs no puedan alcanzar el plano de gestión; hazlo por diseño de red o firewalling (mejor ambos).
6. Protege backups: restringe endpoints de backup, separa permisos y verifica que puedas restaurar.
7. Agenda revisión de logs: 15 minutos semanales detectan más de lo que querrías admitir.

El objetivo no es seguridad perfecta. El objetivo es hacer que el compromiso sea caro, ruidoso y contenible. Si tu laboratorio puede sobrevivir a tus propios errores, tiene una oportunidad contra la intención de otra persona.