Cómo aseguro un servidor, del primer acceso SSH a la guía de la NSA
TL;DR
Un servidor nuevo, expuesto a internet, es escaneado en pocos minutos por bots que buscan una contraseña débil en el puerto 22. La base: una clave SSH en lugar de una contraseña, un usuario no root con derechos limitados, un cortafuegos que cierra todo salvo lo estrictamente necesario, fail2ban contra el ruido, y backups que se restauran de verdad para comprobar que funcionan. La guía de endurecimiento de la NSA, documentada desde 2011, formaliza los mismos principios: cifrar, reducir la superficie de ataque, dar el mínimo de privilegios.
1. Una clave SSH, nunca una contraseña
Al crear el servidor, genero un par de claves si no tengo ya uno disponible:
ssh-keygen -t ed25519
La clave pública (.pub) llega al servidor de dos maneras, según el momento:
- Al crear el VPS: la mayoría de los proveedores (Hostinger, DigitalOcean, Scaleway...) muestran un campo "Clave SSH" durante la configuración de la instancia, incluso antes del primer arranque. Pega el contenido de
~/.ssh/id_ed25519.pub(que puedes obtener concat ~/.ssh/id_ed25519.pub) en ese campo: la clave ya está en su sitio en el primer acceso, sin teclear nunca una contraseña. - En un servidor ya creado:
ssh-copy-id thomas@ip-del-servidor, o a falta de eso, a mano:mkdir -p ~/.ssh && chmod 700 ~/.ssh echo "contenido-de-la-clave-publica" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys
La clave privada no sale nunca de mi máquina. Una clave sustituye a una contraseña: nada que recordar, nada que adivinar por fuerza bruta, y un compromiso se revoca borrando una línea de authorized_keys.
2. Un usuario no root, con derechos medidos
Conectarse como root da acceso total a quien adivine la contraseña o robe la clave. Creo un usuario con nombre propio, nunca "admin" o "user" (esos nombres genéricos le regalan la mitad del trabajo a un atacante, que solo tiene que encontrar el secreto):
adduser thomas
usermod -aG sudo thomas
Por defecto, el grupo sudo puede hacerlo todo, sin contraseña, desde cualquier sitio. visudo abre el archivo de configuración (/etc/sudoers) en un editor que verifica la sintaxis antes de guardar, para evitar quedarte fuera con un archivo roto. Una línea como esta restringe al usuario a unos pocos comandos precisos en lugar de un acceso total:
thomas ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/docker
Es el principio de mínimo privilegio aplicado a una cuenta, no solo a un servicio.
3. Actualizaciones, todos los días si es posible
Una imagen de VPS se construye en un momento dado. Entre ese momento y el arranque del servidor, salen parches de seguridad. Primer reflejo tras la conexión:
apt-get update && apt-get upgrade -y
La guía de la NSA recomienda hacerlo a diario, no semanalmente: un fallo conocido y publicado sigue siendo explotable mientras no se aplique el parche. Una semana de espera es una semana de exposición a una vulnerabilidad documentada públicamente.
4. Endurecer la configuración SSH
En /etc/ssh/sshd_config, tres líneas que cambiar antes que cualquier otra cosa:
PermitRootLogin no
PasswordAuthentication no
UsePAM no
La primera cierra el acceso directo de root. La segunda fuerza el uso de la clave: sin ella, PermitRootLogin no puede eludirse si PAM sigue activo. La tercera desactiva el módulo de autenticación que, en ciertas configuraciones, vuelve a pasar por una contraseña a pesar de todo. Reinicia el servicio tras la modificación:
systemctl restart sshd
5. Fail2ban contra el ruido, no contra los expertos
Con autenticación por clave, un ataque de fuerza bruta tiene una probabilidad casi nula de éxito. El problema no está ahí: un servidor expuesto es bombardeado con intentos de conexión de forma continua, y ese tráfico infla los registros hasta volverlos inutilizables.
apt-get install fail2ban
jail.conf se sobrescribe en cada actualización del paquete: la configuración va en una copia dedicada, nunca en el original.
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
En jail.local, bajo la sección [sshd], fijo un umbral amplio (maxretry = 15, findtime = 10m) en lugar de uno agresivo: un umbral demasiado bajo acaba baneando la IP de la oficina el día en que se prueban varias claves seguidas. Después:
systemctl restart fail2ban
fail2ban-client status sshd
El último comando confirma que la jaula sshd está activa y muestra las IP baneadas en ese momento. Fail2ban limita el spam, no sustituye a una buena autenticación.
6. Cortafuegos: dos capas, no una
Primer reflejo, iptables, permitiendo solo lo que debe pasar:
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP
Estas reglas desaparecen en el próximo reinicio si no se guardan. En Debian/Ubuntu:
apt-get install iptables-persistent
netfilter-persistent save
Segunda capa: el cortafuegos que ofrece el proveedor, configurado desde su interfaz web en lugar de la línea de comandos. En Hostinger, está en hPanel > VPS > Cortafuegos; en DigitalOcean, Networking > Firewalls; en Scaleway, Red > Security Groups. El principio es el mismo en todas partes: una lista de reglas de entrada/salida por puerto e IP de origen, aplicada incluso antes de que el tráfico llegue al servidor. Este cortafuegos no sustituye a iptables, se suma a él, con una ventaja concreta: un error de configuración en iptables puede cortar el acceso al servidor desde el propio servidor. El cortafuegos del proveedor sigue siendo controlable desde fuera, y por tanto recuperable incluso tras una mala manipulación local.
7. Red privada y bastión, para todo lo que no necesita internet
Una base de datos no tiene ninguna razón para tener una IP pública: solo los servidores de aplicación deben llegar a ella. La mayoría de los proveedores ofrecen una red privada (rango 10.0.0.0/8 típicamente), que se crea y se asocia a las máquinas correspondientes desde su interfaz (sección "Red privada" o "Private Network" del panel del VPS, distinta de la red pública creada por defecto). Una máquina puede pertenecer a las dos redes a la vez, o solo a la red privada si no tiene ninguna razón para ser alcanzada desde internet.
El montaje clásico: un servidor bastión, único punto de entrada público, con solo un SSH endurecido, conectado a la red privada donde viven las bases de datos y los servicios internos. Desde el bastión, una conexión SSH normal (ssh usuario@ip-privada) llega a las máquinas internas sin exponerlas nunca públicamente. Todo debe pasar por el bastión. Los esfuerzos de seguridad se concentran en una sola máquina, no en diez.
8. Backups: restaurarlos, no solo programarlos
Un backup programado y nunca probado es una falsa seguridad. Llega la avería, la restauración falla, y el problema se descubre en el peor momento. Dos maneras de programar los backups:
- Desde el panel del proveedor: la mayoría ofrece una pestaña "Copias de seguridad" con frecuencia (diaria, semanal) y retención configurables, sin instalar nada en el servidor.
- Con un script propio, para un control más fino (solo la base de datos, envío a un almacenamiento externo): un
cronque llama a un script de volcado (pg_dump,mysqldump...) seguido de un envío a un almacenamiento compatible con S3.
En ambos casos, a intervalos regulares, restaura un backup al azar en una máquina de pruebas y comprueba que los datos esperados están ahí, completos. Un backup que nunca has restaurado no es más que una hipótesis.
9. Lo que añade la guía de la NSA
La guía "Hardening Network Infrastructure" de la NSA (documentada desde 2011, revisada hasta 2016) formaliza tres principios que coinciden con esta checklist y van un poco más allá:
- Reducir la superficie de ataque: desactivar todo servicio que no se use, no solo asegurarlo. Un servidor X11, una impresora de red o un servicio NTP que corre sin motivo no protege de nada: cada servicio activo es un fallo potencial, aunque nunca llegue a explotarse.
- SELinux o un módulo equivalente: un módulo del kernel que verifica, para cada acción de un programa (leer un archivo, abrir un puerto), si tiene derecho a hacerla según una base de reglas centralizada. Poco usado en producción por la fama de ser complejo de configurar, pero es una capa de control que un cortafuegos solo no ofrece.
- Seguridad física: contraseña de BIOS, desactivación de los puertos USB en un servidor de datacenter. Si nadie debe conectar allí una memoria USB, mejor dejar el puerto inoperativo.
Ninguna de estas medidas sustituye a las ocho primeras. Cierran ángulos que una checklist orientada a SSH y red no cubre.