概要

2025/08/12 朝、管理しているWebサーバーにSSHで接続できなくなり、Webサイトも全て閲覧できなくなる障害が発生しました。本記事は、その原因究明から、応急処置、そして恒久対策までの一連の流れを記録したものです。

障害発生時の状況

  • Webサイトにアクセスすると、タイムアウトエラーになる。
  • SSHでログインしようとしても、接続ができない。
  • VPSの管理コンソールから再起動をかけると、redis-serverの停止処理（DBの保存）でタイムアウトし、正常にシャットダウンできない。
  • 強制再起動後、一時的に復旧するものの、しばらくすると再び応答がなくなる。

止まっていたサービス

  • mongod
  • redis-server
  • elasticsearch
  • growi

原因の特定手順

切り分け中に原因判明

障害の切り分け中、Wasabiクラウドストレージをマウントしようとした際に、以下のエラーが発生しました。

  • クラウドストレージのマウントを実行
sudo mount -a
mount.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以上にまで肥大化していたことが、直接の原因であると確定しました。

ここまで分かれば対処はもうすぐです。

対処手順

ステップ1：応急処置（空き容量の確保）

まず、サーバーを正常に動作させるため、巨大化した監査ログを削除し、空き容量を確保します。

  • 巨大なログファイルを削除
sudo rm /var/log/apache2/modsec_audit.log*
  • Apacheを再起動して、ファイルハンドルを解放
sudo systemctl restart apache2.service

ステップ2：恒久対策（監査ログの無効化）

modsec_audit.logは、攻撃の詳細な分析やデバッグには役立ちますが、今回のようにログがディスクを圧迫し、サーバーダウンを引き起こしますため、この設定をオフにします。

  1. ModSecurityのメイン設定ファイルを開きます。 sudo nano /etc/modsecurity/modsecurity.conf
  2. SecAuditEngineの値をOffに変更します。 修正前: SecAuditEngine RelevantOnly 修正後: SecAuditEngine Off
  3. Apacheをリロードして設定を反映させます。 sudo systemctl reload apache2.service

その後、念のためサーバそのものを

```bash
sudo reboot
```

で、状況が元に戻っていることを確認しました。

まとめ

今回の障害は、ModSecurityの監査ログが有効になったまま放置され、そのログがログローテーションの対象になっていなかったために、ディスク容量を100%使い果たしたことが原因でした。

前述したとおり、よりよいスペックのサーバに引っ越した後の出来事だけに、かなりの冷や汗ものでした。