Dsar SysAdmin

📡 Arquitectura de seguridad

Antes de tocar nada, viene bien tener un mapa mental claro de lo que vamos a reforzar. No se trata de montar un búnker, sino de cubrir los puntos más críticos para que tu servidor deje de ser un objetivo fácil.

+------------------------------------------------------+
|                 HARDENING LINUX                      |
+------------------------------------------------------+
|  SSH seguro     |  Permisos y usuarios               |
|  Firewall UFW   |  Auditoría (auditd)                |
|  Fail2Ban       |  Logs y monitorización             |
+------------------------------------------------------+

🔐 Endurecimiento de SSH

SSH es la puerta principal. Si está mal configurada, da igual lo que hagas después. Aquí empezamos por lo básico: reducir superficie de ataque y evitar accesos triviales.

# /etc/ssh/sshd_config
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers daniel

Cambiar el puerto no te hace invulnerable, pero reduce ruido. Desactivar el login por root es casi obligatorio si quieres dormir tranquilo, y la autenticación por clave debería ser el estándar en cualquier entorno serio.

daniel@server:~$ sudo systemctl restart ssh
daniel@server:~$ sudo ss -tuna | grep 2222

Si ves el puerto escuchando en el nuevo número, vas por buen camino.

🧩 Permisos y usuarios

Aquí es donde muchos servidores fallan: permisos demasiado abiertos, usuarios que ya no deberían existir, servicios escribiendo donde no deben… Un par de comprobaciones rápidas pueden ahorrarte muchos problemas más adelante.

# Buscar archivos con permisos peligrosos
$ sudo find / -type f -perm /o+w

# Revisar sudoers
$ sudo visudo

Si encuentras cosas raras, corrige antes de seguir. Un servidor con permisos mal puestos es como una casa con las ventanas abiertas: puede aguantar un tiempo, pero no es buena idea.

🧱 Firewall UFW

UFW es simple, pero suficiente para la mayoría de servidores web. La idea es clara: por defecto, todo cerrado salvo lo que realmente necesitas.

$ ufw default deny incoming
$ ufw default allow outgoing
$ ufw allow 2222/tcp
$ ufw allow 80/tcp
$ ufw enable

Consejo de veterano: activa UFW solo después de permitir tu puerto SSH. Casi todos hemos aprendido esto por las malas al menos una vez.

🚫 Fail2Ban

Fail2Ban es como un portero de discoteca: no evita que vengan, pero echa rápido a los pesados. Analiza los logs y banea IPs que se comportan de forma sospechosa.

# /etc/fail2ban/jail.d/sshd.conf
[sshd]
enabled  = true
port     = 2222
maxretry = 5
bantime  = 3600

daniel@server:~$ sudo fail2ban-client status sshd

Si ves IPs baneadas, significa que alguien ya estaba intentando entrar. Bienvenido a Internet.

📋 Auditoría con auditd

Auditd te permite saber qué ha pasado cuando algo huele raro. No es la herramienta más amigable del mundo, pero es muy útil para tener trazabilidad de cambios críticos.

# /etc/audit/rules.d/audit.rules
-w /etc/passwd -p wa -k passwd_changes
-w /etc/ssh/sshd_config -p wa -k ssh_config

Con estas reglas tendrás registro de modificaciones en ficheros sensibles como /etc/passwd o la configuración de SSH.

⚙️ Retos y soluciones

🔸 Reto: Bloqueo accidental por firewall

Uno de los clásicos: activas el firewall sin permitir antes el puerto SSH y te quedas fuera. La solución pasa por ser ordenado y no correr más de la cuenta.

$ ufw allow 2222/tcp
$ ufw enable

🔸 Reto: Permisos incorrectos en /etc

A veces un simple chmod mal puesto puede romper medio sistema o dejar huecos innecesarios. Por eso es importante revisar y corregir permisos peligrosos antes de dar por cerrado el hardening.

⏱️ Timeline del artículo

[2026-01-10]  Inicio del hardening
[2026-01-11]  Configuración de SSH y UFW
[2026-01-12]  Integración de Fail2Ban y auditd
[2026-01-13]  Revisión final y pruebas

Este tipo de hardening no convierte tu servidor en un búnker, pero sí lo coloca varios pasos por delante de una instalación por defecto. Y lo mejor: puedes aplicar todo esto en menos de una hora y dormir un poco más tranquilo.