個人の小さなブログでも、SiteGuard WP Pluginは入れておく価値がありました。先に要点だけまとめておきます。
- 必要な理由: ログインページ(
wp-login.php)は場所が決まっていて、自動の総当たり攻撃の標的になりやすい - 有効にした機能: 画像認証、ログインロック、ログイン通知、XML-RPCの防御
- 最初は見送った機能: ログインURLの変更。変更後のURLを忘れると、自分がログインできなくなる
- ローカル環境には入れていない。公開されていないので攻撃を受けず、ログインの手間だけが増える
備えは早いに越したことありません。本番サーバーを公開してすぐ、セキュリティプラグイン「SiteGuard WP Plugin」を導入しました。個人の小さなブログに大げさかとも思ったのですが、実際に調べてみると入れない理由の方が少なかったので、導入した理由と設定内容をまとめます。
🎥 この記事の内容は動画でも解説しています。
SiteGuard WP Pluginは個人ブログにも必要か
理由は単純です。WordPressは世界的にシェアの高いCMSなので、その分「WordPressを狙った」自動攻撃も多いと言われています。個人の小さなブログだから狙われないだろう、と考えるのは楽観的すぎると感じました。油断は禁物です。特にログインページ(wp-login.php)は場所が固定で分かりやすいため、ブルートフォース攻撃(パスワードを総当たりで試す攻撃)の標的になりやすい部分です。公開直後、アクセスがまだ少ない段階だからこそ、被害が出る前に対策しておく方が結局は手間が少ないと考えました。
他の選択肢も検討した
決め手は情報量でした。セキュリティプラグインはSiteGuard以外にも、Wordfenceのような多機能なファイアウォール系プラグインなど選択肢がいくつかあります。今回SiteGuardを選んだのは、日本語での情報が豊富で、国内のレンタルサーバー環境(特にXserverのような環境)での動作実績や設定例が見つけやすかったためです。多機能すぎるプラグインは、設定項目が多い分、逆にどこまで有効化すればいいのか判断に迷うこともあります。個人ブログの規模であれば、必要な機能に絞って提供してくれるプラグインの方が扱いやすいと感じました。
SiteGuardでできること
- ログイン試行のたびに画像認証(ひらがな入力)を要求し、機械的な総当たり攻撃を防ぐ
- 一定回数ログインに失敗すると、一時的にログインをロックする(フェールワイヤー)
- 管理者にログインがあった際、メールで通知する
- コアやプラグイン・テーマの更新情報を通知する
- XML-RPCへの攻撃を防御する
効果は明確です。WordPress標準の管理画面だけでは用意されていない、こうした「攻撃を受けにくくするための仕組み」をまとめて導入できるのが大きなメリットです。
ローカル環境には入れなかった理由
答えは明快でした。このプラグインは本番環境にだけ導入し、ローカルのMAMP環境には入れていません。ローカルはそもそもインターネットに公開されていないので、ブルートフォース攻撃やXML-RPC攻撃といったリスクが実質的に存在しないからです。逆に、ログインURLの変更や画像認証は、開発中に何度もログインし直す作業の邪魔になってしまいます。セキュリティ系のプラグインは、環境ごとに必要性が違うという当たり前のことを、実際に運用してみて改めて意識しました。
WAF(Webアプリケーションファイアウォール)との住み分け
役割は別物です。Xserver自体にもサーバーレベルのWAFが標準で用意されており、SQLインジェクションなど典型的な攻撃パターンはサーバー側である程度防御されています。心強い限りです。SiteGuardはこれと役割が重複しているわけではなく、あくまでWordPressアプリケーション寄りの防御(ログイン試行・XML-RPCなど)を担当するものだと理解しています。サーバー側の防御とアプリケーション側の防御は層が違うので、片方があるからもう片方は不要、とは考えず、両方をそのまま活かす方針にしました。
設定で気をつけたこと: ログインできなくなる事故を避ける
あえて見送りました。初期状態では、ログインURL自体を変更する機能も用意されていましたが、今回はあえて有効化しませんでした。URLを変更すること自体は有効な対策ですが、変更後のURLを忘れると自分がログインできなくなるリスクがあり、まだ運用に慣れていない段階では事故につながりやすいと判断したためです。画像認証やログイン通知など、URLを変えなくても効果のある機能から先に有効化し、運用に慣れてきたら段階的に強化していく方針にしています。安全策です。
効果は思わぬところにありました。ログイン通知メールについては、先に構築していたSMTP経由のメール送信の仕組みがそのまま使えたので、追加設定なしですぐに届くようになりました。以前の記事で書いたメール送信周りの整備が、こんなところでも地味に効いてきました。地道な備えは裏切りません。
導入してみて感じたこと
杞憂でした。実際に運用を始めてみると、SiteGuard自体の存在を意識する場面はほとんどありません。普段通りにログインしていれば、画像認証の一手間が増えるだけで、それ以外は特に何も変わりません。逆に言えば、「普段は意識しないけれど、いざという時に守ってくれる」というのが、セキュリティ対策のあるべき姿だと思います。派手な機能ではありませんが、公開したばかりの個人サイトでは真っ先に入れておいて損はないプラグインだと感じています。
反応は正直でした。ログイン通知メールが実際に届いたときは、少し身構えました。自分がログインしただけなのに「不正アクセスかもしれない」と一瞬ドキッとするくらいには効果を実感できています。裏を返せば、それだけ普段は意識していなかった領域を、プラグインが代わりに見張ってくれているということでもあります。
ここからは微調整です。今後、ブログのアクセス数が増えてきたら、フェールワイヤーの閾値やロック時間なども見直していくつもりです。最初から完璧な設定を目指すのではなく、運用状況に応じて少しずつチューニングしていく、という姿勢でセキュリティ対策とも付き合っていきたいと思っています。
まとめ
判断は正解でした。個人ブログだからとセキュリティ対策を後回しにせず、公開のタイミングでまとめて設定しておいたのは良い判断だったと思います。特にログイン周りの防御は、被害が出てからでは遅い部類の対策なので、アクセスが少ないうちに済ませておくのがおすすめです。
続きがあります。なお、このとき「あえてオフのままにした」設定については、後日あらためて見直すことになりました(SiteGuardの「あえてオフにしてた」設定、結局オンにした話)。
