owasp-modsecurity/modsecurityModSecurityは、Apache、IIS、Nginx向けのオープンソースでクロスプラットフォームなWebアプリケーションファイアウォール（WAF）エンジンです。堅牢なイベントベースのプログラミング言語を備えており、Webアプリケーションに対するさまざまな攻撃から保護し、HTTPトラフィックの監視、ロギング、リアルタイム分析を可能にします。
LibmodsecurityはModSecurity v3プロジェクトのコンポーネントの一つです。このライブラリのコードベースは、ModSecurity Connectorsへのインターフェースとして機能し、Webトラフィックを受け取って従来のModSecurity処理を適用します。一般的には、ModSecurity SecRules形式で記述されたルールを読み込み/解釈し、Connectorsを介してアプリケーションから提供されるHTTPコンテンツに適用する機能を提供します。
Apache向けのModSecurity（別名ModSecurity v2.x）をお探しの場合、それは現在もメンテナンスされており、以下から入手可能です： こちら。
LibmodsecurityはModSecurityプラットフォームの完全な書き直しです。ModSecurityプロジェクトは当初、単なるApacheモジュールとして始まりました。時が経つにつれ、このプロジェクトは需要に応じて拡張され、NginxやIISを含む（ただしこれらに限らない）他のプラットフォームをサポートするようになりました。追加のプラットフォームサポートに対する高まる需要に応えるため、このプロジェクトの基盤となるApacheへの依存関係を削除し、よりプラットフォームに依存しない形にする必要が生じました。
この目標の結果として、LibmodsecurityはApache Webサーバーに（コンパイル時および実行時の両方で）依存しなくなるように再設計されました。この副作用の一つとして、すべてのプラットフォームでユーザーはパフォーマンスの向上を期待できます。さらに、この機会を利用して、ユーザーが長い間求めていたいくつかの新機能の基盤を築きました。例えば、JSON形式での監査ログのネイティブサポートを目指しており、その他にも将来のバージョンで多数の機能を提供する予定です。
'ModSecurity'ブランチには、従来まとめてパッケージ化されていた伝統的なモジュールロジック（Nginx、Apache、IIS向け）はもはや含まれていません。代わりに、このブランチにはこのプロジェクトのライブラリ部分（libmodsecurity）のみが含まれています。このライブラリは、私たちが「Connectors」と呼ぶものによって利用されます。これらのコネクタはお使いのWebサーバーとインターフェースし、ライブラリが理解できる共通形式でデータを提供します。これらのコネクタはそれぞれ別のGitHubプロジェクトとして管理されています。例えば、NginxコネクタはModSecurity-nginxプロジェクト（https://github.com/owasp-modsecurity/ModSecurity-nginx）によって提供されています。
これらのコネクタを分離しておくことで、各プロジェクトが異なるリリースサイクル、課題、開発ツリーを持つことが可能になります。さらに、ModSecurity v3をインストールする際には、必要なものだけを正確に入手でき、使わない余分なものは含まれないということでもあります。
コンパイルプロセスを開始する前に、必要な依存関係がすべてインストールされていることを確認してください。
詳細については、依存関係およびGitサブモジュールのセクションを参照してください。
コンパイル後、ビルド環境やプラットフォームに問題がないことを確認してください。
ユニットテストおよび回帰テストの実行を強く推奨します。これらのテストユーティリティはtests/サブフォルダにあります。
動的ライブラリとして、libmodsecurityはオペレーティングシステムが動的ライブラリを見つけられる場所にインストールする必要があります。
Unix系システムでは、プロジェクトはコンパイルプロセスにautotoolsを使用します。
gitチェックアウトで作業している場合は、ビルド前にリポジトリを再帰的にクローンするか、すべてのサブモジュールを初期化してください。
Gitサブモジュールのセクションも参照してください。
git clone https://github.com/owasp-modsecurity/ModSecurity ModSecurity
cd ModSecurity
このリポジトリはgitサブモジュールを使用しています。クローン後、すべてのサブモジュールを初期化して取得してください:
git submodule update --init --recursive
サブモジュールがすべて正しく初期化されているかは、次のコマンドで確認できます:
git submodule status
正しく初期化されたサブモジュールにはコミットハッシュが表示されます。
先頭の - は、そのサブモジュールが初期化されていないことを示します。
その後、ビルドプロセスを開始できます:
./build.sh
./configure
make
sudo make install
ディストリビューション固有のビルドの詳細は、Wiki を参照してください: Compilation Recipes
Windows ビルドの情報はこちらにあります。
SecRules における正規表現処理は、Regex ユーティリティ (src/utils/regex.*) を介して実装されています。
デフォルトでは、ModSecurity は正規表現処理に PCRE2 を使用します。
これは @rx、@rxGlobal、@verifyCC などの演算子で使用されます。
ビルド時の動作:
--with-pcre が明示的に指定された場合 (WITH_PCRE)、レガシーな PCRE を使用できます。つまり、明示的に別途設定しない限り、現在のビルドは PCRE2 を前提としています。
@rx と @rxGlobal はデフォルトで DOTALL | MULTILINE を指定してパターンをコンパイルします: DOTALL
は . が改行にマッチできるようにし、MULTILINE は ^/$ が被検査文字列全体の先頭/末尾だけでなく
内部の各行の改行位置でもアンカーできるようにします。代わりに DOTALL | DOLLAR_ENDONLY
でコンパイルするには --enable-regex-dollar-endonly=yes を渡します: MULTILINE がない場合、
^/$ は被検査文字列全体の先頭/末尾でのみアンカーし、さらに DOLLAR_ENDONLY は $ が
末尾の改行の直前ではなく、そこでのみマッチするよう制限します。DOTALL はいずれの場合も
変更されないため、パターンは引き続き . を介して内部の改行をまたいでマッチできます。
これは ModSecurity v2 の @rx の動作と一致します。このフラグはデフォルトで無効です。詳細は
issue #3295 を参照してください。
その他の依存関係はすべて SecRules 内で指定される演算子や設定ディレクティブに関連するものであり、コンパイルには必須ではない場合があります。
libinjection は演算子 @detectXSS と @detectSQL に必要です。curl はディレクティブ SecRemoteRules に必要です。これらのライブラリが存在しない場合、ModSecurity は該当する演算子やディレクティブのサポートなしでコンパイルされます。
リポジトリには以下のサブモジュールが含まれています:
others/libinjection – @detectSQLi および @detectXSS 演算子で使用されます。
others/mbedtls (TF-PSA-Crypto サブセット) – 暗号化関数およびヘルパー (ハッシュ、base64 など) に使用されます。
注: 新しい mbedTLS v4 のレイアウトは、古い v3 の構造と互換性がありません。 内部構造が大幅に変更され、多くのコンポーネントがサブモジュール (例: TF-PSA-Crypto) に移動しました。
PR #3532 のマージ後、以下を実行する必要があります:
git submodule update --init --recursive
これにより、必要なすべてのサブモジュールが取得されます。この手順を行わないと、プロジェクトは正常にビルドされません。
すべてのサブモジュールが正しく初期化されたことを確認するには、次のコマンドを実行します:
git submodule status
出力例:
bc625d5... bindings/python
2117822... others/libinjection (v4.0.0)
0fe989b... others/mbedtls (v4.1.0)
a3d4405... test/test-cases/secrules-language-tests
サブモジュールが欠落している場合、先頭に - が付いて表示されます。例:
-bc625d5... bindings/python
先頭の - は、そのサブモジュールが初期化または取得されていないことを示します。
test/test-cases/secrules-language-tests – make check で使用される、SecRules の適合性および回帰テストの共有スイート。
bindings/python – ModSecurity の Python バインディング（コアライブラリのコンパイルには不要）。
others/libinjection と others/mbedtls はソースビルドに事実上必須であり、ビルド前に初期化する必要があります。
いくつかの外部ライブラリはオプションであり、以下を含む追加機能を有効にします：
libcurl – SecRemoteRules に必要
LMDB – 永続ストレージのサポート
Lua – スクリプトのサポート
XML ライブラリ – 拡張 XML 処理
GeoIP（レガシー）/ MaxMind
レガシーな GeoIP C API（libGeoIP）は MaxMind によって非推奨とされ、もはやメンテナンスされていません。 上流のリポジトリはアーカイブされており、新規のデプロイには使用すべきではありません。
代わりに、ModSecurity は活発にメンテナンスされている最新の MaxMind DB API（libmaxminddb） をサポートしています。
設定中に次のようなメッセージが表示される場合があります：
+ GeoIP/MaxMind ....found
* (MaxMind) v1.12.2
-lmaxminddb , -I/usr/include/x86_64-linux-gnu
これは libmaxminddb が使用されていることを示します（推奨）。
レガシーな GeoIP ライブラリではなく、MaxMind DB を使用することを強く推奨します。
ライブラリのドキュメントは、Doxygen 形式でコード内に記述されています。このドキュメントを生成するには、"doc/" サブフォルダにある提供の設定ファイル「doxygen.cfg」を使用して doxygen ユーティリティを実行してください。これにより、使用例を含む HTML 形式のドキュメントが生成されます。
ライブラリは C++ および C のインターフェースを提供します。一部のリソースは現在 C++ インターフェース経由でのみ利用可能です。たとえば、カスタムロギング メカニズムを作成する機能などです（これらのロギングメカニズムがどのように動作するかは、回帰テストを参照してください）。 目標は、両方の API（C、C++）が同じ機能を提供することです。 特定のインターフェース経由で API の一部が欠けていることに気づいた場合は、issue を開いてください。
examples サブフォルダ内には、API の使用方法に関する簡単な例があります。 以下にいくつかを示します: