
Gixy-Next v0.7.1
Gixy-Next:NGINX 配置安全扫描器与性能检查器
Gixy-Next:用于安全审计的 NGINX 配置安全扫描器
概述
Gixy-Next(Gixy)是一款开源的 NGINX 配置安全扫描器和加固工具,可对您的 nginx.conf 进行静态分析,在配置进入生产环境之前检测安全配置错误、加固缺口以及常见的性能陷阱。它是 Yandex 的 Gixy 的一个积极维护的分支。Gixy-Next 的源代码可在 GitHub 上获取。
Gixy-Next 也可以在浏览器中在此页面运行。无需下载;您可以在网站上扫描您的配置(在本地,使用 WebAssembly)。
快速开始
Gixy-Next(gixy 或 gixy-next CLI)发布在 PyPI 上。您可以使用 pip 或 uv 安装它:
# pip
pip3 install gixy-next
# uv
uv pip install gixy-next
然后您可以运行它:
# gixy defaults to reading /etc/nginx/nginx.conf
gixy
# But you can also specify a path to the configuration
gixy /opt/nginx.conf
您也可以将 NGINX 配置导出为单个转储文件(参见 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 -
基于 Web 的扫描器
无需在本地下载并运行 Gixy-Next,您可以使用此网页并从您的 Web 浏览器中扫描配置(在本地,使用 WebAssembly)。
使用 Docker 扫描
Gixy-Next 以 Docker 镜像形式提供,可从 Docker Hub 或 GitHub Registry 获取。
通过将本地配置文件挂载到容器中来扫描它:
# 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
扫描 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
从 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 -
它能做什么
Gixy-Next 可以检测 nginx.conf 及包含的配置文件中广泛的 NGINX 安全和性能配置错误。支持以下插件:
- [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
有未检测到的问题?请在 GitHub 上提交一个 issue,说明缺少什么!
用法(标志)
gixy 默认从 /etc/nginx/nginx.conf 读取系统的 NGINX 配置。您也可以通过将其传递给 gixy 来指定位置:
# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf
您可以使用 --tests 运行一个聚焦的检查子集:
# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure
或者使用 --skips 跳过一些嘈杂的检查:
# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections
要仅报告某一严重级别或更高级别的问题,请使用可叠加的 -l 标志:
# -l for LOW severity issues and higher, -ll for MEDIUM and higher, and -lll for only HIGH severity issues
gixy -ll
默认情况下,gixy 的输出是 ANSI 着色的;最好在兼容的终端中查看。您可以使用 --format(-f)标志并指定 text 值来获得无着色输出:
$ 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
您也可以使用 -f json 来获得可复现、机器可读的 JSON 输出:
$ 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."}]
您也可以使用 -f sarif 来获得 SARIF 2.1.0 日志,例如用于上传到 GitHub 代码扫描:
# Write a SARIF report to a file, e.g. for `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif
更多用法标志可通过向 gixy 传递 --help 找到。您也可以在使用指南中找到更多信息。
配置和插件选项
一些插件暴露了选项,您可以通过 CLI 标志或配置文件进行设置。您可以在配置指南中阅读更多相关内容。
用于 NGINX 安全和合规的 Gixy-Next
与仅检查语法的 nginx -t 不同,Gixy-Next 实际上会分析您的配置并检测未加固的实例和漏洞。
使用 Gixy-Next,您可以执行自动化的 NGINX 配置安全审查,它可以在每次更改时在本地运行,无论是用于审计、合规还是常规测试,帮助产生可操作的发现,从而帮助防止 NGINX 服务器不稳定/缓慢,并降低来自不安全指令和不安全默认值的风险。
贡献
Gixy-Next 由 Joshua Rogers 维护,但始终欢迎贡献!您可以通过不同方式帮助我们,例如:
- 报告错误。
- 为检测建议新插件。
- 改进文档。
- 修复、重构、改进和编写新代码。
在通过拉取请求提交任何更改之前,请阅读贡献指南文档《为 Gixy-Next 做贡献》。
Gixy-Next 的官方主页是 https://gixy.io/。Gixy-Next 中文档的任何更改都会自动反映在该网站上。
源代码可在 https://github.com/MegaManSec/Gixy-Next 找到。
什么是 Gixy?(背景)
Gixy 是一个 NGINX 配置分析器,最初由 Yandex 的 Andrew Krasichkov 开发。它于 2017 年首次发布,此后一直无人维护。它不支持现代版本的 Python,包含大量错误,并且在功能和检测易受攻击的 NGINX 配置的能力方面存在局限。如今在现代系统上运行原始 Gixy 会导致以下错误:
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 是一个分支,它增加了对现代系统的支持,添加了新的检查、性能改进、加固建议,并支持现代 Python 和 NGINX 版本。
为什么不是 gixy-ng?
Gixy-Next 实际上是 gixy-ng 的一个分支,而 gixy-ng 本身又是原始 gixy 的一个分支。Gixy-Next 是在 gixy-ng 的维护者开始产生大量 AI 辅助更改和自动生成的代码之后创建的,这些代码既庞大到无法审查,又是损坏的。
一段时间后,gixy-ng 的维护者开始向代码库提交 AI 生成的更改,这些更改引入了明显的回归,破坏了工具的关键行为(任何使用该工具的人都会发现),添加了随机的 AI 工具产物,并引入了根本不做其应该做的事情的代码。最重要的是,维护者还将他们的业务营销添加到 gixy-ng 的所有文档、所有输出和所有源代码中。
换句话说,gixy-ng 的维护者拿走了原始的 gixy,让 AI 进行更改,引入了一堆错误(以及其他 AI 垃圾),然后在代码中添加了广告。他们还以合并请求的形式接受贡献,但删除了作者的信息(参见这篇文章和这篇文章)。
Gixy-Next 专注于恢复质量,并已在近 100,000 行长的 NGINX 配置上经过实战检验。它修复了 gixy-ng 中引入的更改所导致的错误和误检,移除了 AI 工具产物/垃圾,并努力保持代码库的可审查性和可维护性。这个分支适合那些对干净代码和长期可维护性感兴趣的人。
