El endurecimiento de Proxmox comienza con un estado operativo preciso: ¿qué accesos de gestión existen, qué redes son críticas, qué dependencias de rutas de almacenamiento existen? Este capítulo ofrece una guía práctica ampliada para administradores, ingenieros de sistemas, operadores y proveedores de servicios TI con comprobaciones concretas, pasos de implementación, errores típicos y estrategias de recuperación probadas.
Endurecimiento de Proxmox: Precisar el modelo de amenazas: quién, cómo y qué proteger
Un modelo de amenazas realista es la base de todo endurecimiento. Pregúntese al menos: ¿Quién necesita acceso GUI/API? ¿Qué cuentas de automatización usan API‑Tokens? ¿Están los hosts de gestión accesibles vía VPN o directamente? Documente también vectores de ataque como API‑Tokens robados, jump‑hosts comprometidos o movimiento lateral desde una red de VM.
Términos explicados brevemente: API (Application Programming Interface) es la interfaz programática; Corosync es el protocolo de comunicación de clúster de Proxmox; Ceph es un backend de almacenamiento distribuido. Si conoce estos conceptos, entenderá por qué una GUI cerrada sirve de poco si los puertos del clúster permanecen abiertos.
Segmentación, Break‑Glass und Change‑Management
Separar claramente Management-, Storage‑ und VM‑Netze
Separe Management (GUI/API/SSH), Storage (NFS/iSCSI/Ceph) y tráfico de VM en VLANs/Subnetze distintas. Esto evita que VMs comprometidas alcancen directamente el clúster o el almacenamiento. Errores frecuentes son bridges compartidas o etiquetas VLAN faltantes en los puentes del hipervisor, lo que expone las IPs de gestión.
Break‑Glass und getestete Rückfallwege
Defina al menos dos vías de recuperación: consola local/IPMI y un jump‑host probado con Always‑Allow‑IP en el firewall. Antes de activar Default‑DROP, documente los pasos para abrir temporalmente: pve‑firewall deaktivieren, ajustar la regla del firewall, redirigir el puerto SSH. Practique estos pasos una vez en vivo.
pve‑firewall: Architektur, Regeln und sichere Aktivierung
La pve‑firewall es un componente central para el endurecimiento de Proxmox. Opera en varios niveles – Datacenter, nodo y VM/CT – y finalmente genera reglas nftables/iptables en los hosts. Planifique las reglas en bloques funcionales: Cluster/Corosync, Storage, Management, Monitoring.
Corosync & Cluster‑Kommunikation
Corosync utiliza en instalaciones estándar puertos UDP para tráfico de quórum y heartbeat (p. ej. 5404/5405). Si estas conexiones son bloqueadas por el firewall, los nodos salen del quórum y los servicios se vuelven inestables. Cree reglas que permitan Corosync entre subredes del clúster y pruebe latencia/pérdida de paquetes con ping/iperf.
# Prüfen, ob Corosync läuft und UDP-Ports offen sind
systemctl status corosync
ss -uanp | grep -E '5404|5405'
# Testweise UDP-Pakete senden (nur in Lab/mit Absprache)
echo test | nc -u -w1 node2.example.org 5405Storage‑Zugriffe sauber erlauben
Los protocolos de almacenamiento usan puertos típicos: NFS (2049), iSCSI (3260) y Ceph (Mon 6789, OSD 6800–7300). Abra únicamente los puertos que su diseño de almacenamiento realmente utiliza. Los clústeres Ceph suelen requerir conectividad bidireccional entre OSDs y monitores; una configuración de firewall incompleta provoca errores de reequilibrio y latencias elevadas.
Praktische Reihenfolge zur Aktivierung
- Identificar: puertos, interfaces, nombres DNS.
- Regeln hinzufügen: Cluster & Storage erlauben.
- Restringir la gestión de forma gradual: GUI/API/SSH solo desde orígenes administrativos.
- Activar logging y limitación de tasa.
- Establecer la política por defecto en DROP; supervisar el monitoreo.
Diagnóstico de firewall y fallos típicos
Síntomas frecuentes tras una configuración incorrecta del firewall: separación del clúster, mensajes de quórum poco claros, migraciones interrumpidas o tiempos de espera del almacenamiento. La resolución de problemas comienza con comprobaciones de servicios y de red.
# Service- und Netzwerkstatus prüfen
systemctl is-active pveproxy pvedaemon pvestatd corosync
journalctl -u pve-firewall -n 200 --no-pager
ss -tulpen | sed -n '1,200p'
# Temporäre Deaktivierung für Test (Node-lokal)
systemctl stop pve-firewall || trueModifique las reglas siempre de forma controlada: utilice los registros de auditoría, anote las marcas temporales y el autor. Así se puede rastrear la causa más rápidamente.
Seguridad de la API y la interfaz web: TLS, Tokens, MFA
La API de Proxmox (pveproxy) permite la automatización y es funcionalmente equivalente a la GUI; por tanto requiere las mismas medidas de protección: transmisión cifrada, autenticación robusta y RESTricciones de red.
Controles TLS y monitorización
Compruebe los certificados regularmente: expiración, SAN/nombres DNS, confianza de la CA en los clientes de administración. Evite soluciones como „insecure_skip_verify“ en las comprobaciones de monitorización; si la monitorización no puede validar, la solución es una mejor gestión de certificados.
# Zertifikat schnell prüfen
openssl s_client -connect pve.example.org:8006 -servername pve.example.org </dev/null | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256Tokens de API y mínimo privilegio
Utilice tokens de API con permisos limitados para la automatización en lugar de contraseñas personales. Separe las cuentas administrativas interactivas de las cuentas de servicio. Los tokens deben rotarse y documentarse en la gestión de cambios.
# Beispiel: pvesh nutzt die API ohne separate Tokens zur schnellen Abfrage
echo 'Nodes:'
pvesh get /nodesMFA y WebAuthn
Implante autenticación de dos factores (por ejemplo, TOTP o WebAuthn/U2F) cuando sea posible. La MFA protege las sesiones interactivas frente a contraseñas robadas; no sustituye, sin embargo, las RESTricciones de red ni la gestión de tokens.
Endurecimiento de SSH y despliegues seguros
SSH es el punto de acceso clave. El endurecimiento reduce ataques de fuerza bruta, mejora la auditabilidad y minimiza el riesgo derivado de una cuenta root comprometida.
Implementación gradual
- Inventario: ¿Qué cuentas usan SSH? ¿Dónde están los authorized_keys?
- Obligatorio: al menos una cuenta de clave funcional por nodo y una consola abierta durante las pruebas.
- Cambiar la configuración: PasswordAuthentication no, PermitRootLogin no, LogLevel VERBOSE.
- Despliegue escalonado: nodo por nodo, monitorización tras cada cambio.
# /etc/ssh/sshd_config (empfohlen, Auszug)
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
LogLevel VERBOSE
AllowGroups proxmox-adminsMantenga siempre una vía de retroceso: la consola local/IPMI puede deshacer cambios; de lo contrario existe el riesgo de bloqueo administrativo.
Fail2ban, RESTricciones IP y escenarios NAT
Fail2ban ayuda contra intentos repetidos de acceso, pero debe usarse con precaución en entornos con NAT o proxies cuando varios administradores comparten la misma IP. Configure conjuntos de IP en la lista blanca para jump hosts y puntos de supervisión automatizados.
# Fail2ban-Status prüfen
systemctl status fail2ban
fail2ban-client status sshd
# Beispiel: Whitelist in /etc/fail2ban/jail.d/proxmox.conf
# ignoreip = 10.0.0.5 192.168.100.0/24Comprobaciones de auditoría, detección de deriva y control automatizado
El hardening no es una acción puntual. Las auditorías automatizadas detectan la deriva de configuración de forma temprana y alivian la carga de Operations.
Comprobaciones esenciales (mensuales)
- Estado de parches: pveversion -v y revisión del kernel.
- Puertos abiertos y sockets en escucha: ss -tulpen.
- Estado del firewall y política por defecto: pve-firewall status y nft list ruleset.
- Política SSH: sshd -T.
- Consistencia temporal: timedatectl y registros NTP/SNTP.
- Pruebas de copia de seguridad y RESTauración: RESTauración completa en prueba aislada.
# Basis-Checks als Skript (Auszug)
pveversion -v; uname -a
ss -tulpen
pve-firewall status
sshd -T | egrep 'passwordauthentication|permitrootlogin' || true
timedatectl statusDetección de drift y registro de cambios
Utilice la replicación de /etc/pve (sistema de archivos pmxcfs) y registre los cambios. Un diff sencillo antes/después del mantenimiento evita sorpresas. Reenvíe los registros de journald a SIEM/syslog central, para que los eventos de auditoría no se pierdan.
Observaciones específicas de VMware (migración y operación)
Muchas entornos Proxmox se encuentran en el contexto de migraciones desde VMware. Durante el hardening surgen cuestiones específicas: conversión de discos, mapeo de redes y timeouts de almacenamiento. Tenga en cuenta estos puntos al cerrar las redes de gestión.
Problemas típicos relacionados con VMware
- Formato de disco: tras qm importdisk o la conversión con qemu-img, compruebe que los UUID de los discos de la VM y los adaptadores SCSI estén mapeados correctamente.
- Red: traduzca los conceptos de vSwitch/DVSwitch a bridges/VLANs — una asignación incorrecta de bridges puede exponer rutas de gestión.
- Almacenamiento: los timeouts de iSCSI/NFS son comunes en migraciones; abra los puertos de almacenamiento necesarios y, si procede, aumente temporalmente los timeouts durante la migración.
Consejo de resolución de problemas: si después de la migración faltan redes, compruebe ‚qm config‘ y compare las entradas de bridge con el inventario de bridges del host (ip -br a).
Runbook: Hardening paso a paso con plan de pruebas
Un despliegue seguro incluye pruebas, puntos de observación y pasos de reversión claros:
- Documentar el estado actual (puertos, servicios, topología de almacenamiento).
- Prueba en laboratorio: simular las reglas en un clúster de pruebas.
- Stage: aplicar las reglas nodo por nodo, activar el monitoreo.
- Producción: activar Default‑DROP tras 48–72h de funcionamiento exitoso.
- Revisión: informe de auditoría y lecciones aprendidas.
Monitorización, registro y alertas
Recoja los registros del sistema de forma centralizada, configure alertas para pérdidas de Corosync, timeouts de almacenamiento, detenciones de pve-firewall y intentos de acceso SSH fallidos repetidos. Las alertas deben ser claras: p. ej., Corosync Quorum Lost — iniciar el runbook.
Conclusión
El hardening de Proxmox es un proceso continuo con una priorización clara: segmentación, aseguramiento de la comunicación de clúster y almacenamiento, RESTricción gradual de API/GUI/SSH y controles de auditoría establecidos. Planifique cada paso con pruebas, monitorización y un plan de reversión documentado. Especialmente en migraciones desde VMware y en entornos de almacenamiento distribuido queda patente que reglas de firewall incompletas y cambios en SSH sin comprobar provocan fallos más rápido de lo esperado. Con el orden y los pasos de comprobación descritos aquí reducirá el riesgo sin sacrificar la seguridad operativa.
Preguntas frecuentes
¿Debería estar accesible la GUI de Proxmox (puerto 8006) desde Internet?
No. La Web‑GUI/API ofrecen amplias capacidades de administración. Es preferible que la accesibilidad sea exclusivamente desde una red de gestión aislada, vía VPN o mediante un jump‑host. Si el acceso externo es imprescindible, debe realizarse a través de capas de protección previas (VPN, autenticación fuerte, redes de origen RESTrictivas, monitorización).
¿Qué ocurre al activar la pve‑firewall sin preparación?
A menudo falla el tráfico de clúster o de almacenamiento porque faltan reglas necesarias. Las consecuencias son avisos de quórum, migraciones colgadas o timeouts de almacenamiento. Por ello: primero permitir explícitamente el clúster y el almacenamiento, después RESTringir la gestión y solo al final establecer Default‑DROP.
¿Basta Fail2ban como protección para los accesos a Proxmox?
Fail2ban es una capa adicional útil contra intentos fallidos repetidos, pero no sustituye la segmentación de red, las reglas de firewall ni la autenticación fuerte. En entornos NAT/Proxy Fail2ban puede incluso ser problemático si muchos usuarios comparten la misma IP.
¿Cómo reforzar SSH sin quedarme fuera?
Antes de desactivar los inicios de sesión por contraseña, asegúrese de que al menos una cuenta de administrador tenga autenticación por clave. Utilice sshd -t para la comprobación antes del reinicio y mantenga una segunda sesión abierta. Pruebe los cambios primero en un nodo y despliegue de forma escalonada.
¿Qué comprobaciones de auditoría son las más importantes en el día a día?
Las revisiones periódicas del estado de parches, de los puertos abiertos, del estado del firewall y de la política SSH (sin inicio de sesión por contraseña, sin inicio de sesión root) son fundamentales. Complementariamente: consistencia NTP, pruebas de RESTauración de backups y registros de cambios trazables (diffs en /etc/pve).
Operación, integraciones y riesgos: perspectivas ampliadas
Además del endurecimiento del firewall, de la API y de SSH, conviene revisar los procesos operativos y las integraciones, ya que en ellos a menudo se esconden riesgos inadvertidos. Tres áreas son especialmente críticas: gestión de secretos, ciclo de vida de certificados/firmware y cambios automatizados desde pipelines CI/CD.
Secrets & Token‑Management
Los API‑Tokens y las claves de servicio son herramientas potentes — pero también objetivos atractivos para un atacante. Evite los Long‑Lived‑Tokens en configuraciones en texto claro. Integre su automatización de Proxmox en un Secrets‑Vault central (p. ej. HashiCorp Vault o una PKI interna de la empresa) y aplique rotación de tokens y separación de roles.
# Beispiel: Liste der API-Tokens (nur als Admin lokal ausführen)
pvesh get /access/tokens
# Nutzen Sie das Ergebnis zur Abgleichsliste gegen Ihre Vault-EinträgePor qué: los tokens pueden exponerse a través de backups, logs de CI o playbooks mal configurados. Riesgo: un token comprometido permite acciones automatizadas sobre VMs sin inicio de sesión interactivo.
PKI, Zertifikate und Rolling‑Renewal
Una gestión centralizada de certificados reduce el riesgo de fallos por certificados TLS que expiren. Planifique las renovaciones escalonadas (rolling‑renewals) de forma que no todos los nodos carguen certificados nuevos al mismo tiempo — de lo contrario existe el riesgo de pérdida de comunicación en el clúster. Automatice comprobaciones y alertas para las fechas de caducidad, no se limite a muestreos manuales.
# Zertifikatsprüfung über mehrere Hosts (Auszug)
for host in pve1 pve2 pve3; do
echo "Checking $host"
openssl s_client -connect ${host}:8006 -servername ${host} /dev/null | openssl x509 -noout -enddate
doneFirmware, Out‑of‑Band und IPMI/Redfish‑Härtung
Los controladores de gestión (IPMI/Redfish) son superficies de ataque independientes. Segmente las redes OOB, implemente StrongAuth y mantenga las actualizaciones de firmware de forma automatizada. Documente las credenciales Break‑Glass separadas del inventario habitual y pruebe la recuperación OOB al menos cada seis meses.
Automatización, CI/CD y control de cambios
Si los Playbooks aplican cambios directamente sobre Proxmox, las pruebas y los despliegues canary deben formar parte del proceso. Realice comprobaciones sintéticas (p. ej., arranque/parada de VM, montaje de almacenamiento) en Staging e instrumente los rollbacks: los Playbooks deberían poder revertir los cambios de forma idempotente.
SLOs, monitorización y escalación
Defina SLOs medibles para la salud del clúster (disponibilidad de quórum), la latencia del almacenamiento y los tiempos de respuesta de la API. Las alarmas sin pasos claros en el runbook generan ruido; combine las alertas con diagnósticos automatizados (recolección de logs, pveproxy health, corosync status) y una ruta de escalación clara.
Estas operacionalizaciones cierran la brecha entre el endurecimiento técnico y la operación fiable: quien gestiona secretos, automatiza certificados y controla cambios reduce notablemente el riesgo residual.
Para este tema también es importante asegurar Proxmox Firewall y Proxmox API. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.