WordPressセキュリティ対策強化の基本

｜2017年1月25日 12:00 公開

オープンソースCMSのWordPressを利用するときに一番気になるのが、セキュリティ対策についてではないでしょうか。
近年WordPressを狙ったハッキングが増えてきていますので、しっかりとセキュリティ対策を実施し、皆様のウェブサイトを守ってください。

「Webサイトからお問い合わせが来ない…」とお悩みの方必見！
当サイトのノウハウを詰め込んだ『Web集客の無料ガイド』をご提供

詳細はこちら

2016年Q3のハッキング状況

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


（調査結果及び、画像引用：Hacked Website Report – 2016/Q3）

2017年のハッキング状況

「Hacked Website Report 2017」の調査によると、2017年に34,371件の感染したウェブサイトを調査した結果、WordPressが83%、Joomlaが13.1%、Magentoが6.5%でした。WordPressの感染は2016年第3四半期の74％から2017年の83％に増加しました。

 

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

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でも定期的に出ます。その脆弱性を放置したままサイトを運用することは、大変危険です。定期的に実行し、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年以上経過しているものは使わないようにしてください。もちろん公式以外にも優れたテーマや、プラグインは存在しますので、使う場合は十分に気をつけてください。

CMSのアップデートはセキュリティ対策の基本です。必ず実施してください。

 

管理IDと、パスワード

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

 

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


（国別ランキング）

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

 

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

（ID別ランキング）

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

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

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

ポイント：

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

推測されないようなIDと、パスワードを設定することはセキュリティ対策の基本です。必ず実施してください。

 

ファイル転送の手段

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

SFTPでの接続方法

一般的なレンタルサーバーの場合のSFTP接続方法を紹介します。

  1. お使いのレンタルサーバーのコントロールパネルからSSHアカウントを作成します。
  2. ID、パスワード認証か、鍵認証方式の2通りが一般的です。
  3. ID、パスワード認証の場合、転送プロトコルを「SFTP」を選択し、コントロールパネルで設定した、ユーザー名、パスワードを入力します。
    （画面はWinSCP）

     
  4. 鍵認証方式の場合、プロトコルを「SFTP」に選択、ログオンタイプに「鍵ファイル」を選択し、コントールパネルで設定した、鍵ファイルを選択します。
    （画面はFileZilla）

昨今の通信はhttpからhttps、ftpから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);

 

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

多サイト運営の場合

同一サーバー上で複数のブログを実行している場合は、別々のデータベースに格納し、異なるユーザーで管理をしてください。
（レンタルサーバーによっては、データベースごとにユーザーを分けられない場合もあります）

接頭辞

ハッカーからの自動で生成されたSQLコードが実行されないよう、WordPressはデータベースに接頭辞を付与することができます。
しかし多くの場合はWordPressのデフォルトである「wp_」が設定されているので、これを推測されにくい文字列にしてください。

確認方法はレンタルサーバーのコントロールパネルから、データベース管理画面（phpMyAdmin）にアクセスし、データベース構造を確認してください。
赤枠の「wp_」が接頭辞です。現在はWordPressのデフォルトが使用されています。

接頭辞の変更方法

  1. データベース管理画面（phpMyAdmin）の「SQL」メニューを開きます。
  2. 下記のSQLを実行し現在のテーブルをコピーします。このコピー時に「wp_」から推測されにくい接頭辞に変更を行います。今回は「wp_c12345」とします。
    CREATE TABLE wp_c12345_commentmeta (SELECT * FROM wp_commentmeta);
CREATE TABLE wp_c12345_comments (SELECT * FROM wp_comments);
CREATE TABLE wp_c12345_links (SELECT * FROM wp_links);
CREATE TABLE wp_c12345_options (SELECT * FROM wp_options);
CREATE TABLE wp_c12345_postmeta (SELECT * FROM wp_postmeta);
CREATE TABLE wp_c12345_posts (SELECT * FROM wp_posts);
CREATE TABLE wp_c12345_termmeta (SELECT * FROM wp_termmeta);
CREATE TABLE wp_c12345_terms (SELECT * FROM wp_terms);
CREATE TABLE wp_c12345_term_relationships (SELECT * FROM wp_term_relationships);
CREATE TABLE wp_c12345_term_taxonomy (SELECT * FROM wp_term_taxonomy);
CREATE TABLE wp_c12345_usermeta (SELECT * FROM wp_usermeta);
CREATE TABLE wp_c12345_users (SELECT * FROM wp_users);

     

  3. 下記のSQLを実行しoptionテーブルの「wp_」を検索後、wp_から、wp_c12345に変更します。
    SELECT * FROM `wp_c12345_options` WHERE `option_name` LIKE '%wp_%';


     

  4. 下記のSQLを実行しusermetaテーブルの「wp_」を検索後、wp_から、wp_c12345に変更します。
    変更箇所はプラグインの数によって変わ場合があります。 
    SELECT * FROM `wp_a123456_usermeta` WHERE `meta_key` LIKE '%wp_%'


     

  5. WordPressをインストールした直下の「wp-config.php」を編集します。
      
    $table_prefix  = 'wp_c12345_';
  6. ウェブサイトが正しく表示されるか、WrodPressの管理画面に正しくログインできるか確認をしてください。
  7. 確認し正しく動作していたら、「wp_xxxxx」のテーブルを全て削除し、作業完了です。

 

WAF（Web Application Firewall）

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

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

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

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

 

昨今はWAFの導入が当たり前の時代となりました。
WAFを有効にするとWordPressの一部の機能が動作しなくなることから、WAFを停止するサイトが多少見受けられます。この場合はWAFを停止するのでなく、WAFの除外設定を実施してください。

参考記事

知らないと怖いWebセキュリティと、CPIサーバーのWAF設定方法

 

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のセキュリティを強化するために必要な機能を備えていますので、サーバー選定時に思い出していただけると幸いです。

関連タグ：

CPIの最新情報をTwitterでチェックできます！
@cpiadjp
次へ
前へ