ブログ | NGINX

モッドセキュリティ: ログとデバッグ

NGINX-F5 水平黒タイプ RGB の一部
ファイサル・メモン サムネイル
ファイサル・メモン
2017 年 10 月 22 日公開

ModSecurity は、何よりも可視性の問題を解決し、Web トラフィックを確認できるため、安心して眠れるようになります。

– Ivan Ristic 氏、ModSecurity 作成者

 

何かが期待どおりに動作しない場合は、常に最初にログを確認します。 適切なログは、直面している問題のトラブルシューティングに役立つ貴重な洞察を提供します。 Ivan Ristić が ModSecurity を最初に作成した理由の 1 つは、使用していたツールの可視性の欠如に不満を感じていたことです。 したがって、ModSecurity に広範なログ記録およびデバッグ機能が備わっているのは驚くことではありません。

ModSecurity には 2 種類のログがあります。

  • 監査ログ。 ブロックされたすべてのトランザクションについて、ModSecurity はトランザクションに関する詳細なログとブロックされた理由を提供します。
  • デバッグ ログ。 このログをオンにすると、ModSecurity が実行するすべての操作に関する詳細な情報が保存されます。

監査ログは、個々の攻撃がブロックされた理由を知るだけでなく、全体的な攻撃パターンについてさらに詳しく知るのに役立ちます。 ポート 80 や 443 をインターネットに公開するだけで、ボットやスキャナーのトラフィックがどれだけ発生するかに驚かれるかもしれません。

このブログ記事では、ModSecurity を使用したログ記録とデバッグの基本について説明します。

監査ログ

ModSecurity の主なログは監査ログであり、発生するすべての攻撃 (潜在的な攻撃を含む) が記録されます。 ModSecurity( NGINX Open Sourceを使用)またはNGINX ModSecurity WAF( NGINX Plusを使用)のインストール手順に従っている場合、デフォルトでは、ModSecurityは警告またはエラーをトリガーしたすべてのトランザクションと、 5xxおよび4xx応答をもたらしたすべてのトランザクションをログに記録します。404 。 (Ubuntu 16.04 システムの場合のみ、監査ログは/var/log/modsec_audit.logにあります。)

ModSecurity 監査ログはセクションに分割されています。 これにより、ログをスキャンして必要な情報を簡単に見つけることができます。 以下の表に、各セクションの内容を示します。

セクション 説明
監査ログ ヘッダー (必須)
B リクエストヘッダー
リクエスト本文
予約済み
レスポンス本文
レスポンスヘッダー
予約済み
H 追加データを含む監査ログトレーラー
ファイルを除外するコンパクトなリクエスト本文の代替(パートC)
J アップロードされたファイルに関する情報
トランザクションに一致したすべてのルールのリストが含まれます
最終境界(必須)

監査ログ エントリをトリガーする各トランザクションでは、上記のセクションの一部またはすべてがログに記録されます。 ログに記録するセクションを設定できます。

監査ログの例

ModSecurity 監査ログ エントリの例は次のようになります。

---ICmPEb5c---A--[04/Oct/2017:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80
---ICmPEb5c---B--
GET / HTTP/1.1
ホスト: 54.183.57.254
ユーザーエージェント: Mozilla/5.0 zgrab/0.x
Accept-Encoding: gzip

---ICmPEb5c---D--

---ICmPEb5c---F--
HTTP/1.1 200
サーバー: nginx/1.13.4
日付: 2017 年 10 月 4 日水曜日 21:45:15 GMT
コンテンツ タイプ: text/html
接続: keep-alive

---ICmPEb5c---H--
ModSecurity: 警告。 変数 `REQUEST_HEADERS:Host' (値: `54.183.57.254') に対してパラメータ `^[d.:]+$' を持つ「演算子 `Rx'」が一致しました [ファイル "/root/owasp
-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [行 "733"] [ID "920350"] [リビジョン "2"] [メッセージ "ホスト ヘッダーは数値の IP アドレスです"] [データ "54.183.57.254"] [重大度 "4"] [バージョン "OWASP_CRS/3.0.0"] [成熟度 "9"] [精度 "9"] [タグ "application-multi"] [タグ "language-multi"] [タグ "platform-multi"] [タグ "attack-prot
ocol"] [タグ"OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [タグ "WASCTC/WASC-21"] [タグ "OWASP_TOP_10/A7"] [タグ "PCI/6.5.10"] [ref "o0,13v21,13"]

---ICmPEb5c---I--

---ICmPEb5c---J--

---ICmPEb5c---Z--

上記の表からはすぐには分かりませんが、特定のリクエストがブロックされた理由に関する情報を見つけるのに最適なセクションは、セクション K ではなくセクション H です。上記の監査ログの例では、セクション H をスキャンすると、 「ホスト ヘッダーは数値 IP アドレスです」というメッセージが表示され、誰かがホスト名ではなく IP アドレスでサイトにアクセスしようとしたことがわかります。 これはスキャナーを示している可能性があります。

監査ログの構成

ModSecurity のインストールと設定の手順に従っている場合は、監査ログ設定が/etc/nginx/modsec/modsecurity.confにあります。 このファイルには、監査ログに記録される内容を制御する次の 3 つのディレクティブがあります。

SecAuditEngine 関連のみ SecAuditLog 関連ステータス "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ

どこ

  • SecAuditEngine – ログに記録する内容を制御します。 オプションは次のとおりです:

    • オフ– 監査ログを無効にします。
    • オン– すべてのトランザクションをログに記録します。これはデバッグ時に役立ちます。
    • RelevantOnly – 警告/エラーをトリガーしたトランザクション、またはSecAuditLogRelevantStatusディレクティブの内容と一致するステータス コードを持つトランザクションのみをログに記録します。
  • SecAuditLogRelevantStatus – SecAuditEngine がRelevantOnlyに設定されている場合、このディレクティブはどの HTTP 応答ステータス コードをログに記録するかを制御します。 正規表現ベースです。 上記の値は、 5xx4xxの応答をすべて記録しますが、404 s。

  • SecAuditLogParts – アクセス ログに含めるセクションを制御します。 関心のないセクションを削除すると、監査ログのサイズが小さくなり、スキャンしやすくなります。

追加の監査ログ構成ディレクティブについては、 ModSecurity wikiを参照してください。

デバッグログ

デバッグ ログをオンにすると、ModSecurity が実行するすべての操作に関する豊富な情報が提供されます。 何かが期待どおりに動作しない理由に関する問題のトラブルシューティングには、デバッグ ログが頼りになるリソースです。 また、ModSecurity を使い始めて、なぜ特定の方法で動作するのかを確認したい場合にも最適です。

デバッグログの例

デバッグログは次のようになります。 ModSecurity があらゆるトランザクションに対して実行するアクションに関する詳細が多数記載されています。

[4] (ルール: 1234) ARGS:testparam.[9]に対してパラメータ「test」で演算子「Contains」を実行しています。ターゲット値:「test」(変数: ARGS:testparam)
[9] 一致した変数が更新されました。
[4] [独立] (非破壊的) アクションを実行中: log
[9] トランザクションをログに保存中
[4] ルールが 1 を返しました。
[9] (SecDefaultAction) アクションを実行中: log
[9] トランザクションをログに保存中
[9] (SecDefaultAction) アクションを実行中: Auditlog
[4] (SecDefaultAction) アクションを無視: pass (ルールに破壊的アクションが含まれています)
[4] (非破壊的) アクションを実行中: Auditlog
[4] (破壊的) アクションを実行中: deny

デバッグ ログには、簡単に検索できるようにルール ID 番号がリストされます。 この例では、出力は ID 番号 1234 のテスト ルールからのものになります。

デバッグログの設定

デバッグ ログはパフォーマンスに悪影響を与える可能性があるため、デフォルトでは無効になっています。 監査ログと同様に、デバッグ ログは/etc/nginx/modsec/modsecurity.confで構成されます。 そのファイルには、コメントアウトされた 2 つの構成ディレクティブがあります。 デバッグ ログを有効にするには、コメントを解除して次のように変更します。

SecDebugLog /var/log/modsec_debug.logSecDebugLogレベル 9

どこ

  • SecDebugLog – デバッグ ログ ファイルへのパスを指定します。
  • SecDebugLogLevel –09ログに記録する情報の量を示します。9最も多いです。 トラブルシューティングを行う場合は、この値を9最も役立ちます。

結論

このブログ記事では、ModSecurity 内の広範なログ機能の使用を開始する方法について説明しました。 ModSecurity には、ブロックされたすべてのトランザクションに関する情報を含む監査ログと、ModSecurity の使用中に問題が発生した場合にさらに役立つデバッグ ログの両方があります。

ModSecurity 3.0 は、NGINX Open Source と NGINX Plus 用のNGINX ModSecurity WAFの両方で利用できます。 NGINX ModSecurity WAF は、NGINX, Inc. によって保守および完全にサポートされている、事前コンパイルされた動的モジュールです。 30日間無料でお試しください

[編集者注– NGINX ModSecurity WAF は、2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF はサポート終了に移行しています<.htmla>」をご覧ください。


「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"