Hardening de Servidor Linux: Guía Esencial para Web

El hardening de servidor Linux es el proceso de reducir todo lo que un servidor expuesto a internet ofrece a un atacante: puertos, servicios, usuarios, versiones antiguas y permisos excesivos. Si tu empresa tiene un sitio web, tienda online o sistema en un VPS propio y nadie del equipo es sysadmin, esta checklist muestra qué hacer, en qué orden, qué no hacer y cuánto cuesta mantenerlo.

TL;DR

• En 2026, la explotación de vulnerabilidades se convirtió en la principal puerta de entrada en las brechas de datos: el 31% de los accesos iniciales en el Verizon DBIR 2026, frente al 20% del año anterior. Un servidor desactualizado es el objetivo más barato.
• El orden que funciona: inventario y copia de seguridad → SSH → firewall → actualizaciones → PHP y servidor web → base de datos → logs y monitorización.
• Varias versiones populares ya han dejado de tener soporte: PHP 8.1 (31/12/2025), MySQL 8.0 (abril/2026), Debian 11 (31/08/2026). PHP 8.2 solo recibe correcciones de seguridad hasta el 31/12/2026.
• Las trampas más costosas son silenciosas: Docker ignora UFW, fail2ban detrás de Cloudflare banea a la propia Cloudflare y, en Ubuntu 24.04, cambiar el puerto en sshd_config no cambia nada.
• El hardening de servidor Linux no es una tarea de un día: es una rutina mensual. Si nadie en la empresa va a realizar esta rutina, contrata a quien lo haga.

Escribo como desarrollador full stack y fundador de Agathas Web, una empresa que opera servidores Linux desde 2008. Mantengo entornos Moodle para instituciones educativas, sitios web y sistemas de clientes en alojamiento gestionado, así como la infraestructura de Voyia, nuestra plataforma de atención al cliente basada en la API oficial de WhatsApp. La checklist de hardening de servidor Linux que se presenta a continuación es la misma que aplicamos cuando heredamos un servidor.

¿Qué es el hardening de servidor Linux y por qué se ha vuelto urgente en 2026?

Un servidor recién creado en cualquier nube viene configurado para funcionar, no para resistir. Acepta el inicio de sesión por contraseña, deja servicios escuchando en todas las interfaces y confía en que alguien aplicará las actualizaciones. El hardening de servidor Linux es el proceso de desactivar lo que sobra y fortalecer lo que queda.

El motivo de la urgencia radica en los números. Según el Verizon Data Breach Investigations Report 2026, la explotación de vulnerabilidades ha pasado a representar el 31% de los accesos iniciales en las brechas de seguridad, por delante del phishing y las credenciales robadas. El mismo informe muestra que las organizaciones tardan una mediana de 43 días en corregir una vulnerabilidad que ya está siendo explotada, y solo el 26% de ellas la corrigen por completo.

Traducido a la realidad de una empresa con un servidor web: sin hardening de servidor Linux y sin una rutina de parches, el atacante no necesita elegirte. Escanea internet en busca de una versión vulnerable y entra donde encuentre la puerta abierta.

El caso que mejor ilustra esto es regreSSHion (CVE-2024-6387). En julio de 2024, Qualys reveló una vulnerabilidad en OpenSSH que permitía la ejecución remota de código como root, sin autenticación, en sistemas Linux con glibc. Afectaba a las versiones 8.5p1 a 9.7p1 y la empresa estimó más de 14 millones de instancias expuestas potencialmente vulnerables. Quienes tenían una rutina de actualización lo corrigieron en días. Quienes no, quedaron expuestos durante meses.

Por ello, el hardening de servidor Linux no es un proyecto con principio, medio y fin. Es una configuración inicial bien hecha sumada a una rutina que nunca se detiene. En nuestro alojamiento gestionado, el objetivo contractual es aplicar parches críticos en un plazo de 72 horas tras la publicación de la CVE — y es esta rutina, no la configuración del primer día, lo que separa un servidor seguro de un servidor que lo fue en su momento.

Antes de empezar: inventario, copia de seguridad y acceso de emergencia

El error más común de quienes realizan hardening de servidor Linux por primera vez es empezar por SSH y quedarse fuera. Antes de tocar nada, asegúrate de tres cosas.

1. Un camino de vuelta

• Consola de emergencia del proveedor (KVM, consola web, "rescue mode"). Pruébala antes. Si te equivocas con la regla del firewall, es por ahí por donde entras.
• Snapshot del disco tomado inmediatamente antes de los cambios. En un VPS cuesta céntimos y deshace un error en minutos.
• Una segunda sesión SSH abierta mientras alteras la configuración de acceso. Ciérrala solo después de probar el inicio de sesión en una tercera.

2. Un inventario honesto

Ejecuta ss -tulpn y anota cada servicio que esté escuchando. En un servidor heredado, el patrón que más encontramos es una base de datos escuchando en 0.0.0.0, un panel de administración olvidado y un servicio de prueba que nadie recuerda haber instalado. Cada elemento de esta lista necesita un propietario y una razón para existir.

3. Cuándo NO aplicar hardening ahora

• Sin una copia de seguridad probada. Reforzar un servidor sin una restauración garantizada cambia un riesgo por otro.
• En vísperas de un lanzamiento, período de matriculación o Black Friday. Los cambios de seguridad tienen una ventana, igual que los despliegues.
• Con un script de internet ejecutado a ciegas. Benchmarks como el CIS son una excelente referencia, pero aplicar todos los elementos de una vez puede romper la aplicación. Aplícalos por bloques y prueba entre ellos.
• En un sistema operativo sin soporte. Si el servidor ejecuta Ubuntu 20.04 o Debian 11, el hardening correcto es migrar a una versión soportada, no parchear la antigua.

SSH y usuarios: quién entra y cómo entra

SSH inicia el hardening de servidor Linux porque es la puerta principal. También es lo primero que prueban los robots, minutos después de que una nueva IP aparezca en internet.

Lo mínimo obligatorio

• Inicio de sesión solo por clave. PasswordAuthentication no y KbdInteractiveAuthentication no en sshd_config. Usa claves ed25519, una por persona, nunca compartidas.
• Root no entra directamente. PermitRootLogin no. Cada persona usa su propio usuario y eleva privilegios con sudo, lo que deja un rastro de quién hizo qué.
• Solo quien lo necesita. AllowUsers o AllowGroups limita quién puede iniciar sesión, incluso si existe otra cuenta en el sistema.
• fail2ban para bloquear IPs que insisten en fallar. No sustituye la clave, pero elimina ruido de los logs y detiene ataques de fuerza bruta en otros servicios.
• Desactiva las cuentas de quienes se han ido. Un antiguo proveedor con una clave aún autorizada en authorized_keys es más común de lo que parece.

Trampa: cambiar el puerto SSH en Ubuntu 24.04

Cambiar el puerto 22 por otro reduce el ruido en los logs, pero no es una protección real — un escáner encuentra el nuevo puerto en segundos. Y hay un detalle que sorprende a mucha gente: desde Ubuntu 22.10, SSH usa la activación por socket de systemd. En Ubuntu 24.04, modificar Port en sshd_config pasa la validación y es simplemente ignorado, porque quien escucha el puerto es ssh.socket. Es necesario ajustar el socket y ejecutar systemctl daemon-reload. Si el firewall ya se ha cerrado para el puerto antiguo, es aquí donde la persona pierde el acceso.

Usuarios y permisos en el sistema

La regla es el privilegio mínimo. El proceso del servidor web (www-data, nginx o apache) no puede ser el propietario de los archivos de la aplicación: si lo es, cualquier fallo en el código permite reescribir el propio código. Deja el código con un usuario de despliegue y otorga al servidor web permisos de escritura solo en las carpetas que lo necesiten, como uploads y cache. En Moodle, por ejemplo, moodledata debe estar fuera de la carpeta pública, con permisos de escritura solo para el proceso PHP.

Firewall: cierra todo y abre solo lo necesario

El firewall en el hardening de servidor Linux sigue una política simple: denegar todo por defecto y permitir solo lo que el negocio requiere. En general, esto significa 80 y 443 para el mundo y SSH solo para IPs conocidas o vía VPN.

En Ubuntu, UFW funciona bien: ufw default deny incoming, ufw allow 443/tcp, ufw allow from <seu-ip> to any port 22. Las bases de datos, Redis y los paneles internos no aparecen en esta lista. Escuchan en 127.0.0.1 o en una red privada.

Trampa 1: Docker pasa por encima de UFW

Si ejecutas contenedores, debes saber que al publicar un puerto con -p 8080:80, Docker escribe sus propias reglas de iptables, que el tráfico recorre antes de las reglas de UFW. Resultado: un ufw deny 8080 no bloquea nada. La documentación oficial de Docker explica el comportamiento. La corrección más simple es publicar solo en localhost (-p 127.0.0.1:8080:80) y dejar que el proxy inverso se comunique con el contenedor.

Trampa 2: fail2ban detrás de Cloudflare

Con un proxy como Cloudflare delante, el servidor ve la IP de Cloudflare, no la del visitante. Un fail2ban que lee el log de Nginx sin configurar la IP real baneará direcciones de la propia Cloudflare — y derribará clientes legítimos junto con el atacante. Configura el módulo de IP real con los rangos oficiales de Cloudflare antes de activar cualquier regla de bloqueo basada en logs.

Lo que no se puede cerrar en el firewall

Algunas integraciones requieren un endpoint público. El webhook de la API oficial de WhatsApp es un ejemplo que operamos todos los días en Voyia: Meta necesita llegar a tu servidor. Aquí la protección sale del firewall y va a la aplicación: validar la firma X-Hub-Signature-256 de cada solicitud, aplicar un límite de velocidad (rate limit) y rechazar lo que no esté firmado. Con el WAF de Cloudflare delante, aún se pueden bloquear bots y picos antes de que lleguen al servidor.

Actualizaciones: sistema operativo, PHP y base de datos

Es el elemento con mayor retorno y el más abandonado del hardening de servidor Linux en empresas sin sysadmin. La tabla a continuación muestra por qué la versión es tan importante como la configuración.

Componente	Situación en septiembre de 2026	Qué hacer
Ubuntu 20.04 LTS	Soporte estándar finalizado el 31/05/2025 (solo ESM de pago)	Migrar a 24.04 LTS
Ubuntu 22.04 LTS	Soporte estándar hasta abril de 2027	Planificar migración para 2027
Debian 11	LTS finalizado el 31/08/2026	Migrar ya
Debian 12	En LTS hasta el 30/06/2028	Soportado, planificar Debian 13
PHP 8.1	Fin de vida el 31/12/2025	Actualizar la aplicación
PHP 8.2	Solo seguridad, hasta el 31/12/2026	Migrar antes de fin de año
MySQL 8.0	Fin de vida en abril de 2026	Migrar a 8.4 LTS

Fuentes: ciclo de lanzamientos de Ubuntu, anuncio del fin de Debian 11 LTS y versiones soportadas de PHP.

Actualización automática: actívala, pero entiende el límite

En Ubuntu, unattended-upgrades viene activo y aplica solo actualizaciones de seguridad una vez al día. Es una buena base. El límite: no reinicia el servidor por defecto. Las correcciones de kernel y de bibliotecas como glibc y OpenSSL solo son efectivas después del reinicio o del restart de los servicios. Verifica el archivo /var/run/reboot-required y programa reinicios en una ventana combinada.

Cuándo NO actualizar solo

En el hardening de servidor Linux, una regla es: las actualizaciones de versión mayor — PHP 8.1 a 8.3, MySQL 8.0 a 8.4, Ubuntu 22.04 a 24.04 — nunca deben ser automáticas. Un plugin, extensión o código antiguo puede romperse. El camino seguro es levantar un nuevo servidor en paralelo, validar en staging y hacer el cambio, como describimos en la guía para migrar Moodle de servidor sin perder datos. Sirve para cualquier sistema, no solo para Moodle.

PHP y servidor web: lo que la aplicación expone

Gran parte de las invasiones en sitios PHP no entran por el sistema operativo: entran por el código, por un plugin desactualizado o por una subida de archivos mal validada. El hardening de servidor Linux no arregla código malo, pero limita el daño.

Configuraciones de PHP que siempre son válidas

• expose_php = Off y display_errors = Off en producción. Un mensaje de error en pantalla revela la ruta del archivo, la versión y, a veces, credenciales.
• allow_url_include = Off. No hay una razón moderna para incluir código por URL.
• Un pool PHP-FPM por aplicación, cada uno con su usuario. Si un sitio web cae, el vecino no cae con él.
• Bloquear la ejecución de PHP en la carpeta de uploads. Es por ahí por donde entra el archivo .php disfrazado de imagen.
• open_basedir restringiendo PHP a las carpetas de la propia aplicación.

Cuidado con el disable_functions copiado de internet

Listas predefinidas que deshabilitan exec, shell_exec y proc_open aparecen en todos los tutoriales. Funcionan en sitios institucionales simples, pero rompen recursos reales: Moodle, por ejemplo, llama a binarios externos para tareas como la conversión de documentos y el cálculo del uso de disco. Ajusta la lista a la aplicación, no al revés. Los requisitos, costes y errores del alojamiento Moodle muestran cómo la pila de este tipo de sistema requiere una configuración específica.

En el servidor web

Elimina la firma de versión (server_tokens off en Nginx), fuerza HTTPS con HSTS, deshabilita el listado de directorios y bloquea el acceso a archivos sensibles como .env, .git y copias de seguridad .sql olvidadas en la raíz. Un certificado SSL renovado automáticamente por Let's Encrypt elimina el susto del sitio web "no seguro" un lunes.

Base de datos: fuera de internet, siempre

No hay motivo para que un MySQL, MariaDB o PostgreSQL de un sitio web o sistema empresarial acepte conexiones desde internet. Aun así, una base de datos expuesta es uno de los hallazgos más frecuentes cuando realizamos hardening de servidor Linux en un entorno heredado.

La checklist de la base de datos

• Escuchar solo en 127.0.0.1 o en la red privada (bind-address en MySQL/MariaDB, listen_addresses en PostgreSQL).
• Un usuario por aplicación, con permiso solo en la propia base de datos. La aplicación no usa el root de la base de datos.
• Contraseñas fuertes y fuera del código versionado. Una credencial en un repositorio Git es una credencial filtrada.
• Acceso administrativo por túnel SSH, nunca abriendo el puerto 3306 "solo por un día".
• Eliminar usuarios anónimos y bases de datos de prueba que algunas instalaciones crean.
• Copia de seguridad de la base de datos separada de la copia de seguridad de archivos, con un dump consistente y una copia fuera del servidor.

Redis y similares

Redis sin contraseña escuchando en una interfaz pública es una invitación. Fue diseñado para una red de confianza. Déjalo en localhost, activa la autenticación y deshabilita comandos peligrosos que la aplicación no use.

Logs, monitorización y copia de seguridad: el hardening que demuestra que funcionó

Un servidor reforzado y sin monitorización es un servidor en el que solo descubres el problema por el cliente. Esta etapa cierra el ciclo del hardening de servidor Linux y muestra si las otras funcionaron.

• Logs centralizados y retenidos. Autenticación (/var/log/auth.log o journalctl), servidor web y aplicación. Si el servidor se ve comprometido, un log solo local puede ser borrado.
• Alerta que llega a alguien. Uptime externo, disco por encima del 85%, CPU bloqueada, error 500 en serie, inicio de sesión SSH desde una nueva IP. Una alerta que va a un correo electrónico que nadie lee no es una alerta.
• Copia de seguridad 3-2-1, cifrada y probada. Tres copias, dos medios, una fuera del servidor. Y la parte que casi nadie hace: restaurar de verdad, cada mes, en un entorno de prueba. Una copia de seguridad que nunca ha sido restaurada es una hipótesis.

Checklist resumido y esfuerzo estimado

Etapa	Esfuerzo inicial	Rutina
Inventario, snapshot y acceso de emergencia	1 a 2 h	Con cada cambio importante
SSH y usuarios	1 h	Revisión trimestral de claves
Firewall y WAF	1 a 3 h	Con cada nuevo servicio
Actualizaciones y reboots	1 h de configuración	Semanal, con ventana
PHP y servidor web	2 a 4 h	Con cada nueva aplicación
Base de datos	1 a 2 h	Revisión trimestral
Logs, alertas y copia de seguridad probada	3 a 6 h	Mensual (prueba de restauración)

Las horas anteriores son nuestra estimación de hardening de servidor Linux para un servidor web típico con una o dos aplicaciones, realizado por alguien que ya conoce el camino. Para quien está aprendiendo, multiplica por tres. Y el coste real no es el día de la configuración: es la rutina que debe suceder cada semana, durante años, sin que nadie lo olvide.

Aquí es donde la cuenta cambia para quien no tiene sysadmin. Contratar a un profesional senior a tiempo completo para cuidar uno o dos servidores rara vez se amortiza. Dejar la rutina al desarrollador de la aplicación suele funcionar hasta el primer mes de prisa. Comparamos el coste de operar solo y externalizar, con números, en Moodle en AWS vs alojamiento gestionado — el razonamiento es válido para cualquier sistema.

Cómo Agathas Web resuelve esto

Todo lo que se encuentra en esta checklist de hardening de servidor Linux forma parte del estándar de nuestro alojamiento gestionado. No es un paquete extra: es el punto de partida de todo entorno que asumimos.

Qué está incluido

• Hardening del sistema operativo en la entrega, con fail2ban, MFA obligatorio y auditoría de logs.
• Cloudflare WAF con reglas personalizadas, mitigación de DDoS y bloqueo de bots.
• Actualizaciones de sistema, runtime (PHP, Node, Python), base de datos y plugins críticos, probadas en staging y aplicadas en ventana combinada. Parche crítico en hasta 72 horas tras la CVE pública, por contrato.
• Copia de seguridad diaria e incremental, offsite y cifrada con AES-256, con restauración probada mensualmente.
• Monitorización 24/7 con Grafana, Prometheus, Sentry y UptimeRobot, y alertas en el WhatsApp del equipo técnico.
• SSL Let's Encrypt renovado automáticamente en todos los dominios.
• SLA contractual: 99,9% de uptime, respuesta en hasta 15 minutos para incidente crítico y resolución en hasta 2 horas.

Cómo funciona en la práctica

Comenzamos con un diagnóstico gratuito de la infraestructura actual: en hasta 3 días hábiles señalamos riesgos, versiones sin soporte y un coste optimizado. Si tiene sentido continuar, migramos el sitio web, la base de datos, los correos electrónicos y el DNS en hasta 7 días hábiles, con validación en staging antes del cambio y el entorno antiguo mantenido durante 30 días como plan de rollback. Quien atiende tu llamada es el mismo ingeniero que configuró el servidor.

Cuánto cuesta y cómo contratar

Los sitios web institucionales y blogs cuestan entre 250 € y 500 € al mes; e-commerce y SaaS, entre 600 € y 2.500 € al mes. La configuración inicial va de 800 € a 3.500 €, según la complejidad. El contrato es mensual, sin permanencia, con 30 días de preaviso para cancelar. Si tu empresa también necesita a alguien para decidir la arquitectura y las prioridades de TI, la consultoría con un rol de CTO as a Service complementa la operación.

Conclusión: la checklist solo funciona si alguien la ejecuta cada mes

El hardening de servidor Linux comienza con un día de configuración y continúa con años de disciplina. Clave en lugar de contraseña, firewall denegando por defecto, base de datos fuera de internet, versiones soportadas, logs y copia de seguridad probada. Nada de esto es secreto. Lo que falta en la mayoría de las empresas es alguien con tiempo y responsabilidad para mantener la rutina.

Si tienes el servidor y no tienes a esa persona, el siguiente paso es simple: solicita el diagnóstico gratuito del alojamiento gestionado de Agathas Web. Recibirás un retrato del riesgo actual de tu servidor y decidirás, con datos en mano, si vale la pena hacerlo tú mismo o dejarlo en manos de quienes lo hacen todos los días.