> ## Content Index > Fetch the complete content index at: https://www.sredevops.org/llms.txt > Use this file to discover other available public pages before exploring further. # Audita tu Nginx o Apache sin exponer la configuración: Vulnerable.cl y el hardening real - URL: https://www.sredevops.org/es/audita-tu-nginx-o-apache-sin-exponer-la-configuracion-vulnerable-cl-y-el-hardening-real/ - Published: 2026-09-24T16:19:11.000Z - Updated: 2026-09-24T16:19:11.000Z - Description: En ciberseguridad no se compite, se colabora. La propuesta de Vulnerable.cl —hecha en Chile y liberada para la comunidad— va en esa línea: una herramienta gratuita que respeta la privacidad de tu configuración y te entrega una revisión rápida de hardening. - Author: Nicolás Georger - Tags: Security, Open Source, DevSecOps, Español, #es Si tu servidor web todavía usa una configuración heredada de 2015, no hace falta que una IA rebelde quiera dominar el mundo: probablemente ya dejaste la puerta entreabierta para cualquier bot de Shodan. La herramienta de [Vulnerable.cl](https://vulnerable.cl/?ref=sredevops.org) no evitará la singularidad, pero al menos puede ayudarte a que tu `nginx.conf` o tu `apache2.conf` no sean el equivalente digital de un candado de papel. Este artículo explica por qué conviene auditar Nginx y Apache, qué patrones de configuración suelen generar vulnerabilidades y cómo usar una herramienta que analiza todo localmente, sin subir tu configuración a ningún servidor. ## Por qué importa auditar la configuración de un servidor web Nginx y Apache son la puerta de entrada de la mayoría de las aplicaciones web. Una mala configuración de seguridad figura en el [OWASP Top 10 2021 como A05: Security Misconfiguration](https://owasp.org/Top10/A05%5F2021-Security%5FMisconfiguration/?ref=sredevops.org). No se trata solo de parches: directivas débiles, headers ausentes, TLS obsoleto o permisos excesivos pueden exponer información sensible, facilitar ataques de clicjacking, permitir *sniffing* de MIME o abrir rutas internas que no deberían ser públicas. La auditoría de hardening no es un trámite único. Cada vhost, cada `location`, cada `Directory` y cada reverse proxy puede introducir una desviación nueva. Por eso conviene revisar la configuración efectiva, no solo la plantilla base. ## Los sospechosos de siempre La herramienta de Vulnerable.cl se enfoca en varios problemas comunes. Estos son los más rentables si quieres cerrar brechas rápido. ### Headers "flojos" Los headers HTTP de seguridad son baratos de implementar y su ausencia es fácil de detectar. Los principales que deberías evaluar: | Header | Objetivo | | ---------------------------------------------------------- | ----------------------------------------------------------------------- | | Strict-Transport-Security | Forzar HTTPS y evitar degradación a HTTP. | | X-Content-Type-Options | Evitar el *MIME sniffing*. | | X-Frame-Options o Content-Security-Policy: frame-ancestors | Prevenir clicjacking. | | Referrer-Policy | Limitar la fuga de información en la URL de referencia. | | Permissions-Policy | Restringir APIs del navegador como cámara, micrófono o geolocalización. | | Content-Security-Policy | Reducir el impacto de inyecciones de contenido. | Ejemplo básico para Nginx: ```nginx add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "DENY" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always; ``` Para Apache, con `mod_headers`: ```apache Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "DENY" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()" ``` La `Content-Security-Policy` conviene definirla por aplicación, no copiarla de un blog sin entenderla. Una CSP mal hecha puede romper recursos legítimos y no aporta seguridad real. ### TLS a medias TLS 1.0 y TLS 1.1 están oficialmente deprecados según la [RFC 8996](https://datatracker.ietf.org/doc/rfc8996/?ref=sredevops.org). Si tu servidor todavía los acepta, no estás “manteniendo compatibilidad”: estás ofreciendo una vía de downgrade. Lo mismo aplica para cifrados RC4, `SSLv3` o suites exportables. En Nginx, una base moderna sería: ```nginx ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_tickets off; ``` En Apache: ```apache SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 SSLHonorCipherOrder off ``` No copies estos fragmentos sin contexto: usa el [generador de configuraciones SSL de Mozilla](https://ssl-config.mozilla.org/?ref=sredevops.org) para obtener una configuración coherente con tu versión de servidor y tus clientes. ### Permisos raros Activar el listado de directorios, permitir acceso a archivos ocultos o dejar expuestos `.git`, `.env`, backups o archivos de configuración es regalar información. En Nginx, `autoindex off` debería ser la norma y conviene denegar explícitamente los dotfiles: ```nginx autoindex off; location ~ /\. { deny all; } location ~ ^/(\.git|\.env|backup) { deny all; } ``` En Apache: ```apache Options -Indexes Require all denied ``` Los permisos del sistema de archivos también importan: los archivos de configuración no deberían ser legibles por cualquier usuario del equipo. Un `chmod 640` y un propietario `root:root` son una base más limpia que un `chmod 777`. ### Configuraciones heredadas de 2015 La herencia no es vintage: es deuda técnica con exploits. Apache 2.2 dejó sintaxis como `Allow from all`, `Order allow,deny` y `Deny from all`. Apache 2.4 usa `Require all granted` o `Require all denied`. Nginx también tuvo cambios: el clásico `ssl on;` desapareció en favor de `listen 443 ssl;`. Si tu configuración mezcla sintaxis antigua con módulos modernos, las herramientas estáticas saltarán con avisos. A veces no es explotable directamente, pero indica que nadie revisó la configuración desde que el servidor se puso en producción. ## Análisis local: por qué es importante Vulnerable.cl plantea un punto interesante: el análisis ocurre en tu navegador. No hay backend, no hay cuentas, no se sube ni se guarda nada. La configuración nunca sale de tu equipo. Eso importa porque un `nginx.conf` puede contener rutas internas, IPs, cabeceras de autenticación, certificados o vhosts que no quieres pegar en un servicio web cualquiera. Si el análisis fuera remoto, estarías compartiendo un mapa de tu infraestructura. Al ejecutarse como JavaScript local, reduces la superficie de exposición. Eso sí: si tu paranoia es nivel productivo, abre las DevTools y revisa la pestaña de red antes de pegar el archivo. Verifica que no haya llamadas salientes. La herramienta se presenta como local, pero en seguridad siempre conviene confirmar. ## Cómo usar Vulnerable.cl El flujo es simple: 1. Ve a [Vulnerable.cl/hardening/hardening.html](https://vulnerable.cl/hardening/hardening.html?ref=sredevops.org). 2. Pega tu `nginx.conf`, tu `apache2.conf` o fragmentos relevantes de `.htaccess`. 3. Revisa los hallazgos y las recomendaciones. 4. Aplica solo los cambios que entiendas. 5. Valida la sintaxis antes de recargar: ```bash # Nginx nginx -t && systemctl reload nginx # Apache apachectl configtest && systemctl reload apache2 ``` No apliques configuraciones de hardening a ciegas. Un header mal puesto puede romper un frontend, un CSP demasiado estricto puede bloquear recursos legítimos y un TLS moderno puede dejar fuera clientes viejos que tu negocio aún necesita. ## Limitaciones y verificación real Una herramienta que analiza el archivo de configuración no reemplaza una auditoría activa. No puede, por ejemplo, comprobar el handshake TLS real, detectar permisos incorrectos en el sistema de archivos ni simular un ataque. Es una primera capa de revisión. Para complementar, usa: - [Mozilla Observatory](https://observatory.mozilla.org/?ref=sredevops.org) para evaluar headers y TLS desde fuera. - [SSL Labs](https://www.ssllabs.com/ssltest/?ref=sredevops.org) para el análisis del protocolo. - [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/?ref=sredevops.org) para entender cada header. - Los benchmarks CIS de Apache y Nginx para una base más formal. También conviene extraer la configuración efectiva con `nginx -T` o `apachectl -S`. A veces un archivo parece limpio, pero un include secundario introduce una directiva que lo cambia todo. ## Conclusión En ciberseguridad no se compite, se colabora. La propuesta de Vulnerable.cl —hecha en Chile y liberada para la comunidad— va en esa línea: una herramienta gratuita que respeta la privacidad de tu configuración y te entrega una revisión rápida de hardening. La próxima vez que digas “vulnerable”, que sea `.cl`. Y si una IA decide actuar por cuenta propia, al menos que no encuentre tu `nginx.conf` con `autoindex on`, TLS 1.0 y un `.env` servido como descarga. ## Referencias - [Vulnerable.cl - hardening de servidores](https://vulnerable.cl/hardening/hardening.html?ref=sredevops.org) - [Vulnerable.cl](https://vulnerable.cl/?ref=sredevops.org) - [OWASP Top 10 2021: A05 Security Misconfiguration](https://owasp.org/Top10/A05%5F2021-Security%5FMisconfiguration/?ref=sredevops.org) - [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/?ref=sredevops.org) - [Mozilla SSL Configuration Generator](https://ssl-config.mozilla.org/?ref=sredevops.org) - [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://datatracker.ietf.org/doc/rfc8996/?ref=sredevops.org) - [Documentación de Apache mod\_headers](https://httpd.apache.org/docs/current/mod/mod%5Fheaders.html?ref=sredevops.org) - [Documentación de Apache mod\_ssl](https://httpd.apache.org/docs/current/mod/mod%5Fssl.html?ref=sredevops.org) - [Mozilla Observatory](https://observatory.mozilla.org/?ref=sredevops.org) - [SSL Labs](https://www.ssllabs.com/ssltest/?ref=sredevops.org) - [Publicación original en LinkedIn](https://www.linkedin.com/feed/?ref=sredevops.org)