サーバー・WordPressセキュリティ強化

2026年11月12日日記

あなたのWEBサイトは大丈夫？セキュリティ対策 https://twitter.com/takaichi_sanae/status/2112890642590564386 内閣総理大臣が、PHPという特定のプログラム言語を名指して指摘し、セキュリティ対策を行うよう注意喚起がありました。PHPについては私はバージョン4のころから付き合って戦ってきました。たびたび致命的な欠陥（バグ）によってバージョンが上がってきたPHPですが、ここにきて各国首脳が呼びかけを行うほどの問題になりました。それも、インターネットWEBサイトの7割ほどがPHPで作られており、またおそらく世界シェアNo1のCMSがWordPressということもあり、全滅するレベルの問題になったのだと考えられます。詳しいことはわかりませんが、先般起きたGMOインターネットのサービスであるお名前.comのVPSサービスがいわゆるクラッキング（不正アクセス）された問題がこのPHPに起因するのか否かはわかりませんが、不正アクセス事案がかなり増えているのは間違いありません。何にせよ、PHPについて、そして、サーバー自身のセキュリティについて、自らが認識し、対応を行う必要があると考えます。 VPS～仮想専用サーバー～に大きな問題私は以前はVPSを提供する側、要はホスティング事業者を営んでいた経験があります。そのうえで、利用者側の立場に立って、VPSサービスについて、大きな問題がはらんでいると、かねてより考えていました。それは、何よりも【サービスはサーバーが立ち上がった状態から始まる】ことで、とりあえず使いたいものがすでに導入済みなので、専用サーバーを契約したり自前でサーバーを用意するよりも、目的達成が容易で手早く手軽にサービスを立ち上げられることです。もちろん、大きなメリットでもあるのですがセキュリティ面ではこの容易さが大きなデメリットであろうと考えていました。 VPSサーバー自身のファイアウォールは自分で設定する必要があるって知っていましたか？ここを勘違いされる方が多いと思っています。ごく一般的なレンタルサーバーであれば、貸すのはWEBサーバーのスペースのみであり、サーバー業者が設定している言語（たとえばPHPであったりPerl、cgiであったり）やDBは使えますが、細かいバージョンを指定したりドキュメントルートを細かく修正したりするのは難しいものになります。その代わり、ファイアウォールや、言語の脆弱性対策などはサーバー業者にお任せとなります。こちらであればある程度のセキュリティについては業者の責任で行ってくれます。ただし、自分だけ特定のポートを空けてほしいなどの要望は聞いてもらえません。VPSというのはVirtualPrivateServerで、仮想専用サーバーなのです。なので、root権限がユーザに付与されていて、一つのサーバー（ディストリビューション）を独占する形になります。簡単に言えばディストリビューションのインストールまでは、業者が行ってくれることが多いですが、そこから先は契約者にお任せです。なので、当然セキュリティ関係の設定も契約者が行う必要があります。お名前.comの事案は基本的にはWindowsServerの仮想サーバーがクラッキングされたそうで、Linuxのそれとは違いますが、ハッキングされた根本的な要因は同じように感じます。リモートデスクトップ接続の際に、クライアント側のHDDが共有が掛かるようにデフォルト設定されていたそうですが、自分で意識的に、設定を変更できたのではないかと思います。また更に、RDPは、非常に弱いので、何かしらのセキュリティ対策を行うのが通常です。私は、まず、リモートデスクトップ自身をファイアウォールで遮断します。ただし、内部からは接続できるようにしたうえで、外からのファイアウォールを閉じておきます。そして、SSHサーバーを導入し、鍵認証をのみ設定した状態にします。SSHで接続したうえで、ポートフォワーディングをかけて中からのみ接続可能になるようにしました。最低限このくらいはしないと、リモートデスクトップはやはり怖いですね。今の時代に、パスワード認証のみはやはり少々危険な気がします。 Linuxの場合は、はるか昔はtelnetというターミナル接続がありましたが、こちらもリモートデスクトップ同様、パスワード認証のみでした。そこで、Linuxは、SSHというターミナル接続に移行し、セキュリティ的な制限としては、パスワード認証をやめて鍵認証のみにするや、指定したIPアドレスのみ接続を許可するなどの設定があります。一般的には鍵認証をONにするのがマストだと思います。可能ならIPを制限して、自分だけが接続できるようにするのがよろしいかと思います。さらには私は、ファイアウォールでSSHを普段は遮断しておきます。PleskにログインしてFireWallで開く作業が必要になります。しかし、こうすると、Pleskにすべてが集約されますので、Pleskがハックされてログインされてしまうと、終わります。考えうるセキュリティ強固な認証～段階認証を設定する～ Pleskも当初の設定では、パスワード認証のみですが、オプションで二段階認証のプラグインがありますので、それを設定します。そうすることで、Googleの認証アプリなどと連携して二段階認証をONにすることができます。Pleskは、LinuxWEBサーバー・メールサーバーの運用をGUI画面を介して管理ができるコントロールパネルなのですが、逆の言い方をすれば、ログインされてしまうと、容易に操作できてしまう危険なものです。なので、不正にログインされることがあるとほぼそのサーバーは乗っ取られたに等しいレベルです。そのようなコントロールパネルがパスワード認証のみであるとした場合、SSHなどのセキュリティを強固にしたところでほとんど意味がないといっても過言ではないです。接続可能なIPアドレスに制限を掛けるなどの施策が有効ではあるのですが、この種のコントロールパネルは、エンドユーザが使えるようにすることが一般的で、IP制限を掛けにくい面があります。今回二段階認証を導入したことで、少なくとも、２段階認証コードを受け取ることができる人しかログインできなくなりますので、セキュリティ面は大幅に向上します。もはや最低限必要な認証となったと思います。 WordPressにも二段階認証を採用このサイトもそうですし、ほかのWordPressを利用しているWEBサイトにも二段階認証のプラグインを導入し採用しました。元々、SiteGuard WP Pluginを導入し、画像認証を採用したりしていましたが、最近のAIは、画像の中の文字も読み取りますし、ひらがななど英数字以外も認識できますので、確実な安全を確保できているとは言えないと思っていました。そのうえで、画像認証プラス二段階認証とし、WordPressについては登録されているメールアドレスに、認証コードを送付する仕組みを採用しました。これにて、WEBサイト自身が不正アクセスを受けることで乗っ取られるケースは激減すると考えられます。多段階認証を設定したからといってすべてを防げるわけではない！大事なのは、セキュリティを強化すればそれなりに不正アクセスを防ぐことはできます。ただし、100％、すべてを防ぐことができるわけで張りません。今回問題になったPHPの脆弱性については、ログインなしで不正操作ができてしまうという問題でした(PHP2shell)。簡単に言えば、正規のログインルートをたどらずに、管理者IDとパスワードにまでたどり着くことができて、その後は正規のルートから接続して、情報を抜き出せてしまう可能性があったということです。この問題を残したまま、二段階認証などを掛けたところで、意味はなかったということになります。何を言いたいかといいますと、すべてが完ぺきにできるのかというとそういうことはなく、提供側の問題があって、すべてのセキュリティ対策が意味のなさないものになることもあるということです。だから、やらなくていいということではなく、やれる限りの対策をしたうえで、今回のPHPの問題のようなことがあった場合に、いち早く情報を仕入れて、可能な対策を打つ必要があるということを忘れてはいけないということです。今回の対応は早かった？私の対応今回私（私のお客様も含めて）は、それなりに早かったと思っています。高市総理の発表の前にPHPの問題があることは把握していました。その時点でPHPの修正パッチが出ていませんでしたので、一旦はその問題を回避するために、WEBサーバーをいったん落としました。共有サーバーを利用されているお客様については、htaccessなどで接続できないようにするくらいしかできませんでしたが一旦はWEBサイトを止める対応に出ました。そのうえでDBに顧客情報などがあるECサイトなどはDBのデータをバックアップし、DBのデータをいったん空にする対応を取りました。そうしているうちにPleskは、PHPの対応パッチを素早くリリースしてくれましたので、即座にパッチを当てて対応。Plesk導入サーバーについてはこれによってPHPの問題は解決したものになっていて、順次WEBサイトを再開、WordPress導入サイトオーナーには、MFAプラグインの導入を進めさせてもらいました。共有サーバー業者も順次対応を進めており、対応完了後に各サイトを再開しました。高市総理からの発表があった直後くらいには私のお客様の対応はすべて完了しておりました。のっとり事案、情報漏洩事案は0件で済みました。今回は、情報が明るみになってから対応までに約1日程度でできましたが、ものによってはこれが数日～数週間かかるかのせいもあります。インターネット上におけるリスクと認識し、仕様の際にはそのような問題があるかもしれないので突如としてWEBサイトが動かなくなったり、メールが使えなくなったりする可能性があることをエンドユーザ、また、そのエンドユーザの従業員さんなどに常日頃から告知・周知をしておくことで混乱が軽減されると思います。皆様は今回の事案はどのような対応で切り抜けましたか？続きを読む