Modsecurityの概要と特徴についてリファレンスマニュアルを読んでまとめました。
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Introduction
※目次をクリックすると目次の下部にコンテンツが表示されます。
- 1.概要
- 2.HTTPトラフィックロギング
- 3.リアルタイムモニタリングと攻撃検知
- 4.攻撃防御とVirtual Patch(バーチャルパッチ)
- 5.フレキシブルルールエンジン
- 6.組み込みモードでデプロイ(Embedded-mode Deployment)
- 7.ネットワークベースデプロイ
- 8.OWASP ModSecurity Core Rule Set (CRS)プロジェクトとは?
- 9.コアルールセット(Core Rule Set)について
概要
・ModSecurityは、Webアプリケーションファイアウォール(WAF)として位置づけられています。
・現在、Webの世界で行われている攻撃の70%以上はアプリケーションレベル以上で実行されています。
・ModSecurityは、攻撃がWebアプリケーションに到達する前に攻撃を検知、防御するセキュリティレイヤーとして導入されています。
・ModSecurityは、既存のインフラをほとんど変更せずにWebアプリケーションに対する防御、HTTPトラフィックモニタリング、リアルタイム分析の機能を提供しています。。
・現在、Webの世界で行われている攻撃の70%以上はアプリケーションレベル以上で実行されています。
・ModSecurityは、攻撃がWebアプリケーションに到達する前に攻撃を検知、防御するセキュリティレイヤーとして導入されています。
・ModSecurityは、既存のインフラをほとんど変更せずにWebアプリケーションに対する防御、HTTPトラフィックモニタリング、リアルタイム分析の機能を提供しています。。
HTTPトラフィックロギング
・Webサーバーの通常のログは、マーケットの分析用途で記録する情報が少なく、HTTPのリクエストボディ部を記録していないといった問題があります。
・攻撃者もそれを知っているのでPOSTリクエストを使って攻撃を実行しています。
・ModSecurityは、リクエストの開始からレスポンスの終了まですべてのHTTPトランザクションにおけるログが可能となっています。
・HTTPデータ内のあるフィールドには機密性の高い情報が含まれる事もありますが、これらの情報が監視ログに記述される際にマスクするように設定する事も出来ます。
・攻撃者もそれを知っているのでPOSTリクエストを使って攻撃を実行しています。
・ModSecurityは、リクエストの開始からレスポンスの終了まですべてのHTTPトランザクションにおけるログが可能となっています。
・HTTPデータ内のあるフィールドには機密性の高い情報が含まれる事もありますが、これらの情報が監視ログに記述される際にマスクするように設定する事も出来ます。
リアルタイムモニタリングと攻撃検知
・攻撃を検知するためにHTTPトラフィックをリアルタイムにモニターする機能があります。
この場合、ModSecurityは侵入検知ツールとしての役割を担います。
この場合、ModSecurityは侵入検知ツールとしての役割を担います。
攻撃防御とVirtual Patch(バーチャルパッチ)
Webアプリケーションに対する攻撃を防ぐためのアクションも直ちに実行できます。以下3つのアプローチがあります。
①ネガティブセキュリティモデル
・アノマリーなリクエスト、異常な振る舞い、一般的なWebアプリケーション攻撃をモニターします。
・IPアドレス、アプリケーションセッション、ユーザーアカウントを基に各リクエストのアノマリースコアを把握していて、高いアノマリースコアのリクエストの場合はログに記録したり拒否するなどのアクションをとります。
②ポジティブセキュリティモデル
・正当だと判断できるリクエストのみ受けつけ、それ以外のすべては拒否します。
・このモデルの場合は、防御対象のWebアプリケーションに対する深い知識が必要です。
・このモデルは、防御対象のアプリケーションを使い込んでいて深い知識があり、アップデートがまれでモデルのメンテナンスがあまり必要がない場合に適しています。
③既知の欠点、脆弱性
・外部パッチ(またはバーチャルパッチ)ツールとしての役割を担います。
・アプリケーションの脆弱性に対するパッチを用意するのに数週間かかる場合があります。
このModSecurityのバーチャルパッチによって、アプリケーション自身にパッチを適用したり、ソースに触れることなしに外部から仮想的にパッチを適用した状態にし、正規のパッチが適用されるまでの間、システムをセキュアに保つように維持します。
①ネガティブセキュリティモデル
・アノマリーなリクエスト、異常な振る舞い、一般的なWebアプリケーション攻撃をモニターします。
・IPアドレス、アプリケーションセッション、ユーザーアカウントを基に各リクエストのアノマリースコアを把握していて、高いアノマリースコアのリクエストの場合はログに記録したり拒否するなどのアクションをとります。
②ポジティブセキュリティモデル
・正当だと判断できるリクエストのみ受けつけ、それ以外のすべては拒否します。
・このモデルの場合は、防御対象のWebアプリケーションに対する深い知識が必要です。
・このモデルは、防御対象のアプリケーションを使い込んでいて深い知識があり、アップデートがまれでモデルのメンテナンスがあまり必要がない場合に適しています。
③既知の欠点、脆弱性
・外部パッチ(またはバーチャルパッチ)ツールとしての役割を担います。
・アプリケーションの脆弱性に対するパッチを用意するのに数週間かかる場合があります。
このModSecurityのバーチャルパッチによって、アプリケーション自身にパッチを適用したり、ソースに触れることなしに外部から仮想的にパッチを適用した状態にし、正規のパッチが適用されるまでの間、システムをセキュアに保つように維持します。
フレキシブルルールエンジン
・フレキシブルルールエンジンは、ModSecurityの中心となる機能です。
・これは、ModSecurityルール言語によって実装されていて、HTTPトランザクションデータ用に設計されたプログラミング言語です。
・ModSecurityルール言語は使用しやすく、フレキシブルです。
一般的なオペレーションはシンプルですが複雑なオペレーションも可能です。
・ModSecurity同梱のModSecurityルールには、一般的なハードニング、プロトコルバリデーション、一般的なWebアプリケーションセキュリティ不具合などが設定された包括的なルールセットが含まれています。
このルールセットを学習ツールとして使用できるほど詳しくコメントされています。
・これは、ModSecurityルール言語によって実装されていて、HTTPトランザクションデータ用に設計されたプログラミング言語です。
・ModSecurityルール言語は使用しやすく、フレキシブルです。
一般的なオペレーションはシンプルですが複雑なオペレーションも可能です。
・ModSecurity同梱のModSecurityルールには、一般的なハードニング、プロトコルバリデーション、一般的なWebアプリケーションセキュリティ不具合などが設定された包括的なルールセットが含まれています。
このルールセットを学習ツールとして使用できるほど詳しくコメントされています。
組み込みモードでデプロイ(Embedded-mode Deployment)
ModSecurityは、組み込みのWebアプリケーションファイアウォールで、Apache、IIS、NginxなどのWebサーバーの一部としてデプロイできます。
このデプロイでは、下記メリットがあります。
①既存のネットワークの変更不要
既存のWebサーバーに簡単に導入できます。デフォルトは完全にパッシブなので導入後すぐにご検知による不具合が生じることがありません。
最初はパッシブで、徐々に必要な機能を自由に追加できます。不要になった機能はすぐに無効化、削除する事も出来ます。
②Single Point of Failure(単一障害点)とならない
ネットワークベースのデプロイとは違って、あらたに障害点を導入せずに済みます。
③ロードバランスやスケーリングの効果もある
ModSecurityは、Webサーバー内に組み込まれて動作するので、自動でロードバランスとスケーラビリティーの機能を持つことになります。
④オーバーヘッドが最小
Webサーバーのプロセス内で動作するので、ネットワーク通信のオーバーヘッドやデータ解析、変換のオーバーヘッドがありません。
⑤暗号化、圧縮化コンテンツに関する問題もない
多くのIDSシステムではSSLトラフィックの解析が困難と言われています。ModSecurityでは、トラフィックが復号化された後、圧縮を伸張した後の段階で位置で動作しているので問題ありません。
このデプロイでは、下記メリットがあります。
①既存のネットワークの変更不要
既存のWebサーバーに簡単に導入できます。デフォルトは完全にパッシブなので導入後すぐにご検知による不具合が生じることがありません。
最初はパッシブで、徐々に必要な機能を自由に追加できます。不要になった機能はすぐに無効化、削除する事も出来ます。
②Single Point of Failure(単一障害点)とならない
ネットワークベースのデプロイとは違って、あらたに障害点を導入せずに済みます。
③ロードバランスやスケーリングの効果もある
ModSecurityは、Webサーバー内に組み込まれて動作するので、自動でロードバランスとスケーラビリティーの機能を持つことになります。
④オーバーヘッドが最小
Webサーバーのプロセス内で動作するので、ネットワーク通信のオーバーヘッドやデータ解析、変換のオーバーヘッドがありません。
⑤暗号化、圧縮化コンテンツに関する問題もない
多くのIDSシステムではSSLトラフィックの解析が困難と言われています。ModSecurityでは、トラフィックが復号化された後、圧縮を伸張した後の段階で位置で動作しているので問題ありません。
ネットワークベースデプロイ
・リバースプロキシサーバーの一部として動作させることも可能です。
・このシナリオでは、リバースプロキシにModSecurityを導入するだけのバックエンドの多くのWebサーバーを保護する事が出来ます。
・このシナリオでは、リバースプロキシにModSecurityを導入するだけのバックエンドの多くのWebサーバーを保護する事が出来ます。
OWASP ModSecurity Core Rule Set (CRS)プロジェクトとは?
・OWASP(Open Web Application Security Project)
・OWASP ModSecurity Core Rule Set Project
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
・既知の脆弱性に特化したシグネチャに基づいているIDSやIDPとは異なり、CRSは、Webアプリケーション(多くはカスタムなコード)でたびたび発見される未知の脆弱性に対する全般的な保護の機能を提供します。
・CRSは詳しくコメント化されているので、ModSecurityの入門ガイドとしても使用できます。
・OWASP ModSecurity Core Rule Set Project
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
・既知の脆弱性に特化したシグネチャに基づいているIDSやIDPとは異なり、CRSは、Webアプリケーション(多くはカスタムなコード)でたびたび発見される未知の脆弱性に対する全般的な保護の機能を提供します。
・CRSは詳しくコメント化されているので、ModSecurityの入門ガイドとしても使用できます。
コアルールセット(Core Rule Set)について
Webアプリケーションを保護するため、CRSは下記手法を使用します。
・HTTP保護
HTTPプロトコルの違反やローカルに定義されて使用されているポリシーを検知します。
・一般的なWeb攻撃保護
一般的なWebアプリケーションセキュリティ攻撃を検知します。
・自動検知
ボット(遠隔操作などする悪用プログラム)、クローラー、スキャナー、その他の悪意のあるアクティビティを検知します。
・トロイの木馬攻撃を保護
・エラーを隠す
サーバーから送られたエラーメッセージを分からないように変換する。
・HTTP保護
HTTPプロトコルの違反やローカルに定義されて使用されているポリシーを検知します。
・一般的なWeb攻撃保護
一般的なWebアプリケーションセキュリティ攻撃を検知します。
・自動検知
ボット(遠隔操作などする悪用プログラム)、クローラー、スキャナー、その他の悪意のあるアクティビティを検知します。
・トロイの木馬攻撃を保護
・エラーを隠す
サーバーから送られたエラーメッセージを分からないように変換する。
-
インストール、設定全般、運用
- Apacheのインストール
- Apache初期設定確認
- Apacheの静的、DSOモジュールの確認、インストール方法
- Apacheでconf.dディレクトリ内の設定ファイルのインクルードに注意
- Apacheのhttpdサービスの使用方法
- WordPressパーマリンク設定時のApache設定
- Apache mod_rewriteの仕組み、設定方法、動作確認
- Apacheで特定の拡張子を含むリクエストをログ対象から外す
- CentOS Stream9でApache、PHPを設定する際の注意点
- ApacheのTraceメソッドを無効にする
- ヘッダーにApacheバージョンが表示されないようにする
- PHPのバージョン情報とApacheの設定
- Apacheでディレクトリ内一覧表示を無効にする
- Apacheで不要なモジュールはロードしない
- Apacheで不要なモジュールはロードしない(1)ベーシック認証と認証プロバイダ
- Apacheで不要なモジュールはロードしない(2)ダイジェスト認証
- Apacheで不要なモジュールはロードしない(3)mod_rewrite、LDAP、WebDAV
- Apacheで不要なモジュールはロードしない(4)Server Side Includes
- Apacheで不要なモジュールはロードしない(5)mod_mime_magic
- Apacheで不要なモジュールはロードしない(6)mod_info、mod_status
- Apacheで不要なモジュールはロードしない(7)mod_speling、mod_userdir
- Apacheで不要なモジュールはロードしない(8)プロキシ関連のモジュール
- Apacheで不要なモジュールはロードしない(9)キャッシュ関連のモジュール
- Apacheで不要なモジュールはロードしない(10)CGI関連のモジュール
- Apacheで不要なモジュールはロードしない(11)フィルター、expires、圧縮のモジュール
- Apacheでディレクトリへのアクセスを制限する設定方法
- Apacheベーシック認証の設定手順とセキュリティ上の注意
- Apacheで使用できるHTTPメソッドを制限する
- FIPS140-2とApacheのmod_nss
- Apacheにおける自己証明書作成手順
- ApacheにおけるSSL証明書インストール手順
- DoS攻撃からWebサーバーを保護するApacheモジュール
- Apacheに関するLinux側のセキュリティ設定(パーミッション、iptables、chroot)
- Modsecurityの概要と特徴
- Modsecurityのインストール方法
- modsecurityの設定方法と設定例
- Apacheのパフォーマンスに影響を与えるOS、ハードウェアの要素、注意点
- ApacheのMPMの概要とチューニング
- ApacheのMaxClientsのチューニングとListenBacklog
- HostnameLookupsを有効にして名前解決を行う場合のApacheパフォーマンスに与える影響
- FollowSymLinks、SymLinksIfOwnerMatchの設定とApacheのパフォーマンス
- AllowOverrideの設定とApacheのパフォーマンス
- コンテントネゴシエーションの設定とApacheのパフォーマンス
- Apacheのプロセス生成とパフォーマンスに与える影響
セキュリティ
パフォーマンス