WordPress / Drupal を Aikido で守る ── 無料枠で始める多層防御、最後の砦は「フルバック(Zen)」

数年前に自分で立てて、その後ほぼ放置していた自社WordPress。

本体は自動更新で上がっていた。けれど、プラグインやテーマはきちんと見ていない。誰も継続監視していない。

「これ、本当に安全なのか？」

正直、分からない。

そこで、WordPress / Drupal を Aikidoで、どこまで守れるのか。しかも、まずは無料枠でどこまで見える化できるのか。自分のサイトで試してみました。

昨日、ラグビーの守備の話を書きました。

セキュリティもまったく同じで、重要なのは 多層防御 です。

前には ディフェンスライン(線) が並ぶ。 破られたら、二人目・三人目がカバーに入る。 それでも抜かれたとき、最後に立っているのが フルバック。

フィールド全体、つまり 面 をカバーする最後の砦。

このフルバックが、Aikidoでいう Zen です。

第一線(線)：日々の守り ── 無料で始められる

前線の守りは、Aikidoの無料枠でもかなり始められます。

• SCA：依存パッケージのCVE確認
• SAST：コード上の脆弱パターン検知
• Secrets：秘密情報の混入検知
• サーフェス／ヘッダ監視：公開面の点検

これに加えて、WordPress本体・プラグイン・テーマの更新、不要なプラグインの削除、HTTPヘッダの強化。

ここが、攻撃を前で止める第一線です。

もちろん、有料機能が必要になる領域もあります。コンテナイメージのスキャン、フルDAST、オンプレ環境の常時スキャンなどです。

ただ、放置サイトをまず「見える化」する入口としては、無料枠でも十分に始められます。

ラインは破られる ── 指摘は大量に出る。でも驚かない

ただし、ディフェンスラインは破られます。

WordPressのリポジトリをつなぐと、プラグインやテーマのコードも丸ごとスキャン対象になります。すると、指摘が 大量に 出ます。

最初は面食らいます。

でも、驚かないでください。

多くは、プラグインやテーマの ベンダーが書いたコード、あるいは ビルド時だけに使う依存 です。本番では実行されないツール類が含まれていることもあります。

大事なのは、数で判断しないことです。

見る軸は2つです。

• 到達性：それは本番の実行経路に乗るのか
• 所有権：自分のコードか、ベンダーのコードか

ただし、ベンダーコードだから無視してよい、という話ではありません。ベンダーコードでも、実際に破られれば被害を受けるのは自分のサイトです。

指摘の数＝リスクではない。 でも、指摘を見ないこと＝リスク です。

数で慌てず、中身で判断する。これが大事です。

もう一つ、落とし穴があります。

更新すると、指摘がむしろ増えることがあります。

最新版のプラグインやテーマは、ソース一式や開発用依存を含んでいることがあります。そのため、静的スキャン上の指摘数は増えることがある。

これは必ずしも「リスクが増えた」という意味ではありません。 でも、「確認しなくてよい」という意味でもありません。

一度スキャンして終わりではない。 更新のたびに、継続して確認する必要があります。

抜かれたとき(カバー)：直せない穴は、上流へ通告する

検証の途中で、SASTがあるプラグインに実在の脆弱性を1件指摘しました。

誤検知ではありません。

ただし、これは自分では直せない。ベンダーのコードです。

ここでやるべきことは、勝手に書き換えることではありません。

• 勝手に直しても、次の更新で消える
• 本来の動作を壊す可能性がある
• 根本的には、開発元で修正されるべき

だから、カバーディフェンスとしてやるべきことは 開発元への通告 です。

修正前に詳細を公開せず、まず非公開で報告する。いわゆる責任ある開示です。

本記事では、対象プラグイン名、該当箇所、再現手順は一切開示しません。修正・調整がつくまで伏せるのが作法です。

ただし、通告しても、修正されるまでには時間があります。 その間も攻撃は来ます。

ラインも、カバーも、抜けてくる球がある。

だから最後の砦が必要になります。

最後の砦＝フルバック(面)：Zen

抜けてきた攻撃を、フィールド全体、つまり 面 で見て、実行時に止める。

それが Zen です。

Zenは、SQLインジェクション、コマンドインジェクション、パストラバーサル、SSRFなどを、アプリケーションの内側で検知・遮断します。

WordPressもDrupalも、PHPアプリケーションであれば対象になります。

つまり、すぐには直せないベンダーコードの穴も、実行時の最後尾で止めることができます。

今回のWordPressはDockerコンテナ内で動いているため、Zenは専用イメージに同梱しました。他サイトで使っている共有イメージには影響させず、このWordPressだけを対象にしています。

まずは 検知モード で様子を見る。 問題がなければ 遮断モード に切り替える。

この順番が安全です。

設置直後、Aikidoのダッシュボードには検証用の攻撃波が記録されました。

User-Agentは Aikido Zen Attack Wave Test。

これはAikidoが動作確認のために行う 自己テスト であり、実攻撃ではありません。

内容は、実際のbotによる偵察に近いものでした。/etc/passwd、/wp-config.php.old、.git 配下、各種シークレット探索、time-based SQLi などです。

結果はすべて404。つまり、これらは露出していませんでした。

そして、Zenはそれらをきちんと検知しました。

フルバックが、抜けてきた相手をちゃんと見ていた。 そういう状態です。

本番では、同じようなパターンの実攻撃を、ここで検知・遮断する役割を担います。

まとめ：無料枠で始める多層防御、最後はフルバック

ラグビーと同じです。

守りは一枚では足りません。 多層で守る必要があります。

• 第一線(線)：SCA / SAST / Secrets / ヘッダ監視 / 更新 / プラグイン選定
• 検証：指摘は大量に出る。数ではなく、到達性と所有権で見る
• カバー：直せないベンダーコードの穴は、勝手に直さず上流へ通告する
• 最後の砦(面)：抜けてきた攻撃を、Zenで実行時に検知・遮断する

フルバックのいないチームは、一度抜かれたら失点します。

WordPressやDrupalのように、プラグインやテーマを多用するCMSでは、前線だけでは守りきれません。

まずAikidoにつないで、見える化する。 指摘を一つ一つ確認する。 直せないものは上流へ通告する。 そして最後尾にZenを立てる。

放置サイトの守り方は、これで大きく変わります。

---

次回は「ファイルに現れない攻撃」について書きます。

クッキー型のPHP Webシェル。 GTM型のスキマー。

前線もカバーもすり抜けてくる球が、なぜ最後のフルバック(Zen)を必要とするのか。

その続きです。