Un servidor Linux expuesto a Internet empieza a recibir intentos de intrusión automatizados en cuestión de minutos desde el momento en que su IP responde. Bots que prueban contraseñas SSH, escáneres que buscan servicios vulnerables, exploits contra software sin parchear. El hardening —el proceso de reducir la superficie de ataque de un sistema— no es una tarea opcional para entornos de producción: es la diferencia entre un servidor que resiste ese ruido de fondo constante y uno que acaba formando parte de una botnet.
La buena noticia es que el hardening de Linux está muy bien documentado y la mayoría de las medidas son de bajo coste y alto impacto. La mala noticia es que las configuraciones por defecto de casi todas las distribuciones priorizan la comodidad sobre la seguridad, así que el trabajo hay que hacerlo de forma deliberada. Si aún estás decidiendo sobre qué base construir, nuestro repaso de las distribuciones Linux más usadas en servidores te ayudará a elegir.
En este artículo recorremos un checklist completo organizado por áreas, con las medidas concretas de cada una y una tabla resumen con prioridades para que puedas auditar tus servidores hoy mismo.
SSH: la Puerta de Entrada que Todos Atacan
SSH es el objetivo número uno de los ataques automatizados, así que es el primer servicio que hay que endurecer. Las medidas esenciales en /etc/ssh/sshd_config:
- check_circle Autenticación con claves, no con contraseñas: genera un par de claves (ed25519 es la opción recomendada actual), despliega la pública en el servidor y establece PasswordAuthentication no. Los ataques de fuerza bruta dejan de tener sentido.
- check_circle Deshabilitar el login de root: con PermitRootLogin no obligas a entrar con un usuario nominal y escalar con sudo, lo que deja trazabilidad de quién hizo qué.
- check_circle Limitar quién puede conectar: la directiva AllowUsers (o AllowGroups) restringe SSH a los usuarios que realmente lo necesitan. Todo lo demás se rechaza aunque tenga credenciales válidas.
- check_circle fail2ban: banea automáticamente las IPs que acumulan intentos fallidos, cortando los ataques de diccionario y reduciendo carga y ruido en los logs.
Sobre cambiar el puerto SSH:
Mover SSH del puerto 22 a otro puerto reduce el ruido de los escaneos masivos y deja logs más limpios, pero no es una medida de seguridad: cualquier escáner dirigido lo localiza en segundos. Úsalo como higiene operativa, nunca como sustituto de claves, fail2ban o MFA.
Usuarios, Privilegios y Actualizaciones Automáticas
La gestión de identidades es la segunda capa. El principio rector es el mínimo privilegio: cada usuario y cada proceso deben tener exactamente los permisos que necesitan, y ninguno más. Es el mismo principio que inspira las arquitecturas modernas de seguridad que analizamos en nuestra guía práctica de Zero Trust.
- check_circle sudo con mínimo privilegio: evita el comodín ALL=(ALL) ALL generalizado. Define en sudoers qué comandos concretos puede ejecutar cada rol y revisa esas reglas periódicamente.
- check_circle Contraseñas robustas: aunque SSH funcione con claves, las contraseñas locales siguen protegiendo sudo y consola. Aplica longitud mínima y complejidad con pam_pwquality y caduca las cuentas que lo requieran.
- check_circle Eliminar cuentas sin uso: usuarios de empleados que ya no están, cuentas de servicio de software desinstalado o usuarios de prueba son puertas traseras esperando a ser usadas. Inventaría /etc/passwd y bloquea o elimina lo que sobre.
En cuanto a los parches, la inmensa mayoría de las intrusiones explotan vulnerabilidades conocidas con parche disponible. Automatiza: unattended-upgrades en Debian/Ubuntu y dnf-automatic en RHEL/AlmaLinux/Rocky aplican las actualizaciones de seguridad sin intervención humana. Define además una estrategia de reinicios: los parches de kernel y glibc no se activan hasta reiniciar, así que programa ventanas de mantenimiento periódicas o usa live patching en sistemas que no pueden parar.
Firewall y Servicios: Exponer Solo lo Imprescindible
La regla de oro del firewall es denegar por defecto: todo cerrado salvo lo que explícitamente necesita estar abierto. Da igual la herramienta que uses —nftables directamente, ufw en Ubuntu/Debian o firewalld en la familia RHEL—, lo que importa es la política: entrada denegada por defecto, apertura selectiva de los puertos de servicio (80/443 para web, el puerto SSH restringido por origen cuando sea posible) y registro de lo descartado para detectar patrones de ataque.
El complemento natural del firewall es reducir los servicios en ejecución. Cada demonio activo es superficie de ataque: revisa con systemctl list-unit-files --state=enabled y con ss -tulpn qué está corriendo y escuchando, y desactiva lo que no se use: impresión, avahi, bluetooth o bases de datos instaladas por dependencias que nadie consulta.
Para los servicios que sí deben ejecutarse, systemd ofrece hardening por unidad con muy poco esfuerzo: directivas como ProtectSystem=strict, PrivateTmp=yes, NoNewPrivileges=yes o ProtectHome=yes confinan cada proceso a lo que necesita. El comando systemd-analyze security puntúa la exposición de cada unidad y te dice por dónde empezar.
Kernel, sysctl y Control de Acceso Obligatorio
El comportamiento de red del kernel se ajusta vía sysctl (ficheros en /etc/sysctl.d/). Tres ajustes clásicos que deberían estar en cualquier servidor:
- check_circle Desactivar redirects ICMP (accept_redirects y send_redirects a 0): evita que un atacante en la red manipule las rutas del servidor para interceptar tráfico.
- check_circle rp_filter = 1 (validación de ruta inversa): descarta paquetes con IP de origen falsificada, primera defensa contra spoofing.
- check_circle SYN cookies activadas (tcp_syncookies = 1): mantienen el servicio disponible durante ataques de inundación SYN sin agotar la tabla de conexiones.
La segunda pieza es el control de acceso obligatorio (MAC): SELinux en RHEL, AlmaLinux, Rocky y Fedora, y AppArmor en Ubuntu, Debian y SUSE. Ambos confinan lo que cada proceso puede tocar aunque haya sido comprometido: un servicio web bajo una política MAC no puede leer /etc/shadow ni lanzar una shell inversa aunque el atacante consiga ejecutar código. La regla es simple: modo enforcing siempre. Desactivarlo "porque da problemas" equivale a quitar el cinturón porque molesta; lo correcto es ajustar la política del servicio concreto.
Auditoría, Logs, Permisos de Ficheros y MFA
Si no registras lo que ocurre, no puedes detectar una intrusión ni investigarla después. Tres medidas de base:
- check_circle auditd: registra eventos a nivel de kernel —accesos a ficheros sensibles, cambios en sudoers, llamadas privilegiadas— con reglas alineadas con los CIS Benchmarks.
- check_circle journald persistente: con Storage=persistent los logs sobreviven a los reinicios; por defecto en muchas instalaciones se pierden al apagar.
- check_circle Envío a syslog remoto o SIEM: un atacante con root borra los logs locales. Copiarlos en tiempo real a un colector externo garantiza que la evidencia sobreviva al compromiso.
En el sistema de ficheros, revisa los permisos de los ficheros sensibles (/etc/shadow, claves privadas, configuraciones con credenciales), busca binarios SUID innecesarios y establece un umask restrictivo (027 o 077) para que los ficheros nuevos no nazcan legibles por todos. En las particiones, monta /tmp, /var/tmp y /dev/shm con noexec y nodev donde aplique: muchos exploits descargan su payload en directorios temporales y fallan si no pueden ejecutarlo desde ahí.
Por último, el MFA: añade un segundo factor (TOTP con google-authenticator vía PAM, o llaves FIDO2 nativas en OpenSSH) al acceso SSH y a cualquier panel administrativo. Si una clave privada se filtra desde un portátil robado, el segundo factor sigue cerrando la puerta.
Tabla Resumen: Checklist de Hardening por Prioridad
Esta tabla condensa el checklist completo. Empieza por las medidas críticas y baja por la lista:
| Área | Medida | Prioridad |
|---|---|---|
| SSH | Claves en lugar de contraseñas, PermitRootLogin no, AllowUsers, fail2ban | Crítica |
| Actualizaciones | unattended-upgrades / dnf-automatic + estrategia de reinicios | Crítica |
| Firewall | nftables/ufw/firewalld con denegación por defecto, solo puertos necesarios | Crítica |
| Usuarios | sudo con mínimo privilegio, contraseñas robustas, eliminar cuentas sin uso | Alta |
| Servicios | Desactivar demonios sin uso, hardening de unidades systemd | Alta |
| MAC | SELinux/AppArmor en modo enforcing | Alta |
| MFA | Segundo factor en SSH y accesos administrativos | Alta |
| Auditoría | auditd, journald persistente, envío a syslog remoto/SIEM | Alta |
| Kernel/sysctl | Desactivar redirects ICMP, rp_filter, SYN cookies | Media |
| Ficheros | Permisos, umask restrictivo, particiones con noexec/nodev | Media |
Cómo Auditarlo: CIS Benchmarks y Lynis
No hace falta inventar el estándar: los CIS Benchmarks publican guías de configuración segura para cada distribución (Ubuntu, Debian, RHEL, AlmaLinux…), con cientos de controles verificables organizados por niveles. Son la referencia que usan auditores y marcos de cumplimiento como ISO 27001 o ENS.
Para el día a día, Lynis es la herramienta más práctica: un script de auditoría de código abierto que analiza el sistema en minutos, puntúa su nivel de endurecimiento (hardening index) y genera una lista de recomendaciones priorizadas. Ejecutarlo trimestralmente —y después de cada cambio importante— convierte el hardening en un proceso medible en lugar de un acto de fe.
Todo esto exige tiempo y disciplina, y por eso en los servidores gestionados de EasyDataHost estas tareas van incluidas como servicio: hardening inicial alineado con CIS, parcheo automático con ventanas de reinicio pactadas, monitorización, gestión de logs y auditorías periódicas. Y si quieres una capa adicional de protección perimetral —firewall gestionado, filtrado DDoS, VPN—, nuestra página de seguridad detalla todas las opciones disponibles sobre nuestra infraestructura en España.
Preguntas Frecuentes
¿Cambiar el puerto SSH mejora la seguridad del servidor?
Reduce el ruido de los escaneos automatizados y limpia los logs, pero no es una medida de seguridad real: cualquier escáner de puertos lo encuentra en segundos. La protección efectiva viene de la autenticación con claves, deshabilitar el login de root, fail2ban y MFA.
¿Debo usar SELinux o AppArmor?
Usa el que integra tu distribución: SELinux en RHEL, AlmaLinux, Rocky Linux y Fedora; AppArmor en Ubuntu, Debian y SUSE. Lo importante no es cuál eliges, sino que esté en modo enforcing: un MAC en modo permissive o deshabilitado no protege nada.
¿Con qué frecuencia hay que auditar el hardening?
Como mínimo una auditoría trimestral con Lynis o los CIS Benchmarks, y siempre después de cambios importantes: nuevos servicios, actualizaciones de versión o cambios de arquitectura. Los parches de seguridad, en cambio, deben aplicarse de forma continua y automatizada.
Conclusión
El hardening no es un proyecto que se cierra: es un estado que se mantiene. Pero la mayor parte del riesgo se elimina con un conjunto de medidas bien conocidas y automatizables:
- arrow_right SSH con claves, sin root y con fail2ban, más MFA para los accesos administrativos: la puerta de entrada, blindada.
- arrow_right Parches automáticos y firewall con denegación por defecto: las dos medidas con mejor relación esfuerzo/impacto de toda la lista.
- arrow_right Mínimo privilegio en todas partes: sudo acotado, servicios desactivados, systemd endurecido y SELinux/AppArmor en enforcing.
- arrow_right Auditoría continua: logs persistentes y remotos, auditd, y verificación periódica con CIS Benchmarks y Lynis para que el endurecimiento sea medible.
Si prefieres que este trabajo lo haga un equipo especializado, en EasyDataHost lo incluimos en nuestros servidores gestionados. Contacta con nuestro equipo y te preparamos una propuesta sin compromiso.