PR

WordPress失敗談|SiteGuardでユーザー名が丸見えに…プラグイン不要の本当のセキュリティ対策とは

WordPress失敗談|SiteGuardを入れても無意味?ユーザー名が丸見えだった私の遠回りと、プラグイン不要の本当の対策 ブログ
このサイトはアフィリエイト広告(Amazonアソシエイト含む)を掲載しています。

皆さん、こんにちは!てつやです。

定年を機に始めたこのブログ。日々パソコンと向き合い、少しずつですが新しいことができるようになるのが嬉しい毎日です。

さて、この記事を読んでくださっている皆さんに、一つ質問です。
「あなたのWordPressブログ、セキュリティ対策は万全ですか?」

おそらく多くの方が、何かしらのセキュリティプラグインを導入されていることでしょう。「人気の『SiteGuard WP Plugin』を入れているから大丈夫!」…そう安心しきってはいませんか?

実を言うと、少し前の私がまさにその状態でした。ブログ開設時に参考にしたサイトの教え通りにSiteGuardを導入し、基本的な対策は万全だと思い込んでいたのです。

しかし、その自信は、ほんの些細なブログのカスタマイズをきっかけに、もろくも崩れ去ることになります。

この記事は、私が自分のサイトの脆弱性に気づき、慌てて対策したものの、実はもっとシンプルで正しい方法が最初から用意されていた…という、なんともお恥ずかしい、私の遠回りな失敗談です。

もしかしたら、あなたのサイトも同じ「思い込みの罠」に陥っているかもしれません。ぜひ、私の失敗談に最後までお付き合いいただき、ご自身のサイトは大丈夫か、一緒に確認していきましょう。

【危険】URLに「/?author=1」でユーザー名が漏洩する脆弱性

その日は、いつもと変わらない穏やかな一日でした。 「この投稿者のページ(投稿者の作成した記事が一覧表示されるページ)、もう少し見栄えを良くできないかな」 そんな軽い気持ちで、いつものように情報収集を始めたのがすべての始まりでした。

「WordPress 投稿者のページ カスタマイズ」…そんなキーワードで検索し、いくつかのサイトを眺めていた時、ある一文が私の目に飛び込んできました。

「WordPressはURLの末尾に『/?author=1』と入力するだけで、簡単にユーザー名が分かってしまう」

…え? まさか。

私の頭の中は一瞬で疑問符でいっぱいになりました。だって、私のサイトにはあの「SiteGuard」が入っている。多くの専門家が推奨する、鉄壁の守りのはず。ユーザー名が漏れるなんて、そんな初歩的な脆弱性が見過ごされているわけがない…。

半信半疑のまま、私は自分のブログのURLをブラウザのアドレスバーに打ち込み、その後ろに恐る恐る「/?author=1」と付け加えて、エンターキーを押しました。

次の瞬間、アドレスバーの表示が切り替わります。

…見事に、私のログイン用ユーザー名を含んだURLにリダイレクトされているではありませんか!

サーッと血の気が引いていくのが分かりました。万全だと思っていた家の玄関のドアに、住所氏名を書いた表札がデカデカと掲げられていたようなものです。これでは、悪意のある攻撃者に対して「どうぞ、このユーザー名でパスワード攻撃を仕掛けてください」と言っているようなものです。いわゆるブルートフォースアタック(総当たり攻撃)の格好の的となってしまいます。これは、考えられるパスワードの組み合わせを、ツールなどを使って片っ端から試していく非常に原始的ですが強力な攻撃方法です。

なぜ?

なぜSiteGuardが機能していないんだ…?
頭が真っ白になりながらも、私の心には大きな疑問が渦巻き始めました。

応急処置で「Edit Author Slug」プラグインを導入

理由を解明したい気持ちは山々でしたが、それよりもまず優先すべきことがあります。 「とにかく、今すぐこの穴を塞がなければ!」

原因の追求は後回しです。家が丸裸の状態であることに気づいた以上、一刻も早くシャッターを下ろさなければなりません。私は再び検索エンジンに向き合いました。

「WordPress ユーザー名 漏洩 対策」

焦る気持ちで情報を探すうち、一つの解決策にたどり着きました。それは「Edit Author Slug」というプラグインを導入する方法です。このプラグインを使えば、投稿者ページのURL(author/ の後ろの部分)を、ユーザー名とは全く別の文字列に書き換えられるとのこと。これなら、たとえリダイレクトされても本当のユーザー名は分かりません。

「これだ!」

私はすぐさまプラグインをインストールし、設定画面で管理アカウント名とは別のニックネームへ変更しました。そして、祈るような気持ちで、再度自分のサイトのURLに「/?author=1」を付けてアクセスします。

今度は、スラッグとして指定したニックネームが表示されるように変わりました。

「ふぅ…、やった…。これで一安心だ…」

大きく息をつき、胸をなでおろしました。原因は分からないままでしたが、ひとまず目の前の火事は消し止めることができた。この時点では、私はこの「Edit Author Slug」がベストな対策だと信じて疑いませんでした。

原因はSiteGuardの設定ミス!『ユーザー名漏えい防御』を有効化しよう

応急処置を終え、いったんは安堵したものの、私の心の中では、あの疑問がずっとくすぶっていました。

「なぜ、最初から入れていたSiteGuardは機能しなかったのだろうか?」

あれほど多くのサイトで推奨されているプラグインが、こんな基本的なセキュリティホールを見過ごすはずがない。何か、私が見落としている決定的なことがあるに違いない…。

その答えを見つけるため、私はWordPressの管理画面に戻り、左側のメニューから「SiteGuard」を選び、その設定画面を、今度は隅から隅まで、一項目ずつじっくりと見直してみることにしました。

WAFチューニング、ログインページ変更、画像認証…。見慣れた項目が並びます。そして、いくつかの項目をスクロールした、その時でした。

「ログインページセキュリティ」というセクションの中に、その文字列はひっそりと、しかしハッキリと存在していたのです。

「ユーザー名漏えい防御」

…あった。まさに、私が探し求めていた機能そのものではありませんか。

そして、その機能名の横に目をやった私は、言葉を失いました。そこには、今回の物語の最大の「オチ」が待っていたのです。

その機能の初期設定は… 「無効」。

SiteGuardのユーザー名漏えい防御機能が無効になっている設定画面のスクリーンショット
SiteGuardのユーザー名漏えい防御機能が無効になっている設定画面のスクリーンショット

全身から力が抜けていくような、強烈な脱力感に襲われました。犯人は、外部の侵入者でも、プラグインの不具合でもありませんでした。ただただ、備わっていた機能を自分で有効にしていなかっただけだったのです。灯台下暗しとは、まさにこのこと。安心しきっていた守護神(SiteGuard)に強力な武器(ユーザー名漏えい防御機能)が備わっていたにも関わらず、そのスイッチを入れ忘れていたのは、他の誰でもない、この私自身だったのです。

しかし、そこで新たな疑問が湧きました。「なぜ、こんなに重要な機能が初期設定で「無効」になっているのだろう?」と。

これも調べてみて、私は深く納得しました。それには、「互換性への配慮」「多層防御」という、プラグイン開発者の賢明な判断があったのです。

お城の防御に例えるなら、こうです。

  • SiteGuardのログインロック機能:
    非常に屈強な「門番」。怪しい者が何度も門を叩くと門を固く閉ざし、侵入を許さない。
  • ユーザー名漏えい防御機能:
    お城の「場所」そのものを地図から消し、敵に見つかりにくくする。

私のサイトは、「門番」が非常に優秀だったので、お城の場所(ユーザー名)がバレていても、攻撃者の侵入を許さずに撃退してくれていました。これが、攻撃履歴だけが残っていた理由です。

ではなぜ「場所を隠す機能」が最初から有効でないのか。それは、テーマや他のプラグインの中には、お城の場所(/author/ユーザー名というURL)が分かっていることを前提に作られているものがあるからです。もしSiteGuardが勝手に場所を隠してしまうと、それらのテーマやプラグインが道に迷ってしまい、サイト全体の表示が崩れるなどの不具合を起こしかねません。

つまり、この初期設定は単なる「不親切」や「ミス」ではなく、「どんな環境でもサイトが壊れないように」という、開発者の深い配慮と、安全性を最優先する賢明な判断の結果だったのです。この事実に気づいた時、私は自分の確認不足を恥じると同時に、WordPressというシステムの奥深さに改めて感心させられました。

プラグイン不要!SiteGuardだけで完結する正しい設定手順

このなんとも締まらない事実に気づいたことで、新たな疑問が湧いてきました。 「今、私のサイトには『SiteGuard』と、応急処置で入れた『Edit Author Slug』の両方が入っている。これって、両方とも必要なんだろうか?」

少し調べてみると、答えはすぐに見つかりました。同じ目的の機能を持つプラグインを複数入れることは、不要であるばかりか、時に干渉しあって不具合の原因になることもあるとのこと。そして、サイトの表示速度や管理のしやすさを考えても、プラグインは少ない方がシンプルで良い、というのが一般的な考え方のようです。

では、どちらを選ぶべきか。 答えは明白でした。「Edit Author Slug」はユーザー名の漏洩を防ぐ一点に特化したプラグインですが、「SiteGuard」はログイン周りをはじめ、総合的なセキュリティを一つのプラグインで管理できます。ならば、SiteGuardに備わっている機能をきちんと有効にして使うのが、最もスマートで本来あるべき姿です。

私は、自分の遠回りを正すため、以下の手順で最終的な設定に落ち着かせました。

ステップ1. 応急処置で入れた「Edit Author Slug」を停止・削除する
まず、管理画面の「プラグイン」一覧から「Edit Author Slug」を「停止」し、その後「削除」しました。お世話になりました。

ステップ2. 「SiteGuard WP Plugin」の設定で「ユーザー名漏えい防御」を有効にする
次に、本丸であるSiteGuardの設定画面を開きます。「ログインページセキュリティ」のタブを選び、先日「無効」になっているのを発見した「ユーザー名漏えい防御」の項目を「有効」に変更します。そして、最も大切なのが、ページ下部の「変更を保存」を忘れずにクリックすること。これを忘れると、せっかくの設定が反映されませんのでご注意ください。

SiteGuardのユーザー名漏えい防御機能を有効に変更した後の設定画面のスクリーンショット
SiteGuardのユーザー名漏えい防御機能を有効に変更した後の設定画面のスクリーンショット

3. 最後に、再度確認作業を行う
念には念を入れ、ブラウザから「/?author=1」でアクセスします。結果は、問題なくトップページが表示され、ユーザー名が漏洩しないことを確認できました。これで、本当に正しい形での対策が完了です。

まとめ:この失敗談から学んだ、たった一つの重要なこと

ユーザー名が丸見えであることに気づいて血の気が引き、慌てて別のプラグインで応急処置をし、結局は最初から入れていたプラグインの設定一つで解決した…。

今回の私の遠回りな経験から得た、たった一つの、しかし最も重要な教訓。

それは、「プラグインは、インストールして有効化したら終わり、ではない」ということです。

特にセキュリティのようにブログの心臓部を守るプラグインは、必ず一度は設定画面の隅々まで自分の目で確認し、その機能と設定を正しく理解する。これこそが、本当の意味での「対策」なのだと痛感しました。

特に、セキュリティのような重要な役割を担うプラグインはなおさらです。

「人気のプラグインだから」「解説サイトでおすすめされていたから」という理由だけで安心せず、ぜひこの機会に、コーヒーでも飲みながら、ご自身のサイトに入っているプラグインの設定画面を一度じっくりと見直してみてください。もしかしたら、まだ使っていない便利な機能や、今回のような思わぬ設定の「見落とし」が発見できるかもしれません。

私のなんともお恥ずかしい失敗談が、あなたの愛するブログをより安全にする、何かのきっかけになれば、これほど嬉しいことはありません。

「やってみたい!」と思ったその気持ちが、すでに第一歩です。
私も最初は右も左も分からず手探りでしたが、初心者にも分かりやすい管理画面と、手厚いサポートがあったConoHa WINGのおかげでスムーズにスタートできました。セキュリティがしっかりしたサーバーを選ぶことも重要な対策の一つです。初心者でも安心のConoHa WINGで、安全なブログ運営を始めませんか?

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

プロフィール
この記事を書いた人
てつや

今年3月に定年を迎えました60代です。これからの人生を「やってみた!」の一言で埋め尽くしていこうと、小さな一歩を踏み出したところです。長年仕事に追われて先送りしていた興味や関心ごとを、少しずつ形にしていけたらと思っています。

SNSもブログも初挑戦。見よう見まねではありますが、日々の気づきや試みを綴っています。よろしければ、のぞいてみてください。【Update:2025/5】

てつやをフォローする
ブログ
シェアする
てつやをフォローする

コメント

タイトルとURLをコピーしました