¿Es seguro un VPS? Riesgos y lo que controlas

¿Es seguro el alojamiento VPS? La respuesta breve

Sí. El alojamiento VPS es seguro para el trabajo para el que la mayoría lo contrata y supone una mejora real frente al alojamiento compartido. Un VPS KVM (servidor privado virtual) es una máquina virtual con su propio kernel, memoria, disco y cuentas de usuario. El hipervisor que la ejecuta mantiene a los demás clientes aislados de esos cuatro recursos. La persona que alquila el servidor contiguo al suyo en la misma máquina física no puede leer sus archivos, enumerar sus procesos, iniciar sesión en su servidor ni ver su tráfico de red. Los planes basados en contenedores ofrecen un aislamiento más débil, como se explica más adelante.

La respuesta completa tiene dos partes. El proveedor es responsable del hardware y del hipervisor. Usted es responsable de todo lo que hay dentro de su máquina virtual, y ahí empiezan casi todos los incidentes reales. Los servidores suelen sufrir intrusiones por un puerto abierto, una contraseña SSH débil, un paquete que nadie actualizó o un secreto incluido en un archivo que se publicó. Es muy poco frecuente que sufran intrusiones a través del hipervisor.

Qué separa realmente el hipervisor

Un hipervisor es el software que ejecuta máquinas virtuales en un mismo host físico. En un VPS KVM (KVM significa kernel based virtual machine y es el estándar en hosts Linux), su servidor es una máquina virtual completa. Arranca su propio kernel. El host le asigna una región fija de memoria física, y la unidad de gestión de memoria del procesador rechaza cualquier acceso fuera de esa región. Por tanto, el código que se ejecuta en otro guest no puede direccionar su memoria RAM. No hay un sistema de archivos compartido ni una tabla de usuarios compartida. Por eso, los permisos de archivos del servidor de otro cliente no tienen ningún efecto en el suyo.

El hosting compartido funciona de otra forma. Muchos sitios se ejecutan dentro de un mismo sistema operativo, con un mismo servidor web y una misma instalación de PHP, como cuentas de usuario normales. El único límite son los permisos de archivos. Por tanto, un error de permisos o un plugin vulnerable que se ejecute con un usuario que pueda leer demasiado puede acceder a los archivos de otra cuenta. Esa es la brecha que cierra pasar de un hosting compartido a un VPS.

Compruebe qué está contratando, porque no todos los planes vendidos como VPS son máquinas virtuales. Los planes basados en contenedores (OpenVZ, LXC, Virtuozzo) comparten el kernel del host y separan a los clientes mediante namespaces y cgroups, en lugar de usar virtualización de hardware. Es un límite más débil, porque un error del kernel en el host también afecta al kernel de su servidor. Además, esos planes no permiten cargar módulos del kernel, lo que impide usar algunos programas. KVM es la opción predeterminada más segura. Pregunte cuál recibirá antes de pagar.

Qué puede hacerle un vecino ruidoso

Compartir un host físico reduce la velocidad, y ese es el único coste. Los guests de una máquina comparten la CPU física y los discos. Cuando la CPU está ocupada con otro guest, su CPU virtual espera, y Linux registra esa espera como tiempo de steal: el campo %st de top y vmstat. Un tiempo de steal superior a unos pocos puntos porcentuales durante horas indica que el host está sobreasignado. No significa que alguien esté leyendo sus datos. La solución es contratar otro plan o cambiar de proveedor. Antes de decidir, puede medir la CPU y el disco que realmente obtuvo.

Hay un efecto entre clientes que conviene conocer, y no es una vulnerabilidad de seguridad. Si envía correo desde su VPS, su dirección IP pertenece a un rango que también utilizan otros clientes. Un vecino que envía spam puede hacer que parte de ese rango aparezca en una blocklist, por lo que sus mensajes llegan a las carpetas de spam por una razón que usted no causó. Los proveedores que controlan los abusos mantienen rangos más limpios. Pregunte por este aspecto si el correo es importante para usted.

Lo que un vecino hostil no puede hacer y el caso poco frecuente en que sí puede

Un cliente del mismo host no tiene ninguna vía de acceso a sus archivos. No puede ver sus procesos, montar su disco ni abrir un shell en su servidor, porque ninguna de esas cosas existe dentro de su máquina virtual. Hay una excepción que conviene mencionar: trate cualquier red privada del proveedor como una red compartida con desconocidos y cifre lo que la atraviese, en lugar de asumir que es invisible.

Los escapes del hipervisor son reales. Un error en la capa de virtualización puede permitir que el código de un guest alcance el host y, desde el host, acceda a todos los guests que se ejecutan en él. Estos errores se descubren, se publican con un identificador CVE (common vulnerabilities and exposures) y se corrigen con parches. Los proveedores de hosting los corrigen rápidamente porque todo su negocio depende de esa capa. Para aprovechar uno se necesita un exploit funcional para una versión específica del hipervisor. Es un recurso costoso para invertirlo contra una cuenta de hosting pequeña.

Los canales laterales entre guests también son reales. Pertenecen a la familia Spectre y Meltdown y aprovechan las cachés compartidas del procesador para inferir pequeñas cantidades de datos a través de una frontera. Las actualizaciones de microcode y del kernel reducen este riesgo, y las tasas de filtración descritas en los trabajos publicados son muy bajas. Los casos publicados son demostraciones de investigación, no ataques masivos. El riesgo no es cero. Simplemente está muy por debajo de los problemas que probablemente le causarán daños.

Dónde termina la responsabilidad del proveedor y dónde empieza la tuya

El proveedor es responsable del edificio, el hardware del host, el hipervisor y el kernel del host, la red física y el panel de control que permite iniciar, detener, reconstruir y crear snapshots de tu servidor. Si falla alguno de estos elementos, el proveedor debe solucionarlo.

Tú eres responsable de todo lo que está por encima del sistema operativo. Esto incluye los paquetes que instalas, los puertos que dejas abiertos, las cuentas y claves que pueden iniciar sesión, las actualizaciones que aplicas, tus copias de seguridad y tu propio código de aplicación. La mayoría de los planes VPS no son gestionados. Esto significa que nadie aplica parches a tu servidor por ti y que ningún ticket de soporte lo hará. La diferencia entre servicios gestionados y no gestionados merece una lectura antes de contratar, porque determina qué parte de esa lista queda bajo tu responsabilidad.

Hay una parte de tu responsabilidad que se olvida fácilmente: el propio panel de control del proveedor. Quien tenga esas credenciales puede reconstruir tu servidor o conectar su disco a un sistema de rescate sin conocer ninguna contraseña del interior del servidor. Activa la autenticación de dos factores (2FA) en la cuenta de hosting y no reutilices esa contraseña en ningún otro sitio.

¿Puede su proveedor de hosting ver sus datos?

Sí, en principio. Este es el límite real de lo que ofrece un VPS. La imagen de disco se encuentra en el almacenamiento del proveedor. Su consola proporciona acceso a nivel de pantalla a su máquina virtual. El modo de rescate puede arrancar otro sistema con el disco conectado. Un VPS le protege frente a otros clientes, pero el proveedor queda fuera de esa garantía.

Si almacena datos que el proveedor no debe poder leer, cifrelos en la aplicación antes de escribirlos. El cifrado de disco completo dentro del sistema invitado ayuda frente a una imagen copiada mientras está almacenada, pero la clave debe permanecer en la memoria mientras el servidor está en ejecución. Por tanto, el proveedor sigue formando parte del modelo de confianza. La misma confianza se aplica a un servidor dedicado que alquila para uso exclusivo, con una capa compartida menos.

Qué es lo que realmente vulnera un VPS

Un servicio que escucha en todas las interfaces. Las bases de datos, las cachés, las colas de mensajes y los paneles de administración suelen enlazarse a 0.0.0.0 de forma predeterminada. Esto significa que escuchan en todas las interfaces de red, incluida la pública. El escaneo automatizado de todo Internet en IPv4 es constante. Por eso, una dirección IPv4 nueva recibe su primera sonda no solicitada pocos minutos después de conectarse. El espacio de IPv6 es demasiado grande para recorrerlo dirección por dirección. Sin embargo, una dirección IPv6 puede descubrirse mediante registros DNS y otras filtraciones. No la trate como si estuviera oculta. Redis sin contraseña, un nodo de Elasticsearch sin autenticación, una API de Docker abierta en el puerto 2375 y un panel de administración que todavía usa sus credenciales predeterminadas se encuentran de esta forma. El escáner no necesita saber quién es usted. Enlace el servicio a 127.0.0.1 cuando sólo lo necesite la máquina local y bloquee el resto en el firewall.

Docker que evita el firewall. Publicar el puerto de un contenedor crea reglas de traducción de direcciones de red (NAT) que se evalúan antes que las reglas de ufw (uncomplicated firewall). Por eso, un contenedor puede ser accesible desde Internet aunque ufw status indique que ese puerto está denegado. Esto afecta incluso a quienes han configurado correctamente todo lo demás. El motivo por el que un puerto de Docker ignora ufw explica este comportamiento y conviene leerlo antes de publicar un puerto de contenedor.

SSH con las contraseñas habilitadas. Lea el registro de SSH en cualquier servidor con una dirección IPv4 pública (/var/log/auth.log en Ubuntu, /var/log/secure en Rocky Linux y otros sistemas de la familia RHEL, o journalctl -u ssh y journalctl -u sshd cuando no se conserva ningún archivo de registro). Encontrará líneas como Failed password for root from 203.0.113.10 port 54312 ssh2, miles de ellas, día y noche. Los bots prueban nombres de usuario y contraseñas habituales. El inicio de sesión con contraseña, junto con una cuenta root que acepta inicios de sesión, es todo lo que necesita un atacante. Si permite sólo claves y desactiva el inicio de sesión de root, ese tráfico se convierte en ruido que puede ignorar.

Una sola clave privada usada en todas partes. Copiar una clave en todos los portátiles y servidores significa que un solo portátil robado permite desbloquearlo todo. Además, las claves SSH no caducan. Por tanto, una clave entregada a un contratista hace dos años todavía funciona hoy. Una clave por persona y por máquina no cuesta nada y limita el alcance de una sola clave robada.

Paquetes que nadie actualiza. Un CVE publicado contra su servidor web o el framework de su aplicación es un conjunto público de instrucciones. Los escáneres empiezan a comprobarlo en cuestión de días. Las actualizaciones de seguridad son la defensa más económica disponible y pueden ejecutarse de forma automática. Consulte actualizaciones de seguridad automáticas en Ubuntu.

Un secreto filtrado. Las contraseñas de bases de datos y las claves de API se almacenan en archivos .env. Esos archivos pueden confirmarse en un repositorio público o servirse desde un servidor web configurado con el directorio incorrecto. Cualquier contenido que pegue en el contexto de un agente de programación con IA también puede acabar en un registro. Este es un tema independiente: cómo mantener los secretos fuera del alcance de un agente.

Todo se ejecuta como root. Cuando la aplicación se ejecuta como root, un solo error en ella le da el control de toda la máquina. Dentro del servidor ya no queda ningún límite que impida que el problema se propague.

Tu parte del trabajo

Nada de lo siguiente corresponde al trabajo del hipervisor. Todo queda de tu lado de la línea, y ese es el lado que determina si tu VPS es seguro.

• Haz bien la primera hora: los primeros diez minutos en un VPS nuevo cubren un usuario que no sea root y un firewall.
• Restringe el acceso remoto: refuerzo de la seguridad de SSH en un VPS.
• Cierra los puertos que no utilices: conceptos básicos del firewall ufw.
• Concede a cada servicio sólo el acceso que necesita: usuarios con privilegios mínimos en un VPS.
• Reduce la velocidad de los intentos de inicio de sesión por fuerza bruta: fail2ban en Ubuntu 24.04.
• Conserva una copia de seguridad que hayas restaurado al menos una vez: copias de seguridad de un VPS con restic.

La parte del proveedor ya está hecha cuando el servidor arranca. Tu parte requiere aproximadamente una hora el primer día y unos minutos al mes después de eso. Si todavía estás comparando opciones, qué es realmente un VPS explica los fundamentos de todo esto.

FAQ

¿Puede otro cliente del mismo servidor físico leer mis archivos?

No, si usa un VPS KVM. Su servidor es una máquina virtual con su propio kernel y su propio disco virtual, además de una región de memoria física que el host le asigna. El procesador bloquea cualquier acceso fuera de esa región. No hay un sistema de archivos compartido entre los invitados, por lo que los permisos de archivos del servidor vecino no tienen ningún efecto dentro del suyo. Los planes basados en contenedores, como OpenVZ y LXC, comparten el kernel del host y ofrecen un aislamiento más débil. Compruebe qué tipo de servicio está contratando.

¿Es un VPS más seguro que el alojamiento compartido?

Para el aislamiento, sí. En el alojamiento compartido, muchos sitios se ejecutan dentro de un mismo sistema operativo y el único límite son los permisos de archivos. Por eso, un error en otra cuenta puede exponer archivos en algunos casos. En un VPS, el límite es una máquina virtual. La diferencia es que el host aplica los parches del alojamiento compartido, mientras que en un VPS no administrado los aplica usted. Un VPS sólo es más seguro si realmente instala las actualizaciones y cierra los puertos.

¿Puede mi proveedor de alojamiento leer mis datos?

En principio, sí, y ningún producto VPS cambia esa situación. La imagen de disco se almacena en el hardware del proveedor, la consola permite acceder a la pantalla de la máquina en ejecución y el modo de rescate puede arrancar otro sistema con el disco conectado. Si algunos datos deben permanecer ilegibles para el host, cífrelos en la aplicación antes de escribirlos. El cifrado de disco dentro del invitado sigue dejando la clave en la memoria mientras el servidor está en ejecución, por lo que no elimina al proveedor del modelo de confianza.

¿Cuál es la forma más habitual de que un VPS sea comprometido?

Un servicio expuesto o un acceso SSH débil, con mucha diferencia. Los escáneres automatizados sondean continuamente todas las direcciones IPv4 públicas. Por eso, una base de datos vinculada a 0.0.0.0 sin contraseña, o un panel de administración que conserve sus credenciales predeterminadas, se detecta en minutos y no en meses. El registro SSH de cualquier servidor con una dirección IPv4 pública (/var/log/auth.log en Ubuntu, /var/log/secure en Rocky Linux) muestra la parte relacionada con SSH: líneas Failed password for root repetidas procedentes de direcciones de todo el mundo. Las vulnerabilidades de escape del hipervisor existen, pero requieren capacidades de investigación avanzadas y se dirigen a objetivos de alto valor. No son la causa de los incidentes habituales.