当サイト、Codex 日本語版は今後積極的な更新は行わない予定です。後継となる新ユーザーマニュアルは、https://ja.wordpress.org/support/ にあります。
万が一、当サイトで重大な問題を発見した際などは、フォーラムWordSlack #docs チャンネルでお知らせください。</p>

「WordPress の安全性を高める」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
(See Also: 原文へのリンク修正)
(自動アップグレードに関して: まで翻訳)
1行目: 1行目:
 +
{{NeedTrans}}
 
セキュリティは重要なトピックで、灰色の部分が多くあります。WordPress 開発者はセキュリティを非常に重要なものと考えています。しかし、他のシステム同様、潜在的にはセキュリティ上の問題があるかもしれません。また、セキュリティと利便性のバランスは常にトレードオフの関係にあります。WordPress を安全に保つために行うことができる普遍的なことをいくつか紹介します。
 
セキュリティは重要なトピックで、灰色の部分が多くあります。WordPress 開発者はセキュリティを非常に重要なものと考えています。しかし、他のシステム同様、潜在的にはセキュリティ上の問題があるかもしれません。また、セキュリティと利便性のバランスは常にトレードオフの関係にあります。WordPress を安全に保つために行うことができる普遍的なことをいくつか紹介します。
  
32行目: 33行目:
 
ネットワークの両端、WordPress サーバーサイドとクライアントサイド、は信頼できるべきです。つまり、家のルータのファイアウォールルールをアップデートし、どのネットワークから作業するかについて注意すべきです。例えば、混雑したインターネットカフェで、暗号化されていない無線接続で平文でパスワードを送信するのは、信頼できるネットワークでは''ありません。'' ホスティング業者は、ハッカーによって汚染されていないことを確かめるべきですし、あなたもそうすべきです。ネットワークに脆弱性があると、スニファやその他の破壊(中間者攻撃など)の発生をゆるしてしまうかもしれません。
 
ネットワークの両端、WordPress サーバーサイドとクライアントサイド、は信頼できるべきです。つまり、家のルータのファイアウォールルールをアップデートし、どのネットワークから作業するかについて注意すべきです。例えば、混雑したインターネットカフェで、暗号化されていない無線接続で平文でパスワードを送信するのは、信頼できるネットワークでは''ありません。'' ホスティング業者は、ハッカーによって汚染されていないことを確かめるべきですし、あなたもそうすべきです。ネットワークに脆弱性があると、スニファやその他の破壊(中間者攻撃など)の発生をゆるしてしまうかもしれません。
  
== Passwords ==
+
== パスワード ==
  
Some vulnerabilities can be avoided by good security habits.  An important element of this are passwords: do not use your own name for your password, do not use a dictionary word (from any language) for your password, do not use a 4 character string of numbers as your password.  Your goal with your password is to make the search space as large as possible, so using numbers and varying capitalization all make it more difficult, statistically, to brute force a password.  This is particularly important if you do not rename the administrator account.  In that case half the puzzle is already solved for malicious users as they know what username will give them significant privileges to edit files and databases. Many [http://www.google.co.uk/#hl=en&source=hp&q=password+generator automatic password generators] can be found on the internet and used to create secure passwords.
+
良いセキュリティ習慣により、いくつかの脆弱性は回避可能です。これが重要なのは、パスワードです。自分の名前をパスワードにしたり、(どんな言語であれ)辞書にある語をパスワードにしたあり、4 文字の数字をパスワードにしたりしてはいけません。パスワードの目的は、検索空間を可能な限り巨大にすることです。数字や大文字小文字を混在させると、統計的にブルートフォースを難しくします。管理者アカウントを別の名前にしていない場合は特に重要です。この場合、悪意あるユーザーは難問の半分を既に解いています。どのユーザー名が、ファイルやデータベースを編集する特権を持っているか知っています。 インターネット上に多くの[http://www.google.co.uk/#hl=en&source=hp&q=password+generator パスワード自動生成]が硬化いされており、安全なパスワードを作成するのに使用できます。
  
== File permissions ==
+
== ファイルパーミッション ==
  
Some of WordPress' cool features come from allowing some files to be writable by web server.  However, letting an application have write access to your files is a dangerous thing, particularly in a public environment.
+
WordPress の便利な機能のいくつかは、ウェブサーバーがファイルに書き込みできることに基づいています。しかし、アプリケーションがファイルに書き込み権限を持つことは危険です。公開環境では特に危険です。
  
It is best, from a security perspective, to lock down your file permissions as much as possible and to loosen those restrictions on the occasions that you need to allow write access, or to create special folders with more lax restrictions for the purpose of doing things like uploading images.
+
セキュリティの観点からベストなのは、ファイルパーミッションを可能な限り制限して、書き込み権限が必要な時のみ制限を緩くする、あるいは画像アップロード等の目的のために制限の緩い特別のフォルダを作成することです。
  
Here is one possible permission scheme.
+
考えられるパーミッションスキーマの1つを示します。
  
All files should be owned by your user account, and should be writable by you.  Any file that needs write access from WordPress should be group-owned by the user account used by the webserver.
+
すべてのファイルの所有者はあなたのユーザーアカウントで、あなたのみ書き込み可能。WordPress が書き込み権限を必要とするファイルは、ウェブサーバーで使用するユーザーアカウントのグループ所有。
  
* <code>/</code> -- the root Wordpress directory: all files should be writable only by your user account.
+
* <code>/</code> -- ルート Wordpress ディレクトリ: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
** EXCEPT <strong><code>.htaccess</code></strong> if you want WordPress to automatically generate rewrite rules for you
+
** 例外 <strong><code>.htaccess</code></strong> もし WordPress でリライト規則を自動生成したい場合
* <code>/wp-admin/</code> -- the WordPress administration area: all files should be writable only by your user account.
+
* <code>/wp-admin/</code> -- WordPress 管理領域: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
* <code>/wp-includes/</code> -- the bulk of WordPress application logic: all files should be writable only by your user account.
+
* <code>/wp-includes/</code> -- WordPress アプリケーションロジックの大半: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
* <code>/wp-images/</code> -- image files used by WordPress: all files should be writable only by your user account.
+
* <code>/wp-images/</code> -- WordPress が使用する画像ファイル: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
* <code>/wp-content/</code> -- variable user-supplied content: intended by [[Copyright_Holders|Developers]] to be completely writable by all (owner/user, group, and public).
+
* <code>/wp-content/</code> -- ユーザー提供の様々なコンテンツ: [[Copyright_Holders|開発者]] により、すべて(所有者、グループ、全体)で書き込み可能に意図されている。
** <code>/wp-content/themes/</code> -- theme files.  If you want to use the built-in theme editor, all files need to be group writable.  If you do not want to use the built-in theme editor, all files can be writable only by your user account
+
** <code>/wp-content/themes/</code> -- テーマファイル。ビルトインテーマエディタを使用する場合は、グループに書き込み権限を与える。ビルトインテーマエディタを使用しない場合は、あなたのユーザーアカウントでのみ書き込み可能。
** <code>/wp-content/plugins/</code> -- plugin files: all files should be writable only by your user account.
+
** <code>/wp-content/plugins/</code> -- プラグインファイル: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
** other directories under <code>/wp-content/</code> should be documented by whatever plugin / theme requires them.  Permissions may vary.
+
** <code>/wp-content/</code> の他のディレクトリは、プラグイン/テーマの要求次第で異なる。
  
* If you have shell access to your server, you can change file permissions recursively with the following command:
+
* サーバーへのシェルアクセスが可能な場合は、以下のコマンドでファイルパーミッションを再帰的に変更できます。
For Directories<br />
+
ディレクトリ<br />
 
<code>find [your path here] -type d -exec chmod 755 {} \;</code><br />
 
<code>find [your path here] -type d -exec chmod 755 {} \;</code><br />
For Files<br />
+
ファイル<br />
 
<code>find [your path here] -type f -exec chmod 644 {} \;</code><br />
 
<code>find [your path here] -type f -exec chmod 644 {} \;</code><br />
You have to omit to use this command for <code>/wp-includes/</code>.
+
<code>/wp-includes/</code> にはこのコマンドを使用してはいけません。
  
<b>Note that if you are on a shared-server the permissions of your wp-config.php should be 750. It means that no other user will be able to read your database username and password. If you have FTP or shell access, do the following:</b><br />
+
<b>共有サーバーの場合は、wp-config.php のパーミッションを 750 にすべきです。他のユーザーがデータベースユーザー名とパスワードを閲覧できないようにします。FTP またはシェルアクセスで、以下を行ってください。</b><br />
 
<code>chmod 750 wp-config.php</code>
 
<code>chmod 750 wp-config.php</code>
  
===Regarding automatic upgrade===  
+
===自動アップグレードに関して===  
Beginning with [[Version 2.7]] WordPress can perform an [http://core.trac.wordpress.org/ticket/5560 automatic upgrade].  As such, all file operations are performed as the user that owns the files, not as the web server's user.  All files are set to 0644 and all directories are set to 0755, and writable by only the user and readable by everyone else, including the web server.
+
[[Version 2.7]] から、WordPress は[http://core.trac.wordpress.org/ticket/5560 自動アップグレード]が可能になりました。すべてのファイル素すさは、ウェブサーバーのユーザーではなく、ファイル所有者によって実行されます。すべてのファイルは 0644 に設定され、すべてのディレクトリは 0755 に設定され、所有者のみが書き込み可能、(ウェブサーバーを含む)その他は閲覧のみ可能になります。
  
 
== Database security ==
 
== Database security ==

2010年6月13日 (日) 20:32時点における版

このページ「WordPress の安全性を高める」は未翻訳です。和訳や日本語情報を加筆してくださる協力者を求めています

セキュリティは重要なトピックで、灰色の部分が多くあります。WordPress 開発者はセキュリティを非常に重要なものと考えています。しかし、他のシステム同様、潜在的にはセキュリティ上の問題があるかもしれません。また、セキュリティと利便性のバランスは常にトレードオフの関係にあります。WordPress を安全に保つために行うことができる普遍的なことをいくつか紹介します。

セキュリティとは? 基本的には、セキュリティは、クラックすることが全く不可能なシステムではありません。そういうシステムは、見つける/維持するのが不可能でしょう。セキュリティは、信頼と責任に関するものです。例えば、信頼できるホスティング業者は、(Apache、IIS、あるいはその他の)ウェブサーバーの安定した、パッチの当てられたブランチを実行しています。ホスティング業者は利用者にそう伝えるべきです。また自身で行った設定をテストするべきです。そして、決断するのは利用者自身です。信頼できないホスティング業者は、パッチがリリースされても適用せず、実行しているバージョンを利用者に通知しません。

このガイドにそっていくつかのテーマが実行されています。

  1. アクセスの制限: 悪意ある人物が利用可能な潜在的な入り口を効果的に減らす選択をします。
  2. 抑制: あなたのインストールの弱点を悪意ある人物が発見した場合に備え、システム内部で実行できる損害を最小化するようにシステムを設定すべきです。
  3. 知識: バックアップを取り、定期的に WordPress インストールの状態を知り、WordPress インストールを理解しやすいよう、行った変更をドキュメント化しておきましょう。

ローカルコンピュータの脆弱性

WordPress に投稿するコンピュータが、スパイウェア、マルウェア、アドウェア、ウイルス感染していないことを確かめましょう。またアプリケーションが安全で安定したバージョンであることを確かめましょう。例えば、キーロガーが仕込まれていれば、以下の対策はほとんど無意味になってしまいます。

WordPress パッケージの脆弱性

プログラムを書いた結果、WordPress に脆弱性があるかもしれません。攻撃者が HTTP 引数、不正な URI 文字列、フォーム入力などを渡して悪いことを行うかもしれません。

この問題に対処する方法は、次の二つです。

  1. WP のバージョンを常に最新にする: WordPress 開発者は、古いバージョンの WordPress のセキュリティパッチ当てを行いません。新バージョンがリリースされるか、脆弱性が修復されたら、脆弱性を利用するのに必要な情報はほとんど公開され、古いバージョンは、スクリプトキディが簡単に攻撃できます。WordPress インストールを複数管理している場合は、Subversion Installing/Updating_WordPress_with_Subversion、Subversion に付随するスクリプトを使用してチェックアウトし、最新版にすることを考えるべきでしょう。[[1]]
  2. バグを報告する: バグだと思うものを見つけた場合は、報告してください。詳しくは、Submitting_Bugs をごらんください。脆弱性、または脆弱性に繋がるバグを見つけたかもしれません。セキュリティ上の問題を見つけたと思う場合の報告方法については、Security FAQ をごらんください。

サーバーの脆弱性

WordPress を実行しているウェブサーバー、WordPress データのあるデータベース、プラグインで使用される PHP およびその他のスクリプト/プログラム言語あるいはヘルパーアプリケーションに脆弱性があるかもしれません。ウェブサーバー、データベース、スクリプトインタプリタが安全で安定したバージョンであることを確かめるか、これらの作業を行う信頼できるホスティング業者を使用しているか確かめてください。

共有サーバー(同じサーバー上に他人が同居)において忠告すべきことがあります。誰かが感染すると、たとえこのガイドにしたがっていた場合でも、あなたも感染してしまう可能性が高いです。使用している web host がどのようなセキュリティ対策を行っているか確かめておいてください。

ネットワークの脆弱性

ネットワークの両端、WordPress サーバーサイドとクライアントサイド、は信頼できるべきです。つまり、家のルータのファイアウォールルールをアップデートし、どのネットワークから作業するかについて注意すべきです。例えば、混雑したインターネットカフェで、暗号化されていない無線接続で平文でパスワードを送信するのは、信頼できるネットワークではありません。 ホスティング業者は、ハッカーによって汚染されていないことを確かめるべきですし、あなたもそうすべきです。ネットワークに脆弱性があると、スニファやその他の破壊(中間者攻撃など)の発生をゆるしてしまうかもしれません。

パスワード

良いセキュリティ習慣により、いくつかの脆弱性は回避可能です。これが重要なのは、パスワードです。自分の名前をパスワードにしたり、(どんな言語であれ)辞書にある語をパスワードにしたあり、4 文字の数字をパスワードにしたりしてはいけません。パスワードの目的は、検索空間を可能な限り巨大にすることです。数字や大文字小文字を混在させると、統計的にブルートフォースを難しくします。管理者アカウントを別の名前にしていない場合は特に重要です。この場合、悪意あるユーザーは難問の半分を既に解いています。どのユーザー名が、ファイルやデータベースを編集する特権を持っているか知っています。 インターネット上に多くのパスワード自動生成が硬化いされており、安全なパスワードを作成するのに使用できます。

ファイルパーミッション

WordPress の便利な機能のいくつかは、ウェブサーバーがファイルに書き込みできることに基づいています。しかし、アプリケーションがファイルに書き込み権限を持つことは危険です。公開環境では特に危険です。

セキュリティの観点からベストなのは、ファイルパーミッションを可能な限り制限して、書き込み権限が必要な時のみ制限を緩くする、あるいは画像アップロード等の目的のために制限の緩い特別のフォルダを作成することです。

考えられるパーミッションスキーマの1つを示します。

すべてのファイルの所有者はあなたのユーザーアカウントで、あなたのみ書き込み可能。WordPress が書き込み権限を必要とするファイルは、ウェブサーバーで使用するユーザーアカウントのグループ所有。

  • / -- ルート Wordpress ディレクトリ: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
    • 例外 .htaccess もし WordPress でリライト規則を自動生成したい場合
  • /wp-admin/ -- WordPress 管理領域: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
  • /wp-includes/ -- WordPress アプリケーションロジックの大半: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
  • /wp-images/ -- WordPress が使用する画像ファイル: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
  • /wp-content/ -- ユーザー提供の様々なコンテンツ: 開発者 により、すべて(所有者、グループ、全体)で書き込み可能に意図されている。
    • /wp-content/themes/ -- テーマファイル。ビルトインテーマエディタを使用する場合は、グループに書き込み権限を与える。ビルトインテーマエディタを使用しない場合は、あなたのユーザーアカウントでのみ書き込み可能。
    • /wp-content/plugins/ -- プラグインファイル: すべてのファイルは、あなたのユーザーアカウントでのみ書き込み可能。
    • /wp-content/ の他のディレクトリは、プラグイン/テーマの要求次第で異なる。
  • サーバーへのシェルアクセスが可能な場合は、以下のコマンドでファイルパーミッションを再帰的に変更できます。

ディレクトリ
find [your path here] -type d -exec chmod 755 {} \;
ファイル
find [your path here] -type f -exec chmod 644 {} \;
/wp-includes/ にはこのコマンドを使用してはいけません。

共有サーバーの場合は、wp-config.php のパーミッションを 750 にすべきです。他のユーザーがデータベースユーザー名とパスワードを閲覧できないようにします。FTP またはシェルアクセスで、以下を行ってください。
chmod 750 wp-config.php

自動アップグレードに関して

Version 2.7 から、WordPress は自動アップグレードが可能になりました。すべてのファイル素すさは、ウェブサーバーのユーザーではなく、ファイル所有者によって実行されます。すべてのファイルは 0644 に設定され、すべてのディレクトリは 0755 に設定され、所有者のみが書き込み可能、(ウェブサーバーを含む)その他は閲覧のみ可能になります。

Database security

If you run multiple blogs on the same server, it is wise to consider keeping them in separate databases each managed by a different user. This is best accomplished when performing the initial WordPress installation. This is a containment strategy: if an intruder successfully cracks one of WordPress installation, this makes it that much harder to alter your other blogs.

If you administer MySQL yourself, ensure that you understand your MySQL configuration and that unneeded features (such as accepting remote TCP connections) are disabled. See Secure MySQL Database Design for a nice introduction.

Securing wp-admin

You can greatly enhance the security of your blog by adding additional access control to your /wp-admin/ folder using the AskApache Password Protection plugin. This plugin also secures your /wp-login.php file, and all files in your /wp-includes/ and /wp-content/ folders.

Caution: Installing the AskApache Password Protection plugin may lock you out of your WordPress Admin panel and return an error 500 when you attempt to go to yourdomain.com/wp-admin. You might try installing the plugin on a test site first, as your server or other configurations may cause issues. To uninstall the plugin, first delete the new .htaccess file that appears inside your wp-admin folder. Then log in to your site and deactivate (and then possibly delete) the plugin. See the comments under the author's plugin home page to read other users' experiences with this plugin.

Adding server-side password protection to /wp-admin/ adds a 2nd layer of protection around your blog's admin area, login, and files. This forces an attacker or bot to attack this 2nd layer of protection instead of your actual admin files. Most of the time WordPress attacks are carried out autonomously by a malicious software bot.

The most common attacks against a WordPress blog usually fall into 2 categories.

  1. Sending specially-crafted HTTP requests to your server with specific exploit payloads for specific vulnerabilities. These include old/outdated plugins and software.
  2. Attempting to gain access to your blog by using "brute-force" password guessing.

By adding a 2nd layer of protection around these important files you force the attackers to have to break through that before they can even attempt to attack your main /wp-admin/. This protection uses Basic HTTP Authentication, the password is passed over the network uuencoded as plain text, not encrypted. The main benefit of this protection is in denying access to your servers files and alerting you to an attack against your blog before the attack reaches your /wp-admin/ doorstep.

The ultimate implementation of this "2nd layer" password protection is to require an HTTPS SSL encrypted connection for your /wp-admin/ directory, so that all communications and sensitive data is encrypted.

Securing wp-config.php

You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed in the root of your webspace, you can store wp-config.php outside the web-root folder. Note that wp-config.php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make sure that only you (and the web server) can read this file (it generally means a 750 permission).

SSL Encryption Security

WordPress 2.6 and later has greatly improved support for Administration Over SSL out of the box.

Plugins

First of all, make sure your plugins are always updated. Also, if you are not using a specific plugin, make sure to delete it from the system.

Security Plugins

The WP Security Scan Plugin can be downloaded at WP Security Scan. While this helps tremendously to protect your WordPress installation, you still need to maintain good passwords, check plugins and themes before installing them, and keep good backups of your files and database in the event that you do get hacked.

Firewall Plugins

There are a few plugins that purport to screen out suspicious-looking requests based on rule databases and/or whitelists. BlogSecurity's WPIDS plugin installs PHPIDS, a generic security layer for PHP applications, while WordPress Firewall uses some WordPress-tuned pre-configured rules along with a whitelist to screen out attacks without much configuration.

Plugins that need write access

If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. Possible places to check are the Support Forums and IRC Channel.

Code execution plugins

As we said, part of the goal of hardening WordPress is containing the damage done if there is a successful attack. Plugins which allow arbitrary PHP or other code to execute from entries in a database effectively magnify the possibility of damage in the event of a successful attack.

A way to avoid using such a plugin is to use custom page templates that call the function. Part of the security this affords is active only when you disallow file editing within WordPress.


Security through obscurity

Security through obscurity is typically thought to be an unsound primary strategy. However, there are areas in WordPress where obscuring information might help with security:

  1. Rename the administrative account: On a new install you can simply create a new Administrative account and delete the default admin account. On an existing WordPress install you may rename the existing account in the MySQL command-line client with a command like update tableprefix_users set user_login='newuser' where user_login='admin';, or by using a MySQL frontend like phpMyAdmin.
  2. Change the table_prefix: Many published WordPress-specific SQL-injection attacks make the assumption that the table_prefix is "wp_," the default. Changing this probably amounts to security by obscurity, but will block at least some SQL-injection attacks.
  3. Do not advertise the WordPress version you are running: If you are running an old WordPress version with known vulnerabilities, it is unwise to display this information to the public. Why not simply hide the WordPress version entirely? Even if you update packages as quickly as you can, there will be lag between the version release and your deployment, potentially enough time for a malicious person to carry out an attack. However, editing out all the places where WordPress advertises its version string (e.g., <meta name="generator" content="WordPress 2.9" /> in every page) in your theme can be a pain. It is still best to make sure you are running the latest WordPress version. An easier way to do this is with the Replace WP-Version, Secure WordPress, or WP-Secure Remove Wordpress Version plugins. If you want to remove this line without a plugin, you can simply add <?php remove_action('wp_head', 'wp_generator'); ?> to your theme's function.php file. Please Note: This does NOT prevent WordPress exploits being attempted against your site, as modern worms ignore the version in their exploit attempts (Note: There are many ways of determining the WordPress version a site uses, the "generator" is a rarely used method.)

Data backups

Backup your data regularly, including your MySQL databases (see Backing Up Your Database). Data integrity is critical for trusted backups. Encrypting the backup, keeping an independent record of MD5 hashes for each backup file, and/or placing backups on read-only media (such as CD-R) increases your confidence that your data has not been tampered with.

A sound backup strategy could include keeping a set of regularly-timed snapshots of your entire WordPress installation (including WordPress core files and your database) in a trusted location. Imagine a site that makes weekly snapshots. Such a strategy means that if a site is compromised on May 1st but the compromise is not detected until May 12th, the site owner will have pre-compromise backups that can help in rebuilding the site and possibly even post-compromise backups which will aid in determining how the site was compromised.

Logging

It is possible to log all $POST variables sent to WordPress. Standard Apache logs do not offer much help with dealing with security forensics.

Monitoring

Sometimes prevention is not enough and you may still be hacked. That's why intrusion detection/monitoring is very important. It will allow you to react faster, find out what happened and recover your blog back in place.

Monitoring your logs

If you are on a private server (where you have admin access), you have to watch your logs to detect password guessing attempts, web attacks, etc. A good open source solution to monitor your logs in real time and block the attacker is OSSEC.

Monitoring your files for changes

When an attack happens, it always leave traces. Either on the logs or on the file system (new files, files modified, etc). If you are using http://www.ossec.net OSSEC] that we recommended above, it will monitor your files and alert when they change as well. You can also use the open sourceTripwire to alert on file changes.

Monitoring your web server externally for malware and changes

If the attacker tries to deface your site or add malware, you can also detect these changes by using a web-based integrity monitor solution.

See Also

最新英語版: WordPress Codex » Hardening_WordPress最新版との差分