Gixy-Next: Scanner de Segurança de Configuração NGINX para Auditorias de Segurança

Visão geral

Gixy-Next (Gixy) é um scanner de segurança de configuração NGINX e ferramenta de endurecimento (hardening) de código aberto que analisa estaticamente seu nginx.conf para detectar más configurações de segurança, lacunas de endurecimento e armadilhas comuns de desempenho antes que cheguem à produção. É um fork mantido ativamente do Gixy da 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 baixar nada; você pode analisar 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 despejo (dump) (veja nginx -T Despejo de Configuração ao Vivo):

# 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 da web e analisar uma configuração a partir do seu navegador (localmente, usando WebAssembly).

Analisar com Docker

O Gixy-Next está disponível como imagem Docker no Docker Hub ou no GitHub Registry.

Analise 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

Analise um despejo de configuração ao vivo do 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

Analise a partir do 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 más configurações de segurança e desempenho do NGINX em nginx.conf e em arquivos de configuração incluídos. Os seguintes plugins são suportados:

• [add_header_content_type] Definir Content-Type via add_header
• [add_header_multiline] Cabeçalhos de resposta multilinha
• [add_header_redefinition] Redefinição de cabeçalhos de resposta pela diretiva "add_header"
• [alias_traversal] Travessia de caminho (path traversal) via alias mal configurado
• [allow_without_deny] Allow especificado sem deny
• [default_server_flag] Ausência da flag default_server
• [error_log_off] error_log definido como off
• [hash_without_default] Ausência de default em blocos hash
• [host_spoofing] Falsificação do cabeçalho Host da requisição
• [http2_misdirected_request] Ausência de proteção contra requisições mal direcionadas (misdirected request) em HTTP/2
• [http_splitting] Divisão de Resposta HTTP
• [if_is_evil] If é prejudicial quando usado no contexto de location
• [invalid_regex] Grupos de captura de regex inválidos
• [low_keepalive_requests] keepalive_requests baixo
• [missing_worker_processes] Ausência de worker_processes
• [mixed_case_variable] Referências a variáveis com maiúsculas e minúsculas misturadas
• [origins] Problemas com validação dos cabeçalhos referer/origin
• [overlapping_captures] Capturas sobrepostas no contexto redirect/args do rewrite
• [proxy_buffering_off] Desativação de proxy_buffering
• [proxy_pass_normalized] Problemas de normalização de caminho em proxy_pass
• [quic_bpf_reuseport] Conexões QUIC descartadas silenciosamente após reload
• [regex_redos] Negação de serviço por expressão regular (ReDoS)
• [resolver_external] Uso de servidores DNS externos
• [return_bypasses_allow_deny] A diretiva return ignora as restrições allow/deny
• [ssl_stapling_without_resolver] OCSP stapling falha silenciosamente sem resolver
• [ssrf] Falsificação de Solicitação no Lado do Servidor (SSRF)
• [stale_dns_cache] Registros DNS em cache desatualizados/obsoletos usados em proxy_pass
• [status_page_exposed] Garante que status_page não esteja exposto ao mundo
• [try_files_is_evil_too] A diretiva try_files é prejudicial sem open_file_cache
• [unanchored_regex] Expressões regulares sem ancoragem
• [unnamed_groups] Grupos de captura sem nome na query string do rewrite
• [valid_referers] none/blocked em valid_referers
• [version_disclosure] Uso de valores inseguros para server_tokens
• [worker_rlimit_nofile_vs_connections] worker_rlimit_nofile deve ser pelo menos o dobro de worker_connections

Algo não detectado? Por favor, abra uma issue no GitHub informando o que falta!

Uso (flags)

Por padrão, o gixy 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 relatar 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; o ideal é visualizá-la 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 envio 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.

Opções de configuração e de plugins

Alguns plugins expõem opções que você pode definir por meio de flags de CLI ou de um arquivo de configuração. Você pode ler mais sobre elas no Guia de configuração.

Gixy-Next para segurança e conformidade NGINX

Diferentemente de executar nginx -t, que apenas verifica a sintaxe, o Gixy-Next de fato 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 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 evitar servidores NGINX instáveis/lentos e a reduzir o risco de diretivas inseguras e padrões não seguros.

Contribuindo

O Gixy-Next é mantido por Joshua Rogers, mas contribuições são sempre bem-vindas! Você pode nos ajudar de diversas formas, como:

• Relatando bugs.
• Sugerindo novos plugins para detecção.
• Melhorando a documentação.
• Corrigindo, refatorando, melhorando e escrevendo novo código.

Antes de enviar qualquer alteração em pull requests, leia o documento de diretrizes de contribuição, Contribuindo com o Gixy-Next.

A página oficial do Gixy-Next é https://gixy.io/. Qualquer alteração na documentação do Gixy-Next será refletida automaticamente 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, da Yandex. Foi lançado pela primeira vez em 2017 e, desde então, deixou de ser mantido. Ele não suporta versões modernas do Python, contém inúmeros bugs e tem funcionalidade e capacidade limitadas para 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, novas verificações, melhorias de desempenho, sugestões de endurecimento e suporte a versões modernas de Python e 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 eram ao mesmo tempo grandes demais para revisão e quebrados.

Depois de algum tempo, o mantenedor do gixy-ng começou a enviar para o código alterações geradas por IA que introduziram regressões óbvias, quebraram o comportamento crítico da ferramenta (o que qualquer usuário da ferramenta perceberia), 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 o 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 que fizesse alterações, introduziu um monte de bugs (e outras porcarias de IA) e depois adicionou publicidade ao código. Eles também aceitaram contribuições na forma de merge requests, mas removeram as informações do autor (veja este post e este post).

O Gixy-Next concentra-se em restaurar a qualidade e foi testado em batalha em configurações NGINX com quase 100.000 linhas de extensão. Ele corrige bugs e detecções incorretas introduzidos pelas alterações do gixy-ng, remove artefatos/lixo de ferramentas de IA e procura manter o código revisável e sustentável. Este fork é para aqueles interessados em código limpo e manutenibilidade de longo prazo.