Hardening de NGINX en 2026: configuración segura básica paso a paso

NGINX es uno de los servidores web más utilizados del mundo. Su rendimiento y flexibilidad lo convierten en una pieza central de muchas soluciones modernas. Precisamente por ello también es un objetivo habitual de escaneos automáticos en busca de debilidades, auditorías de seguridad y ataques oportunistas.

Por defecto, un servidor NGINX funciona perfectamente, pero suele exponer más información de la necesaria o permitir el uso de configuraciones criptográficas antiguas que hoy ya no se consideran seguras. El resultado son avisos en auditorías, incumplimiento de estándares (OWASP, PCI DSS) y una superficie de ataque mayor de la realmente necesaria para ofrecer el servicio.

En esta entrada, después de ver la semana pasada como realizar hardening de SSH en Rocky Linux, veremos cómo aplicar una hardenización básica pero sólida de NGINX, centrada en tres pilares clave:

• Uso de TLS moderno y cifrados fuertes
• Aplicación de cabeceras HTTP de seguridad
• Reducción de información expuesta innecesariamente

Todo ello mediante cambios sencillos en la configuración que permiten mejorar significativamente la seguridad de un servidor en producción y alinearlo con las buenas prácticas actuales.

Ocultar la versión de NGINX: menos información, menos riesgo

Uno de los errores más habituales es ofrecer la versión exacta de NGINX, un dato muy valioso para posibles atacantes.

¿Qué problema existe?

Por defecto, NGINX incluye su versión exacta en las respuestas HTTP. Por ejemplo:

Server: nginx/1.24.0

Esto puede parecer inofensivo, pero para un atacante es una información muy útil: permite identificar rápidamente si esa versión concreta tiene vulnerabilidades conocidas y potencialmente explotables.

Cómo solucionarlo

Dentro del bloque http {} de la configuración global se debe agregar:

server_tokens off;

Introducir este cambio en la configuración es importante ya que ofrece las siguientes ventajas:

• Oculta la versión de NGINX en headers y páginas de error
• Reduce la efectividad de ataques automatizados
• No afecta al funcionamiento ni al rendimiento

No convierte el servidor en invulnerable, pero elimina información innecesaria, que es uno de los principios básicos del hardening.

Forzar el uso de protocolos TLS modernos

Algunas versiones antiguas de TLS ya no se consideran seguras.

El problema de los protocolos antiguos

Protocolos como TLS 1.0 y TLS 1.1 están oficialmente obsoletos. Aunque en algunos sistemas todavía aparecen en configuraciones por defecto, hoy representan un riesgo claro y suelen ser detectados en cualquier auditoría de seguridad.

Configuración recomendada

Para solucionar el problema se debe agrega las siguientes opciones dentro del bloque server {}:

ssl_protocols TLSv1.2 TLSv1.3;

Agregar esta línea a la configuración es clave, ya que su inclusión ofrece las siguientes ventajas:

• Elimina protocolos criptográficamente débiles
• Garantiza conexiones seguras por defecto
• Es totalmente compatible con navegadores y clientes modernos

En 2026, permitir TLS 1.0 o TLS 1.1 ya no es una cuestión de compatibilidad, sino de deuda técnica de seguridad.

Uso de cifrados fuertes y controlados por el servidor

Utilizar suites criptográficas débiles puede comprometer la seguridad incluso cuando se usan versiones modernas de TLS.

Configuración

Para solucionar el problema se debe agrega las siguientes opciones dentro del bloque server {}:

ssl_ciphers HIGH:!aNULL:!MD5:!RC4:!3DES;
ssl_prefer_server_ciphers on;

En donde cada uno de los elementos que se agregan al impactan de la siguiente forma en la seguridad de NGINX:

• HIGH: solo se permiten cifrados considerados fuertes
• !aNULL: excluye cifrados sin autenticación
• !MD5, !RC4, !3DES: elimina algoritmos débiles o rotos
• ssl_prefer_server_ciphers on: el servidor decide qué cifrado usar, no el cliente

Siendo unos cambios que ofrecen las siguientes ventajas de seguridad:

• Evita negociaciones inseguras
• Reduce el riesgo de ataques como BEAST, POODLE o ataques de downgrade
• Asegura que incluso clientes mal configurados utilicen cifrados robustos

En este caso el servidor actúa como árbitro de seguridad, en lugar de delegar la decisión en el cliente.

Endurecer la gestión de sesiones TLS

Controlar adecuadamente las sesiones TLS también contribuye a mejorar la seguridad y el rendimiento del servidor.

Una configuración típica puede ser:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;
ssl_session_tickets off;

Mejorar la gestión de TLS, permite no solo mejorara la seguridad, sino que también el rendimiento. Entre otras, las ventajas que se obtienes son:

• Mejora el rendimiento en conexiones repetidas
• Reduce la exposición a ataques relacionados con la reutilización de sesiones
• ssl_session_tickets off evita problemas de seguridad asociados a tickets mal gestionados

Es un buen equilibrio entre seguridad y eficiencia, especialmente en entornos con tráfico recurrente.

Cabeceras HTTP de seguridad: defensa en profundidad

Las cabeceras HTTP no sustituyen a una aplicación bien diseñada, pero añaden capas adicionales de protección frente a ataques web comunes.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

Donde cada una de las cabeceras ofrece las siguientes protecciones:

• Strict-Transport-Security (HSTS): Obliga al navegador a utilizar HTTPS en futuras conexiones, evitando ataques de downgrade hacia HTTP.
• X-Frame-Options: DENY: Impide que la página sea cargada dentro de un iframe, lo que bloquea ataques de clickjacking.
• X-Content-Type-Options: nosniff: Evita que el navegador intente interpretar el contenido con un tipo MIME diferente al declarado, lo que reduce ciertos vectores de ataque.

Son cabeceras muy simples de aplicar, pero con un impacto de seguridad considerable.

Ejemplo completo de un bloque server {} endurecido

A continuación se recopilan las recomendaciones anteriores en un ejemplo de configuración de servidor HTTPS endurecido.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # Certificados TLS
    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;
    ssl_trusted_certificate /etc/ssl/certs/chain.crt;

    # Protocolos seguros
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cifrados
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4:!3DES;
    ssl_prefer_server_ciphers on;

    # Gestión de sesiones
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1h;
    ssl_session_tickets off;

    # Cabeceras de seguridad
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Pruebas y validación: el paso que no hay que saltarse

Una vez aplicada la nueva configuración, es fundamental comprobar que todo funciona correctamente.

Primero se puede verificar la sintaxis del archivo de configuración:

sudo nginx -t

Si la respuesta es correcta, se puede recargar el servicio para aplicar los cambios:

sudo systemctl reload nginx

A continuación conviene validar que las medidas de seguridad funcionan como se espera.

Comprobar protocolos TLS

Lo primero es verificar que las versiones antiguas de TLS han sido deshabilitadas:

openssl s_client -connect localhost:443 -tls1
openssl s_client -connect localhost:443 -tls1_1
openssl s_client -connect localhost:443 -tls1_2
openssl s_client -connect localhost:443 -tls1_3

Los dos primeros comandos deberían fallar, mientras que los dos últimos deberían establecer la conexión correctamente.

Revisar cabeceras HTTP

También se puede comprobar que el servidor envía las cabeceras de seguridad configuradas:

curl -k -I https://localhost

Salida esperada:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Server: nginx

Conclusiones

Con esta configuración básica de hardening, tu servidor NGINX:

1. Reduce significativamente la información expuesta
2. Fuerza el uso de TLS y cifrados modernos
3. Refuerza la seguridad de las sesiones TLS
4. Añade defensas eficaces contra ataques web comunes
5. Está preparado para superar auditorías internas y externas

Estas prácticas ya no pueden considerarse avanzadas: son el estándar mínimo esperado en 2026 para cualquier servidor web en producción.

En una próxima entrada profundizaremos en técnicas adicionales de hardening, como:

• OCSP stapling
• Content-Security-Policy
• rate limiting
• protección frente a bots y ataques de fuerza bruta

Nota: La imágenes de este artículo fueron generadas utilizando un modelo de inteligencia artificial.