先日、Naiba は実際の事例を処理しました。長期間誰もメンテナンスしていなかった EC サイトが侵入され、攻撃者はすでに数ヶ月間潜伏していた可能性があります。
このサイトは Naiba が提供するサーバーを使用しており、コンテンツとセキュリティはクライアント自身が管理していました。サーバーには WP Panel がインストールされ、サイトの可用性監視が有効になっていました。パネルがサイトにアクセスできないと警告を出すまで、私が調査に入り、サイトにすでに多層のバックドアが仕込まれていることを発見しました。
最も背筋が凍るのは„サイトがハッキングされた“ことではなく、この数ヶ月間サイトがほぼ正常に見えていたことです。クライアントも長い間管理画面にログインしていないと述べていました。今回のダウンがなければ、次に異常に気づくのはいつだったかわかりません。
さらにサイトの侵入記録を調査したところ、時間が経ちすぎているため、最初にどの脆弱性を通じて侵入されたのかは特定できませんでした。しかし管理画面から、当時 12 件のコア、テーマ、またはプラグインの更新が長期間インストールされていなかったことが確認できます。これは攻撃者が必ずしも特定のプラグイン脆弱性を通じて侵入したことを証明するものではありませんが、少なくともサイトが長期間高リスク状態にあったことを示しています。特に公開済みの脆弱性は自動スキャンツールによって一括で悪用されることが多く、AI の普及により脆弱性の分析や攻撃スクリプトの改変のハードルがさらに下がっています。
この事件は Naiba に大きな衝撃を与えました。WP Panel パネルを開発したのは、初心者ユーザーがサーバーと WordPress サイトを適切に管理できるようにしたいという思いからです。そのため、WP Panel のセキュリティ保護をさらに強化し、以前からあったセキュリティ機能に加えて、今回1.6.0 では「より早く侵入を発見する」ための監視を一整套新たに追加しました。
注意してください、これは„より早く侵入を発見する“ための監視であり、侵入を阻止できるという意味ではありません。サイトが侵入されないことを保証するものではありません。これはどのツールにもできません。できるのは、この事例のようにサイトが開けなくなるまで待つのではなく、問題が起きた早期の段階でシグナルを受け取れるようにすることです。
一、この事例で攻撃者が実際に行ったこと
多くの方は、サイトがハッキングされるのは「トップページに黒いページを貼られる」程度の単純なものだと思っています。実際の攻撃はもっと隠蔽されており、段階的に行われ、潜伏させます。この事例では、私がクリーンアップした際に合計 4 層の永続化を発見しました。
- 第一層は、偽のプラグインです。表面的には正常なプラグインですが、実際にはリモートで記事を投稿するインターフェースを提供し、さらには密かに管理者アカウントを作成することもできました。
- 第二層は、Cloudflare に偽装した「プラグイン」です。これは自身を WordPress の mu-plugins ディレクトリにコピーし、管理画面では自身を隠します。「プラグインを停止」をクリックするだけでは、完全に削除できません。
- 第三層は、データベース内のトリガーです。攻撃者はデータベースにロジックを仕込みました。トップページが編集されると、隠されたスパムコンテンツを自動的に再挿入するというものです。そのため管理画面で削除しても、フロントエンドを更新するとコンテンツが戻ってきます。
- 第四層は、アプリケーションパスワードです。攻撃者は一見合法に見える「アプリケーションパスワード」を使い、WordPress のインターフェースを通じて自動的に記事を投稿し、次々とスパムをサイトに流し込みました。ブラウザ上のログインをログアウトしても、それは依然として使用できました。
これら 4 層が重なり、さらにログの期限切れ、ファイルの改変、スパム記事の「公開日」が数ヶ月前に偽装されていたことも加わり、発見した時には追跡に使える証拠がすでに失われていることがよくあります。
二、なぜ「事後に初めて気づく」ことがこんなに一般的なのか
Naiba が接してきた企業サイトの状況では、事後に初めて気づくケースは非常に普通で一般的です。なぜなら、ほとんどの企業サイトには専任の管理者がおらず、管理画面に更新通知があっても、多くの人はスマホの更新と同じで更新するほど重くなると考え、見て見ぬふりをするからです。
長期間メンテナンスされていないサイトは、構築後にほとんど手を加えられず、テーマやプラグインも更新されず、管理者も当初の数人のままで、管理画面を覗く人もほとんどいない。
こうしたサイトの本当の危険は「誰も防御していない」ことではなく、「何か起きても誰も気づかない」ことにある。
攻撃者が最も好むのはこうしたサイトだ。ゆっくりと一つの入口を手に入れ、その後は焦らず、数日、数週間、あるいは数ヶ月かけて少しずつ永続化を仕込んでいく。フロント側では異常は見えず、サイトは変わらず開ける。スパムコンテンツとトラフィックでサーバーがダウンし、サイトが開けなくなる頃には、それはすでに最後の段階であり、最初の段階ではない。
三、今回 WP Panel に追加されたもの
「より早い発見」を中心に、1.6.0 では既存のセキュリティ保護を基盤として、以下の機能が追加された。
1. アカウントと認証情報の監視
サイトの管理者アカウントを監視し、管理者アカウントの追加、権限降格、権限昇格が発生した際に、WP Panel が即座にアラートを出す。アプリケーションパスワードはさらに一件ずつ記録される。いつ新しいものが追加されたか、最初に誰が使用したか、送信元 IP に変化がないか、いつ取り消されたか。
この点は特に重要だ。事例の攻撃者は、アプリケーションパスワードを利用して長期間自動投稿を行っていた。
2. コンテンツと設定の監視
長期間メンテナンスされていないサイトで、ある日突然多くの投稿やページの変更が発生した場合、侵害された可能性が高い。そのため WP Panel 1.6.0 では、投稿やページの集中公開、一括変更、削除、非公開化の監視アラートをサポートしている。ホームページの変更も通知される（連続する重複変更は自動的に統合され、何度も通知されることはない）。ユーザー登録の開放、デフォルトロールの変更も同様に通知される。
3. データベース永続化オブジェクトの監視
データベース内のトリガー、イベント、ストアドプロシージャ、関数を監視する。事例のような「コンテンツを削除しても勝手に復活する」データベースバックドアに特化している。
4. ファイル整合性ベースライン
ファイルロックが有効で状態が健全なサイトでは、WP Panel はサイト外にコードファイルのフィンガープリントベースラインを保存し、コア、プラグイン、テーマ、MU プラグインなどのファイルが変更されていないかを監視する。通常のメンテナンス更新が完了すると新しいベースラインが受け入れられ、異常な変更のみがアラートされる。
5. SQL インジェクションリクエストの防御
信頼度の高い SQL インジェクションリクエストを、PHP に到達する前に直接ブロックする。同一の信頼できる送信元が繰り返しトリガーした場合、一時的にブロックされる。ここで説明しておくと、これは完全な WAF ではなく、POST/JSON リクエストボディも検査しない。
6. アプリケーションパスワードの無効化
サイトスイッチが新たに追加された。新規作成サイトではアプリケーションパスワードがデフォルトで無効化され、「遺残したリモート認証情報が投稿に悪用される」リスクを軽減する。既存サイトはアップグレード後も許可が維持され、使用中のスマホアプリ、自動投稿、サードパーティ連携に影響はない。
これらに加えて、1.6.0 では一時メンテナンスウィンドウ、IPv6 永続ブロック、新規サイトログのデフォルト 14 日間保持、WordPress セキュリティイベントの 90 日間保持など、多くの細部も補完された。
四、今回の機能をあの事例に当てはめると
もしこれらの機能がサイト侵害前に導入されていれば、事件全体の発見プロセスは次のようになっていたかもしれない。
- 攻撃者が密かにアプリケーションパスワードを作成 → 認証情報監視が追加記録を残す。
- 偽プラグインがディスクに置かれ、新しい管理者が出現 → 管理者変更アラートとファイル整合性アラートが同時に発生する。
- データベーストリガーが仕込まれる → データベースオブジェクト監視が報告する。
- 短時間に数万件の投稿が集中公開される → コンテンツ公開量の異常アラートが発動する。
これらのシグナルは、どれか一つでも捉えられれば、サイトがまだ正常にアクセスできるうちに調査を開始するのに十分であり、数ヶ月後にサイトが開けなくなるまで待つ必要はない。
もちろん、ここで強調しておきたい。これらは「シグナル」であり「有罪判決」ではない。それ自体はサイトが必ず侵害されたことを証明するものではなく、投稿やユーザー、プラグインを自動で削除してくれるわけでもない。その価値は、適切なタイミングで介入できるようにすることにある。
五、WP Panel 1.6.0 の能力の限界
1.6.0 バージョンの WP Panel は、サイトが侵害されないことを保証するものではなく、「より早い発見」のみを解決する。
SQL 防御は URL レベルの信頼度の高い構造のみを処理し、リクエストボディは検査せず、完全な WAF の代替にはならず、あなたのサイトに必ず脆弱性があることを意味するものでもない。
ファイル整合性ベースラインが管理するのはファイルであり、「純粋なデータベース書き込み」、たとえば正規のインターフェースを通じた投稿までは管理できません。これらはデータベースオブジェクト監視とコンテンツ監視によって発見する必要があります。
ベースラインを確立したばかりの時点では、「現在のファイルの状態を記録した」ことだけを意味し、「サイトがクリーンである」ことを意味するわけではありません。悪意のあるファイルや未知の認証情報がベースライン確立前にすでに存在していた場合、やはり人手による再確認が必要です。
すべての監視はデフォルトで警告と証拠保全のみを行い、あなたのデータを自動的に操作することはありません。記事の削除、ユーザーの削除、プラグインの削除といった操作は、常にあなたの確認後に実行されます。
監視が本当に役立つ前提は、通知チャネルが適切に設定され、かつ誰かが確認していることです。そうでなければ、それはバックエンドにある単なる記録にすぎません。
最後に
冒頭のケースに戻ります。
サイトが侵入されること自体、完全に避けるのは難しいですが、「侵入されてから数ヶ月間気づかない」ことは完全に変えられます。
WP Panel 1.6.0 が目指すのは、異常を発見する時間をできるだけ早めることです。„サイトが開けなくなって初めて侵入に気づく“から„サイトに異常な動作が現れた瞬間に通知を受け取る“へ。 „ログが期限切れで何も調べられない“から„パネルにセキュリティイベントと証拠が残る“へ。
サイトを無敵にすることを約束するものではありませんが、少なくとも数ヶ月後に開けないサイトを前にして、何が起きたのかさえ分からない、という事態にはならないでしょう。
もしあなたの手元にも「構築後ほとんど管理していない」サイトがいくつかあるなら、今回の 1.6.0 はアップグレードする価値があります。
構築後にほとんどコンテンツを更新しないサイトについて、Naiba はより厳格な„サイト凍結“機能の追加も検討しています。通常のアクセスに影響を与えずに、ファイルと重要なデータの変更を可能な限り制限するものです。ただし、この機能はまだ初期構想段階であり、脆弱性の修正や日常的なメンテナンスの代わりにはなりません。
もしサイトが本当にバックエンド、フォーム、会員、オンライン取引機能を全く必要としないなら、純粋な静的 HTML を使用する方が、長期間誰もメンテナンスしない動的プログラムを維持するよりも通常は手間がかかりません。
WP Panel官网https://wp-panel.org