この記事はtomita@atuwebがお届けします。

私の他WordPressブログのお話です。ダッシュボードに表示される「ブロックされた悪意あるログイン施行」が3桁を超える事態となり、かなり怖くなってしまいました。

その画像がこちらです。。。

art-wp-secure-wrong-login-c

792!
こわー。

何されてるんでしょうかね!
(上記はJetpackプラグインを有効化し、WordPress.com連携時、さらにAkismetを有効にすると表示されます)


私は、いくばくかWebアプリケーションを開発に携わった経験から、「Webサービスは、その規模にかかわらず常に攻撃にさらされている」ということを実感として強く持っています。

「これはまじめに対策を考えないとなー」という気持ちになりましたので、WordPressで行うことができる不正ログインの対策についてまとめてみました。

対策の実施前には必ずバックアップをお取りください!!

Overview

アカウント名が表に出ないようにする

WordPressに限らず、世の中の大抵のWebサイトはアカウント名パスワードで使ってユーザを識別しています。
たった2つの文字列です。

このうち片方、アカウント名が露見すると、あとはパスワードをどうにか入手すれば「なりすましログイン」が可能になってしまいます。

最低限として、はじめにアカウント名が世に出ないよう対策します。

管理ツールを隠す・壁を増やす

WordPressは最もポピュラーなブログCMSですから、利用者も相当な数に上ります。

WordPressの管理画面といえばwp-adminと決まっており、URLが周知であることが不正ログインを容易にする一因になっています。

管理ツールへの対策としては次のようなことが考えられます。

  • 管理ツールの場所を分かりにくくする、隠蔽する
  • ログインするための手順を増やす、壁を増やす

その他

その他の対策についてまとめます。

アカウント名が表に出ないようにする

案外やることがありました。

アカウントの表示名を変える

WordPressの初期状態はアカウント名が丸見えです。
「投稿・固定ページ」に表示される投稿者がアカウント名そのままなのです。

即、管理ツールからニックネームを設定し、投稿者の表示を変更しましょう。

art-atu-wcsec-nickname

手順

  • 管理ツールにログインし「ユーザー > あなたのプロフィール」をクリック
  • ニックネームを入力する
  • ブログ上の表示名を切り替える
  • 画面下部のプロフィールを更新ボタンを押下する
  • ブラウザが更新され「プロフィールを更新しました。」表示が出ることを確認する

投稿者のリンクを変更する・削除する

表示を切り替えればOKというわけではありません。
投稿者にマウスポインタを載せると、URLにしっかりアカウント名が出ているではありませんか!

WordPressは「投稿・固定ページ」の投稿者名からAuthorアーカイブページへ遷移するようになっています。

Authorアーカイブページとは、投稿者ごとの記事を一覧で表示するページです。
こんなページがあることに、私はつい最近まで気づいていませんでした。

「複数人で運用できる」WordPressならではの機能ですね!素晴らしい!
ですが、しかし「すべての記事 == あなたの投稿記事」という大抵の一人ブログには不要な機能だと思います。

ここは、使用しているテーマによって対応方法が異なります。

Simplicity

オススメのテーマSimplicityでは、テーマのカスタマイズメニューに以下があり、簡単に対策ができました。

art-atu-wcsec-simplisity-custom

管理ツールにログインし「外観 > カスタマイズ > レイアウト(投稿・固定ページ)」から設定を行います。

投稿者情報の表示

チェックを外すと、ページ上の投稿者が非表示となりますので、Authorアーカイブページへのリンクもなくなります。

投稿者情報をTwitter IDに

チェックを入れると、投稿者からTwitterにリンクされます。
忘れずに「外観 > カスタマイズ > SNS」からTwitter IDを設定してください。

SNSを併用してアクセスアップするのがベターだと思います。
こちらがおすすめです。

その他のテーマ

デフォルトテーマの以下は、カスタマイズメニューから投稿者を非表示にすることができないように見受けられました。

  • Twenty Fifteen
  • Twenty Fourteen

テーマを変更するか、テーマに手を入れてリンクを外してしまうと良いでしょう。

国産の有名なテーマであれば何らかの対応ができるのではないかと思いますが、確認しておりません。

Authorアーカイブページを無効にする

2017年2月18日追記:新しいWordPressバージョンでは post_author に変わっているようです。

まだ戦いは終わりません。
投稿者のリンクを変更しても、Authorアーカイブページは生きています。

ブラウザページに次のULRを打ち込んでみてください。

http(s)://[FQDN]/?author=1

すると、次のURLにリダイレクトされ、簡単にAuthorアーカイブページを開くことができますね。

http(s)://[FQDN]/author/[アカウント名]

繰り返しますが、一人ブログにAuthorアーカイブページは不要です。
無効化してしまいましょう。

Kawatama.netさんを参考に、リダイレクトを設定します。
管理ツールの「外観 > テーマの編集」からfunctions.phpを開き、次のPHPコードを追加します。

function theme_slug_redirect_author_archive() {
    if (is_author() ) {
        wp_redirect( home_url());
        exit;
    }
}
add_action( 'template_redirect', 'theme_slug_redirect_author_archive' );

これで、Authorアーカイブページへのアクセスをブログトップにリダイレクトすることができます。

今回編集したfunctions.phpというファイルは、テーマ別のに管理されているものですから、テーマを変更した場合は同じ対策をおこなう必要があります。(これ絶対忘れるやつだ)

次の一歩

上記のリダイレクト設定は「登録済みアカウントのみ有効」であることが分かりました。
こんな感じです。

  • リダイレクトされるパターン
http://[FQDN]/author/[OKなアカウント]/
  • 404が返却されるパターン
http://[FQDN]/author/[OK以外のアカウント]/

つまり「404エラーが発生しない -> 登録アカウントである」と判断できます。

手動アカウントを探ることは難しいかもしれませんが、ツールを開発すれば一瞬でアカウント有無を見分けることができそうです。

対策として、「Authorアーカイブページ以下のアクセスはすべてTOPへリダイレクト」します。
ということで、.htaccessに以下のリワイトを追記しました。

RewriteRule ^author/(.*)$  http://atuweb.net/ [R=301,L]
RewriteRule ^article/pauthor/(.*)$  http://atuweb.net/ [R=301,L]

上記のatuweb.netを適宜を書き換えてご使用ください。
私はそのままでもかまいませんw

WordPressのバージョン違いか「article/pauthor/~」というURLも確認いたしました。
大した手間ではありませんので、どちらも塞いでしまいましょう。

それでも安心できないあなたへ

管理ツール上ではアカウント名を変更できないようになっていますが、WordPress機能の外でアカウント名の変更が可能です。
実際、私は「アカウントが割れたかな?」と感じたため、ムリヤリ書き換えたことがあります。

これについては改めてまとめたいと思ってます。

管理ツールを隠す・壁を増やす

メタ情報を隠す

管理ツールを隠す対策です。

WordPressの初期状態ではご丁寧にサイドバーに管理ツールへの導線が張られています。

art-atu-wcsec-side-meta

これです、これ!

知識のない初心者の方にとってはワナだと感じます。
Twenty Fourteen、Twenty Fifteen、Simplicityいずれも同等でした。

管理ツールの「外観 > ウィジェット」を開き、メタ情報を外しましょう。
art-atu-wcsec-meta-delete

クリックして開き削除ボタンを押下するとOKです。

ちなみに、ウィジェットは「テーマを変更したら元に戻っちゃう」ことはありませんでした。

ログインページのURLを変更する

そもそも「ログインページのURLを分からなく」するという、管理ツールを隠す対策です。
この対応は、一昔前は手間がかかるものだったのですが、現在はAll In One WP Securityで簡単に対策できます。

All In One WP Securityで対策する

プラグインからAll In One WP Securityをインストール、有効化してください。

管理ツールの「WP Security > Brute Force」を開きます。

art-atu-wcsec-loginpage

Enable Rename Login Page Featureにチェックを入れ、Login Page URLで任意のURLを指定します。
このURLを忘れるとログインできなくなってしまいますから、しっかりメモしてくださいね。


設定後、ログアウト状態で/wp-admin/にアクセスすると次の画面が表示されました。

art-atu-wcsec-notaval

またwp-login.phpにアクセスすると404ページが表示され、しっかりログインページが隠蔽されたことを確認できました。
イイですね!

もう一つの穴[xmlrpc.php]を塞ぐ

WordPressではピンバックのためにxmlrpc.phpというファイルが付属しておりますが、このファイルはログイン機能を有しており、Dos攻撃の踏み台にされることがあるようです。

私も「対策したはずのWordPressなのになぜログイン失敗が記録されているのか」とずっと悩んでおりましたが、それがようやく解決しました。

ピンバックよりもセキュリティを重視、ということでxmlrpc.phpをアクセス禁止にしたところ、不正なログイン試行がなくなりました。

対策の詳細としては、以下をWordPressの.htaccessに追記しました。

<Files xmlrpc.php>
Satisfy Any
Order deny,allow
Deny from all
</Files>

環境によっては上記の通りでは動作しないかもしれません。

その他の対策方法

「プラグインを増やしたくない!」という場合、次のサイトさんの対策ができました。

WordPress私的マニュアル
ログインページを変える
http://elearn.jp/wpman/column/c20121118_01.html

こちらは知識がある方向けですから、プラグインでサクッと対策するのが良いと思います。

管理ツール以下にBasic認証を導入する

知識、権限がある方向けの対策です。

Basic認証(Basic Authentication)とは、HTTPで定義される認証でもっとも簡単なものです。
実際、Web系の開発を行っていると、手っ取り早く壁を作る方法としてよく利用されます。

正直、セキュリティ強度は強くなく「ないよりはあったほうが良い」レベルにもかかわらず、設置に手間がかかり、WordPress特有の落とし穴がありますので、導入する場合は覚悟が必要です。

のがBasic認証です。

私も.htaccessにBasic認証を設定してwp-admin以下にアクセスする場合に認証を入れようと試みましたが、ここにも落とし穴があります。

落とし穴↓

ねとたす:WordPressの管理画面(wp-admin)のBasic認証トラブルと解決方法-記事ページで認証がでる現象
https://netotas.net/wordpress-basic-auth

ごく簡単に手順を。

ID/パスワードの準備

IDとパスワードを用意し、次のようなツールでパスワードの暗号化を行います。

.htaccess による認証用 パスワード暗号化ツール
http://www.luft.co.jp/cgi/htpasswd.php

.htpasswdを作成

サーバ上に.htpasswdを作成します。

場所は任意ですが、ドキュメントルート以下は当然避けてください。
ここではパスを/home/hoge/.htpasswdとします。

パーミッションは604か644で良いでしょう。

.htaccessに認証を設定する

管理ツール以下のみを認証の対象とします。
wp-adminディレクトリ直下に.hataccess`を作成し、次を入力してください。

AuthUserFile /home/hoge/.htpasswd
AuthName "パスワードを入力してください"
AuthType BASIC
require valid-user

<Files admin-ajax.php>
Satisfy any
allow from all
</Files>

AuthUserFileはhtpasswordを絶対パスで指定します。

次の一歩

とはいえ、毎回2つもパスワードを入力するのが面倒ですよね。
特定IPの場合はBasic認証をスルーすることもできますよ。

AuthUserFile /home/atuweb/.htpasswd
AuthName "パスワードを入力してください"
AuthType BASIC
require valid-user

<Files admin-ajax.php>
Satisfy any
allow from all
</Files>

Satisfy any
Order deny,allow
Allow from 127.0.0.1
Deny from all

くどいようですが、Basic認証は薄い壁を1枚作るだけの簡易的なもので、本当に気休めにしかならないことをご認識ください。

その他

ファイルのアクセス権限を正しく設定する

WordPressの設定ファイルにはデータベースの接続情報が平文で記載されています。
サーバ上設定によってはこれが見られてしまうことがありますので、ファイル権限を設定してしっかりと引き締めましょう。

こちらの対策にもAll In One WP Securityが便利です。

管理ツールの「WP Security > Filesystem Security」を開くと、主要なファイルと現在の権限が一覧表示されます。
art-atu-wcsec-filesystem

推奨権限と相違がある場合、表の右端にSet Recommended Permissionsボタンが表示されますのでこれをクリックするだけでOKです。
推奨権限通りの場合No Action Requiredというテキストが表示されますので、すべてこの表示になるようにしてください。

次の一歩

wp-config.phpは特に重要なファイルです。
WP Securityの推奨パーミッションは644ですが、600や400などガチガチに設定しても良いでしょう。

加えて、.htaccessに以下を加えてネット上から閲覧できないようにしてください。

<files wp-config.php>
order allow,deny
deny from all
</files>

Jetpackの使用中止を検討する

WordPressを利用するにあたって、最初に導入を検討する便利プラグインの一つがJetpackではないでしょうか。
Jetpackを利用すると、たとえばアクセス解析やSNS連携、画像表示系の機能が強化されるなどのメリットがあります。

Jetpackを利用するにはWordPress.com連携が必須で、ここがキモだと思います。

WordPress.com連携を行うと、そちら側で操作が可能になり、複数ブログの一元管理も可能という利点があるように見えます。
しかしながら、ブログの編集もできてしまうということは、管理ツールがもう一つ増えることと同義です。

息を切らしながら自前のブログをバリバリ整備して体制を整えても、外部管理から攻撃を受けてしまったら。
メインで利用する管理ツールで異変にすぐ気がつけば早期対処できますが、編集できることを意図していなかったら、気付くのが遅れてしまいます。

そういったことを考えて、私はJetpackの利用を中止しました。

もともと、私はブログをMarkDownで書くことができればOKでしたので、かわりにJP Markdownをインストールして利用しています。
アクセス解析はGoogle Analyticsを直接見に行っています。
これで十分です。

便利さとセキュリティはほとんどの場合トレードオフ」になっていますので、あなにとってどこまでがOKでどこからがNGなのかはよくよく検討してくださいね。

おわりに

私は上記の対策に加えて、「ちょっと手間がかかるけれども、これで不正ログインされることはないだろう」という対策を入れています。
ちょっとだけ恥ずかしい方法のため、記事中では紹介しませんでした。

知らないから、分からないからと言って放置せず、しっかり対応することをお勧めします。

私も微力ながらお手伝いできると思います。
今後WordPress導入、フォローといったメニューを検討していきます!


WordPress Security 101: How to secure your website against hackers (English Edition)

たった5分で出来る!あなたのWordPressブログをハッキングから守る方法

試したけれど採用しなかった対応

Google Authenticatorを導入する

Google AuthenticatorプラグインはWordPressへのログインを二段階認証化するプラグインです。

スマートフォンアプリと連動したトークンを利用してログインする機能を追加します。
この認証はGmailなどでも利用されているので高いセキュリティが見込まれます。

でも、、、あれれ?
トークンなくてもログインできたような気がするけれども、、、

私は設定を誤ったためか、トークンを入力しなくてもログインできてしまったためいろいろ確認中で現在は利用していません。

参考



2017年02月18日:autorのアドレスがpost_author に変わっていることを追記。
2017年01月23日:「もう一つの穴[xmlrpc.php]を塞ぐ」を追記

スポンサーリンク
ad_336
ad_336
  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存