Así que te acabas de instalar un servidor Linux y piensas que ya estás a salvo porque "Linux no tiene virus". Bonito. Precioso. También podrías dejar la puerta de casa abierta porque "en mi barrio no roban". El hardening Linux no es opcional, es lo mínimo que deberías hacer antes de conectar esa máquina a internet. Da igual si es un VPS de 5 euros o un servidor dedicado con más RAM que sentido común: si no aplicas una configuración segura de Linux, estás regalando tu servidor al primer script kiddie que pase por ahí. En esta guía vamos a repasar cómo asegurar un servidor Linux desde el minuto cero, con pasos concretos, herramientas reales y sin esa falsa sensación de seguridad que te da el logo del pingüino. Porque la seguridad Linux básica es eso: básica. Y aun así, el 90% no la aplica.
Primer paso: actualizar y minimizar la superficie de ataque
Antes de tocar nada, lo primero es lo primero: actualiza el sistema. Sí, ya sé que parece obvio. También es obvio mirar antes de cruzar la calle y la gente sigue mirando el móvil. Ejecuta lo que corresponda a tu distribución:
- Debian/Ubuntu:
apt update && apt upgrade -y - RHEL/CentOS/AlmaLinux:
dnf update -y - Arch:
pacman -Syu(y si usas Arch en un servidor, respeto y miedo a partes iguales)
Ahora viene la parte que nadie hace: eliminar servicios innecesarios. Un servidor seguro es un servidor que ejecuta solo lo que necesita. ¿Tienes un servidor web y resulta que tiene instalado avahi-daemon, cups y bluetooth? Fantástico, acabas de darle tres vectores de ataque gratuitos al enemigo. Revisa qué está corriendo:
systemctl list-units --type=service --state=running
Y desactiva todo lo que no necesites con systemctl disable --now nombre-servicio. El principio es simple: menos software, menos bugs, menos superficie de ataque. El CIS Benchmark para cada distribución tiene una lista detallada de servicios que deberían estar desactivados. Consúltalo, no muerde.
SSH: la puerta principal merece un buen cerrojo
Si hay un servicio que los atacantes van a martillear desde el segundo uno, es SSH. Abre /etc/ssh/sshd_config y vamos a hacer hardening Linux de verdad en el punto más crítico de tu servidor:
- Cambia el puerto por defecto: Sí, es seguridad por oscuridad. No, no es infalible. Pero reduce el ruido de bots automatizados un 95%.
Port 2222o el que prefieras (por encima de 1024). - Desactiva el login de root:
PermitRootLogin no. Siempre. Sin excepciones. Crea un usuario normal y usasudo. - Usa autenticación por clave pública:
PasswordAuthentication noyPubkeyAuthentication yes. Las contraseñas se pueden bruteforcear, las claves Ed25519 no (al menos no antes de que se extinga el sol). - Limita usuarios:
AllowUsers tu-usuariopara que solo los usuarios autorizados puedan conectar. - Timeout de inactividad:
ClientAliveInterval 300yClientAliveCountMax 2. Si te olvidas una sesión abierta, que se cierre sola.
Genera tus claves con ssh-keygen -t ed25519 -C "tu-email" y copia la pública al servidor con ssh-copy-id. Después de aplicar estos cambios, reinicia el servicio con systemctl restart sshd. Y por el amor de Tux, prueba que puedes conectar antes de cerrar tu sesión actual. No seas el administrador que se auto-bloqueó de su propio servidor. Nos ha pasado a todos, pero no hace falta repetirlo.
Para un nivel extra de protección, instala Fail2Ban. Esta herramienta monitoriza los logs de autenticación y banea automáticamente las IPs que fallan demasiadas veces. Es como tener un portero de discoteca para tu SSH:
apt install fail2ban -y
Si te interesa este tema, te recomendamos leer nuestro artículo sobre Las mejores herramientas de ciberseguridad gratuitas para particulares y pymes, donde profundizamos en aspectos clave relacionados.
La configuración por defecto ya es razonable, pero créate un /etc/fail2ban/jail.local para personalizar tiempos de baneo y número de intentos. En un servidor real, Fail2Ban puede bloquear miles de intentos al día. Literalmente miles. Si revisas /var/log/auth.log en un servidor nuevo sin protección, te entrará ansiedad.
Firewall: si no filtras, te filtran a ti
Un servidor seguro necesita un firewall correctamente configurado. No es negociable. En el mundo de la seguridad Linux básica, el firewall es tu primera línea de defensa después de la red. Tienes varias opciones:
- UFW (Uncomplicated Firewall): perfecto para empezar. Viene en Ubuntu/Debian y hace honor a su nombre.
- firewalld: el estándar en RHEL/CentOS/AlmaLinux, basado en zonas.
- nftables/iptables: para cuando quieras control total y te guste sufrir (o eres un profesional, que a veces es lo mismo).
Con UFW, la configuración básica es ridículamente sencilla:
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp (o el puerto SSH que hayas elegido)
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
La regla de oro: deniega todo por defecto y permite solo lo necesario. Cada puerto abierto es una invitación. Si no necesitas que un servicio sea accesible desde internet, no abras su puerto. Punto. Revisa periódicamente con ufw status verbose o ss -tlnp para verificar qué puertos están escuchando. Te sorprenderías de las cosas que aparecen ahí sin que las hayas invitado.
Permisos, auditoría y extras que marcan la diferencia
Vamos con el hardening Linux que separa a los administradores de los que simplemente tienen acceso root. Estos pasos son los que muchos ignoran y después lloran:
Política de contraseñas: aunque uses claves SSH, hay servicios locales que usan contraseñas. Configura /etc/login.defs con valores razonables: PASS_MAX_DAYS 90, PASS_MIN_DAYS 1, PASS_MIN_LEN 12. Instala libpam-pwquality para forzar complejidad.
Permisos de archivos críticos: revisa que estos archivos tengan los permisos correctos:
| Archivo | Permisos recomendados | Propietario |
|---|---|---|
| /etc/passwd | 644 | root:root |
| /etc/shadow | 640 | root:shadow |
| /etc/gshadow | 640 | root:shadow |
| /etc/ssh/sshd_config | 600 | root:root |
| /etc/crontab | 600 | root:root |
Auditoría con auditd: instala auditd para tener un registro detallado de lo que pasa en tu sistema. Puedes configurar reglas para monitorizar cambios en archivos críticos, ejecución de comandos privilegiados y accesos sospechosos. El CVE-2021-4034 (PwnKit, escalada de privilegios en pkexec) se habría detectado mucho antes con reglas de auditoría sobre ejecución de binarios SUID.
Si te interesa este tema, te recomendamos leer nuestro artículo sobre Cómo proteger tu cuenta de Google al máximo: guía de seguridad completa, donde profundizamos en aspectos clave relacionados.
Actualizaciones automáticas de seguridad: instala unattended-upgrades en Debian/Ubuntu o configura dnf-automatic en RHEL. Las vulnerabilidades no esperan a que tú decidas actualizar un martes por la mañana. En 2024, el CVE-2024-6387 (regreSSHion) en OpenSSH afectó a millones de servidores. Los que tenían actualizaciones automáticas dormían tranquilos. Los demás, bueno, sudaron bastante.
Desactivar el bit SUID innecesario: busca binarios con SUID activo usando find / -perm -4000 -type f 2>/dev/null y evalúa si realmente necesitan ese permiso. Cada binario SUID es una potencial escalada de privilegios. Para una linux configuración segura, menos SUID es más seguridad.
Herramientas de auditoría recomendadas:
- Lynis (
apt install lynis): escanea tu sistema y te da una puntuación de hardening con recomendaciones concretas. Es como un examen de conciencia, pero para servidores. - ClamAV: sí, antivirus en Linux. No para detectar virus de Linux (que los hay, aunque pocos), sino para escanear archivos que sirves a usuarios de Windows.
- rkhunter / chkrootkit: detectan rootkits conocidos. No son infalibles, pero es una capa más.
- OSSEC / Wazuh: para monitorización en tiempo real si gestionas varios servidores.
Kernel y red: hardening avanzado para los valientes
Si has llegado hasta aquí, ya tienes un servidor más seguro que el 80% de los que hay en internet. Pero si quieres asegurar un servidor Linux de verdad, toca meterle mano al kernel a través de /etc/sysctl.conf:
Añade estas líneas para protección de red:
net.ipv4.conf.all.rp_filter = 1— activa la validación de ruta inversa para prevenir IP spoofingnet.ipv4.conf.all.accept_redirects = 0— ignora redirecciones ICMP (previene ataques MITM)net.ipv4.conf.all.send_redirects = 0— no enviar redireccionesnet.ipv4.icmp_echo_ignore_broadcasts = 1— ignora pings de broadcast (previene ataques Smurf)net.ipv4.tcp_syncookies = 1— protección contra SYN floodkernel.randomize_va_space = 2— ASLR completo, dificulta la explotación de vulnerabilidades de memoria
Aplica con sysctl -p. Estas opciones son estándar en cualquier guía de seguridad Linux básica seria, incluidas las del NIST y CIS. Si tu proveedor de hosting no las tiene activas por defecto, deberías plantearte cambiar de proveedor. O al menos, mirarle con desconfianza.
Preguntas frecuentes
¿Es realmente necesario el hardening si mi servidor solo tiene una web pequeña?
Absolutamente sí. A los atacantes les da igual que tu web tenga 10 visitas al día. No buscan tu contenido, buscan recursos: tu servidor para minar criptomonedas, enviar spam, lanzar ataques DDoS o alojar phishing. Un servidor seguro no depende de lo importante que sea para ti, sino de lo útil que es para un atacante. Y cualquier servidor con conexión a internet es útil.
¿Cambiar el puerto SSH sirve de algo realmente?
No te protege de un ataque dirigido, pero elimina el 99% del ruido automatizado. Los bots escanean el puerto 22 constantemente. Si lo cambias, tus logs de autenticación pasan de miles de intentos diarios a prácticamente cero. No es una medida de seguridad real, es higiene. Combínalo siempre con claves públicas y Fail2Ban para una protección efectiva.
¿Cada cuánto debo revisar la seguridad de mi servidor?
Ejecuta Lynis al menos una vez al mes y revisa los logs semanalmente. Las actualizaciones de seguridad deberían ser automáticas (con unattended-upgrades). Además, suscríbete a las listas de seguridad de tu distribución y revisa CVEs relevantes. Herramientas como Wazuh pueden automatizar gran parte de esta monitorización si gestionas múltiples servidores.
¿SELinux o AppArmor? ¿Cuál es mejor?
Depende de tu distribución. RHEL/CentOS usan SELinux por defecto; Debian/Ubuntu usan AppArmor. Ambos implementan Mandatory Access Control (MAC) y ambos funcionan bien. La mejor elección es la que tu distribución trae integrada, porque tendrá mejor soporte y documentación. Lo peor que puedes hacer es desactivar cualquiera de los dos porque "da problemas". Esos "problemas" son exactamente la protección funcionando.
¿Qué hago si creo que mi servidor ya ha sido comprometido?
No entres en pánico, pero actúa rápido. Primero, no apagues el servidor — perderás evidencia forense en memoria. Aísla la máquina de la red si puedes, revisa los logs (/var/log/auth.log, /var/log/syslog), busca procesos extraños con ps auxf y conexiones sospechosas con ss -tlnp. Ejecuta rkhunter y chkrootkit. Si confirmas la intrusión, lo más seguro es reinstalar desde cero con un backup limpio. Y esta vez, aplica todo el hardening desde el minuto uno.
Conclusión: un servidor seguro es un servidor mantenido
El hardening Linux no es algo que haces una vez y te olvidas. Es un proceso continuo que empieza con la instalación y no termina nunca. Pero con los pasos de esta guía — actualizar, minimizar servicios, blindar SSH, configurar el firewall, auditar permisos y ajustar el kernel — ya tienes una base sólida que te pone muy por delante de la mayoría. Recuerda: no necesitas ser el servidor más seguro del mundo, solo necesitas ser más seguro que el de al lado. Aunque lo ideal sería que todos fuéramos seguros, claro. Explora más artículos en nuestro blog para seguir blindando tu infraestructura, y si el spam es tu problema, ya sabes que MataSpam se encarga del correo mientras tú te encargas del servidor.
