Freigeben über

Azure WebSites で Web アプリケーション ファイアウォールの ModSecurity をサポート

  • Artikel

このポストは、9 月 29 日に投稿された ModSecurity Web Application Firewall on Azure Websites の翻訳です。

Microsoft Azure WebSites で、お客様の Web サイト向けに Web アプリケーション ファイアウォールの ModSecurity をご利用いただけるようになりました。これにより、カスタムのアプリケーション ファイアウォール ルールを作成するか、商用のルールを利用して、Web アプリケーションを Web の脆弱性や悪用から保護できます。

ModSecurity とは

ModSecurity はオープン ソースのクロスプラットフォーム Web アプリケーション ファイアウォール (WAF) モジュールです。このアプリケーションは WAF の「アーミー ナイフ」としても知られていて、Web アプリケーションの防御機構が HTTP(S) のトラフィックの内容を把握することができ、また強力なルール言語と API で高度な保護機能を実装可能です。ModSecurity は、IIS や ASP.NET 要求のフィルタリングまたは UrlScan と同様の、受信する HTTP 要求や送信する HTTP 応答をフィルタリングするルールを作成するための非常にリッチな構文をサポートするツールです。ModSecurity ではイベントに基づくプログラム言語構文が使用されており、ユーザーがさまざまな演算子 (正規表現など) を使用する「SecRules」を定義して、受信側および送信側の HTTP(S) データを検査できます。詳細については、https://www.modsecurity.org/ (英語) をご覧ください。

ModSecurity が必要な理由

ModSecurity にはさまざまなメリットがありますが、主な使用目的の 1 つとして「仮想的な修正プログラムの適用」があります。これは、既知の脆弱性の悪用を防ぐ目的でセキュリティ ポリシーを強制適用するためのレイヤーで、脆弱性の悪用を Web アプリケーションのロジックと切り離してフィルタリングすることができます。たとえば、自動化された SQL インジェクション攻撃が発生した場合、お客様の Web アプリケーションのコードに SQL インジェクションのバグがないことが確認されているとしても、ModSecurity ルールを容易に構成してこれらの要求がお客様のアプリケーションのロジックに影響しないようにフィルタリングすることができます。

ModSecurity を Azure WebSites で使用する方法

ModSecurity を Azure WebSites で使用するには、次の構成用のコードをお客様のアプリケーションの web.config ファイルに追加するだけです。

 <configuration>
<system.webServer>
<ModSecurity enabled=”true” configFile=”D:\home\site\wwwroot\secrules.conf” />
< /system.webServer>
</configuration>

Azure WebSites では、D:\home\site\wwwroot がお客様の Web サイトのルート ディレクトリになります。上記の configFile 属性はこのサイトで使用する ModSecurity の構成ファイルを指定するもので、この構成ファイルに記述されている ModSecurity の設定とルールが適用されます。

さらに、通常 ModSecurity はサービスを提供することを意図していないディレクトリに格納されている各種ファイルに対する読み書きを実行するように構成されています。これらのファイルのサービスをブロックするには、web.config ファイルに次の構成を追加します。

 <configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<add segment=”modsecurity” />
< /hiddenSegments>
<fileExtensions>
<add fileExtension=”.conf” allowed=”false” />
< /fileExtensions>
</requestFiltering>
</security>
</system.webServer>
</configuration>

これで、コンテンツ ディレクトリ内の ModSecurity ディレクトリへの要求がブロックされ、クライアントに提供されないようになります。

ModSecurity の .conf ファイルの内容

ModSecurity のコア ルール セットは、https://www.modsecurity.org/rules.html (英語) で入手できます。このコア ルール セットは無料で使用可能で、商用のルールは有料となっています。コア ルール セットをダウンロードすると、.conf ファイルの内容について知ることができます。以下は、secrules.conf という構成ファイルの非常に基本的な構成例です。

 SecRuleEngine DetectionOnly
SecRequestBodyAccess Off
SecTmpDir d:\home\site\wwwroot\modsecurity\temp\
SecDataDir d:\home\site\wwwroot\modsecurity\temp\
SecRule REQUEST_URI|ARGS “bad_arg” “log,deny,id:12345,msg:’Access Denied’”

SecRuleEngine の設定は、ルールがトリガーされたときの ModSecurity の動作を指定します。これを DetectionOnly に設定すると、要求や応答はブロックされず、ただイベント ログに記録されます。このログを見ると、ユーザーはどのルールがトリガーされ、ユーザーの要求に含まれていないものはどれかを確認できます。この値を On に設定するとブロックが有効になり、Off に設定するとルールが完全に無視されます。

SecRequestBodyAccess オプションは、ModSecurity のルールが、そのルールの一部として要求の本文へのアクセスを許可するかどうかを指定します。ご想像のとおり、これを Off にするとメモリと CPU のパフォーマンスが向上しますが、その代わりに HTTP 要求の本文に対してルールの評価を行うことはできなくなります。要求の本文全体をスキャンする機能は IIS の要求のフィルタリングにはない ModSecurity 独自の機能です。エンティティ本文を分析するための独自のルールをお持ちの場合は、この設定を On にします。

SecTmpDir および SecDataDir では、ModSecurity が一時データや永続的なデータを保存するディレクトリを設定します。

SecRule の行は実際のフィルタリング ルールで、受信側の HTTP 要求の REQUEST_URI および ARGS (クエリ文字列のパラメーター) に対して処理を実行します。任意の場所で「bad_arg」という文字列が検出された場合、「log,deny,msg:’Access Denied’」というアクションが実行されます。これは、基本的には要求を拒否しログ ファイルにアクセスが拒否されたことを示すログを記録するものです。

すべてのオプションとその詳細な説明については、ModSecurity のドキュメント (英語) をご覧ください。

OWASP CRS ルールの概要とその使用方法

OWASP ModSecurity コア ルール セット (CRS) は、Web アプリケーションの未知の脆弱性からの一般的な保護を行うものです。この保護機能の一部は、http.sys や IIS による要求のフィルタリング、または Web アプリケーションのロジックなど、他のレイヤーでも提供されています。このルール セットは汎用的なものであるため、サイトの管理者や開発者は必要に応じてこのルールの追加、削除、変更を行い、お客様が保護するアプリケーションに適したものにカスタマイズする必要があります。

コア ルール セットの構成ファイルは、ModSecurity Web サイトのこちらのページ (英語) からダウンロードできます。ダウンロードした zip ファイルには、多数の .conf ファイルや .data ファイルが含まれたフォルダーがあります。それぞれの .conf ファイルには 1 つまたは複数のルールが含まれていて、ルール カテゴリ別に分類されています。コンテンツ フォルダーに modsecurity\rules ディレクトリを作成し、そこに zip ファイルに含まれているファイルとフォルダーをすべてコピーします。この手順では、FTP や、Microsoft Web Deploy などの他の方法を使用することもできます。ファイルをコピーしたら、前の手順で構成した web.config の .conf ファイルの指示によりルールを有効化することができます。たとえば、slr_rules ディレクトリの wordpress ルールに格納し、その他のすべてのルールを base_rules ディレクトリに格納している場合、secrules.conf ファイルの冒頭に次の行を追加します。

 Include d:\home\site\wwwroot\modsecurity\rules\base_rules\*.conf
Include d:\home\site\wwwroot\modsecurity\rules\slr_rules\modsecurity_crs_46_slr_et_wordpress_attacks.conf

一部の .conf ファイルにはコメントが入れてあり、参照先の .data ファイルを更新することができます。たとえば、base_rules ディレクトリの modsecurity_crs_35_bad_robots.conf は modsecurity_35_bad_robots.data というファイルを参照します。このファイルには、ブロック対象の User-Agent のリストが含まれています。コア ルール セットには modsecurity_iis.conf ファイルも含まれていて、これを使用するとすべての CRS ルールをお客様のサイトでセットアップできます。

ModSecurity の使用の制限事項

現在、ModSecurity モジュールは Free レベルも含めて Azure WebSites のすべてのカテゴリでご利用いただけます。ただし、このモジュールは Azure WebSites の IIS のワーカー プロセスで実行されています。このため、ワーカー プロセスに適用される各種制限は、同様に ModSecurity にも適用されます。このため、Free 料金レベルではサイトの 1 日あたりの CPU 使用時間に制限があるので、ワーカー プロセスで実行されている ModSecurity にもこれが適用されます。

ModSecurity そのものは、ルールを構成しないと大きな効果は期待できません。この点では、既定のルールが構成されていないという違いがありますが、IIS の要求のフィルタリング機能と同様です。これらのルールはユーザー自身が追加する必要があります。下記のブログの説明に従って基本構成をセットアップするか、OWASP のコア ルール セットを使用します。ルールの複雑さやどのような HTTP 要求/応答に対して処理を実行するかによって、Web サイトのパフォーマンスに影響が出ることもあります。このため、ルールが HTTP 要求/応答との照合を行う際のオーバーヘッドを抑制するように、ルールはできるだけ絞り込むことをお勧めします。

ModSecurity ルールを確認したい場合は、ModSecurity 認証ブログ (英語) を参照してください。