Libmodsecurity は ModSecurity v3 プロジェクトのコンポーネントの 1 つです。ライブラリのコードベースは ModSecurity コネクタへのインターフェースとして機能し、Web トラフィックを受け取り、従来の ModSecurity 処理を適用します。一般的には、ModSecurity SecRules 形式で記述されたルールをロード・解釈し、コネクタ経由でアプリケーションが提供する HTTP コンテンツにそれらを適用する機能を提供します。
Apache 向け ModSecurity（別名 ModSecurity v2.x）をお探しの場合は、現在もメンテナンス中で、こちらから入手できます：こちら。
Libmodsecurity は ModSecurity プラットフォームの完全な書き直しです。当初 ModSecurity プロジェクトは Apache モジュールとして始まりましたが、時間の経過とともに、多くの要望を受けて Nginx や IIS などの他のプラットフォームもサポートするように拡張されました。プラットフォームサポートの需要の高まりに応えるためには、このプロジェクトの基盤となる Apache 依存関係を取り除き、よりプラットフォームに依存しないものにする必要がありました。
この目標の結果として、Libmodsecurity を再設計し、コンパイル時および実行時の両方で Apache Web サーバーに依存しないようにしました。これにより、すべてのプラットフォームでパフォーマンスが向上することが期待できます。さらに、この機会に、ユーザーが長らく望んでいたいくつかの新機能の基盤を築きました。たとえば、将来のバージョンでは JSON 形式の監査ログをネイティブでサポートする予定です。
「ModSecurity」ブランチには、従来のように Nginx、Apache、IIS 向けの従来のモジュールロジックは含まれなくなりました。その代わり、このブランチにはこのプロジェクトのライブラリ部分（libmodsecurity）のみが含まれています。このライブラリは、私たちが「コネクタ」と呼ぶものによって消費されます。これらのコネクタは 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 にあります。 コンパイルレシピ
Windows のビルド情報はこちらにあります。
SecRules での正規表現処理は、Regex ユーティリティ（src/utils/regex.*）を介して実装されています。
デフォルトでは、ModSecurity は正規表現処理に PCRE2 を使用します。
これは @rx、@rxGlobal、@verifyCC などのオペレーターで使用されます。
ビルド時の動作：
--with-pcre が明示的に指定された場合（WITH_PCRE）、従来の PCRE を使用できます。言い換えれば、特に指定がない限り、現在のビルドは PCRE2 を前提としています。
その他の依存関係は、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
先頭の - は、サブモジュールが初期化またはフェッチされていないことを示します。
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 形式で記述されています。このドキュメントを生成するには、提供されている設定ファイル "doxygen.cfg" を "doc/" サブフォルダとともに doxygen ユーティリティで使用してください。これにより、使用例を含む HTML 形式のドキュメントが生成されます。
ライブラリは C++ および C のインターフェースを提供しています。一部のリソースは現在 C++ インターフェースでのみ利用可能です。たとえば、カスタムロギングメカニズムを作成する機能（ロギングメカニズムの動作を確認するには回帰テストを参照）などです。目標は、両方の API（C、C++）が同じ機能を提供することです。特定のインターフェースで API の側面が欠けている場合は、Issue を開いてください。
サブフォルダ examples 内には、API の使用方法を示す簡単な例があります。以下にいくつかを示します。
using ModSecurity::ModSecurity;
using ModSecurity::Rules;
using ModSecurity::Transaction;
ModSecurity *modsec;
ModSecurity::Rules *rules;
modsec = new ModSecurity();
rules = new Rules();
rules->loadFromUri(rules_file);
Transaction *modsecTransaction = new Transaction(modsec, rules);
modsecTransaction->processConnection("127.0.0.1");
if (modsecTransaction->intervention()) {
std::cout << "There is an intervention" << std::endl;
}
#include "modsecurity/modsecurity.h"
#include "modsecurity/transaction.h"
char main_rule_uri[] = "basic_rules.conf";
int main (int argc, char **argv)
{
ModSecurity *modsec = NULL;
Transaction *transaction = NULL;
Rules *rules = NULL;
modsec = msc_init();
rules = msc_create_rules_set();
msc_rules_add_file(rules, main_rule_uri);
transaction = msc_new_transaction(modsec, rules);
msc_process_connection(transaction, "127.0.0.1");
msc_process_uri(transaction, "http://www.modsecurity.org/test?key1=value1&key2=value2&key3=value3&test=args&test=test");
msc_process_request_headers(transaction);
msc_process_request_body(transaction);
msc_process_response_headers(transaction);
msc_process_response_body(transaction);
return 0;
}
このプロジェクトへのコントリビューションを歓迎します。ModSecurity の新しいバージョンを中心としたコミュニティの成長を楽しみにしています。関心のある分野は以下のとおりです。新機能、修正、バグ報告、初心者ユーザーへのサポート、またはお手伝いいただけることなら何でも構いません。
レビュー作業と QA 統合を容易にするため、GitHub インフラストラクチャ内でパッチを提供することをお勧めします。GitHub では「プルリクエスト」の実行方法に関する優れたドキュメントが提供されています。詳細はこちら：https://help.github.com/articles/using-pull-requests/
コーディングスタイルを尊重してください。プルリクエストには複数のコミットを含めることができます。その場合、1 つの修正または 1 つの機能ごとに 1 つのコミットを提供してください。対象作業の範囲外のもの（たとえば、通過した関数内のコーディングスタイル）は変更しないでください。このプロジェクトで使用されているコーディングスタイルの詳細については、https://www.chromium.org/blink/coding-style を確認してください。
説明的なコミットメッセージを提供してください。最初の行にはパッチの要点を、3 行目以降にはパッチの詳細な説明や技術的詳細を記載してください。パッチの説明はレビュープロセスで重要です。
コード内には、TODO や FIXME としてマークされた項目がいくつかあり、注意が必要かもしれません。grep を実行して項目のリストを確認してください。
$ cd /path/to/modsecurity-nginx
$ egrep -Rin "TODO|FIXME" -R *
TODO リストは Doxygen ドキュメントの一部としても利用可能です。
手動テストに加えて、回帰テストとユニットテストを使用することを強くお勧めします。オペレーターを実装した場合は、そのユニットテストも作成することを忘れないでください。その他のものを実装する場合も、補完的な回帰テストを開発することをお勧めします。
回帰テストとユニットテストのユーティリティはネイティブであり、外部ツールやスクリプトは必要ありませんが、テストケースを他のリポジトリから取得する必要があります。これらは他のバージョンの ModSecurity と共有されているため、その他のリポジトリは git サブモジュールです。サブモジュールリポジトリをフェッチしてユーティリティを実行するには、以下のコマンドに従ってください。
$ cd /path/to/your/ModSecurity
$ git submodule update --init --recursive
$ make check
デバッグプロセスを開始する前に、バグの場所を特定してください。問題はコネクタまたは libmodsecurity のいずれかに存在する可能性があります。バグの場所を特定するために、バグが発生しているシナリオを模倣した回帰テストを作成することをお勧めします。バグが回帰テストユーティリティで再現可能であれば、デバッグがはるかに簡単になり、再発を防止できます。Linux では、デバッグを行う人は必要に応じて gdb や valgrind を使用することをお勧めします。
設定/コンパイル時に、コンパイラの最適化を無効にして、「バックトレース」に読み取り可能なデータを表示させることができます。CFLAGS を使用してコンパイル最適化パラメータを無効にします。
$ export CFLAGS="-g -O0"
$ ./build.sh
$ ./configure --enable-assertions=yes
$ make
$ sudo make install
「アサーションを使用すると、前提条件を文書化し、開発プロセスの早い段階で違反を発見できます。さらに、アサーションを使用すると、最小限の労力で違反を発見できます。」https://dl.acm.org/doi/pdf/10.1145/240964.240969
該当する場合はアサーションを使用し、テストおよびデバッグのワークフロー中に '--enable-assertions=yes' で有効にすることをお勧めします。
ソースツリーには、ライブラリのパフォーマンスを測定するのに役立つベンチマークツールが含まれています。ツールは test/benchmark/ ディレクトリにあります。ビルドプロセスによってここにバイナリも作成されるため、コンパイル完了後にツールを使用できます。
実行するには、次のように入力します。
cd test/benchmark
$ ./benchmark
Doing 1000000 transactions...
より小さい値を渡すこともできます。
$ ./benchmark 1000
Doing 1000 transactions...
時間を測定するには：
$ time ./benchmark 1000
Doing 1000 transactions...
real 0m0.351s
user 0m0.337s
sys 0m0.022s
これは非常に高速です。なぜなら、ベンチマークは最小限の modsecurity.conf.default 設定を使用し、多くのルールを含んでいないからです。
$ cat basic_rules.conf
Include "../../modsecurity.conf-recommended"
実際のルールで測定するには、同じディレクトリにあるダウンロードスクリプトのいずれかを実行します。
$ ./download-owasp-v3-rules.sh
Cloning into 'owasp-v3'...
remote: Enumerating objects: 33007, done.
remote: Counting objects: 100% (2581/2581), done.
remote: Compressing objects: 100% (907/907), done.
remote: Total 33007 (delta 2151), reused 2004 (delta 1638), pack-reused 30426
Receiving objects: 100% (33007/33007), 9.02 MiB | 16.21 MiB/s, done.
Resolving deltas: 100% (25927/25927), done.
Switched to a new branch 'tag3.0.2'
/path/to/ModSecurity/test/benchmark
Done.
$ cat basic_rules.conf
Include "../../modsecurity.conf-recommended"
Include "owasp-v3/crs-setup.conf.example"
Include "owasp-v3/rules/*.conf"
これでコマンドははるかに高い値を返します。
このツールは、ライブラリを利用する単純なラッパーアプリケーションです。ModSecurity インスタンスと RuleSet インスタンスを作成し、指定された数に基づいてループを実行します。このループ内で、Transaction オブジェクトを作成して実際の HTTP トランザクションをエミュレートします。
各トランザクションは、いくつかの GET パラメータを持つ HTTP/1.1 GET リクエストです。共通のヘッダーが追加され、その後に応答ヘッダーと XML 本文が続きます。フェーズ間で、ツールは介入が発生したかどうかを確認します。すべてのトランザクションは同じデータで作成されます。
ツールは最後のフェーズ（ロギング）を呼び出さないことに注意してください。
別のルールセットで試す場合は、basic_rules.conf をリセットすることを忘れないでください。
設定の問題が発生した場合、または期待どおりに動作しない場合は、ModSecurity ユーザーメーリングリストを使用してください。GitHub での Issue も歓迎しますが、まずメーリングリストで質問してコミュニティ全体にアクセスすることをお勧めします。また、新しい Issue を開く前に、既存の Issue を確認することを忘れないでください。
GitHub で新しい Issue を開く場合は、libmodsecurity のバージョンと、該当する場合は特定のコネクタのバージョンを必ずお知らせください。
セキュリティ問題を公開しないでください。[email protected] までご連絡いただき、問題を報告してください。問題が修正されたら、クレジットを記載します。
新しい機能リクエストについては、メーリングリストを通じてコミュニティと話し合う用意があります。または、GitHub で機能リクエストの Issue を開いてもかまいません。新しい Issue を開く前に、同じトピックの Issue がすでに開かれていないか確認してください。
libModSecurity の設計は、バインディングとの統合を可能にします。API [バイナリ] 互換性を壊さないように努力しており、バインディングとの容易な統合を実現しています。現在、コミュニティによって保守されている注目すべきプロジェクトがいくつかあります。
ディストリビューションにパッケージをタイムリーに提供することは私たちの願いです。パッケージャーとしての作業を容易にするためにできることがあればお知らせください。
ModSecurity の開発は Trustwave がスポンサーを務めています。スポンサーシップは 2024 年 7 月 1 日に終了します。詳細はこちらをご覧ください。https://www.trustwave.com/en-us/resources/security-resources/software-updates/end-of-sale-and-trustwave-support-for-modsecurity-web-application-firewall/
test/test-cases/secrules-language-tests – make check で使用される共有の SecRules 適合性テストおよび回帰テストスイートです。
bindings/python – ModSecurity の Python バインディング（コアライブラリのコンパイルには不要）。