Seguridad Esencial de Nginx: Mejores Prácticas y Preguntas Frecuentes de Solución de Problemas

La seguridad esencial de Nginx no es una sola configuración o un encabezado mágico. Es una colección de valores predeterminados cuidadosos: HTTPS, acceso estricto a archivos, comportamiento seguro del proxy, exposición limitada y registros que te ayudan a detectar problemas antes de que crezcan.

Esta FAQ cubre las preguntas que los equipos suelen hacer después de poner Nginx en línea y darse cuenta de que la configuración predeterminada es solo un punto de partida.

¿Cuáles Son las Primeras Configuraciones de Seguridad de Nginx que Debo Revisar?

Comienza con lo básico que reduce la exposición accidental. Estas configuraciones te protegen de errores comunes, no de ataques avanzados.

Primero, desactiva los tokens de versión:

server_tokens off;

Esto evita que Nginx anuncie su versión en páginas de error y encabezados. No hace que el servidor sea invisible, pero elimina detalles innecesarios.

Segundo, asegúrate de que tu raíz de documentos sea correcta. Un error común es apuntar root a un directorio del proyecto en lugar del directorio de compilación pública. Eso puede exponer archivos fuente, ejemplos de entorno o activos privados.

Para un sitio estático, prefiere algo como:

root /var/www/example.com/public;

no:

root /var/www/example.com;

Tercero, bloquea los archivos ocultos a menos que tu aplicación realmente los necesite:

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

Esto permite las rutas .well-known utilizadas para la validación de certificados mientras deniega archivos como .env, .git y .htpasswd.

Finalmente, revisa los límites de subida. Si tu sitio no acepta subidas grandes, mantén client_max_body_size modesto. Esto reduce el radio de explosión de solicitudes grandes accidentales.

¿Cómo Debe Manejar Nginx HTTPS?

HTTPS debería ser la ruta normal para sitios web públicos y APIs. Redirige HTTP simple a HTTPS, usa certificados válidos y evita configuraciones de protocolo obsoletas.

Un bloque de servidor de redirección simple se ve así:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

El bloque de servidor HTTPS debe hacer referencia a tus archivos de certificado e incluir configuraciones TLS modernas. Muchos equipos usan Certbot o un balanceador de carga administrado para manejar los certificados. El punto importante es mantener la renovación automatizada y monitoreada.

Los encabezados de seguridad también pueden ayudar a los navegadores a tomar decisiones más seguras:

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;

Ten cuidado con la Política de Seguridad de Contenido. Es poderosa, pero una política estricta puede romper scripts, fuentes, análisis o contenido incrustado si la aplicas sin pruebas. Comienza en modo solo informe cuando sea posible.

Para un tutorial práctico sobre HTTPS, consulta asegurando Nginx con HTTPS.

¿Cómo Aseguro Nginx como Proxy Inverso?

Cuando Nginx envía tráfico a una aplicación, necesitas preservar la información correcta de la solicitud sin confiar ciegamente en la entrada del cliente.

Los encabezados de proxy comunes se ven así:

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;

Estos encabezados ayudan a la aplicación ascendente a entender la solicitud original. Son útiles para registro, redirecciones, limitación de velocidad y controles de seguridad.

Si Nginx está detrás de otro proxy o balanceador de carga confiable, configura el manejo de IP real cuidadosamente. Solo confía en direcciones de proxy conocidas:

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

No confíes en X-Forwarded-For desde internet abierto. Un cliente puede falsificar ese encabezado. Confía en él solo cuando la solicitud provenga de tu balanceador de carga, CDN o proxy interno.

También debes ocultar los detalles de implementación ascendente. Si tu aplicación devuelve encabezados específicos del framework que no necesitas, elimínalos en la capa de proxy o aplicación.

¿Debería Usar Limitación de Velocidad?

La limitación de velocidad es útil para páginas de inicio de sesión, endpoints de búsqueda, APIs costosas y cualquier ruta que los atacantes puedan abusar fácilmente. No es un reemplazo para la seguridad de la aplicación, pero puede frenar los intentos de fuerza bruta y el tráfico ruidoso.

Ejemplo:

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

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

Esto crea una zona de memoria compartida clave por IP del cliente y limita las solicitudes a la ruta de inicio de sesión. Los valores exactos dependen de tus usuarios. Un panel de control corporativo generalmente puede tolerar límites más estrictos que una aplicación pública de consumo en redes móviles.

Prueba los límites de velocidad cuidadosamente. Si tu sitio está detrás de un proxy y no has configurado el manejo de IP real del cliente, cada usuario puede parecer que proviene de la misma dirección. Eso puede bloquear el tráfico legítimo.

¿Por Qué Sigo Viendo Solicitudes Sospechosas?

Los servidores Nginx públicos reciben ruido de fondo constante: escaneos de paneles de administración antiguos, archivos PHP, rutas de WordPress y archivos de entorno expuestos. Ver estas solicitudes en los registros no siempre significa que estés comprometido.

Lo que importa es cómo responde tu servidor. Una solicitud para /wp-admin en un sitio que no es WordPress debería devolver 404 o 403. Una solicitud para /.env nunca debería devolver secretos. Una solicitud con una ruta extraña no debería ser enviada a un servicio de administración interno.

Revisa tus registros de acceso para:

• Respuestas 401 o 403 repetidas
• Muchas solicitudes de una IP
• Cuerpos de solicitud grandes
• Sondeos de archivos ocultos
• Agentes de usuario inusuales
• Picos en respuestas 499, 502 o 504

Para una solución de problemas más amplia, consulta Errores comunes de Nginx.

Cuándo Pedir Ayuda de Seguridad

Involucra a un ingeniero de seguridad o consultor DevOps experimentado cuando Nginx protege datos de clientes, autenticación, flujos de pago, APIs privadas o herramientas de administración internas. También debes buscar ayuda después de cualquier sospecha de violación, exposición inesperada de archivos o tráfico de ataque repetido que afecte la disponibilidad.

Vale la pena una revisión profesional cuando la configuración abarca múltiples capas, como CDN, balanceador de carga, Nginx, malla de servicios y framework de aplicación. Un archivo Nginx seguro aún puede debilitarse por un límite de confianza deficiente en otro lugar.

Asegura Nginx eliminando la exposición innecesaria, forzando HTTPS, manejando los encabezados de proxy con cuidado y vigilando los registros. No necesitas una configuración enorme para ser más seguro. Necesitas valores predeterminados claros, cambios probados y el hábito de verificar lo que tu servidor realmente sirve.