はじめに

以前、.env ファイルを狙った大量スキャンについて記事を書きました。

そのとき紹介したのは、「設定ファイルが公開されていないか」を世界中で機械的に探し回るボットの話です。

今回観測したログは、その続編とも言えるものでした。

狙われていたのは wp-config.php ……ではありません。

/wp-config.php.bak
/wp-config.php.old

つまり、人間が「作業時に残しておいたバックアップ」です。

今回もホスト名・IPアドレス・ディレクトリ名などは無害化しています。例によって、テロリストに名前を与えていません。

観測されたログ（マスキング済み）

[Fri Sep 04 00:55:48 2026] ModSecurity:
Rule 920440
URL file extension is restricted by policy
URI: /wp-config.php.bak

[Fri Sep 04 00:55:48 2026] ModSecurity:
Rule 930130
Restricted File Access Attempt
URI: /wp-config.php.bak

[Fri Sep 04 00:55:48 2026] ModSecurity:
Rule 920440
URL file extension is restricted by policy
URI: /wp-config.php.old

[Fri Sep 04 00:55:48 2026] ModSecurity:
Rule 930130
Restricted File Access Attempt
URI: /wp-config.php.old

数百ミリ秒という短時間で、.bak と .old の両方を試しています。ブラウザで人間が操作しているとは考えにくく、自動化されたスキャナーによる探索と見てよいでしょう。

なぜ .bak や .old を探すのか？

攻撃者が欲しいのは、バックアップファイルそのものではありません。その中に書かれている情報と「運用者の癖」です。

wp-config.php には、

  • データベースの接続情報
  • WordPressの認証キー（AUTH_KEY や SECURE_AUTH_KEY）
  • Cookieの暗号化キー
  • テーブルプレフィックス
  • サイト固有の設定

などが保存されています。本来の wp-config.php はPHPとして実行されるため、その内容をブラウザから読むことはできません。

しかし、

  • wp-config.php.bak
  • wp-config.php.old

になると話は別です。WebサーバーはこれらをPHPとして扱わず、単なるテキストファイルとして返してしまう場合があります。

このテキストファイルが表示されてしまえば、攻撃者はWordPressの脆弱性を探す必要すらありません。データベースへ直接接続するための情報が、そのまま手に入ってしまうからです。

玄関の鍵を壊そうとしているのではありません。玄関脇の植木鉢に、合鍵が入っていないかを確認している状態です。

本当に見られているのは「運用」

ここで興味深いのは、攻撃者が .bak を探していることではありません。

「そのようなファイルを公開領域へ置く運用をしているか」

を見ています。例えば

cp wp-config.php wp-config.php.bak
  • 編集前の退避。
  • FTPソフトが自動生成したバックアップ。
  • エディタが保存した一時ファイル。

どれも作業中であれば珍しいものではありません。問題なのは、それを公開ディレクトリへ置いたままにしてしまうことです。

もし .bak が見つかったら、多くのスキャナーはそこで終わりません。

続けて

  • wp-config.php.save
  • wp-config.php.tmp
  • wp-config.php.orig
  • backup/
  • old/
  • test/

などを次々に探し始めます。理由は単純です。

「バックアップを公開ディレクトリへ置く運用をしているなら、他にも何か残っている可能性が高い。」

と判断するからです。つまり、.bak はゴールではありません。攻撃者にとっては

「このサーバーは、まだ掘る価値がある」

という判断材料です。

ModSecurityは何を見ていたのか

今回ヒットしたのは二つのルールでした。

Rule 920440

まず反応したのは

URL file extension is restricted by policy

というルールです。.bak や .old といった、本来ブラウザから取得されるべきではない拡張子を検知しています。

つまり、「その拡張子をHTTPで取りに来る時点で怪しい」という考え方です。

Rule 930130

続いて

Restricted File Access Attempt

が反応しています。こちらはファイル名そのものを見ています。

  • 危険な拡張子
  • 危険なファイル名

という二方向から同じリクエストを評価していました。一つのルールだけではなく、多層で検査するOWASP CRSらしい構成です。

ボットは「運用者の癖」を学習している

以前の記事では、

「多くの攻撃は、意志を持たず、目標を自動的に追尾するボットが大半を占めています。」

と書きました。今回のログも、まさにその延長線上にあります。ボットは感情を持って

「この管理者は雑そうだ」

と考えているわけではありません。過去の膨大な成功例から、

  • .bak が見つかったサーバーは他にも置き忘れが多い
  • .env.production が見つかる環境は設定管理も甘い
  • .git が公開されているサーバーはソース管理も甘い

という"統計"を利用しているだけです。つまり攻撃者は、サーバーを見ているようで、その向こうにいる運用者の習慣を見ています。

ソフトウェアの脆弱性だけではなく、人間の癖まで含めてスキャン対象になっているということです。

おわりに

以前は、ソフトウェアの脆弱性を突く攻撃が主流でした。もちろん今もゼロデイ攻撃は存在します。

しかしログを眺めていると、それと同じくらい多いのが

「人間が置き忘れたものを探す攻撃」

です。

  • .env
  • .bak
  • .old

どれも高度な脆弱性ではありません。運用の隙です。だからこそ、防御も特別な技術だけではありません。

  • 不要なファイルを公開ディレクトリへ置かない。
  • 作業が終わったら必ず片付ける。
  • 公開前に一度確認する。

そうした当たり前の積み重ねが、結果として最も強い防御になります。

それを防ぐための筆者の手

/etc/conf_backup

のような、まず公開ディレクトリではないディレクトリを作り、

sudo cp -pi /home/www-data/wordpress/wp-config.php /etc/conf_backup/wp-config.php.conf.$(date +%Y%m%d)

のように別ディレクトリに作ります。(もちろん、/etcがWeb経由で閲覧できる状況になっているのであれば、それは「バックアップが見えるかどうか」を心配する段階ではありません。サーバーそのものの侵害を疑うべき状況です）

また、変数による日付自動付与により

  • 最新版2026-3（承認済み）.xlsx
  • 2026確定版（社長の意見反映）.xlsm
  • 最新確定版2026_コピー(2)セキュリティ委員修正済み.xlsx
  • 改訂版2026_new_コピー(1)レビュー済み.xlsm
  • 2026-10改訂最新版（消さないこと）重役確認済み.xlsx

のような「だから最新どれだよ」を防ぐことはある程度行えます。ちょっとした工夫で癖は防げるというお話しでした。