Manualmaton's Laboratory

2024年以来のワイヤレスイヤホン、導入です。

Bluetoothイヤホンを買い換えました。筆者が最終的に選択したのはAnkerのSoundcore Liberty 4 Proです。

それまで使用していたモデルは、同社のSport X20。イヤーフックがあるため落としにくいという利点がありましたが、アクティブノイズキャンセリングの効き具合に関してはやや物足りなくなっていったというのも事実です。特に移動時や周囲の雑音が気になる環境では、より強力な遮音性能がほしいというのも購入のきっかけである。

選択肢Pro 4 かPro 5か

SportはX20が未だ現役ということから、イヤーフックなしでも使える機種を選定していきます。選択肢として検討したのは、

• 昨年登場したLiberty Pro 4
• 今年新たに発表された後継機のLibetty Pro 5です。

最新モデルであるPro 5は性能面を見れば非常に魅力的ではありましたが、ここに一つの問題が立ちはだかります。

落としても授業料で済むか？

筆者は過去に、当時のSONYのハイエンドモデルを側溝に落として紛失してしまった経験があります。いくら2年使っていたとはいえ、高価格なイヤホンを失った際の精神的・金銭的ダメージは小さくなく、だからこそこれまである程度割り切って使える価格帯（そして落ちにくい形状）の製品を選んできました。

なので、Pro 5の約2.5万円強という価格設定は、万が一の紛失を想像した際にやや心理的ハードルが高いというものがあります。

一方でPro 4は、実売1万円台半ばから後半という価格帯でありながら、十分強力なノイズキャンセリング性能を確認。万が一の紛失時のリスクを許容範囲に抑えつつ、日常の静寂を手に入れるという点も協力でした。

確定、Pro 4

また、Pro 4のスマート充電ケースにディスプレイが搭載されている点もポイントでした。ケース側でノイズキャンセリングの切り替えやモード設定を直接行えるため、歩行中などに耳元のイヤホン本体を直接触る機会が減る。これは耳元での操作ミスによるポロリと落とす事故をある程度防げます。

それ以上に、実機を装着して「自分を選んだ」感が強いのものPro 4でした。

使用感、気になったことなどは改めてご報告します。

いつも訪れる定食屋にて。

鰹の刺身定食、そして

あじフライを注文。

たっぷり脂の乗った戻り鰹。ここは丁寧に生姜とネギが別添えなので味変にリズムつけられます。

ここで揚げ物を食べないのはこの店への敬意が欠けるとしてサクサクのアジフライ。ドラムスティックのように尻尾を持って食べられるのが最高です。

ですが、真に驚くべきは、最後に口を支配するのがご飯の甘みと香り。刺身もフライも味噌汁•漬物すら上書きする主食の破壊力はまさに定食屋の面目躍如でした。

はじめに

以前、.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

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