Azure Websites で ModSecurity を使用して問題を診断する

このポストは、10 月 1 日に投稿された Diagnosing Issues with ModSecurity in Azure Websites の翻訳です。

Azure Websites で ModSecurity を使用する方法については、以前こちらの記事でもご紹介しました。ModSecurity のルールと構成は、特に外部ソースから特定のデータをコピーする場合などに、非常に複雑になることがあります。通常、ModSecurity を使用するときは、変更履歴を把握して障害を診断しやすいように、簡単な構成から始めてテストを繰り返し、徐々に構成を複雑にしていきます。この記事では、問題の原因を特定するためのヒントについて説明します。

ModSecurity が HTTP の要求および応答に対して実行している処理を把握する方法

SecRuleEngine を DetectionOnly に設定すると、受け取ったすべての要求をブロックすることなく、各ルールが実行する処理をテストできます。DetectionOnly に設定した場合は通常、イベント ログに出力が送信されます。この出力は Azure Websites からお客様のサイトの D:\home\LogFiles ディレクトリに転送されます。このログは FTP 経由でダウンロードすることが可能で、どのルールがトリガーされたかを確認することができます。

より詳細なログが必要な場合は、.conf file に次の構成オプションを追加します。

 SecDebugLog d:\home\site\wwwroot\modsecurity\logs
 SecDebugLogLevel 9

これはグローバル設定で、トラフィックがそれほど混雑していない場合であっても、お客様の Web サイトのパフォーマンスが大幅に低下する原因となる可能性があります。このため、サイトにトラフィックがまったくない場合を除いて、下記のような条件付きのデバッグ設定を使用することをお勧めします。

次のコードは、デバッグ ログを特定のクライアントの IP アドレスのみに限定する場合の例です。

 SecRule REMOTE_ADDR “@ipMatch 192.168.1.1″ “phase:1,id:1234,t:none,nolog,pass,ctl:debugLogLevel=9″

次のコードは、デバッグ ログを特定のパラメーターが要求内に存在する場合のみに限定する場合の例です。

 SecRule ARGS:debug_log “@streq on” “phase:1,id:1235,t:none,nolog,pass,ctl:debugLogLevel=9″

ログ レベルの詳細については、ModSecurity のドキュメント (英語) を参照してください。

注 : これらを設定すると、データがお客様のコンテンツ ディレクトリに書き込まれます。Web サイトのストレージに容量制限がある場合は、構成と要求の量によりこの制限に達する可能性があります。

自分で設定した ModSecurity ルールがトリガーされない場合

ルールがトリガーされない場合、次の手順に従って問題を診断します。

 

1. web.config ファイルは適切なものか

web.config ファイルの構成セクションが適切であることを確認します。また、複数の場所からセクションをコピーした場合は、XML が正しくマージされ、構成が適切なセクションに配置されていることを確認します。

 

2. ModSecurity の Include ファイルのパスは正しいか

OWASP CRS ルール (ModSecurity の Web サイトから無料で入手可能) では、.conf ファイルに Include ディレクティブが含まれています。これは他の .conf ファイルを指定してインクルードするためのもので、このファイルをそのまま使用する場合、Include d:\home\sites\wwwroot\ のように Include ディレクティブの場所の指定を編集する必要があります。

 

3. トリガーされないのは特定のルールのみか

ModSecurity が各ルールで HTTP の各要求および応答に対してどのような処理を実行しているかを診断するときには、SecDebugLog の設定を使用します。この設定では、上の例と同様に特定のルールに対して ctl:debugLogLevel=9 を設定すると、このルールに関する問題を診断できます。