De un VPS Vulnerable a una Fortaleza Automatizada - Parte I

Muchas veces montamos un VPS como laboratorio, y como sysadmin analizas tu propio servidor y piensas: "esto es un desastre". No porque algo haya explotado todavía, sino porque sabes que es cuestión de tiempo para que eso pase. Este post documenta exactamente eso: un VPS expuesto (un lab para probar muchas cosas, casi un HoneyPot) a proposito, un VPS desordenado y ruidoso, y despues de ver todo el ruido que hay, poco a poco te propones en convertirlo en una infraestructura que trabaja sola mientras duermes.

1. Lo primero que hice: que el servidor me hable solo

Antes de tocar el firewall, antes de mover usuarios, lo primero que necesitaba era visibilidad. Porque no puedes defender lo que no ves, y revisar /var/log/auth.log a mano cada día no es administrar un servidor, es torturarse.

La solución fue simple: un script que corre solo cada noche a las 23:00 y me deja un resumen en el log. Sin intervención. Sin acordarme. Si algo raro pasó durante el día, lo sé al día siguiente sin haber hecho nada.

Lo que hace ese script es centralizar tres cosas: los intentos de acceso SSH fallidos, las IPs que fueron bloqueadas, y los accesos exitosos del día. Nada más. Pero esas tres cosas, juntas, te cuentan la historia completa de lo que pasó mientras no estabas mirando.

2. Quién puede hacer qué: separar identidades de verdad

Este es el cambio que más cuesta entender hasta que lo ves en acción. Mucha gente opera su VPS entero desde root. Todo. Siempre. Y mientras nada falla, parece cómodo. El problema es que cuando algo falla, y va a fallar, ese atacante tiene las llaves de todo.

La solución no es compleja. Es simplemente decidir qué hace cada quien y no cruzar esa línea. Tres usuarios, tres funciones, sin excepciones:

Y lo mismo aplica al filesystem. Mover las herramientas de recon y exploit a /opt, fuera del PATH estándar, no es solo orden: es que un exploit automatizado que entre al servidor no va a encontrar esas herramientas a mano. Tendría que saber exactamente dónde buscar. Ese fricción extra puede ser la diferencia.

/opt/
 ├── recon/    # Herramientas de reconocimiento (fuera del PATH estándar)
 └── exploit/  # Herramientas ofensivas (permisos restrictivos, aisladas)

3. El firewall no es magia, es política

Cuando haces ss -tulpen en un VPS recién configurado, el resultado da miedo. Puertos por todos lados. Y la reacción instintiva es cerrar todo a lo loco. Pero no es así como funciona: la clave no es cuántos puertos escuchan internamente, sino cuántos puertos deja pasar el firewall desde fuera.

La política es simple y no tiene excepciones: todo denegado por defecto, y solo abres lo que puedes justificar.

Y aquí está la parte que me parece más elegante de toda la configuración: Tailscale. Con tailscaled.service corriendo, Portainer, las bases de datos, cualquier servicio interno, solo son accesibles desde mi red privada virtual. No hace falta abrir ningún puerto extra. Para cualquier bot escaneando internet, esos servicios directamente no existen.

4. El disco no miente: Docker y Snap se comen el espacio

Hay una cosa que nadie te dice cuando empiezas a meter contenedores y paquetes Snap en un servidor: se comen el disco sin que te des cuenta. No de golpe, sino poco a poco. Y un día haces df -h y el disco está al 87% sin saber bien por qué.

El du -sh /* es la autopsia. Te dice exactamente dónde está el peso y ya no puedes ignorarlo:

Los 22GB de /var son principalmente volúmenes Docker huérfanos: imágenes de contenedores que ya no usas, capas de builds anteriores, datos de contenedores borrados que siguen ocupando espacio. Un docker system prune bien dado puede recuperar bastante. Para Snap, el problema es que por defecto guarda las dos últimas versiones de cada paquete. Con unos pocos paquetes instalados eso se acumula. La solución es decirle que guarde solo dos revisiones.

Y para que nada de esto sea un problema de seguridad mientras duermes: unattended-upgrades activo. Los parches críticos se aplican solos. Sin recordatorios, sin ventanas de vulnerabilidad innecesarias.