V.J.Catkick様
お返事ありがとうございます。
早速相談してみたいと思います。
http://coliss.com/articles/blog/wordpress/security-tipps-for-wordpress-install.html
コリスを参考にするのはやめましょう。海外の情報を積極的に紹介しているのはすばらしいのですが、玉石混交のままなので、役立たずだったりゴミの内容もいっぱいあって、「スキルがない人が読む」には適していません。
ご提示された記事も、以下のコツは効果がないものです。
- テーブルのプレフィックス変更
- wp-contentのリネーム
- インストール済みの保全
- ユーザー名の変更
- バージョンを開示しない
以下のものは適切な用語を使ってなくて混乱を招く情報です。
- ファイルとフォルダのパーミッション (通常パーミッションと言えば 755 とか読み書き実行の権限のこと。robots.txt とは違う話)
以下のものは役に立ちますが情報が古いです。
まあ、今回は「.htaccessの設定」だけが必要な情報で、ここはマトモなことが書いてあるので参考にはなりますが、.htpasswd ファイルの生成が必要なことを書いてないという不備があります (それが分かっている人向けのドキュメントということ)。
http://ja.forums.wordpress.org/topic/8056
wp-login.php を隠す方法は紹介してないようですが……。
IKEDA Yuriko様
そうだったんですね！！
ちまたで言われていても、効果がないものもあるのですね。
教えて下さってありがとうございます。
せっかくなので詳細を書いておきましょう。
* テーブルのプレフィックス変更
* インストール済みの保全
SQL インジェクション対策を想定しているのだと思いますが、WordPress では SQL インジェクションはほとんど起こり得ません。
また、悪意あるテーマやプラグインが DB の中身を読みだそうとしたら、wp-config.php で定義されている $table_prefix を読めばいいので、wp_ 以外にしても効果がありません。
* wp-content のリネーム
これは他 CMS から URL を維持したままコンテンツを移行しようとするための機能であって、あまりセキュリティーとは関係ありません。
だいたい、画像とか貼り込んでしまえば wp-content のありかはすぐバレます。
* ユーザー名の変更
すでに存在するユーザー名を知ることによって、ログインを試そうとしているのだと思いますが、WordPress で存在するユーザーは
http://example.com/?author=1
などのクエリをすることによってすぐ判明します。ユーザー ID を1から順に増やしていけば、存在するユーザーかどうか判明します。
したがって、デフォルトユーザーを admin 以外に変更しても、すぐに管理権限をもっているユーザーがどれか予測することができます。
単純に、「デフォルトのユーザーが admin というのはかっこわるい」という理由で変更するものにすぎません。
余談ですが、ログインパネルで「存在しないユーザーです」「パスワードが間違っています」の区別がされていますが、これもセキュリティーには影響していません。
通常のウェブアプリでは、ログイン時のエラーでユーザー名の失敗とパスワードの失敗のメッセージは区別しないのが鉄則ですが、WordPress はユーザーの存在を上記の方法で調べることができるため、ログイン時に情報を提示しても問題ないわけです。
* バージョンを開示しない
これはいつも論争になりますね。はっきり言うと、鉄則は「常に最新版の WordPress を使う」です。
あるバージョンのWordPressで脆弱性が出たとしても、攻撃者は「WordPress サイトを見つけたらまず攻撃する」のが先であって「バージョンを調べてから攻撃する」なんてことはしないのが普通です。
よって、バージョンを隠したからといって攻撃耐性が上がるわけではありません。
バージョンを隠すのは「よくわかってないセキュリティー監査業者からの指摘を減らす」ぐらいの意味しかありません。
コリスさんは、以前にも WordPress のセキュリティー向上の記事を載せたことがあって、そのとき「バージョン隠しは意味がない」ことを説いたのですが「元記事にあるからそのまま載せています」という回答で萎えました。
つまり、コリスは「元記事の良否を検討せずに紹介している」わけで、だからこそ「参考にしてはいけないサイト」というわけなのです……。
バージョンを開示しない
余談ですが、コリスさんの所に書いてあるように add_filter( 'the_generator', create_function('$a', "return null;") ); しただけではバージョンは隠せません。
http://example.com/readme.html を見れば、バージョンわかるので。
まぁ、ゆりこさんのおっしゃるように「バージョン隠しは意味がない」と言うのは、僕もその通りだと思うので、どうでも良いことですが。
IKEDA Yuriko様
さらに詳しい情報、ありがとうございます！！
先に頂いた回答と合わせて、私のレベルでは難しいので、
社内の分かりそうな者に相談してみました。（まだ返事がありませんが…）
wokamoto様
ありがとうございます。勉強になります。
http://example.com/readme.html を見れば、バージョンわかるので。
さらなる手法として、同梱プラグインである AKismet や WP Multibyte Patch の readme.txt (wp-content/plugins/akismet/readme.txt) を見る 方法もあります。必ずしもプラグインのバージョンと WordPress のバージョンとの一対一対応が取れるわけではありませんが、おおまかな判別が可能です。
wp-login.php へのアクセスを制限してないならログイン画面のスタイルシートにバージョンがついています。
<link rel='stylesheet' id='colors-fresh-css' href='http://thisle.local/~lily/ynet/wp-admin/css/colors-fresh.css?ver=20110703' type='text/css' media='all' />
以前は WordPress のバージョン番号そのままでしたが、最近は日付になっています。しかし、WordPress のバージョンごとに日付が違うので判別材料となります。
他にもさまざまな挙動から WordPress のバージョンを推測することができるので、バージョン番号を隠すだけ、というのは意味がないのです。
こんにちは
先日、お客様から、アドレスの後ろに「wp-login.php」とつけると
どのパソコンからでもログイン画面が見えるのは、鍵穴が見えているようで不安だ
悪意のある人にいたずらされないか心配だと言われました。
特定の人しかログイン画面見れないようにできますか？
実際に運用した話でないので、参考まで
1. wp-login.phpなんて名前じゃいやだ
では、名前を変えましょう。wp-login.phpをコピーnaisyo.phpにして同じディレクトリにおきます。
（ファイル名を知っている特定の人しかアクセスできないよって感じ）
2. .htaccessをつかって、wp-login.phpに特定のIPからしかアクセスできなくしましょう
<FilesMatch "wp-login.php">
Order deny,allow
Deny from all
Allow from 000.000.00.00
</FilesMatch>
こんな感じのアイディアですが
単体のワードプレスなら動くみたいです
マルチサイトなら、ログアウトのリダイレクトでおかしくなるかもしれないです。
も少し手を入れれば、今月は、このログインアドレスでみたいにもできるんじゃないかな
IKEDA Yuriko様
そうなんですね。分かる人からしたら、小手先の対策は何の意味もないのですね…
ありがとうございます。とっても勉強になります！
nobita様
具体的なアイディアありがとうございます！
nobita さん
単体のワードプレスなら動くみたいです
マルチサイトなら、ログアウトのリダイレクトでおかしくなるかもしれないです。
シングルサイトでもログアウトできなくなってしまう気が…… (ログアウトも wp-login.php を使うので)。
login_url と logout_url というフィルターがあるので、これを使って ‘wp-login.php’ を ‘naisho.php’ に書き換える処理を入れる必要があるはずです。
IKEDA Yurikoさん
login_url と logout_url というフィルターがある
そうなんですか、教えていただきありがとうございます。
一応動作は、ちょっとだけシングルサイトとマルチサイトで確認しましたが、見落としがあるかもしれないですね、
ログアウトの時や、wp-admin/にアクセスした場合は、wp-login.phpにりダイレクトするので.htaccessでIPアドレスではじく、
naisyo.phpというファイルを知っていて、IPもあっていれば、wp-login.phpがはじかないので、ログインできるかもという発想でためしましたが
（wp-login.php ,naisyo.php,ダッシュボードが三角形で動く感じ…)
IPが合っていて、wp-admin/にアクセスすれば、wp-login.phpが動いていまうので、ちょっと詐欺かも、、、
マルチサイトでは、ログアウト時に,
http://example.com/blog/wp-login.php?loggedout=true
にならないで
http://example.com/blog/blog/wp-login.php?loggedout=true
という感じになりました。
やってみて、フックもあるとなれば、思ったよりうまく動いてる感があるのですが
思いつきなので、いやな予感がないわけではありません
ご指摘ありがとうございました
loggedout=true はログアウト完了後に移行するアドレスであって、実際のログアウト処理は
http://example.com/wp-login.php?action=logout&_wpnonce=XXXXXX
のようになります。
よって、wp-login.php にアクセスできないとログアウトできません。
そして、ログアウト用の URL は wp_logout_url() で生成されているので、logout_url フィルターで変更してやると naisho.php でログイン／ログアウトができるようになります。
IKEDA Yurikoさん
ありがとうございます。
よって、wp-login.php にアクセスできないとログアウトできません。
そうですね
wp-login.phpを残して、.htaccessでIPアドレスではじいているので、アクセスした人が正当なIPでアクセスしていれば、wp-login.phpは、動きますので、動いたということだと思います。
「動作完了後のアドレス」にリダイレクト出来ていますし、、、
と書こうとしていましたが、「ちょっと、思い当たるところがあり」
マルチサイトの場合
http://example.com/blog/blog/wp-login.php?loggedout=true
リダイレクト先が、
//.../blog/blog/...
になってしまったのは、なぜなんだろうと引っかかっていたのですが、
3.3のお勉強で、チケットを見ていたら、
http://core.trac.wordpress.org/ticket/17243
というのがありました。
シングルサイトは動きましたと書いたのですが、よく考えてみれば、3.3だったんです。
もしかすると、3.2.1では、動かないのかもしれないですね
WordPress3.3大動脈乖離 だと動きましたということに訂正させていただきます。
お手を煩わせてすみませんでした
