En un ecosistema donde lanzar un VPS cuesta minutos pero comprometerlo puede tardar segundos, una guía de GitHub se ha convertido en lectura obligada para administradores y devops que trabajan con Linux. Se trata de “How To Secure A Linux Server”, un repositorio mantenido y en constante evolución que condensa —de forma didáctica y accionable— las medidas esenciales para asegurar un servidor Linux: de endurecer SSH a levantar un firewall, pasar por Fail2Ban o CrowdSec, aplicar actualizaciones de seguridad automáticas, instrumentar auditoría, e incluso automatizar todo con Ansible.
La propuesta no es un listado desordenado de comandos, sino una metodología con contexto: cada capítulo explica por qué aplicar una medida, cómo funciona y qué riesgos evitar. Añade además advertencias claras —como mantener una segunda sesión abierta antes de cambiar sshd_config para no perder el acceso— y toma en serio lo que muchos manuales pasan por alto: correo saliente para alertas, plan de recuperación, copias de seguridad y pruebas de restauración.
Una cobertura amplia y pragmática: del “mínimo viable de seguridad” a un hardening serio
La guía está pensada para Debian y derivadas, pero casi todo se extrapola a otras distribuciones. Se estructura en bloques con un orden lógico: asegurar el acceso, limitar privilegios, cerrar la red, detectar abusos y auditar. Los puntos más destacados, por capítulos:
- SSH. Recomienda claves Ed25519 en el cliente (
ssh-keygen -t ed25519), copiar la clave pública al servidor (ssh-copy-id) y, a continuación, desactivar la autenticación por contraseña y el login de root. Sugiere crear un grupo (por ejemplo,sshusers) y restringir el acceso conAllowGroups. Propone endurecer el fichero/etc/ssh/sshd_configcon Kex/Ciphers/MACs seguros (alineados con las guías de Mozilla), limitar intentos (MaxAuthTries 2) y cerrar forwardings no utilizados. Para 2FA, utiliza libpam-google-authenticator (TOTP) y explica cómo integrarlo con PAM para exigir segundo factor cuando se inicia sesión con contraseña. - Privilegios mínimos. Limita sudo a un grupo concreto (p. ej.,
sudousers) y exige contraseña. Acota también el uso desua un grupo (suusers) y ajusta permisos de/bin/supara que solo sea ejecutable por miembros de ese grupo. - Contraseñas seguras. Integra
pam_pwqualitypara establecer políticas como longitud mínima, presencia de mayúsculas, minúsculas, dígitos y caracteres especiales, número de repeticiones, y que el password no contenga el nombre del usuario. - Tiempo y /proc. Insiste en tener NTP activo (o timesyncd) porque muchas validaciones de seguridad incluyen ventana temporal. Para ocultar procesos entre usuarios, monta
/procconhidepid=2(con aviso de compatibilidad en sistemas determinados). - Actualizaciones y avisos. En Debian, propone unattended-upgrades para parches críticos, apticron para avisos de paquetes pendientes y apt-listchanges para conocer cambios antes de actualizarlos. Recomienda habilitar correo con msmtp o exim4 (TLS implícito 465) para recibir alertas.
- Red. Con UFW como frontend sencillo sobre iptables/nftables, sugiere denegar por defecto tráfico entrante y (si se quiere un perfil más estricto) también saliente, abriendo solo lo necesario: SSH, DNS (53), NTP (123), HTTP/HTTPS para instalación de paquetes y servicios, SMTP saliente si se envían correos del sistema, etc.
- Detección y respuesta en red. Complementa UFW con PSAD (lee logs del kernel/iptables para detectar port scans y tráfico sospechoso) o con CrowdSec (detección colaborativa y bouncer iptables/nftables para bloqueo). Para el plano aplicación, incluye Fail2Ban con jails listas para SSH —y extensible a web, reverse proxy o bases de datos—.
- Auditoría y salud. Para compliance y hardening continuo, propone Lynis (escáner de seguridad con recomendaciones priorizadas) y Logwatch para un resumen diario de los logs del sistema por correo. También contempla AIDE (integridad de archivos), rkhunter/chkrootkit (detección de rootkits) y ClamAV (análisis bajo demanda o programado).
- Registro y rotación. Sección explícita para separar logs de iptables con rsyslog (usando prefixes como
[IPTABLES]) y logrotate para evitar llenar disco. - Cifras adecuadas en SSH. Purga moduli de Diffie-Hellman con < 3.072 bits en
/etc/ssh/moduli, una recomendación recurrente en guías modernas. - Aislamiento de apps. Para escritorios o servidores que alojan clientes de correo o navegadores, muestra cómo ejecutarlos en jaulas con Firejail y perfiles listos.
- Automatización. Incluye playbooks de Ansible que reproducen el hardening de la guía. El autor advierte: editar variables a medida, leer tareas antes de correrlas y tener siempre acceso alternativo (consola del proveedor) por si algo falla.
Más allá de la lista, la guía prioriza y advierte. Pide leer cada capítulo antes de aplicarlo, documentar variantes por distribución, y no copiar/pegar a ciegas. Propone, incluso, tomar como segunda fase los benchmarks de CIS para elevar el nivel cuando el entorno lo exija.
Un “mínimo viable” en 30 minutos y un hardening serio en 1–2 horas
El valor diferencial es que se puede empezar hoy. Un administrador con prisa puede aplicar un “MVP de seguridad” en menos de una hora —y ampliar después—:
- Claves SSH, sin contraseña, sin root, y restringido a grupo.
- UFW activo: denegar por defecto, permitir solo lo necesario (incluido HTTP/HTTPS para paquetes).
- Fail2Ban vigilando SSH.
- Unattended-upgrades + correo configurado para alertas.
- Lynis para un primer informe de brechas y quick wins.
Con 1–2 horas adicionales, es viable desplegar CrowdSec o PSAD, Logwatch diario, hidepid=2 en /proc, política de contraseñas con pam_pwquality, purga de moduli cortos, y comenzar con AIDE. Para equipos que mantienen varios servidores, la guía ofrece la vía Ansible para reproducir el resultado con idempotencia.
Qué evita que uno se quede sin acceso (y otros errores que la guía ayuda a esquivar)
El repositorio no rehúye los clásicos que rompen servidores:
- Cambiar
sshd_configy reiniciar sin un segundo terminal activo. - Cerrar salidas de UFW y olvidarse de DNS/NTP/HTTP(S) (adiós
apt). - Activar MFA sin consola del proveedor o códigos de emergencia.
- Poner
PasswordAuthentication noantes de copiar la clave pública al servidor.
Al enumerarlos y ponerlos en contexto, la guía reduce el “riesgo de brickear” un VPS al aplicar las mejores prácticas.
¿Para quién es útil y hasta dónde llega?
El público natural son administradores de sistemas, desarrolladores con VPS o quien mantiene servidores self-hosted (blogs, tiendas, paneles, reverse proxies, homelabs). El enfoque es agnóstico de distribución y está probado en Debian, pero aplica a Ubuntu y otras distros con adaptaciones mínimas (paquetes, rutas, servicios).
¿Hasta dónde llega? Cubre con solidez el baseline que se espera de un servidor conectado a Internet. Para entornos de producción críticos —SLA estrictos, datos regulados—, sugiere escalar con CIS Benchmarks, auditorías formales, monitorización (Prometheus/Node Exporter), logs centralizados (ELK/Loki), copias de seguridad verificadas y un plan de recuperación. También incorpora OSSEC-HIDS como opción de detección en host, para quien necesite ir más lejos en host-based IDS.
Un recurso “para guardar en favoritos” (y mantener vivo)
Quien trabaja con servidores sabe que lo más difícil no es saber qué hacer, sino tener todo en un solo sitio, actualizado y con contexto. Ese es el hueco que esta guía ha llenado: estructura, razón de ser de cada medida, código listo para copiar y, sobre todo, una lista de tareas priorizada que se puede empezar hoy mismo y que escala con las necesidades.
Para equipos y freelancers, el repositorio permite estandarizar el hardening, repetirlo con Ansible y documentarlo de forma clara. Para principiantes, es una puerta de entrada amable que enseña seguridad mientras la pone en práctica. Y para usuarios experimentados, un checklist vivo que evita olvidos y recoge atajos.
Preguntas frecuentes
¿Qué diferencia práctica hay entre Fail2Ban y CrowdSec, y puedo usarlos juntos?
Fail2Ban monitoriza logs de aplicaciones (SSH, Nginx, etc.) y bloquea IPs según patrones locales (p. ej., múltiples fallos seguidos). CrowdSec hace algo similar, pero comparte inteligencia con la comunidad y distribuye una lista de bloqueo comunitaria a todos los usuarios. Se pueden usar juntos: Fail2Ban para reglas locales específicas y CrowdSec para bloquear IPs maliciosas a escala antes de que lleguen a tu host.
¿Qué medidas mínimas debería aplicar en un VPS recién creado para no quedar expuesto?
Claves SSH (sin contraseña), cerrar root, habilitar UFW (denegar por defecto y abrir lo justo), Fail2Ban para SSH, actualizaciones automáticas críticas con alertas por correo, y Lynis para un informe de brechas. Con 30–60 minutos se puede cubrir ese “mínimo viable” de seguridad.
¿Cuándo tiene sentido pasar a automatización con Ansible en lugar de aplicar todo a mano?
En cuanto gestiones > 2–3 servidores o repitas hardening a menudo. La guía enlaza playbooks que reproducen las medidas (SSH, UFW, Fail2Ban, updates, etc.). Con Ansible ganas idempotencia, velocidad y consistencia; además, reduces errores humanos.
¿Por qué insiste tanto en configurar correo saliente y avisos si “solo” es seguridad del sistema?
Porque sin avisos no hay reacción. Un unattended-upgrades que falla, un Fail2Ban que banea de más, un Logwatch que detecta errores o un Lynis que marca brechas valen de poco si nadie lo ve. Configurar msmtp o exim4 (TLS 465), y asegurar que las alertas llegan a tu bandeja, es parte del baseline.
Fuentes
- GitHub – How To Secure A Linux Server (An evolving how-to guide for securing a Linux server): https://github.com/imthenachoman/How-To-Secure-A-Linux-Server
- Mozilla – OpenSSH guidelines (cifras, KEX, MACs modernos): https://infosec.mozilla.org/guidelines/openssh/
- Debian – Unattended-Upgrades (parches automáticos de seguridad): https://wiki.debian.org/UnattendedUpgrades
- CrowdSec (detección colaborativa y bouncers): https://www.crowdsec.net/
- CISOFY – Lynis (auditoría de seguridad host-based): https://cisofy.com/lynis/
La guía enlaza documentación adicional (CIS Benchmarks, Fail2Ban, PSAD, AIDE, rkhunter, chkrootkit, Logwatch, Firejail, OSSEC), útil para profundizar una vez asegurado el “mínimo viable”.
