Ubuntu 22.04 の Apache で WAF を有効化する手順です。ここでは ModSecurity と OWASP Core Rule Set を使い、Apache の追加防御層として WAF を導入します。
WAF は攻撃を完全に防ぐ魔法ではありません。実際には、検知ログを確認し、誤検知を調整し、必要なルールだけを狭く除外しながら運用する仕組みです。特に WordPress や管理画面、REST API を扱うサイトでは、WAF の誤検知と例外調整まで含めて設計する必要があります。
ModSecurity Handbook, Second Edition
ModSecurity と Web Application Firewall の設定、ログ、ルール、チューニングを確認したい場合の参考書籍です。英語書籍であり、価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する Apache 記事
WAF は Apache の基本構築、TLS、PHP、HTTP/2 の上に追加する防御層です。まず基本設定が安定してから有効化します。
- Ubuntu 22.04 Apache 基本構築 – VirtualHost と DocumentRoot を整理する
- Ubuntu 22.04 Apache TLS – 内部 CA 証明書で HTTPS を有効化する
- Ubuntu 22.04 Apache PHP 有効化 – libapache2-mod-php の設定と確認
- Ubuntu 22.04 Apache HTTP/2 有効化 – TLS VirtualHost で h2 を使う
WAF の位置づけ
| 要素 | 役割 |
|---|---|
| Apache | HTTP / HTTPS リクエストを受ける Web サーバー |
| ModSecurity | Apache に組み込む WAF エンジン |
| OWASP CRS | 攻撃パターンを検知する汎用ルールセット |
| audit log | どのルールで何が検知されたかを確認するログ |
| 除外ルール | 誤検知や業務上必要な通信だけを狭く許可する調整 |
WAF は脆弱なアプリケーションを安全に変えるものではありません。アプリケーションの修正、認証、アクセス制御、TLS、ログ監視の上に追加する防御層として考えます。
パッケージをインストールする
sudo apt update
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y libapache2-mod-security2 modsecurity-crsModSecurity を有効化する
Ubuntu では推奨設定ファイルをコピーし、SecRuleEngine を有効化します。最初は検知だけの DetectionOnly で様子を見る運用もありますが、ここでは防御動作を有効にする例にします。
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
sudo sed -i 's/^SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/modsecurity/modsecurity.conf
grep '^SecRuleEngine' /etc/modsecurity/modsecurity.confCRS を読み込む
OWASP CRS の設定を Apache から読み込ませます。Ubuntu のパッケージ構成に合わせて、ModSecurity の設定で CRS を include します。
sudo tee /etc/apache2/mods-available/security2.conf <<'EOF'
<IfModule security2_module>
SecDataDir /var/cache/modsecurity
IncludeOptional /etc/modsecurity/*.conf
IncludeOptional /usr/share/modsecurity-crs/*.load
</IfModule>
EOF
sudo a2enmod security2
sudo apache2ctl configtest
sudo systemctl reload apache2サービス状態を確認する
apache2ctl -M | grep security
sudo systemctl status apache2 --no-pager
sudo journalctl -u apache2 -n 50 --no-pagerApache が起動しない場合は、CRS の include パス、設定ファイルの構文、ModSecurity の設定を確認します。WAF は Apache のリクエスト処理に入るため、設定ミスがあると Web サーバー全体に影響します。
audit log を確認する
WAF 運用で重要なのは、ブロックされたこと自体ではなく、どのルールで何が検知されたかを確認することです。ModSecurity の audit log を見ます。
sudo tail -n 200 /var/log/apache2/modsec_audit.log
sudo grep -E 'Message:|id "[0-9]+"|uri' /var/log/apache2/modsec_audit.log | tail -n 80誤検知の調整では、rule id、対象 URI、検知された変数、リクエストの種類を確認します。単に 403 になったという情報だけでは、適切な除外はできません。
テストリクエストを送る
WAF が反応するかを確認するため、検証用のリクエストを送ります。公開環境では影響範囲に注意し、検証用のホストやパスで実施します。
curl -i 'http://server.example.local/?q=<script>alert(1)</script>'
sudo grep -E 'Message:|id "[0-9]+"' /var/log/apache2/modsec_audit.log | tail -n 40除外ルールの考え方
WAF の誤検知が出た場合、最初にやるべきことは WAF 全体を無効化することではありません。対象 URI、対象ルール、対象パラメータを絞り、必要最小限の除外にします。
| 除外の粒度 | 評価 |
|---|---|
| WAF 全体を無効化 | 切り分けには使えても恒久運用には向かない |
| 特定 URI だけ除外 | 管理 API や特定エンドポイントの誤検知に使いやすい |
| 特定 rule id だけ除外 | 影響を比較的狭くできる |
| 特定パラメータだけ除外 | 最も狭く調整しやすいが確認に手間がかかる |
URI 単位でルールを除外する
例として、特定の URI に対して特定 rule id を除外します。実際の rule id は audit log で確認した値を使います。
sudo tee /etc/modsecurity/local-exceptions.conf <<'EOF'
<LocationMatch "^/wp-json/">
SecRuleRemoveById 949110
</LocationMatch>
EOF
sudo apache2ctl configtest
sudo systemctl reload apache2この例は考え方を示すものです。実運用では、/wp-json/ 全体を広く許可するより、実際に必要な endpoint や rule id に絞る方が安全です。
ルール ID を確認してから調整する
除外ルールを書く前に、audit log から rule id を確認します。
sudo awk '/Message:|id "[0-9]+"|uri/ {print}' /var/log/apache2/modsec_audit.log | tail -n 120WAF の除外は、ログを見て、仮説を立て、狭く調整し、再度同じリクエストで確認する作業です。ログ確認なしに大きく許可すると、WAF を入れた意味が薄くなります。
WordPress で注意すること
WordPress では、管理画面、REST API、記事投稿、ブロックエディター、プラグイン更新などで長い HTML や JSON を送るため、WAF の汎用ルールに引っかかることがあります。
- 投稿編集や REST API の 403 は audit log を見て rule id を確認する
- 記事本文にコードや HTML が多い場合、誤検知が起きやすい
- 除外は管理画面全体ではなく、必要な URI と rule id に絞る
- WAF の検知と WordPress の権限エラーを混同しない
- 許可後は同じリクエストを再実行して確認する
運用上の注意
- WAF はアプリケーション修正の代替ではない
- 最初から強くブロックすると誤検知で運用が止まりやすい
- audit log を定期的に確認する
- 除外ルールは理由と対象をコメントで残す
- 本番反映前に検証環境でルール変更を確認する
まとめ
Ubuntu 22.04 の Apache で WAF を有効化するには、ModSecurity と OWASP CRS を導入し、Apache に読み込ませます。ただし、WAF は入れた瞬間に完成するものではなく、audit log を見ながら誤検知を調整していく運用が前提です。
特に WordPress や REST API を扱う環境では、WAF による 403 は珍しくありません。重要なのは、WAF を無効化することではなく、ログから rule id と対象 URI を確認し、必要最小限の除外を積み重ねることです。
Related posts:
CentOS 8 Apache ModSecurity WAF – 導入と誤検知調整の基本
Ubuntu 26.04 Apache WAF の設定
WordPress 更新後に ModSecurity が偽陽性判定する原因と調整方針
Ubuntu 22.04 Apache 基本構築 – VirtualHost と DocumentRoot を整理する
Ubuntu 22.04 Apache TLS – 内部 CA 証明書で HTTPS を有効化する
Ubuntu 22.04 Apache PHP 有効化 – libapache2-mod-php の設定と確認
Ubuntu 22.04 Apache Web サーバー構築 Userdir 有効化
Ubuntu 22.04 Apache HTTP/2 有効化 – TLS VirtualHost で h2 を使う
Ubuntu 26.04 Apache の基本設定
Ubuntu 26.04 Apache TLS の設定
Ubuntu 26.04 Apache リバースプロキシの設定
Ubuntu 22.04 CentOS と Ubuntu の違い