皆様はじめまして、モリイです。本業ではWordPress専用のセキュリティ診断サービスを運営しています。
さて、ご存知の方も多いとは思いますが、WordPressは攻撃者によく狙われます。
その理由の1つは高い導入率です。LIGブログでも以前こちらの記事「みんなは知ってる？WordPressの特徴と人気の理由を分析してみた」で紹介されていたように、世界で一番人気のCMSです。WordPressで作成されたサイトは世界中に9000万以上あると言われており、悪意を持っている人物にとっては格好のターゲットです。
また、WordPressだけではなく、CMS一般、例えば、Drupal、EC-CUBEなどにも言ることですが、構造がパターン化されており、そのCMSを利用しているということが一目でわかる、ということも攻撃される理由に挙げられます。
そこで、サイト管理者は攻撃者からサイトを守らなければいけません。みなさんも様々な対策をなさっているかと思いますが、今回はあなたのサイトが安全かどうかを確かめるためのチェックリストを作成したので、ぜひ活用してみてください。
では、はじめます！
WordPressの攻撃者を知る
と、その前に。古代中国の兵法家「孫氏」も言うように、戦をするにはまず敵を知る必要があります。すなわち、考えるべきは「攻撃者」が何を考えているか、です。
ここで言う「攻撃者」を知るためには、まず、以下の3つの事柄の理解が必要です。
- 何で狙われるの？
- どうやって攻撃されるの？
- 攻撃されないために何が必要なの？
ひとつずつおさらいしていきましょう。
何で狙われるの？
そこに山があるからです。というのは冗談でもなんでもなく、テロと同じで、そこにたまたま攻撃しやすいサイトがあるから攻撃するのです。
多くの攻撃者は意図的に特定のサイトを狙うのではなく、自動攻撃ツールを動かしてみて、サイトの改ざんや機密情報の取得が容易そうだったからついでにやってみた、あるいはセキュリティ対策を全く実施していないことや、ログインIDやパスワードが推測可能だったことにより、サイトにログインできたし何となくデータを書き換えてみよう、といったレベルの話が多いです。
ですから、基本的な対策をキチンと実施するだけでも、多くの攻撃者に「面倒だな」と思わせ、攻撃を防ぐことができます。
どうやって攻撃されるの？
あなたのサイトにアクセスすれば、ブラウザで様々な情報を取得できます。例えばリクエストヘッダ、レスポンスヘッダ、ソース内の非表示コメント、あるいはバージョンの古いソフトウェアやミドルウェアの情報が開示されている可能性もあります。
サーバーの設定で隠せるものもあれば、隠すことが不可能なものもあります。が、せめてソース内の非表示コメントには機密情報を記載しないようにしましょう。
攻撃されないために何が必要なの？
まずは、攻撃者が攻撃する際に指標とするデータを表示しないようにすることです。上に記載した情報を表示しないようにするだけで攻撃されるリスクは大きく下がります、
攻撃者も自動攻撃ツールも、攻撃できる糸口があって初めて攻撃を開始してくるのです。誤解を恐れず言い切ってしまえば、セキュリティ対策とは「どれだけ情報を隠せるか」が大事です。
実際、攻撃者本人が直接サイトを狙うのは攻撃という概念の最終段階であり、それ以前の攻撃とは、攻撃者が作成した、もしくはネット上に霧散している自動攻撃ツールによって「ログインに成功した」「低難易度かつ範囲の広い脆弱性が存在する」「確実に目的のデータが存在する」などを判定することです。
以上のプロセスを経て、価値が高いと思われるサイトにのみ攻撃を実行し、目的を達成するというのがサイト攻撃の定石です。つまり、攻撃者もヒマではないのです。
WordPressサイトの管理者向けセキュリティ対策方法チェックリスト
では、それらを踏まえた上で、攻撃者からサイトを守るための対策方法をチェックしていきましょう。
下記の対策を実施すれば、自動攻撃ツールの攻撃を防いだり、攻撃者の攻撃を諦めさせたりすることができます。
□ResponceHeader中の情報を隠ぺいする
「Server: Apache/2.2.25」のように、現行利用中のOS・ミドルウェアが記載されており、かつその利用バージョンに脆弱性が存在している場合は、そこが攻撃の糸口にされるされる恐れがあります。例えば、Apacheのhttpd.confにおけるServerTokensを、Prodに設定しましょう。
また、「X-Powred-By PHP/5.4.28」のように、現行利用中のミドルウェアが記載され、かつその利用バージョンに脆弱性が存在している場合は、それも攻撃の糸口にされるされる恐れがあります。OSミドルのインストール時にデフォルト表示されるものではなく、特定のCMSなどを利用した場合にデフォルト表示される場合があるため、例えばphp.iniのexpose_phpは、Offに設定（expose_php = Off）しましょう。
□htmlソースコード中の情報を隠ぺいする
ソース中のmeta name=”generator” content=”WordPress 3.○.○”にはワードプレスのバージョンなどが表示されています。必要ないので削除しましょう。functions.phpにremove_action(‘wp_head’, ‘wp_generator’);と記載すれば非表示にできます。
また、ソース中の<link rel=”EditURI” type=”…には、ブログ編集用のアドレスが書かれています。管理画面上でのみブログを編集する場合は必要がないため削除しましょう。functions.phpにremove_action(‘wp_head’, ‘rsd_link’);と記載すれば非表示にできます。
なお、開発中はスクリプトやDBへのアクセス、バッチで行われる処理内容などについて、ソース中にコメントを書くことがよくあります。しかし、コメントは内部のファイル構成や処理の流れなどを推測させてしまう情報になります。リリース前にコメントはでき得る限り削除しておくほうがよいでしょう。
□特定のディレクトリやファイルに対してアクセスを制限する
重要なファイルやディレクトリの推奨設定パーミッションは700です。ただし、pluginやthemeを利用する際に755を求められる場合がありますので、その際は755のパーミッションを設定するしかありません。
また、705の場合であっても/区切りでディレクトリにアクセスされた場合、該当ディレクトリの一覧が表示とディレクトリ内のファイル一覧が閲覧可能となりますが、外部からの書き込み権限が存在していないため、ファイルの改竄やファイルの設置をされることはありません。
仮にアクセスできても単なるファイル一覧が表示されるのみですが、testファイルや見られたくないファイルが存在する場合、アクセス者に存在がバレてしまうため、httpd.confのDirectoryIndexに以下のような記載がなければ追記してください。
<IfModule dir_module>DirectoryIndex index.html</IfModule>と記載し、index.htmlファイルを設置するようにしましょう。index.htmlを設置しない場合、大体は画面が真っ白になります。
□wp-config.php・.htaccessファイルのパーミッションを確認する
- wp-config.php 600（本来400が望ましいが、動作しなくなる可能性が高くなるため）
- .htaccess 600（動作しない場合は644でも可だが、other4だと誰からでも読まれてしまう可能性がある）
上記は代表的なファイルパーミッションについての記載ですが、システム環境に依存したり、pluginを利用する際に755を求められたりします。大事なことはファイルパーミッションを適切に設定するという心構えです。
□自動アップデート後はパーミッションを変更する
特に自動アップデートを実施している方は、自動アップデート実施後のパーミッションを変更しましょう、自動アップデートを実施した場合、全てのディレクトリのパーミッションは755に、ファイルは644に設定されるため容易に誰もが閲覧可能な状態となります。
WordPressの利用上、安全を考慮した場合、自動アップデートを推奨いたしますが、自動アップデートを実施することにより、既存のプラグインやテーマが動作しない、という事態が発生する場合があります。設備に余裕がある場合、本番環境は自動アップデートを切り、テスト検証環境でアップデート後の動作を確認後、本番環境でのアップデートを実施することをおすすめします。
□wp-admin/wp-login.phpに対するアクセス制限をする
アクセス制限方法は他にもいくつかありますが、代表的なものを記載します。可能であればリダイレクトや.htaccessを設置することによるベーシック認証ではなく、IP認証を用いた接続制限が望ましいです。
例えば、.htaccessによるベーシック認証の場合、そこにアクセスされたくないディレクトリやファイルが存在していると推測される恐れがあります。IP認証が難しい場合のみ、.htaccessによるベーシック認証を利用してください。
また、wp-login.phpにログインするためのデフォルトユーザーであるadminは削除し、可能な限り推測が難しいアカウントで管理しましょう。
□table_prefixを変更する
WordPressを狙う攻撃手法の1つにSQLインジェクションという攻撃手法が存在します。WordPressはインストール時から変更しないとデフォルトtable_prefixがwp_と表記されたままなので、条件により攻撃者に推測されSQLインジェクションを実施される可能性があります。ここへの攻撃が成功してしまうと、簡単にDB上の機密情報を閲覧されたり変更されたり削除されたりしてしまいます。
※6/19追記：分かりにくい表現がありましたので修正しました
もちろん、wp_を変更すれば大丈夫かと言うとそうではありませんが、攻撃者に容易に標的とされることがないように、wp_の接頭辞を変更しましょう。
□404ページを設置する
httpd.confに記載する場合、ErrorDocument 404 /error/404.htmlと、httpd.confに追記しとけば良いでしょう。ちなみに、404.htmlでも404.phpでも拡張子は何でもOKです。/error/404.htmlとした場合、var/www/error/に設置された404.htmlが参照されるため、ディレクトリは適切に変更してください。
また、apache標準の404NotFoundページには不必要なOSやミドルウェアのバージョンが記載されている場合があるので可能な限り加工しましょう。
□ソフトウェア、ミドルウェアを可能な限り最新のバージョンに保つ
WordPressでサイトを構築する際にデザイン性の高い「動き」のあるサイトにする場合、jQueryを利用されると思いますが、jqueryのバージョンを最新とすることを忘れないでおきましょう。セキュリティ診断の際に10社中9社指摘することがあるくらい、放置されているが重要な内容です、jQuery/jQuery Mobile共に可能な限り最新のバージョンを利用するようにしましょう。
また、WordPress本体、プラグイン、テーマについては、バージョンを上げる場合にかならずバックアップを取る、これが基本です。また、当たり前ですが、旧バージョンの利用を続けると、脆弱性が存在する場合があります。可能な限り速やかに最新バージョンにアップデートしましょう。
まとめ
本日ご紹介した内容は、攻撃者に狙われるケースが非常に多い項目について、最低限これらに注意し「出さなくて良い情報は極力無くして運用しましょう」という例となります。
少なくとも、上記の設定が正しく行われていれば自動攻撃ツールレベルによる被害は格段に減少させることができるはずです。
これからFW、IDS、IPS、WAFの落とし穴についてや、セキュアプログラミングでも防ぎきれない攻撃への対処法についてもいずれ書きたいと思ってます。
それでは、また！
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
