
Gixy-Next v0.7.1
Gixy-Next: Scanner de Segurança de Configuração NGINX & Verificador de Desempenho
Gixy-Next: Scanner de Segurança para Configurações NGINX para Auditorias de Segurança
Visão Geral
Gixy-Next (Gixy) é um scanner de segurança e ferramenta de hardening para configurações NGINX de código aberto que analisa estaticamente seu nginx.conf para detectar configurações incorretas de segurança, lacunas de hardening e armadilhas de desempenho comuns antes que cheguem à produção. É um fork ativamente mantido do Gixy do Yandex. O código-fonte do Gixy-Next está disponível no GitHub.
O Gixy-Next também pode ser executado no navegador nesta página. Não é necessário download; você pode escanear suas configurações no site (localmente, usando WebAssembly).
Início rápido
O Gixy-Next (a CLI gixy ou gixy-next) é distribuído no PyPI. Você pode instalá-lo com pip ou uv:
# pip
pip3 install gixy-next
# uv
uv pip install gixy-next
Você pode então executá-lo:
# gixy defaults to reading /etc/nginx/nginx.conf
gixy
# But you can also specify a path to the configuration
gixy /opt/nginx.conf
Você também pode exportar sua configuração NGINX para um único arquivo de dump (veja 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 -
Scanner baseado na web
Em vez de baixar e executar o Gixy-Next localmente, você pode usar esta página web e escanear uma configuração diretamente do seu navegador (localmente, usando WebAssembly).
Escanear com Docker
O Gixy-Next está disponível como imagem Docker no Docker Hub ou no GitHub Registry.
Escanear um arquivo de configuração local montando-o no contêiner:
# 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
Escanear um dump de configuração NGINX em execução:
# 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 a partir de 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 -
O que ele pode fazer
O Gixy-Next pode detectar uma ampla variedade de configurações incorretas de segurança e desempenho do NGINX em nginx.conf e arquivos de configuração incluídos. Os seguintes plugins são suportados:
- [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 não detectado? Por favor, abra uma issue no GitHub informando o que está faltando!
Uso (flags)
O gixy por padrão lê a configuração NGINX do sistema em /etc/nginx/nginx.conf. Você também pode especificar o local passando-o para o gixy:
# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf
Você pode executar um subconjunto focado de verificações com --tests:
# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure
Ou pular algumas verificações ruidosas com --skips:
# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections
Para reportar apenas problemas de uma determinada severidade ou superior, use a flag cumulativa -l:
# -l for LOW severity issues and higher, -ll for MEDIUM and higher, and -lll for only HIGH severity issues
gixy -ll
Por padrão, a saída do gixy é colorida com ANSI; melhor visualizada em um terminal compatível. Você pode usar a flag --format (-f) com o valor text para obter uma saída sem cores:
$ 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
Você também pode usar -f json para obter uma saída JSON reproduzível e legível 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."}]
Você também pode usar -f sarif para obter um log SARIF 2.1.0, por exemplo, para enviar ao code scanning do GitHub:
# Write a SARIF report to a file, e.g. for `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif
Mais flags de uso podem ser encontradas passando --help para o gixy. Você também pode encontrar mais informações no Guia de Uso.
Configuração e opções de plugins
Alguns plugins expõem opções que você pode definir via flags de CLI ou um arquivo de configuração. Você pode ler mais sobre isso no Guia de Configuração.
Gixy-Next para segurança e conformidade do NGINX
Diferente de executar nginx -t, que apenas verifica a sintaxe, o Gixy-Next realmente analisa sua configuração e detecta instâncias não endurecidas e vulnerabilidades.
Com o Gixy-Next, você pode realizar uma revisão automatizada de segurança da configuração do NGINX que pode ser executada localmente a cada alteração, seja para auditoria, conformidade ou testes gerais, ajudando a produzir descobertas acionáveis que ajudam a prevenir servidores NGINX instáveis/lentos e a reduzir o risco de diretivas inseguras e padrões inseguros.
Contribuindo
O Gixy-Next é mantido por Joshua Rogers, mas contribuições são sempre bem-vindas! Você pode nos ajudar de diferentes maneiras, como:
- Reportando bugs.
- Sugerindo novos plugins para detecção.
- Melhorando a documentação.
- Corrigindo, refatorando, melhorando e escrevendo novo código.
Antes de enviar quaisquer alterações em pull requests, por favor leia o documento de diretrizes de contribuição, Contributing to Gixy-Next.
A página oficial do Gixy-Next é https://gixy.io/. Quaisquer alterações na documentação do Gixy-Next serão automaticamente refletidas nesse site.
O código-fonte pode ser encontrado em https://github.com/MegaManSec/Gixy-Next.
O que é o Gixy? (Contexto)
Gixy é um analisador de configuração NGINX que foi originalmente desenvolvido por Andrew Krasichkov, do Yandex. Foi lançado pela primeira vez em 2017 e desde então ficou sem manutenção. Ele não suporta versões modernas do Python, contém inúmeros bugs e é limitado em sua funcionalidade e capacidade de detectar configurações NGINX vulneráveis. Executar o Gixy original hoje em um sistema moderno resultará no seguinte erro:
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'?
O Gixy-Next, portanto, é um fork que adiciona suporte a sistemas modernos, adiciona novas verificações, melhorias de desempenho, sugestões de hardening e suporte a versões modernas do Python e do NGINX.
Por que não gixy-ng?
O Gixy-Next é na verdade um fork do gixy-ng, que por sua vez era um fork do gixy original. O Gixy-Next foi criado depois que o mantenedor do gixy-ng começou a produzir grandes quantidades de alterações assistidas por IA e código gerado automaticamente que era tanto grande demais para ser revisado quanto quebrado.
Depois de algum tempo, o mantenedor do gixy-ng começou a commitar alterações geradas por IA na base de código que introduziram regressões óbvias, quebraram comportamentos críticos da ferramenta (que qualquer pessoa usando a ferramenta teria percebido), adicionaram artefatos aleatórios de ferramentas de IA e introduziram código que simplesmente não fazia o que deveria fazer. Mais importante ainda, o mantenedor também adicionou marketing para seu negócio em toda a documentação, toda a saída e todo o código-fonte do gixy-ng.
Em outras palavras, o mantenedor do gixy-ng pegou o gixy original, pediu à IA para fazer alterações, introduziu um monte de bugs (e outras porcarias de IA) e depois adicionou publicidade ao código. Ele também aceitou contribuições na forma de merge requests, mas removeu as informações do autor (veja este post e este post).
O Gixy-Next foca em restaurar a qualidade e foi testado em batalha em configurações NGINX com quase 100.000 linhas. Ele corrige bugs e detecções incorretas introduzidas por alterações feitas no gixy-ng, remove artefatos/lixo de ferramentas de IA e tenta manter a base de código revisável e sustentável. Este fork é para aqueles interessados em código limpo e manutenibilidade a longo prazo.
