¿Es seguro un VPS? Qué controla realmente

¿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 (servidor privado virtual) es una máquina virtual con su propio kernel, su propia memoria, su propio disco y sus propias 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.

La respuesta honesta tiene dos partes. El proveedor es propietario del hardware y del hipervisor. Usted es responsable de todo lo que hay dentro de su máquina virtual, y ahí es donde empiezan casi todos los incidentes reales. Los servidores sufren intrusiones por un puerto abierto, una contraseña débil de SSH, 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é puede comprometer realmente 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 vincularse a 0.0.0.0 de forma predeterminada. Esto significa que escuchan en todas las interfaces de red, incluida la pública. El escaneo de Internet es constante y automatizado. Por eso, una dirección IP nueva recibe su primera sonda no solicitada pocos minutos después de conectarse. 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 detectan de esta forma. El escáner no necesita saber quién es usted. Vincule un 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 escribe 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. Revise /var/log/auth.log en cualquier servidor público y 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 acceso mediante contraseña, junto con una cuenta root que acepta inicios de sesión, es suficiente para un atacante. Si permite sólo claves y deshabilita 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 misma clave en todos los portátiles y servidores significa que un solo portátil robado permite acceder a 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 su framework de aplicaciones es un conjunto público de instrucciones. Los escáneres empiezan a buscar esa vulnerabilidad en cuestión de días. Las actualizaciones de seguridad son la defensa más económica disponible y pueden ejecutarse automáticamente: consulte las 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 terminar en un repositorio público o ser servidos por un servidor web configurado con el directorio incorrecto. Cualquier dato que pegue en el contexto de un agente de programación con IA también puede acabar en un registro. Ese es otro tema: 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 permite controlar toda la máquina. Ya no queda ningún límite dentro del servidor 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, en un VPS KVM. Su servidor es una máquina virtual con su propio kernel y su propio disco virtual. También tiene una región de memoria física que el host le asigna, y el procesador bloquea cualquier acceso fuera de esa región. No hay un sistema de archivos compartido entre los huéspedes, por lo que los permisos de archivos del servidor de un vecino no tienen ningún efecto dentro del suyo. Los planes basados en contenedores, como OpenVZ y LXC, comparten el kernel del host y proporcionan un aislamiento más débil. Compruebe qué tipo de VPS está contratando.

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

Para el aislamiento, sí. En el hosting 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 proveedor aplica los parches del hosting compartido, mientras que en un VPS no gestionado debe aplicarlos usted. Un VPS sólo es más seguro si instala realmente las actualizaciones y cierra los puertos.

¿Puede mi proveedor de hosting leer mis datos?

En principio, sí. Ningún producto VPS cambia esta situación. La imagen de disco se almacena en el hardware del proveedor. La consola proporciona acceso a la pantalla de la máquina en ejecución, y el modo de rescate puede arrancar otro sistema con su 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 huésped todavía mantiene la clave en memoria mientras el servidor está en ejecución. Por tanto, no elimina al proveedor del modelo de confianza.

¿Cuál es la forma más habitual en que se compromete un VPS?

Un servicio expuesto o un inicio de sesión SSH débil, con mucha diferencia. Los escáneres automatizados comprueban continuamente todas las direcciones IP públicas. Por eso, una base de datos vinculada a 0.0.0.0 sin contraseña, o un panel de administración que conserva sus credenciales predeterminadas, se detecta en minutos y no en meses. /var/log/auth.log en cualquier servidor público muestra la parte relacionada con SSH: líneas Failed password for root repetidas desde direcciones de todo el mundo. Los escapes del hipervisor existen, pero son trabajos de nivel de investigación dirigidos a objetivos de alto valor. No son la causa de las intrusiones habituales.