Endurecer un VPS nuevo en la primera hora

Observe journalctl -u ssh en un servidor que lleva una hora en línea, y la primera vez que lo vea el volumen le resultará alarmante. No debería serlo. Lo que está viendo es la radiación de fondo de internet: un puñado de operaciones de escaneo, algunas académicas, algunas comerciales, algunas delictivas, que enumeran todo el espacio IPv4 de forma continua y entregan los resultados a bots que prueban credenciales. Su dirección fue alcanzada porque existe, en orden numérico, y volverá a ser alcanzada dentro de unas horas haga usted lo que haga.

Esto cambia el problema de una forma útil. No se está defendiendo de un adversario que lo ha elegido a usted y que se irá adaptando; se está defendiendo de un script con un repertorio fijo — root, admin, ubuntu, test, git, oracle, postgres, y las veinte mil contraseñas que han aparecido en filtraciones de datos. No tiene paciencia, ni creatividad, ni interés alguno en una máquina que no responde al primer intento. Desactivar la autenticación por contraseña no ralentiza a este atacante: lo elimina del tablero por completo.

Vale la pena conocer dos detalles. Primero, IPv6 es muchísimo más tranquilo, porque un /64 no se puede barrer por completo — pero en el momento en que su registro AAAA se hace público, o la dirección de su máquina aparece en una cabecera de correo o en un registro de transparencia de certificados, la tranquilidad se termina. Nunca trate IPv6 como un escondite; trátelo como un pajar más pequeño. Segundo, una dirección IPv4 tiene un pasado. Tuvo un inquilino antes que usted, y si ese inquilino gestionó mal un servidor de correo o alojó algo que acabó en una lista negra, usted hereda esa reputación hasta que se disipa. Si el correo le importa, compruebe la dirección en las listas negras habituales antes de construir nada sobre ella — es una comprobación de cinco minutos que ahorra una quincena depurando problemas de entregabilidad.

Casi todo compromiso real de un servidor pequeño empieza en uno de dos sitios: una contraseña que se podía adivinar, o un servicio que estaba escuchando y no debería haberlo estado. Las soluciones correspondientes son PasswordAuthentication no y un firewall con una política drop por defecto. No tienen nada de vistoso, se hacen juntas en quince minutos, y valen más que todos los demás controles de esta página juntos.

La razón es estructural, no estadística. Ambas están cerradas por defecto — fallan hacia el lado seguro. Un sshd que solo acepta claves no se puede forzar por fuerza bruta por muchos intentos que lleguen, porque no existe ningún camino en el código que acepte una contraseña. Un firewall de denegación por defecto protege servicios que todavía no ha instalado, incluida la base de datos que añadirá dentro de tres meses y olvidará vincular a localhost. Todo lo demás en una lista de endurecimiento es una enumeración de cosas malas: una lista de elementos concretos que apagar, que solo es tan completa como la propia lista.

Así que si solo va a leer una sección y cerrar la pestaña, lea esta, haga los pasos 2 a 5 más abajo, y dé la hora por bien empleada. El resto es genuinamente útil y genuinamente secundario.

En Debian 13 y Ubuntu 24.04, /etc/ssh/sshd_config empieza con una línea Include /etc/ssh/sshd_config.d/*.conf, y las imágenes cloud incluyen un archivo en ese directorio — normalmente 50-cloud-init.conf — que ya establece PasswordAuthentication. Editar el archivo principal y añadir sus propias directivas al final resulta natural, pero produce una configuración que no hace lo que dice.

La regla es lo único de sshd que sorprende a casi todo el mundo: para cada palabra clave, gana el primer valor obtenido. Esto es lo contrario de casi cualquier otro sistema de fusión de configuraciones que haya usado. El Include aparece cerca del principio del archivo principal, así que un fragmento se lee antes que el cuerpo de sshd_config — y entre los fragmentos, decide el orden alfabético. Un archivo llamado 10-hardening.conf vence a 50-cloud-init.conf. Un archivo llamado 60-hardening.conf pierde frente a él, en silencio, y no se dará cuenta al reiniciar y ver que todo informa de éxito.

Por eso nunca debe fiarse del archivo que acaba de escribir. Pregúntele al daemon qué es lo que realmente interpretó:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

sshd -T imprime la configuración efectiva una vez resueltos todos los includes, anulaciones y valores por defecto. Si esa salida dice passwordauthentication yes, la autenticación por contraseña está activada, sin importar lo que diga cualquier archivo en el disco. Nada más cuenta como verificación.

La segunda trampa es de la misma familia. Ubuntu 24.04 arranca sshd mediante activación por socket: ssh.socket es quien posee el puerto de escucha, y Port en sshd_config se ignora por completo. Compruébelo con systemctl is-enabled ssh.socket; si está habilitado y quiere un puerto distinto, cámbielo con systemctl edit ssh.socket y una anulación ListenStream= — no en sshd_config, donde el ajuste parecerá correcto y no hará nada.

Seamos honestos con este punto, porque internet no lo es. Mover sshd al puerto 2222 o al 47000 no detiene a ningún atacante competente. Un escaneo TCP completo de un host tarda segundos, el servicio se anuncia solo en el banner, y cualquiera que haya decidido atacarle a usted en concreto lo encontrará antes de terminarse el café.

Lo que sí consigue es reducir su log de autenticación en algo así como un noventa y cinco por ciento, y eso tiene valor real: es la diferencia entre unos logs que se hojean por encima y unos logs que de verdad se leen. Una señal que se puede ver gana a una señal enterrada. Si monitoriza aunque sea un poco, un auth.log tranquilo es la forma más barata de hacer visible una anomalía.

Los costes son pequeños pero reales, y son la razón por la que lo llamamos opcional en lugar de recomendado. Se olvidará del puerto cuando vuelva dentro de ocho meses. En principio, un puerto no estándar por encima de 1024 puede ser tomado por un proceso sin privilegios si en algún momento sshd deja de escuchar. Los firewalls de salida restrictivos en redes de cliente bloquean puertos poco habituales, así que de vez en cuando no podrá llegar a su propio servidor desde una oficina o un hotel. Y en un sistema con activación por socket hay que cambiarlo en el lugar correcto, según la sección anterior. Hágalo si le importan unos logs tranquilos. No lo haga y luego se sienta seguro por ello, y nunca lo haga en lugar de usar solo claves.

Un firewall que enumera qué bloquear es un archivador. Un firewall que enumera qué permitir es un control de seguridad. La diferencia lo es todo, porque solo el segundo cubre el servicio que instalará el mes que viene, el puerto de depuración que abrió un viernes, y el contenedor que decidió exponerse por su cuenta.

En nuestra plataforma dispone de dos capas, y son independientes. El filtro de borde es opcional, se configura por servidor desde el panel y se aplica en el hipervisor, de modo que el tráfico bloqueado nunca llega siquiera a su instancia — útil para reglas de capa 4 que quiere aplicar antes de que su kernel les dedique un solo ciclo, y para evitar que una instancia comprometida sea alcanzable mientras trabaja en ella. El firewall de la instancia es enteramente suyo: nftables, iptables, pf, lo que traiga su imagen. Nosotros nunca lo tocamos. Use ambos si la máquina importa; use al menos el segundo siempre.

Dos cosas del conjunto de reglas del paso 5 merecen explicación, porque la mayoría de los conjuntos de reglas copiados y pegados las hacen mal. No descarte todo el ICMP. Parece prudente, pero rompe el descubrimiento de la MTU de la ruta, lo que produce la peor clase de fallo que existe: las peticiones pequeñas funcionan, las respuestas grandes se quedan colgadas, y nada en sus logs menciona al firewall. Acepte como mínimo destination-unreachable, time-exceeded y parameter-problem. No filtre ICMPv6 por tipo a menos que conozca la lista. IPv6 depende de ICMPv6 para el descubrimiento de vecinos y los anuncios de router; bloquéelo de forma general y su conectividad IPv6 morirá de una manera que parece un problema de enrutamiento. Aceptar todo el ICMPv6 en un único host es un compromiso razonable, y el conjunto de reglas de más abajo hace exactamente eso.

Una advertencia antes de ejecutar flush ruleset: si Docker está instalado, esa línea elimina las reglas de NAT y de filtrado que escribió Docker, y la red de los contenedores deja de funcionar hasta que systemctl restart docker las restaura. Cargue primero su conjunto de reglas, reinicie Docker después, y lea la siguiente sección antes de publicar un solo puerto de contenedor.

Pregúntele a la máquina en qué está escuchando. No en lo que usted cree haber instalado — en lo que está vinculado ahora mismo:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

Todo lo que sobrevive a ese filtro es alcanzable desde algún sitio distinto de la propia máquina. En una imagen de fábrica, lo habitual es encontrar rpcbind en el 111 (nada de lo que usted ejecute lo necesita), un exim4 escuchando, sobrante de la instalación base, y un stub de systemd-resolved que es inofensivo en loopback y un resolutor abierto si no lo está. Los peligrosos llegan después, con el software que instaló usted a propósito: PostgreSQL en 0.0.0.0:5432 porque un tutorial decía que editara listen_addresses, Redis sin contraseña porque Redis no tuvo contraseña por defecto durante la mayor parte de su vida, un nodo de Elasticsearch, un exporter de Prometheus, un notebook de Jupyter. Cada uno de ellos ha sido el primer paso de una brecha real en muchísimas ocasiones.

Y ahora, la trampa que sorprende a la gente cuidadosa. Docker no le pide permiso a su firewall. Cuando escribe -p 5432:5432, Docker inserta reglas DNAT en la cadena PREROUTING de la tabla nat, que el kernel evalúa antes de que su cadena input llegue siquiera a ver el paquete; el tráfico se reenvía entonces al contenedor. Su política de denegación por defecto en la cadena input no se consulta, ufw status muestra el puerto como cerrado, y la base de datos está en el internet público. Este es un comportamiento documentado de Docker, lleva así una década, y ha dejado expuestas una cantidad enorme de bases de datos.

La solución es una sola cadena de texto, y es el hábito que vale la pena adquirir:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

Por último, consiga una opinión externa. Un escaneo de puertos desde el propio servidor le dice lo que piensa el kernel; un escaneo desde otro sitio le dice lo que ve el mundo, que es el único número que importa. Ejecute nmap -Pn -p- <your-ip> desde su portátil, no desde la máquina, y compare el resultado con la lista que esperaba.

La ventana que compromete a los servidores pequeños no es el zero-day. Son las cuatro semanas que pasan entre que un CVE se hace público con una prueba de concepto funcional y la siguiente vez que a usted le toca conectarse. Las herramientas de ataque absorben un nuevo fallo remoto en cuestión de días; una máquina que se parchea “cuando se tenga tiempo” queda expuesta durante todo ese intervalo, y cualquier operador honesto sabe lo largo que es en realidad ese intervalo.

La objeción a las actualizaciones automáticas es el miedo a que algo se rompa, y merece tomarse en serio — y después acotarse. Restrinja la automatización al repositorio de seguridad de su distribución, donde los mantenedores retroportan las correcciones a la versión empaquetada en lugar de publicar nuevas versiones upstream. Una actualización de seguridad de Debian para openssl es una compilación parcheada de la misma versión que ya está usando; el riesgo de que cambie el comportamiento es muchísimo menor que el riesgo de dejar un agujero remoto abierto durante un mes. Las actualizaciones de funcionalidades se quedan en manual, que es donde deben estar.

La parte que la gente se salta es el reinicio. Un libssl parcheado en el disco no le sirve de nada al proceso que cargó el antiguo al arrancar, y una actualización del kernel no hace absolutamente nada hasta que arranque con ella. O bien acepta un reinicio desatendido en una ventana horaria que elija usted, o instala needrestart y deja que le diga qué servicios siguen corriendo contra bibliotecas ya borradas — pero haga una de las dos cosas. “Las actualizaciones automáticas están activadas” mientras uptime marca 340 días es una ilusión cómoda, y es la más habitual que vemos.

fail2ban lee sus logs, detecta fallos repetidos desde una dirección y la bloquea durante un tiempo. CrowdSec hace lo mismo y comparte los veredictos a través de una red de participantes, de modo que puede bloquear una dirección que se ha portado mal en otro sitio antes de que llegue hasta usted. Ambos son buen software. Ninguno de los dos hace lo que la mayoría cree en un servidor SSH que solo acepta claves.

En cuanto PasswordAuthentication está en no, un ataque de fuerza bruta por SSH no puede tener éxito. No que “sea poco probable”: es que no existe ningún camino en el código para lograrlo. Bloquear una dirección tras cinco fallos, por lo tanto, no evita nada; reduce el volumen de logs y una cantidad insignificante de CPU. Eso es un beneficio real, simplemente no es un beneficio de seguridad, y la contrapartida no es gratis: una jail mal escrita que vigila el log equivocado ha dejado fuera de sus propios servidores a más administradores de los que jamás ha dejado fuera a atacantes.

Donde estas herramientas se ganan de verdad su lugar es una capa más arriba, en los servicios que sí expone de verdad: un formulario de inicio de sesión, un panel de administración de WordPress, una API con límites de tasa, un servidor de correo con SMTP AUTH. Esos sí aceptan contraseñas, sí se pueden forzar por fuerza bruta, y una lista de bloqueo es exactamente el control correcto. Así que nuestro veredicto es concreto y limitado. Sáltese la jail de SSH. Ponga CrowdSec o fail2ban delante de lo que tenga un campo de contraseña. Y elija lo que elija, ponga en la lista blanca su propia dirección de gestión primero — ignoreip existe precisamente para esa noche que, si no, recordará por los motivos equivocados.

La prevención es lo que se puede hacer en una hora. La detección es lo que le dice si esa hora fue suficiente. No hace falta que sea elaborada, y en un servidor único, tres cosas baratas cubren la mayor parte del terreno.

Conserve los logs. En muchas imágenes el journal vive en /run y se evapora al reiniciar, lo que significa que el registro de un incidente desaparece justo en el reinicio que lo sigue. Crear /var/log/journal es una corrección de una sola línea y lo más valioso de esta sección.

Entérese de los inicios de sesión. Una línea en /etc/ssh/sshrc que dispare logger en cada inicio de sesión no cuesta nada y le da un registro limpio y fácil de buscar con grep, separado del propio ruido de sshd. Hay una salvedad que suele pillar a la gente: sshd ejecuta ~/.ssh/rc en lugar de /etc/ssh/sshrc cuando el usuario tiene uno propio, así que el archivo global del sistema se salta precisamente para la cuenta que más probablemente tenga un dotfile personalizado. Si necesita un gancho que no se pueda eclipsar así, use pam_exec en su lugar.

Sepa cómo era el sistema de archivos el primer día. AIDE registra hashes de sus binarios, bibliotecas y archivos de unit, e informa de lo que ha cambiado desde entonces. La trampa es fundamental y suele ignorarse: una base de datos almacenada en la misma máquina que vigila puede ser regenerada por quien la haya comprometido, y a partir de ahí la comprobación informará “sin cambios” para siempre. Copie la base de datos fuera de la máquina, o al menos anote su hash en otro sitio, y la herramienta pasa a valer los veinte minutos que cuesta. Dejada donde está, es solo una manta de seguridad.

Merece la pena enunciar el principio general por separado: el log del que no puede fiarse es el que está en la máquina comprometida. Todo aquello con lo que realmente cuente —un journal, una base de datos de integridad, una copia de seguridad— debería tener una copia en algún sitio que ese mismo atacante no controle. Un segundo servidor pequeño en otra jurisdicción es una respuesta legítima a esto, y uno de cinco dólares basta.

Todo lo anterior es trabajo de perímetro, y vale la pena precisar dónde está el límite para no confundir una puerta de entrada bien cerrada con una caja fuerte.

No protege los datos en una máquina en funcionamiento. Un kernel endurecido y un firewall cerrado son irrelevantes para cualquiera con acceso al hipervisor, y para el contenido de la RAM mientras la máquina está encendida. Si lo que le preocupa es el disco cuando el servidor está apagado, incautado o dado de baja, eso es cifrado de disco, y es un procedimiento distinto con un modo de fallo distinto — vea cifrar un disco VPS con LUKS.

No le hace anónimo. Un servidor puede estar impecablemente endurecido y aun así delatar quién es su dueño, a través de un registro WHOIS, una clave SSH reutilizada, una etiqueta de analítica, un cliente SSH que se conecta desde casa sin ningún salto intermedio, o un certificado que vincula dos identidades entre sí. Pagar con Monero y luego iniciar sesión desde su propia dirección anula el pago. Ese modo de fallo tiene su propia página: los errores que desanonimizan.

No arregla su aplicación. Una inyección SQL, un endpoint de administración sin autenticar o una dependencia con una puerta trasera no entienden de ajustes de sshd. La mayoría de los compromisos de servidores bien gestionados llegan por el puerto que usted mismo abrió, deliberadamente, a propósito, para un servicio que escribió o instaló.

No es una copia de seguridad. El ransomware, un rm -rf con una variable que resultó estar vacía, y una actualización fallida acaban todos de la misma forma. Haga una copia, guárdela en otro sitio, y restáurela una vez antes de necesitarla de verdad — la misma disciplina que hace sobrevivible una migración a otro proveedor es la que hace sobrevivible un mal martes.

Nada de esto es un argumento en contra de dedicar esa hora. Es un argumento a favor de saber exactamente qué compró esa hora.