これは、筆者が自分のサーバに組み込んでいるWebセキュリティシステム(と言ってもスクリプトと設定の組み合わせ) 『ONE OUTS』について述べたものです。
を目標に構築しました。
メンテナンスが高いとは言え、少々複雑な流れを含むため、いくつかに分けて解説します。
甲斐谷忍先生による同名の野球漫画『ONE OUTS』から来ています。
などをイメージしながら構築しました。
以下の環境で動いています。
次のページから、実際のファイル群を示します。
こちらの記事の改訂・再編集版です。
WAFとはWeb Application Firewallの略で、Webアプリケーション層の脆弱性を狙った攻撃を防ぐためのセキュリティシステムです。
この機能により、Webサーバーやアプリケーション本体に脆弱性が見つかったとしても、WAFが前段の盾としてこれをカバーできます。
ModSecurityは、IIS/Apache/Nginxといった主要なWebサーバープログラムにモジュールとして組み込みが可能なオープンソースのWAFです。
本稿で導入するModSecurityは、Ubuntu 24.04系のパッケージ管理で提供されるEOL (End-of-Life) となっているv2ですが、機能性は単一VPSの防御としては十分です。
v3への移行は、セキュリティ強度とメンテナンス性を考慮し、パッケージ化ないしはOSアップデートなどのタイミングでまた後日検討していきます。
※ パッケージ管理にaptitudeを用いています。必要に応じてaptに読み替えてください。
sudo aptitude updatesudo aptitude install libapache2-mod-security2sudo apache2ctl -M |grep securitysecurity2_module (shared)と表示されていることを確認します。
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf推奨ファイルをそのまま設定ファイルとして書き換えます。
cd /usr/share/modsecurity-crs && pwdsudo git clone https://github.com/coreruleset/coreruleset.gitsudo mv /usr/share/modsecurity-crs/coreruleset/crs-setup.conf.example /usr/share/modsecurity-crs/coreruleset/crs-setup.confcd /etc/apache2/mods-available/ && pwdsudo 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の運用を旨としているため、ここに関するデータはオミットです。 その分、他の設定の補強でセキュリティ強度を担保します。
sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive (running) を確認します。
稼働済みのApacheバーチャルサイトの設定ファイルをいじります。バックアップ確認は入念に行ってください。
cd /etc/apache2/sites-available && pwdsudo 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を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive (running) を確認します。
?modsecparam=testを追加してアクセスします。
のように、アクセスできないことを確認します。
また、サーバでも
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として検知モードとして動かした方が良いでしょう。
Redmineでファイルをアップロードしようとした際、ModSecurity (WAF) によってブロックされ、エラーになる事象が発生しました。
その原因と事象解決のメモです。
環境をWebArenaからXServerに移行した直後。
Redmineのチケットでファイルをアップロードしようとすると、ファイルアップロードのプログレスバーが完了せず、アップロードできません。
こういうときの答えはたいがい、エラーログに書かれているのでそれを確認します。
見つけたログ（IPアドレスやホスト名は改変済み）:
[Wed Aug 13 12:47:21.713637 2025] [security2:error] [pid 11190] [client AAA.BBB.CCC.DDD:40404] ModSecurity: Request body no files data length is larger than the configured limit (131072). [hostname "hoge.example.com"] [uri "/uploads.js"] [unique_id "aJwKye92u8EKc4H_FxCb5QAAABQ"], referer: https://hoge.example.com/issues/123Request body no files data length is larger than the configured limit (131072)
これは、「ファイル以外のリクエストデータ（no files data）のサイズが、設定された上限値（131072バイト = 128KB）を超えています」という意味です。
Redmineは、ファイルをアップロードする際、ファイルそのものとは別に、チケットの題名や説明といったテキスト情報も同時にサーバーへ送信します。このテキスト情報の合計サイズが、ModSecurityのデフォルトの上限値である128KBを超えてしまったため、攻撃と誤認され、ブロックされる。
というのがAI（Gemini）の回答。
既にApacheのバーチャルサイトの.confファイルには
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000と記述していますが、サーバの入れ替えと同時にModSecurityのCRSをアップデートしたことで設定が足りなかったようです。
ここまで分かれば、解決まであと少し。
ModSecurityのメイン設定ファイルで、SecRequestBodyNoFilesLimitの上限値を設定で上書きしていきます。
sudo cp -pi /etc/apache2/site-available/redmine.conf /path/to/backup/directory/redmine.conf.$(date +%Y%m%d).confの名前やバックアップディレクトリは自分の環境に合わせます。
diff -u /path/to/backup/directory/redmine.conf.$(date +%Y%m%d) /etc/apache2/site-available/redmine.conf差分がなければ（エラーがなければ）バックアップ成功。
上述した設定ファイルを以下のように修正。
修正前（例）:
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000修正後（例）:
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
SecRequestBodyNoFilesLimit 524288000両方の値を同じにしておくと、管理が分かりやすくなります。
なお、500MBとしているのは一時的に大きなファイルを置くこともあるからです。上限値は自分の運用方針やストレージ量に合わせましょう。
diff -u /path/to/backup/directory/redmine.conf.$(date +%Y%m%d) /etc/apache2/site-available/redmine.confSecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
+SecRequestBodyNoFilesLimit 524288000と、追記した行が出てくることを確認します。
sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceRunning(active)を確認します。
Redmineのチケット作成/編集画面でファイルが正常にアップロードできるようになれば対処完了です。
新環境の構築時、最新のCRSを導入したため、旧環境をそのまま引き継いだというのが直接的な原因でした。
こういう罠があちこちに潜んでいるので、何かあったらログを見て事象を確かめるのが事象解消の近道です。
2025/08/12 朝、管理しているWebサーバーにSSHで接続できなくなり、Webサイトも全て閲覧できなくなる障害が発生しました。本記事は、その原因究明から、応急処置、そして恒久対策までの一連の流れを記録したものです。
redis-serverの停止処理（DBの保存）でタイムアウトし、正常にシャットダウンできない。障害の切り分け中、Wasabiクラウドストレージをマウントしようとした際に、以下のエラーが発生しました。
sudo mount -amount.s3fs: unable to access MOUNTPOINT /mnt/wasabi: No space left on device「No space left on device（デバイスに空き領域がありません）」というこのエラーメッセージ。150GBもディスク容量があるのになぜ……？ 思いつつ調査を行います。
上記のエラーを受け、ディスクの空き容量を確認しました。
df -h実行結果:
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 145G 145G 0 100% /この結果から、**ルートディレクトリ（/）のディスク使用率が100%**になり、空き容量がゼロになっていることが、数値的にも裏付けられました。
次に、どのディレクトリが容量を使い果たしているのかを調査しました。
sudo du -h -d 1 /実行結果（抜粋）:
125G /var/varディレクトリが125GBを占めていることが分かりました。さらに詳細に調査を進めます。
sudo du -h -d 1 /var/log実行結果（抜粋）:
122G /var/log/apache2/var/log/apache2が122GBという、異常なサイズになっていることが特定できました。
その後、/var/log/apache2ディレクトリの中身を確認しました。
ls -lh /var/log/apache2実行結果（抜粋）:
-rw-r----- 1 root adm 61G 8月 12 08:09 modsec_audit.log
-rw-r----- 1 root adm 59G 8月 11 00:15 modsec_audit.log.1**ModSecurityの監査ログ（modsec_audit.log）**が、わずか2日間で120GB以上にまで肥大化していたことが、直接の原因であると確定しました。
ここまで分かれば対処はもうすぐです。
まず、サーバーを正常に動作させるため、巨大化した監査ログを削除し、空き容量を確保します。
sudo rm /var/log/apache2/modsec_audit.log*sudo systemctl restart apache2.servicemodsec_audit.logは、攻撃の詳細な分析やデバッグには役立ちますが、今回のようにログがディスクを圧迫し、サーバーダウンを引き起こしますため、この設定をオフにします。
sudo nano /etc/modsecurity/modsecurity.confSecAuditEngineの値をOffに変更します。 修正前: SecAuditEngine RelevantOnly 修正後: SecAuditEngine Offsudo systemctl reload apache2.serviceその後、念のためサーバそのものを
```bash
sudo reboot
```で、状況が元に戻っていることを確認しました。
今回の障害は、ModSecurityの監査ログが有効になったまま放置され、そのログがログローテーションの対象になっていなかったために、ディスク容量を100%使い果たしたことが原因でした。
前述したとおり、よりよいスペックのサーバに引っ越した後の出来事だけに、かなりの冷や汗ものでした。
先日の記事でgitを用いたmod-securrity core rule setのアップデートを行いました。
このアップデートにより新たに検知されたルールの対処を行います。
OWASP Core Rule Set (CRS) を導入したModSecurityをブロックモード（SecRuleEngine On）に切り替え後、
Apacheのエラーログに、これまで見られなかった Execution error - PCRE limits exceeded (-47) というエラーが大量に記録されていることを発見しました。
[Sat Jun 14 11:09:05.195039 2025] [security2:error] [pid 28306:tid 28306] [client AAA.BBB.CCC.DDD:59314] [client AAA.BBB.CCC.DDD] ModSecurity: Rule 73f4b9603e90 [id "951190"][file "/usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"][line "246"] - Execution error - PCRE limits exceeded (-47): (null). [hostname "hoge.example.com"] [uri "/path/to/page.html"] [unique_id "aE_NnHj4jZdbb2PH1-4O0QAAABc"]
[Sat Jun 14 11:09:05.195564 2025] [security2:error] [pid 28306:tid 28306] [client AAA.BBB.CCC.DDD:59314] [client AAA.BBB.CCC.DDD] ModSecurity: Rule 73f4b95f9e98 [id "951210"][file "/usr/share/modsecurity-crs/coreruleset/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"][line "288"] - Execution error - PCRE limits exceeded (-47): (null). [hostname "hoge.example.com"] [uri "/path/to/page.html"] [unique_id "aE_NnHj4jZdbb2PH1-4O0QAAABc"]このログから、SQLインジェクション系の情報漏洩を検知するRESPONSE-951-DATA-LEAKAGES-SQL.confの内容に沿ったものと特定。
cat /var/log/apache2/hoge/error.log |grep 951190 |wc -lとしたところ、数時間で2万件近いログを検知。
複雑な正規表現を、非常に大きなデータ（Webページなど）に対して実行すると、サーバーのCPUやメモリを大量に消費し、サービス拒否（DoS）攻撃に繋がる危険性があります。これを防ぐため、ModSecurityには処理の複雑さや再帰の深さに上限（リミット）が設けられています。
今回のエラーは、サーバーが返信するHTMLページ（レスポンスボディ）の内容を、情報漏洩がないか確認するルールがスキャンしようとした際に、そのWebページの内容が非常に大きい、または複雑であったため、PCREの処理上限値を超えてしまったことが原因です。(筆者のサイトの長文が災いしています)
この、処理上限値を超えてしまったことでエラーが発生したのですからmodsecurity.confでSecPcreMatchLimitの値を大きくすると言うのが考えられる対処ではありますが、
運用しているサイトのvpsのリソースを鑑みて、より簡便な「原因となっている特定のルールのみの無効化」を行いました。
sudo cp -ci /etc/apache2/sites-available/hoge.conf /path/to/backup/directory/hoge.conf.$(date +%Y%m%d)設定ファイルやバックアップディレクトリは自分の環境に合わせます。
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) /etc/apache2/sites-available/hoge.confエラー無く、差分も表示されていなければバックアップは成功です。
/etc/apache2/sites-available/hoge.confを以下のように修正していきます。(要root権限)
# PCREリミット超過エラーを起こす、レスポンスボディスキャン系のルール群を無効化
SecRuleRemoveById 951190
SecRuleRemoveById 951210
SecRuleRemoveById 951220
SecRuleRemoveById 951250diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) /etc/apache2/sites-available/hoge.conf+ # PCREリミット超過エラーを起こす、レスポンスボディスキャン系のルール群を無効化
+ SecRuleRemoveById 951190
+ SecRuleRemoveById 951210
+ SecRuleRemoveById 951220
+ SecRuleRemoveById 951250sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
対処後、ターミナルで
tail -f /var/log/apache2/hoge/error.log |grep "PCRE limits"を実行し、しばらく観察します。
このエラーが表示されないことを確認し、処置が完了です。
こちらの方法で導入したMod-Security（WAF）。
この防御ルールであるOWASP Core Rule Setの更新を行います。
/etc/apache2/sites-available配下の.confファイルアップデートにより
などがあるため、今までと同じ作業をしていたのにWAFがブロックした（あるいは今までブロックされていたアクセスがスルーした）などは可能性としてあります。
なので、
という作業を取ります。そのため、WAFの防御が一度無効化される時間が発生します。
環境や予算が許すなら、インターネットに公開された別環境で試してからの方が良いでしょう。
→ テストが済んでいる状態であれば、本番環境で「ModSecurityをオフにする」の作業は不要になります。
cd /etc/apache2/sites-available && pwdsudo cp -pi hoge.conf /path/to/backup/directory/hoge.conf.yyyymmdddiff -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 DetectionOnlysudo apache2ctl configtestSyntax OKを確認します。
systemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.service※設定ファイルの修正のみのためreloadで十分ですが、念を入れてrestartにしています。（以下同じ）
systemctl status apache2.serviceactive(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)ディレクトリ一式があることを確認します。
cd /usr/share/modsecurity-crs/coreruleset && pwdsudo git fetch originsudo 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が最新版に変更されました。
systemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
その後、既存のWebシステムに問題が無いかを確認します。
tail -f /var/log/hoge/hoge_error.log等として、通常の作業を行い
等を確認し、それに応じて新たな偽陽性の除外などを行っていきます。
アップデートの影響で既存サービスに問題が無いことが判明したら、再びModSecurityを有効化します。この例では、バックアップから.confファイルを切り戻します。
cd /etc/apache2/sites-available && pwdsudo cp -pi /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) hoge.confsystemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
その後、既存のWebシステムに問題が無いかを確認します。
新たに偽陽性を追加した、既存のファイルを削除した、またはそれに伴う設定変更を行ったことにより、バックアップ前と.confファイルが異なるケースはあります。
その場合は、.confファイルの
SecRuleEngine DetectionOnlyを
SecRuleEngine Onと修正した後で以下の作業を行います。
sudo apache2ctl configtestSyntax OKを確認します。
systemctl status apache2.serviceactive(running)を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
Redmineでクリップボードの画像を貼り付けようとした際、画像のアップロードができませんでした。
そこで、エラーログを確認したところ、以下のメッセージが表示されました。
ModSecurity: Request body no files data length is larger than the configured limit (131072). [hostname "redmine-url"] [uri "/uploads.js"] [unique_id "Zv0wom0FwSak1tXDUgFRLAAAAAw"], referer: https://redmine-url/issues/3SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000と、50MBはアップロードできるようになっています。
管理＞ 設定 ＞ ファイルの「添付ファイルサイズの上限でも`51200KB`を確認。
`cat /etc/modsecurity/modsecurity.conf |grep Limit` の結果、以下を確認しました。
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimitAction Reject
SecRequestBodyJsonDepthLimit 512
SecPcreMatchLimit 100000
SecPcreMatchLimitRecursion 100000
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial`/etc/modsecurity/modsecurity.conf`の設定がバーチャルサイトの設定にオーバーライドしたため、こちらの設定が上書きされた模様です。
これを変更していきます。
sudo cp -pi /etc/modsecurity/modsecurity.conf /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d)任意のバックアップディレクトリを指定します。
diff -u /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d) /etc/modsecurity/modsecurity.confバックアップできていること（差分がないこと）を確認します。
sudo sed -i 's/SecRequestBodyNoFilesLimit 131072/SecRequestBodyNoFilesLimit 52428800/; s/SecRequestBodyInMemoryLimit 131072/SecRequestBodyInMemoryLimit 52428800/; s/SecRequestBodyLimit 13107200/SecRequestBodyLimit 52428800/' /etc/modsecurity/modsecurity.confdiff -u /path/to/backup/directory/modsecurity.conf.$(date +%Y%m%d) /etc/modsecurity/modsecurity.conf以下の差分を確認します。
-SecRequestBodyLimit 13107200
-SecRequestBodyNoFilesLimit 131072
+SecRequestBodyLimit 52428800
+SecRequestBodyNoFilesLimit 52428800
# Store up to 128 KB of request body data in memory. When the multipart
# parser reaches this limit, it will start using your hard disk for
# storage. That is slow, but unavoidable.
#
-SecRequestBodyInMemoryLimit 131072
+SecRequestBodyInMemoryLimit 52428800sudo systemctl restart apache2.service書き換え後、無事にファイルのアップロードができることを確認しました。
個別に走らせていたスクリプトを1つにまとめました。
#!/bin/bash
# このスクリプトは、Tor出口ノードリストをダウンロードし、特定のログファイルからIPアドレスを抽出して処理します。
# 使い方: このスクリプトを実行することで、最新のTor出口ノードリストを取得し、ログファイルから抽出したIPアドレスと照合します。
# 結果は指定されたディレクトリに保存され、Apacheが再起動されます。
# cronでの指定例: 毎日午前2時に実行する場合 -> 0 2 * * * /path/to/this_script.sh
# === 変数の定義 ===
# 出口ノードリストのURL
TOR_EXIT_LIST_URL="https://check.torproject.org/exit-addresses"
# ダウンロード先ファイル名
OUTPUT_FILE="/hoge/script/log/node_list/exit_nodes.$(date +%Y%m%d).txt"
# 各サイトのログディレクトリ
log_dirs=("/var/log/bookstack") # 各サイトのログディレクトリを指定
# エラーログファイル名
log_file="bs_error.log"
# Tor出口ノードリストのディレクトリ
tor_list_dir="/hoge/script/log/sorted_list" # tor_list.txtのディレクトリを指定
# Tor出口ノードリストのファイル名
tor_list_file="sorted_ip_addresses$(date +%Y%m%d).txt"
# 除外するIPアドレスをファイルで指定
exclude_ips_file="/hoge/script/log/exclude_ips.txt"
# 共通の出力ログディレクトリ
output_log_dir="/hoge/script/log"
# === Tor出口ノードリストのダウンロードと処理 ===
# curlを使用してリストをダウンロード
curl -o "$OUTPUT_FILE" "$TOR_EXIT_LIST_URL" >/dev/null 2>&1
# ダウンロードが成功したかどうかを確認
if [ $? -eq 0 ]; then
echo "Tor出口ノードリストをダウンロードしました。ファイル: $OUTPUT_FILE"
else
echo "ダウンロード中にエラーが発生しました。"
exit 1
fi
# IPアドレスのみを抽出し、ソートして出力
awk '/^ExitAddress/ {print $2}' "$OUTPUT_FILE" | sort -u | tee "$tor_list_dir/$tor_list_file" >/dev/null 2>&1
# === 各サイトのエラーログからIPアドレスを抽出して処理 ===
for log_dir in "${log_dirs[@]}"; do
cd "$log_dir"
awk '/ModSecurity/ && match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "$log_file" | sort -u > "$output_log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"
done
# 過去のIPアドレスを読み込んで重複を排除し、ファイルに保存
cat "$output_log_dir/suspicious_ip/suspicious_ip."2* | sort -u > "$output_log_dir/suspicious_ip_all.txt"
# 新たにリストに書き起こすと同時に別のログファイルを読み込んで重複を排除し、negativelist.txtに追加
cat "$output_log_dir/suspicious_ip_all.txt" "$tor_list_dir/$tor_list_file" | sort -u > "$output_log_dir/negativelist.txt"
# 除外するIPアドレスをファイルから削除
while IFS= read -r exclude_ip; do
sed -i "/$exclude_ip/d" "$output_log_dir/negativelist.txt"
done < "$exclude_ips_file"
# Apacheを再起動
systemctl reload apache2.service
192.168.0.1
nnn.nnn.nnn.nnnなど、エラーログから除外したいIPアドレスのリストを作ります。
/etc/apache2/site-available 配下のバーチャルサイトの設定ファイルを以下のように追記します。
# Mod_Security設定
SecRuleEngine On
SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"
sudo ln -sf /hoge/script/log/negativelist.txt /etc/apache2/sites-enabled/negativelist.txtsudo crontab -e -u rootとして、
0 2 * * * /path/to/this_script.sh等と設定すれば、毎日2時に、その日に検知した怪しい動きをシャットダウンしてくれます。
Nextcloudにmod_securityを導入するに当たり、気をつけなければならないのがファイルの閲覧や登録、入力処理中にMod_securityが不審な処理として判断してしまうこと（偽陽性）です。
そこで、
を行います。
/var/log/nextcloud_error.logから、以下のようなログを見ました。
[Wed Sep 11 16:35:02.048442 2024] [security2:error] [pid 32762:tid 32762] [client aaa.bbb.ccc.ddd:56994] [client aaa.bbb.ccc.ddd] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "92"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [ver "OWASP_CRS/3.3.5"] [tag "event-correlation"] [hostname "nextcloud.hoge.com"] [uri "/ocs/v2.php/apps/user_status/api/v1/heartbeat"] [unique_id "ZuFIJU_udFaqxqrJvRLaPQAAAAA"]ここで見たいのは
です。
これらを確認するため、copilotの助けを借りてawkスクリプトを生成します。
awk '/ModSecurity/ {
ip = gensub(/.*\[client ([0-9.]+):.*/, "\\1", "g", $0);
rule_id = gensub(/.*\[id "([0-9]+)"\].*/, "\\1", "g", $0);
print rule_id, ip;
}' /var/log/nextcloud/nextcloud_error.log | sort | uniq -cこれを実行したところ、Mod_Securityがエラーとして検知したログの中から
36 911100 127.0.0.1
267 911100 aaa.bbb.ccc.ddd
65 920420 aaa.bbb.ccc.ddd
36 949110 127.0.0.1
267 949110 aaa.bbb.ccc.ddd
36 980130 127.0.0.1
267 980130 aaa.bbb.ccc.dddという結果を確認しました。127.0.0.1はローカルアドレス、aaa.bbb.ccc.dddも自分がアクセスしてきたIPアドレス。この間、自分がしていたのはNextcloudの設定変更やファイルの閲覧のみです。
Mod_securityが検知したルールIDを「偽陽性」と判断し、処置していきます。
Apacheのバーチャルサイトで設定しているという形です。
sudo cp -ci /etc/apache2/sites-available/nextcloud.conf /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d)設定ファイルやバックアップディレクトリは自分の環境に合わせます。
diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.confエラー無く、差分も表示されていなければバックアップは成功です。
/etc/apache2/sites-available/nextcloud.confを以下のように修正していきます。(要root権限)
# Mod_security
## 最初は検知モード
SecRuleEngine DetectionOnly
## 偽陽性と判断したID
SecRuleRemoveById 911100
SecRuleRemoveById 920420
SecRuleRemoveById 949110
SecRuleRemoveById 980130diff -u /path/to/backup/directory/nextcloud.conf.$(date +%Y%m%d) /etc/apache2/sites-available/nextcloud.confSecRuleRemoveById IDで、これにマッチするパターンは無視します。
## 最初は検知モード
SecRuleEngine DetectionOnly
+
+## 偽陽性と判断したID
+SecRuleRemoveById 911100
+SecRuleRemoveById 920420
+SecRuleRemoveById 949110
+SecRuleRemoveById 980130
+
</VirtualHost>sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive(running)を確認します。
ターミナルで
tail -f /var/log/nextcloud/nextcloud_error.logとしてエラーログを流します。（エラーログは自分の環境に合わせます）
ApacheのWAFモジュールであるmod_securityを導入します。
として機能しているにもかかわらず文書化していなかったので、Web Arenaでの検証を機に文章に残します。
※ パッケージ管理にaptitudeを用いています。必要に応じてaptに読み替えてください。
sudo aptitude updatesudo aptitude install libapache2-mod-security2sudo apache2ctl -M |grep securitysecurity2_module (shared)と表示されていることを確認します。
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf推奨ファイルをそのまま設定ファイルとして書き換えます。
cd /usr/share/modsecurity-crs && pwdsudo git clone https://github.com/coreruleset/coreruleset.gitsudo mv /usr/share/modsecurity-crs/coreruleset/crs-setup.conf.example /usr/share/modsecurity-crs/coreruleset/crs-setup.confcd /etc/apache2/mods-available/ && pwdsudo 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>
+ # Include OWASP ModSecurity CRS rules if installed
+ IncludeOptional /usr/share/modsecurity-crs/*.load
+</IfModule>sudo apache2ctl configtestSyntax OKを確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive (running) を確認します。
稼働済みのApacheバーチャルサイトの設定ファイルをいじります。バックアップ確認は入念に行ってください。
cd /etc/apache2/sites-available && pwdsudo 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を確認します。
sudo systemctl restart apache2.servicesystemctl status apache2.serviceactive (running) を確認します。
?modsecparam=testを追加してアクセスします。のように、アクセスできないことを確認します。
また、サーバでも
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として検知モードとして動かした方が良いでしょう。
Powered by WordPress & Theme by Anders Norén