概要
こちらの方法で導入したMod-Security（WAF）。
この防御ルールであるOWASP Core Rule Setの更新を行います。
環境
- Ubuntu 24.04
- Apache 2.4
- バーチャルサイトで個別設定
- aptでインストールしているため
- 設定ファイルは
/etc/apache2/sites-available配下の.confファイル
- サービス実行ユーザはwww-data
- Mod Security ver.2系
注意点
アップデートにより
- 追加されたルール
- 削除されたルール
- 変更された挙動
などがあるため、今までと同じ作業をしていたのにWAFがブロックした（あるいは今までブロックされていたアクセスがスルーした）などは可能性としてあります。
なので、
- ModSecurityを検知モードにして作業を実施する
- しばらく様子を見て有効化に戻す
という作業を取ります。そのため、WAFの防御が一度無効化される時間が発生します。
環境や予算が許すなら、インターネットに公開された別環境で試してからの方が良いでしょう。
→ テストが済んでいる状態であれば、本番環境で「ModSecurityをオフにする」の作業は不要になります。
さっくりとした手順
- 【事前準備】ModSecurityを検知モードにします。
- 【事前準備】ルールセットディレクトリのバックアップを行います。
- gitで最新リリースを確認します。
- OWASP Core Rule Setのアップデートを行います。
- Webサービスの再起動でアップデートを反映させます。
- 【事後作業】ModSecurityを有効化します。
【事前準備】ModSecurityを検知モードにします。
cd /etc/apache2/sites-available && pwd
sudo cp -pi hoge.conf /path/to/backup/directory/hoge.conf.yyyymmdd
- 設定ファイル(.conf)は自分の環境に合わせます。
- 任意のバックアップディレクトリを指定します。
diff -u /path/to/backup/directory/hoge.conf.yyyymmdd hoge.conf
差分が無いことを確認します。
通常、筆者は$(date +%Y%m%d)変数を用いてバックアップを行いますが、「検知モードでの試験」は日をまたぐこともあるため、この形式にしています。
hoge.confファイルを管理者権限で修正。
SecRuleEngine On
から
SecRuleEngine DetectionOnly
に変更し、保存します。
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf
以下の差分を確認します。
- SecRuleEngine On
+ SecRuleEngine DetectionOnly
sudo apache2ctl configtest
Syntax OKを確認します。
systemctl status apache2.service
active(running)を確認します。
sudo systemctl restart apache2.service
※設定ファイルの修正のみのためreloadで十分ですが、念を入れてrestartにしています。（以下同じ）
systemctl status apache2.service
active(running)を確認します。
【事前準備】ルールセットディレクトリのバックアップを行います。
cd /usr/share/modsecurity-crs && pwd
これは、上記のリンク先で示した通り、ルールセットを/usr/share/modsecurity-crs/corerulesetに配置していた場合のディレクトリです。
必要に応じて自分の環境に合わせます。
sudo cp -pir coreruleset /path/to/backup/directory/coreruleset.$(date +%Y%m%d)
任意のバックアップディレクトリを指定します。
ls -l /path/to/backup/directory/coreruleset.$(date +%Y%m%d)
ディレクトリ一式があることを確認します。
OWASP Core Rule Setのアップデート
cd /usr/share/modsecurity-crs/coreruleset && pwd
sudo git fetch origin
sudo git status
筆者環境で、以下のように表示されました。
ブランチ main
このブランチは 'origin/main' に比べて172コミット遅れています。fast-forwardすることができます。
(use "git pull" to update your local branch)
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: crs-setup.conf.example
no changes added to commit (use "git add" and/or "git commit -a")
コミット内容が大幅に変わっているので、上述した「検知モードで様子見にする」が活きてきます。
sudo git pull
これで、OWASP Core Rule Setが最新版に変更されました。
Webサービスの再起動でアップデートを反映させます。
systemctl status apache2.service
active(running)を確認します。
sudo systemctl restart apache2.service
systemctl status apache2.service
active(running)を確認します。
その後、既存のWebシステムに問題が無いかを確認します。
tail -f /var/log/hoge/hoge_error.log
等として、通常の作業を行い
- 既存のサービスに異常は無いか？
- 新たな偽陽性は発生していないか？
等を確認し、それに応じて新たな偽陽性の除外などを行っていきます。
【事後作業】ModSecurityを有効化します。
アップデートの影響で既存サービスに問題が無いことが判明したら、再びModSecurityを有効化します。この例では、バックアップから.confファイルを切り戻します。
- バーチャルサイト(.conf)ファイルのディレクトリに移動
cd /etc/apache2/sites-available && pwd
sudo cp -pi /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.conf
systemctl status apache2.service
active(running)を確認します。
sudo systemctl restart apache2.service
systemctl status apache2.service
active(running)を確認します。
その後、既存のWebシステムに問題が無いかを確認します。
有効化前に既存.confファイルを修正した場合
新たに偽陽性を追加した、既存のファイルを削除した、またはそれに伴う設定変更を行ったことにより、バックアップ前と.confファイルが異なるケースはあります。
その場合は、.confファイルの
SecRuleEngine DetectionOnly
を
SecRuleEngine On
と修正した後で以下の作業を行います。
sudo apache2ctl configtest
Syntax OKを確認します。
systemctl status apache2.service
active(running)を確認します。
sudo systemctl restart apache2.service
systemctl status apache2.service
active(running)を確認します。
