megamansec/gixy-nextGixy-Next: NGINX構成セキュリティスキャナー＆パフォーマンスチェッカー
# Gixy-Next: セキュリティ監査のための NGINX 設定セキュリティスキャナー
## 概要
<a href="https://gixy.io/"><img width="192" height="192" alt="Gixy-Next マスコットロゴ" style="float: right;" align="right" src="https://assets.kitploit.com/production/public/readmes/10695/943d5c952685014f6540ef9cb02fe9d8cd895479a41a8f78786b5f2997207ec0.jpg" /></a>
Gixy-Next (Gixy) は、オープンソースの NGINX 設定セキュリティスキャナー兼ハードニングツールであり、nginx.conf を静的に解析して、セキュリティ上の設定ミス、ハードニングの不足、および一般的なパフォーマンスの落とし穴を本番環境に到達する前に検出します。これは Yandex の [Gixy](https://github.com/yandex/gixy) の活発にメンテナンスされているフォークです。Gixy-Next のソースコードは [GitHub で公開されています](https://github.com/megamansec/gixy-next)。
Gixy-Next は[このページ](https://gixy.io/scanner/)でブラウザ上でも実行できます。ダウンロードは不要で、ウェブサイト上で設定をスキャンできます (WebAssembly を使用してローカルで実行されます)。
### クイックスタート
Gixy-Next (`gixy` または `gixy-next` CLI) は [PyPI](https://pypi.python.org/pypi/Gixy-Next) で配布されています。pip または uv でインストールできます:
```shell-session
# pip
pip3 install gixy-next
# uv
uv pip install gixy-next
```
その後、実行できます:
```shell-session
# 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 ライブ設定ダンプ](https://gixy.io/nginx-config-dump) を参照）：
```shell-session
# 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をローカルにダウンロードして実行する代わりに、[このウェブページ](https://gixy.io/scanner/)を使用して、Webブラウザから設定をスキャンできます（WebAssemblyを使用してローカルで実行されます）。
### Dockerでスキャンする
Gixy-Nextは、[Docker Hub](https://hub.docker.com/r/megamansec/gixy-next/)または[GitHub Registry](https://github.com/MegaManSec/Gixy-Next/pkgs/container/gixy-next)からDockerイメージとして利用できます。
ローカルの設定ファイルをコンテナにマウントしてスキャンします：
```shell-session
# 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 のライブ設定ダンプをスキャンします:
```shell-session
# 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
```
標準入力からスキャンします:
```shell-session
# 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] add_header による Content-Type の設定](https://gixy.io/plugins/add_header_content_type/)
- [[add_header_multiline] 複数行のレスポンスヘッダー](https://gixy.io/plugins/add_header_multiline/)
- [[add_header_redefinition] "add_header" ディレクティブによるレスポンスヘッダーの再定義](https://gixy.io/plugins/add_header_redefinition/)
- [[alias_traversal] 誤設定された alias によるパストラバーサル](https://gixy.io/plugins/alias_traversal/)
- [[allow_without_deny] deny を伴わない allow の指定](https://gixy.io/plugins/allow_without_deny/)
- [[default_server_flag] default_server フラグの欠落](https://gixy.io/plugins/default_server_flag/)
- [[error_log_off] `error_log` が `off` に設定されている](https://gixy.io/plugins/error_log_off/)
- [[filesystem_root_exposure] ファイルシステムのルートがドキュメントルートとして使用されている](https://gixy.io/plugins/filesystem_root_exposure/)
- [[hash_without_default] hash ブロックに default がない](https://gixy.io/plugins/hash_without_default/)
- [[host_spoofing] リクエストの Host ヘッダーの偽造](https://gixy.io/plugins/host_spoofing/)
- [[http2_misdirected_request] HTTP/2 の誤誘導リクエスト対策の欠落](https://gixy.io/plugins/http2_misdirected_request/)
- [[http_splitting] HTTP レスポンス分割](https://gixy.io/plugins/http_splitting/)
- [[if_is_evil] location コンテキストで使用すると if は有害](https://gixy.io/plugins/if_is_evil/)
- [[invalid_regex] 無効な正規表現のキャプチャグループ](https://gixy.io/plugins/invalid_regex/)
- [[low_keepalive_requests] `keepalive_requests` の値が低すぎる](https://gixy.io/plugins/low_keepalive_requests/)
- [[missing_worker_processes] `worker_processes` の欠落](https://gixy.io/plugins/missing_worker_processes/)
- [[mixed_case_variable] 大文字小文字が混在した変数参照](https://gixy.io/plugins/mixed_case_variable/)
- [[origins] referer/origin ヘッダー検証の問題](https://gixy.io/plugins/origins/)
- [[overlapping_captures] rewrite のリダイレクト/引数コンテキストにおけるキャプチャの重複](https://gixy.io/plugins/overlapping_captures/)
- [[proxy_buffering_off] `proxy_buffering` の無効化](https://gixy.io/plugins/proxy_buffering_off/)
- [[proxy_pass_normalized] `proxy_pass` が意図しないパスを上流に送信する可能性](https://gixy.io/plugins/proxy_pass_normalized/)
- [[proxy_set_header_redefinition] "proxy_set_header" ディレクティブによるプロキシリクエストヘッダーの再定義](https://gixy.io/plugins/proxy_set_header_redefinition/)
- [[quic_bpf_reuseport] リロード後に QUIC 接続がサイレントに切断される](https://gixy.io/plugins/quic_bpf_reuseport/)
- [[regex_redos] 正規表現によるサービス拒否 (ReDoS)](https://gixy.io/plugins/regex_redos/)
- [[resolver_external] 外部 DNS ネームサーバーの使用](https://gixy.io/plugins/resolver_external/)
- [[return_bypasses_allow_deny] return ディレクティブが allow/deny 制限をバイパスする](https://gixy.io/plugins/return_bypasses_allow_deny/)
- [[ssl_ecdh_curve] 耐量子グループにより古い OpenSSL で NGINX が起動しなくなる](https://gixy.io/plugins/ssl_ecdh_curve/)
- [[ssl_stapling_letsencrypt] Let's Encrypt 証明書では OCSP ステープリングが機能しない](https://gixy.io/plugins/ssl_stapling_letsencrypt/)
- [[ssl_stapling_without_resolver] resolver がないと OCSP ステープリングがサイレントに失敗する](https://gixy.io/plugins/ssl_stapling_without_resolver/)
- [[ssrf] サーバーサイドリクエストフォージェリ](https://gixy.io/plugins/ssrf/)
- [[stale_dns_cache] proxy_pass で古い/期限切れのキャッシュ済み DNS レコードが使用される](https://gixy.io/plugins/stale_dns_cache/)
- [[status_page_exposed] status_page が外部に公開されていないことを確認する](https://gixy.io/plugins/status_page_exposed/)
- [[try_files_is_evil_too] open_file_cache なしでは `try_files` ディレクティブは有害](https://gixy.io/plugins/try_files_is_evil_too/)
- [[unanchored_regex] アンカーされていない正規表現](https://gixy.io/plugins/unanchored_regex/)
- [[unnamed_groups] rewrite のクエリ文字列における名前なしキャプチャグループ](https://gixy.io/plugins/unnamed_groups/)
- [[valid_referers] valid_referers における none/blocked](https://gixy.io/plugins/valid_referers/)
- [[version_disclosure] server_tokens に安全でない値を使用している](https://gixy.io/plugins/version_disclosure/)
- [[worker_rlimit_nofile_vs_connections] `worker_rlimit_nofile` は少なくとも `worker_connections` の2倍でなければなりません](https://gixy.io/plugins/worker_rlimit_nofile_vs_connections/)
何か検出されませんでしたか？不足している内容を添えてGitHubで[issue](https://github.com/MegaManSec/Gixy-Next/issues)を開いてください！
## 使用方法（フラグ）
`gixy`はデフォルトでシステムのNGINX設定を`/etc/nginx/nginx.conf`から読み込みます。`gixy`に場所を渡すことで指定することもできます：
```shell-session
# Analyze the configuration in /opt/nginx.conf
gixy /opt/nginx.conf
```
`--tests` を使用して、チェックのサブセットを絞り込んで実行できます:
```shell-session
# Only run these checks
gixy --tests http_splitting,ssrf,version_disclosure
```
`--skips` でいくつかのノイズの多いチェックをスキップします:
```shell-session
# Run everything except these checks
gixy --skips low_keepalive_requests,worker_rlimit_nofile_vs_connections
```
特定の重大度以上の問題のみを報告するには、複合的な `-l` フラグを使用します:
```shell-session
# -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` の値を指定します:
```shell-session
$ 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 出力を得ることもできます:
```shell-session
$ 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](https://sarifweb.azurewebsites.net/) ログを取得することもできます。たとえば、GitHub コードスキャンにアップロードする場合などに便利です:
```shell-session
# Write a SARIF report to a file, e.g. for `github/codeql-action/upload-sarif`
gixy -f sarif -o gixy-results.sarif
```
`gixy` に `--help` を渡すことで、使用可能なフラグの詳細を確認できます。また、[Usage Guide](https://gixy.io/usage/) にはさらに詳しい情報が記載されています。
## 設定とプラグインオプション
一部のプラグインは、CLI フラグまたは設定ファイルを通じて設定できるオプションを公開しています。詳細については、[Configuration guide](https://gixy.io/configuration/) を参照してください。
## NGINX のセキュリティとコンプライアンスのための Gixy-Next
構文チェックのみを行う `nginx -t` の実行とは異なり、Gixy-Next は実際に設定を分析し、強化されていないインスタンスや脆弱性を検出します。
Gixy-Next を使用すると、監査、コンプライアンス、または一般的なテストのいずれの目的であっても、変更のたびにローカルで実行できる自動化された NGINX 設定のセキュリティレビューを実施できます。これにより、不安定または低速な NGINX サーバーの防止に役立つ実用的な検出事項を生成し、安全でないディレクティブや安全でないデフォルト設定によるリスクを軽減できます。
## コントリビューション
Gixy-Next は [Joshua Rogers](https://joshua.hu) によって維持されていますが、コントリビューションはいつでも歓迎します！以下のようなさまざまな方法で支援できます：
- バグの報告。
- 検出用の新しいプラグインの提案。
- ドキュメントの改善。
- コードの修正、リファクタリング、改善、および新規コードの作成。
プルリクエストで変更を提出する前に、コントリビューションガイドライン文書 [Contributing to Gixy-Next](https://gixy.io/contributing/) をお読みください。
Gixy-Next の公式ホームページは [https://gixy.io/](https://gixy.io/) です。Gixy-Next のドキュメントへの変更は、自動的にそのウェブサイトに反映されます。
ソースコードは [https://github.com/MegaManSec/Gixy-Next](https://github.com/MegaManSec/Gixy-Next) にあります。
## Gixy とは何か？（背景）
_Gixy_ は、Yandex の Andrew Krasichkov によって[当初](https://github.com/yandex/gixy)開発された NGINX 設定アナライザーです。2017 年に最初にリリースされ、それ以来メンテナンスされていません。最新バージョンの Python をサポートしておらず、多数のバグを含み、その機能や脆弱な NGINX 設定を検出する能力には限界があります。現代のシステム上でオリジナルの Gixy を今日実行すると、次のエラーが発生します：
```text
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スロップ)を導入し、さらにコードに広告を追加しました。また、マージリクエストの形で貢献を受け入れていましたが、作者の情報を削除していました([こちらの](https://joshua.hu/gixy-ng-new-version-gixy-updated-checks#quality-degradation)投稿と[こちらの](https://joshua.hu/gixy-ng-ai-slop-gixy-next-maintained)投稿を参照)。
Gixy-Nextは品質の回復に焦点を当てており、約100,000行に及ぶNGINX設定で実戦テスト済みです。`gixy-ng` で導入された変更によって生じたバグや誤検出を修正し、AIツールの痕跡や不要物を除去し、コードベースをレビュー可能かつ保守可能に保つよう努めています。このフォークは、クリーンなコードと長期的な保守性に関心を持つ人々のためのものです。