Un momento, ¿no hay que desactivar root? La confusa realidad de endurecer un servidor Proxmox

Para cualquiera que esté montando su primer servidor Proxmox, el instinto es sencillo: cerrarlo todo. Desactivar los inicios de sesión de root, restringir SSH, añadir firewalls y tratar la máquina como cualquier otro equipo Linux expuesto a internet.

Pero en cuanto empiezas a investigar la seguridad de Proxmox, aparece algo raro. Las guías se contradicen entre sí, y algunos consejos parecen el endurecimiento estándar de Linux mientras que otras recomendaciones parecen llevarle la contraria por completo.

Esa confusión desató una conversación animada entre usuarios de homelab que intentaban averiguar la forma más segura de proteger una instalación de Proxmox. Un usuario planteó el problema sin rodeos: quería una guía detallada para endurecer un servidor Proxmox, pero enseguida se dio cuenta de que se comporta de forma distinta a una instalación Linux típica.

El debate que siguió dejó claro que endurecer Proxmox exige algo más que buenas prácticas de seguridad. También tienes que entender cómo funciona la plataforma por dentro, y ahí es donde las opiniones empezaron a dividirse.

La primera regla que sugiere mucha gente: cerrar SSH

Cuando la gente empieza a endurecer servidores, SSH es casi siempre lo primero que mira. Un comentarista fue directo a lo básico: activar la autenticación de dos factores y pasar el acceso SSH a autenticación solo con claves, eliminando por completo los inicios de sesión con contraseña. Para muchos administradores, ese es el mínimo imprescindible de seguridad.

La lógica es sencilla. Los inicios de sesión con contraseña son fáciles de atacar por fuerza bruta, mientras que las claves SSH son bastante más difíciles de atacar, sobre todo si van acompañadas de unas reglas de firewall adecuadas.

Otro usuario hizo la pregunta obvia a continuación: ¿restringir el acceso SSH, sobre todo para el usuario root, rompe algo dentro de Proxmox? Ahí es donde las cosas dejaron de estar tan claras.

Algunos administradores aseguraban que llevan años ejecutando servidores Proxmox con acceso SSH solo por clave sin ningún problema. Según su experiencia, a Proxmox le da igual cómo inicies sesión mientras SSH funcione. Otros no estaban tan seguros, y la discusión se convirtió enseguida en una madriguera técnica.

El debate sobre el login de root que siempre vuelve

En las guías tradicionales de endurecimiento de Linux, desactivar el login de root es uno de los primeros pasos recomendados. Proxmox complica ese consejo.

Varias personas en la conversación señalaron que el acceso root tiene un papel central en cómo se comunican los nodos de Proxmox, sobre todo en los clústeres. Algunos creían que desactivar el acceso root podía romper la comunicación interna entre nodos. Un comentarista dijo sin rodeos que el login de root es necesario para la comunicación del clúster, y otro respondió que la comunicación interna del clúster en realidad usa claves SSH y no contraseñas.

Entonces, ¿quién tiene razón? La respuesta está en algún punto intermedio. Muchos usuarios explicaron que el login de root en sí tiene que seguir activado, pero que a menudo se puede desactivar la autenticación por contraseña para root. La cuenta sigue existiendo y puede conectarse, solo que con claves SSH.

Esa distinción confundió a varios participantes del hilo. Una persona admitió que una vez desactivó el login de root con contraseña en un clúster de pruebas y todo empezó a romperse después de un reinicio, hasta que lo volvió a activar. Otro usuario respondió que lleva años ejecutando clústeres sin login de root por contraseña sin problemas. La misma plataforma les dio experiencias distintas, y así es la gestión de infraestructura en pocas palabras.

Por qué Proxmox no siempre sigue los consejos estándar de Linux

A primera vista, Proxmox parece un sistema más basado en Debian. Por debajo, está mucho más integrado que un servidor normal. Los clústeres, la gestión de VMs y la comunicación entre nodos dependen mucho de servicios internos que dan por hecho ciertos comportamientos del sistema, y por eso algunos pasos estándar de endurecimiento pueden volverse en tu contra.

Desactivar root por completo, por ejemplo, suena a una idea estupenda desde el punto de vista de la seguridad. Pero las herramientas y los scripts de Proxmox a menudo dan por hecho que root existe y puede hacer acciones administrativas directamente.

Un comentarista lo resumió de forma sencilla: la contraseña de root es necesaria durante la creación del clúster, pero después muchas operaciones dependen de claves SSH para la comunicación entre nodos. El sistema espera que root exista aunque las personas casi nunca inicien sesión con esa cuenta, y eso crea un equilibrio delicado entre seguridad y compatibilidad.

El cifrado y la pregunta de "¿hasta qué punto deberías ser paranoico?"

Con el tiempo, la conversación fue más allá de SSH hacia otro tema de seguridad, el cifrado de disco. Un usuario preguntó si merece la pena cifrar los discos adicionales de un host de Proxmox además de la partición raíz.

La respuesta reflejó una filosofía habitual entre los administradores de infraestructura: si el cifrado es necesario depende del modelo de amenazas. Si que alguien robe la máquina física es un riesgo realista, el cifrado de disco completo en todas las unidades tiene sentido. Si el servidor vive en un entorno seguro, como un rack cerrado con llave en casa, algunos administradores se lo saltan por completo.

El razonamiento es práctico. El cifrado puede complicar el arranque, la gestión remota y los procedimientos de recuperación, y esa complejidad añadida no siempre compensa salvo que el riesgo sea real. En muchos homelabs, los ataques por red suelen ser una amenaza mayor que el robo físico. La seguridad siempre implica concesiones.

Los tres bandos de la seguridad en Proxmox

Al final de la discusión habían surgido con claridad tres puntos de vista.

Los minimalistas se centran en lo esencial: activar la autenticación de dos factores, limitar SSH a claves y apoyarse en el firewall de Proxmox. Para homelabs pequeños, eso suele bastar.

Los partidarios del endurecimiento tradicional tratan el sistema como cualquier otro servidor Linux. Aplican reglas SSH estrictas, limitan los servicios y desactivan todo lo que no sea necesario, aunque eso suponga retocar el comportamiento de Proxmox.

Y luego están los puristas de la plataforma, que sostienen que Proxmox debería configurarse sobre todo como lo pensaron sus desarrolladores. En lugar de un endurecimiento agresivo, se apoyan en los mecanismos integrados y en la segmentación de red para proteger el entorno.

Cada enfoque tiene sus partidarios, y cada uno puede funcionar, según el montaje.

Por qué los usuarios nuevos de Proxmox se siguen confundiendo

Parte del problema es que Proxmox está en una categoría poco habitual. Es toda una plataforma de virtualización montada sobre Linux, así que chocan dos conjuntos de suposiciones. Los administradores de Linux llegan esperando las prácticas de endurecimiento de siempre, mientras que la arquitectura interna de Proxmox espera que ciertos valores por defecto sigan intactos.

El resultado es mucha incertidumbre, sobre todo para quienes montan su primer nodo de homelab. Un usuario recogió esa confusión cuando dijo que solo buscaba una guía y en su lugar encontró "muchas peculiaridades que difieren de endurecer un servidor Linux estándar". Sinceramente, ese es probablemente el resumen más preciso de la situación.

La lección escondida en la discusión

Las conversaciones sobre seguridad suelen centrarse en ajustes concretos: activa esta opción, desactiva aquel servicio, cambia este archivo de configuración. La lección más importante de esta discusión es más sencilla. Antes de endurecer cualquier sistema, tienes que entender cómo funciona de verdad.

Con Proxmox, eso significa reconocer que algunos consejos tradicionales de Linux no se trasladan a la perfección. Las cuentas root se comportan de otra forma, la comunicación del clúster depende de mecanismos SSH internos y ciertos cambios de seguridad pueden romper sin querer la automatización dentro de la plataforma.

Nada de eso es motivo para ignorar la seguridad. Endurecer Proxmox solo requiere una mentalidad algo distinta, una que equilibre la prudencia con la compatibilidad, porque a veces la configuración más segura es la que mantiene el sistema funcionando exactamente como se diseñó, aunque no sea la más blindada.