インターネットに公開したテストサーバが受けていた攻撃パターンを分析

弊社関連のテスト用のインターネットサーバがあります。そこへ外部からの攻撃の内容を分析してみました。今頑張られているサーバ保守のエンジニア様方々のために、参考になればと思い解析結果を公開致します。お役に立てばと考えています。

見たのは 2 台です。サーバAは古い LAMP 構成、サーバBは新しい Ubuntu LTS で、どちらもテスト用にインターネットへ出しています。ホスト名やアドレス、アプリ名は伏せています。攻撃の記録として残る数字と、空振りだったかどうかだけを書いています。分析したのは 2026年10月24日です。

Web のログは、サーバAが 9月28日から10月23日、サーバBが 10月9日から10月23日です。SSH はサーバAが 10月4日から、サーバBが 9月5日から見ています。時刻は UTC です。日本時間は 9 時間足してください。

先に、結論

両方とも、侵入や改ざんの痕跡は見つかりませんでした。来ていた攻撃は、不特定多数へ投げる自動スキャンで、この 2 台を名指ししたものではありません。

Web シェルの名前を探して、成功の応答（2xx）が返ったものは 0 件です。新しく作られた実行ファイルも見つけていません。SSH はパスワード認証を切ってあり、総当たりはすべて失敗しています。

ただし、痕跡が無いことは、侵害が無いことの証明ではありません。JPCERT も同じ注記をしています。ここにあるのは、ログとサーバの状態を調べた範囲での結果です。

どのくらい来ているか

サーバAは 26 日で 68,689 件、送信元のIPアドレスは 4,810 件です。1 日あたり約 2,600 件。そのうち、こちらが置いているページへのアクセスは約 6% でした。残りは、存在しないパスを叩く探索と、トップページへの集中アクセスです。

サーバBは 15 日で 4,507 件、送信元のIPアドレスは 1,059 件です。1 日あたり約 300 件で、サーバAのおよそ 9 分の 1 です。PHP も CGI も入っていないので、当たり所が小さいのだと思います。

SSH の不正なログイン試行は、サーバAが 4,430 件（送信元のIPアドレス 85 件）、サーバBが 5,985 件（送信元のIPアドレス 187 件）です。Bの方が多いのは、見ている期間が長いからです。どちらも成功はしていません。

外から届くのは、両方とも Web と SSH だけです。データベースやアプリ本体は外に出していません。

サーバAでは、半分近くが「そんなパスは無い」

サーバAの応答を分けると、404 が 32,679 件です。WordPress や .env、シェルの名前など、置いていないパスを順に試しています。302 が 21,461 件で、これは HTTP から HTTPS への誘導が中心です。200 は 10,960 件で、正規のページとトップページです。

メソッドは GET が 60,606、POST が 7,015、HEAD が 85 です。POST のうち約 4,300 件は、あとで書く集中アクセスがトップページへ送ったものです。

リクエストを性質で分けると、攻撃や探索として分類できたものが 21,940 件（32%）です。トップページが 16,357 件（24%）ですが、そのうち約 11,100 件は同じ集中アクセスなので、普通の閲覧とは分けて見た方がよいです。正規のコンテンツは 4,365 件（6%）。robots や favicon は 2,308 件。残り 23,719 件（34%）は、この分類に入らなかったものです。

探していたものは、どれも「あれば使う」型です。

設定ファイルと秘密情報。.env や .git、クラウドの認証情報。API キーやデータベースのパスワード、ソースそのものを取りに来ています。すべて 404 か 302 でした。公開ディレクトリに秘密を置かない、これがそのまま効いています。

WordPress。ログイン画面や xmlrpc、REST の一括エンドポイント。このサーバに WordPress は無いので、404 か 302 です。

管理画面とデータベース管理画面。/admin や phpMyAdmin のような既定の場所。接触はなく、404 です。

phpinfo や test.php。PHP の設定を見て、次の攻撃の材料にする探索です。404 でした。

他の製品。CGI や Java、Solr、Jenkins、家庭用ルータの管理画面。このサーバには無いので、すべて 404 です。

バックアップ。.sql や .zip、dump という名前。データベースの中身をそのまま置いていないかを見ています。すべて 404 です。

ディレクトリを遡る要求。../ や、それを符号化した形、システムのファイル名。すべて 404 か 400 です。

シェルの名前で、乗っ取られているかを調べに来る

既知のバックドアのファイル名を GET して、200 が返れば「このサーバはもう入られている」と判断する探索もあります。サーバAでは 564 件以上あり、すべて 404 でした。

名前は使い回しです。WordPress のプラグインに見せかけたもの、1.php や admin.php のような汎用名、キャンペーンごとに決まった名前、ランダムな名前。同じ辞書を、何台ものサーバへ順番に投げています。各名称が 100 件前後なのは、そのためです。

30 日以内に作られたり変わったりした PHP や実行ファイルも 0 件でした。今後、この種のパスが 1 つでも 200 を返したら、その時点でインシデントとして見た方がよいです。ログのアラート条件に入れておく価値があります。

一日だけ、まとまって来た

サーバAの普段は 1 日 1,000〜3,000 件です。10月23日だけ 14,557 件まで跳ねました。うち 13,636 件（94%）は、同じ送信元のまとまりです。9月28日に 384 件、9月30日に 1,157 件の小さな山があり、約 3 週間おいて、10月23日にまとめて来ています。偵察して、間を置いて、投下する、という動きに見えます。

中身の多くは、トップページへの GET と POST です。User-Agent は空。WordPress の REST も少し混ざっています。ステータスは 302 が 8,276 件、200 が 3,617 件、404 が 1,766 件。そのまとまりをファイアウォールで止めたあとは 0 件です。小容量のサーバでは、この種の集中が負荷になります。

そのまとまりだけで 15,226 件あり、Web 全体の上位を占めています。残りは件数の少ない送信元が長く続きます。アドレスは入れ替わるので、レンジごと止めるより、回数やパスの傾向で切る fail2ban のような仕組みの方が合います。

時間帯も、普段は平坦です。毎時 1,200〜3,000 件で、人が働く時間には寄っていません。12時台・14時台・22時台（UTC）の山は、10月23日のその集中です。

SSH は、パスワードを受け付けないので全部拒否

サーバAの SSH は、存在しないユーザー名で 4,430 回試されています。同じ辞書を、いくつかの送信元に分けて投げています。ユーザー名は user、admin、debian、pi、oracle のような、どこにでもある一覧です。このサーバの利用者を調べたものではありません。

パスワード認証は無効で、root のログインも許可していません。試行はすぐ切れます。ログの量と再試行を減らすなら、SSH のレート制限と fail2ban が次の一手です。

PHP の更新が終わっているサーバは、緩和では足りない

2026年10月21日に PHP から、10月22日に JPCERT と IPA から、PHP2Shell（CVE-2026-109618 と CVE-2026-109619）の注意が出ています。認証なしで遠隔からコードを実行できる、という内容です。メモリ不足の処理のあと内部のデータが壊れたまま残るものと、エラーのあと解放済みのメモリを参照するものの組み合わせ、と公表されています。PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 より前が対象で、5.4 以降の広い版に影響します。mod_php が特に危ない、とされています。

サーバAの PHP は 7.3 系で、更新は終わっています。修正版は出ません。メモリ上限、アップロードサイズ、upload_progress の無効化を、アプリから上書きできない形で入れ、実在しない .php を PHP へ渡さないようにしました。過大な要求は拒否し、設定が実際に効いていることと、公開ページが表示されることは確認しています。これは発火点へスキャナが直接届きにくくする緩和です。根本は、PHP 8 系と、更新が続いている OS への移行です。

10月23日には CVE-2026-115560 も追加で公表されています。特殊な構成の Web アプリが対象で、upload_progress を止めておくことがあわせて推奨されています。サーバAではその設定で覆っています。

サーバBには PHP がありません。Apache も mod_php を読んでおらず、公開しているのは静的なページだけです。PHP2Shell は該当しません。古い PHP-CGI の引数注入（CVE-2024-4577 型）を試す要求は 2 件届きましたが、返ったのは静的ページで、コードは動いていません。あとから PHP を入れるなら、修正が入った版かどうかを先に確認した方がよいです。

公表元はこちらです。

• JPCERT/CC JPCERT-AT-2026-0033
• IPA PHP の脆弱性対策について（CVE-2026-109618 / 109619）
• PHP Group 2026年10月21日のセキュリティ告知

サーバBは、同じスキャンがほとんど当たらない

サーバBは平均約 300 件/日です。多い日は 10月15日の 551 件、10月19日の 506 件、10月10日の 504 件。少ない日は 10月21日の 116 件です。続きません。1 つの送信元が 30 秒前後で 100〜300 件送って去る、というバーストがピークの理由です。時間帯も業務時間には寄らず、UTC 15 時台の 461 件が山で、ほぼ一日中来ています。

404 が 68% です。200 は 1,059 件ありますが、内訳は / が 919、絶対 URI 形式の / が 121、/index.html が 12、その他が 7 です。すべて静的ページで、コードが動いた応答ではありません。

目立つのは次のようなものです。

phpMyAdmin のパス総当たりが 768 件。少数の送信元が、同じ長さのパス一覧を分けて投げています。Web シェルの名前が 409 件。.env や .git、設定ファイルが 337 件。クラウドの認証情報や CI の設定が 172 件で、これは 1 つの送信元が 52 秒に集中させていました。すべて 404 です。秘密のファイルは Web の公開領域に置いていません。.env やクラウドの鍵を取られると被害が大きいので、ここが空振りで済んだのは構成のおかげです。

プロキシの踏み台を試す CONNECT が 12 件あり、すべて 405 で拒否しています。絶対 URI 形式も 246 件ありましたが、中継はしていません。POST が 200 になっても、静的ページが返っただけで、転送されたわけではありません。

ルータや NAS、VPN 機器向けの既知の穴も来ています。家庭用ルータ、光回線の機器、FortiGate や Cisco、QNAP。このサーバはそれらの製品ではないので 404 です。ボットネットの配布物を取らせようとする要求も数件あり、404 か拒否です。Apache の古いパス迂回（CVE-2021-41773 型）は、URI 不正として拒否しています。/cgi-bin もありません。

80 番へ TLS や HTTP/2、WebLogic の t3 を送りつける、プロトコルの取り違えが約 290 件。400 か 501 です。

新しい傾向として、AI エージェント向けの /mcp や /sse が 29 件ありました。まだ少なく、すべて 404 ですが、スキャンの辞書は製品の流行に合わせて増えています。

攻撃用のツールと、調査目的のスキャナが混ざっています。User-Agent が空、または偽装が約 25% です。10〜60 秒で終わる単発が多いので、送信元を一つずつ手で塞いでも、次は別のところから来ます。

SSH は 5,985 回です。辞書を、多数の送信元に分散しています。パスワード認証は無効です。不正な試行の成功は 0 です。root は拒否しています。鍵、sudoers、cron、systemd、一時ディレクトリ、プロセス、外向きの通信を見ましたが、後から足されたものはありませんでした。直近 14 日で変わったファイルは、自動更新の時刻と一致していて、改ざんではありません。

サーバBは読み取りだけの調査で、この時点では設定を変えていません。残っている点は、カーネルと libc の更新を入れたあとの再起動がまだなことと、80 番が全世界に開いていて平文の HTTP であることです。

侵入していないかを、どこで見たか

サーバAは、JPCERT が挙げる項目に、こちらで足した確認を合わせています。

HTTP 500 とメモリ超過は 0 件。PHP ワーカーの異常終了もありません。Web 領域で 30 日以内に変わった PHP やシェルもありません。/tmp や /dev/shm に実行できる不審なファイルはありません。外向きの不審な通信もありません。cron は証明書の更新だけで、SSH の公開鍵は長いあいだ変わっていません。書き込めるディレクトリは、CMS として必要な範囲に収まっています。ここは定期的に見た方がよいです。

サーバBも、アカウント、鍵、sudoers、cron、systemd、一時ディレクトリ、プロセス、外向き通信、公開領域を見ています。攻撃用パスへの 200 は 0 件です。

繰り返しになりますが、これらは「見た範囲では痕跡が無かった」です。無いことを証明してはいません。

保守している人に、共有しておきたいこと

インターネットに出したサーバは、何も有名でなくても、毎日スキャンされます。WordPress が無くても WordPress を探され、PHP が無くても PHP のファイル名を探されます。空振りが続くのは、置いていないからです。秘密のファイルを公開ディレクトリに置いた瞬間、同じスキャンが当たります。

今回の 2 台から、優先してやりたいことは次です。

更新が入ったカーネルや libc は、再起動するまで動いているプロセスに乗りません。入れたつもりで終わらせない。

80 番を全世界に開けたままにしない。使う人のアドレスに限る、不要なパスは実行させない。スキャンそのものが減ります。

更新の終わった OS と PHP は、緩和を重ねても根本にはなりません。新しい環境へ移す。PHP2Shell は、サーバAではその状態です。

HTTP のままにしない。HTTPS へ誘導する。

fail2ban と、SSH のレート制限、できれば接続元の制限。送信元は入れ替わるので、レンジ遮断だけでは追いつきません。

アクセスログに User-Agent と Referer を残す。あとから「人が見たのか、道具が投げたのか」を分ける材料になります。

強い権限で動く処理は、専用のユーザーに分ける。入られたときの広がりが違います。

余裕があれば、前段に WAF を置き、ログはサーバの外へ保管して、週に一度は見ます。見るポイントは、PHP の異常終了、新しくできた PHP、それまで 404 だった攻撃用パスが 200 になること、です。

移行が終わるまでは、PHP2Shell の続報もあわせて確認しています。同じログの見方を、他の公開サーバでも使ってもらえたら、この記録を出した意味があります。