ApacheのWAFモジュールであるmod_securityを導入します。
- AWS 時代から早々とインストールしていた
- 各種不審なIPアドレスを弾くための盾
として機能している、筆者のVPS運用の核となる技術。その2026年版です。
そもそもWAFとは？
WAFとはWeb Application Firewallの略で、Webアプリケーション層の脆弱性を狙った攻撃を防ぐためのセキュリティシステムです。
- UFWやFail2banがIPアドレスやポート番号といった家の玄関を監視するのに対し、WAFは、Webサーバーへ届く手紙（HTTPリクエスト）の中身を解析し、悪意あるスクリプトやコマンドの有無をチェックします。
- UFWでは、通常のポート（80番や443番）を通る攻撃は防げませんが、WAFは攻撃の内容を解析し、独自のルールセットに基づき「このアクセスは許可するが、このコードがアクセスすることは許可しない」という、より柔軟で厳しいセキュリティチェックを施します。
この機能により、Webサーバーやアプリケーション本体に脆弱性が見つかったとしても、WAFが前段の盾としてこれをカバーできます。
ModSecurityとは？
ModSecurityは、IIS/Apache/Nginxといった主要なWebサーバープログラムにモジュールとして組み込みが可能なオープンソースのWAFです。
- 導入コスト: ライセンス費用が不要であり、既存のWebサーバーと連携する形で容易に組み込めます。
- 柔軟性: OSSであるため、高い柔軟性を持ち、設定（チューニング）次第でピンポイントの防御や包括的な防御を併せ持つことができます。
備考（バージョンの選択）:
本稿で導入するModSecurityは、Ubuntu 24.04系のパッケージ管理で提供されるEOL (End-of-Life) となっているv2ですが、機能性は単一VPSの防御としては十分です。
v3への移行は、セキュリティ強度とメンテナンス性を考慮し、パッケージ化ないしはOSアップデートなどのタイミングでまた後日検討していきます。
環境
- Ubuntu 24.04 (22.04でも動作確認)
- Apache 2.4
※ パッケージ管理にaptitudeを用いています。必要に応じてaptに読み替えてください。
さっくりとした手順
- mod_securityのインストールを行います。
- mod_securityの設定を行います。
- Apacheのバーチャルサイトにmod_securityを組み込みます。
- 設定を反映して動作を確認します。
mod_securityのインストールを行います。
- パッケージ全体のアップデート
sudo aptitude update- mod_securityインストール
sudo aptitude install libapache2-mod-security2- インストール確認
sudo apache2ctl -M |grep securitysecurity2_module (shared)と表示されていることを確認します。
ModSecurityの設定
- 設定ファイル書き換え
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf推奨ファイルをそのまま設定ファイルとして書き換えます。
OWASP Core Rule Set (CRS)のインストールと設定
- ディレクトリ移動
cd /usr/share/modsecurity-crs && pwd- ルールセットのダウンロード
sudo git clone https://github.com/coreruleset/coreruleset.git- ルールセットの設定書き換え
sudo mv /usr/share/modsecurity-crs/coreruleset/crs-setup.conf.example /usr/share/modsecurity-crs/coreruleset/crs-setup.confmod_securityモジュールにCRSを読み込む設定を追記
- ディレクトリ移動
cd /etc/apache2/mods-available/ && pwd- ファイルのバックアップ
sudo cp -pi security2.conf /path/to/backup/directory/security2.conf.$(date +%Y%m%d)任意のバックアップディレクトリを指定します。
- バックアップ確認
diff -u /path/to/backup/directory/security2.conf.$(date +%Y%m%d) security2.confエラーがなければバックアップは成功です。
- ファイル追記
/etc/apache2/mods-available/security2.confを、以下の差分になるように教義・信仰に沿ったエディタで編集します。（要root権限）
<IfModule security2_module>
- # Default Debian dir for modsecurity's persistent data
- SecDataDir /var/cache/modsecurity
+ # Default Debian dir for modsecurity's persistent data
+ SecDataDir /var/cache/modsecurity
- # Include all the *.conf files in /etc/modsecurity.
- # Keeping your local configuration in that directory
- # will allow for an easy upgrade of THIS file and
- # make your life easier
- IncludeOptional /etc/modsecurity/*.conf
+ # Include all the *.conf files in /etc/modsecurity.
+ # Keeping your local configuration in that directory
+ # will allow for an easy upgrade of THIS file and
+ # make your life easier
+ IncludeOptional /etc/modsecurity/*.conf
- # Include OWASP ModSecurity CRS rules if installed
- IncludeOptional /usr/share/modsecurity-crs/*.load
+ # --- OWASP Core Rule Set (CRS) の読み込み ---
+
+ # 1. CRSのセットアップファイルを読み込む（必須）
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/crs-setup.conf
+
+ # 2. CRSのルールファイルを読み込む
+ # パフォーマンス問題を起こすSQLデータ漏洩検知ルールを除外
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/REQUEST-*.conf
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-950-DATA-LEAKAGES.conf
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-980-CORRELATION.conf
+ IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf→ 修正後のsecurity2.conf全文
<IfModule security2_module>
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
# Include all the *.conf files in /etc/modsecurity.
# Keeping your local configuration in that directory
# will allow for an easy upgrade of THIS file and
# make your life easier
IncludeOptional /etc/modsecurity/*.conf
# --- OWASP Core Rule Set (CRS) の読み込み ---
# 1. CRSのセットアップファイルを読み込む（必須）
IncludeOptional /usr/share/modsecurity-crs/coreruleset/crs-setup.conf
# 2. CRSのルールファイルを読み込む
# パフォーマンス問題を起こすSQLデータ漏洩検知ルールを除外
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/REQUEST-*.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-950-DATA-LEAKAGES.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-980-CORRELATION.conf
IncludeOptional /usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
</IfModule>※ なぜここまで除外するか？
この、RESPONSE-9x系のルールは、ページの内容に機密情報（クレジットカードのデータなど）が入っていないかを精査します。
これは重要なものですが、昨今のAIボットによる過剰なクロールが挟むと、サーバそのものへの負荷を強め、更にログの圧迫（実際にサーバ容量120GB全てを食い尽くしました）とサーバダウンにつながります。
こちらは個人サイト、単一VPSの運用を旨としているため、ここに関するデータはオミットです。 その分、他の設定の補強でセキュリティ強度を担保します。
例外ルールを追記
/usr/share/modsecurity-crs/coreruleset/rules && pwd配下に
REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confファイルを作成します。
#
# === CRS Exclusions - Before Rules Execution (Organized) ===
#
# ===================================================================
# 1. 共通ルール・汎用ルール (General/Common Rules)
# ===================================================================
# 1-1. 遅い通信（Slowloris）対策
# 矛盾するConnectionヘッダーを持つリクエストを遮断
SecRule REQUEST_HEADERS:Connection "@rx (?i)(?:keep-alive(?:,\sclose|,\skeep-alive)|close(?:,\skeep-alive|,\sclose))" \
"id:10001,phase:1,t:none,block,msg:'[CUSTOM RULE] Contradictory Connection header, possible Slowloris probe.',tag:'application-attack',tag:'PROTOCOL_VIOLATION/INVALID_HREQ',setvar:'tx.inbound_anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
# 1-2. IPアドレス直打ちアクセス対策
SecRule REQUEST_HEADERS:Host "@rx ^[\d.]+(:\d+)?$" \
"id:10002,\
phase:1,\
deny,\
status:404,\
log,\
msg:'[CUSTOM RULE] Host header is a numeric IP address (incl port). Blocked immediately.',\
tag:'application-attack',\
tag:'PROTOCOL_VIOLATION/INVALID_HREQ'"
# 1-3. Hostヘッダーが存在しない場合は即ブロック
SecRule &REQUEST_HEADERS:Host "@eq 0" \
"id:10003,\
phase:1,\
deny,\
status:404,\
log,\
msg:'[CUSTOM RULE] Missing Host Header. Blocked immediately.'"なぜこの設定が必要なのか？
「雑なスキャナー/クローラーをまとめてブロックする」にあります。
- 攻撃者は、
Connection: keep-alive, closeという通常ではありえないヘッダーでサーバを枯渇させることが非常に多いです。(Slowloris などのDoS攻撃ツール) - 攻撃者のほぼ大半は、ドメイン名ではなくIPアドレスを指定。そして、Hostヘッダーを指定せずに無差別にスキャンを行います。
「ブラウザを用いて実際にアクセスする」方が
- 矛盾したヘッダー
- IPアドレス直打ち
- Hostヘッダー抜きのアクセス
はあり得ません。これら雑なスキャナー/クローラーにWAFの計算力を与える必要はありません。
- 設定追記の整合性を確認
sudo apache2ctl configtestSyntax OKを確認します。
- Apache再起動
sudo systemctl restart apache2.service- Apache再起動確認
systemctl status apache2.serviceactive (running) を確認します。
Apacheのバーチャルサイト編集
稼働済みのApacheバーチャルサイトの設定ファイルをいじります。バックアップ確認は入念に行ってください。
- ディレクトリ移動
cd /etc/apache2/sites-available && pwd- バーチャルサイトの設定ファイルバックアップ
sudo cp -pi your_site.conf /path/to/backup/directory/your_site.conf.$(date +%Y%m%d).confファイルやバックアップディレクトリは自分の環境を指定します。
- バックアップ確認
diff -u /path/to/backup/directory/your_site.conf.$(date +%Y%m%d) your_site.confエラーがなければバックアップは成功です。
- ファイル追記
/etc/apache2/sites-available/your_site.confを、以下の差分になるように教義・信仰に沿ったエディタで編集します。（要root権限）
# Mod Security
## ModSecurity有効化
SecRuleEngine On
## ModSecurity検知モード
### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
#SecRuleEngine DetectionOnly
## ファイルのアップロードをできるようにします。
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## テスト用の検知パラメータを付け加えます。
SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"- ファイル差分
diff -u /path/to/backup/directory/your_site.conf.$(date +%Y%m%d) your_site.conf+# Mod Security
+
+## ModSecurity有効化
+SecRuleEngine On
+## ModSecurity検知モード
+### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
+#SecRuleEngine DetectionOnly
+
+## ファイルのアップロードをできるようにします。
+SecRequestBodyInMemoryLimit 524288000
+SecRequestBodyLimit 524288000
+
+## テスト用の検知パラメータを付け加えます。
+ SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
+- 設定追記の整合性を確認
sudo apache2ctl configtestSyntax OKを確認します。
- Apache再起動
sudo systemctl restart apache2.service- Apache再起動確認
systemctl status apache2.serviceactive (running) を確認します。
mod_security動作確認
- ブラウザで、上記の設定を行ったWebサイトにアクセスし、閲覧できることを確認します。
- アドレスバーの末尾に
?modsecparam=testを追加してアクセスします。
403 Forbidden
のように、アクセスできないことを確認します。
また、サーバでも
sudo cat /path/to/sites_log/directory/sites_error.log※ログの格納場所やログの名前は自分の環境に合わせます。
を開き、
ModSecurity: Access denied with code 403 (phase 2). String match "test" at ARGS:modsecparam. [file "/etc/apache2/sites-enabled/your_site.conf"] [line "53"] [id "4321"] [msg "ModSecurity test rule has triggered"] [hostname "host_address"] [uri "/"] [unique_id "xxxxxxx"]のように、エラーが発生していることを確認します。
備考
WordPress、Redmine等のWebアプリは自身の操作によって「不審なアクセス」として遮断することが極めてよくあります。(偽陽性)
そのため、テストを行った後は
## ModSecurity有効化
#SecRuleEngine On
## ModSecurity検知モード
### 検知モードで動かす場合はSecRuleEngine Onをコメントアウトしてこちらを有効化します
SecRuleEngine DetectionOnlyとして検知モードとして動かした方が良いでしょう。
