WordPress のセキュリティ対策・前編

2008年11月16日 16:45

WordPress のセキュリティ対策について取り上げます。前編と後編に分けてあります。コーディングレベルからプラグインの導入まで、ひととおり考え付く論点を挙げてみますので、追加したいポイントがあれば続編も追加します。個人的な意見にもとづく対策プランも含まれているので、「試案」というよりも「私案」と呼ぶべきかもしれませんが、そのあたりは差し引いて、それぞれの事情に合わせて頂ければよいでしょう。

基礎編の対象

まずどのような方を対象とするかですが、全ての WordPress ユーザを対象にするつもりはありません。最低限の運用スキルとして、

プラグインをインストールできる
WordPress の管理者権限をもっている
WordPress をインストールする環境の FTP アカウントをもっている

という条件があります。つまり、自分でレンタルサーバを借りて WordPress をインストールして使っている方というわけです（いちばん下の条件から順番に、それぞれ直前の条件を含意しているように見えるかもしれませんが、そうではないということに注意して下さい）。昨今はレンタルサーバに自動インストールのサービスがあるため、ボタン一発でサイトに入れてお使いの方もおられると思いますが、その場合はセキュリティの責任がユーザ自身にあるのか、それともレンタルサーバ会社にあるのか不明です。もしレンタルサーバ会社のサービスとして、定期的にアップデートされているのであれば、レンタルサーバ会社に対策をご相談ください。自力でセキュリティ対策をすると、レンタルサーバ会社のアップデート作業によって、あなた自身で対策した環境が上書きされてしまう可能性があります。とはいえ、上げ膳据え膳の環境でも導入できそうな対策はあると思うので、自力のインストールでなくても何かの参考にはしていただけるかもしれません。

それから、WordPress の運用に関して質問されることですが、「PHP を自分でプログラミングできなきゃいけないのか」という点については、もちろん自分でコードを理解し手を入れられたらよいかもしれませんが、ひとくちに「PHP が書ける」と言っても客観的な基準がありません。たとえば僕は Zend Certified Engineer の資格を持っていますが、このようなものは最低限の知識として要求される設問の何割かを正解したという事実を裏書きしているにすぎず、セキュリティ対策を自力で実施できる証明などではありません。また、PHP を実務で使い出してから6年ほどになりますが、何年のキャリアだろうとセキュリティ対策がぜんぜんできないプログラマはたくさんいます（僕がそうでないことを祈るばかりですが）。そのようなわけで、前編と後編に分けていますので、今回の前編ではハードコーディングしなくても導入できる対策に限定して、曖昧な基準のままスキルを求めるようなことはせずに、話を進めたいと思います。

それでも、「このくらいのバックグラウンドがあれば、ハードコーディングを要求される対策にも対応できるだろう」という、何らかの大雑把な指標がほしいというということであれば、「プロダクトリリースしたユーザ管理システムや決済サブルーチンを自力で設計・実装し、サーバの運用も含めてシステムをメンテナンスした経験が3年以上あること」という、ブログを運用するための条件としてはややシビアと思える内容を書かざるを得ません。もちろん、今回のような記事を（不遜にも）書こうとしているくらいなので、僕自身は会員制の（アダルト）サイトで使う決済サブルーチン（決済代行会社とのAPI通信、データベース接続、システムのメンテナンスを含む）を自力で実装した経験がありますし、できばえはともかく販売管理システムも実装して運用した経験があります。したがって、上記のような条件を満たしている人であれば、最低限このくらいは対策を検討するだろうという見通しは、本稿で立てられると思います（もちろん、それで万全というわけではありません）。しかし、結局のところ、いま述べたレベルのスキルをもっている方であれば、後編で述べるような対策は自分で調べて既に対応しているでしょう。

限界

次に、現実的な限界について、あらかじめ書いておきます。まず、レンタルサーバで運用している方が対象ですから、どれほどセキュリティ対策として有効であっても、本稿で対象とする方々には不可能と思われる対策は述べません。例えば、機密性や予防のために IDS やファイアーウォールを導入すべきとか、あるいは可用性のためにバランサーが必要だなどと言っても、レンタルサーバによってはそのようなオプションサービスが提供されていないところも多いでしょう。だからといって「そのようなレンタルサーバで WordPress を運用すべきではない」などと言う権利は、僕にはありません（言おうとも思いません）。

また、「現実的な限界」という言葉の意味としては、技術的な限界だけでなく、もちろん経済的な限界もあります。仮に共用ファイアーウォールのオプションがついていたとしても、レンタルサーバの月額料金が 5,000 円のところで、ファイアーウォールのオプションが月額で +5,000 円もかかるとすれば、ブログの運用予算として受け入れられそうな範囲に収まるかどうかは一概に言えません。それどころか、あなたのサイトだけのためにバランサーや IDS を導入するともなれば、お小遣いや娯楽費としての常識的な範囲を超え、費用は格段に高くなります。

これらに加えて、僕自身が調べたり思いつく範囲の対策でしかないという意味での限界もあります。したがって、ここでは体系的に WordPress でサイトを運営するためのセキュリティ対策を網羅できるとは思いませんし、よくご存知のようにセキュリティ対策は「これで十分、あとは改善の余地なし」という最終の到達点などありませんから、まだ他にも、そして将来に渡っても数多くの対策が可能だと思いますし、必要だろうと考えます。

セキュリティ対策の要約

それでは、これから説明する対策を列挙しておきます。以下をチェックポイントとしてすぐに理解できる方は、本文を読む必要はないでしょう。

ブログシステムが必要かどうか判断すること
適正なレンタルサーバを選定すること
利用する機能を選ぶこと
インストール後の設定を確認すること
セキュリティ対策用のプラグインを導入すること

対策(1): ブログシステムが必要かどうか判断すること

では、さしあたって、WordPress を新規にインストールしようとしている方を想定します。そして、まず考えてほしいのは「そもそもブログシステムを導入する必要があるのか」という点です。WordPress 関連の記事でこのようなことを書くのは身も蓋もないでしょうが、ウェブにコンテンツを公開するときには、事業担当者が業務として行うのであれ、小・中学生が趣味として行うのであれ、リテラシーとしてこのような観点はもっていただきたいと思います。そして、この点はユーザである皆さんだけがやるかどうかを決定できるセキュリティ対策なのです。仮に公開しようとしているサイトが自社のコーポレートサイトであって、せいぜい更新するとしても決算月の翌月に前年度実績のページを書き換えるくらいであれば、ブログシステムを導入したという実績がほしいわけでもないかぎり、はっきり言って無理にブログシステムを導入する必要などありません。自分や自社のリソースでブログシステムを導入したり運用できるのか、そしてブログシステムを導入しなくてもウェブページを更新したり運用できるのかどうか、そういった点を考慮しながら、導入すべきかどうかを決定しておく必要があります。

では、このような点がなぜ「セキュリティ対策」のチェックポイントになるのでしょうか。それは、コンテンツを動的に出力するとか、そしてその仕組みをウェブサイトの運営者がよく理解しているとは限らないという状況を考えると、ウェブサイトで提供しようとするコンテンツによっては静的な HTML ファイルを公開するほうが安全だと言えるからです。もちろん、静的な HTML だけを公開するサイトにも脆弱性や脅威は必ずついて回りますが、不用意にブログシステムを導入することに比べれば比較的安全と言ってよいでしょう。極端に言えば、

<html>
<head>
<title>TEST1</title>
</head>
<body>
<h1>TEST1</h1>
<p>これはテストのコンテンツです。</p>
</body>
</html>

という静的なコンテンツと、

<html>
<head>
<title>TEST2</title>
</head>
<body>
<h1>TEST2</h1>
<p><?php echo $_GET['message']; ?></p>
</body>
</html>

という動的なコンテンツを比較すれば、どちらが脆弱であるかは一目瞭然です。もちろん、WordPress のコアシステムは上記のような愚かなやり方で出力などしていませんが、サイト制作を委託したプロダクションのプログラマが、これと似たり寄ったりのバカなハードコーディングをテーマファイルに加える可能性はありますし、コアシステムにも脆弱性が残っているかもしれません。

したがって、セキュリティ対策の第一歩は、あなたの公開するコンテンツが、ブログシステムを使わなければ公開も運用も負荷が大きくなるようなコンテンツなのかどうかを判断することなのです。もしその判断がつかなければ、制作のプロである（筈の）プロダクションに相談すればよいと思います。

他方、もしあなたが中学生や専門学校の学生あるいは定年退職後の方などなどであって、趣味としてブログを運営したいと思っているなら、Dreamweaver やホームページビルダーといったウェブページの制作ツールを買う余裕があるとは限りませんし、HTML やスタイルシートのコーディングを覚える必要を感じているかどうかは分からないので（コンテンツを公開することが第一の目標であるような人たちに、これらの技術的な知識が必須であるとは思えません。プロとして制作している人やプロを目指す人は別ですが）、ブログシステムの導入は「よい選択」の一つかもしれません。必要を感じない PHP や HTML を勉強して自力の運用システムを組んでしまうよりは、既存のブログシステムを運用する方が安全ですし、システムを導入しなくても HTML や CSS のコーディングに負担を感じてコンテンツの作成まで諦めてしまうようなことになれば、元も子もありません（と、手放しでイデオロギーの含まれる話を呑気に語ってよいかどうか、本当のところ悩んではいるのですが）。

対策(2): 適正なレンタルサーバを選定すること

既にレンタルサーバを借りてしまっている場合は選択の余地が制限されてしまいますが、ブログを運営するとか、コーポレートサイトをブログツールで制作・運営しようと考えていて、まだレンタルサーバ会社を選んでいない方には、情報セキュリティの点から幾つかのアドバイスができます。本稿では「予算がない」とか「そこまでは費用を捻出できない（小遣いがない）」という理由で実現が難しくなる条件を、できるだけ要求しない範囲でセキュリティ対策を考えていこうと思っています。そのため、利用料金がほぼ同じであるとすれば、どういう条件が満たされているほうがよいかという視点で条件を述べておきます。

なお、レンタルサーバを選定する条件として、次回の後編でもご紹介するポイントがあります。これから述べる説明だけで十分というわけではありませんので、もし後編でご紹介するポイントも気になる方は「ファイル転送に SFTP や FTPS が使えるかどうか」という条件も合わせて、レンタルサーバを選定されるとよいでしょう。

WordPress のインストール要件は、PHP 4.3 以上が動作するウェブサーバと、MySQL 4.0 以上で動作している DBMS です（それから WordPress.org へのリンクも！）。昨今の共用レンタルサーバであれば、月額利用料金が数百円の契約価格帯でも、これらの条件を満たしているサービスは多いでしょう。現実的なところでは、月額料金が 3,000 円以下のサービスがよく利用されていると思います（ちなみに、当サイトは Chicappa! を利用していますので、複数のサイトを運営しても数百円の利用料金になります）。他のブログシステムであれば、もっと違った条件になりますし、もちろん PHP 以外の言語で動作するシステムもありますから、ここではひとまず他のツールと比べて WordPress のセキュリティ対策がどうであるかという話は、範囲が広くなりすぎるのでやめておきます。

同じくらいの価格帯で選ぶという前提であれば、大まかにバージョンが新しい方がよいと言っておいてよいでしょう。もちろん、ウェブサーバの Apache については、1.x 系統と 2.x 系統のどちらを使ってもよいですし、WordPress を運用するにあたって両者の違いは殆どないと言えます。また、セキュリティという面でも、両方ともアップデートは続けられていますから、1.x 系統が 2.x 系統より前のバージョンだからといって、最新の脅威に弱いとは一概に言えません。MySQL に関しても、4.x 系統、5.0 系統、5.1 系統、6.0 系統と幾つかの違いはありますが、4.x 系統もアップデートされていますから、5.x 系統でなければ脆弱だと直ちに決め付けてはいけません。したがって、Apache と MySQL については、どちらかと言えば、新しい系統のバージョンを使っているかどうかよりも、セキュリティホールの警告やバグフィクスに対応したアップデートが頻繁に行われているかどうか（それをきちんとサービスのプロモーションサイトで開示しているかどうか）という点の方が重要です。

他方 PHP に関しては、たいていのレンタルサーバでは 4.x 系統と 5.x 系統のどちらかが使われていますが、他のサービスや予算の点で違いがなければ、5.x 系統で運用されているサーバを選択するほうがよいでしょう。最も大きな理由（決定的と言ってもよいでしょう）として、既に 4.x 系統は最終の 4.4.9 以降はセキュリティアップデートがされないからです。もちろん、PHP 本体のソースコードを書き換えて運用するスキルをもっている会社もあるので、一概に 4.x 系統のままだから直ちにいけないというわけではありませんが、Zend Engine をカスタマイズし続けるコストやリスクと、5.x 系統に移行して運用してゆくコストやリスクを比較すれば、4.x 系統から 5.x 系統への PHP 実行環境の移行という一時的なコストやリスクは必ず発生するものの、現状を維持し続けることに大きなメリットがあるとは思えません。これから先も 4.x 系統で運用され続けるサーバは残ると思いますが、それはどちらかと言えばセキュリティやコストという理由よりも、営業的な理由で放置されている（発注されない限りはアップグレードしないとか）と言った方がよいかもしれません。

いづれにせよ、PHP のバージョンが古く、PHP の実行環境にあるセキュリティホールを突かれてもソースコードの改良が行われないのであれば、その上で動作するアプリケーションに対策を講じることが大変難しくなる場合が多く、基本的なビルトイン関数にバグがあると、アプリケーションへのハードコーディングだけでは対処できないこともあります。したがって、もうアップデートされない 4.x 系統を使い続ける環境では、WordPress に限らず PHP のアプリケーションを導入することは再考したほうがよいと言えます。あるいは、既にサーバを借りているならともかく、これからレンタルサーバの契約をするのであれば、既に今年に入ってレンタルサーバを提供している各社は PHP4 から PHP5 に移行し始めていますから、同じ価格帯の中で選択するなら PHP4 のまま放置されていそうなプランを選択すべきではないと言えます。

詳しいレンタルサーバの情報は、日本語版の Codex にたくさん紹介されています。

対策(3): 利用する機能を選ぶこと

WordPress を導入すると言っても、全ての機能を使うわけでないなら、不要な PHP ファイルやディレクトリを公開サーバに展開しておくのはよくありません。もしその使ってもいないコードに脆弱性があって攻撃されてしまうと、全く無意味なコストを後で負担しなければならなくなります。WordPress をインストールする際に、公式サイトからダウンロードして解凍したファイルやフォルダを、そのままサーバへアップロードするのは感心しません。

幾つかのケースに分けて検討してみましょう。まずコーポレートサイトを構築する場合、個々の Pages ページ（特に IR コンテンツや会社概要）や新着情報のページに、トラックバックやコメントの機能を導入する必要はないでしょう。そもそも WordPress を使っていると思われるコーポレートサイトで、コメントやトラックバックを使っている企業は見たことがありません。もちろん企業がそうしている理由の一つは、営業妨害に当たる書き込みや株価を下げるような風評を書かれてしまうリスクがあるからです。

加えて、そのようなリスクがあるからといって、たとえコメントの表示にあたって管理者の承認が必須であるように設定したとしても、コメントやトラックバックをいちいち管理するという運用コストをコーポレートサイトに投入する意味があるかどうかは意見の分かれるところです。ここからは私見ですが、コーポレートサイトにブログシステムや CMS を導入するケースに限って言えば、コーポレートサイトのコメントを管理するという業務は、カスタマーからのクレームを管理する業務とは違って、企業として行うべき価値も意味も殆どないと考えます。もちろん、ウェブサイトそのものが商品である ASP のスタートアップやオンライン店舗であれば、逆にきちんとフィードバックのしくみを導入しなくてはなりませんが、一般企業のウェブサイトに、問い合わせフォームやメールアドレスのリンクよりも複雑なフィードバックのしくみを導入するのは、おおむね無駄と言えます。したがって、コメントの表示や投稿あるいは管理にかかわる PHP ファイルは、サーバにアップロードする必要はありません。（なお、ビジネスブログと混同しないようにしてください。とは言っても、ビジネスブログでさえ、コメントやトラックバックを受け付けていないサイトは多いのです。）

コメントやトラックバックを一切受け付けない場合、最低でも以下のファイルは公開サーバへのアップロードを除外することになります。

/wp-comments-post.php
/wp-commentsrss2.php
/wp-trackback.php
/wp-includes/feed-atom-comments.php
/wp-includes/feed-rss2-comments.php

要するに、外からのコメント投稿やトラックバックを拒否すればよいわけです。当然、コメントやトラックバックはデータとして存在しないので、それらのリストを RDF として表示するためのしくみも不要です。もちろん、/wp-includes や /wp-admin には、テンプレート用のサブルーチンが含まれるファイルや、コメント管理用のファイルなど、更に除外の対象としうる PHP コードは幾つかあります。潔癖を目指すのであれば、それらを全て取り除き、WPLite のようなプラグインを使って、コメントやトラックバック管理の仕組みが見えないようにもできます。

それから、僕自身も利用していない機能として、メール投稿があります。当サイトの記事は長文が多く、それなりにまとまった分量の記事でなければ公開しないと決めているので、出先からメールで数行の記事を投稿する場合は Posterous に投稿するという使い分けをしています。すると、メールでサーバに記事を送り、WordPress から POP3 プロトコルでメールを読みに行くという機能は不要です。

メールの機能全般を全く使わない場合は、以下のファイルを除外すればよいでしょう。

/wp-mail.php
/wp-includes/class-phpmailer.php
/wp-includes/class-pop3.php
/wp-includes/class-smtp.php

このようにケース毎で不要なファイルを除外できるわけですが、一般に、不要な機能の取捨選択にあたっては、特にブログのホームディレクトリ直下にあるファイルを除外することから考えましょう。その理由として、次のように言えます。例えば当サイトの場合は、markupdancing.net の直下に wp-rss2.php というファイルがあります。そして、誰でもこのファイルをリクエストできるようになっているので、このようなファイルはリモートから攻撃にさらされることを前提にコーディングされていなければなりません。堅くコーディングされていなければ、それはそのまま誰からもアクセス可能な攻撃対象となってしまいます。

もちろん、WordPress を導入すると決めたからには、自力でプログラミングしたりオリジナルのシステムを開発会社に発注するよりは賢明だと選択したのでしょうから、一定の信頼はあって当然だと思います。しかし、むやみに妄信すると期待過剰となって、何か問題あると容易く「これだからオープンソースは駄目なんだ」といった反動に向かいやすいものです。どのようなシステムにもそれなりに強いところと弱いところがあり、それはプログラミングだけでは解決しないこともある、ウェブのアプリケーションに限らず、およそ人がつくるものはそうした色々な要素の組み合わせなのだという冷静な姿勢が望まれます。

情報セキュリティについても、一つ問題が見つかっただけでそのシステムを使わないといった潔癖症では、使えるアプリケーションなど一つもなくなってしまうでしょう。何が最も大切なことなのかを指定し、重要度に応じて、許容できる脆弱性や脅威のレベルを一定以下に保つよう注意して運用し続けることが、リスクマネジメントの基本となります。どこかにある完全無欠なブログシステムを導入すれば攻撃される心配がなくなるとか、予算をこれだけかけたらこれだけのセキュリティが維持されるだろうなどという見込みは、少なくとも情報セキュリティに関しては、何の根拠もないでたらめな願望でしかないのです。

さて、ダウンロードしてきた WordPress 本体を解凍してみてすぐに気づくことかと思いますが、

/license.txt（WordPress のライセンス）
/readme.html（説明書）
/wp-app.php（Atom API ライブラリ。元はサードパーティのプラグインでした）
/wp-atom.php（Atom フィードの出力用）
/wp-comments-post.php（コメント投稿用）
/wp-commentsrss2.php（コメントの RSS 出力用）
/wp-feed.php（RSS 2.0 フィード出力用の古いコード）
/wp-links-opml.php（リンクの OPML XML 出力用）
/wp-mail.php（メール投稿用）
/wp-rdf.php（RDF フィード出力用）
/wp-register.php（ユーザ登録用、管理者の登録ではありません）
/wp-rss.php（RSS 出力用）
/wp-rss2.php（RSS 2.0 フィード出力用の新しいコード）
/wp-trackback.php（トラックバック処理と ping 送信用）

上記のうち太字で強調しているファイルは、実際に当サイトで使っていない（サーバにアップロードしていない）ファイルです。これらのファイルは、ブログシステムを導入する目的・用途に応じて、アップロードしなくてもよいものです。特に個人でブログを運営するなら、wp-register.php など全く不要ですし、wp-links-opml.php のようなコードは、頻繁にリンクの一覧をエクスポートするわけでもないでしょうから、必要なときにアップロードすればよいだけで、サーバに放置する意味など殆どありません。

対策(4): インストール後の設定を確認すること

インストールが完了すれば、すぐに管理画面へログインすると思います。ここで WordPress のセキュリティを取り上げているブログやサイトで多くの人が忠告しているのは、“admin” というデフォルトの管理ユーザのユーザ名とパスワードを変更しろという一点です（但し、本家の Codex には書かれていません）。そもそも、このインストール手続きが他のユーザや自動巡回ツールに横取りされないという保証など、本当はどこにもないのです。それゆえ、後編で説明するように、プロダクトリリースのサーバではベーシック認証を設定したり、IP 制限をかけたりするわけです。ともあれ、現状ではそこまで厳しいルールは必要ないと妥協して話を進めているため、インストール作業が完了して、”admin” というユーザのパスワードとログイン先のリンクが表示されるところまでステップを経たと仮定しましょう。

真っ先にやることは、彼らが言うには、デフォルトで作られる “admin” という管理ユーザの、せめてユーザ名を変更すること、あるいは新しい管理者ユーザをつくって admin を削除してしまうことです。どちらがよいかは特に大きな違いがないと思いますが、僕は新しく管理ユーザを作ってから admin を削除しています。既につくったユーザのユーザ名を変更するには、MySQL にクエリを送ってユーザ情報を UPDATE してしまうのがいちばんスマートですが、ここでは説明できませんし、新しく管理ユーザをつくって admin を消す方が楽だからです。もちろん、新しくつくった管理ユーザや、admin を改名したユーザについては、パスワードの強度を上げるようにおすすめします。確かに、SSL 通信をしていなければ強度など上げても殆ど意味はありませんが、管理者権限を奪われるチャンスは、インターネット上の経路でログを取っている第三者だけにあるわけではないからです。不意に他人のブログの /wp-admin へアクセスして遊ぶような人に容易く侵入されてもいけません。

次に、管理画面で設定しておいた方がよいと思われる点を列挙したいと思います。

まずは「一般設定（General）」ですが、ここでは投稿ユーザを追加するわけでもないかぎり、「誰でもユーザ登録できるようにする」という設定は全く不要なので、チェックされていたら外してください。ただし、その次にある、コメントするにはユーザ登録を要するという設定も、コメントを受け付けるのであれば外さなければなりません（管理サイドしかコメントを投稿できなくなります）。外部のコメントシステム（DISQUS, intensedebate など）を導入する場合は、それぞれの環境に合わせて設定するようにしてください。

次に「ディスカッション設定（Discussion）」では、上記のようにコメントの表示にあたって承認制を導入します。管理ユーザが承認しなければコメントを表示しないようにして、自動投稿をなるばく防ぐために名前とメールアドレスの入力を強制します。まぁ、現在のブログシステム用の投稿ロボットは、このような設定をしても殆ど効果はありませんが。それから、WordPress のセットアップファイルに同梱されている Akismet プラグインはぜひ活用した方がよいでしょう。WordPress.com にユーザ登録すると Akismet 用の API キーが発行されるので、その API キーを Akismet の設定画面で入力するだけでＯＫです。

次にすぐ下をご覧いただくと、ブラックリストの設定ボックスがあります。ここには、コメントの入力で認めない文字列を登録しておくわけです。WordPress のコアシステムでサニタイズ処理などの不備があるかもしれませんから、ここにも “script”, “alert”, “<”, “>” といった、タグやスクリプトの実行に使われる文字列を登録して拒否しましょう。やろうと思えばかなりのパターンになりますが、考え方としては “script” という文字列を大文字と小文字で記すパターン、”script” それぞれの文字にヌル文字を挟んだパターン、そしてそれらを異なるエンコードで表現しているパターンなど、何らかの「変換処理をして安全にしようとする対策ベクトル」に対抗する攻撃を、ブラックリストでも拾い上げるという方針を採ることになります。もちろん、この方針は、新しい変換処理が出たり文字の入力間違いで抜け道が発見される可能性が残るという点でリスクは残ります。したがって、サニタイズの処理は文字列を出力する直前で「何を出力しようとしているか」というデータの中身を見て判定しなければ、途中で処理しても無駄と言って良く、場合によっては、そのような処理に依存することが抜け道になってしまう場合さえあります。ですから、ここでの設定は「おまじない」ていどの効果しかない（しかしヘタレ攻撃者への対策にはなる）という自覚が必要です。

今回は前編として、ライトウェイトな対策からご紹介しているわけですが、セキュリティ対策を説明しているブログなどでも見落とされがちな点があり、これはあらかじめ指摘しておく価値があるだろうと思います。それは、コメントの管理画面へうかつに入らないということです。

残念ながら、現行バージョンの WordPress ではコメント管理画面のデフォルト表示が「詳細」になっており、とりわけ管理ユーザのアカウントで投稿されたコメントの文面がそのまま表示されます。もし、先のようなコメント入力の規制を突破して XSS などの攻撃を可能にする文字列が投稿されてしまうと、ブログに表示されなくとも管理画面では全て残らず表示・実行されてしまうのです。しかし、いまのところ「リスト」表示をデフォルトとして強制できませんので、何か問題のある文字列を含んだコメントが投稿されると、管理ユーザが投稿画面へ遷移した瞬間に JavaScript が起動するという、リスクの高い状態のままになります。管理ユーザのコメント投稿は管理画面で禁止ワードを指定していようと、そのまま承認されブログに表示されるので、試しに管理ユーザとして <script>alert(document.cookie);</script> とでもコメント欄に入力してみて下さい。

「そのようなリスクがあるとしても、それは自分自身のアカウントが盗まれた上で、そのような投稿がはじめて可能になるのだ」という理由で、いま述べたような指摘を馬鹿げていると反論する人々もいるわけですが、管理者権限をもっているユーザが複数いるブログでは、他の人のアカウントが盗まれていないかどうか常に管理できるとは限りません。そして、そもそも上記のような反論の裏には、「自分自身のアカウントが盗まれたら、誰だってわかるだろう」という、殆ど根拠のない思い込みがあるように思われます。しかし、盗まれた直後は何も変化がなくても（まだ攻撃者はあなたになりすまして何もしていないのですから）、その次に何かをたったいちど行うだけで攻撃者の目的が成就されるなら、あなたは（たとえ何らかの方法でアカウントを盗まれたことに気づくとしても）攻撃者になりすましで何かをされた後でしか気づけないのです。このような状況が、HTML メールを Outlook Express でおもむろに読むことと大差のない、危険な行為であることがお分かりいただけるのではないでしょうか。

本来は後編で説明すべき内容ですが、この点は後編で再び指摘してもよいくらいの問題なので、具体的な対策を述べておきます。まず、管理画面でコメント管理のページへ遷移したときに、デフォルトで「詳細」表示とならないようにしましょう。それには、ひとまず /wp-admin/edit-comments.php の 49 行目（WP 2.6.3）あたりにある、

if ( empty($_GET['mode']) )
$mode = ‘detail‘;

という箇所を、

if ( empty($_GET['mode']) )
$mode = ‘list‘;

と書き換えます。「詳細」ビューをそもそも使わないように管理画面そのものを書き換えてしまってもよいでしょう。そして具体的に個々のコメントを見る場合、そこでコメントが表示されるときにも対策を講じる必要があるのは言うまでもありません。

対策(5): セキュリティ対策用のプラグインを導入すること

さて、いきなり話は飛んでインストール後の話になります。実はインストールにあたって wp-config.php のカスタマイズやデータベースの接頭辞を変更することなど、色々とやっておきたい対策はあるのですが、これらはひとまず後編に回して、インストールした後の運用を考慮した対策に話をすすめます。

ちなみに、よくウェブアプリケーションのインストールについて、インストールが終わった後に掃除しろと書いてある場合があります。WordPress の場合も、確かに /wp-admin/install.php は、インストールが完了すると不要です。但し、現在のバージョンでは、既にインストールが完了したあとで install.php にアクセスしても、

という表示が出るだけなので、ひとまず他人に上書きインストールされるような心配はありません。

既に他所でも紹介されているように、WordPress のプラグインは 2008 年 11 月 15 日の時点で 3,000 を越える数が公開されています。しかし、これらの中から “security” といった検索で引っかかるプラグインを片っ端から導入していく必要などありませんし、そうすべきでもありません。まず基礎として導入しておきたいものとしては、

こういった辺りになるでしょうか。特に最後の TTC -* シリーズのプラグインは、クリス・ピアソンさんのサイトで数多く公開されており、サイトの目的に応じて利用されるとよいでしょう。

では、まず WP Database Backup（上図）から説明します。冒頭で述べたように、プラグインのインストールについては説明しません。殆どのプラグインは、解凍したフォルダをそのまま /wp-content/plugins 配下へアップロードし、WordPress の管理画面でアクティブにすれば使えます。キャッシュやログやアップロードといった、ファイルを出力するプラグインは、決められたフォルダに書き込み権限を追加すればよいくらいで、FTP クライアントソフトを扱える方であれば苦労はないでしょう。

このプラグインは、WP Backup and Restore や WP-DBManager など、他にも幾つかあるバックアップ用のプラグインです。WP Backup and Restore は少し古いプラグインなので、上記の WP Database Backup か、WP-DBManager を選べば、バックアップという目的の用は果たせます。もちろん、レンタルサーバのコントロールパネルに phpMyAdmin などのデータベース管理ツールが用意されていれば、データベースからデータを直に取り出してバックアップできます。また、WordPress 管理画面の Manage（管理）メニューにある Export（エクスポート）画面で、WordPress のオリジナルデータ形式をダウンロードできますから、あれば便利という程度のプラグインと言えます。

バックアップについて基本的な知識は、日本語版の Codex にあるバックアップのページをご覧になればよいでしょう。

次に WP-Security をご紹介します。これはセキュリティの観点から、チェックしておくべき設定やサーバ環境を調べて報告してくれるプラグインです。レポートの内容と具体的な対策は、後編に該当する内容が大半を占めるので、ひとまずこれをインストールしておくことが基礎レベルの対策となります。

それから次の BTEV プラグインは、

password_reset（パスワードリセット）
delete_user（ユーザ削除）
wp_login（ユーザのログイン）
lostpassword_post（パスワードリセットのリクエスト）
profile_update（プロフィールの更新）
add_attachment（ファイルのアップロード）
wp_logout（ユーザのログアウト）
user_register（ユーザ登録）
switch_theme（テーマの切り替え）
プラグインの有効・無効化
invalid_username（不正なユーザ名）
invalid_password（不正なパスワード）
WordPress から送信されたメール

これらのイベントを検知してログを残します。これも、基礎の対策としてご紹介するにとどめておきたいと思います。レンタルサーバの環境では、これ以上のレベルで攻撃されても、サーバ会社の方で対策をとってもらう以外は何もやりようがない場合もあるため、こうしたプラグインを使うからといって、何かが劇的に改善されるわけではありません。しかし何もせずに運用するよりは「よい」と言えますし、それほど過大な管理コストがかかることでもないので、現実的なメンテナンスのツールとして、インストールすることは望ましいと思います。

次にリストで紹介した Replace WP-Version というプラグインは、特に管理画面で何かを設定するものではなく、アクティブにすれば即座に有効となります。このプラグインの役割は単純で、WordPress のバージョンを具体的に表示しないというものです。もちろん、WordPress というブログシステムの名称も、あまりあけすけに表示するようなものではありませんし、コーポレートサイトで使う場合は、バージョンどころか WordPress というツール名を隠すのが当たり前のようになっています。

このプラグインを使う理由としては、ブログシステムのバージョンアップをしていない（つまりセキュリティホールが存在し広く知られているなら、攻撃対象となる）ことを、わざわざ告知しないためです。このような隠蔽は、ウェブサーバの Signature を表示しないとか、PHP を .php という拡張子で動作させないようにするとか、さまざまな方法で行われています。

最後に TTC WordPress Security Tool をご紹介しておきましょう。

上記の画面が TTC WP Security Tool で表示している設定画面です。このツールは、主に wget コマンドや検索エンジンのロボット、あるいは俗に言う「ホームページダウンロード・ソフト」のアクセスを遮断します。こうしたツールも、後編で言及すると思いますが、.htaccess でアクセスを遮断する方法があり、既に出来合いの「ボットリスト」や「国別 IP アドレスのリスト」が存在しているため、補助的な役割のツールとして扱う方が無難です。また、同じシリーズからは TTC Tripwire というツールも公開されており、

こちらはファイルのアップロードや更新（上書きとか削除）があるとログを残してくれます。これもセキュリティという点では便利なプラグインの一つです（ウェブサーバのログからこうした情報だけを引っ張り出すのは、なによりも面倒だと思います）。但し、WordPress で出力するページをキャッシュしてくれるプラグインと同時に使っていると、アクセスの多いサイトでは（キャッシュを維持する間隔が短いと）キャッシュ保存のログだけが肥大化してしまうため、他のログが埋もれてしまいかねないので、注意が必要です。

ひとまず前編でご紹介する対策は以上となります。中にはコーディングを要するものもありますが、リスクをよく自覚して扱えば（あるいは、扱わないと決めれば）、何も考えずに運用しているよりも効果はあると思うので、詳細なコーディングの内容は後編に回すとしても、敢えて先にご紹介しました。

Related / 関連リンク