WAFログ1,001件を公開 小さなメディアサイトはこう狙われる

2026年10月4日から28日までの25日間に、このブログ(legare.tech)のWAF(不正なアクセスをサーバーの手前で止める仕組み)は1,001件のアクセスを止めました。月間の訪問者が200人前後の小さなサイトでも、1日平均40件ほどの攻撃が届いています。契約しているレンタルサーバーの管理画面から記録を書き出して集計し、何が狙われたのかをパブリッシャーの目線で整理しました。

関連記事
・PHP2Shellで止めた媒体・止めなかった媒体 日本と海外の対応差
・AIがパブリッシャーの収益構造を変える – Amazon・MSのコンテンツマーケットプレイスとスクレイピング問題の最前線
・Chromeが2026年9月に広告体験の新指標を追加、CrUXの4メトリクスとパブリッシャーへの影響

25日間で何件、どんな攻撃が来たのか?

止めた1,001件のうち57%は、置き忘れたファイルを探すアクセスでした。SQLインジェクション(データベースを不正に操作する攻撃)は203件で2番目です。

攻撃の種類別 件数と送信元IPの数(2026年10月4日〜28日)
置き忘れたファイルを探す
569件
IP 228個
SQLインジェクション
203件
IP 53個
OSコマンドの実行を狙う
82件
IP 14個
ディレクトリトラバーサル(サーバー内の別の場所をのぞく)
80件
IP 17個
XSS(ページに不正なスクリプトを埋め込む)
44件
IP 10個
その他
23件
IP 6個
出典: legare.tech の WAF ログ(2026年10月4日〜28日、筆者集計)

送り元のIPは293個あり、そのうち203個は1回しか来ていません。3日以上来たIPは3個だけでした。同じ相手が毎日しつこく来るより、使い捨てのアドレスから一度ずつ来る形が中心です。

日別に見ると、ふだんは1日10〜50件で、ときどき山が立ちます。2026年10月9日の123件、10月19日の203件、10月28日の68件です。山の中身はそれぞれ違うので、下で1つずつ見ていきます。

日別の検知件数(2026年10月4日〜28日)
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
▼
21
22
23
24
25
26
27
28
オレンジの棒: 2026年10月9日(123件)・10月19日(203件)・10月28日(68件)の山/▼ 2026年10月21日: PHP2Shell修正版公開/1日平均は10月4〜20日が45件、10月21〜27日が23件
出典: legare.tech の WAF ログ(2026年10月4日〜28日、筆者集計)

攻撃者は何を探しているのか?

いちばん多かったのは、`.bak`・`.old`・`~` のような末尾のついたファイル名です。設定ファイルを書き換える前にコピーを残すと、こういう名前になります。末尾別の件数は、`.bak` が186件、`.old` が129件、`~` が72件でした。

狙われたファイル末尾別の件数
.bak
186件
.old
129件
~
72件
.inc
56件
.org
45件
.log
31件
.tmp
31件
出典: legare.tech の WAF ログ(2026年10月4日〜28日、筆者集計)

狙われたファイル名の上位は次のとおりです。

  • `/.env.bak`(50件)、`/.env.old`(49件)、`/.env~`(28件)
  • `/wp-content/debug.log`(17件)
  • `/phpinfo.php` のコピー(`.bak`・`.old`・`~` の3種で計25件)
  • `/wp-config.php.old`(8件)

`.env` はデータベースのパスワードや API キーを書いておくファイルです。元のファイルは PHP として実行されるので中身は見えません。ところが `.bak` を付けたコピーはただの文字として返るため、パスワードがそのまま読めてしまいます。攻撃者はこの「うっかり残したコピー」を探しています。

`debug.log` は、WordPress のデバッグ記録を有効にすると `wp-content` の下に作られるファイルです。エラーの記録にはサーバー内のパスや、使っているプラグインの名前が残ります。WordPress のサイトだと分かったうえで、このファイルを名指しで探しに来ています。

このサイトはLaravel(WordPress とは別の PHP の仕組み)を使っていませんが、Laravel のログ(`/storage/logs/laravel.log`)を探すアクセスも9件ありました。相手はサイトの中身を調べてから来るのではなく、よくある名前の一覧を総当たりで試しています。

2026年10月19日、6分間に174個のIPから

25日間でいちばん大きな山は、2026年10月19日の13時33分から39分までの約6分間です。この間に182件、174個のIPから、置き忘れファイルを探すアクセスが届きました。1つのIPが送ったのは多くても3件です。

2026年10月19日 13:33〜13:39の1分ごとの件数
13:33
39件
13:34
68件
13:35
39件
13:36
29件
13:37
6件
13:38
0件
13:39
1件
この6分間で182件、174個のIPから届いた(1つのIPからの送信は最大3件)
出典: legare.tech の WAF ログ(2026年10月19日、筆者集計)

送り元のIPを登録情報(RDAP)で調べると、174個すべてがドイツの1つのホスティング会社のアドレスでした。IPを1件ごとに使い捨てて、別々の相手からのアクセスに見せる手口です。1件ずつ見ると目立たないため、IP ごとの回数で見張る仕組みでは見つけにくい手口です。WAF は送られてきた中身(ファイル名の形)で止めていたので、この山もすべて止まっています。

送り元の会社はアドレスを貸しているだけで、攻撃した本人ではありません。このため会社名は伏せます。

2026年10月28日、1本の記事に2分間で65回

この日の山は、性質が違いました。インドネシアの携帯回線の1つのIPから、8時51分から52分までの2分間に、SQLインジェクションが65件届きました。同じIPからは1時55分にも1件来ており、この日の合計は66件です。

狙われたのは、2026年3月に公開した AdCP の比較記事でした。記事のURLの末尾に SQL の命令を付け足し、データベースの応答が遅れるかどうかで弱点を探る型です。命令には、Oracle・SQL Server・PostgreSQL それぞれの「待て」の命令が混ざっていました。どのデータベースか分からないまま、ツールが全種類を順に試したのでしょう。

なぜこの記事だったのかは分かりません。検索結果や外部のリンク集から、ツールがURLを拾った可能性はあります。携帯回線は大勢の利用者が同じIPを使い回すため、送り主が乗っ取られた端末なのか、中継に使われた端末なのかも区別できません。

WAFの内側には何が届いていたか

WAF の記録は止めた分だけです。サーバーに届いたアクセスも見るために、10月25日(日本時間で10月25日4時ごろから26日4時半ごろまで)のアクセスログを集計しました。

  • 届いたリクエストは3,648件、送り元のIPは830個
  • そのうち641件は、自分から「bot」「crawler」などと名乗る巡回プログラム
  • 存在しない PHP ファイルを探すリクエストは638件で、送り元はわずか9個のIP。533件は「ファイルなし」(404)で終わり、残りも転送か空の応答で、中身は返していません
  • クラウドの1つのIPから、PEAR(PHP の古い付属ツール)の穴を狙う命令が108件。すべてHTTPSへの転送(301)で返り、命令は実行されていません

この日、WAF が止めたのは2件だけでした。サーバー側では、WAF の目印に当たらない形の探索が数百件届いていたことになります。ただし、どれも「ファイルがない」か「中身がない」で終わっており、何かを持ち出された跡は見つかりませんでした。

PHP2Shellの公表で攻撃は増えたのか?

増えていません。PHP 本体の脆弱性 PHP2Shell の修正版は、2026年10月21日に公開されました(経緯は2026年10月22日の記事にまとめています)。このサイトの WAF の件数は、10月4日から20日までが1日平均45件、10月21日から27日までが1日平均23件でした。公表の後のほうが少ないくらいです。

WAF の検知名にも、PHP2Shell を名指しするものはありませんでした。ここから言えるのは「目立った増加はない」ことまでです。PHP2Shell は PHP 本体の欠陥なので、WAF の目印に当たらない形で来る可能性もあります。WAF の件数が静かでも、PHP を修正版に上げる作業は省けません。

表示回数の急増は喜んでいいのか

同じ時期、Jetpack の表示回数は2026年10月13日から大きく跳ね上がりました。同年10月1日から12日までは1日平均8回だったのが、10月13日から28日までは1日平均304回です。訪問者数は1日5.4人から14.6人への増加にとどまりました。

ページ表示回数・訪問者数の1日平均
2026年10月1日〜12日 2026年10月13日〜28日
ページ表示回数

8回

304回

訪問者数

5.4人

14.6人

出典: legare.tech の Jetpack 統計(2026年10月1日〜28日、筆者集計)

2026年10月25日は、3人の訪問者で198回の表示がありました。1人あたり66回で、人が記事を読む量ではありません。サーバーのログでは、この日にブラウザを名乗って記事を開いたアクセスが161個のIPから269件ありました。そのうち、画面の見た目を作るファイル(CSS や JavaScript)も一緒に読み込んでいたのは19個のIPだけです。残りは、ページの文字だけを取りに来たプログラムと見られます。

広告を載せているサイトでは、ここに注意が要ります。Google AdSense の定義では、ロボットなどのソフトウェアによる表示やクリックは無効なトラフィックです。これが多いと、収益の見積もり額と確定額がずれたり、アカウントが停止されたりします。第三者が知らないうちに起こした場合でも、防ぐ責任はパブリッシャーにあるというのが AdSense の立場です。表示回数が急に増えたときは、まず人かどうかを確かめるのが先です。

パブリッシャーが今日やれること

今回の記録から、実際に狙われた順に並べると次の5つになります。

  1. 設定ファイルのコピー(`.bak`・`.old`・`~`)を公開フォルダに置かない。編集の前のコピーは公開フォルダの外に作る
  2. `wp-content/debug.log` を残さない。デバッグ記録は調べ終わったら止め、ファイルも消す
  3. 使っていないプラグインは停止して削除する。持っていないプラグインの穴まで総当たりで試しに来ます
  4. PHP を修正版に上げる。PHP2Shell のような PHP 本体の穴は、WAF やプラグインの更新では防げません
  5. 表示回数の急増は、収益の増加と考える前に人かどうかを確かめる

今回の1,001件は、どれも WAF が自動で止めたもので、こちらで個別に手を動かしたものはありません。

筆者が一番意外だったのは、攻撃の大半が「こちらの弱点を調べてから来る」のではなく「よくある失敗を順に試すだけ」だったことです。その分、置き忘れファイルとデバッグ記録をなくし、WAF を入れておけば、ほとんどは WAF の段階で止まります。

関連記事

参考記事

コメントを残す

上部へスクロール