Red Hat JBoss Core Services ModSecurity ガイド
Red Hat JBoss ミドルウェア製品との使用
概要
Red Hat ドキュメントへのフィードバック (英語のみ)
弊社の技術的な内容についてのフィードバックに感謝します。ご意見をお聞かせください。コメントの追加、Insights の提供、誤字の修正、および質問を行う必要がある場合は、ドキュメントで直接行うこともできます。
Red Hat アカウントがあり、カスタマーポータルにログインしている必要があります。
カスタマーポータルからドキュメントのフィードバックを送信するには、以下の手順を実施します。
- Multi-page HTML 形式を選択します。
- ドキュメントの右上にある Feedback ボタンをクリックします。
- フィードバックを提供するテキストのセクションを強調表示します。
- ハイライトされたテキストの横にある Add Feedback ダイアログをクリックします。
- ページの右側のテキストボックスにフィードバックを入力し、送信 をクリックします。
フィードバックを送信すると、自動的に問題の追跡が作成されます。Submit をクリックすると表示されるリンクを開き、問題の監視を開始するか、さらにコメントを追加します。
貴重なフィードバックにご協力いただきありがとうございます。
第1章 ModSecurity の概要
1.1. 概要
本ガイドには、Red Hat JBoss Core Services 2.4.37 と使用する 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.37にあります。 -
Apache が
C:\Apache2437にインストールされています -
ModSecurity ソースが
C:\ sourceDirectory\mod_securityにあります
この場合、sourceDirectory はプロジェクトとともに使用する汎用ディレクトリーです。
さらに、ビルド環境に正しい設定があることを確認します。PATH 環境変数には、vsvars32.bat や CMAKE bin\ ディレクトリーに設定される Visual Studio 変数が含まれる必要があります。最後に、Apache ソースコードディレクトリー C:\ sourceDirectory\httpd-2.4.37 に環境変数を設定します。
上記の基準を満たしたら、お使いの 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 にある事前設定されたディレクトリーが含まれています。このディレクトリーまたは、その中の activated_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 のようこそディレクティブで起動します。これにより、ルールの更新/移行が容易になります。設定ディレクティブの完全なリストは、本書のリファレンスセクションを参照してください。
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 ドキュメントへの重要な参考資料を説明します。これには、ルールの作成に使用する以下の項目の完全なリストへのリンクがあります。