防御と不正アクセスからの復旧 ~ 基礎からしっかり!WordPressのセキュリティ対策ことはじめ (3/3)
目次
はじめに
最終回はWordPressのプラグインによるセキュリティ対策と不正アクセスを受けた時の対応について触れます。WEBサイトは構築することが目的ではなく、運営して情報を発信していくこととなりますので、より良いWEBサイトを継続していくためにも本記事をご参考いただければ幸いです。
WordPressのセキュリティ対策を行う
ここでは簡単に対策が行えるAll In One WP Securityプラグインを用いた方法について触れます。
▼Wordpress.org プラグインディレクトリ All In One WP Security & Firewall
https://ja.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
セキュリティ対策としてのプラグインは多数ありますが、All In One WP Securityプラグインを選択したのは下記の理由からです。
- 開発状況が活発であり、迅速なアップデートが行われている実績も確認できたため
- 単一のプラグインで機能が多く、様々な要求に対応できるため
- 挙動を調べる時にソースコードが追いかけやすい内容であったため
とても機能が多いプラグインですが、基本的なセキュリティ対策としては本項で触れている設定項目だけで十分であり、他の項目については要件にあったものを適時選択すると良いでしょう。
ダッシュボードへのログインを守る
パスワード総当たり攻撃によるダッシュボードへのログイン試行への対策を行います。この項目では、ダッシュボードへのログイン試行回数の制限、およびログインURLの変更を行います。
ログインロックの設定
ログインロックとは、一定回数ログインに失敗したIPアドレスからの試行を拒否する機能となります。
設定するためには、ダッシュボードのメニューから”WP Security” → “User Login”を選択して、ページ上部の”Login Lockdown”タブをクリックします。
それぞれの設定項目は下記になります。
設定項目 | 設定内容 | 初期値 | 推奨値 | 備考 |
---|---|---|---|---|
Enable Login Lockdown Feature | ログインロックの機能を有効にするか | Off | On | 有効にしないと以降の設定が反映されません |
Allow Unlock Requests | ロック解除リクエスト用のフォームを表示するか | Off | Off | フォームからメールアドレスを入力し、受信後に文面に記載されている URL にアクセスするとロックが解除されます。効率は悪いですが自動的にログイン試行できるので、管理上の都合(複数人で使用している場合など)がなければ Off を推奨します。 |
Max Login Attempts | ロックされるまでのログイン試行回数 | 3 | 任意の値 | |
Login Retry Time Period (min) | ロックされるまでの経過時間(分) | 5 | 任意の値 | ログイン試行回数が Login Retry Time Period で指定された時間内にMax Login Attempts で指定された回数に達したらロックします。初期値では 5分間に3回ログイン失敗したらロックされます |
Time Length of Lockout (min) | 再度ログイン試行できるまでの隔離時間(分) | 60 | 任意の値 | ここで指定した分が経過するまでログイン自体ができなくなります。 |
Display Generic Error Message | ログイン失敗時に標準のエラーメッセージを表示するか | Off | Off | 標準のエラーメッセージではアカウントが間違っているのか、パスワードが間違っているのかが区別されています。このため、アカウントが存在するかどうかがわかってしまいます。 |
Instantly Lockout Invalid Usernames | 存在しないアカウント名でログイン試行した場合、即時ロックする | Off | On | ユーザ名の試行となるため、有効にします。 |
Notify By Email | ログインロックが発生した時に通知を送信するか | Off | Off | 大量のメールが送信される可能性があるため、非通知が好ましいです。 |
通知を送信するメールアドレス | デフォルトのメールアドレス | デフォルトのメールアドレス | 管理用アカウントに設定されているものを利用します。 |
試行回数や制限を行う時間の設定については、攻撃者に対策を行っていることを検知させないために初期値から変更するという方法もありますが、こちらについては運営形態や単純に好みなどで任意の値で設定します。
注意点として、ログインロックの対象となるIPアドレスは単一ではなく、/24単位のネットワーク範囲(256個)という仕様となっているため、無関係な付近のIPアドレスを巻き込んでしまう可能性があります。
ログインURLの変更
ダッシュボードへのログインはhttp://ドメイン名/ wp-login.phpといったURLとなりますが、総当たり攻撃への対策として、特定の手順を踏まないとこのURLからログインできないようにします。
設定するためには、ダッシュボードのメニューから”WP Security” → “Brute Force”を選択して、ページ上部の”Cookie Based Brute Force Prevention”タブをクリックします。
それぞれの設定項目は下記になります。
設定項目 | 設定内容 | 初期値 | 推奨値 | 備考 |
---|---|---|---|---|
Enable Brute Force Attack Prevention | ブルートフォース攻撃への防止を有効にするか | Off | On | |
Secret Word | ログインURLへの任意の文字列 | 任意の文字列 | 英数文字 | |
Re-direct URL | HTTPクッキーが無い不正なアクセスをされたときにリダイレクトするURL | http://127.0.0.1 | http://127.0.0.1 | 127.0.0.1はローカルホストとなります。 |
My Site Has Posts Or Pages Which Are Password Protected | パスワード付き投稿を対象外とする | Off | On | 他の部分で動作に影響がある可能性があるため。 |
My Site Has a Theme or Plugins Which Use AJAX | プラグインやテーマでAJAXを使っている場合、対象外とする | Off | On | 他の部分で動作に影響がある可能性があるため。 |
正規のダッシュボードのログインへたどり着くには下記のような流れとなります。
- Secret Word で指定した URL (http://ドメイン名/?{Secret Word}=1 ) にアクセス
- 専用のHTTPクッキーが設定される
- 本来のダッシュボードのログインURLへリダイレクトされる
- 専用のHTTPクッキーを持っている場合、正規とみなして処理を継続する
- 専用のHTTPクッキーを持っていない場合、不正とみなしてRe-direct URLに設定されたURLへリダイレクトする
- wp-login.phpにてダッシュボードのログインフォームを表示する
- ユーザ名とパスワードを入力し、認証を行う
このようにSecret Wordで指定したパラメタを含むURLを経由してからダッシュボードへのログインURLへ遷移する必要があるため、総当たり攻撃でいきなりwp-login.phpへアクセスした場合、認証フォームは表示されずRe-direct URLに設定されたURLへリダイレクトされてしまいます。
また、Secret Wordで指定したURLを忘れてしまいログインできなくなった場合は、.htaccess の #AIOWPS_ENABLE_BRUTE_FORCE_PREVENTION_START から #AIOWPS_ENABLE_BRUTE_FORCE_PREVENTION_END の部分を削除します。
#AIOWPS_ENABLE_BRUTE_FORCE_PREVENTION_START RewriteEngine On RewriteCond %{REQUEST_URI} (wp-admin|wp-login) RewriteCond %{REQUEST_URI} !(wp-admin/admin-ajax.php) RewriteCond %{QUERY_STRING} !(action\=postpass) RewriteCond %{HTTP_COOKIE} !n3na1k0dar3da= [NC] RewriteCond %{HTTP_COOKIE} !aiowps_cookie_test_6ijvdgxxxf= [NC] RewriteRule .* http://127.0.0.1 [L] #AIOWPS_ENABLE_BRUTE_FORCE_PREVENTION_END
このように内部的にはmod_rewriteの機能を使って実現しています。
データベースのバックアップを行う
バックアップについてはデータの損失、もしくは不正アクセスの被害を受けた時のために保全として事前に取得しておくことを目的としています。特に後者の場合では、サーバ上のデータは利用できないものとなるため、事前のデータが必要になります。
FTPでダウンロードするだけで良いコンテンツのファイルとは違い、データベースのバックアップはデータベースサーバへ接続し、専用のコマンドにてデータを抽出する、といった複雑な手順が必要になります。ここではWWWブラウザからバックアップの設定を行う方法について触れます。
バックアップの設定を行う
バックアップの設定をするためには、ダッシュボードのメニューから”WP Security” → “Database Security”を選択して、ページ上部の”DB Backup”タブをクリックします。
それぞれの設定項目は下記になります。
設定項目 | 設定内容 | 初期値 | 推奨値 | 備考 |
---|---|---|---|---|
Enable Automated Scheduled Backups | 自動バックアップ機能を有効にするか | Off | On | |
Backup Time Interval | バックアップを取る間隔 | 4週 | 任意 | 週、日、時間単位で指定可 |
Number of Backup Files To Keep | バックアップを残す世代数 | 2 | 任意 | |
Send Backup File Via Email | バックアップ処理後に通知のメールを送信するか | Off | 任意 | |
バックアップ処理後に通知するメールアドレス | デフォルトのメールアドレス | 任意 | 管理用アカウントに設定されているものを利用します。 |
バックアップを取得する間隔と残す世代については、コンテンツの更新頻度から任意のものを設定してください。
また、バックアップされたデータについては、wp-content/aiowps_backupsディレクトリ以下にzipファイルとして格納されます。このディレクトリへはHTTPによるアクセスはできませんので、FTPクライアントなどでデータを取得してください。
注意点として、データベース上のデータ量が増えた場合において処理に時間がかかる、トランザクションを発行していないためデータの整合性が保証されないといったものがあります。このため、mysqldumpコマンドにてダンプデータを定期的にバックアップデータとして取得し、それを世代管理する方が望ましいです。
改ざんを検知する
ここでの改ざんとはコンテンツの改ざんではなく、サーバ上に設置されているWordPressのファイル自体の改ざんを検知する方法について触れます。これは表示されるコンテンツに見た目の変化は無いものの、ファイルの一部が改ざんされ迷惑メールを送信する処理が追加されているといった事例が多く確認されています。
また、WordPress配下のディレクトリに不正なファイルを設置されるといった事例もあるため、WordPress全体の変更を監視することにより、不正利用されていることを検知します。
ファイル変更通知の設定を行う
ファイル変更通知の設定するためには、ダッシュボードのメニューから”WP Security” → “Scanner”を選択して、ページ上部の”File Change Detection”タブをクリックします。
それぞれの設定項目は下記になります。
設定項目 | 設定内容 | 初期値 | 推奨値 | 備考 |
---|---|---|---|---|
Enable Automated File Change Detection Scan | 自動スキャン機能を有効にするか | Off | On | |
Scan Time Interval | スキャンを行う間隔 | 4週 | 任意 | 週、日、時間単位で指定可 |
File Types To Ignore | スキャン対象外とするファイルの拡張子 | 任意 | ファイル名で判定します | |
Files/Directories To Ignore | スキャン対象外とするディレクトリ名 | 任意 | ||
Send Email When Change Detected | 変更を検知した時に通知のメールを送信するか | Off | 任意 | |
変更を検知した時に通知するメールアドレス | デフォルトのメールアドレス | 任意 | 管理用アカウントに設定されているものを利用します。 |
スキャンを行う間隔については1日毎が望ましいです。これは自分が行った変更や自動アップデートも通知の対象となるため、あまり期間を開けると何が原因なのかわかりにくくなるためです。また、ファイルの変更が検知されなかった場合、メールは送信されません。
不正アクセスを受けた場合には
次に不正アクセスを受けた場合について触れます。セキュリティ対策も重要ですが、これに加えて実際に不正アクセスを受けた時に復旧する手段を想定しておくことも必要です。
特に問題が発生してから対応の検討を開始するのではなく、事前にすべきことを策定しておき、対応の漏れが発生しないようにします。
公開を停止し、原因を特定する
不正なアクセスを受けて問題が発生している状態となっているため、まずはWEBサイトの公開を停止する必要があります。
次に原因の特定を行いますが、多くの場合、非常に困難であること考えられます。
前述のAll In One WP Securityプラグインを導入済みの場合、変更されたファイルやダッシュボードへログインした履歴を確認できるため、ここから特定を行える可能性があります。
また、WordPressやプラグイン・テーマの脆弱性であれば、セキュリティスキャナであるWPScanを用いて原因を調査することも可能ですが、環境によっては動作させることが難しいかもしれません。
しかしながら、原因の特定については必要であれば後日の対応とし、まずは復旧を優先したほうが良いでしょう。
コンテンツのデータをダウンロードしてから削除する
問題が発生しているコンテンツを手元のPCにダウンロードしてから、サーバ上のデータを削除します。
※クライアントPCには必ずアンチウイルスソフトウェアをインストールしておいてください。
次にダウンロードしたコンテンツをバックアップとして取得しているコンテンツの差分を確認して、どこが違うかを確認します。差分の確認についてはdiffなどの専用のツールを使用してください。
差分が確認できない時は、コンテンツの問題ではなくパスワードを不正利用されている可能性が高いです。
差分がある場合、不正なファイルの設置、改ざんなどが発生している可能性があるため、ダウンロードしてきたコンテンツのデータについては信用できないものとなります。
しかしながら、不正利用を検知してから時間が経過している場合、手元にあるバックアップデータ自体が既に不正である可能性が高いことに注意してください。
新しいWordPressとプラグインをアップロードする
最新のバージョンであるWordPressをアップロードします。さくらのレンタルサーバではクイックインストールからインストールすることができます。
問題となるのが各種プラグインとなりますが、これは事前に使用しているプラグインのスラグ名を把握しておくとwordpress.orgからAPIを使ってプラグインのアーカイブの取得ができます。
https://api.wordpress.org/plugins/info/1.0/(スラグ名).jsonでプラグインの詳細を含んだJSON形式のデータが取得でき、download_linkフィールドにアーカイブのURLが記載されています。
ダウンロードしたアーカイブを展開後、サーバのwp-content/pluginsディレクトリ以下にアップロードします。
特に複数のWordPressを運用している場合においては、このようなAPIを用いると構築の負担が軽減されるため、一度検討してみてください。
http://codex.wordpress.org/WordPress.org_API
データベースを復元する
バックアップしておいたデータベースのデータを復元します。方法については様々なものがあるため、詳細についてはMySQLのドキュメントを参照してください。
http://dev.mysql.com/doc/
しかしながら、復旧する手順については必ず事前に確認しておきます。バックアップを取得する方法については、単純に複製を取る行為であるため容易です。しかし、逆に書き戻しといった復旧の場合は、対象の取り違いによるデータ破損の懸念があるため、細心の注意を払う必要があります。
各種パスワードを変更する
不正アクセスを受けた場合、データベースへの参照が行われている可能性があります。WordPressのダッシュボードへログインするためのパスワードについては平文ではなくハッシュ化されたものが格納されているため、即時にパスワードが漏洩するものではありません。
mysql> select user_login, user_pass from wp_users;
+------------+------------------------------------+
| user_login | user_pass |
+------------+------------------------------------+
| akari | $P$BR5Ax7w8TPiHySXPXVG9qBdDMKioYN. |
+------------+------------------------------------+
1 row in set (0.00 sec)
しかしながら、可能性について完全に否定することはできないため、ダッシュボードや各種パスワードの変更を実施した方が良いでしょう。
今後の対策を検討する
不正アクセスを受けた原因から再発防止のための対策を検討します。しかしながら、原因の特定については困難な事例が多く、またサイトの再開を急ぐ必要がある状態であるかもしれません。
ここで十分な検討を行わずに問題を抱えたままサイトの再開をした場合、数日から数カ月後の間に高い確率で同じ問題が発生してしまうことがほとんどです。このため、対策については必ず実施するようにします。
まとめ
3回にわたってWordPressのセキュリティ対策について触れ、最終回はプラグインを用いた対策と不正アクセスを受けた時の対応について述べました。
今回触れたAll In One WP Securityプラグインについては、さくらのレンタルサーバのクイックインストールにてWordPressに同梱された状態で導入できます。
WordPressのセキュリティ対策として方法だけを伝えるだけはなく、さくらインターネットは事業者として、提供しているサービスの中にこのようなセキュリティを啓発できるような仕組みを用意させていただきました。
また、さくらのレンタルサーバをご利用いただいておりますお客様に限らず、すべてWordPressを利用している方々において本記事をセキュリティ対策の手助けとしていただけると幸いです。