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

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

提供: WordPress Codex 日本語版
移動先: 案内検索
(プラグイン: まで翻訳)
(翻訳完了。セキュリティに関する記事なので皆で確認してください。)
1行目: 1行目:
{{NeedTrans}}
+
{{CheckTrans}}
 
セキュリティは重要なトピックで、灰色の部分が多くあります。WordPress 開発者はセキュリティを非常に重要なものと考えています。しかし、他のシステム同様、潜在的にはセキュリティ上の問題があるかもしれません。また、セキュリティと利便性のバランスは常にトレードオフの関係にあります。WordPress を安全に保つために行うことができる普遍的なことをいくつか紹介します。
 
セキュリティは重要なトピックで、灰色の部分が多くあります。WordPress 開発者はセキュリティを非常に重要なものと考えています。しかし、他のシステム同様、潜在的にはセキュリティ上の問題があるかもしれません。また、セキュリティと利便性のバランスは常にトレードオフの関係にあります。WordPress を安全に保つために行うことができる普遍的なことをいくつか紹介します。
  
124行目: 124行目:
 
== 隠蔽によるセキュリティ ==
 
== 隠蔽によるセキュリティ ==
  
[http://en.wikipedia.org/wiki/Security_through_obscurity#Open_source_repercussions 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: 
+
[http://en.wikipedia.org/wiki/Security_through_obscurity#Open_source_repercussions Security through obscurity(隠蔽によるセキュリティ)] は、典型的には、基本戦略として健全でない、と考えられています。しかし、WordPress のある領域では、情報を隠蔽することがセキュリティの助けになる''ことがあるかもしれません''
  
# '''Rename the administrative account:''' On a new install you can simply create a new Administrative account and delete the default <code>admin</code> account. On an existing WordPress install you may rename the existing account in the MySQL command-line client with a command like <code>update tableprefix_users set user_login='newuser' where user_login='admin';</code>, or by using a MySQL frontend like [[phpMyAdmin]].
+
# '''管理者アカウント名の変更:''' 新規インストール時に、新しい管理者アカウントを作成し、(WP2.9 以前で)デフォルトの <code>admin</code> アカウントを削除します。既存の WordPress インストールでは、MySQL コマンドラインクライアントで <code>update tableprefix_users set user_login='newuser' where user_login='admin';</code> のようなコマンドを入力するか、[[phpMyAdmin]] のような MySQL フロントエンドを使用して、名前を変更しても良いでしょう。
# '''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. 
+
# '''table_prefix の変更:'''  多くの既知の WordPress を狙った SQL インジェクション攻撃は、table_prefix がデフォルトの "wp_" であることを仮定しています。これを変更することは、隠蔽によるセキュリティですが、SQL インジェクション攻撃の一部は防ぐことができます。
# '''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., <nowiki><meta name="generator" content="WordPress 2.9" /></nowiki> 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 [http://wordpress.org/extend/plugins/replace-wp-version/ Replace WP-Version], [http://wordpress.org/extend/plugins/secure-wordpress/ Secure WordPress], or [http://wordpress.org/extend/plugins/wp-secure-remove-wordpress-version/ WP-Secure Remove Wordpress Version] plugins. If you want to remove this line without a plugin, you can simply add <code><?php remove_action('wp_head', 'wp_generator'); ?></code> 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.)
+
# '''動作中の WordPress バージョンを公開しない:'''  既知の脆弱性のある古いバージョンの WordPress を動作させている場合は、バージョン情報を公開するのは賢明ではありません。WordPress バージョンを画してしましましょう。可能な限り最新に更新しているとしても、リリースとデプロイにはタイムラグがあり、悪意ある者が攻撃を実行するのに十分な時間かもしれません。しかし、テーマファイルの WordPress のバージョン(例えば、<nowiki><meta name="generator" content="WordPress 2.9" /></nowiki>) を全て取り除くのは大変です。最新バージョンの WordPress を使用しているのを確実にするのが最良でしょう。簡単な方法として、[http://wordpress.org/extend/plugins/replace-wp-version/ Replace WP-Version][http://wordpress.org/extend/plugins/secure-wordpress/ Secure WordPress]、あるいは [http://wordpress.org/extend/plugins/wp-secure-remove-wordpress-version/ WP-Secure Remove Wordpress Version] といったプラグインがあります。この行をプラグインを使わないで取り除くには、テーマの function.php ファイルに <code><?php remove_action('wp_head', 'wp_generator'); ?></code> を追加してください。 '''注意:''' これは、あなたのサイトの WordPress 攻撃を防ぐものではありません。現在のワームはバージョンを無視します。(注意: 使用している WordPress バージョンを決定する方法は多くあり、"generator" はあまり使用されていません。)
  
 
== データバックアップ ==
 
== データバックアップ ==
  
Backup your data regularly, including your MySQL databases (see [[Backing_Up_Your_Database|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.
+
データを定期的にバクアップしましょう。MySQL データベース ([[Backing_Up_Your_Database|Backing Up Your Database]] を参照) もです。データ保全は、信頼できるバックアップに大切です。バックアップを暗号化し、各バックアップファイルに独立した MD5 ハッシュをつけ、バックアップを読み込み専用メディア (CD-R など) に保存すると、データが改変されていない、という信頼性が高まります。
  
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.
+
健全なバックアップ戦略は、WordPress インストール全体も含む (WordPress コアファイルとデータベースを含む) 定期的なバックアップを信頼できる場所に保管することです。毎週バックアップするサイトを考えてみましょう。5月1日に感染し、5月12日まで発見されなかった場合、サイトオーナーは、サイトを再構築する助けとなる感染前のバックアップを持っており、感染後のバックアップはサイトが感染した方法を決定する助けとなるでしょう。
  
 
== ロギング ==
 
== ロギング ==
  
It is possible to log all $POST variables sent to WordPress. Standard Apache logs do not offer much help with dealing with security forensics.
+
WordPress に送信される全ての $POST 変数をログを取ることが可能です。標準 Apache ログはセキュリティ鑑識には、さほど助けにならないでしょう。
  
 
* [http://www.modsecurity.org/ Mod_Security - Logs and Prevents using Apache]
 
* [http://www.modsecurity.org/ Mod_Security - Logs and Prevents using Apache]
144行目: 144行目:
 
== モニタリング ==
 
== モニタリング ==
  
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.
+
ときには、予防策が十分でなく、攻撃されることがあります。このため、侵入の検知/監視が非常に重要です。すぐに対策を取ることができ、何が起きたかを把握し、ブログを元に回復することができるでしょう。
  
=== ログのモニタリング ===
+
=== ログの監視 ===
  
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 [http://www.ossec.net OSSEC].
+
(admin アクセス権限のある)占有サーバーでは、パスワード推測試行、ウェブアタック等を検知するためにログを見る必要があります。リアルタイムでログを監視し、攻撃を防ぐ、優れたオープンソースソリューションは [http://www.ossec.net OSSEC] です。
  
=== ファイル変更のモニタリング ===
+
=== ファイル変更の監視 ===
  
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 source[http://www.tripwire.org Tripwire] to alert on file changes.
+
攻撃が発生すると、必ず痕跡が残ります。ログまたはファイルシステム(新規ファイル、変更されたファイル等)です。上で推奨している [http://www.ossec.net OSSEC] を使用している場合、ファイルを監視し、変更があるとアラートします。ファイル変更のアラートには、オープンソース [http://www.tripwire.org Tripwire] を使用することもできます。
  
=== 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 ==
+
== 参考 ==
  
 
* [[Security FAQ]]
 
* [[Security FAQ]]

2010年6月18日 (金) 19:32時点における版

この項目「WordPress の安全性を高める」は、翻訳チェック待ちの項目です。加筆、訂正などを通して、Codex ドキュメンテーションにご協力下さい。

セキュリティは重要なトピックで、灰色の部分が多くあります。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 に設定され、所有者のみが書き込み可能、(ウェブサーバーを含む)その他は閲覧のみ可能になります。

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

同一サーバー上で複数のブログを実行している場合は、それらを別のデータベースに格納し、異なるユーザーが管理するのが賢明でしょう。最初のWordPressのインストールで実行するのがもっとも達成しやすいでしょう。これは、抑制戦略です。もし侵略者が WordPress インストールのいずれかのクラッキングに成功した場合、他のブログを改変するのが難しくなるでしょう。

MySQL をあなたが管理している場合は、MySQL 設定を理解しているか確認し、(外部 TCP 接続を受け入れるなどの)不要な機能が無効になっていることを確認してください。MySQL の優れた入門については、Secure MySQL Database Design をごらんください。

wp-admin を安全にする

AskApache Password Protection plugin を使用して /wp-admin/ フォルダにアクセス制限を追加することにより、セキュリティを大きく高めることができます。このプラグインは、/wp-login.php ファイル、/wp-includes//wp-content/ フォルダ内のすべてのファイルを安全にします。

警告: AskApache Password Protection プラグインをインストールすると、あなたが WordPress 管理パネルから追い出され、yourdomain.com/wp-admin にアクセスしようとすると 500 エラーが返されるかもしれません。サーバーあるいはその他の設定が問題になるかもしれないので、まずテストサイトでこのプラグインを試しにインストールしてください。このプラグインをアンインストールするには、まず wp-admin フォルダの新しい .htaccess ファイルを削除してください。その後、ログインし、プラグインを無効化(たいていはさらに削除)してください。このプラグインについて他のユーザーの体験を読むには、comments under the author's plugin home page をごらんください。

サーバーサイドで /wp-admin/ にパスワードを追加すると、ブログ管理領域、ログイン、ファイルに第二層の保護を追加します。攻撃者またはボットは、実際の管理ファイルではなく、第二層の保護を攻撃する必要があります。ほとんどの場合、WordPress への攻撃は、悪意あるソフトウェアボットが自動実行しています。

WordPress ブログへのよくある攻撃は、以下の 2 カテゴリに分類されます。

  1. 特定の脆弱性を食い物にする特別な細工をした HTTP 要求をサーバーに送信する。古い/更新されていないプラグインやソフトウェアへの攻撃も含む。
  2. 「ブルートフォース」パスワード推測により、ブログへアクセスを試みる。

重要なファイルに第二層の保護を追加することで、攻撃者は、/wp-admin/ に攻撃を仕掛ける前に、これを突破する必要があります。この保護は、Basic HTTP Authentication を使用し、パスワードは平文で、暗号化されずにネットワークに流れます。この保護の主な利点は、サーバーファイルへのアクセスを拒否し、あなたのブログへの攻撃が /wp-admin/ の入り口に達する前に警告が発生することです。

"第二層"パスワード保護の完全な実装をするには、/wp-admin/ ディレクトリに HTTPS SSL 暗号化接続し、すべての通信と重要なデータを暗号化することが必要です。

wp-config.php を安全にする

wp-config.php ファイルを、WordPress をインストールした階層の一つ上に移動することができます。ウェブスペースのルートにインストールしている場合、wp-config.php をウェブルートの外側に格納できます。wp-config.php が、WordPress (wp-includes のある場所) インストールの一つ上のディレクトリに格納できることに注意してください。また、あなた(とウェブサーバー)だけがこのファイルを閲覧可能(通常は 750 パーミッション)にしてください。

SSL 暗号化セキュリティ

WordPress 2.6 以降では、Administration Over SSL のサポートが飛躍的に向上しています。

プラグイン

まず、利用しているプラグインが常に最新に更新されていることを確かめてください。また、使用していないプラグインはシステムから削除するようにしてください。

セキュリティプラグイン

WP Security Scan プラグインは、WP Security Scan からダウンロードできます。あなたの WordPress インストールを保護するのに役立ちますが、それでも、ハッキングに備え、良いパスワードを維持することや、プラグインやテーマをインストールする前に調べることや、ファイルやデータベースをバックアップしておくことが必要です。

ファイアウォールプラグイン

ルールデータベースおよび/またはホワイトリストにより、怪しい要求を排除するプラグインがあります。 BlogSecurity's WPIDS pluginPHPIDS、PHP アプリケーションの一般セキュリティレイヤー、をインストールします。WordPress Firewall は、WordPress 向けに設定されたルールとホワイトリストで、様々な設定をすることなく攻撃を排除します。

書き込み権限を必要とするプラグイン

プラグインが WordPress ファイルとディレクトリに書き込み権限を要求する場合は、コードを読んで合法であることを確認するか、信頼できる人にチェックしてもらうようにしてください。チェックする場所は、Support ForumsIRC Channel です。

コードを実行するプラグイン

上述のとおり、WordPress を強固にする目的には、攻撃が成功した場合の被害を抑えることが含まれます。データベースのエントリから任意の PHP やコード実行を許可するプラグインは、攻撃が成功した場合の被害が非常に大きくなります。

これらのプラグインを避ける方法の一つは、関数を呼び出すcustom page templates を使用することです。このセキュリティの一部は、WordPress でファイル編集を無効にする 場合にのみ有効です。

隠蔽によるセキュリティ

Security through obscurity(隠蔽によるセキュリティ) は、典型的には、基本戦略として健全でない、と考えられています。しかし、WordPress のある領域では、情報を隠蔽することがセキュリティの助けになることがあるかもしれません

  1. 管理者アカウント名の変更: 新規インストール時に、新しい管理者アカウントを作成し、(WP2.9 以前で)デフォルトの admin アカウントを削除します。既存の WordPress インストールでは、MySQL コマンドラインクライアントで update tableprefix_users set user_login='newuser' where user_login='admin'; のようなコマンドを入力するか、phpMyAdmin のような MySQL フロントエンドを使用して、名前を変更しても良いでしょう。
  2. table_prefix の変更: 多くの既知の WordPress を狙った SQL インジェクション攻撃は、table_prefix がデフォルトの "wp_" であることを仮定しています。これを変更することは、隠蔽によるセキュリティですが、SQL インジェクション攻撃の一部は防ぐことができます。
  3. 動作中の WordPress バージョンを公開しない: 既知の脆弱性のある古いバージョンの WordPress を動作させている場合は、バージョン情報を公開するのは賢明ではありません。WordPress バージョンを画してしましましょう。可能な限り最新に更新しているとしても、リリースとデプロイにはタイムラグがあり、悪意ある者が攻撃を実行するのに十分な時間かもしれません。しかし、テーマファイルの WordPress のバージョン(例えば、<meta name="generator" content="WordPress 2.9" />) を全て取り除くのは大変です。最新バージョンの WordPress を使用しているのを確実にするのが最良でしょう。簡単な方法として、Replace WP-VersionSecure WordPress、あるいは WP-Secure Remove Wordpress Version といったプラグインがあります。この行をプラグインを使わないで取り除くには、テーマの function.php ファイルに <?php remove_action('wp_head', 'wp_generator'); ?> を追加してください。 注意: これは、あなたのサイトの WordPress 攻撃を防ぐものではありません。現在のワームはバージョンを無視します。(注意: 使用している WordPress バージョンを決定する方法は多くあり、"generator" はあまり使用されていません。)

データバックアップ

データを定期的にバクアップしましょう。MySQL データベース (Backing Up Your Database を参照) もです。データ保全は、信頼できるバックアップに大切です。バックアップを暗号化し、各バックアップファイルに独立した MD5 ハッシュをつけ、バックアップを読み込み専用メディア (CD-R など) に保存すると、データが改変されていない、という信頼性が高まります。

健全なバックアップ戦略は、WordPress インストール全体も含む (WordPress コアファイルとデータベースを含む) 定期的なバックアップを信頼できる場所に保管することです。毎週バックアップするサイトを考えてみましょう。5月1日に感染し、5月12日まで発見されなかった場合、サイトオーナーは、サイトを再構築する助けとなる感染前のバックアップを持っており、感染後のバックアップはサイトが感染した方法を決定する助けとなるでしょう。

ロギング

WordPress に送信される全ての $POST 変数をログを取ることが可能です。標準 Apache ログはセキュリティ鑑識には、さほど助けにならないでしょう。

モニタリング

ときには、予防策が十分でなく、攻撃されることがあります。このため、侵入の検知/監視が非常に重要です。すぐに対策を取ることができ、何が起きたかを把握し、ブログを元に回復することができるでしょう。

ログの監視

(admin アクセス権限のある)占有サーバーでは、パスワード推測試行、ウェブアタック等を検知するためにログを見る必要があります。リアルタイムでログを監視し、攻撃を防ぐ、優れたオープンソースソリューションは OSSEC です。

ファイル変更の監視

攻撃が発生すると、必ず痕跡が残ります。ログまたはファイルシステム(新規ファイル、変更されたファイル等)です。上で推奨している OSSEC を使用している場合、ファイルを監視し、変更があるとアラートします。ファイル変更のアラートには、オープンソース Tripwire を使用することもできます。

悪意ある変更に備えて外部からウェブサーバーを監視する

攻撃者がサイトを書き換えたり、マルウェアを追加しようとするとき、ウェブベースの改善検知ソリューションを使用して、これらの変更を検知することができます。

参考

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