Guía práctica de hardening para un servidor Linux publicado en Internet

Publicar un servidor en Internet no consiste únicamente en abrir los puertos necesarios y comprobar que la aplicación responde. En cuanto una dirección IP es accesible, empezará a recibir escaneos automatizados, intentos de autenticación y peticiones dirigidas a servicios conocidos. El objetivo del hardening es reducir la superficie de ataque, limitar el impacto de un fallo y facilitar la detección de actividad anómala.

Esta guía propone un orden de trabajo. No es una lista para ejecutar sin contexto: cada cambio debe probarse y documentarse. Antes de modificar SSH, firewall, red o autenticación, conserva una sesión administrativa abierta y prepara un método de recuperación desde la consola del proveedor.

1. Crea un inventario real

Empieza por saber qué hay instalado y qué escucha en red. Conviene registrar sistema operativo, versión del kernel, aplicaciones, usuarios administrativos, puertos, tareas programadas, servicios y rutas de datos.

hostnamectl
uname -a
ss -tulpn
systemctl --type=service --state=running

Un servicio desconocido no debe bloquearse a ciegas. Primero identifica el paquete, su función y quién lo utiliza. El inventario es la referencia para saber qué sobra y para detectar cambios futuros.

2. Mantén el sistema actualizado

Aplica parches de seguridad con una ventana de mantenimiento y revisa si es necesario reiniciar. En Debian y derivados:

apt update
apt list --upgradable
apt upgrade

Automatizar actualizaciones de seguridad puede ser útil, pero no elimina la necesidad de revisar dependencias, servicios reiniciados y compatibilidad con la aplicación.

3. Reduce servicios y exposición

Cada puerto abierto representa una responsabilidad. Si una base de datos solo la usa una aplicación local, debe escuchar en 127.0.0.1 o en una red privada, no en todas las interfaces. Los paneles administrativos deberían limitarse por VPN, red de gestión o lista de IP autorizadas.

Comprueba de nuevo con ss -tulpn y desde un equipo externo. El resultado externo es importante porque un firewall intermedio puede cambiar lo que realmente queda accesible.

4. Protege SSH

Usa cuentas individuales y claves públicas. Evita el acceso directo de root, revisa los grupos con privilegios y deshabilita métodos que no necesites. Antes de reiniciar SSH, valida la configuración:

sshd -t

Después prueba una nueva conexión en otra terminal. Una configuración segura que te deja fuera del servidor no es una configuración operativa.

5. Aplica mínimo privilegio

Los procesos web no deben ejecutarse como administradores. Separa usuarios por servicio, limita permisos de lectura y escritura, y evita que las aplicaciones compartan secretos o directorios. Revisa especialmente:

• Propietarios y grupos de archivos de configuración.
• Directorios de subida de usuarios.
• Claves privadas, tokens y contraseñas.
• Uso de sudo y pertenencia a grupos privilegiados.
• Tareas cron ejecutadas como root.

6. Configura un firewall comprensible

Una política sencilla es más fácil de mantener que un conjunto de reglas improvisadas. Permite únicamente los puertos necesarios y documenta el motivo de cada excepción. No cierres la conexión SSH actual hasta confirmar que la regla de administración funciona desde tu ubicación.

El firewall local complementa, pero no sustituye, al firewall del proveedor o al filtrado perimetral. Mantener ambos aporta defensa en profundidad.

7. Registros, alertas y protección frente a fuerza bruta

Centraliza o conserva los registros suficientes para investigar. Revisa autenticaciones, errores de aplicaciones, cambios de privilegios y actividad del servidor web. Herramientas como Fail2ban pueden bloquear patrones repetitivos, pero deben configurarse con filtros adecuados para evitar falsos positivos.

Un SIEM como Wazuh aporta correlación, inventario y alertas. Aun así, la monitorización solo es útil si alguien revisa y responde a los eventos.

8. Copias y recuperación

Una copia de seguridad no está validada hasta que se prueba una restauración. Conserva copias fuera del servidor, cifra la información sensible y documenta los pasos para reconstruir el servicio. Incluye configuración, bases de datos, certificados, aplicaciones y secretos necesarios.

9. Verificación final

Tras aplicar cambios:

• Comprueba que la aplicación funciona desde fuera.
• Repite el inventario de puertos.
• Valida permisos y usuarios.
• Revisa los registros por errores nuevos.
• Ejecuta una restauración de prueba.
• Documenta fecha, responsable y cambios realizados.

Conclusión

El hardening no es una acción puntual. Es un ciclo de inventario, reducción, actualización, monitorización y verificación. Un servidor pequeño con pocos servicios, permisos claros y copias probadas suele ser más resistente que una plataforma compleja cuya exposición nadie conoce por completo.

Este contenido es informativo y está orientado a administración defensiva, auditorías autorizadas y mejora de la seguridad. Adapta cualquier cambio a tu entorno y conserva una copia de seguridad antes de aplicarlo.