CloudWatch インテリジェントオペレーションでこのブログのログを調査してみました

CloudWatch インテリジェントオペレーションを設定しました。

設定

マネジメントコンソールでCloudWatchにアクセスして、[AIオペレーション]を展開して、概要、調査、設定どのメニューにも[このアカウント用に設定]ボタンがあったのでクリックしました。

調査データの保持期限をデフォルトで最大の90日のままにしました。
画面下部のIAMロールは新規作成しました。

ログ調査

CloudWatch Logs Insightで、このブログのEC2インスタンスから送信している、NGINXとPHPのログを選択して適当なクエリを実行しました。
実行結果から[調査]-[新しい調査を開始]を選択しました。

調査のタイトルをBlog WordPress server errorにして、日付時間を適当に設定して、[調査を開始]をクリックしました。

調査が完了して、調査結果のフィードと提案が示されました。

フィード

「ログにはWordPressブログへのHTTPトラフィックが記録されており、ほとんどのリクエストはAmazon CloudFront経由で行われています。アクティビティの大部分は、スクリプトやスタイルの読み込み、post-new.phpやedit.phpなどの管理ページへのアクセスなど、WordPress管理パネルでの通常の操作です。複数のNginxエラーログには、「/oldsite」、「/New」、「/OLD」、「/wp-old」などの存在しないディレクトリへのリクエストで404エラーが発生しており、スキャンまたはプローブアクティビティが発生している可能性が示唆されています。また、PHPスクリプトの不足に関連するFastCGIエラーも確認されており、具体的にはサーバー上に存在しない「hello_dolly_v2.php」などのファイルへのアクセス試行が見られます。WordPress管理アクティビティはすべて、CloudFront経由で同じIPアドレス（115.125.248.50）から発信されているように見えますが、スキャン試行はさまざまなソースから行われています。」

観察結果の提案

「ログには、ブログサービスのnginxエラーログに複数の中優先度の異常が記録されています。エラーは主に2つのカテゴリに分類されます。1つは「robots.txt」や「ioxi002.PhP7」といった存在しないファイルをnginxが開こうとしたときに発生する「ファイルが見つからない」エラー、もう1つはサーバー上に存在しないPHPファイルを処理しようとしたときに発生する「プライマリスクリプトが不明です」というFastCGIエラーです。これらのリクエストは2つのクライアントIPアドレス（10.0.42.151と10.0.43.140）からホスト「8bangai.rocks」に向けられています。リクエストされたファイルには、robots.txtなどの一般的なWebアプリケーションファイルに加え、wp_filemanager.phpやadminer.phpといったコンテンツ管理システムや管理ツールに関連すると思われるPHPファイルも含まれています。」

「WordPressブログのPHP-FPMエラーログに、優先度低の異常が2件記録されています。どちらの異常も、同じファイル（/usr/share/nginx/yamamanx/wp-content/themes/stinger5ver20140902/404.php）の12行目で発生したPHP警告です。最初の警告は、コードがnull値の「cat_ID」プロパティを読み取ろうとした際に発生しました。2つ目の警告は、インデックス0の未定義配列キーにアクセスしようとした際に発生しました。これらの警告は、2025年7月31日23時53分（UTC）から2025年8月1日0時22分（UTC）までの間に複数回発生しました。」

少しすると仮説とアクションが提案されました。

仮説

「根本原因は、blog-role サービス上の WordPress インストールを対象とした自動脆弱性スキャンです。複数の IP アドレスからのこのスキャン活動は、存在しない管理ファイル (wp_filemanager.php や adminer.php など) や潜在的なバックアップディレクトリ (/oldsite や /OLD など) をリクエストすることで、一般的なセキュリティ上の弱点を探っています。これらのスキャン試行がサーバーに到達すると、WordPress 404 エラーハンドラー (404.php) が起動します。このハンドラーの 12 行目にコーディングエラーがあり、これらのリクエストの処理時に PHP 警告が生成されます。この警告は、スキャンによって引き起こされた 404 エラーを処理する際に、コードが null オブジェクトや未定義の配列インデックスのプロパティにアクセスしようとしたために発生します。スキャン自体は直接的なサービス中断を引き起こしていませんが、多数のエラーログエントリを生成し、潜在的なセキュリティ上の懸念事項を明らかにしています。これは、スキャンが WordPress インストール内の悪用可能な脆弱性を体系的にテストしているように見えるためです。」

提案されたアクション

「WordPressテーマ（stinger5ver20140902）の404.phpファイルを確認し、cat_IDプロパティと配列インデックスにアクセスする前に適切なnullチェックを追加することで、PHP警告を修正してください。
Webアプリケーションファイアウォール（WAF）ルールを実装または更新し、疑わしいスキャンパターンや、wp_filemanager.phpやadminer.phpなどの存在しない管理ファイルへのリクエストをブロックしてください。
適切なrobots.txtファイルを設定して、不要な404エラーを削減し、適切なクローラー指示を提供してください。
スキャンアクティビティによるサーバーへの影響を軽減するため、404/エラーレスポンスを返すリクエストに対してIPベースのレート制限を実装することを検討してください。」

直接的な問題はなさそうですが、余計なログを減らすために、存在しないファイルへのリクエストをブロックするWAFルールの設定を検討します。

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。

「AWS認定資格試験テキスト　AWS認定AIプラクティショナー」という本を書きました。

「ポケットスタディ AWS認定 デベロッパーアソシエイト ［DVA-C02対応］ 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。