はい、承知いたしました。NginxにModSecurityをインストールしてWAFを導入する手順の詳細な説明を含む記事を作成します。約5000語を目指し、背景、手順、設定、トラブルシューティング、運用まで網羅した内容とします。記事の内容を直接表示します。

NginxにModSecurityを導入して強固なWAFを構築する：詳細手順と設定ガイド

1. はじめに：Webアプリケーションの脅威とModSecurityの役割

現代のサイバー攻撃において、Webアプリケーションは最も狙われやすいターゲットの一つです。SQLインジェクション、クロスサイトスクリプティング（XSS）、ディレクトリトラバーサル、リモートコード実行などの攻撃手法は日々進化し、巧妙化しています。これらの攻撃は、個人情報の漏洩、サービスの停止、Webサイトの改ざんなど、企業や組織に甚大な被害をもたらす可能性があります。

このような脅威に対抗するために、Web Application Firewall（WAF）が不可欠なセキュリティ対策として広く採用されています。WAFは、HTTP/HTTPSトラフィックを検査し、悪意のある通信パターンを検知・遮断することで、Webアプリケーションを保護します。従来のファイアウォールがネットワーク層やトランスポート層の通信を制御するのに対し、WAFはアプリケーション層（レイヤー7）のトラフィックを理解し、より高度な検査を行います。

ModSecurityは、オープンソースのWAFエンジンとして非常に有名で、広く利用されています。Apache HTTP Server、Nginx、IISなどの主要なWebサーバーと連携して動作し、柔軟かつ強力なルールベースの検査機能を提供します。特にNginxと組み合わせることで、Nginxの高いパフォーマンスとModSecurityの堅牢なセキュリティ機能を両立させることが可能です。

この記事では、NginxにModSecurityをソースコードからインストールし、WAFとして機能させるための詳細な手順を解説します。なぜソースコードからビルドするのか、必要な依存関係、具体的なコンパイル方法、基本設定、そして最も重要なOWASP ModSecurity コア・ルール・セット（CRS）の導入と設定、さらに運用上の注意点やトラブルシューティングまで、網羅的に説明します。これにより、読者の皆様がNginx環境にModSecurity WAFを効果的に導入・運用できるようになることを目指します。

2. 導入前の準備：システム要件と必要なツール

ModSecurityをNginxに組み込んで動作させるためには、いくつかの前提条件と準備が必要です。ここでは、必要なシステム環境、コンパイルツール、およびModSecurity自身が要求する依存ライブラリについて解説します。

2.1 システム要件とOSの選択

ModSecurityおよびNginxは、Linux、Unix系OSで広く利用されています。本記事では、CentOSやUbuntuといった主要なLinuxディストリビューションを想定して解説を進めます。使用するOSによってパッケージ管理コマンド（yum または apt）やディレクトリ構成に違いがありますが、基本的な手順は共通です。

OS: CentOS 7/8, Ubuntu 18.04/20.04/22.04など。十分なメモリとディスク容量が必要です。WAFはリアルタイムでトラフィックを検査するため、特にトラフィック量が多い場合はCPUリソースも重要になります。
Nginx: ModSecurityをモジュールとして組み込むため、Nginxもソースコードからビルドするのが一般的です。ModSecurityと互換性のあるNginxのバージョンを選択してください。通常は最新の安定版で問題ありません。
権限: インストールや設定ファイルの編集には、root権限またはsudo権限が必要です。

2.2 必要なコンパイラおよびビルドツール

ソースコードからソフトウェアをビルドするには、開発ツールが必要です。以下のツールがシステムにインストールされていることを確認してください。

GCC/G++: C/C++コンパイラです。
Make: ビルドプロセスを自動化するためのツールです。
Autoconf, Automake, Libtool: ソースコードからconfigureスクリプトなどを生成するために使用されます。ModSecurityのビルドプロセスで必要になることがあります。
PCRE (Perl Compatible Regular Expressions) Development Library: ModSecurityはルールのパターンマッチングに正規表現を使用します。PCREライブラリは必須です。開発用パッケージ（通常 pcre-devel や libpcre3-dev といった名前）が必要です。
Zlib Development Library: データ圧縮に使われます。NginxのGzipモジュールなどでも使用されます。開発用パッケージ（通常 zlib-devel や zlib1g-dev といった名前）が必要です。
OpenSSL Development Library: SSL/TLS暗号化通信のために必要です。開発用パッケージ（通常 openssl-devel や libssl-dev といった名前）が必要です。NginxでHTTPSを使用する場合に必須ですが、ModSecurityのいくつかの機能でも必要になる場合があります。

これらのツールは、各OSのパッケージマネージャーを使用してインストールできます。

CentOSの場合:

bash sudo yum groupinstall "Development Tools" sudo yum install pcre-devel zlib-devel openssl-devel

Ubuntuの場合:

bash sudo apt update sudo apt install build-essential autoconf automake libtool sudo apt install libpcre3-dev zlib1g-dev libssl-dev

2.3 ModSecurityが必要とするその他の依存ライブラリ

ModSecurityは、その機能のためにいくつかの追加ライブラリに依存しています。これらも開発用パッケージが必要です。

libxml2 Development Library: XMLパーシングのために必要です。SOAPやXMLRPCなどのリクエストを検査する際に使用されます。開発用パッケージ（通常 libxml2-devel や libxml2-dev）が必要です。
libcurl Development Library: 外部へのアクセス（例：Reputation Lookup）に使用されることがあります。開発用パッケージ（通常 libcurl-devel や libcurl4-openssl-dev）が必要です。
YAJL (Yet Another JSON Library) Development Library: JSONパーシングのために必要です。JSON形式のリクエストを検査する際に使用されます。開発用パッケージ（通常 yajl-devel や libyajl-dev）が必要です。
libmaxminddb Development Library (オプション): GeoIPルックアップ機能を使用する場合に必要です。開発用パッケージ（通常 libmaxminddb-devel や libmaxminddb-dev）が必要です。これは必須ではありませんが、CRSのルールによってはGeoIP情報を使用するものがあるため、インストールしておくと良いでしょう。

これらの依存ライブラリもパッケージマネージャーでインストールできます。

CentOSの場合:

bash sudo yum install libxml2-devel libcurl-devel yajl-devel libmaxminddb-devel

Ubuntuの場合:

bash sudo apt install libxml2-dev libcurl4-openssl-dev libyajl-dev libmaxminddb-dev

重要な注意点: これらの依存ライブラリは、ModSecurityのビルド時に検出されます。もし必要なライブラリが不足している場合、configure スクリプトの実行時にエラーが発生します。エラーメッセージをよく読み、不足しているライブラリを特定してインストールしてください。

これで、ModSecurityとNginxをソースコードからビルドするための準備が整いました。次のセクションでは、ModSecurity自体のインストールに進みます。

3. ModSecurityのインストール：ソースコードからのビルド

NginxにModSecurityを組み込むには、ModSecurityをNginxの外部モジュールとしてビルドする必要があります。このモジュールは、Nginx本体をコンパイルする際に --add-module オプションで指定することで組み込まれます。ModSecurityの公式リポジトリでは、このNginxコネクタ（ModSecurity-nginx）が提供されています。

3.1 なぜソースコードからビルドするのか

最新バージョンの利用: パッケージマネージャーで提供されるバージョンは、最新版ではない場合があります。ソースコードからビルドすれば、常に最新の機能やセキュリティ修正が含まれたバージョンを利用できます。
Nginxバージョンとの連携: Nginxのバージョンに合わせてModSecurityモジュールをビルドする必要があります。特に古いNginxや特定の機能を持つNginxを使用している場合、ソースからのビルドが最も確実な方法です。
カスタマイズ性: ビルドオプションによって、必要な機能だけを有効にするなど、より細かいカスタマイズが可能です。

3.2 ModSecurityソースコードの取得

ModSecurityプロジェクト本体（libmodsecurity）と、Nginxとの連携のためのコネクタ（ModSecurity-nginx）の二つが必要です。どちらもGitHubで公開されています。

まず、libmodsecurityのソースコードを取得します。適切なディレクトリ（例: /opt/src や $HOME/src）に移動し、Gitコマンドでクローンします。

“`bash

ソースコードを置くディレクトリに移動（なければ作成）

mkdir -p /opt/src
cd /opt/src

libmodsecurityのソースコードをクローン

git clone –depth 1 -b v3/master –single-branch https://github.com/SpiderLabs/ModSecurity
“`

次に、Nginxコネクタのソースコードを取得します。これも同じディレクトリにクローンします。

“`bash

ModSecurity-nginxコネクタのソースコードをクローン

git clone –depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git
“`

ディレクトリ構成は以下のようになるはずです。

/opt/src/ ├── ModSecurity/ <-- libmodsecurity本体 └── ModSecurity-nginx/ <-- Nginxとの連携モジュール

3.3 libmodsecurityのビルドとインストール

ModSecurity-nginxモジュールは、libmodsecurityをビルドしてインストールしておく必要があります。

クローンしたModSecurityディレクトリに移動し、ビルドプロセスを開始します。

bash cd /opt/src/ModSecurity/

まず、autogen.shを実行して、configureスクリプトなどを生成します。これは、依存ライブラリや環境をチェックし、ビルドに必要なファイルを用意するステップです。

“`bash

サブモジュールをアップデート（必要な場合）

git submodule init
git submodule update

configureスクリプトなどの生成

./autogen.sh
“`

autogen.shが成功すると、configureスクリプトが生成されます。次に、このconfigureスクリプトを実行してビルド設定を行います。

“`bash

configureスクリプトの実行

–prefix=/usr/local/modsecurity のようにインストール先を指定できますが、

Nginxモジュールとして使用する場合、libmodsecurity本体のインストールは必須ではありません。

ここでは、システムデフォルトの場所（/usr/local）にインストールすることを想定します。

必要に応じてオプションを追加してください。

./configure –enable-standalone-module –disable-mlog –disable-dependency-tracking
“`

configureオプションの解説：
– --enable-standalone-module: スタンドアローンモジュールとしてビルドするためのオプションです。Nginxモジュールとして利用する場合に必要です。
– --disable-mlog: ロギング機能の一部を無効にします。通常はビルドに必須ではありませんが、特定の環境で問題を起こす場合に無効化することがあります。
– --disable-dependency-tracking: コンパイル速度を向上させるためのオプションです。開発時以外は有効にすることが推奨されます。

configureスクリプトが完了すると、システム環境と依存ライブラリが正しく検出されたかどうかのサマリーが表示されます。ここでエラーが表示された場合は、必要な依存ライブラリが不足しているか、検出できなかったことを意味します。エラーメッセージをよく確認し、不足しているライブラリをインストールしてから再度configureを実行してください。

configureが成功したら、makeコマンドでコンパイルを実行します。

“`bash

コンパイル

make
“`

コンパイルにはしばらく時間がかかります。特にエラーが出ずに完了すれば成功です。

最後に、make installでシステムにインストールします。

“`bash

インストール

sudo make install
“`

このコマンドにより、libmodsecurityのライブラリファイルやヘッダーファイルなどがシステムディレクトリ（通常 /usr/local/lib, /usr/local/include など）に配置されます。これにより、Nginxコネクタがlibmodsecurityを参照してビルドできるようになります。

発生しうるエラーと基本的な対処法：
– 依存関係エラー: configure実行時に「library not found」のようなエラーが出た場合、対応する開発用ライブラリパッケージがインストールされていません。セクション2.3を参考にインストールしてください。
– コンパイルエラー: make実行時にエラーが出た場合、環境依存の問題や、まれにソースコード自体の問題である可能性があります。エラーメッセージを検索して対処法を探るか、依存ライブラリが正しくインストールされているか再確認してください。

libmodsecurityのインストールが完了したら、次のステップとしてNginx本体にModSecurityモジュールを組み込みます。

4. NginxへのModSecurityモジュールの組み込み

NginxにModSecurityを組み込むには、Nginx本体もソースコードからビルドする必要があります。Nginxのconfigureスクリプト実行時に、ModSecurity-nginxコネクタをモジュールとして追加するように指定します。

4.1 Nginxソースコードの取得

Nginxの公式ウェブサイトから、使用したいバージョンのソースコードをダウンロードします。通常は最新の安定版で良いでしょう。

“`bash

Nginxのソースコードをダウンロード

例: Nginx 1.24.0 の場合

cd /opt/src/
wget https://nginx.org/download/nginx-1.24.0.tar.gz

ダウンロードしたファイルを展開

tar -xzf nginx-1.24.0.tar.gz
cd nginx-1.24.0/
“`

4.2 NginxのConfigureとModSecurityモジュールの追加

Nginxのソースコードディレクトリに移動したら、configureスクリプトを実行してビルド設定を行います。ここで、ModSecurity-nginxコネクタを--add-moduleオプションで指定します。

重要なのは、既存のNginx環境がある場合、現在のNginxがどのようにコンパイルされているかを確認し、その設定を新しいコンパイルオプションに含めることです。これにより、現在の機能（例: HTTP/2, SSL, 特定のモジュール）を維持したまま、ModSecurityを追加できます。

既存のNginxのコンパイルオプションを確認するには、以下のコマンドを実行します。

bash nginx -V

出力例：

nginx version: nginx/1.20.1 built by gcc 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) built with OpenSSL 1.1.1f 31 Mar 2020 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-r5T5uK/nginx-1.20.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -pie' --with-file-aio --with-threads --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_compress_module --with-http_gunzip_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module

この出力の configure arguments: 以降のオプションをコピーし、そこにModSecurityモジュールを追加するオプション --add-module=/opt/src/ModSecurity-nginx を加えてconfigureを実行します。

“`bash

Nginxソースコードディレクトリに移動

cd /opt/src/nginx-1.24.0/

configureスクリプトの実行

例: 既存設定にModSecurityモジュールを追加する場合

まず、既存のNginxの設定を確認 (nginx -V)

そして、そのオプションに –add-module=/opt/src/ModSecurity-nginx を追加して実行

sudo ./configure \
–prefix=/etc/nginx \
–sbin-path=/usr/sbin/nginx \
–modules-path=/usr/lib/nginx/modules \
# … (既存のconfigureオプションをここに貼り付け) …
–add-module=/opt/src/ModSecurity-nginx \
# … (必要に応じてその他のオプションを追加) …
–with-http_ssl_module –with-http_v2_module # 例：SSLやHTTP/2が必要ならこれらも追加
“`

重要なオプションの解説:

--add-module=/opt/src/ModSecurity-nginx: ModSecurity-nginxコネクタモジュールのソースコードディレクトリを指定します。パスは実際にクローンしたディレクトリに合わせてください。
--prefix, --sbin-path など: Nginxのインストール先や実行ファイル名を指定します。既存環境に上書きインストールする場合は、現在の設定と一致させる必要があります。
--with-http_ssl_module, --with-http_v2_module など: 必要な標準モジュールや追加モジュールを指定します。これも既存環境を維持する場合は、nginx -V の出力からコピーします。

configureが成功すると、ビルド設定が完了し、makeコマンドでコンパイルに進む準備ができます。

“`bash

コンパイル

sudo make
“`

make installはここでは実行しないことを推奨します。特に稼働中のサーバーの場合、make installは既存のNginxファイルを直接上書きするため、予期せぬ問題が発生する可能性があります。代わりに、新しくビルドされたNginxバイナリを手動で置き換える方法が安全です。

4.3 新しいNginxバイナリへの置き換え（既存環境の場合）

稼働中のNginxサーバーにModSecurityを組み込んだNginxを導入する場合、以下の手順で安全に置き換えることを推奨します。

新しいNginxバイナリの確認:
ビルドに成功すると、objs/nginx に新しいNginxの実行ファイルが作成されます。このファイルが存在することを確認します。

bash ls /opt/src/nginx-1.24.0/objs/nginx
既存のNginxバイナリのバックアップ:
万が一の問題に備え、現在使用しているNginxバイナリをバックアップします。Nginxの実行ファイルの場所は、nginx -V コマンドの --sbin-path オプションで確認できます。

“`bash

実行ファイルの場所を確認

nginx -V 2>&1 | grep –color=auto sbin-path

例: /usr/sbin/nginx をバックアップする場合

sudo cp /usr/sbin/nginx /usr/sbin/nginx.bak
“`
新しいNginxバイナリへの置き換え:
ビルドした新しいNginxバイナリを実行ファイルの場所にコピーします。

“`bash

例: /usr/sbin/nginx に新しいバイナリをコピー

sudo cp /opt/src/nginx-1.24.0/objs/nginx /usr/sbin/nginx
“`
Nginx設定ファイルのシンタックスチェック:
新しいバイナリでNginx設定ファイルにエラーがないか確認します。

bash sudo nginx -t

test is successful と表示されれば問題ありません。もしエラーが出る場合は、設定ファイルに問題があるか、新しいNginxバイナリが正しくビルドされていない可能性があります。エラーメッセージに従って修正してください。
Nginxの graceful reload:
稼働中のNginxプロセスを停止せずに、新しいバイナリに切り替えます。これにより、既存の接続を維持しながら新しい設定とバイナリを適用できます。

bash sudo nginx -s reload

もし reload で問題が発生したり、Nginxが起動していなかったりする場合は、一度Nginxを停止してから起動を試みます。

bash sudo systemctl stop nginx # または service nginx stop sudo systemctl start nginx # または service nginx start

Nginxがエラーなく再起動またはリロードされれば、ModSecurityモジュールが組み込まれた新しいNginxが動作している状態です。

4.4 新規インストールのNginxの場合

もし既存のNginxがなく、新規にインストールする場合は、make install を実行しても構いません。これにより、Nginxの設定ファイルなども含めてデフォルトの場所にインストールされます。

bash cd /opt/src/nginx-1.24.0/ sudo make install

この場合、設定ファイルは通常 /usr/local/nginx/conf/ に配置されます。サービスの起動設定なども別途必要になります。

これで、NginxにModSecurityモジュールが組み込まれました。次に、ModSecurityの設定を行います。

5. ModSecurityの基本設定

ModSecurityを有効にしてWAFとして機能させるためには、設定ファイルが必要です。ModSecurityの設定は、独自のディレクティブを使用して行います。

5.1 設定ファイルの準備

ModSecurityのソースコードには、推奨される設定ファイルの例が含まれています。これをベースに設定ファイルを作成します。

libmodsecurityのソースコードディレクトリにある modsecurity.conf-recommended を、Nginxが読み込める場所にコピーします。Nginxの設定ファイル群と同じディレクトリ（例: /etc/nginx/) が適しています。

“`bash

例: 設定ファイルを /etc/nginx/ にコピーし、名前を変更

sudo cp /opt/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsecurity.conf
“`

5.2 主要なModSecurityディレクティブの説明

modsecurity.conf ファイルを開き、必要に応じて設定を編集します。以下に、重要なディレクティブの一部を解説します。

SecRuleEngine: ModSecurityのルール処理を有効にするかどうかを制御します。
- On: ルールを有効にし、一致したルールのアクションを実行します（例: リクエストをブロック）。
- Off: ModSecurity全体を無効にします。
- DetectionOnly: ルールを評価しますが、ブロックなどの破壊的なアクションは実行しません。ログ記録のみを行います。新しいルールセットをテストする際などに便利です。
nginx SecRuleEngine On
SecAuditEngine: 監査ログ（ModSecurityが検知またはブロックしたイベントの詳細ログ）を記録するかどうかを制御します。
- Off: 監査ログを記録しません。
- RelevantOnly: ブロックなどのアクションが実行された場合のみログを記録します。
- On: すべてのトランザクションについてログを記録します（トラフィック量が多い場合はディスク容量に注意）。
nginx SecAuditEngine RelevantOnly
SecAuditLog: 監査ログファイルのパスを指定します。

nginx SecAuditLog /var/log/modsecurity/audit.log
SecAuditLogParts: 監査ログに含める情報のパートを指定します。各パートはアルファベット1文字で表現されます（A: ヘッダー、B: リクエストボディ、C: 監査メッセージ、D: 最終ルールなど）。Allを指定するとすべてのパートが記録されます。

nginx SecAuditLogParts ABCEFHJKZ
SecAuditLogFormat: 監査ログの形式を指定します。JSON または Concurrent が一般的です。Concurrentは古い形式ですが、一部のログ分析ツールで利用されます。JSONが推奨されます。

nginx SecAuditLogFormat JSON
SecDebugLogLevel: デバッグログの詳細度を指定します。0（ログなし）から9（すべての情報）まであります。トラブルシューティング時にレベルを上げることがありますが、通常運用では低めのレベル（0～3程度）を推奨します。

nginx SecDebugLogLevel 0
SecDebugLog: デバッグログファイルのパスを指定します。

nginx SecDebugLog /var/log/modsecurity/debug.log

注意: 監査ログ (SecAuditLog) とデバッグログ (SecDebugLog) の出力先ディレクトリ（例: /var/log/modsecurity/）は、事前に手動で作成し、Nginxを実行するユーザー（通常 nginx や www-data など）が書き込める権限を付与しておく必要があります。

bash sudo mkdir /var/log/modsecurity sudo chown nginx:nginx /var/log/modsecurity # または chown www-data:www-data sudo chmod 755 /var/log/modsecurity
SecRequestBodyAccess: リクエストボディの検査を有効にするかどうか。OnにするとPOSTデータなどを検査します。ファイルをアップロードするフォームがある場合などに重要です。

nginx SecRequestBodyAccess On
SecResponseBodyAccess: レスポンスボディの検査を有効にするかどうか。Onにするとサーバーからの応答内容を検査します。情報漏洩対策などに利用できますが、パフォーマンスへの影響が大きいため、通常は無効（Off）か、特定のMIMEタイプのみ有効にすることが多いです。

nginx SecResponseBodyAccess Off
SecDataDir: ModSecurityが一時ファイルなどを保存するディレクトリを指定します。このディレクトリもNginx実行ユーザーが書き込める必要があります。

nginx SecDataDir /var/cache/modsecurity

ディレクトリの作成と権限設定も同様に行います。

bash sudo mkdir /var/cache/modsecurity sudo chown nginx:nginx /var/cache/modsecurity # または chown www-data:www-data sudo chmod 755 /var/cache/modsecurity

これらの基本設定に加えて、ルールセットを読み込む設定が必要です。

5.3 設定ファイル構成の推奨プラクティス

ModSecurityの設定ファイルは、メインの設定ファイル（例: modsecurity.conf）と、ルールセットを記述した複数のファイルを組み合わせて構成するのが一般的です。メインファイルでは、エンジン全体の有効/無効、ロギング設定、一般的なパラメータなどを定義し、ルールファイルは Include ディレクティブを使って読み込みます。

“`nginx

メイン設定ファイル (/etc/nginx/modsecurity.conf)

SecRuleEngine On
SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsecurity/audit.log
SecDebugLog /var/log/modsecurity/debug.log
SecDataDir /var/cache/modsecurity

… その他の基本設定 …

ルールセットの読み込み（次のセクションで説明）

Include /path/to/rules/*.conf

“`

このようにファイルを分割することで、設定の見通しが良くなり、ルールの管理が容易になります。

6. OWASP ModSecurity コア・ルール・セット (CRS) の導入と設定

ModSecurityは単なるWAFエンジンであり、実際にどのような攻撃パターンを検知・遮断するかを定義するのが「ルール」です。手動でルールを作成することも可能ですが、高度な攻撃に対応するためには、OWASPが提供するModSecurity コア・ルール・セット（CRS）を利用するのが一般的です。

6.1 CRSとは何か、その重要性

OWASP ModSecurity コア・ルール・セット (CRS) は、Webアプリケーションの一般的な脆弱性（SQLインジェクション、XSS、LFI/RFI、RCEなど）に対する防御を提供する、汎用的で堅牢なルールセットです。CRSは、シグネチャベースの検知と異常スコアリングシステムを組み合わせて動作します。

シグネチャベース: 既知の攻撃パターンに一致するトラフィックを検知します。
異常スコアリング: 各ルールに「スコア」が割り当てられており、一致したルールのスコアが累積されます。合計スコアが閾値を超えた場合に、リクエストを悪意のあるものと判断してブロックします。これにより、単一のルールには一致しないが、複数の不審なパターンを含むリクエストも検知できます。

CRSは定期的に更新され、新しい攻撃手法に対応するためのルールが追加されます。CRSを導入することで、手動で複雑なルールを作成する手間を省き、効果的なWAF保護を迅速に実現できます。

6.2 CRSの取得方法

CRSもGitHubで公開されています。ModSecurity本体やNginxコネクタと同様に、Gitコマンドでソースコードを取得します。

“`bash

CRSソースコードを置くディレクトリに移動（なければ作成）

mkdir -p /etc/nginx/waf/crs # 例: Nginx設定ディレクトリ配下に配置

CRSのソースコードをクローン

cd /etc/nginx/waf/crs
git clone –depth 1 https://github.com/OWASP/CRS
“`

ディレクトリ構成は以下のようになるはずです。

/etc/nginx/waf/crs/CRS/ ├── crs-setup.conf.example ├── rules/ │ ├── REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example │ ├── REQUEST-901-INITIALIZATION.conf │ ├── REQUEST-905-COMMON-EXCEPTIONS.conf │ ├── REQUEST-910-IP-REPUTATION.conf │ ├── REQUEST-911-METHOD-ENFORCEMENT.conf │ # ... 他のルールファイル ... │ └── RESPONSE-959-BLOCKING-EVALUATION.conf └── UPLOAD-INVALID-FILE.data

6.3 CRSの設定 (`crs-setup.conf`)

CRSには、いくつかの設定をカスタマイズするための crs-setup.conf.example ファイルが含まれています。これをコピーして crs-setup.conf として使用します。

“`bash

crs-setup.conf ファイルを準備

cd /etc/nginx/waf/crs/CRS/
cp crs-setup.conf.example crs-setup.conf
“`

crs-setup.conf ファイルを開き、必要に応じて設定を編集します。このファイルには、異常スコアリングの閾値など、CRSの動作に影響を与える重要な設定が含まれています。

主な設定項目：

異常スコアリングの閾値 (paranoia_level): CRSは「偏執病レベル (Paranoia Level)」という概念でルールの厳格さを調整します。レベル1が最も緩く、レベル4が最も厳しくなります。レベルを上げるほど検知できる脅威の種類は増えますが、偽陽性（正当なリクエストを誤ってブロックすること）の可能性も高くなります。最初はデフォルトのレベル1から始め、偽陽性を抑えつつ徐々にレベルを上げていくのが一般的です。

“`nginx

Default paranoia level is 1 (lowest setting)

To increase the level, uncomment the appropriate SecAction below.

# SecAction \
# “id:900000,\
# phase:1,\
# nolog,\
# pass,\
# ctl:ruleEngine=On,\
# ctl:ruleRemoveById=900005,\

setvar:tx.paranoia_level=1″

例：レベルを2に設定する場合、対応するSecActionのコメントアウトを外す

# SecAction \
# “id:900000,\
# phase:1,\
# nolog,\
# pass,\
# ctl:ruleEngine=On,\
# ctl:ruleRemoveById=900005,\

setvar:tx.paranoia_level=2″

`` この設定は、SecActionディレクティブを使って行われます。paranoia_level` を設定したいレベルに合わせてコメントアウトを外します。
閾値スコア (tx.critical_anomaly_score, tx.error_anomaly_score, tx.warning_anomaly_score, tx.notice_anomaly_score): 各異常スコアレベルに対応する閾値です。通常、これらのデフォルト値（Critical: 5, Error: 4, Warning: 3, Notice: 2）を変更する必要はありません。総合スコアがこれらの閾値を超えた場合に、対応するアクション（通常はブロック）がトリガーされます。

“`nginx

Default anomaly scoring thresholds

The score for each anomaly level is defined in RESPONSE-980-CORRELATION.conf.

Default scores are:

– Critical: 5

– Error: 4

– Warning: 3

– Notice: 2

Uncomment and modify these SecActions to change the default thresholds.

# SecAction \
# “id:900006,\
# phase:1,\
# nolog,\
# pass,\

setvar:tx.critical_anomaly_score=5″

… 他の閾値設定 …

`` これらの閾値を変更する場合は、対応するSecAction`のコメントアウトを外し、値を変更します。

crs-setup.confには他にも様々な設定項目がありますが、まずはデフォルト値のまま進め、必要に応じて後からチューニングしていくことを推奨します。

6.4 ModSecurity設定ファイルからのCRSルールのインクルード

準備したCRSルールセットを、メインのModSecurity設定ファイル（例: /etc/nginx/modsecurity.conf）から読み込むように設定します。Include ディレクティブを使用します。

modsecurity.conf の最後に、以下の行を追加します。

“`nginx

CRS設定ファイルの読み込み

Include /etc/nginx/waf/crs/CRS/crs-setup.conf

CRSルールファイルの読み込み

exclude any rules you do not want to use

Include /etc/nginx/waf/crs/CRS/rules/*.conf
“`

ここで指定するパスは、CRSをクローンした実際の場所に合わせてください。rules/*.conf とすることで、rules ディレクトリ内のすべての .conf ファイルが読み込まれます。

ルールの読み込み順序の重要性: CRSのルールは、特定の順序で読み込まれることを前提として設計されています。crs-setup.conf を最初に読み込み、その後で rules ディレクトリ内のファイル群を読み込むのが正しい順序です。Include /path/to/crs-setup.conf を Include /path/to/rules/*.conf より前に記述してください。通常、ファイル名のアルファベット順で読み込まれるため、CRSのファイル名は番号が振られており、正しい順序で読み込まれるようになっています。

7. Nginx設定ファイルでのModSecurityの有効化

ModSecurityモジュールとCRSルールセットの準備ができたら、Nginxの設定ファイルでModSecurityを有効にします。

ModSecurityは、http, server, location の各ブロックで有効化できます。適用したい範囲に応じて適切なブロックで設定を行います。

http ブロック: すべてのバーチャルホスト、すべての場所にModSecurityを適用する場合。
server ブロック: 特定のバーチャルホスト（ドメイン）にModSecurityを適用する場合。
location ブロック: 特定のURLパスにのみModSecurityを適用する場合。

最も一般的なのは server ブロックまたは http ブロックで有効化し、必要に応じて特定の location で無効化したり、異なるルールを適用したりする方法です。

7.1 `modsecurity` および `modsecurity_rules_file` ディレクティブ

Nginx設定ファイルでModSecurityを有効にするには、以下のディレクティブを使用します。

modsecurity [ on | off | detection_only ];
そのブロック内でModSecurityを有効にするかどうかを制御します。modsecurity.conf の SecRuleEngine に似ていますが、これはNginx側でモジュール自体を有効にするかどうかの設定です。通常は on または detection_only に設定します。
modsecurity_rules_file path/to/modsecurity.conf;
ModSecurityのメイン設定ファイル（上で作成した /etc/nginx/modsecurity.conf など）のパスを指定します。このファイルからCRSなどのルールが読み込まれます。
modsecurity_rules rules_string;
Nginx設定ファイル内に直接ModSecurityルールを記述するためのディレクティブです。単一のシンプルなルールを追加する場合には便利ですが、CRSのような複雑なルールセットは管理が困難になるため、通常は modsecurity_rules_file を使用します。

7.2 設定例：Serverブロックでの有効化

特定のバーチャルホスト (server ブロック) に対してModSecurityとCRSを有効にする例です。

“`nginx
http {
# … 他のhttp設定 …

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com;

    # ModSecurityとCRSを有効にする
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsecurity.conf; # ModSecurityメイン設定ファイルを指定

    location / {
        # ... アプリケーション固有の設定 ...
    }

    # 必要に応じて、特定のlocationでModSecurityを無効化することも可能
    # 例: /admin パスではModSecurityを無効にする
    # location /admin {
    #     modsecurity off;
    #     # ...
    # }

    error_log /var/log/nginx/example.com_error.log;
    access_log /var/log/nginx/example.com_access.log;
}

# ... 他のserverブロック ...

}
“`

この設定により、example.com へのリクエストに対してModSecurity WAFが適用され、/etc/nginx/modsecurity.conf で定義されたルール（CRSを含む）に従って検査が行われます。

7.3 設定ファイル全体の確認

ModSecurityとCRSの設定ファイル、およびNginx設定ファイルの全体的な構成を再確認しましょう。

ModSecurityメイン設定ファイル (/etc/nginx/modsecurity.conf):
- SecRuleEngine On; または DetectionOnly;
- ロギング設定 (SecAuditEngine, SecAuditLog, SecDebugLogLevel, SecDebugLog, SecDataDir)
- Include /etc/nginx/waf/crs/CRS/crs-setup.conf;
- Include /etc/nginx/waf/crs/CRS/rules/*.conf; （パスは正しいか？）
CRS設定ファイル (/etc/nginx/waf/crs/CRS/crs-setup.conf):
- paranoia_level など、必要に応じた設定変更。
Nginx設定ファイル (/etc/nginx/nginx.conf またはインクルードファイル):
- ModSecurityを適用したい http, server, または location ブロックで modsecurity on; を記述。
- 同じブロックで modsecurity_rules_file /etc/nginx/modsecurity.conf; を記述。

これで、ModSecurityとCRSがNginxに組み込まれ、設定も完了しました。次は動作確認とトラブルシューティングに進みます。

8. 動作確認と基本的なトラブルシューティング

ModSecurityを導入した後、正しく動作しているかを確認し、問題が発生した場合の対処法を知っておくことは非常に重要です。

8.1 Nginx設定ファイルのシンタックスチェック

設定ファイルを編集した後は、必ずNginxのシンタックスチェックを行います。

bash sudo nginx -t

エラーがあればメッセージが表示されます。test is successful と表示されれば、設定ファイルの記述に構文上の問題はありません。

8.2 Nginxの再起動またはリロード

設定を反映させるためには、Nginxを再起動またはリロードします。Graceful reload (nginx -s reload) が可能であれば、既存の接続を維持できるため推奨されます。

“`bash
sudo systemctl reload nginx # または service nginx reload

もしくは

sudo systemctl restart nginx # または service nginx restart

“`

Nginxがエラーなく起動・リロードされることを確認します。もし起動しない場合は、Nginxのエラーログを確認してください（通常 /var/log/nginx/error.log）。権限問題や設定ファイルのパス間違い、コンパイルミスなどが原因で起動できないことがあります。

8.3 テストリクエストの実行

ModSecurityが正しく機能しているかを確認するために、意図的に悪意のあるパターンを含むリクエストを送信してみます。

例として、シンプルなSQLインジェクション攻撃パターンを含むURLにアクセスしてみます。

“`bash

Webブラウザまたはcurlコマンドでアクセス

例: http://example.com/?id=1’+OR+’1’=’1

curl “http://example.com/?id=1’+OR+’1’=’1” -I
“`

もしModSecurityが正しく動作していれば、このリクエストはCRSのSQLインジェクションルールにマッチし、ブロックされるはずです。デフォルト設定では、通常HTTPステータスコード403 Forbiddenが返されます。

“`
HTTP/1.1 403 Forbidden
Server: nginx/…

… 他のヘッダー …

“`

403以外のステータスコードが返されたり、アプリケーションの応答が返されたりする場合は、ModSecurityが有効になっていないか、ルールが正しく読み込まれていない可能性があります。

8.4 ModSecurityログの確認

ModSecurityのログファイルは、WAFの動作を確認し、問題を特定するための最も重要な情報源です。上で設定した SecAuditLog と SecDebugLog のパスを確認します。

監査ログ (audit.log)

監査ログには、ModSecurityが処理した各リクエストに関する詳細な情報が記録されます。特に、ルールに一致してブロックされたリクエストはここに記録されます。

bash sudo tail /var/log/modsecurity/audit.log

ログエントリは複数のパートに分かれています（Aパート: リクエストヘッダー、Bパート: リクエストボディ、Cパート: 監査メッセージ、Hパート: 監査トレイル/マッチしたルールなど）。JSON形式で出力している場合は、jqなどのツールで整形すると読みやすくなります。

リクエストがブロックされた場合、監査ログのCパートまたはHパートに、どのルールが一致し、なぜブロックされたのかの情報が含まれています。例えば、[for XSS], [for SQL injection] といったメッセージや、一致したルールのID ([id "942000"]) が記録されます。

デバッグログ (debug.log)

デバッグログは、ModSecurityエンジンのより低レベルな動作情報や、ルールの評価プロセスに関する詳細を記録します。通常運用ではログレベルを低くしておきますが、特定のルールがなぜ一致しないのか、あるいは誤検知がなぜ発生するのかなどを調査する際に、ログレベルを上げて (SecDebugLogLevel を高い値に設定) 詳細な情報を取得します。

bash sudo tail /var/log/modsecurity/debug.log

デバッグログは非常に詳細で大量の情報が出力されるため、トラブルシューティング時以外はログレベルを上げすぎないように注意が必要です。

8.5 Nginxエラーログの確認

Nginx自身のエラーログ（通常 /var/log/nginx/error.log）にも、ModSecurityに関連するエラーが出力されることがあります。ModSecurityモジュールの読み込みエラー、設定ファイルの解析エラー、権限エラーなどが記録されます。

bash sudo tail /var/log/nginx/error.log

8.6 一般的な問題と解決策

Nginxが起動しない:
- nginx -t で設定ファイルのシンタックスエラーを確認。
- Nginxエラーログで詳細を確認。
- ModSecurity設定ファイル (modsecurity.conf, crs-setup.conf) のパスが正しいか、Nginx実行ユーザーが読み込めるか確認。
- ModSecurityログやデータディレクトリ (SecAuditLog, SecDebugLog, SecDataDir) が存在し、Nginx実行ユーザーが書き込める権限があるか確認。
- Nginxをソースからビルドし直す際、configure オプションが正しいか、特に --add-module のパスが正しいか確認。
- libmodsecurityが正しくインストールされたか確認 (sudo make install がエラーなく完了したか)。
ModSecurityが有効にならない（403にならない）:
- Nginx設定ファイル (server または location ブロック) で modsecurity on; が設定されているか確認。
- modsecurity_rules_file で指定されたパスが正しいか確認。
- 指定されたModSecurity設定ファイル (modsecurity.conf) 内で SecRuleEngine On; が設定されているか確認。
- 監査ログ (audit.log) にリクエストが記録されているか確認。記録されていない場合は、ModSecurityモジュール自体がロードされていない可能性が高いです（Nginxのビルドを確認）。記録されているがブロックされていない場合は、ルールが一致していないか、ブロックアクションが設定されていない可能性があります。
リクエストがブロックされるが、監査ログに情報がない:
- SecAuditEngine の設定を確認 (On または RelevantOnly になっているか)。
- SecAuditLog のパスが正しく、Nginx実行ユーザーが書き込めるか確認。
誤検知が多い（正当なリクエストがブロックされる）:
- これはWAF運用で最も頻繁に発生する問題です。次セクション「運用とチューニング」で詳しく解説します。まずは監査ログを確認し、どのルールIDでブロックされているかを特定します。
パフォーマンスが著しく低下した:
- SecResponseBodyAccess が On になっていないか確認。通常は Off にすることを推奨します。
- SecDebugLogLevel が高い値になっていないか確認。通常運用では0～3程度にします。
- 大量のロギングが発生していないか確認。
- 正規表現を含むカスタムルールが非効率的でないか確認。
- パフォーマンス問題の切り分けのため、SecRuleEngine DetectionOnly; にしてブロックはせずに検査だけ行い、パフォーマンスの変化を確認するのも有効です。

9. ModSecurityの運用とチューニング

ModSecurityとCRSを導入した後、そのまま放置せず、継続的な運用とチューニングが必要です。特に、誤検知（偽陽性）への対応と、新たな脅威への対応が重要になります。

9.1 偽陽性 (False Positive) への対応

CRSは汎用的なルールセットであるため、特定のアプリケーションにとっては正当なリクエストが、攻撃パターンとして誤検知されることがあります。例えば、HTMLタグの入力が許可されているフォームでXSSルールが誤検知されたり、特定のパラメータ値がSQLインジェクションとして検知されたりする場合です。

偽陽性が発生した場合は、まず監査ログを確認し、どのルールIDが一致してブロックされたのかを特定します。その後、以下の方法で対応します。

特定のルールIDの除外 (ctl:ruleRemoveById): 最も一般的な方法です。特定のルールIDを、特定の server または location ブロックに対して無効化します。

“`nginx
location /some/path {
# この場所ではルールID 942100 (XSSに関連する可能性のあるルール) を無効にする
modsecurity_rules ‘SecRuleRemoveById 942100;’;
# …
}

server {
server_name specific.example.com;
# このバーチャルホスト全体でルールID 931130 (SQLインジェクションに関連する可能性のあるルール) を無効にする
modsecurity_rules ‘SecRuleRemoveById 931130;’;
# …
}
`` 複数のルールを除外する場合は、カンマで区切って指定できます:modsecurity_rules ‘SecRuleRemoveById 942100,931130;’;`。
特定の引数やURLに対するルール除外 (SecRuleUpdateTargetById): 特定のルールを、特定の引数名やURLに対してのみ適用しないように設定します。これは crs-setup.conf や別途作成した設定ファイルで行うのが一般的です。

“`nginx

CRS設定ファイルやカスタム設定ファイルに追加

SecRuleUpdateTargetById 942100 !ARGS:comment # ルールID 942100 を ARGS:comment に対して無効化
SecRuleUpdateTargetById 931130 !REQUEST_URI:/search.php # ルールID 931130 を /search.php へのリクエストURIに対して無効化
``SecRuleUpdateTargetById [!]変数:対象` の形式で記述します。
特定のURLやIPアドレスのホワイトリスト化 (ctl:ruleEngine): 特定のURLや、特定のIPアドレスからのリクエストに対して、ModSecurityのルール処理を完全に無効化します。

“`nginx

特定のIPアドレスからのリクエストをホワイトリスト化

SecRule REMOTE_ADDR “@ipMatch 192.168.1.100” “id:999999,phase:1,nolog,pass,ctl:ruleEngine=Off”

特定のURLパスをホワイトリスト化

SecRule REQUEST_URI “^/admin/” “id:999998,phase:1,nolog,pass,ctl:ruleEngine=Off”
`` これはmodsecurity_rules` ディレクティブまたは別途Includeした設定ファイルで記述します。ルールのフェーズはリクエスト処理の早い段階（phase:1）で行うのが効率的です。
スコアリング閾値の調整: CRSの crs-setup.conf で設定した異常スコアリングの閾値を調整することも、偽陽性を減らす一つの方法です。閾値を上げるほど、ブロックされるためにはより多くの（またはより深刻な）ルールに一致する必要があるため、誤検知は減ります。ただし、正当な攻撃も見逃すリスクが高まるため、慎重に調整が必要です。

偽陽性のチューニングは継続的なプロセスです。アプリケーションのアップデートや機能追加によって新たな誤検知が発生する可能性があるため、監査ログを定期的に監視し、必要に応じてルールを調整していく必要があります。

9.2 性能への影響と対策

WAFはすべてのリクエストを詳細に検査するため、少なからずWebサーバーのパフォーマンスに影響を与えます。特にトラフィック量が多い環境では、性能への影響を最小限に抑えるための考慮が必要です。

SecResponseBodyAccess Off: 前述のとおり、レスポンスボディの検査は多くのリソースを消費するため、特別な理由がない限り無効にすることを強く推奨します。
不要なルールの無効化: CRSには非常に多くのルールが含まれていますが、アプリケーションの特性によっては不要なルール（例: XMLRPCを使用しないアプリケーションでのXML関連ルール）が存在する場合があります。監査ログやデバッグログを確認し、全く一致しない、あるいは常に誤検知を引き起こすようなルールがあれば、それらを個別に無効化することで負荷を軽減できる可能性があります。ただし、ルールの依存関係に注意が必要です。
正規表現の最適化: カスタムルールを作成する場合、効率的な正規表現を使用することが重要です。非効率な正規表現は、検査時にCPUを過剰に消費し、Denial of Service (DoS) 攻撃に悪用される可能性もあります。
ModSecurityのログレベル: SecDebugLogLevel を必要以上に高く設定しないことも重要です。詳細なデバッグログはパフォーマンスに影響を与えます。
ハードウェアのリソース: トラフィック量に対してサーバーのリソース（CPU, メモリ, ディスクI/O）が不足している場合、WAFの処理がボトルネックになる可能性があります。必要に応じてリソースを増強することを検討します。

9.3 ロギングと監視

WAFの運用において、ログは非常に重要です。監査ログとデバッグログを適切に設定し、定期的に監視することで、攻撃の傾向、誤検知の発生、WAFの正常な動作などを把握できます。

ログファイルのローテーション: 監査ログやデバッグログはトラフィック量に応じて大量に生成される可能性があります。ログファイルをローテーションする設定（logrotateなど）を忘れずに行ってください。
ログ分析ツール: 大量のログを手動で確認するのは困難です。ELK Stack (Elasticsearch, Logstash, Kibana)、Splunk、Graylogなどのログ分析プラットフォームにModSecurityのログを取り込み、可視化・分析・アラート設定を行うことで、より効果的に運用できます。CRSの監査ログフォーマットをJSONに設定している場合、ログ分析ツールでの取り込みが容易になります。
監視システムの統合: ZabbixやPrometheusなどの監視システムと連携し、ModSecurityに関連するエラーログや、ブロックされたリクエスト数などのメトリクスを監視することで、異常を早期に検知できます。

9.4 ルールセットの更新

CRSは継続的に開発されており、新しい攻撃手法に対応するためのルールが追加されたり、既存のルールの改善が行われたりします。定期的にCRSのソースコードを更新し、最新のルールを適用することを推奨します。

“`bash

CRSソースコードディレクトリに移動

cd /etc/nginx/waf/crs/CRS/

/etc/nginx/waf/rules/custom_rules.conf などに配置

SecRule ARGS:secret “@streq evilstring” \
“id:1000001,\
phase:2,\
block,\
msg:’Custom Rule: Detected prohibited string in secret parameter’,\
log,\
auditlog,\
severity:’CRITICAL'”
“`

カスタムルールを作成する際は、既存のCRSルールとの干渉に注意が必要です。また、パフォーマンスへの影響も考慮して、複雑すぎる正規表現などは避けるようにします。

10. まとめと今後の展望

本記事では、NginxにModSecurityをソースコードからインストールし、OWASP CRSと組み合わせてWAFとして機能させるための詳細な手順を解説しました。libmodsecurityのビルド、Nginxへのモジュール組み込み、基本設定、CRSの導入と設定、そして運用上の注意点まで、一連の流れを網羅しました。

NginxにModSecurityを導入することで、WebアプリケーションをSQLインジェクションやXSSといった一般的なWeb攻撃から保護し、セキュリティレベルを大幅に向上させることができます。Nginxの高いパフォーマンスと組み合わせることで、負荷の高い環境でも有効なWAFソリューションとなり得ます。

しかしながら、WAFは万能ではありません。WAFは既知の攻撃パターンや一般的な不審な振る舞いを検知することに長けていますが、未知のゼロデイ攻撃や、アプリケーションのロジック上の脆弱性を突く攻撃（例: 認証・認可の不備、ビジネスロジックの欠陥）には対応できない場合があります。

したがって、WAFはセキュリティ対策の「最後の砦」として過信せず、他の多層防御策と組み合わせて利用することが非常に重要です。

セキュアコーディング: アプリケーション開発段階でセキュリティを考慮し、入力値の検証、出力のエスケープ、安全なAPIの使用などを徹底します。これが最も根本的な対策です。
IDS/IPS: Intrusion Detection System/Intrusion Prevention System は、ネットワークレベルでの不正侵入や攻撃パターンを検知・防御します。
ネットワークファイアウォール: 不必要なポートを閉じ、アクセス元IPアドレスを制限するなど、ネットワークレベルでのフィルタリングを行います。
脆弱性スキャン: 定期的にWebアプリケーションやインフラの脆弱性スキャンを実施し、発見された脆弱性を修正します。
セキュリティパッチ: OS、Webサーバー、ミドルウェア、アプリケーションフレームワーク、ライブラリなどを常に最新の状態に保ち、既知の脆弱性を解消します。

ModSecurity自体も進化を続けています。ModSecurity v3は、これまでのバージョンよりもパフォーマンスが向上し、よりモダンな設計になっています。また、コミュニティによってCRSも活発にメンテナンスされています。

Webアプリケーションのセキュリティは、一度対策すれば終わりではなく、継続的な監視、分析、改善が必要なプロセスです。本記事で解説した手順を参考に、皆様のNginx環境でModSecurityを効果的に導入・運用し、Webアプリケーションを様々な脅威から守り抜いてください。

NginxにModSecurityを導入して強固なWAFを構築する：詳細手順と設定ガイド

1. はじめに：Webアプリケーションの脅威とModSecurityの役割

2. 導入前の準備：システム要件と必要なツール

2.1 システム要件とOSの選択

2.2 必要なコンパイラおよびビルドツール

2.3 ModSecurityが必要とするその他の依存ライブラリ

3. ModSecurityのインストール：ソースコードからのビルド

3.1 なぜソースコードからビルドするのか

3.2 ModSecurityソースコードの取得

ソースコードを置くディレクトリに移動（なければ作成）

libmodsecurityのソースコードをクローン

ModSecurity-nginxコネクタのソースコードをクローン

3.3 libmodsecurityのビルドとインストール

サブモジュールをアップデート（必要な場合）

configureスクリプトなどの生成

configureスクリプトの実行

–prefix=/usr/local/modsecurity のようにインストール先を指定できますが、

Nginxモジュールとして使用する場合、libmodsecurity本体のインストールは必須ではありません。

ここでは、システムデフォルトの場所（/usr/local）にインストールすることを想定します。

必要に応じてオプションを追加してください。

コンパイル

インストール

4. NginxへのModSecurityモジュールの組み込み

4.1 Nginxソースコードの取得

Nginxのソースコードをダウンロード

例: Nginx 1.24.0 の場合

ダウンロードしたファイルを展開

4.2 NginxのConfigureとModSecurityモジュールの追加

Nginxソースコードディレクトリに移動

configureスクリプトの実行

例: 既存設定にModSecurityモジュールを追加する場合

まず、既存のNginxの設定を確認 (nginx -V)

そして、そのオプションに –add-module=/opt/src/ModSecurity-nginx を追加して実行

コンパイル

4.3 新しいNginxバイナリへの置き換え（既存環境の場合）

実行ファイルの場所を確認

例: /usr/sbin/nginx をバックアップする場合

例: /usr/sbin/nginx に新しいバイナリをコピー

4.4 新規インストールのNginxの場合

5. ModSecurityの基本設定

5.1 設定ファイルの準備

例: 設定ファイルを /etc/nginx/ にコピーし、名前を変更

5.2 主要なModSecurityディレクティブの説明

5.3 設定ファイル構成の推奨プラクティス

メイン設定ファイル (/etc/nginx/modsecurity.conf)

… その他の基本設定 …

ルールセットの読み込み（次のセクションで説明）

Include /path/to/rules/*.conf

6. OWASP ModSecurity コア・ルール・セット (CRS) の導入と設定

6.1 CRSとは何か、その重要性

6.2 CRSの取得方法

CRSソースコードを置くディレクトリに移動（なければ作成）

CRSのソースコードをクローン

6.3 CRSの設定 (crs-setup.conf)

crs-setup.conf ファイルを準備

Default paranoia level is 1 (lowest setting)

To increase the level, uncomment the appropriate SecAction below.

setvar:tx.paranoia_level=1″

例：レベルを2に設定する場合、対応するSecActionのコメントアウトを外す

setvar:tx.paranoia_level=2″

Default anomaly scoring thresholds

The score for each anomaly level is defined in RESPONSE-980-CORRELATION.conf.

Default scores are:

– Critical: 5

– Error: 4

– Warning: 3

– Notice: 2

Uncomment and modify these SecActions to change the default thresholds.

setvar:tx.critical_anomaly_score=5″

… 他の閾値設定 …

6.4 ModSecurity設定ファイルからのCRSルールのインクルード

CRS設定ファイルの読み込み

CRSルールファイルの読み込み

exclude any rules you do not want to use

7. Nginx設定ファイルでのModSecurityの有効化

7.1 modsecurity および modsecurity_rules_file ディレクティブ

7.2 設定例：Serverブロックでの有効化

7.3 設定ファイル全体の確認

8. 動作確認と基本的なトラブルシューティング

8.1 Nginx設定ファイルのシンタックスチェック

6.3 CRSの設定 (`crs-setup.conf`)

7.1 `modsecurity` および `modsecurity_rules_file` ディレクティブ

コメントする返信をキャンセル