Red Hat SummitRed Hat JBoss Core Services ModSecurity ガイド
Red Hat JBoss ミドルウェア製品との使用
概要
Red Hat ドキュメントへのフィードバック (英語のみ)
エラーを報告したり、ドキュメントを改善したりするには、Red Hat Jira アカウントにログインし、課題を送信してください。Red Hat Jira アカウントをお持ちでない場合は、アカウントを作成するように求められます。
手順
- このリンクをクリック してチケットを作成します。
- Summary に課題の簡単な説明を入力します。
- Description に課題や機能拡張の詳細な説明を入力します。問題があるドキュメントのセクションへの URL を含めてください。
- Submit をクリックすると、課題が作成され、適切なドキュメントチームに転送されます。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 ModSecurity の概要
1.1. 概要
本ガイドには、Red Hat JBoss Core Services 2.4.51 と使用する ModSecurity v2.9 モジュールに関する情報および例が含まれています。ModSecurity の有効性は、ユーザーが生成したルールに基づいています。そのため、このガイドではルールの作成および実装方法を説明しますが、使用するルールのセットは提供しません。
1.2. ModSecurity
ModSecurity は Web アプリケーションのファイアウォール (WAF) です。Web アプリケーションのファイアウォールは、Web アプリケーションへの HTTP トラフィックをフィルター、監視、およびブロックします。通常のファイアウォールとは異なり、WAF はフィルターを使用して HTTPD サーバーアプリケーションと対話するものを決定します。ModSecurity は、ユーザーが生成したセキュリティールールを使用してこのタスクを実行します。これらのルールにより、HTTP トラフィックの設定可能なリアルタイム監視が可能になり、攻撃を即時に検出できます。
第2章 ModSecurity 設定
2.1. RHEL の設定
2.1.1. 依存関係
ModSecurity には、機能させる依存関係が複数あります。これらの一部は、Red Hat JBoss Core Services の一部としてすでに含まれています。以下の完全リストは以下を参照してください。
| 依存関係 | JBCS の一部 |
|---|---|
| Apache ポート可能なランタイム | Y |
| APR-Util | Y |
| mod_unique_id | Y |
| libcurl | Y |
| PCRE | Y |
| libxml2 | N |
| lua5.x | N |
Red Hat JBoss Core Services for windows に libxml2 および Lua5.x が含まれます。
2.1.2. Red Hat JBoss Core Services でのインストール
ModSecurity は Red Hat JBoss Core Services パッケージの一部として提供されます。Red Hat JBoss Core Services のインストールに関する詳しい手順は、JBCS のインストールガイドを 参照してください。
2.1.3. 初期設定
ModSecurity は Red Hat JBoss Core Services の一部として含まれています。つまり、ModSecurity は事前設定されており、apxs ツールを使用してモジュールのビルドとインストールを行う必要はありません。Mod_sec をさらに設定するには、HTTPD にモジュールをロードする必要があります。
2.1.3.1. ModSecurity の開始
ModSecurity モジュールを読み込む前に、libxml2 ライブラリーおよび lua5.1 ライブラリーを読み込む必要があります。以下のコマンドを使用してライブラリーを読み込みます。
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
次に、以下を使用して ModSecurity モジュールをロードします。
LoadModule security2_module modules/mod_security2.so
2.1.3.2. ルールフォルダーの設定
ModSecurities 機能のバックボーンは、システムが使用するルールの作成です。ただし、それらを使用するには、ルールを保存する場所を知っている必要があります。JBCS には HTTPD_HOME/modsecurity.d に位置する事前に設定したフォルダーが含まれます。ルールは、このフォルダーまたはその下にある activated_rules フォルダーに保存できます。
さらに、これらのルールを使用するには、mod_security.conf.sample ファイルを仕様に設定する必要があります。最も重要な点は、ファイル名 を mod_security.conf に変更 しなければならない ところです。これは、以下のコマンドで実行できます。
mv mod_security.conf.sample ./mod_security.conf
ファイル自体では、ModSecurity ルールで使用するすべての設定ディレクティブにパラメーターを設定できます。
2.1.3.3. PCRE 警告
Apache では、バンドル化された PCRE ライブラリーの使用と、オペレーティングシステムが提供するものリンクを避ける必要があります。これを行う最も簡単な方法は、オペレーティングシステムが提供する PCRE ライブラリーに対して Apache をコンパイルすることです (または、メインの PCRE ディストリビューションサイトからダウンロードした最新の PCRE バージョンに対してコンパイルすることもできます)。これは、--with-pcre スイッチを使用して設定時に実行できます。Apache を再コンパイルしない場合は、ModSecurity を正常にコンパイルするには、バンドル化された PCRE ヘッダーへのアクセスが依然として必要になります (Apache ソースコードでのみ利用可能です)。また、ステップ 7 で行ったように ModSecurity の include パスを変更して、--with-pcre ModSecurity 設定オプションで、ヘッダーを指定します。Apache が外部の PCRE ライブラリーを使用している場合は、WITH_PCRE_STUDY で定義されている ModSecurity をコンパイルできます。これにより、正規表現処理でパフォーマンスをより若干向上できる可能性があります。gcc 以外のコンパイラーでは、現在のビルドシステムが gcc コンパイラーで設計されており、一部のコンパイラー/リンカーフラグが異なるため、追加設定なしの実行で問題が発生する可能性があります。gcc 以外のコンパイラーを使用するには、カスタムの CFLAGS 環境変数および CPPFLAGS 環境変数をエクスポートして問題が解決できない場合に、手動による Makefile 変更が必要になる場合があります。
2.1.3.4. キー設定オプション
enable-pcre-jit: 正規表現のパフォーマンスを向上できる pcre >= 8.20 からの JIT サポートを有効にします。
enable-lua-cache: lua スクリプトのパフォーマンスを改善できる lua 仮想マシンのキャッシュを有効にします。ModSecurity がトランザクションごとに複数のスクリプトを実行する必要がある場合にのみ違いがあります。
Enable-request-early : ModSecurity 2.6 では、フェーズ 1 がフェーズ 2 フックに移動されました。それを回避したい場合は、このオプションを使用してください。
enable-htaccess-config: AllowOverride Option が設定されている場合に、以下のディレクティブを .htaccess ファイルで使用できます。
2.2. Windows の設定
2.2.1. Windows 依存関係
ModSecurity には Windows で機能する依存関係が複数あります。これらの一部は、Red Hat JBoss Core Services の一部としてすでに含まれています。以下の完全リストは以下を参照してください。
| 依存関係 | Windows 上の JBCS の一部 |
|---|---|
| Apache ポート可能なランタイム | Y |
| APR-Util | Y |
| mod_unique_id | Y |
| libcurl | Y |
| PCRE | Y |
| libxml2 | Y |
| lua5.x | Y |
2.2.2. Windows Installation
Windows での ModSecurity の実行に必要なアイテムの多くは JBCS パッケージにすでに含まれています。ただし、ModSecurity が正しく動作するには、特定の条件を満たす必要があります。ソースからソフトウェアを構築するディレクトリーには、Apache Web サーバーと ModSecurity ソースの構築に使用する Apache ソースが含まれます。以下に例を示します。
-
Apache ソースは
C:\ sourceDirectory\httpd-2.4.51にあります。 -
Apache が
C:\Apache2451にインストールされています -
ModSecurity ソースが
C:\ sourceDirectory\mod_securityにあります
この場合、sourceDirectory はプロジェクトとともに使用する汎用ディレクトリーです。
さらに、ビルド環境に正しい設定があることを確認します。PATH 環境変数には、vsvars32.bat や CMAKE bin\ ディレクトリーに設定される Visual Studio 変数が含まれる必要があります。最後に、Apache ソースコードディレクトリー C:\ sourceDirectory\httpd-2.4.51 に環境変数を設定します。
上記の基準を満たしたら、お使いの C: ドライブの適切な場所に JBCS をインストールできます。
ModSecurity は Red Hat JBoss Core Services パッケージの一部として提供されます。Red Hat JBoss Core Services のインストールに関する詳しい手順は、JBCS のインストールガイドを 参照してください。
2.2.3. Windows の設定
2.2.3.1. ModSecurity の開始
ModSecurity モジュールを読み込む前に、libxml2 ライブラリーおよび lua5.1 ライブラリーを読み込む必要があります。以下のコマンドを使用してライブラリーを読み込みます。
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
次に、以下を使用して ModSecurity モジュールをロードします。
LoadModule security2_module modules/mod_security2.so
2.2.3.2. ルールディレクトリーの設定
ModSecurities 機能のバックボーンは、システムが使用するルールの作成です。ただし、それらを使用するには、ルールを保存する場所を知っている必要があります。JBCS には HTTPD_HOME/modsecurity.d にある事前設定されたディレクトリーが含まれています。ルールは、このディレクトリーまたはその下にある active_rules ディレクトリーに保存できます。
さらに、これらのルールを使用するには、mod_security.conf.sample ファイルを仕様に設定する必要があります。最も重要な点は、ファイル名 を mod_security.conf に変更 しなければならない ところです。
2.2.3.3. キー設定オプション
enable-pcre-jit: 正規表現のパフォーマンスを向上できる pcre >= 8.20 からの JIT サポートを有効にします。
enable-lua-cache: lua スクリプトのパフォーマンスを改善できる lua 仮想マシンのキャッシュを有効にします。ModSecurity がトランザクションごとに複数のスクリプトを実行する必要がある場合にのみ違いがあります。
Enable-request-early : ModSecurity 2.6 では、フェーズ 1 がフェーズ 2 フックに移動されました。それを回避したい場合は、このオプションを使用してください。
enable-htaccess-config: AllowOverride Option が設定されている場合に、以下のディレクティブを .htaccess ファイルで使用できます。
第3章 ModSecurity ルール作成
3.1. 設定の例
3.1.1. 背景情報
設定ディレクティブ: ModSecurity の設定ディレクティブは Apache Server ディレクティブに似ています。ModSecurity ディレクティブのほとんどは、さまざまな Apache Scope Directives 内で使用できます。ただし、他のものは、メインの設定ファイル内で 1 回のみ使用できます。これらのルールは、コアルールファイルとともに、httpd.conf ファイルの外部のファイルに含めて、Apache の Include ディレクティブで呼び出す必要があります。これにより、ルールの更新/移行が容易になります。設定ディレクティブの完全なリストは、このドキュメントのリファレンスセクションを参照してください。
3.2. ルールの例
3.2.1. 背景情報
ModSecurity は、主にカスタムルールを作成すると機能します。このカスタムルールは、実行時に Mod_sec をチェックするものを決定します。ルールは、Apache リクエストサイクルの 5 フェーズのいずれかで実装されます。5 つのフェーズとその構文名を指定します。
ヘッダーのリクエスト → REQUEST_HEADERS
ボディーのリクエスト → REQUEST_BODY
応答ヘッダー → RESPONSE_HEADERS
応答ボディー → RESPONSE_BODY
ロギング → LOGGING
3.2.2. ルール 1 の例:
本セクションでは、カスタムルールの例を説明します。指定されたカスタムルールは、履歴がリクエストによって変更されたかどうかを確認します。一般的なルールには、設定ディレクティブ、変数、演算子、およびアクションの 4 つの部分があります。設定ディレクティブ、変数、演算子、および変換/アクションの完全な一覧は、このガイドのリファレンスセクションを参照してください。このルールには、以下の項目があります。
SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"
ルールは SecRule で始まります。これは、選択された演算子を使用して選択した変数を分析するルールを作成する設定ディレクティブです。ほとんどのルールは、この設定ディレクティブを使用します。
その後、ルールは変数 REQUEST_URI で続行されます。この変数は、クエリー文字列データを含む完全なリクエスト URL を保持します。
次に、演算子は "@streq /index.php" として定義されます。@streq は、/index.php ファイルと同等の文字列値を確認します。ただし、これが発生する前に、変換/アクションが実行します。これらは "id:1,phase:1,t:lowercase,deny" として定義されます。このコマンドから、フェーズ 1 時に HTTP リクエストの URI 部分を取得し、その値を小文字に変換します。次に、変換された値を確認して、/index.php と等しいかどうかを確認します。これが等しい場合、Modsecurity はリクエストを拒否し、それ以上のルールは処理されません。
3.2.3. ルール 2 の例
このセクションでは、より複雑なルールの例を説明します。指定されたカスタムルールは、履歴がリクエストによって変更されたかどうかを確認します。一般的なルールには、設定ディレクティブ、変数、演算子、およびアクションの 4 つの部分があります。設定ディレクティブ、変数、演算子、および変換/アクションの完全な一覧は、このガイドのリファレンスセクションを参照してください。このルールには、以下の項目があります。
SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS "history.pushstate|history.replacestate" "phase:4,deny,log,msg:'history-based attacks detected'"
ルールは SecRule で始まります。これは、選択された演算子を使用して選択した変数を分析するルールを作成する設定ディレクティブです。ほとんどのルールは、この設定ディレクティブを使用します。
次に、ルールは変数を使用して続行します。REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS ここには 4 つの変数があり、それぞれがルールがチェックするリクエストの異なる部分を定義します。
次に、演算子は要求に対して定義されます。この場合、ルールは JS メソッド history.pushstate() および history.replacestate() をチェックします。これらの値が見つかると、最後のセクションが実行されます。
最後のセクションでは、実行される変換とアクションを定義します。この場合は、最初にルールが実行する処理フェーズを定義します。次に、deny、log、および msg のアクションを実行します。Deny は、ルール処理を停止し、トランザクションをインターセプトします。Log にはログの作成が必要であることを示します。Msg はログでメッセージを出力します。メッセージは history-based attacks detected (履歴ベースの攻撃が検出されました) として定義されます。
第4章 ModSecurity リファレンス
4.1. 付録
本セクションでは、SpiderLabs が提供する ModSecurity ドキュメントへの重要な参考資料を説明します。これには、ルールの作成に使用する以下の項目の完全なリストへのリンクがあります。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}