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.
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 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.
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. 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.
La herramienta de Vulnerable.cl se enfoca en varios problemas comunes. Estos son los más rentables si quieres cerrar brechas rápido.
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:
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:
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 1.0 y TLS 1.1 están oficialmente deprecados según la RFC 8996. 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:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
En 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 para obtener una configuración coherente con tu versión de servidor y tus clientes.
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:
autoindex off;
location ~ /\. {
deny all;
}
location ~ ^/(\.git|\.env|backup) {
deny all;
}
En Apache:
Options -Indexes
<FilesMatch "^\.|\bbackup\b">
Require all denied
</FilesMatch>
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.
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.
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.
El flujo es simple:
nginx.conf, tu apache2.conf o fragmentos relevantes de .htaccess.# 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.
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:
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.
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.
El gobierno chileno finalmente oficializó lo que el sector privado venía anticipando con inquietud: la entrada en vigencia de la Ley 21.719, sobre protección y tratamiento de datos personales, se posterga por un año.
Si Omarchy Quattro es un vistazo en funcionamiento de ese futuro, la fundación es el motor institucional para hacerlo duradero. Las marcas registradas, la infraestructura y las subvenciones no son emocionantes. Tampoco lo es el interior de un firewall. Pero sin ellos, la visión muere.
