Hardening de Servidores Web: Apache vs. Nginx

📘 Este artículo forma parte de nuestra Guía Completa de Ciberseguridad 2026 y de nuestra Guía Completa de Servidores y Virtualización. Si quieres entender el panorama completo de seguridad y administración de servidores, esas guías son tu punto de partida.

Proteger un servidor web no consiste simplemente en instalar Apache o Nginx y activar HTTPS. Un servidor conectado a Internet puede estar expuesto a intentos de fuerza bruta, explotación de vulnerabilidades, escaneo automatizado, abuso de aplicaciones, robo de credenciales, ataques contra WordPress y errores de configuración.

El hardening de servidores web es el conjunto de técnicas utilizadas para reducir esa superficie de ataque y conseguir que el sistema exponga únicamente los servicios, permisos y funcionalidades que realmente necesita.

En esta guía vamos a analizar cómo aplicar hardening tanto en Apache como en Nginx, qué diferencias existen entre ambos y qué medidas conviene aplicar también a Linux, SSH, PHP, firewall, logs, copias de seguridad y monitorización.

Importante: no existe una configuración universal de hardening. Antes de aplicar cambios en producción, comprueba siempre la compatibilidad con tu aplicación, realiza una copia de seguridad y valida la configuración antes de reiniciar el servicio.

¿Qué es el hardening de un servidor web?

El término hardening hace referencia al proceso de reforzar la seguridad de un sistema reduciendo sus posibilidades de ser comprometido.

En un servidor web puede implicar:

• Desactivar servicios innecesarios.
• Eliminar módulos que no se utilizan.
• Limitar permisos de archivos y directorios.
• Ocultar información innecesaria del servidor.
• Configurar correctamente HTTPS y TLS.
• Añadir cabeceras de seguridad HTTP.
• Proteger SSH.
• Configurar un firewall.
• Utilizar Fail2ban cuando sea apropiado.
• Mantener actualizado el sistema.
• Separar servicios y privilegios.
• Proteger PHP y PHP-FPM.
• Monitorizar logs.
• Mantener copias de seguridad.
• Realizar auditorías periódicas.

Por tanto, hardening no significa únicamente modificar Apache o Nginx. El servidor web forma parte de una cadena de seguridad mucho mayor.

Si quieres ampliar esta parte, puedes consultar nuestra guía sobre las mejores prácticas para la configuración segura de servidores web.

Apache vs Nginx: ¿qué servidor necesita más hardening?

Una idea importante es evitar la conclusión de que Apache es inseguro o que Nginx es automáticamente más seguro.

Ambos pueden configurarse correctamente o de forma insegura.

La seguridad depende de factores como:

• versión utilizada;
• módulos instalados;
• configuración;
• sistema operativo;
• permisos;
• aplicaciones desplegadas;
• PHP;
• firewall;
• autenticación;
• actualizaciones;
• monitorización.

Apache

Apache utiliza un sistema muy flexible basado en módulos y permite configurar determinadas reglas mediante .htaccess.

Esto facilita muchas configuraciones, especialmente en determinados entornos de hosting, pero también significa que hay que controlar cuidadosamente qué módulos y funcionalidades están activos.

Nginx

Nginx utiliza una arquitectura diferente y suele utilizarse como servidor web, reverse proxy o balanceador.

Su configuración se centraliza normalmente en archivos de configuración del servidor y no utiliza .htaccess.

Esto permite tener una configuración muy controlada, pero no elimina la necesidad de realizar hardening.

Conclusión: el objetivo no es determinar qué servidor es «más seguro», sino configurar correctamente el servidor que realmente necesita tu infraestructura.

1. Mantén actualizado el sistema operativo

Antes de endurecer Apache o Nginx, hay que asegurar la base sobre la que funcionan.

En Debian o Ubuntu:

sudo apt update
sudo apt upgrade

También conviene revisar periódicamente los paquetes que tienen actualizaciones de seguridad.

Puedes comprobar qué versión del kernel estás utilizando:

uname -r

Y revisar los servicios activos:

systemctl --type=service --state=running

La regla es sencilla:

Un servidor correctamente configurado pero sin actualizar puede seguir siendo vulnerable.

Para profundizar en la administración de servidores Linux, consulta nuestra Guía Completa de Linux.

2. Desactiva servicios que no necesites

Cada servicio escuchando en un puerto puede aumentar la superficie de ataque.

Comprueba qué puertos están abiertos:

sudo ss -tulpn

También puedes revisar los sockets:

sudo ss -lntup

Si encuentras un servicio que no necesitas, comprueba primero qué función desempeña antes de desactivarlo.

Por ejemplo:

sudo systemctl status nombre-servicio

Y, si realmente no es necesario:

sudo systemctl disable --now nombre-servicio

No conviene desactivar servicios a ciegas. Un cambio aparentemente pequeño puede dejar inutilizada una aplicación.

3. Protege SSH

SSH suele ser uno de los servicios más atacados en servidores Linux expuestos a Internet.

Algunas medidas habituales son:

• utilizar autenticación mediante claves;
• evitar el acceso directo de root;
• limitar usuarios autorizados;
• desactivar métodos de autenticación que no sean necesarios;
• utilizar MFA cuando la infraestructura lo permita;
• restringir el acceso mediante firewall o VPN cuando sea posible.

Puedes comprobar los últimos accesos:

last

Y los intentos fallidos:

sudo lastb

También es recomendable revisar los logs de autenticación.

El objetivo no es simplemente cambiar el puerto SSH. Cambiar el puerto puede reducir ruido automatizado, pero no sustituye una configuración de autenticación segura ni un firewall correctamente configurado.

4. Configura correctamente el firewall

Un servidor web normalmente no necesita tener decenas de puertos accesibles desde Internet.

En una configuración típica podrían ser necesarios:

• HTTP: 80
• HTTPS: 443
• SSH: 22, preferiblemente restringido cuando sea posible

Con UFW puedes comprobar el estado:

sudo ufw status verbose

Una configuración básica podría ser:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Antes de activar reglas relacionadas con SSH, asegúrate de permitir tu método de acceso para no bloquearte fuera del servidor.

Para ampliar la configuración de firewall, consulta Cómo configurar un firewall en Linux con UFW y firewalld y Guía para instalar y configurar firewall en servidor Debian 11.

5. Hardening de Apache

Apache permite realizar diferentes ajustes para reducir información expuesta y limitar funcionalidades innecesarias.

5.1 Desactiva módulos que no utilices

Puedes comprobar los módulos cargados:

apache2ctl -M

En Debian y Ubuntu, algunos módulos pueden desactivarse mediante:

sudo a2dismod nombre_modulo

Por ejemplo, si un módulo no es necesario, desactivarlo evita mantener funcionalidad innecesaria.

Sin embargo, no desactives módulos sin comprobar primero qué aplicaciones dependen de ellos.

Después de modificar Apache:

sudo apachectl configtest

Si aparece:

Syntax OK

puedes continuar con el reinicio o recarga.

5.2 Oculta información de Apache

Dos directivas tradicionales son:

ServerTokens Prod
ServerSignature Off

Estas opciones reducen la cantidad de información que Apache muestra en determinadas respuestas y páginas generadas por el servidor.

Ocultar información no sustituye otras medidas de seguridad, pero evita revelar datos innecesarios.

5.3 Desactiva el listado de directorios

No deberías permitir que un visitante pueda navegar automáticamente por directorios que no están destinados a ser públicos.

En Apache:

Options -Indexes

Esto evita el listado automático de directorios cuando no existe un archivo índice.

5.4 Revisa .htaccess

Una de las características más conocidas de Apache es .htaccess.

Es muy flexible, pero también puede complicar el mantenimiento de la configuración.

Revisa periódicamente:

• reglas de redirección;
• permisos;
• reglas de acceso;
• configuraciones antiguas;
• código añadido por plugins;
• reglas que ya no utiliza la aplicación.

En WordPress es especialmente importante revisar .htaccess cuando se realizan cambios de seguridad o migraciones.

6. Hardening de Nginx

Nginx también permite reducir información expuesta y controlar cuidadosamente el tráfico.

6.1 Oculta la versión

Una de las medidas más sencillas:

server_tokens off;

Esto evita mostrar normalmente la versión exacta de Nginx en determinadas respuestas.

No debe confundirse con una protección contra vulnerabilidades. Si una versión contiene una vulnerabilidad, ocultar su número no la corrige.

6.2 Bloquea archivos ocultos cuando corresponda

Una configuración habitual puede impedir el acceso a determinados archivos ocultos:

location ~ /\.(?!well-known) {
    deny all;
}

La excepción de .well-known es importante porque determinados mecanismos, como los retos de Let’s Encrypt, utilizan esa ruta.

No copies esta regla sin revisar antes qué aplicaciones y servicios utilizan archivos ocultos.

6.3 Protege archivos sensibles

Hay que evitar que archivos de configuración, copias de seguridad o archivos temporales puedan descargarse desde Internet.

Ejemplos de archivos que nunca deberían estar expuestos públicamente:

.env
.git/
wp-config.php.bak
backup.sql
database.sql
config.php~

Para más información sobre cómo evitar exponer información en WordPress, consulta Cómo evitar ataques XML-RPC en PHP y WordPress.

7. Permisos y propietarios de archivos

Uno de los errores más habituales al realizar hardening es aplicar permisos demasiado agresivos de forma recursiva.

Por ejemplo:

chmod -R 750 /var/www/html/

No es una regla universal.

Una aplicación web puede necesitar permisos diferentes para:

• archivos;
• directorios;
• archivos temporales;
• uploads;
• cachés;
• sockets;
• procesos PHP-FPM.

En muchos entornos Linux y WordPress se utiliza como punto de partida algo parecido a:

Directorios: 755
Archivos:    644

Pero debe adaptarse al servidor.

También es importante comprobar el propietario:

ls -la /var/www/

Y evitar que todos los archivos del sistema web sean escribibles por el proceso web.

El principio fundamental es:

El proceso web debe tener solamente los permisos que necesita.

Para profundizar, consulta Control de acceso en Linux: mejores prácticas de permisos y usuarios.

8. HTTPS y TLS

HTTPS ya no debería considerarse una característica opcional para una web pública.

Permite proteger las comunicaciones entre cliente y servidor mediante TLS.

Una opción habitual es Let’s Encrypt junto con Certbot.

Una vez configurado HTTPS, conviene:

• redirigir HTTP a HTTPS;
• mantener los certificados actualizados;
• utilizar protocolos TLS modernos;
• evitar configuraciones criptográficas obsoletas;
• comprobar periódicamente la configuración.

Para ampliar la configuración de HTTPS, consulta Cómo implementar el protocolo HTTPS correctamente y Guía completa para configurar SSL en Nginx.

HSTS

Una vez comprobado que todo funciona correctamente mediante HTTPS, puede utilizarse:

add_header Strict-Transport-Security "max-age=31536000" always;

Pero hay que tener cuidado con:

includeSubDomains
preload

porque pueden afectar a todos los subdominios y requieren que toda la infraestructura sea compatible con HTTPS.

9. Cabeceras de seguridad HTTP

Las cabeceras HTTP pueden ayudar a controlar determinados comportamientos del navegador.

Por ejemplo:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

También puede utilizarse Content Security Policy:

add_header Content-Security-Policy "default-src 'self';" always;

Pero aquí hay que hacer una advertencia importante:

No conviene copiar una CSP genérica a producción sin comprobar primero los recursos que utiliza la web.

Una política demasiado restrictiva puede bloquear:

• JavaScript;
• CSS;
• fuentes;
• imágenes;
• iframes;
• Google Analytics;
• publicidad;
• servicios externos;
• plugins de WordPress.

La CSP debe construirse de acuerdo con la aplicación real.

10. PHP y PHP-FPM también forman parte del hardening

Instalar Nginx o Apache correctamente no sirve de mucho si PHP está mal configurado.

Algunas medidas que conviene revisar son:

• versión de PHP soportada;
• actualización de PHP;
• configuración de PHP-FPM;
• pools separados cuando sea necesario;
• límites de memoria;
• límites de subida;
• exposición de información;
• permisos del socket;
• procesos PHP ejecutándose con privilegios mínimos.

Una configuración de PHP puede incluir:

expose_php = Off

Esto reduce determinada información expuesta por PHP.

También puede ser interesante revisar funciones potencialmente peligrosas, pero no recomiendo desactivarlas indiscriminadamente, porque determinadas aplicaciones pueden necesitarlas.

11. Protege WordPress y otras aplicaciones web

El servidor web puede estar perfectamente configurado y aun así una aplicación vulnerable puede convertirse en el punto de entrada.

En WordPress conviene mantener actualizados:

• WordPress;
• plugins;
• temas;
• PHP;
• componentes del servidor.

También es importante revisar plugins abandonados y eliminar aquellos que ya no se utilizan.

Para instalaciones WordPress con Nginx, consulta Cómo instalar WordPress con Nginx en Debian 10 y 11 y WordPress en Ubuntu Server 24.04 con Nginx.

También puede ser útil revisar cómo evitar ataques XML-RPC en PHP y WordPress.

12. Fail2ban contra ataques repetitivos

Fail2ban puede analizar determinados logs y bloquear temporalmente direcciones IP que realizan demasiados intentos fallidos.

Es especialmente útil para servicios como:

• SSH;
• determinados paneles;
• autenticación;
• servicios con patrones claros de fuerza bruta.

No debe considerarse un sustituto del firewall ni de una aplicación segura.

Su función es reducir determinados ataques repetitivos.

Puedes ampliar esta configuración en Cómo configurar y usar Fail2ban para proteger tu servidor Linux.

13. Rate limiting en Nginx

Nginx permite limitar determinadas peticiones.

Por ejemplo:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

Después puede aplicarse sobre una ubicación concreta:

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
}

Esto puede ayudar a reducir determinados ataques automatizados contra endpoints concretos.

Pero hay que utilizarlo con cuidado.

Un límite demasiado agresivo puede bloquear usuarios legítimos, APIs o servicios que realizan muchas peticiones legítimas.

Por eso es preferible aplicar rate limiting sobre puntos sensibles, en lugar de limitar indiscriminadamente todo el sitio.

14. Logs y monitorización

Un servidor seguro también debe permitir detectar lo que está ocurriendo.

Entre los registros más importantes están:

access.log
error.log
auth.log
syslog

En sistemas modernos también puede utilizarse:

journalctl

Por ejemplo:

sudo journalctl -u nginx

o:

sudo journalctl -u apache2

Busca patrones como:

• numerosos errores 404;
• intentos repetidos de login;
• peticiones sospechosas;
• accesos a archivos inexistentes;
• errores 500;
• picos anormales de tráfico;
• cambios inesperados.

En nuestra web tienes una guía específica sobre análisis de registros en Linux y detección de comportamientos sospechosos.

También puedes complementar el sistema con nuestras guías de monitorización: Las mejores herramientas de monitorización de servidores y Netdata.

15. Monitorización de recursos

La seguridad también está relacionada con la disponibilidad.

Un servidor que se queda sin:

• RAM;
• CPU;
• espacio de disco;
• conexiones;
• descriptores de archivos;

puede dejar de responder aunque no exista un ataque directo.

Conviene monitorizar:

free -h
df -h
uptime
top
ss -s

Para infraestructuras más grandes pueden utilizarse sistemas como Zabbix, Nagios, Grafana o Netdata.

En nuestro blog tienes contenido dedicado a instalar y configurar Nagios para monitorizar un servidor y a instalar Zabbix con Nginx en Debian.

16. Copias de seguridad

El hardening no impide absolutamente todos los incidentes.

Por eso necesitas un sistema de recuperación.

Una estrategia de backups debería contemplar:

• archivos;
• bases de datos;
• configuraciones;
• certificados cuando sea necesario;
• restauraciones verificadas.

Un backup que nunca se ha probado no debería considerarse completamente fiable.

Puedes ampliar este apartado con La importancia de los backups y cómo implementar una estrategia efectiva y Cómo hacer un backup seguro y automatizado en Linux.

17. WAF: ¿ModSecurity o NAXSI?

Un Web Application Firewall puede añadir otra capa de protección.

ModSecurity

ModSecurity es una de las opciones conocidas para Apache y también puede integrarse en determinados escenarios con otros servidores.

Puede utilizar reglas para detectar determinados patrones de ataques web.

NAXSI

NAXSI es una solución orientada específicamente a Nginx.

Un WAF puede ser útil, pero no sustituye:

• actualizaciones;
• autenticación segura;
• permisos;
• validación de entradas;
• firewall;
• backups;
• monitorización.

El WAF debe considerarse una capa adicional, no una armadura mágica.

18. AppArmor y SELinux

El servidor web no debería tener libertad absoluta dentro del sistema operativo.

Tecnologías como:

• AppArmor;
• SELinux;

pueden limitar las acciones que puede realizar un proceso incluso después de un posible compromiso.

El concepto es importante:

Si un proceso es comprometido, sus privilegios deberían limitar el daño que puede causar.

Puedes ampliar esta parte con nuestra Introducción a SELinux: cómo asegurar el acceso.

19. Auditoría de seguridad

Después de modificar la configuración conviene comprobar si realmente hemos mejorado la seguridad.

Una herramienta interesante para Linux es Lynis:

sudo apt install lynis
sudo lynis audit system

También puedes comprobar los puertos:

sudo ss -tulpn

Y revisar los servicios:

systemctl --type=service --state=running

Para Apache:

sudo apachectl configtest

Para Nginx:

sudo nginx -t

Y finalmente comprobar las cabeceras:

curl -I https://tudominio.com

No se trata solamente de instalar herramientas de auditoría. Hay que interpretar sus resultados y corregir las configuraciones relevantes.

Para una revisión más amplia, consulta nuestra Auditoría de seguridad de una web: guía paso a paso y Cómo realizar un análisis de vulnerabilidades paso a paso.

Apache vs Nginx: comparación de hardening

La tabla deja una conclusión importante: la seguridad no depende únicamente del servidor web elegido.

Checklist de hardening de un servidor web

Antes de considerar terminado el proceso, revisa:

Sistema operativo

• Sistema actualizado.
• Kernel actualizado.
• Servicios innecesarios desactivados.
• Usuarios revisados.
• Permisos correctamente configurados.

SSH

• Acceso root directo desactivado cuando no sea necesario.
• Claves SSH configuradas.
• Usuarios autorizados revisados.
• Acceso restringido cuando sea posible.

Firewall

• Solo están abiertos los puertos necesarios.
• SSH está restringido cuando es posible.
• HTTP/HTTPS funcionan correctamente.
• No existen servicios innecesariamente expuestos.

Apache/Nginx

• Versión no expuesta innecesariamente.
• Módulos revisados.
• Archivos sensibles protegidos.
• Directorios sin listado.
• Configuración validada.
• Rate limiting en puntos sensibles cuando procede.

HTTPS

• Certificado válido.
• HTTP redirige correctamente a HTTPS.
• TLS actualizado.
• HSTS configurado cuando corresponde.

Aplicación

• WordPress/CMS actualizado.
• Plugins actualizados.
• Temas actualizados.
• Componentes innecesarios eliminados.
• PHP actualizado.

Seguridad adicional

• Fail2ban configurado cuando procede.
• Logs revisados.
• Monitorización activa.
• Backups automáticos.
• Restauración de backups probada.
• Auditoría periódica.

Errores frecuentes al hacer hardening

Error 1: copiar una configuración de Internet

Una configuración que funciona perfectamente en un servidor puede romper otro.

Cada infraestructura tiene diferentes:

• aplicaciones;
• versiones;
• plugins;
• puertos;
• usuarios;
• servicios;
• necesidades.

Error 2: bloquear demasiado

Un servidor extremadamente restrictivo puede dejar de funcionar.

El objetivo no es bloquear todo.

El objetivo es permitir solamente lo necesario.

Error 3: pensar que ocultar la versión soluciona vulnerabilidades

server_tokens off o ServerTokens Prod reducen información expuesta, pero no actualizan el software.

Error 4: confiar exclusivamente en Fail2ban

Fail2ban ayuda contra determinados patrones de ataques repetitivos, pero no corrige vulnerabilidades de aplicaciones.

Error 5: olvidar los backups

La seguridad también consiste en poder recuperarse después de un incidente.

Error 6: modificar producción sin probar

Antes de recargar:

sudo nginx -t

o:

sudo apachectl configtest

Y, cuando sea posible, realiza los cambios primero en un entorno de pruebas.

¿Apache o Nginx?

La elección entre Apache y Nginx no debería basarse exclusivamente en seguridad.

Ambos pueden formar parte de una infraestructura segura si están correctamente configurados, actualizados y monitorizados.

Apache puede resultar especialmente interesante cuando necesitas su ecosistema de módulos y .htaccess.

Nginx resulta muy habitual como servidor web, reverse proxy y punto frontal de aplicaciones.

En ambos casos, el verdadero hardening se consigue trabajando varias capas:

                    INTERNET
                       │
                    FIREWALL
                       │
                 ┌─────┴─────┐
                 │ HTTPS/TLS │
                 └─────┬─────┘
                       │
                Apache / Nginx
                       │
                  PHP-FPM / App
                       │
                   Base de datos
                       │
                ┌──────┴──────┐
                │ Linux       │
                │ SSH         │
                │ AppArmor    │
                │ Logs        │
                │ Backups     │
                └─────────────┘

La seguridad efectiva aparece cuando todas estas capas trabajan juntas.

Preguntas frecuentes sobre hardening

¿Qué es el hardening de un servidor web?

Es el proceso de reducir la superficie de ataque de un servidor mediante configuraciones de seguridad, eliminación de servicios innecesarios, control de permisos, actualizaciones, firewall, protección de aplicaciones y monitorización.

¿Es Nginx más seguro que Apache?

No existe una respuesta universal. Ambos pueden configurarse de forma segura o insegura. La seguridad depende de la configuración, las versiones, los módulos, las aplicaciones y las medidas de protección adicionales.

¿Es suficiente utilizar HTTPS?

No. HTTPS protege las comunicaciones, pero no evita por sí mismo vulnerabilidades en WordPress, PHP, plugins, configuraciones, credenciales o servicios.

¿Necesito Fail2ban?

Puede ser útil para determinados servicios y patrones de fuerza bruta, especialmente SSH. No sustituye al firewall ni a las actualizaciones.

¿Debo utilizar un WAF?

Depende de la aplicación y del nivel de protección que necesites. Un WAF puede proporcionar una capa adicional, pero no sustituye las medidas básicas de seguridad.

¿Qué permisos debo utilizar en /var/www?

No existe un único valor válido para todas las aplicaciones. Los permisos deben adaptarse a la aplicación, al usuario del servidor web y a las necesidades de escritura.

¿Cómo puedo comprobar la seguridad del servidor?

Puedes combinar revisión de configuración, puertos, logs y servicios con herramientas de auditoría como Lynis y pruebas específicas de la aplicación.

¿Cada cuánto tiempo debería revisar el hardening?

No existe un intervalo universal. Conviene revisar la configuración después de cambios importantes, actualizaciones de infraestructura, instalación de nuevos servicios o modificaciones de la aplicación, además de realizar revisiones periódicas.

Conclusión

El hardening de servidores web no consiste en copiar diez líneas de configuración de Apache o Nginx y dar el trabajo por terminado.

Es un proceso continuo que debe cubrir toda la infraestructura:

Linux + SSH + firewall + Apache/Nginx + TLS + PHP + aplicación + permisos + logs + monitorización + backups.

Apache y Nginx pueden utilizarse en servidores seguros siempre que se mantengan actualizados y se configure cada componente siguiendo el principio de mínimo privilegio.

Si estás administrando un servidor Linux, empieza por reducir los servicios expuestos, proteger SSH, configurar el firewall, actualizar el sistema y endurecer Apache o Nginx. Después añade monitorización, Fail2ban cuando corresponda, backups y auditorías periódicas.

La seguridad no es una única configuración.

Es una cadena de capas.

Y en esa cadena, la mejor configuración es aquella que reduce la superficie de ataque sin romper aquello que el servidor necesita hacer.

📘 ¿Quieres seguir profundizando?

• Lee nuestra Guía Completa de Ciberseguridad 2026 para una visión integral.
• Consulta la Guía Completa de Servidores y Virtualización para administración avanzada.
• Aprende sobre Zero Trust para arquitecturas modernas.