ModSecurity：ログ記録とデバッグ

Faisal Memonソフトウェアエンジニア

「ModSecurityがあれば、夜も安心して眠れるようになります。何よりも、可視性の問題を解決し、Webトラフィックを確認できるようになるからです」

— Ivan Ristić（ModSecurity開発者）

何かが期待どおりに動作しない場合、まず確認すべきなのはログです。適切なログからは、直面している問題のトラブルシューティングに役立つ貴重な情報を得られます。Ivan RistićがModSecurityを開発した当初の理由の1つは、使用していたツールでは十分な可視性が得られず、不満を感じていたことでした。そのため、ModSecurityが充実したロギング機能とデバッグ機能を備えているのも不思議ではありません。

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

• 監査ログ。ModSecurityは、ブロックしたすべてのトランザクションについて、その詳細とブロックした理由をログに記録します。
• デバッグログ。有効にすると、ModSecurityが実行するすべての処理に関する詳細な情報が記録されます。

監査ログは、個々の攻撃がブロックされた理由だけでなく、攻撃パターンの全体像を詳しく把握するうえでも役立ちます。ポート80または443、あるいはその両方をインターネットに公開するだけで、予想以上に多くのボットやスキャナーからのトラフィックが発生することがあります。

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

監査ログ

ModSecurityの主要なログは監査ログです。発生した攻撃は、潜在的な攻撃も含め、すべてこのログに記録されます。ModSecurity（NGINX Open Sourceを使用）またはNGINX ModSecurity WAF（NGINX Plusを使用）についてF5のインストール手順に従った場合、デフォルトでは、警告またはエラーが発生したすべてのトランザクションに加え、5xxおよび4xxレスポンスとなったすべてのトランザクションがModSecurityによって記録されます。ただし、404は除きます。（Ubuntu 16.04システムの場合に限り、監査ログは/var/log/modsec_audit.logにあります。）

ModSecurityの監査ログは複数のセクションに分かれているため、ログを確認して必要な情報を見つけやすくなっています。各セクションの内容を以下の表に示します。

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

監査ログの例

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.1Host: 54.183.57.254User-Agent: Mozilla/5.0 zgrab/0.xAccept-Encoding: gzip---ICmPEb5c---D-----ICmPEb5c---F--HTTP/1.1 200Server: nginx/1.13.4Date: Wed, 04 Oct 2017 21:45:15 GMTContent-Type: text/htmlConnection: keep-alive---ICmPEb5c---H--ModSecurity: Warning. Matched "Operator `Rx' with parameter `^[d.:]+$' against variable `REQUEST_HEADERS:Host' (Value: `54.183.57.254' ) [file "/root/owasp-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "733"] [id "920350"] [rev "2"] [msg "Host header is a numeric IP address"] [data "54.183.57.254"] [severity "4"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [ref "o0,13v21,13"]---ICmPEb5c---I-----ICmPEb5c---J-----ICmPEb5c---Z--

上の表からはすぐには分かりませんが、特定のリクエストがブロックされた理由を確認するには、セクションKではなくセクションHが最適です。上記の監査ログの例でセクションHを確認すると、"Host header is a numeric IP address"というメッセージがあります。これは、誰かがホスト名ではなくIPアドレスを使用してサイトにアクセスしようとしたことを示しています。スキャナーによるアクセスの可能性があります。

監査ログの設定

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

SecAuditEngine RelevantOnlySecAuditLogRelevantStatus "^(?:5|4(?!04))"SecAuditLogParts ABIJDEFHZ

ここで

• SecAuditEngine – ログに記録する内容を制御します。オプションは次のとおりです。
  • Off – 監査ログを無効にします。
  • オン – すべてのトランザクションをログに記録します。デバッグ時に役立つ場合があります。
  • RelevantOnly – 警告またはエラーが発生したトランザクション、あるいはステータスコードがSecAuditLogRelevantStatusディレクティブの指定と一致するトランザクションのみをログに記録します。
• SecAuditLogRelevantStatus – If SecAuditEngine is set to RelevantOnly, then this directive controls what HTTP response status codes should be logged. It’s regular expression‑based. The above value will log all 5xx and 4xx responses, excluding 404s.
• SecAuditLogParts – アクセスログに含めるセクションを制御します。不要なセクションを削除すると、監査ログのサイズが小さくなり、確認しやすくなります。

監査ログに関するその他の設定ディレクティブについては、ModSecurity wikiを参照してください。

デバッグログ

デバッグログを有効にすると、ModSecurityのあらゆる動作に関する豊富な情報を確認できます。期待どおりに動作しない原因をトラブルシューティングする際は、まずデバッグログを参照してください。また、ModSecurityを使い始めたばかりで、特定の動作をする理由を確認したい場合にも役立ちます。

デバッグログの例

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

[4] (Rule: 1234) Executing operator "Contains" with param "test" against ARGS:testparam.[9] Target value: "test" (Variable: ARGS:testparam)[9] Matched vars updated.[4] Running [independent] (non-disruptive) action: log[9] Saving transaction to logs[4] Rule returned 1.[9] (SecDefaultAction) Running action: log[9] Saving transaction to logs[9] (SecDefaultAction) Running action: auditlog[4] (SecDefaultAction) ignoring action: pass (rule contains a disruptive action)[4] Running (non-disruptive) action: auditlog[4] Running (disruptive)     action: deny

デバッグログには、検索しやすいようにルールID番号が記載されます。この例では、ID番号1234のテストルールからの出力です。

デバッグログの設定

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

SecDebugLog /var/log/modsec_debug.logSecDebugLogLevel 9

ここで

• SecDebugLog – デバッグログファイルへのパスを指定します。
• SecDebugLogLevel – 0～9は、ログに記録する情報量を示します。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ブログの「F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla>」をご覧ください。］

著者について

Faisal Memonソフトウェアエンジニア

Faisal Memonのその他のブログ記事