De un VPS Vulnerable a una Fortaleza Automatizada - Parte II

En la Parte I vimos el diagnóstico: qué tiene un VPS típico, por qué es un problema, y cuáles son los principios que guían el hardening. Ahora viene lo concreto. Esta parte es el plan de ejecución real: los comandos en orden, con contexto, explicados para que entiendas qué hace cada uno y por qué va en ese lugar. No es una receta de copiar y pegar. Es un plan maestro que puedes adaptar a cualquier servidor desde el día cero.

El Script Maestro: De Cero a Fortaleza en 5 Fases

El orden importa. No puedes configurar el firewall antes de crear los usuarios. No puedes automatizar reportes antes de tener la estructura de carpetas. Cada fase prepara el terreno para la siguiente. Sigue el orden y el resultado es predecible. Sáltate pasos y tendrás un servidor a medias protegido, que es casi peor que uno sin proteger, porque te da falsa confianza.

Fase 1: Preparación y Limpieza — Adiós al Bloatware

Antes de construir cualquier cosa, hay que limpiar. Un servidor recién aprovisionado trae consigo servicios que no pediste y que no necesitas. Servicios de impresión, descubrimiento de red local, gestión de módems. En un entorno cloud no sirven para nada, pero sí añaden superficie de ataque. Lo primero es actualizar el sistema a su estado más reciente y luego quitarle todo lo que sobra.

Ese tercer comando es más importante de lo que parece. Si el servidor tenía una interfaz gráfica instalada (cosa común en VPS que empezaron como laboratorio), este comando le dice a systemd que no la levante en el próximo arranque. El servidor sigue funcionando exactamente igual para todo lo demás, pero sin cargar X11, el display manager ni ninguna de sus dependencias. Menos RAM consumida, menos superficie de ataque, más foco.

Fase 2: Creación de la Jerarquía de Usuarios

Aquí empieza la arquitectura de seguridad real. La premisa es simple: ninguna tarea debe tener más permisos de los estrictamente necesarios para realizarla. Creamos tres usuarios con funciones muy concretas, y solo uno de ellos tendrá acceso a sudo.

El usuario services y el usuario pentest no tienen acceso a sudo. Eso es deliberado. Si un contenedor Docker es comprometido y el atacante consigue acceso al usuario services, está en un callejón sin salida: no puede instalar software, no puede modificar configuraciones del sistema, no puede escalar privilegios. La jaula funciona.

Fase 3: Arquitectura de Carpetas en /opt

Un servidor sin estructura es un servidor que no puedes defender ni auditar. Si mañana necesitas saber qué hay en producción, qué está en pruebas y dónde están los logs, la respuesta tiene que ser inmediata. La estructura de /opt es esa respuesta.

El flag -p en mkdir crea toda la jerarquía de una vez, incluidos los directorios intermedios que no existan todavía. El chown -R aplica el cambio de propietario de forma recursiva a todo el árbol de /opt. A partir de ahora, labadmin puede trabajar libremente en esa estructura sin necesitar sudo para cada operación.

/opt/
 ├── services/          # Aplicaciones en producción
 │   ├── web/           # Servicios web y frontends
 │   ├── api/           # Backends y APIs
 │   └── proxy/         # Configuraciones de Nginx
 ├── lab/               # Entornos de laboratorio
 │   ├── redteam/       # Herramientas ofensivas
 │   ├── blueteam/      # Herramientas defensivas
 │   ├── malware/       # Muestras para análisis (aisladas)
 │   └── poc/           # Pruebas de concepto
 ├── tools/             # Scripts y binarios de mantenimiento
 └── data/              # Datos persistentes
     ├── logs/          # Logs centralizados
     ├── captures/      # Capturas de tráfico
     └── dumps/         # Volcados de memoria o DB

Fase 4: Blindaje de Red — Firewall y VPN

Esta es la fase que más impacto visible tiene. Antes de ejecutar estos comandos, el servidor es accesible desde cualquier punto de internet en múltiples puertos. Después, solo existen tres puertas públicas. Todo lo demás desaparece del mapa.

El orden aquí es crítico: primero defines las reglas, después activas el firewall. Si lo haces al revés y olvidas abrir el puerto 22 antes de hacer ufw enable, te quedas sin acceso SSH a tu propio servidor. Tailscale se instala antes de activar UFW porque su script de instalación necesita acceso a internet para descargar los binarios.

Una vez activo, Portainer, las bases de datos y cualquier panel de administración dejan de necesitar un puerto público. Solo son accesibles por la IP de la red Tailscale. Para Shodan, para Nmap, para cualquier escáner externo, esos servicios no existen.

Fase 5: Automatización de Informes con Cron

El último pilar es la observabilidad. Un servidor que no te informa de lo que pasa es un servidor que administras a ciegas. El script ssh-summary.sh es la solución mínima viable: un resumen diario automático que llega a tu log sin que tengas que hacer nada.

Ese último comando merece atención. El crontab -l 2>/dev/null lista las tareas existentes, redirigiendo los errores a la nada por si el crontab está vacío. El resultado se combina con la nueva línea usando un pipe, y todo se pasa a crontab - que reescribe el crontab completo. Es la forma segura de añadir una tarea sin borrar las que ya tienes.

Glosario Técnico: El Vocabulario del Hardening

Si llegaste hasta aquí y hay términos que se repiten en los posts pero no quedaron del todo claros, este glosario es para ti. No es un diccionario de Wikipedia: cada definición está contextualizada para lo que hemos estado haciendo.