
Gixy-Next v0.7.1
Gixy-Next: Escáner de seguridad de configuración y verificador de rendimiento de NGINX
Gixy-Next: Escáner de seguridad de configuraciones NGINX para auditorías de seguridad
Descripción general
Gixy-Next (Gixy) es un escáner de seguridad y herramienta de hardening de configuraciones NGINX de código abierto que analiza estáticamente tu nginx.conf para detectar configuraciones erróneas de seguridad, carencias de hardening y errores de rendimiento comunes antes de que lleguen a producción. Es un fork mantenido activamente del Gixy de Yandex. El código fuente de Gixy-Next está disponible en GitHub.
Gixy-Next también se puede ejecutar en el navegador en esta página. No se necesita descargar nada; puedes escanear tus configuraciones en el sitio web (localmente, usando WebAssembly).
Inicio rápido
Gixy-Next (la CLI gixy o gixy-next) se distribuye en PyPI. Puedes instalarlo con pip o uv:
# pip
pip3 install gixy-next
# uv
uv pip install gixy-next
Luego puedes ejecutarlo:
# gixy defaults to reading /etc/nginx/nginx.conf
gixy
# But you can also specify a path to the configuration
gixy /opt/nginx.conf
También puedes exportar tu configuración de NGINX a un único archivo de volcado (consulta nginx -T Live Configuration Dump):
# Dumps the full NGINX configuration into a single file (including all includes)
nginx -T > ./nginx-dump.conf
# Scan the dump elsewhere (or via stdin):
gixy ./nginx-dump.conf
# or
cat ./nginx-dump.conf | gixy -
Escáner basado en web
En lugar de descargar y ejecutar Gixy-Next localmente, puedes usar esta página web y escanear una configuración desde tu navegador web (localmente, usando WebAssembly).
Escanear con Docker
Gixy-Next está disponible como imagen de Docker desde Docker Hub o GitHub Registry.
Escanea un archivo de configuración local montándolo en el contenedor:
# Use Github Registry
docker run --pull=always --rm -v "$PWD/nginx.conf:/nginx.conf:ro" ghcr.io/megamansec/gixy-next /nginx.conf
# Or Docker Hub
docker run --pull=always --rm -v "$PWD/nginx.conf:/nginx.conf:ro" megamansec/gixy-next /nginx.conf
Escanea un volcado de configuración en vivo de NGINX:
# Dumps the full NGINX configuration into a single file (including all includes)
nginx -T > ./nginx-dump.conf
# Use Github Registry
docker run --pull=always --rm -v "$PWD/nginx-dump.conf:/nginx-dump.conf:ro" ghcr.io/megamansec/gixy-next /nginx-dump.conf
# Or Docker Hub
docker run --pull=always --rm -v "$PWD/nginx-dump.conf:/nginx-dump.conf:ro" megamansec/gixy-next /nginx-dump.conf
Escanear desde stdin:
# Use Github Registry
nginx -T | docker run --pull=always --rm -i ghcr.io/megamansec/gixy-next gixy-next -
# Or Docker Hub
nginx -T | docker run --pull=always --rm -i megamansec/gixy-next gixy-next -
Qué puede hacer
Gixy-Next puede detectar una amplia gama de configuraciones erróneas de seguridad y rendimiento de NGINX en nginx.conf y en los archivos de configuración incluidos. Se admiten los siguientes plugins:
- [add_header_content_type] Setting Content-Type via add_header
- [add_header_multiline] Multiline response headers
- [add_header_redefinition] Redefining of response headers by "add_header" directive
- [alias_traversal] Path traversal via misconfigured alias
- [allow_without_deny] Allow specified without deny
- [default_server_flag] Missing default_server flag
- [error_log_off]
error_logset tooff - [hash_without_default] Missing default in hash blocks
- [host_spoofing] Request's Host header forgery
- [http2_misdirected_request] Missing HTTP/2 misdirected-request safeguard
- [http_splitting] HTTP Response Splitting
- [if_is_evil] If is evil when used in location context
- [invalid_regex] Invalid regex capture groups
- [low_keepalive_requests] Low
keepalive_requests - [missing_worker_processes] Missing
worker_processes - [mixed_case_variable] Mixed-case variable references
- [origins] Problems with referer/origin header validation
- [overlapping_captures] Overlapping captures in rewrite redirect/args context
- [proxy_buffering_off] Disabling
proxy_buffering - [proxy_pass_normalized]
proxy_passpath normalization issues - [proxy_set_header_redefinition] Redefining of proxied request headers by "proxy_set_header" directive
- [quic_bpf_reuseport] QUIC connections silently dropped after reload
- [regex_redos] Regular expression denial of service (ReDoS)
- [resolver_external] Using external DNS nameservers
- [return_bypasses_allow_deny] Return directive bypasses allow/deny restrictions
- [ssl_ecdh_curve] Post-quantum groups stop NGINX from starting on older OpenSSL
- [ssl_stapling_letsencrypt] OCSP stapling does nothing for a Let's Encrypt certificate
- [ssl_stapling_without_resolver] OCSP stapling silently fails without a resolver
- [ssrf] Server Side Request Forgery
- [stale_dns_cache] Outdated/stale cached DNS records used in proxy_pass
- [status_page_exposed] Ensures that status_page is not exposed to the world
- [try_files_is_evil_too]
try_filesdirective is evil without open_file_cache - [unanchored_regex] Unanchored regular expressions
- [unnamed_groups] Unnamed capture groups in rewrite query string
- [valid_referers] none/blocked in valid_referers
- [version_disclosure] Using insecure values for server_tokens
- [worker_rlimit_nofile_vs_connections]
worker_rlimit_nofilemust be at least twiceworker_connections
¿Algo no detectado? ¡Abre un issue en GitHub indicando qué falta!
Uso (flags)
gixy lee por defecto la configuración de NGINX del sistema desde /etc/nginx/nginx.conf. También puedes especificar la ubicación pasándosela a gixy:
# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf
Puedes ejecutar un subconjunto específico de comprobaciones con --tests:
# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure
O saltarte algunas comprobaciones ruidosas con --skips:
# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections
Para informar solo de problemas de una severidad determinada o superior, usa la flag acumulativa -l:
# -l for LOW severity issues and higher, -ll for MEDIUM and higher, and -lll for only HIGH severity issues
gixy -ll
Por defecto, la salida de gixy tiene color ANSI; se ve mejor en una terminal compatible. Puedes usar la flag --format (-f) con el valor text para obtener una salida sin color:
$ gixy -f text
==================== Results ===================
Problem: [http_splitting] Possible HTTP-Splitting vulnerability.
Description: Using variables that can contain "\n" may lead to http injection.
Additional info: https://gixy.io/plugins/http_splitting/
Reason: At least variable "$action" can contain "\n"
Pseudo config:
include /etc/nginx/sites/default.conf;
server {
location ~ /v1/((?<action>[^.]*)\.json)?$ {
add_header X-Action $action;
}
}
==================== Summary ===================
Total issues:
Informational: 0
Low: 0
Medium: 0
High: 1
También puedes usar -f json para obtener una salida JSON reproducible y legible por máquina:
$ gixy -f json
[{"config":"\nserver {\n\n\tlocation ~ /v1/((?<action>[^.]*)\\.json)?$ {\n\t\tadd_header X-Action $action;\n\t}\n}","description":"Using variables that can contain \"\\n\" or \"\\r\" may lead to http injection.","file":"/etc/nginx/nginx.conf","line":4,"path":"/etc/nginx/nginx.conf","plugin":"http_splitting","reason":"At least variable \"$action\" can contain \"\\n\"","reference":"https://gixy.io/plugins/http_splitting/","severity":"HIGH","summary":"Possible HTTP-Splitting vulnerability."}]
También puedes usar -f sarif para obtener un registro SARIF 2.1.0, por ejemplo para subirlo al escaneo de código de GitHub:
# Write a SARIF report to a file, e.g. for `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif
Puedes encontrar más flags de uso pasando --help a gixy. También puedes encontrar más información en la Guía de uso.
Configuración y opciones de plugins
Algunos plugins exponen opciones que puedes configurar mediante flags de CLI o un archivo de configuración. Puedes leer más sobre ellas en la Guía de configuración.
Gixy-Next para la seguridad y el cumplimiento de NGINX
A diferencia de ejecutar nginx -t, que solo comprueba la sintaxis, Gixy-Next analiza realmente tu configuración y detecta instancias sin hardening y vulnerabilidades.
Con Gixy-Next, puedes realizar una revisión automatizada de la seguridad de la configuración de NGINX que puede ejecutarse localmente en cada cambio, ya sea para auditoría, cumplimiento o pruebas generales, ayudando a producir hallazgos accionables que ayudan a prevenir servidores NGINX inestables/lentos y a reducir el riesgo de directivas inseguras y valores predeterminados inseguros.
Contribuir
Gixy-Next está mantenido por Joshua Rogers, ¡pero las contribuciones siempre son bienvenidas! Puedes ayudarnos de diferentes maneras, como:
- Reportando errores.
- Sugiriendo nuevos plugins para la detección.
- Mejorando la documentación.
- Corrigiendo, refactorizando, mejorando y escribiendo nuevo código.
Antes de enviar cualquier cambio en pull requests, lee el documento de directrices de contribución, Contributing to Gixy-Next.
La página oficial de Gixy-Next es https://gixy.io/. Cualquier cambio en la documentación de Gixy-Next se reflejará automáticamente en ese sitio web.
El código fuente se puede encontrar en https://github.com/MegaManSec/Gixy-Next.
¿Qué es Gixy? (Antecedentes)
Gixy es un analizador de configuraciones de NGINX que fue originalmente desarrollado por Andrew Krasichkov, de Yandex. Se publicó por primera vez en 2017 y desde entonces ha quedado sin mantenimiento. No admite versiones modernas de Python, contiene numerosos errores y está limitado en su funcionalidad y en su capacidad para detectar configuraciones de NGINX vulnerables. Ejecutar el Gixy original hoy en un sistema moderno dará como resultado el siguiente error:
File "gixy/core/sre_parse/sre_parse.py", line 61, in <module>
"t": SRE_FLAG_TEMPLATE,
^^^^^^^^^^^^^^^^^
NameError: name 'SRE_FLAG_TEMPLATE' is not defined. Did you mean: 'SRE_FLAG_VERBOSE'?
Gixy-Next, por lo tanto, es un fork que añade compatibilidad con sistemas modernos, añade nuevas comprobaciones, mejoras de rendimiento, sugerencias de hardening y compatibilidad con versiones modernas de Python y NGINX.
¿Por qué no gixy-ng?
Gixy-Next es en realidad un fork de gixy-ng, que a su vez era un fork del gixy original. Gixy-Next se creó después de que el mantenedor de gixy-ng empezara a producir grandes cantidades de cambios asistidos por IA y código autogenerado que era tanto imposible de revisar por su tamaño como defectuoso.
Después de un tiempo, el mantenedor de gixy-ng comenzó a hacer commit de cambios generados por IA en el código base que introdujeron regresiones evidentes, rompieron comportamientos críticos de la herramienta (que cualquiera que usara la herramienta habría detectado), añadieron artefactos aleatorios de herramientas de IA e introdujeron código que simplemente no hacía lo que se suponía que debía hacer. Lo más importante es que el mantenedor también añadió publicidad de su negocio en toda la documentación, toda la salida y todo el código fuente de gixy-ng.
En otras palabras, el mantenedor de gixy-ng tomó el gixy original, le pidió a la IA que hiciera cambios, introdujo un montón de errores (y otra basura de IA) y luego añadió publicidad al código. También aceptó contribuciones en forma de merge requests, pero eliminó la información del autor (consulta esta publicación y esta publicación).
Gixy-Next se centra en restaurar la calidad y ha sido probado en batalla con configuraciones de NGINX de casi 100.000 líneas. Corrige errores y detecciones incorrectas introducidas por los cambios de gixy-ng, elimina artefactos/basura de herramientas de IA e intenta mantener el código base revisable y mantenible. Este fork es para quienes están interesados en el código limpio y la mantenibilidad a largo plazo.
