El tiempo promedio entre el compromiso inicial y el movimiento lateral es ahora de 34 minutos, frente a los 48 minutos de hace un año, según investigaciones de IBM. El ataque más rápido observado comenzó a moverse lateralmente en cuatro minutos. Si tu estrategia de hardening de VPS sigue dependiendo de firewalls perimetrales y de asumir que tus vecinos en la infraestructura compartida son inofensivos, esa cronología debería hacerte repensar las cosas rápidamente.

La nube de tenencia compartida no es inherentemente insegura, pero sí implica que una instancia comprometida en el mismo host físico, la misma VLAN o el mismo nodo de Kubernetes que el tuyo puede convertirse en un punto de apoyo para un atacante. Los controles que importan no son exóticos: son la aplicación disciplinada de aislamiento a nivel de Linux, políticas de red y límites de privilegios que la mayoría de los equipos conocen pero rara vez aplican de forma consistente.

Este artículo es una lista de verificación con criterio propio, ordenada desde los controles con mayor retorno de esfuerzo hasta los que requieren una inversión más sostenida. Asume un VPS con Linux, acceso root o sudo, y una carga de trabajo que realmente te importa proteger.

Empieza por la superficie de ataque que expones desde el primer día

En cuanto un proveedor cloud asigna una dirección IPv4 pública, los escáneres automatizados la encuentran. Shodan, Censys y botnets especializadas recorren continuamente todo el espacio IPv4. Tu instancia queda indexada antes de que termines de configurarla.

SSH es el principal vector de administración remota en la mayoría de los VPS con Linux y también el punto de entrada más abusado. Los cambios de configuración base no son opcionales:

  • Establece PasswordAuthentication no en /etc/ssh/sshd_config. La autenticación exclusiva por clave elimina el relleno de credenciales como vía de entrada.
  • Establece PermitRootLogin no. Root nunca debería ser la primera cuenta que un atacante pueda apuntar a través de la red.
  • Usa AllowUsers o AllowGroups para definir exactamente quién puede autenticarse. Denegación por defecto para cualquier otra cuenta.
  • Deshabilita los algoritmos de intercambio de claves y cifrados débiles. Prefiere curve25519-sha256 para KEX y chacha20-poly1305 o aes256-gcm para el cifrado.
  • Enruta el acceso interactivo a través de un bastión o jump host en lugar de exponer sshd directamente en una interfaz pública. La limitación de intentos con fail2ban o sshguard es un complemento, no un sustituto.

La autenticación de dos factores mediante el módulo PAM de Google Authenticator añade una fricción significativa para cualquier atacante que consiga una clave privada, especialmente en entornos donde las claves se comparten entre un equipo.

Reglas de firewall en VPS Linux: denegación por defecto, no permisividad por defecto

La mayoría de las instancias VPS mantienen la política de firewall predeterminada de la distribución, que suele ser permisiva. El punto de partida correcto es el opuesto: bloquear todo el tráfico entrante y saliente, y abrir únicamente lo que tu carga de trabajo necesita de forma explícita.

Con nftables (el estándar actual en kernels modernos), un conjunto de reglas base debe establecer una política de descarte por defecto en las cadenas de entrada y reenvío, permitir conexiones establecidas y relacionadas, permitir el loopback y abrir únicamente los puertos específicos y los CIDRs de origen que tu aplicación requiere. La cadena de reenvío importa incluso en un VPS independiente si ejecutas contenedores: Docker y runtimes similares manipulan las reglas de iptables/nftables, y una interfaz bridge mal configurada puede saltarse por completo tu política a nivel de host.

El filtrado de tráfico saliente está subestimado en la prevención del movimiento lateral. Un atacante que tiene ejecución de código en tu instancia necesita alcanzar su infraestructura de comando y control o pivotar hacia servicios adyacentes. Restringir el egreso a destinos conocidos (tu base de datos, tu endpoint de almacenamiento de objetos, tu colector de monitoreo) limita lo que puede hacer con ese punto de apoyo. Registra todo lo que llegue a la regla de descarte por defecto; esos registros son tu indicador más temprano de reconocimiento.

El firewall no está ahí para detener el primer paquete. Está ahí para garantizar que un proceso comprometido no pueda convertirse en un punto de pivote para los diez siguientes.

Hardening del kernel: los parámetros sysctl que realmente importan

Varios parámetros del kernel reducen la explotabilidad de vulnerabilidades que ya están presentes en tu sistema. No son teóricos: CVE-2024-1086, un use-after-free en el subsistema netfilter de Linux, fue confirmado por CISA como activamente explotado en campañas de ransomware a finales de 2025 y fue utilizado por grupos como RansomHub y Akira. ASLR y los controles relacionados elevan el coste de explotar vulnerabilidades como esta.

  • ASLR: kernel.randomize_va_space = 2. Aleatorización completa de los segmentos de pila, heap y MMAP.
  • Filtrado de ruta inversa: net.ipv4.conf.all.rp_filter = 1. Descarta paquetes cuya dirección de origen no es alcanzable a través de la interfaz por la que llegaron, bloqueando una clase de ataques de spoofing.
  • Redirecciones ICMP: Deshabilita su aceptación y envío. Las redirecciones son una característica legítima del protocolo de enrutamiento que los atacantes abusan para redirigir el tráfico.
  • Enrutamiento de origen: net.ipv4.conf.all.accept_source_route = 0. Los paquetes con enrutamiento de origen nunca deberían llegar a un VPS en producción.
  • SYN cookies: net.ipv4.tcp_syncookies = 1. Mitiga el agotamiento por SYN flood sin descartar conexiones legítimas.

Persiste estos valores en /etc/sysctl.d/ para que sobrevivan a los reinicios. Aplícalos con sysctl --system tras escribir el archivo. Ninguno de estos cambios afecta el comportamiento normal de las aplicaciones.

Segmentación de red en VPS y aislamiento de inquilinos en cloud compartido

El hardening a nivel de host es necesario pero no suficiente en un entorno compartido. La topología de red alrededor de tu instancia determina hasta dónde puede moverse un atacante si logra entrar, y hasta dónde puede llegar un vecino comprometido hacia ti.

La red privada entre tus instancias VPS debe usar VLANs dedicadas o redes overlay en lugar de la interfaz pública. El tráfico entre tu capa de aplicación y tu base de datos nunca debería cruzar la internet pública y, idealmente, no debería ser enrutable desde ninguna instancia fuera del grupo de seguridad de esa aplicación. Cuando tu proveedor admita grupos de seguridad o ACLs de red a nivel de hipervisor, úsalos además de las reglas a nivel de host: la defensa en profundidad implica que los controles no compartan un modo de fallo.

Operamos AMS1 en Ámsterdam con un peering denso en los grandes puntos neutros europeos, lo que lo convierte en un ancla práctica para cargas de trabajo que necesitan conectividad privada de baja latencia en el Benelux, el Reino Unido y los mercados de Europa Occidental. Los clientes que ejecutan aplicaciones multicapa allí usan nuestra red privada para mantener el tráfico de bases de datos y caché completamente fuera de la interfaz pública, lo que elimina toda una clase de rutas de movimiento lateral a nivel de red.

Para cargas de trabajo con contenedores, el panorama de aislamiento es más complejo. CVE-2024-21626 (una fuga de descriptor de archivo en runc) y las tres vulnerabilidades críticas de runc divulgadas en noviembre de 2025 demostraron que el límite entre el contenedor y el host no es tan sólido como parece. Actualiza a runc 1.2.8 o posterior y, para cargas de trabajo con GPU, ejecuta NVIDIA Container Toolkit v1.16.2 o superior (CVE-2025-23266, CVSS 9.0, permite acceso root completo al host desde un contenedor malicioso). Trata el ciclo de parches del kernel del host como una preocupación operativa de primer orden, no como una tarea de mantenimiento trimestral.

Límites de privilegios e higiene de credenciales

El movimiento lateral en entornos cloud frecuentemente explota cuentas de servicio con permisos excesivos y tokens de API de larga duración almacenados en variables de entorno o archivos de configuración. La brecha de Change Healthcare en febrero de 2024, que resultó en un pago de rescate reportado de 22 millones de dólares, siguió exactamente este patrón: las credenciales robadas permitieron el movimiento lateral a través de una red plana antes de que se desplegara el ransomware.

Los controles que cierran esta vía son operativos, no solo técnicos:

  • Rota las claves de API y las credenciales de cuentas de servicio según un calendario definido. Trata cualquier token con más de 90 días de antigüedad como potencialmente comprometido.
  • Aplica el principio de mínimo privilegio a cada cuenta de servicio. Un proceso que lee desde el almacenamiento de objetos no necesita acceso de escritura y, desde luego, no necesita permisos de IAM.
  • Usa la versión 2 del servicio de metadatos de instancia (IMDSv2 en APIs compatibles con AWS) para evitar que ataques SSRF recojan credenciales de instancia a través del endpoint de metadatos.
  • Audita las variables de entorno en contenedores en ejecución y en unidades de systemd. Los secretos en variables de entorno son legibles por cualquier proceso que se ejecute como el mismo usuario y por cualquiera con acceso a /proc/<pid>/environ.
  • Separa las cargas de trabajo por nivel de privilegio entre instancias en lugar de ejecutar procesos de alto y bajo privilegio en el mismo host.

El tiempo medio global de permanencia del atacante de 14 días reportado en el informe M-Trends 2026 de Mandiant significa que la exposición de credenciales rara vez se descubre antes de que haya sido utilizada. El objetivo es limitar a qué puede acceder una sola credencial comprometida, no detectar el compromiso al instante.

El monitoreo como control contra el movimiento lateral

El hardening reduce la probabilidad y el radio de explosión de un compromiso; el monitoreo es lo que te indica cuándo el hardening ha fallado. Para cargas de trabajo en VPS, el conjunto mínimo de señales útiles incluye: registros de autenticación (exitosos y fallidos), intentos de conexión saliente hacia destinos inesperados, ejecución de procesos desde rutas inesperadas (auditd con reglas apropiadas) y cambios en archivos de /etc, /bin y /sbin.

Envía estos registros fuera del host en tiempo casi real. Un atacante con acceso root borrará los registros locales. El valor del rastro de auditoría depende enteramente de que esté en un lugar al que el atacante no pueda llegar.

Combina el monitoreo a nivel de host con datos de flujo de red. Un pico en el tráfico saliente de un VPS que normalmente envía unos pocos kilobytes por minuto es una señal más sólida que cualquier entrada de registro individual. Correlacionar ambos es donde la detección automatizada se vuelve genuinamente útil en lugar de simple ruido.