WordPressセキュリティ強化の基本 WP4.7対応

 

Hacked Website Report – 2016/Q3」の調査によると、2016年Q3にハッキングされたCMS8,000サイトのうち、WordPressが74%、Joomla!が17%、Magentoが6%でした。

WordPressサイトをさらに調査すると、ハッキングに関与しているトップ3のプラグインは、Revslider、TimThumb、GravityFormsでした。これらのプラグインを導入しているユーザーは、早急にアップデートをした方が良いでしょう。

 


(調査結果及び、画像引用:Hacked Website Report – 2016/Q3

 

WordPressに限った話ではないですが、CMSのセキュリティ対策を行わず、WWWに公開するということは、いずれハッキングされると思ってください。

 

WordPressサイトのセキュリティを強化しよう

それでは、WordPressのセキュリティを強化するため具体的な施策をご紹介します。
 

参考記事(一部引用)

WordPress Codex(日本語): WordPress の安全性を高める
WordPress Codex(英語): Hardening WordPress
WordPress Codex(英語): Configuring Automatic Background Updates

 

  1. CMSのアップデート
  2. 管理者IDと、パスワード
  3. ファイル転送の通信手段
  4. ファイル・ディレクトリのパーミッション
  5. データベースセキュリティ
  6. WAF
  7. データバックアップ
  8. ログの取得
  9. 静的書き出しについて
  10. さいごに

 

CMSのアップデート

 

CMSの脆弱性はWordPressに限らず、どのCMSでも定期的に出ます。その脆弱性を放置したままサイトを運用することは、大変危険です。CMSのアップデートを定期的に実行し、WordPressのコア、プラグイン、テーマを常に最新に保ってください。
CMSのアップデート手順は大まかに下記の通りです。

[ステージング環境]

  1. バックアップ
  2. CMSアップデート
  3. 動作確認

[プロダクション環境(本番)]

ステージング環境で動作確認がOKの場合、プロダクション環境もアップデートする。

  1. バックアップ
  2. CMSアップデート
  3. 動作確認

 

WordPressのアップデートは管理画面にアクセスすると「更新」欄に通知されます。
アップデート通知がある場合、コア、プラグイン、テーマをアップデートしてください。

ポイント:

WordPressのアップデートは、バージョン3.7から、コアのマイナー更新および翻訳ファイルの更新に対してのみ自動で適用されます。
コアのマイナーも含めて一度ステージング環境で検証してから、プロダクション(本番)環境に適用したい場合は、「wp-config.php」ファイルに下記行を追加します。

/**
 * 自動アップデートを無効
 * true – 開発版、マイナー、メジャーアップグレードをすべて有効化
 * false – 開発版、マイナー、メジャーアップグレードをすべて無効化
 * minor – マイナーアップグレードのみを有効化
 */

define('AUTOMATIC_UPDATER_DISABLED','false');

WordPressは自動アップデートを推奨しています。十分な運用設計ができていない段階で、自動アップデートをオフにするのは危険ですのでおやめください。

また、プラグインやテーマは、できるだけ公式(https://ja.wordpress.org/plugins/)のを使うことと、プラグインに関しては最終更新が1年以上経過しているものは使わないようにしてください。もちろん公式以外にも優れたテーマや、プラグインは存在しますので、使う場合は十分に気をつけてください。

 

管理IDと、パスワード

 

みなさんは“狙われやすい” IDとパスワードが存在することはご存知でしょうか?
普段何気なく付けているIDとパスワードは、とても危険です。下記図は、弊社メールサーバーに対して総当たり攻撃を受けている一日分のログです。
(総当たり攻撃とは、一般的につけそうなIDやパスワードの組み合わせを片っ端から試す攻撃です。)

 

まずはアタックを受けている国別ランキングを見てみましょう。


(国別ランキング)

一番多くアタックが来ている国は中国でした。一日で約80万件のアタックを受けています。(怖いですね)

 

次に本題であります、一番多くアタックを受けているアカウント名を見てみましょう。

(ID別ランキング)

狙われやすいアカウント1位は「test」、2位が「info」でした。何気なくtest、info、admin、demoなどのアカウントに対して、password、p@ssw0rd、test123、demo123などの安易なパスワードを付けていませんか?

これらのIDとパスワードを設定して公開した時点で、遅かれ早かれメールアドレスやCMSなどのシステムが乗っ取られてしまう可能性が高くなってしまいます。

特に気をつけたいのが開発時に適当に設定した、ID:test、PW:test のようなアカウントが残ったまま公開してしまうこともあるかと思いますので、開発時の環境にも複雑なIDとパスワードを設定することをお勧めします。

ポイント:

  1. 推測されやすいアカウント名、パスワードを付けない。
  2. 複数サイトで同じアカウント名、パスワードを付けない。
  3. 開発中に使っていたアカウント「test」「demo」などが残っていないか確認する

 

ファイル転送の手段

 

Webサーバーにファイルを転送する場合に「FTP」を使うのではなく、「SFTP」を使用してください。
SFTPはFTPと違い、サーバー間のファイル転送(パスワード含む)が暗号化されるので、攻撃者に不正使用されることが無くなります。

お使いのファイル転送用アプリケーションをご確認ください。

 

ファイル・ディレクトリのパーミッション

 

セキュリティの観点から、ファイルパーミッション(読み・書き・実行の権限)を可能な限り制限することが重要です。
プログラムから書き込みが必要なファイルや、画像アップロード用の制限の緩い特別のフォルダなど用途に応じて用意する必要があります。

WordPressのデフォルトのパーミッションは以下の通りです。
(注意)レンタルサーバー会社によって、705や、604が推奨されているサーバーもあります

フォルダ - 755
ファイル - 644

 

フォルダが「755」、ファイルが「644」になっていない場合は下記コマンドによりパーミッションを変更するか、SFTPクライアントで接続し、変更することができます。

// フォルダ
find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

// ファイル
find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

 

wp-admin

「wp-admin」ディレクトリは管理者領域です。「wp-admin」にBasic認証を設定することで、ブログ管理領域、ログイン画面に2層の保護を追加することができます。しかしwp-admin ディレクトリを保護することで WordPress の一部機能が使えなくなってしまう場合がありますのでご注意ください(例えば wp-admin/admin-ajax.php に含まれる Ajax ハンドラなどです。)

Basic認証の設定方法は各社によって違いますので、各社オンラインヘルプ等を確認ください。

 

WP-Includes

「wp-includes」ディレクトリはWordPressのロジック部分で、スクリプトがユーザーによってアクセスされることを想定されていない部分です。「.htaccess」で下記コードを追加し、スクリプトをブロックしてください。

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

# BEGIN WordPress
# ここに記述しない

# END WordPress

マルチサイトを利用する場合は、7行目の「RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] 」の記述は削除してください。

 

wp-content/uploads

「wp-content/uploads」ディレクトリは、WordPressが利用する画像ディレクトリで、PHPの実行は必要ありません。
「wp-content/uploads」ディレクトリに「.htaccess」を設置し、PHPの実行を防いでください。

# Kill PHP Execution
<Files *.php>
deny from all
</Files>

(注)お使いのテーマがuploadsディレクトリ内でPHPを実行する場合は、設置した「.htaccess」を削除してください。

 

WP-Config.php

WordPressをインストールした階層にある「wp-config.php」は、WordPressのコンフィグファイルです。WordPressの設定情報や、データベースのID、パスワード情報が記載されています。外部にもれないようにアクセス権限を厳しく設定してください。

「.htaccess」が利用できるサーバーであれば下記コードを追記するか、パミーションを「400」もしくは、「440」に設定してください。

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

 

ファイル編集の無効化

WordPressダッシュボードでファイル編集を無効にすることをお勧めします。無効にするにはwp-configファイルの最後に次のコードを追加してください。

define('DISALLOW_FILE_EDIT', true);

 

データベースセキュリティ

 

同一サーバー上で複数のブログを実行している場合は、別々のデータベースに格納し、異なるユーザーで管理をしてください。

 

WAF(Web Application Firewall)

 

今や一般的になった攻撃手法、XSS、CSRF、SQLインジェクションは、ソースコードレベルでの対策が必要です。
(XSS、CSRF、SQLインジェクションが分からない方は別記事の「知らないと怖いWebセキュリティと、CPIサーバーのWAF設定方法」を参照ください)

これらの攻撃に対してソースコードレベルの対応も必要ですが、WAFを導入し、これらの攻撃を2重で防ぐことも重要です。

CPI ACE01サーバーでは標準でSiteGuard(WAF)が導入されています。またSiteGuard WP Pluginを導入することで、さらにセキュリティを高めることができます。(一部の機能はSiteGuardが導入していないと利用できない)例えば、ある一定の回数以上ログイン失敗を繰り返すと、ログイン機能を一定時間ロックするなどの、セキュリティを強化するためには欠かせない機能が追加されます。

CPIサーバー以外でもWAFが標準装備のホスティングは多数あります。サーバー選定時には気にしたいところです。

 

バックアップ

 

万が一に備えてデータのバックアップを取得しましょう。
バックアップはデータベースのバックアップと、htmlディレクトリのバックアップが必要です。

バックアップ取得方法はいくつかありますが、SSHでコンソールにログインできるのあれば下記コマンドで取得可能です。

コンソール画面より

データベースダンプ:

// -h 127.0.0.1 はデータベースサーバーを指定
mysqldump -h 127.0.0.1 -u USERNAME -p DatabaseName > Db_Dump.sql

Webデータ圧縮:

tar zcvf FileName.tar.gz html

 

Backup Guard Plugin

バックアップ取得用のPluginもいくつか出ていますので、Pluginでバックアップを取得するのも良いでしょう。
Backup Guard」は、バックアップの取得、ダウンロード、インポートが簡単に行えます。

 

レンタルサーバーのバックアップ

プラグインや手動のバックアップに加え、レンタルサーバー各社が提供しているバックアップのサービスを組み合わせることで、データ保全生が増します。バックアップが付いているレンタルサーバー会社を選択することも重要です。

 

 

ログの取得

 

WP Security Audit Log」Pluginを導入すると、誰がどんな操作をしたのか、ログインアタックを受けているかなどのログを取得することができます。


(クリックして拡大)

ログはアタックを受けたときの調査や、日々の監視に役立てることができます。「WP Security Audit Log」Pluginは簡単に導入ができるので入れておきたいプラグインです。

 

静的書き出しについて

 

この項目は書こうかどうか迷った項目です。考え方のひとつとして解説します。

動的コンテンツを公開環境に置かないことが、CMSをもっともセキュアに保つことと言えるでしょう。一例をあげると、ステージング環境にWordPressを導入し、静的なHTMLファイルを書き出し、書き出したHTMLファイルを公開環境にアップする。

このように公開環境に静的ファイルしか存在しない場合、Webコンテンツ経由からのハッキングは、ほぼ無くなります。(DOMや、JavaScriptを使用する場合気にするポイントあり)不特定多数を狙った攻撃からは、まず外れます。

WordPressでは「StaticPress」を導入することで、静的な書き出しができるようです。
ただ静的書き出しをするのであれば、別のプロダクトを考えても良いかもしれません。例えばMovable Typeや、静的サイトジェネレータ(Static Site Generator)のJekyll などが有名です。

要件にあった静的書き出しのプロダクトを選択することで、セキュアにサイトを保つことができます。

 

 

さいごに

 

CMSなどの不正アクセスの原因はIPAの不正アクセス届出状況を参照すると、ID・パスワードの管理不備や、古いバージョンを使用していたことがほとんどと言うことが分かります。

ID・パスワードを予測できないものにする、CMSをアップデートする、ログインを2段階にするということで、ほとんどの不正アクセスは防ぐことができます。これらの基本に加えWAFや、ファイアウォールを組み合わせたり、万が一のためにバックアップを取得したりすることが昨今のCMSに求められています。

 

CPI ACE01サーバーでは、バックアップ標準装備、WAF標準装備、ステージング環境標準装備です。
WordPressのセキュリティを強化するために必要な機能を備えていますので、サーバー選定時に思い出していただけると幸いです。

 

この記事をシェアする:

Author
この記事を書いた人:阿部 正幸

KDDIウェブコミュニケーションズ
クラウドホスティング事業本部 エバンジェリスト

CPIスタッフブログ編集長。ACE01,SmartReleaseをリリース後、現職の「エバンジェリスト」として、web制作に関する様々なイベントに登場

Line@登録よろしくお願いします

Web制作に関する情報や、CPIノベルティのプレゼント、サーバーの無償提供などを定期的に発信しています。
ぜひ、登録ください。