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

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

提供: WordPress Codex 日本語版
移動先: 案内検索
(ファイル編集の無効化)
(Apache 2.4以降の記述を追記)
 
(6人の利用者による、間の13版が非表示)
1行目: 1行目:
{{NeedTrans|一部}}
+
WordPress ではセキュリティを[https://wordpress.org/about/security/ 非常に重要なもの]と考えています。しかし、他のどんなシステムでも同様ですが、基本的なセキュリティ対策がなされていない場合には問題が発生する可能性はあります。このページでは、よくある脆弱性について、そして WordPress を安全に保つためにできることを紹介します。
 
+
WordPress ではセキュリティを非常に重要なものと考えています。しかし、他のどんなシステムでも同様ですが、基本的なセキュリティ対策がなされていない場合には問題が発生する可能性はあります。このページでは、よくある脆弱性について、そして WordPress を安全に保つためにできることを紹介します。
+
  
 
このページはセキュリティに対する心配を一掃するその場限りの応急措置とは違います。特定のセキュリティ問題や不明な点を抱えている場合は、コンピューターセキュリティの知識を十分に持っている信頼のおける人ときちんと話し合うべきです。
 
このページはセキュリティに対する心配を一掃するその場限りの応急措置とは違います。特定のセキュリティ問題や不明な点を抱えている場合は、コンピューターセキュリティの知識を十分に持っている信頼のおける人ときちんと話し合うべきです。
24行目: 22行目:
 
# '''抑制:'''  インストールの弱点を悪意ある人物が発見した場合に備え、システム内部で実行できる損害を最小化するようにシステムを設定する。
 
# '''抑制:'''  インストールの弱点を悪意ある人物が発見した場合に備え、システム内部で実行できる損害を最小化するようにシステムを設定する。
 
# '''知識:'''  バックアップを取り、定期的に WordPress インストールの状態を知り、WordPress インストールを理解しやすいよう、行った変更をドキュメント化しておく。
 
# '''知識:'''  バックアップを取り、定期的に WordPress インストールの状態を知り、WordPress インストールを理解しやすいよう、行った変更をドキュメント化しておく。
 +
# '''信頼できるソース''': テーマやプラグインを信頼できないソースから入手するのはやめて、WordPress.org 公式レポジトリまたはよく知られた信頼のおける企業などからのダウンロードに制限する。それ以外から入手することで[http://blog.sucuri.net/2014/03/unmasking-free-premium-wordpress-plugins.html 問題が発生することがある]。
  
 
== ローカルコンピュータの脆弱性 ==
 
== ローカルコンピュータの脆弱性 ==
29行目: 28行目:
 
WordPress に投稿するコンピュータが、スパイウェア、マルウェア、ウイルスに感染していないことを確かめましょう。またアプリケーションが安全で安定したバージョンであることを確かめましょう。例えば[http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%BC%E3%83%AD%E3%82%AC%E3%83%BC キーロガー]が仕込まれていた場合、WordPress や Web サーバーのセキュリティ対策は全く意味をなさなくなってしまいます。
 
WordPress に投稿するコンピュータが、スパイウェア、マルウェア、ウイルスに感染していないことを確かめましょう。またアプリケーションが安全で安定したバージョンであることを確かめましょう。例えば[http://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%BC%E3%83%AD%E3%82%AC%E3%83%BC キーロガー]が仕込まれていた場合、WordPress や Web サーバーのセキュリティ対策は全く意味をなさなくなってしまいます。
  
OS とソフトウェアは常に最新版にしておきましょう。特に、セキュリティ脆弱性からパソコンを保護するために Web ブラウザを最新版に更新しておくことが大事です。
+
OS とソフトウェアは常に最新版にしておきましょう。特に、セキュリティ脆弱性からパソコンを保護するために Web ブラウザを最新版に更新しておくことが大事です。信頼できないサイトを閲覧しているなら、[http://noscript.net NoScript] などのツールを使うかブラウザの JavaScript/Flash/Java を無効にすることをおすすめします。
  
 
== WordPress パッケージの脆弱性 ==
 
== WordPress パッケージの脆弱性 ==
  
多くの現代的なソフトウェアパッケージと同様、WordPress は新しいセキュリティ関連の問題が発生すると定期的に更新されています。ソフトウェアのセキュリティを改善していくのは常に進行形の懸案事項であり、このため、'''最新バージョンの  WordPress に常に更新すべきです'''。WordPress の旧バージョンは、セキュリティアップデートに対してメンテナンスされていません。
+
多くの現代的なソフトウェアパッケージと同様、WordPress は新しいセキュリティ関連の問題が発生すると定期的に更新されています。ソフトウェアのセキュリティを改善していくのは常に進行形の懸案事項であり、このため、'''最新バージョンの WordPress に常に更新すべきです'''。WordPress の旧バージョンはセキュリティアップデートに対してメンテナンスされていません。
  
 
=== WordPress の更新 ===
 
=== WordPress の更新 ===
39行目: 38行目:
 
メイン記事: [[WordPress のアップグレード]]
 
メイン記事: [[WordPress のアップグレード]]
  
最新版の WordPress は、WordPress 公式サイト([http://wordpress.org/ http://wordpress.org/])または日本語版公式サイト([http://ja.wordpress.org/ http://ja.wordpress.org/])から入手できます。公式リリースはこれ以外のサイトからはリリースされません。wordpress.org ドメイン以外からは'''絶対に''' WordPress をインストール・アップグレードしないでください。
+
最新版の WordPress は、WordPress 公式サイト ( https://wordpress.org/ ) または日本語版公式サイト ( https://ja.wordpress.org/ ) から入手できます。公式リリースはこれ以外のサイトからはリリースされません。wordpress.org ドメイン以外からは'''絶対に''' WordPress をインストール・アップグレードしないでください。
  
バージョン2.7以降、WordPressの特徴として自動アップデートがあります。最新の状態に維持するために、この機能を使用してください。また、ワードプレスのダッシュボードには更新に関する情報が表示されます。更新を行いセキュリティを保つために、ダッシュボード内の情報またはWordPressの開発者ブログを読んでください。
+
バージョン3.7で WordPress は自動アップデート機能を導入しました。最新の状態に維持するためにこの機能を利用してください。また、WordPress のダッシュボードには更新に関する情報が表示されます。更新を行いセキュリティを保つため、ダッシュボード内の情報または WordPress 開発者ブログを読むようにしてください。
  
WordPressで脆弱性が発見された問題に対処する新しいバージョンがリリースされる場合は、この脆弱性を悪用するための
+
脆弱性が発見された問題に対処する新しい WordPress のバージョンがリリースされるほとんどの場合には、この脆弱性を悪用するための情報が公開されています。これにより古いバージョンではより攻撃を受けやすくなるため、WordPress を常に最新の状態にする主な理由の一つといえます。
情報が殆どの場合公開されています。古いバージョンではより攻撃を受けやすくなるため、WordPressを常に最新の状態にする主な理由の一つです。
+
  
複数のWordPressをインストールする管理者は、管理を容易にするために[[Installing/Updating_WordPress_with_Subversion|Subversion]] 等のバージョン管理ソフトウェアを使用することを検討してください。
+
複数の WordPress をインストールする管理者は、管理を容易にするために [[Installing/Updating_WordPress_with_Subversion|Subversion]] などのバージョン管理ソフトを使用することを検討してください。
  
 
=== セキュリティ上の問題の報告 ===
 
=== セキュリティ上の問題の報告 ===
52行目: 50行目:
 
WordPress 上にセキュリティ関連の問題を見つけたと思ったら、これを報告することで協力できます。セキュリティ上の問題を報告する方法については、[[FAQ/セキュリティ|セキュリティ FAQ]] をごらんください。
 
WordPress 上にセキュリティ関連の問題を見つけたと思ったら、これを報告することで協力できます。セキュリティ上の問題を報告する方法については、[[FAQ/セキュリティ|セキュリティ FAQ]] をごらんください。
  
バグだと思うものを見つけた場合は、報告してください。詳しくは、[[バグの報告]]をごらんください。脆弱性、または脆弱性に繋がるバグを見つけたという場合もあります。
+
バグだと思うものを見つけた場合は、報告してください。詳しくは[[バグの報告]]をごらんください。脆弱性、または脆弱性に繋がるバグを見つけたという場合もあります。
  
 
== サーバーの脆弱性 ==
 
== サーバーの脆弱性 ==
  
WordPress を実行しているウェブサーバー、WordPress データのあるデータベース、プラグインで使用される PHP およびその他のスクリプト/プログラム言語あるいはヘルパーアプリケーションに脆弱性があるかもしれません。ウェブサーバー、データベース、スクリプトインタプリタが安全で安定したバージョンであることを確かめるか、これらの作業を行う信頼できるホスティング業者を使用しているか確かめてください。
+
WordPress を実行しているウェブサーバー、WordPress データのあるデータベース、プラグインで使用される PHP およびその他のスクリプト・プログラム言語、またはヘルパーアプリケーションに脆弱性があるかもしれません。ウェブサーバー、データベース、スクリプトインタプリタが安全で安定したバージョンであることを確かめるか、これらの作業を行う信頼できるホスティング業者を使用しているか確かめてください。
  
共有サーバー(同じサーバー上に他人が同居)において忠告すべきことがあります。誰かが感染すると、たとえこのガイドにしたがっていた場合でも、あなたも感染してしまう可能性が高いです。使用している[http://wordpress.org/hosting/ ホスティングサービス]がどのようなセキュリティ対策を行っているか確かめておいてください。
+
共有サーバー (同じサーバー上に他の人のサイトがホスティングされている環境) で誰かのサイトが感染すると、たとえこのガイドに従っていた場合でもあなたのサイトも感染してしまう可能性があります。使用している[用語集#Hosting_provider Web ホスト] がどのようなセキュリティ対策を行っているか確かめておいてください。
  
 
== ネットワークの脆弱性 ==
 
== ネットワークの脆弱性 ==
  
ネットワークの両端、WordPress サーバーサイドとクライアントサイド、は信頼できるべきです。つまり、家のルータのファイアウォールルールをアップデートし、どのネットワークから作業するかについて注意すべきです。例えば、混雑したインターネットカフェで、暗号化されていない無線接続で平文でパスワードを送信するのは、信頼できるネットワークでは''ありません。'' ホスティング業者は、ハッカーによって汚染されていないことを確かめるべきですし、あなたもそうすべきです。ネットワークに脆弱性があると、スニファやその他の破壊 (中間者攻撃など) の発生を許してしまうかもしれません。
+
ネットワークの両端、WordPress サーバーサイドとクライアントサイド、は信頼できるべきです。つまり、家のルータのファイアウォールルールをアップデートし、どのネットワークから作業するかについて注意すべきです。無線であれ有線であれ、インターネットカフェの暗号化されていない接続でパスワードを送信するのは「信頼できるネットワーク」上の作業とは''言えません。''  
 +
 
 +
ホスティング業者は自身のネットワークがハッカーによって汚染されていないことを確かめるべきですし、あなたもそうすべきです。ネットワークに脆弱性があると、スニファやその他の破壊 (中間者攻撃など) の発生を許してしまうかもしれません。
  
 
== パスワード ==
 
== パスワード ==
68行目: 68行目:
 
セキュリティ向上のための習慣を守れば、脆弱性の多くは回避可能です。ここで重要な点のひとつに、パスワードがあります。
 
セキュリティ向上のための習慣を守れば、脆弱性の多くは回避可能です。ここで重要な点のひとつに、パスワードがあります。
  
パスワードの目的は、[[ブルートフォースアタック]]/[[:en:Brute_Force_Attacks|en]](総当たり攻撃)の成功を難しくすることです。インターネット上には多くの[http://www.google.com/?q=password+generator パスワード自動生成ツール]が公開されており、安全なパスワードを作成するために利用できます。
+
パスワードの目的は、[[ブルートフォース攻撃]]/[[:en:Brute_Force_Attacks|Brute_Force_Attacks]](総当たり攻撃)の成功を難しくすることです。インターネット上には多くの[http://www.google.com/?q=password+generator パスワード自動生成ツール]が公開されており、安全なパスワードを作成するために利用できます。
  
 
さらに、WordPress にはパスワードの強度メーターが含まれています。パスワードを変更する際にはこれを活用し、強度が十分かどうか確認しましょう。
 
さらに、WordPress にはパスワードの強度メーターが含まれています。パスワードを変更する際にはこれを活用し、強度が十分かどうか確認しましょう。
144行目: 144行目:
 
つまり、DROP / ALTER / GRANT といったデータベース構造の変更や管理のための他の権限は必要ないということです。こういった権限を取り消すことによって抑制(封じ込め)対策を改善することができます。
 
つまり、DROP / ALTER / GRANT といったデータベース構造の変更や管理のための他の権限は必要ないということです。こういった権限を取り消すことによって抑制(封じ込め)対策を改善することができます。
  
: '''注:''' 一部のプラグイン、テーマ、WordPress コアのメジャーバージョン更新においてはテーブルの追加やスキーマの変更などといったデータベース構造の変更が必要になる場合があります。こういった場合にはプラグインのインストールやソフトウェア更新の際にデータベースユーザーへの権限許可を行ってください。
+
: '''注:''' 一部のプラグイン、テーマ、WordPress コアのメジャーバージョン更新においてはテーブルの追加やスキーマの変更などといったデータベース構造の変更が必要になる場合があります。こういった場合にはプラグインのインストールやソフトウェア更新の際に、一時的にデータベースユーザーへの権限許可を行う必要があります。
 +
: '''警告:''' WordPress のバージョンアップでデータベーススキーマが変わる場合、これらの権限なしに更新しようとすれば、問題を起こす虞があります。よって、これらの権限を外すことは'''お奨めできません'''。セキュリティのために是非ともこれらの権限を外す必要があると思われる場合は、信頼性の高いバックアップ計画を策定し実施することが必要不可欠です。バックアップ計画には、定期的にデータベース全体のバックアップをとること、バックアップした内容を検証すること、そして、容易にバックアップから復元できるようにすることが必要です。データベースのアップグレードに失敗しても、バックアップからデータベースを復元し、必要な権限を付与し、そして WordPress にデータベース更新をやり直させることで、たいてい解決します。データベースは、バックアップから復元することで旧バージョンに戻るので、 WordPress の管理画面で旧バージョンが検出され、必要な SQL コマンドをまた実行させることができます。 WordPress のバージョンアップのたびにスキーマが変更されるわけではありません。スキーマが変わるのはたいていメジャーバージョンアップ(例えば 3.7 から 3.8 へ)のときであり、マイナーバージョンアップ(例えば 3.8 から 3.8.1 へ)では変わらないことが一般的です。いずれにしても、'''定期的にバックアップをとり続ける'''ことです。
  
 
== wp-admin を安全にする ==
 
== wp-admin を安全にする ==
  
サーバーサイドで <code>/wp-admin/</code> にパスワードを追加する([http://ja.wikipedia.org/wiki/Basic%E8%AA%8D%E8%A8%BC Basic 認証]など)と、ブログ管理領域、ログイン画面、ファイルに二層の保護を追加できます。これにより攻撃者またはボットは、実際の管理ファイルではなく二層目の保護レイヤーを攻撃する必要が発生します。ほとんどの場合、WordPress への攻撃は、悪意あるソフトウェアボットが自動実行しています。しかし、<code>wp-admin/</code> ディレクトを保護ことで WordPress の機能の一部が使えなくなってしまう場合があります。例えば <code>wp-admin/admin-ajax.php</code> に含まれる Ajax ハンドラなどです。適切な <code>wp-admin/</code> ディレクトリのパスワード保護方法については、[[#Resources|リソース]]セクションをご覧ください。
+
サーバーサイドで <code>/wp-admin/</code> にパスワードを追加する([http://ja.wikipedia.org/wiki/Basic%E8%AA%8D%E8%A8%BC Basic 認証]など)と、ブログ管理領域、ログイン画面、ファイルに二層の保護を追加できます。これにより攻撃者またはボットは、実際の管理ファイルではなく二層目の保護レイヤーを攻撃する必要が発生します。ほとんどの場合、WordPress への攻撃は、悪意あるソフトウェアボットが自動実行しています。しかし、<code>wp-admin/</code> ディレクトリを保護することで WordPress の機能の一部が使えなくなってしまう場合があります。例えば <code>wp-admin/admin-ajax.php</code> に含まれる Ajax ハンドラなどです。適切な <code>wp-admin/</code> ディレクトリのパスワード保護方法については、[[#Resources|リソース]]セクションをご覧ください。
  
 
WordPress ブログへのよくある攻撃は、以下の2つのカテゴリに分類されます。
 
WordPress ブログへのよくある攻撃は、以下の2つのカテゴリに分類されます。
155行目: 156行目:
 
# 「ブルートフォース」パスワード推測により、ブログへアクセスを試みる。
 
# 「ブルートフォース」パスワード推測により、ブログへアクセスを試みる。
  
重要なファイルに第二層の保護を追加することで、攻撃者は、<code>/wp-admin/</code> に攻撃を仕掛ける前に、これを突破する必要があります。この保護は、[http://www.rfc-editor.org/rfc/rfc2617.txt Basic HTTP 認証]を使用し、パスワードは平文で、暗号化されずにネットワークに流れます。この保護の主な利点は、サーバーファイルへのアクセスを拒否し、あなたのブログへの攻撃が <code>/wp-admin/</code> の入り口に達する前に警告が発生することです。
+
重要なファイルに第二層の保護レイヤーを追加することで、攻撃者は、<code>/wp-admin/</code> に攻撃を仕掛ける前に、これを突破する必要があります。この保護は、[http://www.rfc-editor.org/rfc/rfc2617.txt Basic HTTP 認証]を使用し、パスワードは平文で、暗号化されずにネットワークに流れます。この保護の主な利点は、サーバーファイルへのアクセスを拒否し、あなたのブログへの攻撃が <code>/wp-admin/</code> の入り口に達する前に警告が発生することです。
  
 
"二層式"パスワード保護の完全な実装をするには、<code>/wp-admin/</code> ディレクトリに HTTPS SSL 暗号化接続し、すべての通信と重要なデータを暗号化することが必要です。''[[管理画面での SSL 通信]] をご覧ください。''
 
"二層式"パスワード保護の完全な実装をするには、<code>/wp-admin/</code> ディレクトリに HTTPS SSL 暗号化接続し、すべての通信と重要なデータを暗号化することが必要です。''[[管理画面での SSL 通信]] をご覧ください。''
180行目: 181行目:
 
<tt>wp-config.php</tt> ファイルを、WordPress をインストールした階層の一つ上に移動することができます。つまり、ウェブスペースのルートに WordPress をインストールしている場合、<tt>wp-config.php</tt> をウェブルートの外側に格納できるということです。
 
<tt>wp-config.php</tt> ファイルを、WordPress をインストールした階層の一つ上に移動することができます。つまり、ウェブスペースのルートに WordPress をインストールしている場合、<tt>wp-config.php</tt> をウェブルートの外側に格納できるということです。
  
: '''Note:''' Some people assert that [http://wordpress.stackexchange.com/q/58391/3898 moving wp-config.php has minimal security benefits] and, if not done carefully, may actually introduce serious vulnerabilities. [http://wordpress.stackexchange.com/a/74972/24425 Others disagree].
+
: '''注意:''' [http://wordpress.stackexchange.com/q/58391/3898 wp-config.php の移動は最低限の利点しかなく]、しかも注意深く実行しなければ深刻な脆弱性を引き起こすと主張する人もいます。[http://wordpress.stackexchange.com/a/74972/24425 この意見に反対する人もいます]
  
 
<tt>wp-config.php</tt> は、WordPress (wp-includes のある場所) インストールの'''一つ'''上のディレクトリに格納できることに注意してください。また、<tt>wp-config.php</tt>の読み込み権限があるのはあなた(とウェブサーバー)のみであることを確認してください。(大抵の場合、ファイルパーミッションは400、もしくは440です)
 
<tt>wp-config.php</tt> は、WordPress (wp-includes のある場所) インストールの'''一つ'''上のディレクトリに格納できることに注意してください。また、<tt>wp-config.php</tt>の読み込み権限があるのはあなた(とウェブサーバー)のみであることを確認してください。(大抵の場合、ファイルパーミッションは400、もしくは440です)
189行目: 190行目:
 
order allow,deny
 
order allow,deny
 
deny from all
 
deny from all
 +
</files></pre>
 +
 +
Apahce 2.4以降では、以下のように記述します。
 +
 +
<pre><files wp-config.php>
 +
    Require all granted
 
</files></pre>
 
</files></pre>
  
 
== ファイル編集の無効化 ==
 
== ファイル編集の無効化 ==
  
WordPressダッシュボードでは、デフォルトで管理者がPHPファイル(例えばプラグインとテーマファイル)を編集することが可能です。攻撃者がログインできると、多くの場合まずこの機能を利用してコードを実行します。WordPressダッシュボードには、編集を無効にする定数があります。wp-config.phpに次の行を追加することで、すべてのユーザの「edit_themes」、「edit_plugins」および「edit_files」を無効とします。
+
WordPressダッシュボードでは、デフォルトで管理者がPHPファイル(例えばプラグインとテーマファイル)を編集することが可能です。攻撃者がログインできると、多くの場合まずこの機能を利用してコードを実行します。WordPressダッシュボードには、編集を無効にする定数があります。wp-config.phpに次の行を追加することで、すべてのユーザの「edit_themes」、「edit_plugins」および「edit_files」を無効にします。
 
  define('DISALLOW_FILE_EDIT', true);
 
  define('DISALLOW_FILE_EDIT', true);
 
これにより、アップロードされる悪意があるファイルからあなたのサイトまで攻撃者を防ぎませんが、いくつかの攻撃を止めるかもしれません。
 
これにより、アップロードされる悪意があるファイルからあなたのサイトまで攻撃者を防ぎませんが、いくつかの攻撃を止めるかもしれません。
201行目: 208行目:
 
まず、利用しているプラグインが常に最新に更新されていることを確かめてください。また、使用していないプラグインはシステムから削除するようにしてください。  
 
まず、利用しているプラグインが常に最新に更新されていることを確かめてください。また、使用していないプラグインはシステムから削除するようにしてください。  
  
=== ファイアウォールプラグイン ===
+
=== ファイアウォール ===
 
+
ルールデータベースおよび/またはホワイトリストにより、怪しい要求を排除するプラグインがあります。[http://wordpress.org/plugins/wordpress-firewall/developers/ WordPress Firewall] は、WordPress 向けに設定されたルールとホワイトリストで、様々な設定をすることなく攻撃を排除します。
+
 
+
[http://wordpress.org/plugins/all-in-one-wp-security-and-firewall/ All in One WordPress Firewall] プラグインはサイトに対し、ファイアウォールのルールを適用することができます。
+
  
[http://wordpress.org/plugins/better-wp-security/ Better WP Security] プラグインは、他のプラグインと同様にあなたのサイト(Apacheかnginxを問わず)に書き換えルールを追加する他、アクセスなどの試みを通知することができます。
+
サイトのファイアウォールとして動作するプラグインやサービスがたくさんあります。その一部では .htaccess ファイルを修正し、 WordPress に処理が渡る前に Apache のレベルでアクセスを制限することによって機能するものもあります。良い例は [https://wordpress.org/plugins/better-wp-security/ iThemes Security] や [http://wordpress.org/plugins/all-in-one-wp-security-and-firewall/ All in One WP Security] です。[https://wordpress.org/plugins/wordfence/ WordFence] のように WordPress レベルで動作するファイアウォールプラグインもあり、WordPress がロードされる際、完全に機能する前に攻撃をフィルタリングします。
  
 +
プラグインのほかには Web サーバーに WAF (Web ファイアウォール) をインストールして WordPress で処理される前にコンテンツをフィルタリングできます。もっとも人気のあるオープンソース WASF は ModSecurity です。
  
また、ファイアウォール保護およびその他のツールを含むプラグインとして [http://wordpress.org/plugins/wordfence/ Wordfence Security] もあります。このプラグインはリアルタイム訪問者ログ、設定可能な通知の送信などを提供します。そしてこれが一番良い機能だと思いますが—お使いのサイトのコア、プラグイン、テーマを日時でスキャンし、WordPressレポジトリー上のバージョンと比較します。スキャンの間に問題を発見した場合、管理者は正しいバージョンにファイルを戻すことができます。プラグインがデータベースにテーブルを追加するため、容量を増やすことに注意してください。ただし、これは安全な運用のためには妥当な犠牲と言えるでしょう。
+
またファイアウォールは、ホスティングの提供会社とインターネットの間にも追加できます(中間でのセキュリティ)。ファイアウォールを通過する DNS レコードを変更します。すべてのトラフィックがサイト到達前にファイアウォールによりフィルタリングされます。[http://cloudflare.com CloudFlare]、[http://cloudproxy.sucuri.net/wordpress Sucuri]、[http://www.incapsula.com Incapsula]など、いくつかの会社がこのようなサービスを提供しています。
  
 
=== 書き込み権限を必要とするプラグイン ===
 
=== 書き込み権限を必要とするプラグイン ===
226行目: 230行目:
 
[http://en.wikipedia.org/wiki/Security_through_obscurity#Open_source_repercussions Security through obscurity (隠蔽によるセキュリティ向上)] は、典型的には、基本戦略として健全でない、と考えられています。しかし、WordPress のある領域では、情報を隠蔽することがセキュリティの助けになる''ことがあるかもしれません''。  
 
[http://en.wikipedia.org/wiki/Security_through_obscurity#Open_source_repercussions Security through obscurity (隠蔽によるセキュリティ向上)] は、典型的には、基本戦略として健全でない、と考えられています。しかし、WordPress のある領域では、情報を隠蔽することがセキュリティの助けになる''ことがあるかもしれません''。  
  
# '''管理者アカウント名の変更:''' 新規インストール時に、新しい管理者アカウントを作成し、(WP2.9 以前で)デフォルトの <code>admin</code> アカウントを削除します。既存の WordPress インストールでは、MySQL コマンドラインクライアントで <code>UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin';</code> のようなコマンドを入力するか、[[phpMyAdmin]] のような MySQL フロントエンドを使用して、名前を変更しても良いでしょう。
+
# '''管理者アカウント名の変更:''' 管理者アカウントを作るとき、簡単に推測されるような言葉(<code>admin</code> とか <code>webmaster</code>)をユーザー名に使うのは避けましょう。真っ先に攻撃対象にされてしまいます。既存の WordPress インストールでは、MySQL コマンドラインクライアントで <code>UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin';</code> のようなコマンドを入力するか、[[phpMyAdmin]] のような MySQL フロントエンドを使用して、名前を変更しても良いでしょう。
 
# '''table_prefix の変更:'''  多くの既知の WordPress を狙った SQL インジェクション攻撃は、table_prefix がデフォルトの <code>wp_</code> であることを仮定しています。これを変更することは、隠蔽によるセキュリティですが、SQL インジェクション攻撃の一部は防ぐことができるかもしれません。
 
# '''table_prefix の変更:'''  多くの既知の WordPress を狙った SQL インジェクション攻撃は、table_prefix がデフォルトの <code>wp_</code> であることを仮定しています。これを変更することは、隠蔽によるセキュリティですが、SQL インジェクション攻撃の一部は防ぐことができるかもしれません。
  
237行目: 241行目:
 
== ログの取得 ==
 
== ログの取得 ==
  
When performing forensics logs are your best friend. Contrary to popular beliefs, logs allow you to see what was done and by who and when. Unfortunately the logs will not tell you who, username, logged in, but it will allow you to identify the IP and time. Additionally, you will be able to see any of these attacks via the logs - Cross Site Scripting (XSS), Remote File Inclusion (RFI), Local File Inclusion (LFI) and Directory Traversal attempts. You will also be able to see brute force attempts.
+
調査のためにログを使えば、サイトについて理解するために非常に役に立ちます。ログから、誰がいつ何をしたのかが分かります。残念なことにログからはどのユーザーがログインしたのかという情報は知ることができませんが、IP や時刻などを特定できます。さらに、アタックをすべてチェックできます。クロスサイトスクリプティング (XSS)、リモートファイルインクルージョン (RFI)、ローカルファイルインクルージョン (LFI)、そしてディレクトリトラバーサルの試行といったことです。ブルートフォース攻撃があればその履歴も見られるでしょう。
  
If you get more comfortable with your logs you'll be able to see things like, when the theme and plugin editors are being used, when someone updates your widgets and when posts and pages are added. All key elements when doing forensic work on your web server.
+
ログを見るのに抵抗がなくなったら、いつテーマ・プラグインエディタが使われたのか、いつウィジェットが更新されたのか、いつ投稿や固定ページが追加されたのかといったことも見えるようになってきます。ログには、Web サーバー上での犯人調査のために必要なキー要素が全て含まれています。
  
There are two key open-source solutions you'll want on your web server from a security perspective, this is a layered approach to security.
+
セキュリティの観点から見た場合に、Web サーバーで使っておきたい大事なオープンソースソリューションが2つあります。これはセキュリティへのレイヤー的アプローチです。
  
ModSecurity - This is an Apache module that functions as a Web Application Firewall (WAF). WAF's are key today, it's what you see folks like Cloudflare and Incapsula employing to filter the traffic. It filters all the traffic as it comes from your site and parses it out before it hits your site. I won't lie, configuring can be tricky with WordPress but it's possible. The other challenge is it doesn't work on NGINX, it's tailored for Apache web servers. The good news is Apache still makes up 90% of the web servers. I should clarify that there is a NGINX version, but it's less stable than Apache and currently undergoing a rehaul.
+
[http://www.ossec.net OSSEC] はあらゆる -NIX ディストリビューションと Windows 上で利用でき、正しい設定を行えば非常にパワフルです。すべてのログを関連付け、凝集させるというのがその考え方です。すべての access_logs error_logs を収集するように必ず設定し、サーバーアカウント上に複数のサイトがある場合はそれらも忘れないようにしましょう。また、効果的なログを取るにはデフォルトで含まれるノイズをきちんとフィルタリングするのも忘れないようにしてください。
 
+
OSSEC can run on any NIX distribution and will also run on Windows. When configured correctly its very powerful. The idea is correlate and aggregate all the logs. You have to be sure to configure it to capture all access_logs and error_logs and if you have multiple websites on the server account for that. You'll also want to be sure to filter out the noise. By default you'll see a lot of noise and you'll want to configure it to be really effective.
+
  
 
== モニタリング ==
 
== モニタリング ==
  
ときには、予防策が十分でなく、攻撃されることがあります。このため、侵入の検知/監視が非常に重要です。すぐに対策を取ることができ、何が起きたかを把握し、サイトを元に回復することができるでしょう。
+
ときには、予防策が十分でなく、攻撃されることがあります。このため、侵入の検知や監視が非常に重要です。すぐに対策を取ることができ、何が起きたかを把握し、サイトを元に回復することができるでしょう。
  
 
=== ログの監視 ===
 
=== ログの監視 ===
258行目: 260行目:
  
 
攻撃が発生すると、必ず痕跡が残ります。ログまたはファイルシステム (新規ファイル、変更されたファイル等) です。上で推奨している [http://www.ossec.net OSSEC] を使用している場合、ファイルを監視し、変更があると通知します。ファイル変更の通知には、オープンソース [http://www.tripwire.org Tripwire] を使用することもできます。
 
攻撃が発生すると、必ず痕跡が残ります。ログまたはファイルシステム (新規ファイル、変更されたファイル等) です。上で推奨している [http://www.ossec.net OSSEC] を使用している場合、ファイルを監視し、変更があると通知します。ファイル変更の通知には、オープンソース [http://www.tripwire.org Tripwire] を使用することもできます。
 +
 +
==== 目標 ====
 +
ファイルシステムトラッキングの目標は次のとおりです。
 +
 
 +
* 変更、追加されたファイルのモニタリング
 +
* 変更、追加のログ取得
 +
* 詳細な変更お取得機能
 +
* 自動警告
 +
 +
==== 一般的なアプローチ ====
 +
管理者は次のような一般的な技術を使用してファイルシステムをモニタリングできます。
 +
 +
* システムユーティリティ
 +
* バージョン制御
 +
* OSやカーネルレベルのモニタリング
 +
 +
==== 特定のツール ====
 +
ファイルシステムモニタリングのオプションは次のとおりです。
 +
 +
* [http://ja.wikipedia.org/wiki/Diff diff] - サイトのクリーンなテストコピーをビルドし、本番環境と比較する
 +
* [http://git-scm.com/ Git] - ソースコード管理
 +
* [https://en.wikipedia.org/wiki/Inotify inotify] と [http://inotify.aiken.cz/?section=incron&page=doc&lang=en incron] - OS カーネルレベルのファイルモニタリングサービス。ファイルシステムイベントに対してコマンドを実行
 +
* [https://github.com/gregghz/Watcher/blob/master/jobs.yml Watcher] - Python inotify ライブラリ
 +
* [http://ossec.net OSSEC] - Open Source Host-based Intrusion Detection System。ログ解析、ファイルの一貫性検証、ポリシーのモニタリング、rootkit 検知、リアルタイム警告と動的対応
 +
 +
====注意点====
 +
ファイルベースモニタリング戦略を採用する場合、以下を含む多くの注意点があります。
 +
 +
=====モニタリング用スクリプトやサービスを root で実行する=====
 +
攻撃者によるファイルシステムモニタリングソリューションの無効化や変更が困難になります。
 +
 +
=====計画したメンテナンスやアップグレード時にモニタリングを無効化する=====
 +
サイトの定期的なメンテナンスを実行する際に、不要な警告を回避できます。
 +
 +
=====実行可能なファイルタイプのみモニタリングする=====
 +
 +
.php ファイルなど実行可能なファイルタイプのみをモニタリングすれば十分安全です。非実行可能ファイルをフィルタリングから除外すれば、不要なログ出力や警告を削減できます。
 +
 +
=====厳格なファイルシステムパーミッションを使用する=====
 +
ファイルパーミッションと所有権について参照してください。一般に、可能な限り <em>execute</em> 権限と <em>write</em> 権限は避けてください。
  
 
=== 悪意ある変更に備えて外部からウェブサーバーを監視する ===
 
=== 悪意ある変更に備えて外部からウェブサーバーを監視する ===
  
攻撃者がサイトを書き換えたり、マルウェアを追加しようとするとき、ウェブベースの改善検知ソリューションを使用して、これらの変更を検知することができます。This comes in many forms today, use your favorite search engine and look for Web Malware Detection and Remediation and you'll likely get a long list of service providers
+
攻撃者がサイトを書き換えたり、マルウェアを追加しようとするとき、ウェブベースの改善検知ソリューションを使用して、これらの変更を検知することができます。今日ではさまざまな形式のサービスがあります。検索エンジンで「Web Malware Detection Remediation」または「マルウエア 検知 修正」を検索してください。多くのサービス提供会社がリストされます。
  
 
<div id="Resources">
 
<div id="Resources">
 
== リソース ==
 
== リソース ==
 
</div>
 
</div>
 +
 +
=== 日本語 ===
 +
* [https://dogmap.jp/2016/05/10/post-3258/ WordPress にバックドア仕掛けられないように ...] ([https://dogmap.jp/ dogmag.jp]) - 2016年5月段階での最新の対策方法が丁寧に紹介されています。
 +
* [http://www.rescuework.jp/blog.html 本当は怖い WordPress (ブログ)]
 +
* [http://mikeneko.creator.club.ne.jp/~lab/web/htaccess/directory.html ミケネコの htaccess リファレンス|ディレクトリ制御] - 上記よりも分かりやすく解説されたディレクトリのパスワード保護方法
  
 
=== 英語 ===
 
=== 英語 ===
 
*[http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html WordPress Security Cutting Through the BS]
 
*[http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html WordPress Security Cutting Through the BS]
* [http://wordpress.org/extend/plugins/mvis-security-center/ MVIS Security Center (Plugin): Identifies most of the topics described in this guide and provides information on how to lock down WordPress]
+
* [http://wordpress.org/plugins/secure/ Secure (プラグイン。以前の MVIS Security Center): このガイドで紹介したほとんどのトピックを識別し、WordPress の修正方法がガイドされます。]
 
*[http://build.codepoet.com/2012/07/10/locking-down-wordpress/ e-Book: Locking Down WordPress]
 
*[http://build.codepoet.com/2012/07/10/locking-down-wordpress/ e-Book: Locking Down WordPress]
 
* [http://wpsecure.net/basics/ wpsecure.net has a few guides on how to lock down WordPress]
 
* [http://wpsecure.net/basics/ wpsecure.net has a few guides on how to lock down WordPress]
275行目: 322行目:
 
* [http://wordpress.tv/2010/01/23/brad-williams-security-boston10/ Brad Williams: Lock it Up (動画)]
 
* [http://wordpress.tv/2010/01/23/brad-williams-security-boston10/ Brad Williams: Lock it Up (動画)]
 
* [http://www.wpbeginner.com/wp-tutorials/how-to-password-protect-your-wordpress-admin-wp-admin-directory/ Simple tutorial on how to password protect the WordPress admin area and fix the 404 error]
 
* [http://www.wpbeginner.com/wp-tutorials/how-to-password-protect-your-wordpress-admin-wp-admin-directory/ Simple tutorial on how to password protect the WordPress admin area and fix the 404 error]
* [http://www.nkuttler.de/2010/06/14/htaccess-protect-wordpress-admin/ Nicolas Kuttler: Password protecting the wp-admin directory] - Apache と lighttpd でディレクトリをパスワード保護する際、ajax-admin.php ハンドラを除外する方法
+
* [http://wordpress.org/extend/plugins/askapache-password-protect wp-admin/ 他のディレクトリ向け AskApache Password Protection プラグイン] '''警告:''' AskApache Password Protection プラグインをインストールすると、WordPress 管理画面にアクセスできなくなるかもしれません。このプラグインについて他のユーザーの体験を読むには、[http://www.askapache.com/wordpress/htaccess-password-protect.html#comment プラグインホームページのコメント]をご覧ください。
* [http://wordpress.org/extend/plugins/askapache-password-protect wp-admin/ 他のディレクトリ向け AskApache Password Protection プラグイン] '''警告:''' AskApache Password Protection プラグインをインストールすると、WordPress 管理パネルにアクセスできなくなるかもしれません。このプラグインについて他のユーザーの体験を読むには、[http://www.askapache.com/wordpress/htaccess-password-protect.html#comment プラグインホームページのコメント]をご覧ください。
+
 
+
=== 日本語 ===
+
* [http://www.rescuework.jp/blog.html 本当は怖い WordPress (ブログ)]
+
* [http://mikeneko.creator.club.ne.jp/~lab/web/htaccess/directory.html ミケネコの htaccess リファレンス|ディレクトリ制御] - 上記よりも分かりやすく解説されたディレクトリのパスワード保護方法
+
  
 
== 参考 ==
 
== 参考 ==
 
+
* [[WordPress_サイトが被害を受けたら]]
 
* [[FAQ/セキュリティ|セキュリティ FAQ]]
 
* [[FAQ/セキュリティ|セキュリティ FAQ]]
 
* [[FAQ/ハッキング・クラッキング被害|ハッキング・クラッキング被害 FAQ]]
 
* [[FAQ/ハッキング・クラッキング被害|ハッキング・クラッキング被害 FAQ]]
 
* [[ブルートフォース攻撃]]
 
* [[ブルートフォース攻撃]]
 +
* [http://wordpress.org/about/security/ WordPress Security Whitepaper]
  
{{原文|Hardening_WordPress|141793}}<!-- 2014-03-11T23:49 WPWhiteSecurity 版 -->
+
{{原文|Hardening_WordPress|151587}}<!-- 13:48, 13 May 2015‎ Nawrocki版 -->
  
 
[[Category:セキュリティ]]
 
[[Category:セキュリティ]]
 
[[Category:上級トピック]]
 
[[Category:上級トピック]]
 
[[Category:WordPress の開発]]
 
[[Category:WordPress の開発]]
 +
 +
[[de:Hardening WordPress]]
 +
[[en:Hardening WordPress]]
 +
[[ja:Hardening WordPress]]
 +
[[ko:Hardening WordPress]]
 +
[[pt-br:Blindando_o_WordPress]]

2020年9月30日 (水) 13:07時点における最新版

WordPress ではセキュリティを非常に重要なものと考えています。しかし、他のどんなシステムでも同様ですが、基本的なセキュリティ対策がなされていない場合には問題が発生する可能性はあります。このページでは、よくある脆弱性について、そして WordPress を安全に保つためにできることを紹介します。

このページはセキュリティに対する心配を一掃するその場限りの応急措置とは違います。特定のセキュリティ問題や不明な点を抱えている場合は、コンピューターセキュリティの知識を十分に持っている信頼のおける人ときちんと話し合うべきです。

目次

セキュリティとは

基本的には、セキュリティとは「完璧に安全なシステム」のことではありません。そのようなものは実用的ではないか、見つけたり運用したりするのは不可能といえるでしょう。セキュアなサーバーは、サーバー管理者のコントロールのもとに、リソースのプライバシー・整合性・可用性を保護するものです。

信頼できる Web ホスティングには、以下が含まれます。

  1. セキュリティに関してあなたが気になっている点や、ホスティングにどのようなセキュリティ機能やプロセスがあるのかをためらいなく話し合ってくれる。
  2. 最新安定版のサーバーソフトウェアを使っている。
  3. 確実なバックアップとリカバリ方法を提供している。

保護すべきソフトウェアとデータを確定することで、どのようなセキュリティが必要なのかを決定しましょう。以下のガイドがその助けになるはずです。

セキュリティの考え方

システムの各方面のセキュリティを考える時に、いくつかの一般的な考え方を頭に置いておきましょう。

  1. アクセスの制限: 悪意ある人物が利用可能な潜在的な入り口を効果的に減らすための賢い選択をする。
  2. 抑制: インストールの弱点を悪意ある人物が発見した場合に備え、システム内部で実行できる損害を最小化するようにシステムを設定する。
  3. 知識: バックアップを取り、定期的に WordPress インストールの状態を知り、WordPress インストールを理解しやすいよう、行った変更をドキュメント化しておく。
  4. 信頼できるソース: テーマやプラグインを信頼できないソースから入手するのはやめて、WordPress.org 公式レポジトリまたはよく知られた信頼のおける企業などからのダウンロードに制限する。それ以外から入手することで問題が発生することがある

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

WordPress に投稿するコンピュータが、スパイウェア、マルウェア、ウイルスに感染していないことを確かめましょう。またアプリケーションが安全で安定したバージョンであることを確かめましょう。例えばキーロガーが仕込まれていた場合、WordPress や Web サーバーのセキュリティ対策は全く意味をなさなくなってしまいます。

OS とソフトウェアは常に最新版にしておきましょう。特に、セキュリティ脆弱性からパソコンを保護するために Web ブラウザを最新版に更新しておくことが大事です。信頼できないサイトを閲覧しているなら、NoScript などのツールを使うかブラウザの JavaScript/Flash/Java を無効にすることをおすすめします。

WordPress パッケージの脆弱性

多くの現代的なソフトウェアパッケージと同様、WordPress は新しいセキュリティ関連の問題が発生すると定期的に更新されています。ソフトウェアのセキュリティを改善していくのは常に進行形の懸案事項であり、このため、最新バージョンの WordPress に常に更新すべきです。WordPress の旧バージョンはセキュリティアップデートに対してメンテナンスされていません。

WordPress の更新

メイン記事: WordPress のアップグレード

最新版の WordPress は、WordPress 公式サイト ( https://wordpress.org/ ) または日本語版公式サイト ( https://ja.wordpress.org/ ) から入手できます。公式リリースはこれ以外のサイトからはリリースされません。wordpress.org ドメイン以外からは絶対に WordPress をインストール・アップグレードしないでください。

バージョン3.7で WordPress は自動アップデート機能を導入しました。最新の状態に維持するためにこの機能を利用してください。また、WordPress のダッシュボードには更新に関する情報が表示されます。更新を行いセキュリティを保つため、ダッシュボード内の情報または WordPress 開発者ブログを読むようにしてください。

脆弱性が発見された問題に対処する新しい WordPress のバージョンがリリースされるほとんどの場合には、この脆弱性を悪用するための情報が公開されています。これにより古いバージョンではより攻撃を受けやすくなるため、WordPress を常に最新の状態にする主な理由の一つといえます。

複数の WordPress をインストールする管理者は、管理を容易にするために Subversion などのバージョン管理ソフトを使用することを検討してください。

セキュリティ上の問題の報告

WordPress 上にセキュリティ関連の問題を見つけたと思ったら、これを報告することで協力できます。セキュリティ上の問題を報告する方法については、セキュリティ FAQ をごらんください。

バグだと思うものを見つけた場合は、報告してください。詳しくはバグの報告をごらんください。脆弱性、または脆弱性に繋がるバグを見つけたという場合もあります。

サーバーの脆弱性

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

共有サーバー (同じサーバー上に他の人のサイトがホスティングされている環境) で誰かのサイトが感染すると、たとえこのガイドに従っていた場合でもあなたのサイトも感染してしまう可能性があります。使用している[用語集#Hosting_provider Web ホスト] がどのようなセキュリティ対策を行っているか確かめておいてください。

ネットワークの脆弱性

ネットワークの両端、WordPress サーバーサイドとクライアントサイド、は信頼できるべきです。つまり、家のルータのファイアウォールルールをアップデートし、どのネットワークから作業するかについて注意すべきです。無線であれ有線であれ、インターネットカフェの暗号化されていない接続でパスワードを送信するのは「信頼できるネットワーク」上の作業とは言えません。

ホスティング業者は自身のネットワークがハッカーによって汚染されていないことを確かめるべきですし、あなたもそうすべきです。ネットワークに脆弱性があると、スニファやその他の破壊 (中間者攻撃など) の発生を許してしまうかもしれません。

パスワード

セキュリティ向上のための習慣を守れば、脆弱性の多くは回避可能です。ここで重要な点のひとつに、パスワードがあります。

パスワードの目的は、ブルートフォース攻撃/Brute_Force_Attacks(総当たり攻撃)の成功を難しくすることです。インターネット上には多くのパスワード自動生成ツールが公開されており、安全なパスワードを作成するために利用できます。

さらに、WordPress にはパスワードの強度メーターが含まれています。パスワードを変更する際にはこれを活用し、強度が十分かどうか確認しましょう。

パスワードを選ぶ際には、以下のことは避けましょう。

  • 自分の本名、ユーザー名、会社名、サイト名などの羅列。
  • (あらゆる言語で)辞書にある単語。
  • 短いパスワード。
  • 数字のみ、またはアルファベットのみのパスワード。両方を混ぜるのが効果的です。

強力なパスワードは、ブログのコンテンツを守るためだけに必要なのではありません。あなたの管理アカウントにアクセスできるようになったハッカーは、サーバー全体を危険にさらす可能性がある悪意のあるスクリプトをインストールできてしまいます。

強力なパスワードの使用に加えて、追加のセキュリティ対策として2段階認証/two-step authenticationを有効にすることは良いアイデアです。

FTP

お使いのサーバーに接続するときは、(ホスティングが対応していれば) 暗号化された SFTP を使用すべきです。ホスティングが対応しているか不明な場合は、ホスティングのサポートにお問い合わせください。

SFTP の使い方は FTP と同じですが、手元の端末とサーバーとの間で送受信するパスワードやその他のデータが暗号化される点が異なります。パスワードが平文で送られることは無いため、攻撃者に不正使用されることはありません。


ファイルパーミッション

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

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

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

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

/
ルート Wordpress ディレクトリ。すべてのファイルを自分のユーザーアカウントのみから書き込み可能にするべきです。例外は .htaccess: で、自動的にリライトルールを生成させたいときはこれを WordPress によって書き込み可能にします。
/wp-admin/
WordPress 管理領域: すべてのファイルを自分のユーザーアカウントのみから書き込み可能にする。
/wp-includes/
WordPress アプリケーションロジックの大部分。すべてのファイルを自分のユーザーアカウントのみから書き込み可能にする。
/wp-images/
WordPress が使用する画像ファイル。すべてのファイルを自分のユーザーアカウントと Web サーバーのプロセスのみから書き込み可能にする。

/wp-content/ 内には以下が含まれる。

/wp-content/
ユーザー提供の様々なコンテンツ。開発者/en により、すべて (所有者、グループ、全体) 書き込み可能に意図されている。
/wp-content/themes/
テーマファイル。ビルトインテーマエディタを使用する場合は、Web サーバーのプロセスに書き込み権限を与える。ビルトインテーマエディタを使用しない場合は、自分のユーザーアカウントのみから書き込み可能にする。
/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/ にはこのコマンドを使用してはいけません。

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

WordPress に自動アップグレードを適用する際、すべてのファイル操作は Web サーバーユーザーではなくファイル所有者であるユーザーとして行われます。すべてのファイルは 0644 に、すべてのディレクトリは 0755 に設定され、ユーザーのみ書き込み可能で、(Web サーバーを含む)誰にでも閲覧可能な状態になります。

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

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

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

データベースユーザーの権限を制限する

ブログやコメントの投稿・メディアファイルのアップロード・新規 WordPress ユーザーの作成・プラグインのインストールといった通常の WordPress 運用においては、MySQL データベースユーザーはデータの読み書き(SELECT / INSERT / UPDATE / DELETE)が可能な権限のみが必要となります。

つまり、DROP / ALTER / GRANT といったデータベース構造の変更や管理のための他の権限は必要ないということです。こういった権限を取り消すことによって抑制(封じ込め)対策を改善することができます。

注: 一部のプラグイン、テーマ、WordPress コアのメジャーバージョン更新においてはテーブルの追加やスキーマの変更などといったデータベース構造の変更が必要になる場合があります。こういった場合にはプラグインのインストールやソフトウェア更新の際に、一時的にデータベースユーザーへの権限許可を行う必要があります。
警告: WordPress のバージョンアップでデータベーススキーマが変わる場合、これらの権限なしに更新しようとすれば、問題を起こす虞があります。よって、これらの権限を外すことはお奨めできません。セキュリティのために是非ともこれらの権限を外す必要があると思われる場合は、信頼性の高いバックアップ計画を策定し実施することが必要不可欠です。バックアップ計画には、定期的にデータベース全体のバックアップをとること、バックアップした内容を検証すること、そして、容易にバックアップから復元できるようにすることが必要です。データベースのアップグレードに失敗しても、バックアップからデータベースを復元し、必要な権限を付与し、そして WordPress にデータベース更新をやり直させることで、たいてい解決します。データベースは、バックアップから復元することで旧バージョンに戻るので、 WordPress の管理画面で旧バージョンが検出され、必要な SQL コマンドをまた実行させることができます。 WordPress のバージョンアップのたびにスキーマが変更されるわけではありません。スキーマが変わるのはたいていメジャーバージョンアップ(例えば 3.7 から 3.8 へ)のときであり、マイナーバージョンアップ(例えば 3.8 から 3.8.1 へ)では変わらないことが一般的です。いずれにしても、定期的にバックアップをとり続けることです。

wp-admin を安全にする

サーバーサイドで /wp-admin/ にパスワードを追加する(Basic 認証など)と、ブログ管理領域、ログイン画面、ファイルに二層の保護を追加できます。これにより攻撃者またはボットは、実際の管理ファイルではなく二層目の保護レイヤーを攻撃する必要が発生します。ほとんどの場合、WordPress への攻撃は、悪意あるソフトウェアボットが自動実行しています。しかし、wp-admin/ ディレクトリを保護することで WordPress の機能の一部が使えなくなってしまう場合があります。例えば wp-admin/admin-ajax.php に含まれる Ajax ハンドラなどです。適切な wp-admin/ ディレクトリのパスワード保護方法については、リソースセクションをご覧ください。

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

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

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

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

wp-includes を安全にする

通常スクリプトがユーザーによってアクセスされることを想定されていない部分で次のレイヤーの保護を追加することができます。ひとつの方法は、.htaccess で mod_rewrite を使っているスクリプトをブロックするというやり方です。注: 下記のコードが WordPress によって上書きされないようにするためには、.htaccess ファイルの # BEGIN WordPress# END WordPress タグの外側に書き込んでください。この2つのタグの間に何かを書き込むと WordPress が上書きしてしまうことがあります。

# 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

RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] によって ms-files.php ファイルが画像を生成するのを防ぐため、この設定はマルチサイトでは使えません。 このコードを消すことで動作はしますが、セキュリティ強度は弱まります。

wp-config.php を安全にする

wp-config.php ファイルを、WordPress をインストールした階層の一つ上に移動することができます。つまり、ウェブスペースのルートに WordPress をインストールしている場合、wp-config.php をウェブルートの外側に格納できるということです。

注意: wp-config.php の移動は最低限の利点しかなく、しかも注意深く実行しなければ深刻な脆弱性を引き起こすと主張する人もいます。この意見に反対する人もいます

wp-config.php は、WordPress (wp-includes のある場所) インストールの一つ上のディレクトリに格納できることに注意してください。また、wp-config.phpの読み込み権限があるのはあなた(とウェブサーバー)のみであることを確認してください。(大抵の場合、ファイルパーミッションは400、もしくは440です)

.htaccess を使えるサーバーであれば、下記設定を追加した .htaccess ファイルをサーバーのトップに設置することにより、アクセスを拒否することができます。

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

Apahce 2.4以降では、以下のように記述します。

<files wp-config.php>
    Require all granted
</files>

ファイル編集の無効化

WordPressダッシュボードでは、デフォルトで管理者がPHPファイル(例えばプラグインとテーマファイル)を編集することが可能です。攻撃者がログインできると、多くの場合まずこの機能を利用してコードを実行します。WordPressダッシュボードには、編集を無効にする定数があります。wp-config.phpに次の行を追加することで、すべてのユーザの「edit_themes」、「edit_plugins」および「edit_files」を無効にします。

define('DISALLOW_FILE_EDIT', true);

これにより、アップロードされる悪意があるファイルからあなたのサイトまで攻撃者を防ぎませんが、いくつかの攻撃を止めるかもしれません。

プラグイン

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

ファイアウォール

サイトのファイアウォールとして動作するプラグインやサービスがたくさんあります。その一部では .htaccess ファイルを修正し、 WordPress に処理が渡る前に Apache のレベルでアクセスを制限することによって機能するものもあります。良い例は iThemes SecurityAll in One WP Security です。WordFence のように WordPress レベルで動作するファイアウォールプラグインもあり、WordPress がロードされる際、完全に機能する前に攻撃をフィルタリングします。

プラグインのほかには Web サーバーに WAF (Web ファイアウォール) をインストールして WordPress で処理される前にコンテンツをフィルタリングできます。もっとも人気のあるオープンソース WASF は ModSecurity です。

またファイアウォールは、ホスティングの提供会社とインターネットの間にも追加できます(中間でのセキュリティ)。ファイアウォールを通過する DNS レコードを変更します。すべてのトラフィックがサイト到達前にファイアウォールによりフィルタリングされます。CloudFlareSucuriIncapsulaなど、いくつかの会社がこのようなサービスを提供しています。

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

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

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

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

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

隠蔽によるセキュリティ

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

  1. 管理者アカウント名の変更: 管理者アカウントを作るとき、簡単に推測されるような言葉(admin とか webmaster)をユーザー名に使うのは避けましょう。真っ先に攻撃対象にされてしまいます。既存の WordPress インストールでは、MySQL コマンドラインクライアントで UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin'; のようなコマンドを入力するか、phpMyAdmin のような MySQL フロントエンドを使用して、名前を変更しても良いでしょう。
  2. table_prefix の変更: 多くの既知の WordPress を狙った SQL インジェクション攻撃は、table_prefix がデフォルトの wp_ であることを仮定しています。これを変更することは、隠蔽によるセキュリティですが、SQL インジェクション攻撃の一部は防ぐことができるかもしれません。

データバックアップ

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

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

ログの取得

調査のためにログを使えば、サイトについて理解するために非常に役に立ちます。ログから、誰がいつ何をしたのかが分かります。残念なことにログからはどのユーザーがログインしたのかという情報は知ることができませんが、IP や時刻などを特定できます。さらに、アタックをすべてチェックできます。クロスサイトスクリプティング (XSS)、リモートファイルインクルージョン (RFI)、ローカルファイルインクルージョン (LFI)、そしてディレクトリトラバーサルの試行といったことです。ブルートフォース攻撃があればその履歴も見られるでしょう。

ログを見るのに抵抗がなくなったら、いつテーマ・プラグインエディタが使われたのか、いつウィジェットが更新されたのか、いつ投稿や固定ページが追加されたのかといったことも見えるようになってきます。ログには、Web サーバー上での犯人調査のために必要なキー要素が全て含まれています。

セキュリティの観点から見た場合に、Web サーバーで使っておきたい大事なオープンソースソリューションが2つあります。これはセキュリティへのレイヤー的アプローチです。

OSSEC はあらゆる -NIX ディストリビューションと Windows 上で利用でき、正しい設定を行えば非常にパワフルです。すべてのログを関連付け、凝集させるというのがその考え方です。すべての access_logs と error_logs を収集するように必ず設定し、サーバーアカウント上に複数のサイトがある場合はそれらも忘れないようにしましょう。また、効果的なログを取るにはデフォルトで含まれるノイズをきちんとフィルタリングするのも忘れないようにしてください。

モニタリング

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

ログの監視

root アクセス権限のある専用サーバーや VPS では、何が起こっているかを監視するために簡単に設定を変更できる権限があります。OSSEC を使えばこの設定がやりやすくなるでしょう。詳しくは OSSEC for Website Security - Part I を参照してください。

ファイル変更の監視

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

目標

ファイルシステムトラッキングの目標は次のとおりです。

  • 変更、追加されたファイルのモニタリング
  • 変更、追加のログ取得
  • 詳細な変更お取得機能
  • 自動警告

一般的なアプローチ

管理者は次のような一般的な技術を使用してファイルシステムをモニタリングできます。

  • システムユーティリティ
  • バージョン制御
  • OSやカーネルレベルのモニタリング

特定のツール

ファイルシステムモニタリングのオプションは次のとおりです。

  • diff - サイトのクリーンなテストコピーをビルドし、本番環境と比較する
  • Git - ソースコード管理
  • inotifyincron - OS カーネルレベルのファイルモニタリングサービス。ファイルシステムイベントに対してコマンドを実行
  • Watcher - Python inotify ライブラリ
  • OSSEC - Open Source Host-based Intrusion Detection System。ログ解析、ファイルの一貫性検証、ポリシーのモニタリング、rootkit 検知、リアルタイム警告と動的対応

注意点

ファイルベースモニタリング戦略を採用する場合、以下を含む多くの注意点があります。

モニタリング用スクリプトやサービスを root で実行する

攻撃者によるファイルシステムモニタリングソリューションの無効化や変更が困難になります。

計画したメンテナンスやアップグレード時にモニタリングを無効化する

サイトの定期的なメンテナンスを実行する際に、不要な警告を回避できます。

実行可能なファイルタイプのみモニタリングする

.php ファイルなど実行可能なファイルタイプのみをモニタリングすれば十分安全です。非実行可能ファイルをフィルタリングから除外すれば、不要なログ出力や警告を削減できます。

厳格なファイルシステムパーミッションを使用する

ファイルパーミッションと所有権について参照してください。一般に、可能な限り execute 権限と write 権限は避けてください。

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

攻撃者がサイトを書き換えたり、マルウェアを追加しようとするとき、ウェブベースの改善検知ソリューションを使用して、これらの変更を検知することができます。今日ではさまざまな形式のサービスがあります。検索エンジンで「Web Malware Detection Remediation」または「マルウエア 検知 修正」を検索してください。多くのサービス提供会社がリストされます。

リソース

日本語

英語

参考

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