シリーズ「公開したその後 〜運用と改善のノート〜」の第5回です。前回はスパム対策について書きました。今回はログインまわりのセキュリティです。
正直なところ、この回は「すでに設定してあることの確認」で終わるだろうと思っていました。サイトを作ったときにセキュリティ用のプラグインを入れていたからです。
ところが、記録を開いてみたら話がまったく違いました。
ログイン履歴を見たら、3,967件ありました
使っているのは SiteGuard WP Plugin という無料のプラグインです。管理画面に「ログイン履歴」という項目があり、いつ・どこから・誰の名前で・成功したか失敗したかがすべて記録されています。
開いたら、3,967件ありました。
内訳はこうです。
- 自分のログイン成功: 十数件
- それ以外のほぼすべて: 外部からのログイン試行を「ロック」した記録
分かったことを並べます。
- 攻撃が集中したのはサイト公開の翌日から数日間
- 接続元は
79.127.129.◯◯◯のように同じレンジのIPアドレスに集中 - 1秒間に複数回という速度で、機械的に繰り返されている
念のため先に書いておくと、被害はありませんでした。 有効になっていた機能がすべて止めていたからです。ただ、止まっていたという事実と、狙われていなかったという話はまったく別です。
前回のスパム記事でも書きましたが、相手はサイトの中身を見ていません。「うちみたいな小さいブログは狙われない」は成立しないということが、自分の記録で確認できてしまいました。
第3回でアクセス解析を見たときは、検索から来た読者がほぼゼロでした。読者は来ていないのに、攻撃だけは毎日来ていたことになります。
攻撃はXML-RPCという入口から来ていた
記録の「タイプ」欄を見ると、ほとんどが XML-RPC となっていました。
XML-RPCは、WordPressを外部のアプリから操作するための入口です。スマホアプリから記事を投稿したり、他のサービスと連携したりするために用意されています。
この入口が狙われやすいのには理由があります。
- ログイン画面と違い、画像認証などの人間向けの仕掛けを置きにくい
- 仕様上、1回の通信で複数のIDとパスワードを試せる場合がある
- そもそも使っていない人が多く、閉じられていないまま放置されやすい
SiteGuardには「XML-RPC 防御」という機能があり、これは有効になっていました。おかげで試行はすべてロックされていました。
外部アプリからWordPressを操作する予定がないなら、この機能は有効にしておいて問題ありません。
一番まずかったのは、ユーザー名が割れていたこと
件数よりも気になったのは、記録に残っていたユーザー名でした。
この種の攻撃では、admin や test といったよくある名前が当てずっぽうで試されるのが普通です。ところが履歴に並んでいたのは、このサイトの実際のログインユーザー名でした。すべて正確に一致しています。
つまり、こういう状態でした。
ユーザー名はすでに相手に知られていて、残る壁はパスワードだけ。
ログインは「ユーザー名」と「パスワード」の2つで守るものです。その片方が最初から渡っていたことになります。
なぜ知られたのか。WordPressは初期状態のままだと、ユーザー名が外から取得できてしまうからです。攻撃側が特別なことをしたわけではありません。
SiteGuardの設定を見たら、3つが無効だった
ここで設定画面を開いて、ようやく状況が分かりました。SiteGuardには10個ほどの機能があり、そのうち3つが無効のままでした。
| 機能 | 状態 | 何をするか |
|---|---|---|
| ログインページ変更 | 有効 | ログイン画面のURLを変える |
| 画像認証 | 有効 | ログイン・コメントに文字入力を追加 |
| ログイン詳細エラーメッセージの無効化 | 有効 | 「パスワードが違う」等のヒントを出さない |
| ログインロック | 有効 | 失敗を繰り返す接続元を一定時間ブロック |
| ログインアラート | 有効 | ログインがあったらメールで通知 |
| XML-RPC 防御 | 有効 | 外部連携の入口を塞ぐ |
| 更新通知 | 有効 | 本体・プラグインの更新をメールで通知 |
| ユーザー名漏えい防御 | 無効 | ユーザー名が外から取れないようにする |
| 管理ページアクセス制限 | 無効 | 未ログインの接続元から管理画面を隠す |
| フェールワンス | 無効 | 正しい入力でも1回だけ失敗させる |
無効の3つのうち、今回の件に直結していたのが「ユーザー名漏えい防御」です。これを有効にすれば解決する——そう思って、オンにしました。
有効にしただけでは、穴は塞がらなかった
オンにしたあと、ログアウトした状態で本当に見えなくなったかを確認しました。前回の記事で「設定しただけでは効いているとは言えない」と書いた手前、確かめないわけにはいきません。
結果、ユーザー名が外から見える経路は3つあり、塞がったのは1つだけでした。
| 経路 | 機能をオンにしただけ |
|---|---|
/?author=1 のようなURL |
塞がった |
| REST APIのユーザー一覧 | そのまま見えていた |
| 著者アーカイブのURL | そのまま見えていた |
それぞれ説明します。
REST APIは、WordPressのデータを外部から読み書きするための仕組みです。ここにはユーザー一覧を返す窓口があり、アクセスするとユーザー名がそのままテキストで返ってきます。プラグインの機能をオンにしただけでは、ここは止まりませんでした。
著者アーカイブはもっと単純です。WordPressは既定で、ログインユーザー名をそのままURLに使います。/author/○○○/ の ○○○ の部分が、そのままログイン名なのです。URLそのものが答えになっている状態で、これはプラグインの設定では直りません。
さらに、記事に表示される著者名も初期状態ではログイン名と同じでした。記事を開けば誰でも見える場所に書いてあったわけです。
ユーザー名の露出を止める3つの対処
3つの経路に対して、3つの対処が必要でした。すべて無料でできます。
① ユーザー名漏えい防御を有効にする
SiteGuard → ユーザー名漏えい防御 で「有効」を選んで保存します。これで /?author=1 のようなURLからは取得できなくなります。
② 同じ画面の「REST API 無効化」もオンにする
同じ設定画面にオプションとして用意されています。これをオンにすると、ログインしていない相手からのREST APIアクセスが止まります。
ただし除外リストの設定に注意してください。REST APIは他の機能も使っています。除外欄に contact-form-7 のようなプラグイン名を残しておかないと、お問い合わせフォームが動かなくなる可能性があります。
設定したあとは、必ず自分でフォームからテスト送信して、受信まで確認してください。
③ 投稿者スラッグと表示名を変える
これが一番見落としやすいところです。ログインユーザー名は変えずに、外に出る名前だけを変えます。
| 項目 | 変更前 | 変更後の考え方 |
|---|---|---|
| ログインユーザー名 | — | 変えない |
| 投稿者スラッグ（URLに出る文字） | ログイン名と同じ | まったく別の文字列にする |
| 表示名・ニックネーム | ログイン名と同じ | 屋号や好きな表記にする |
表示名は ユーザー → プロフィール から変更できます。投稿者スラッグは標準の管理画面に項目がないため、変更にはプラグインなどの手段が必要です。
この変更には、セキュリティ以外の利点もあります。 記事の著者名が屋号になるので、見た目が整います。私の場合も、味気ないログイン名から屋号の表記に変わりました。
確認のしかた（キャッシュに注意）
設定が終わったら、ログアウトした状態で確認します。ブラウザのシークレットウィンドウを使うのが簡単です。
自分のサイトのURL/?author=1を開く → ユーザー名が出なければOK/author/ログイン名/を開く → 404になればOK- 記事ページを開いて、著者名の表示がログイン名でなければOK
ここで一度つまずきました。
設定直後に確認したところ、3つとも「まだ見えている」という結果になったのです。設定を間違えたかと思って見直しましたが、どこも間違っていません。
原因はキャッシュでした。サーバー側とブラウザ側の両方に前の状態が残っていて、古い画面を見ていただけだったのです。キャッシュを避けて確認し直したら、正しく塞がっていました。
設定を変えた直後の確認は、キャッシュを疑ってから判断してください。 「効いていない」と誤解して、余計な設定をいじってしまうところでした。
残り2つの機能と、その副作用
無効だった残り2つも有効にしました。どちらも使い勝手が少し変わるので、知らないと戸惑います。
フェールワンスは、正しいIDとパスワードを入れても1回目は必ず失敗する機能です。5〜60秒後にもう一度入力すると成功します。自動ツールを空振りさせる仕組みですが、知らないと「パスワードを間違えた」と勘違いします。
管理ページアクセス制限は、以前ログインしたことのある接続元からしか管理画面に入れなくする機能です。許可は24時間で消えます。外出先など接続元が変わったときは、ログインページを開き直せば入れるようになります。
まとめ：守る対象ごとに「入口を数える」
今回いちばんの学びは、機能の名前を信じすぎないことでした。
「ユーザー名漏えい防御」という名前の機能をオンにしたのだから、ユーザー名の漏えいは防げているはずだ——そう考えるのが自然です。でも実際には、入口が3つあって、その機能が塞ぐのは1つだけでした。
しかも3つの対処は、プラグインの設定・そのオプション・ユーザー情報という別々の場所にありました。1か所だけ見ていては気づけません。
だから、対策は機能単位ではなく「守りたいものに、外から入れる道が何本あるか」で数えるほうが確実です。数えてから、1本ずつ確認して潰す。今回でいえば、守りたいのはユーザー名で、道は3本ありました。
最後に手順としてまとめます。
- ログイン履歴を見る（何が起きているかを知る）
- 無効になっている機能を確認する
- ユーザー名が外から取れないか、3つの経路で確かめる
- 塞いだあと、ログアウト状態で再確認する（キャッシュに注意）
1と3は、設定を変えなくても今すぐできます。まず見るところから始めてみてください。 自分のサイトで何が起きているかを知るだけでも、優先順位がはっきりします。
次回予告
次回はシリーズ最終回です。
ここまで5回にわたって書いてきた作業は、すべて ConoHa WING というレンタルサーバーの上で実際にやったものです。最終回では、15日間運用してみて分かったこのサーバーの良かったところと、契約前に知っておいたほうがいいところを、正直にまとめます。
▶ 次の記事：このシリーズは全部ConoHa WINGでやりました｜15日使って分かった良いところと、知っておくべきところ
コメント