
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 -
ウェブベースのスキャナー
Gixy-Nextをローカルにダウンロードして実行する代わりに、このウェブページを使用して、ウェブブラウザから設定をスキャンできます(WebAssemblyを使用してローカルで)。
Dockerでスキャン
Gixy-NextはDocker HubまたはGitHub RegistryからDockerイメージとして入手できます。
ローカルの設定ファイルをコンテナにマウントしてスキャンします:
# 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] add_headerによるContent-Typeの設定
- [add_header_multiline] 複数行のレスポンスヘッダー
- [add_header_redefinition] "add_header"ディレクティブによるレスポンスヘッダーの再定義
- [alias_traversal] 設定不備のaliasによるパストラバーサル
- [allow_without_deny] denyなしで指定されたallow
- [default_server_flag] default_serverフラグの欠落
- [error_log_off]
error_logがoffに設定されている - [hash_without_default] hashブロックにdefaultがない
- [host_spoofing] リクエストのHostヘッダーの偽装
- [http2_misdirected_request] HTTP/2のmisdirected-request対策の欠落
- [http_splitting] HTTPレスポンス分割
- [if_is_evil] locationコンテキストで使用された場合のIf is evil
- [invalid_regex] 無効な正規表現キャプチャグループ
- [low_keepalive_requests]
keepalive_requestsが低い - [missing_worker_processes]
worker_processesの欠落 - [mixed_case_variable] 大文字小文字が混在した変数参照
- [origins] referer/originヘッダー検証の問題
- [overlapping_captures] rewriteリダイレクト/引数コンテキストでのキャプチャの重複
- [proxy_buffering_off]
proxy_bufferingの無効化 - [proxy_pass_normalized]
proxy_passのパス正規化の問題 - [proxy_set_header_redefinition] "proxy_set_header"ディレクティブによるプロキシリクエストヘッダーの再定義
- [quic_bpf_reuseport] リロード後にQUIC接続がサイレントにドロップされる
- [regex_redos] 正規表現サービス拒否 (ReDoS)
- [resolver_external] 外部DNSネームサーバーの使用
- [return_bypasses_allow_deny] returnディレクティブがallow/deny制限をバイパスする
- [ssl_ecdh_curve] ポスト量子グループにより古いOpenSSLでNGINXが起動しなくなる
- [ssl_stapling_letsencrypt] Let's Encrypt証明書ではOCSPステープリングが機能しない
- [ssl_stapling_without_resolver] resolverなしではOCSPステープリングがサイレントに失敗する
- [ssrf] サーバーサイドリクエストフォージェリ
- [stale_dns_cache] proxy_passで使用される古い/陳腐化したキャッシュDNSレコード
- [status_page_exposed] status_pageが外部に公開されていないことを確認する
- [try_files_is_evil_too] open_file_cacheなしでは
try_filesディレクティブは悪 - [unanchored_regex] アンカーされていない正規表現
- [unnamed_groups] rewriteクエリ文字列内の名前のないキャプチャグループ
- [valid_referers] valid_referersにおけるnone/blocked
- [version_disclosure] server_tokensに安全でない値を使用している
- [worker_rlimit_nofile_vs_connections]
worker_rlimit_nofileは少なくともworker_connectionsの2倍でなければならない
検出されないものがありますか?何が不足しているかを添えてGitHubでissueを開いてください!
使用方法(フラグ)
gixyはデフォルトでシステムのNGINX設定を/etc/nginx/nginx.confから読み取ります。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によってメンテナンスされていますが、コントリビューションはいつでも歓迎します!以下のようなさまざまな方法で支援できます:
- バグの報告。
- 検出用の新しいプラグインの提案。
- ドキュメントの改善。
- コードの修正、リファクタリング、改善、および新しいコードの作成。
プルリクエストで変更を提出する前に、コントリビューションガイドライン文書Contributing to Gixy-Nextをお読みください。
Gixy-Nextの公式ホームページはhttps://gixy.io/です。Gixy-Nextのドキュメントへの変更は自動的にそのウェブサイトに反映されます。
ソースコードはhttps://github.com/MegaManSec/Gixy-Nextにあります。
Gixyとは?(背景)
_Gixy_は、YandexのAndrew Krasichkovによって元々開発されたNGINX設定アナライザーです。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ツールの成果物/ジャンクを削除し、コードベースをレビュー可能かつ保守可能に保つよう努めています。このフォークは、クリーンなコードと長期的な保守性に関心のある人々のためのものです。
