WordPressのセキュリティをアップする11のポイント
WordPressのセキュリティをアップする11のポイントをPro Blog Designのエントリーから紹介します。
11 Best Ways to Improve WordPress Security
- セキュアなデータベースを構築する。
- 他のアプリケーションと共有しないWordPressのためだけのデータベースを使用する。
- データベースへのアクセスは限定する。
- データベースのパスワードは強固なものにする。
- 「wp-config.php」の設定。
- セキュリティキーを設定する。
セキュリティキーツール 1.1でランダムなキーが生成されます。 - テーブル名の接頭辞（$table_prefix）を「wp_」以外のものに変更する。
- セキュリティキーを設定する。
- 管理画面のユーザー名にデフォルトの「admin」を使用しない。
ユーザー名はphpMyAdminなどで変更できます。 - 管理画面のパスワードは複雑なものにする。
英数記号文字、小文字、大文字などを混ぜて作成します。 - SSLが可能な場合は、管理画面へのアクセスはSSL経由で行う。
その場合は、「wp-config.php」に下記を記載します。
- 常に新しいバージョンのWordPressを使用する。
バージョンアップの内容が機能面で必要ない場合でも、セキュリティの修正がされていることがあります。 - データベースはバックアップをする。
セキュリティとは関係がないかもしれませんが、プラグインなどを利用して定期的にデータベースはバックアップします。 - ディレクトリにアクセスできないようにする。
ディレクトリのルートに直接アクセスされないように「.htaccess」に下記の設定を行います。
- 「wp-admin」を保護する。
「wp-admin」内のファイルは管理者しか使用しないので、アクセス制限をします。
「.htaccess」で制限をする場合は「.htaccess」を「wp-admin」に設定し、IPの制限やパスワードの制限をします。
IPで制限
- 「wp-content」を保護する。
「wp-content」内のファイルに一般ユーザーがアクセスするのは、使用しているテーマとプラグインだけのため、拡張子でアクセス制限をします。
「.htaccess」を「wp-content」に設定し、アクセス可能な拡張子を指定します。
- WordPressのバージョンを表示しない。
head内のWordPressのバージョンを表示させないためには、使用しているテーマファイルの「function.php」に下記を指定します。
「function.php」無ければ、新しく作成します。
- 追記：
- 11番目の「function.php」を適用する際は、最初と最後に改行が入らないように注意してください。
- つい末尾に改行を入れてしまったら、feedのxmlに空白行が入ってしまい、エラーになってしまいました。
Post on:2008年12月17日
Comments
ハーフボイルドペーパー 2.0
on 2008年12月18日
WordPressのためのメモ
WordPressのセキュリティをアップする11のポイント
http://coliss.com/articles/blog/wordpress/2853.htmlとりあえず、WordPress構築後のためのメモ書き。忘れないようにね。
ゆりこ
on 2009年1月23日
11番目の、WordPress バージョンを隠すことについてですが、セキュリティーの向上に繋がるかどうかは、少々疑問があります。Apache や PHP のユーザー間では、以前から、Apache, PHP のバージョンを隠すことの意義について議論がされており、セキュリティー向上にはならないという意見に一定の支持があります (攻撃者はバージョンなぞ見ずにいきなり攻略コードを送るから)。ただし、独自にパッチを当てた等、みかけのバージョンが古いままの場合、「指摘がうざい」という理由でバージョンを隠す人もいます。ちょっと検索されると、いろいろ議論が見つかると思います。
WordPress バージョンについても同様の議論があてはまります。少なくとも「古い (==危険な) バージョンを使っているとき、バージョン番号を隠しても安全にはならない」ことは確実です。「バージョンを隠せば安全になる」と勘違いする人を減らすため、11番目の項目については、上記の点について注釈を入れられないでしょうか。
コリス
on 2009年1月23日
> ゆりこ さん
情報、ありがとうございます。
それを実施するだけで絶対安全かというと、11のポイント全てに当てはまってしまいます。
そのため、11のみクローズアップして、逆に1～10を実行すれば絶対安全であると、とられるのは避けたいと思います。
> バージョン番号を隠しても安全にはならない
確かにそれ自体に効果はないですが、古いバージョン番号の公言がきっかけになってしまうこともゼロではないと思います。
ゆりこ
on 2009年2月13日
お返事遅くなってすいません。
「ゼロではない」というのは間違っていないのですが、「ほぼゼロに近いのではないか」ということなんですが……。
こういう意見も、すでに Aapache や PHP のバージョン番号についての議論で出尽しています。ですので、これらの議論について、調べられることをおすすめします。
コリス
on 2009年2月13日
> ゆりこ さん
このエントリーは、Apacheでもなければ、PHPのバージョンに関するものではありません。
また、「function.php」を編集することはできるが、WordPressをアップデートすることができないというケースもあります。
ターゲットにされたアウトでしょうけど、バージョンだけでターゲットにする場合もあるでしょう。
可能性を少しでも取り除くことが、よりセキュリティにつながると思います。
もし、英語に問題無いようであれば、本エントリーの参照記事のサイトで討論された方がよいと思います。
Apache, PHPの議論は優劣つけがたいものでしょう。個人的には、少なくともエンドユーザーに知らせる必要がない情報であると思います。
ゆりこ
on 2009年2月13日
ちょっと長いですが、お付き合いください。
いえいえ、Apache や PHP のバージョンを隠すことに関する議論が、そのまま WordPress に当てはまる、ということですよ。違うソフトウェアながら、サーバー上で動作するアプリケーションという共通点がありますから。
どれだけ安全になるかは、かなり疑問なんです。よくある反論として、「攻撃者は、いちいちバージョン確認なんかせずに、絨毯攻撃のように多数のサイトを自動ツールで狙っている」というものがあります。
あと、バージョン番号を本当に除去したいなら、実は
remove_action('wp_head', 'wp_generator');の記述だけでは不十分です。まず、WordPress 2.6.5 以前の場合、wp-login.php にアクセスすると、HTML ソースの head 部分で、スタイルシートを呼ぶ部分に WordPress バージョンが入ってしまっています (WordPress 2.7 以降では、「ver=20081210」のような文字列になっています)。
そもそも、ログイン画面のデザインを見れば、2.0／2.1〜2.3／2.5〜2.6／2.7以降 の区別は簡単に付くことはご存知だと思います。
次に、WordPress の readme.html ファイルをサーバーから除去することが必要です。残念ながらコリスさんのサイトでも、http://coliss.com/readme.html が存在するため、バージョンが推測できます。
本気でバージョン番号を隠すことがセキュリティー向上になるとお考えならば、これらの手法にも言及するべきです。セキュリティーというのはちょっとでも漏れがあると意味がありませんので、他にバージョンを知る手段があれば、wp_generator アクションの除去という行為も無駄になってしまいます。
実は、問題の本質はそこではないんですよ……。。コリスさんが、英語の記事をそのまま鵜呑みにして翻訳されていることを、問題にしているんです。海外の情報を日本語化して紹介するという活動はすばらしいと思いますが、玉石混交な情報をうまく選別して頂きたいと思うのです。
今回の元記事はけっこういい加減なので、注釈が必要だと思いました。もし、コリスさんが的確にコメントを入れられれば、さらに記事の質が向上するかと思います。現状では、元記事のダメな部分がそのまま残っており、他の人が参考にするにはちょっと物足りない状況です。
コリス
on 2009年2月13日
> ゆりこ さん
前のコメントにも書きましたが、１１番のケースは有用な場合や必要な場合があります。
ゆりこさん自身も『「ゼロではない」というのは間違っていない』と認識されていると思います。
そのため、当方では特に変更する予定はありません。
「readme.html」の件、ありがとうございました。
自動アップデートすると、自動でアップされてしまうのですね。
気がつきませんでした。
また、元記事がダメな記事だとは判断していません。
※上記のみで充分とも思っていませんが。
元記事がけっこういい加減であると思われるなら、元記事にてコメントするか、自身のブログなりで言及すればよいのではないでしょうか。
問題の本質はそこだと思いますよ。
あと、当サイトの記事は「鵜呑み」して書いているものではありません。「鵜呑み翻訳」はひとつもなく、すべて「意訳」です。
１１番も、有用な場合、必要な場合があると判断しています。
WordPressのセキュリティをアップ « こま切れblogの詰め合せ
on 2009年10月30日
[...] WordPressのセキュリティをアップする11のポイント [...]
WordPressニュース＆Tips » Blog Archive » WP Security Scan
on 2009年11月4日
[...] こちらのWordPressのセキュリティをアップする11のポイントを実行していれば問題ないと思います。 [...]
WordPress はてなからの移行から設定までのサイトまとめ | ソースコード備忘録Press
on 2010年2月5日
[...] WordPressのセキュリティをアップする11のポイント [...]
Wordpressをcoreserverで自動アップデートするには « teramemo
on 2010年6月23日
[...] WordPressのセキュリティをアップする11のポイント | コリス [...]
Wordpress Settng Log. « Logs.
on 2010年8月3日
[...] 更にセキュリティを強化したい時は、 こちらを参考にさせてもらいます。感謝！ No Comment Ping RSS [...]
CMSが狙われている。WordPressセキュリティ対策 | ネタ喰い
on 2010年8月31日
[...] WordPressのセキュリティ対策は、 WordPressのセキュリティをアップする11のポイント | コリス [...]
WordPressのバージョン情報を消す。 | egoblock.net
on 2010年9月1日
[...] WordPressのセキュリティをアップする11のポイント（coliss.com）という記事でバージョン情報は表示しない方が良いとあったのでHTMLソース上に表示される<meta name=”generator” content=&# [...]
WordPressが狙われている？セキュリティ対策 | Webit NET
on 2010年9月7日
[...] WordPressのセキュリティをアップする11のポイント | コリス [...]
AKIBE - さくらのVPS CentOSでサーバ構築 8 - PHPとWordPress
on 2011年4月30日
[...] から行った方が間違いが無く、認証用のユニークキーも自動設定してくれるので楽です。また、初期設定時に以下の項目を確認することで、少しはセキュリティアップになります。 参考 [...]
.htaccessでセキュリティ対策 | Country Netlife plus
on 2011年11月25日
[...] WordPressのセキュリティをアップする11のポイント | コリス [...]
yuji
on 2012年2月29日
初めまして。
いつも楽しく読ませていただいております。
いきなりで申し訳ないのですが質問させてください。
８の「ディレクトリにアクセスできないようにする。」を見て、
ドメイン直下の.htaccessに「Options All -Indexes」そのまま記述してアップロードした結果、トップページより下層がエラー500になってしまいました。
慌てて元の状態に戻し、再度アップロードしたのですがエラー500状態のままです。
何かの設定を上書きしてしまったのでしょうか？
自分なりに色々調べてみたのですが…正直お手上げ状態です。
無知でお恥ずかしいのですが、お力をお貸しいただければ幸いです。
サーバーはロリポップです。
気が向いたら、よろしくお願いします。
コリス
on 2012年2月29日
> yuji さん
ロリポップとのことなので、下記ページに手がかりがあるかもしれません。
http://lolipop.jp/support/faq/etc/000650/
yuji
on 2012年3月1日
コリスさん
御返事ありがとうございます。
パーマリンクを再設定したら回復しました！！
お騒がせいたしました！！