Checklist de endurecimiento de un VPS recien creado

Esta es la lista que recorro cuando me entregan un VPS recién creado, antes de subir nada. Sale de auditar mi propio servidor haciéndome la pregunta incómoda: si alguien ya está dentro, ¿qué tan lejos llega?

Está ordenada por lo que más reduce el riesgo, no por lo que es más fácil.

1. Acceso

• Llave SSH con passphrase. Sin ella, copiar un archivo de tu carpeta de usuario equivale a tener tu servidor. Es el punto que más gente se salta.
• Login de root deshabilitado: PermitRootLogin no.
• Autenticación por contraseña deshabilitada: PasswordAuthentication no.
• MaxAuthTries 3.
• Revisa que no haya directivas contradictorias. Los archivos de sshd_config.d/ se leen en orden alfabético; si tu endurecimiento gana solo por llamarse 00-, está teniendo suerte, no está configurado. Verifica el resultado real con sshd -T | grep -Ei 'permitrootlogin|passwordauth'.

2. El grupo docker

• Asume que estar en el grupo docker es ser root. Quien puede hablarle al demonio puede montar la raíz del sistema dentro de un contenedor y leerla entera. Tu sudo con contraseña no protege de eso.
• Decide a conciencia: o sacas al usuario del grupo y usas sudo puntual, o lo dejas sabiendo que la llave SSH es la única puerta real.

3. Exposición de puertos

• Publica todo en loopback: "127.0.0.1:8080:80" y nunca "8080:80". Docker escribe reglas de iptables que se saltan firewalld, así que un puerto mal publicado está en internet aunque tu firewall se vea impecable.
• Firewall activo, solo 22, 80 y 443 abiertos.
• Verifica desde fuera, no desde el servidor. Un escaneo desde otra máquina es la única prueba que vale.
• Apaga lo que no usas (rpcbind en el 111 suele venir encendido).

4. Secretos

• chmod 600 en todos los .env. Por omisión nacen en 644: los lee cualquier usuario del sistema, y cualquier proceso que se escape de un contenedor.
• Una contraseña distinta por stack. Reusar la de una base en otra significa que una filtración se lleva dos. openssl rand -hex 24.
• Nada de credenciales en el repositorio. Lo que entra al historial de git se queda ahí aunque después lo borres.

5. Superficie web

• HTTP redirige a HTTPS, certificado por subdominio.
• .env y .git devuelven 403 desde el navegador. Compruébalo de verdad.
• APP_DEBUG=false. Una traza de error publica rutas, versiones y a veces variables de entorno.
• Cabeceras de seguridad: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
• Los paneles de administración de herramientas de terceros —monitoreo, consolas de almacenamiento, editores de automatización— no se publican. Se llega a ellos por túnel SSH o red privada. Un panel que no responde desde internet no hay que parcharlo.

6. Imágenes y actualizaciones

• Versiones fijas, nunca latest. Un up -d rutinario no debería poder traerte una versión mayor sin que lo hayas decidido.
• Actualizaciones de seguridad del sistema al día.
• SELinux o AppArmor en enforcing. Cuesta un rato de aprender y evita clases enteras de escapes.

7. Después de un incidente

• fail2ban activo. Y ten claro cómo se ven sus baneos en tu firewall: si usa reglas rich, aparecen mezcladas con tu configuración y parecen intrusiones cuando son defensas.
• Respaldos probados. Un respaldo que nunca restauraste no es un respaldo.
• Sabes de qué IPs te conectas tú. Sin eso, no puedes leer un log de accesos.

Cómo usarla

No es una lista para tachar de un tirón. Los puntos 1, 2 y 3 son los que cambian el resultado de un ataque real; los demás son buena higiene. Si solo vas a hacer tres cosas hoy: passphrase a la llave, chmod 600 a los .env, y revisa que ningún contenedor esté publicando sin 127.0.0.1.