La primera hora en un servidor dedicado Linux nuevo: la checklist de endurecimiento

Primero la respuesta: la checklist

Ocho pasos, más o menos en el orden en que debería hacerlos. Cada uno lleva unos minutos; toda la lista cabe cómodamente en su primera hora en la máquina:

1. Cree un usuario admin sin root con sudo; deje de iniciar sesión como root.
2. Pase SSH a solo claves y endurezca sshd_config.
3. Aplique una base de cortafuegos default-deny: permita SSH y sus servicios, descarte el resto.
4. Active las actualizaciones de seguridad automáticas.
5. Instale fail2ban para bloquear direcciones que fallan la autenticación.
6. Verifique que la sincronización horaria esté activa.
7. Audite qué está escuchando y elimine o vincule internamente todo lo que no deba ser público.
8. Haga los registros persistentes y revíselos por encima una vez.

Todo lo de esta lista defiende contra el modelo de amenaza real del primer día de un servidor expuesto a internet: escaneo automatizado e indiscriminado y credential stuffing. La investigación de Unit 42 sobre honeypots encontró servicios expuestos atacados a los pocos minutos de entrar en línea, y el 80 % de los honeypots comprometidos en menos de 24 horas: a los escáneres no les importa quién es usted, solo que haya respondido. A continuación, los detalles, distribución por distribución.

Paso 1: un usuario sin root con sudo

Trabajar como root todo el tiempo significa que cada error tipográfico se ejecuta con privilegios completos y que cada servicio que configura mal parte, por defecto, con el máximo blast radius. Dos minutos:

adduser deploy
usermod -aG sudo deploy      # Debian/Ubuntu
usermod -aG wheel deploy     # RHEL/AlmaLinux/Rocky

Copie su clave SSH al nuevo usuario (ssh-copy-id [email protected], o péguela en ~/.ssh/authorized_keys), confirme que puede iniciar sesión y ejecutar sudo -i, y solo entonces siga adelante para bloquear SSH. El orden importa: nunca desactive una puerta antes de que la nueva se abra de forma demostrada.

Paso 2: SSH (solo claves, root bloqueado)

La autenticación por contraseña es justo aquello a lo que apuestan las botnets que escanean. Elimínela:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Después valide y recargue. sshd -t comprueba la sintaxis de la configuración para que un error tipográfico no pueda tirar SSH consigo:

sshd -t && systemctl reload ssh    # 'sshd' on the RHEL family

Mantenga abierta su sesión actual y confirme que una conexión nueva funciona antes de cerrar sesión. Ese hábito (probar la puerta nueva con la vieja aún abierta) es la diferencia entre endurecer y dejarse fuera. (Si aun así algo sale mal alguna vez, el acceso a consola fuera de banda le salva; más sobre eso al final.)

Cosas que conviene saber:

• Las distribuciones modernas traen valores criptográficos de SSH razonables por defecto; ya no necesita curar a mano las listas de cifrado.
• PermitRootLogin prohibit-password (root solo por clave) es una alternativa defendible a no si sus herramientas realmente necesitan inicios de sesión root; prefiera no más sudo cuando tenga la opción.
• En las versiones recientes de Ubuntu, sshd se activa por socket (ssh.socket), lo que casi nunca importa, hasta que cambia el puerto, momento en el que importa mucho. Lo cual nos lleva a:
• Cambiar el puerto SSH es reducción de ruido, no seguridad. Recorta el spam de registros de los escáneres más torpes; no frena a un atacante con un escáner de puertos. Hágalo por registros más tranquilos si quiere, nunca en lugar de las claves.

Paso 3: la base de cortafuegos

Debian y Ubuntu se entregan sin ninguna regla de cortafuegos. Todo servicio a la escucha es alcanzable desde cualquier parte del mundo en cuanto arranca. La base lleva cinco minutos: default-deny en la entrada, permitir el tráfico established, poner SSH y sus servicios reales en la lista blanca, y tratar bien ICMP (no lo bloquee en bloque; eso rompe el descubrimiento de path-MTU e IPv6).

Hemos escrito el conjunto de reglas completo y comentado como guía propia, reglas de cortafuegos por defecto sensatas para un servidor Linux, con la misma política en nftables nativo, ufw y firewalld, además de la mecánica para evitar quedarse fuera. Si solo sigue un enlace de esta checklist, que sea ese. (¿Dudando entre sintaxis de reglas? iptables vs nftables.)

El resumen de una línea por familia: ufw en Ubuntu, firewall-cmd en RHEL/Alma/Rocky, nftables nativo en Debian. Actívelo, permita el 22 más sus puertos de servicio, deniegue el resto, para ambas familias de direcciones.

Paso 4: actualizaciones de seguridad automáticas

La mayoría de los compromisos reales explotan vulnerabilidades para las que ya había parches disponibles. Un servidor que se parchea a sí mismo cierra esa ventana sin depender de que usted lea avisos de seguridad en el desayuno:

# Debian/Ubuntu — installed and on by default on Ubuntu Server; verify:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# RHEL/AlmaLinux/Rocky — security-only automatic updates:
dnf install dnf-automatic
# set upgrade_type = security in /etc/dnf/automatic.conf, then:
systemctl enable --now dnf-automatic.timer

Limítelo a actualizaciones de seguridad (ambas configuraciones por defecto de arriba ya lo hacen), para que las ejecuciones desatendidas no le sorprendan con saltos de versión mayores. Las actualizaciones del núcleo aún necesitan un reinicio para surtir efecto. Compruebe de vez en cuando o programe reinicios; unattended-upgrades puede hacer reinicios automáticos controlados si su carga de trabajo lo tolera.

Paso 5: fail2ban (bloqueo por evidencia)

El límite de tasa de su cortafuegos frena a ciegas los intentos de conexión; fail2ban lee el registro de autenticación y bloquea las direcciones que realmente fallan, un bloqueo basado en evidencias que complementa tanto al cortafuegos como a la autenticación solo por clave:

apt install fail2ban    # dnf install fail2ban (needs the EPEL repository on RHEL-family)

Los valores por defecto del paquete activan la jail de SSH, que es la que importa. Un ajuste que merece la pena hacer en /etc/fail2ban/jail.local: añada sus propias IP de gestión a ignoreip para que una clave mal escrita por su parte no pueda bloquearle.

¿Es fail2ban necesario una vez desactivadas las contraseñas? Estrictamente, no: la autenticación solo por clave no cae ante la fuerza bruta. Aun así se gana su sitio: reduce mucho el ruido de los registros, cubre los otros servicios que añadirá más adelante (correo, paneles, bases de datos con registros de autenticación), y suaviza el coste de CPU de los escáneres agresivos.

Paso 6: sincronización horaria

Poco vistoso y esencial: la validación de certificados TLS, la replicación de bases de datos, la correlación de registros durante un incidente y las tareas programadas dependen todos, calladamente, de que la hora sea correcta. Cada distribución moderna trae un cliente NTP; solo verifique que esté realmente sincronizado:

timedatectl    # look for "System clock synchronized: yes" and "NTP service: active"

Debian/Ubuntu usan systemd-timesyncd por defecto; la familia RHEL usa chrony. Cualquiera de los dos sirve para un servidor; no hay nada que ajustar el primer día más allá de confirmar el yes.

Paso 7: audite sus servicios a la escucha

Ahora haga honesta la lista blanca del cortafuegos averiguando qué está escuchando realmente:

ss -tlnp    # TCP listeners; add -u for UDP

Lea la salida con tres preguntas: ¿Sé qué es esto? ¿Necesita ser alcanzable desde internet? ¿Está deliberadamente en mi lista blanca del cortafuegos? Los hallazgos típicos en una máquina recién estrenada son inofensivos (sshd, systemd-resolved en 127.0.0.53), pero este es el hábito que atrapa la base de datos vinculada a 0.0.0.0 tras el despliegue del mes que viene. Todo lo que deba ser solo interno debería estar vinculado a 127.0.0.1 o a una dirección de red privada, no solo protegido por el cortafuegos: dos capas ganan a una.

Si usa Docker, sepa que los puertos de contenedor publicados eluden ufw por completo: -p 8080:80 queda expuesto a internet sin importar sus reglas. Vincúlelo a localhost (-p 127.0.0.1:8080:80) o use la cadena DOCKER-USER; detalles en la guía de cortafuegos.

Paso 8: registros persistentes, un vistazo

En algunas distribuciones, el journal de systemd existe solo en memoria y desaparece al reiniciar, justo cuando lo necesitaría. Hágalo persistente:

mkdir -p /var/log/journal && systemctl restart systemd-journald

Después dedique dos minutos a revisar por encima journalctl -p warning -b para saber cómo es lo «normal» en esta máquina; la respuesta a incidentes parte de una base de referencia. Conecte la máquina a cualquier monitorización que ya tenga en marcha (aunque sea una alerta básica de uptime o disco); la primera hora solo necesita que los registros sobrevivan y que alguien reciba un aviso cuando la máquina se comporte mal.

La chuleta, por familia de distribución

Qué familia usar en primer lugar es una decisión aparte; nuestra guía de distribuciones Linux lo cubre.

Con qué NO perder el tiempo en la primera hora

Una guía de endurecimiento honesta también dice dónde empiezan los rendimientos decrecientes:

• Port knocking y single-packet authorization. Divertidos, oscuros y frágiles en producción; claves + fail2ban ya ganaron esta batalla.
• Desactivar SELinux o AppArmor para «arreglar» una aplicación. Lo contrario del endurecimiento. Deje SELinux en enforcing / AppArmor activado; cuando algo se rompa, arregle la política (o las etiquetas de la aplicación), no el framework.
• Recorridos profundos de endurecimiento de núcleo/sysctl. Más allá de las SYN cookies (ya activas por defecto) y de lo que ajusta su guía de cortafuegos, afinar sysctl el primer día es cargo cult. Hágalo más adelante, con un benchmark y un motivo.
• Los antivirus y escáneres de rootkits. En un servidor Linux recién instalado y de propósito único, estos consumen sobre todo RAM y producen falsos positivos. Dejando aparte los regímenes de cumplimiento normativo, prescinda de ellos hoy.
• Las pasadas de benchmark CIS. Valiosas para flotas y auditorías, excesivas para la primera hora. La checklist de arriba cubre la intersección entre «alto impacto» y «bajo esfuerzo»; los benchmarks formales pueden llegar con la madurez.

El patrón: el endurecimiento de la primera hora consiste en cerrar las puertas que los bots realmente prueban, y luego seguir con el trabajo para el que compró el servidor.

Preguntas frecuentes

¿Merece la pena cambiar el puerto SSH?

Como reducción de ruido en los registros: un poco; como seguridad: no. Las botnets no dirigidas machacan sobre todo el puerto 22, así que mover sshd calma sus registros, pero cualquier atacante al que le importe lanza un escaneo de puertos y lo encuentra en segundos, y los puertos no estándar complican las herramientas y los cortafuegos. Si aun así lo mueve, trátelo como un ajuste de comodidad añadido encima de la autenticación solo por clave y fail2ban, nunca como sustituto de ellos.

¿Sigo necesitando fail2ban si la autenticación por contraseña está desactivada?

Necesitar, no: la fuerza bruta no puede vencer una clave que no puede adivinar. Querer, probablemente sí: fail2ban mantiene legibles los registros de autenticación bloqueando el interminable ruido de fondo de los escáneres, extiende ese mismo bloqueo basado en evidencias a los servicios que añada más adelante, y reduce el coste de recursos de ser escaneado. Son cinco minutos de configuración para un servidor permanentemente más tranquilo; la mayoría de los administradores lo consideran un buen trato.

¿Debo desactivar por completo el inicio de sesión como root?

Configure PermitRootLogin en no y use sudo desde un usuario con nombre: es el valor por defecto correcto, y le da atribución (qué clave hizo qué) más un obstáculo adicional para los atacantes. La excepción es la automatización que realmente necesita root directo; ahí, PermitRootLogin prohibit-password (solo claves, nunca contraseñas) es aceptable. Lo que nunca es defendible en un servidor expuesto a internet es root con inicio de sesión por contraseña.

¿En qué se diferencia un servidor dedicado de un VPS para el endurecimiento?

La checklist es idéntica; las diferencias están en los bordes. En un servidor dedicado usted es dueño de toda la pila, así que no hay agente del proveedor dentro de su sistema operativo ni vecinos con los que compartir el núcleo; la contrapartida es que la recuperación es responsabilidad suya, lo que hace que dos cosas importen más: el acceso a consola fuera de banda (para cuando un cambio de cortafuegos o de sshd sale mal) y las protecciones de borde de red delante de su puerto. Compruebe que su proveedor ofrece ambas cosas antes de necesitar una de ellas.

Despliegue en Serverside

El endurecimiento empieza antes de su primer inicio de sesión SSH: en nuestros servidores dedicados, la mitigación DDoS siempre activa y un cortafuegos de borde de autoservicio se sitúan aguas arriba de su puerto (de modo que el tráfico que no es de servicio puede descartarse antes de que llegue siquiera a la máquina que está endureciendo), y el acceso a consola KVM-over-IP incluido hace que un cambio fallido de sshd o del cortafuegos sea una solución de dos minutos en lugar de quedarse fuera. Aprovisione Ubuntu, Debian, AlmaLinux/Rocky o RHEL en menos de un minuto sobre el ASN 55285 y recorra esta checklist de principio a fin.

Profundice con las guías complementarias: reglas de cortafuegos por defecto sensatas, iptables vs nftables, y (para el día en que los escáneres traigan amigos) ataques DDoS explicados.