WAFも国内IP制限もあるのに危ない!? WordPressの「別の入口」を調べた

レンタルサーバーのWAFは有効。SSLも導入済み。WordPressの管理画面には海外からログインできないよう設定した。

これだけ守っていれば、不正アクセスの心配はほとんどないと思いたくなる。

ところが、WordPress公式のセキュリティ資料を調べると、妙な事実が見えてきた。ログイン画面を厳重に守っていても、別の入口から攻撃される可能性があるのだ。

そもそも、サーバー会社がセキュリティ対策をしているのに、なぜ利用者まで守らなければならないのか？

調べてみると、サーバー会社の責任範囲、WordPressの認証機能、複数サイトの管理構造に、意外な落とし穴があった。

※WordPressの管理画面を厳重に守っても、別の認証経路や管理機能に対策が必要となることを示した概念画。実際のサーバー施設や侵入事件を描いたものではありません。

WAFは万能の警備員ではなかった

まず、レンタルサーバーが提供するWAF。これはWebサイトへの不正な通信を検知・遮断する仕組みで、WordPressへの攻撃を減らす重要な防御手段だ。

しかし、すべての攻撃を防げるわけではない。なお、SSL（HTTPS）は主に通信内容を保護するもので、WordPressの弱点そのものを修正する機能ではない。

例えば、古いプラグインに脆弱性が残っている場合。攻撃者がその欠陥を悪用できれば、管理画面へのログインを経ずに被害が生じる可能性がある。WAFが攻撃を検知する場合もあるが、必ず遮断できる保証はない。

さらに、WordPressだけでなく、サーバー管理画面や外部連携機能にも、それぞれ認証の入口がある。

攻撃される入口	必要になる主な対策
WordPressのログイン	二要素認証、強固なパスワード
プラグインの脆弱性	更新、不要なプラグインの削除、WAF
サーバー管理画面	管理画面専用の二要素認証
外部サービスとの連携	認証情報の管理、不要な連携の解除

この表は、WordPress公式とサーバー管理ソフトの公式資料を突き合わせ、主な入口と対策を整理したものだ。

気になるのは、WordPress 5.6から備わっているアプリケーションパスワードという機能。外部ツールが記事を投稿するなどの操作に使う認証情報で、通常の管理画面ログインとは別に機能する。

つまり、WordPressのログインを二要素認証で守っても、外部連携用の認証情報まで自動的に守られるわけではない。

また、サーバー管理画面の二要素認証も別設定だ。cPanel公式資料には、設定によってはAPI経由の操作に通常の二要素認証が適用されない場合があることまで説明されている。

海外IP制限も、国内経由なら通過する？

日本国内からしかWordPressを管理しないなら、海外IP制限には一定の効果が期待できる。

ただし、アクセス元のIPアドレスは、接続している人間の国籍や正体を証明するものではない。

攻撃者が日本国内のサーバーや中継回線を使えば、国内からの通信として扱われる可能性がある。

実際、WordPress公式の総当たり攻撃対策資料では、恒久的な国別ブロックリストへの依存を避け、二要素認証やログイン試行回数の制限などを組み合わせるよう案内している。

国内IP制限が無意味なのではない。侵入経路を減らす補助策であって、本人確認の代わりにはならないということだ。

別ドメインなのに共倒れ!? 4サイトで比較してみた

今回、最も気になったのは複数サイトの管理構造だった。

WordPress公式によれば、複数のWordPressを一つのデータベースに設置できる。その際、テーブル接頭辞を変えれば、それぞれのデータを区別できる。

しかし、この接頭辞はデータの整理番号のようなもの。アクセス権限を分ける仕組みではない。

仮に4サイトが同じデータベースと同じDBユーザーを使い、そのユーザーに全テーブルへの権限がある場合、認証情報が漏れると4サイト分のデータにアクセスできる可能性がある。

4サイトの構成例	1組のDB認証情報がアクセスできる範囲
全サイトでDBユーザーを共有	全テーブルへの権限があれば最大4サイト分
サイトごとにDBとDBユーザーを分離	権限が適切に限定されていれば原則1サイト分

これは同一権限で全テーブルを扱える場合の仮定に基づく比較であり、侵入確率や実際の被害件数を示したものではない。

なお、同じデータベースでもDBユーザーをサイトごとに分け、権限を限定することは可能だ。問題はデータベースが同じことだけではなく、認証情報と権限をどこまで共有しているかにある。

しかも、データベースを分離しても、同じサーバーアカウントで各サイトのファイルを読み書きできるなら、別の問題が残る。

ドメインが別でも、データベースとファイルの権限まで分かれているとは限らない。

WordPress公式も、複数サイトでは異なるデータベースとDBユーザーを利用することを、被害拡大を抑える対策として案内している。

※4つの独立したWordPressサイトが1つのデータベースを共有する構造の概念図。実際の設置形態ではありません。同じDBでも、サイトごとにDBユーザーとアクセス権限を分けることは可能です。

バックアップは週1回で十分？ 失う記事数を計算した

最後に、サーバー会社任せにしがちなバックアップについても計算してみた。

仮に毎日2本の記事を公開し、一定間隔でバックアップを取得するサイトがあるとする。バックアップが正常に保存され、その直後から次の保存直前までに追加した記事を復元できない場合、失う可能性のある記事数は次のようになる。

バックアップ間隔	最大損失記事数の目安
毎日	2本
3日に1回	6本
7日に1回	14本

単純計算では、週1回のバックアップは毎日保存する場合に比べて、最大損失記事数が7倍になる。

これは毎日2本という仮定での試算。実際の損失は公開時刻、障害発生時刻、保存状態などによって変わる。

さらにWordPressのバックアップには、記事などを保存するデータベースと、画像・プラグインなどのファイルの両方が必要になる。

サーバー会社の自動バックアップがあっても、保存期間や復元範囲は契約次第。別の保存先にもバックアップを確保し、復元できるか確認しておくことが大切だ。

結局、利用者は何を確認すればいい？

最初に確認したいのは、WordPressとサーバー管理画面の二要素認証、使っていない管理者アカウントや外部連携の整理、プラグインの更新状況だ。なお、WordPress本体には標準の二要素認証機能がないため、適切なプラグインなどで導入する必要がある。

複数サイトを運営する場合は、サーバー会社に「サイト間のファイルアクセス権限は分離されているか」「別々のDBユーザーを設定できるか」と確認するとよい。

サーバー会社が守るのは主に提供する基盤部分。利用者が導入したWordPressや、その認証情報まで、すべて自動的に守られるわけではない。

反対に、共用サーバー自体の隔離や基盤ソフトウェアの安全性など、利用者だけでは管理できない部分も存在する。

【編集者が思うこと】

俺は最初、WAFも海外IP制限も設定したなら、かなり安心できると思っていた。

ところが調べてみると、WordPressのログインだけでなく、サーバー管理画面や外部連携、さらには同じサーバーに置いた別サイトまで、確認する場所がいくつもある。

特に妙だと思ったのは、ドメインが別なら独立したサイトに見えるのに、裏側では同じデータベースを使っている場合があることだ。

表札が4つあっても、裏口の鍵が共通だったら、そりゃ気になるだろう。

もちろん、サーバー会社に任せるべき仕事まで利用者が背負う必要はない。しかし、どこまで守ってもらえるのかは知っておくべきだと思う。

結局、セキュリティ対策をいくつ導入したかより、どの入口を、誰が守っているのか。 そこなんだよな。

ちょっと分かりにくい用語

参考資料