ラベル セキュリティ対策 の投稿を表示しています。 すべての投稿を表示
ラベル セキュリティ対策 の投稿を表示しています。 すべての投稿を表示

2024年7月3日水曜日

【備忘録】WordPress.org で２段階認証を有効にする方法

突然、WordPress.org へのログインができなくなって ??? と思ったのですが、WordPres.org Plugin Directory からのメールをみて納得しました（6月29日に届いていた）。

件名：[WordPress.org] Password Reset Required for Plugin Authors

内容としては、一部のプラグイン作者がパスワードの使いまわしをしていて、そのパスワードが WordPress.org とは異なるサイトで漏洩してしまい、これを悪用されたかで WordPress.org のプラグインディレクトリのいくつかのプラグインに悪意あるコードを追加されてしまった模様という感じですね。

Password Reset Required for Plugin Authors – Make WordPress Plugins

一時的に全プラグインのコミットはチームによる承認制なって対策していたということです。現在は解除されているとのこと。

で、プラグイン作成者とセキュリティ研究者によって漏洩したとおもわれるパスワードを使っていたユーザーについて、WordPress.org へのログインパスワードを無効化（強制リセット）したということです。

プラグイン作成者は、パスワードのリセットが必要になったわけですが、同時に２段階認証を有効にするように推奨しています。というわけで私のパスワードも無効化されていたのでした。

WordPress.org は、2023年5月から２段階認証を導入していた


下記のようにプラグインコミッターは、少なくてもパスワードに20文字以上で、大文字小文字記号を含め、他のサービスで使いまわししないようにとあります。私自身はランダム生成のパスワードをつかっているので、使い回しはありませんが、パスワードは12文字だったので今回20文字以上にしました。

Keeping Your Plugin Committer Accounts Secure – Make WordPress Plugins

プラグインコミッターでなくても、アカウントへの不正アクセスを防ぐためにも２段階認証は有効にしたほうがよいですね！ 私もしていたつもりがしていなかったので今回してみました。

STEP 1. Two-Factor App と Two-Factor Backup Codes を有効にしてみる




下記にアクセスします。


Two-Factor Apps


あらかじめ、 スマートフォンに Google Authenticator や Microsoft Authenticator など２段階認証用のアプリをインストールしておきます。そして、Two-Factor App をクリックして、表示されたQRコードを、そのアプリで読み込みます。すると6桁の数字が一定時間ごとに変更されたものが表示されるので、その数字を入力して設定を完了します。

Tw-Factor Backup Codes


ここをクリックすると10個の緊急時用の１度のみ使えるバックアップコードが発行できます。もし２段階認証として使っていた端末やアプリが使えなくなったときにログインできるコードになります。どこかにメモっておきます。

STEP 2. Two-Factor Security Key を有効にする


最近流行りのパスキーです。

パスキーの詳しい話は、Googleの公式ヘルプあたりをチェックするとよいかなと思います。

パスワードの代わりにパスキーでログインする - Google アカウント ヘルプ

こちらは端末ごとに設定しておくことになります。パスキーに対応している端末をお持ちの場合には設定しておくと便利ではあります。

下記の「Register new key」をクリックして、名前をつけて設定します。
macOS をお使いなら、iCloud キーチェーンのほうに保存しておくのがよいでしょう。


設定するとパスキーがメインの認証方法になります。


STEP 3. 実際にログインを試してみる



各ブラウザについてプライベートモード（Cookieとキャッシュを無効化したログインしていない状態）にして、WordPress.org にログインしてみます。

アカウントとパスワードを入力すると、下記のようにパスキーを聞いてきます。
macOSと iPhoneをセットで持っているなら、iCloud キーチェーンで同期しているため、iPhoneのカメラで下記のQRコードを読み取ってアクセス。iPhoneのほうで認証します。iPhoneで顔認証を有効にしていれば、顔認証をすることで認証できることになります。

それができない（オンラインでない）場合には、「キャンセル」ボタンをクリックして、下記のようにエラーがでてきたら「User your authenticator app」を選択して、スマートフォンに設定したはずの認証アプリに表示されている WordPress.org 用の6桁の数字を入力すればよいです。この認証アプリについてはオフラインでの利用が可能です。


２段階認証を有効にしておけば、パスワードが漏洩したとしてもログインされることはなくなります。特にパスワードの使い回しをすると、他の脆弱なサイトで漏洩する危険性があるので、そうしないように気をつけないといけませんね

なおパスワードを考えつかない！という場合には、パスワード生成してくれるサイトは検索すればいろいろでてきます。そうしたものを活用してパスワードをランダム生成して、それをブラウザのパスワードマネージャーに保存する、メモするなどをしておくとよいかと思います。

2024年7月3日 @kimipooh
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2020年3月11日水曜日

WordPress では /?author=数字 で WordPressのユーザー名（ログインID）が漏洩してしまう件の対応について

何が問題か


WordPress では、
  • WordPressサイトのURL/?author=数字
にアクセスすることで、
  • WordPressサイトのURL/author/ユーザ名
に自動転送される仕組みになっています。
これを悪用すれば、
  • WordPress のユーザー名に割り当てられている「すべての」ユーザー名（ログインID）を知られてしまいます。
このことは
にあるように脆弱性診断システムなどで脆弱性ありと判断される場合があります。

対策しているかどうかの確認方法


コマンドラインツール curl を使えば（macOS には標準搭載）、たとえば、 http://example.com に WordPressのサイトがあるとすると
  • curl -v -D -  "http://example.com/?author=1"
と Mac ならターミナルから入力することで、標準出力にヘッダー情報が出てきます。
そこの location: をみると
  • location: http://example.com/author/ユーザー名/
になってユーザー名が見えてしまっています。これが存在しない場合、ユーザー名でない場合には何らかの対策がされているということになります。

実際にウェブサーバーログをみると、
?author=1
?author=2
?author=3
?author=4
...
など大量にスキャン（ポーリング）されているサイトもありました。

ユーザー名が漏洩したからといって即座に問題になるとは限らない


先に説明しておきますが、ログインのユーザー名が漏洩したからといって、それだけで不正ログインされるわけではありません。一般的にはパスワードが必要だからです。しかしながら、他のサイトとパスワードを同一（パスワードの使いまわし）をされていれば、もし他のサイトからパスワードが漏洩してしまうとログインできてしまいます。ですので別途ログインについては、下記のようなセキュリティ対策を施しておくのがよいです。
  • IPアドレス制限
  • 認証にクラウドサービス（Google認証等）をつかう
  • 総当り攻撃（ブルートフォース攻撃）への対策（一度に大量アクセスを防止）
などです。そうすれば、たとえユーザー名が漏洩したとしても問題はなくなります。

とはいえ、WordPress にどのユーザーがログインできているのか知られることは嫌ですよね。ですので対策したほうがよいでしょう。
ここでは

1. ウェブシステム側で止める
2. WordPress プラグインで止める（自作）

に絞って備忘録として残しておきます。

対策１. ウェブシステム側で止める


各ウェブサイトの設定において、先頭から
  • /?author=***  = 404エラーとする
  • /author/*** = トップページへリダイレクトする
これが可能なら、WordPress に到達する前に止めることができるのでウェブサイトへの負荷が減ります。
/author/** のケースは、 /hogehoge/author/** を除外するかどうかが、ややこしくなります。たとえばカテゴリー名に使った場合とかです。とはいえ、author は予約語でもあるので、まぁそこは除外するでよいでしょう。

Apache での設定方法


WordPress側では、RewriteBase が設定されているはずなので
  • RewriteRule ^\?author=(.*)? / [NC,R=404,L]
  • RewriteRule ^author/(.*)? / [R=302,L]
の2つを追加すればよいです。
管理者画面側では、?hogehoge=**&author=**
となるので、管理者画面では除外できるはずです（未検証）。
うまくいかなければ、RewriteCond ルールなどを併用すればいいでしょう。筆者は NGINX しかほぼ触っていないので、詳細は

NGINX での設定


nginx は if 文など条件を入れ子構造にできないという問題があります。
したがって細かな条件を書くのが超大変です。
ここではドメインやサブドメイン直下（http://example.com やhttp://hogehoge.example.com/） のように http://example.com/hogehoge というサブディレクトリに保存されていないと仮定すると、汎用性がある設定としては、

set $rp_flag  flag;   
set $rp_flag2 flag; 

if ($request_uri ~ "^/wp-admin/"){
        set $rp_flag false;
}
if ($request_uri ~ "^/author/"){
        set $rp_flag2 "${rp_flag2}_true";
}
if ($args ~ "author=(.*)"){
        set $rp_flag "${rp_flag}_true";
}
if ($rp_flag = flag_true){ 
        return 404;
}
if ($rp_flag2 = flag_true){
        return 302 /;
}


上記コードでは、

1. /wp-admin/ （管理画面）は対象外（リダイレクトしない）
　＊つまり公開している側のみリダイレクトする
2. /author/ か GETパラメーターに author= があるかのいずれか
上記をすべて満たす場合に、トップページへリダイレクトする

ということになります。
「１」が必要な理由は、管理画面の投稿や固定ページ等で各ユーザーごとに一覧を表示するのに、author パラメーターが使われているためです。それは必要だろうという判断です。

このように、フラグを文字連結させた上で、それを文字判定させる手法になります。
さらに、requiest_uri に ? があるとパラメータ扱いになって、$args に保存されるという仕様もあってなおややこしい。

参考：

対策２. WordPress プラグインで止める（自作）



ウェブサーバーのほうで止めることができない場合（設定をいじれない）もあると思います。その場合には、テーマの functions.php に書くなどの方法もありますが、サイトが大量にあるとやってられません。
公式プラグインだと WP-CLIコマンドなどで一括インストールが可能になるので、その設定をしていれば、
  • wp @all  plugin install  プラグイン名  --activate
プラグインを作成してそれを公式プラグインに登録しちゃえばよいのです。
幸い筆者は WordPress の公式プラグインをいくつかアップして、メンテナンスしているのでそのあたりのやり方は知ってます。

ただ問題はどのような手法で止めるのかがかなり悩みました。

など速度低下が著しい模様。wp_safe_redirect をつかうのも同様じゃないかなぁと思います。そこで結局は
で提示された方法を採用しました。また /author/ の場合を追加して、その場合にはトップへリダイレクトすることにしました。author=数字 は明示的に攻撃しているといってもいいですが、 /author/ はもしかして誤って入力したかもしれず、表示されないよりはリダイレクトにしたほうがいいかなぁという想いです。つまりは、
  1. 管理画面以外（公開されている部分のみ）に適用
  2. QUERY_STRING に「author」項目がある = 404エラー
  3. REQUEST_URI に /author/ があること =  トップへリダイレクト
  4. redirect_canonical にも対応し、自動補正時にもチェックが走るようにする
という感じです。

2020年3月11日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2020年1月27日月曜日

コマンドツールで MAMP を SSL 対応しよう！ - macOS Catalina (10.15) 編 -（macOS Sequoia 15.5で動作確認済）

基本的なところは
の通りです。Safari、Chromeでは確認済み。Firefoxは警告（警告: 潜在的なセキュリティリスクあり）がでますが、これは前から。まぁ自前でオレオレ証明書を作って、自分で承認する確信犯（テスト環境のため）ですから、それを検知してくれるのはいいんですけど、アクセスはできることと、SafariとChromeでは警告はでないので、Firefoxの警告を消す努力はもういいやって感じです。

さて、これまではうまくいっていたのにだめになった理由は次の通りでした。
にあるように、2019年1月1日以降の証明書については、２つのルールが追加されており、これに対応する必要があったのでした。
  1. ExtendedKeyUsage (EKU) extension にて serverAuth に対応すること
  2. サーバー証明書の有効期限は、825日以下にすること
です。これを探すまで超苦労したのでメモしておきます。なおそれ以外としては
  • 証明書は、RSA 2048bit 以上、TLS であること
  • SHA-2（SHA-256）を使うこと（SHA-1は駄目よ）
  • Subject Alternative name extension を設定すること
は従来どおりになります。
MAMP 7.2 においては、httpd.conf にある、socache_shmcb_module モジュールを読み込ませる必要がありました。以下、M4 Pro MacBookPro 14inch （macOS Sequioa 15.5９で動くことを確認しました。

mamp-enable-ssl.csh (GitHUB）

において、configファイルで
  1. ExtendedKeyUsage (EKU) extension にて serverAuth に対応すること
  2. サーバー証明書の有効期限は、825日以下にすること
  3. 証明書は、RSA 2048bit 以上、TLS であること
  4. SHA-2（SHA-256）を使うこと（SHA-1は駄目よ）
  5. Subject Alternative name extension を設定すること
に対応しています。

  1. [user_cert] と [v3_req]において、下記を追加
    　extendedKeyUsage = serverAuth
  2. [CA_default]において、有効期限を 700日の設定を追加
    　default_days = 700
  3. [req] において、
    　default_bits = 2048
  4. [CA_default]において、SHA-2 (256)の設定を追加
    default_md = 256
  5. [usr_cert] と [v3_req] において、subjectAltName = @alt_names を追加
    [alt_names] において
    DNS.1 = localhost
    を追加。
DNS.1 = localhost というのは、実際にサイトでつかうDNS名
[alt_names]
DNS.1 = localhost
DNS.2 = *.test

など複数の指定が可能になる。
逆にここでちゃんといれておかないと駄目ってことになります。

上記対応を１つでもしていないと、もれなくChrome君が



といってきます。すべて対応すれば表示されなくなり



のように安全だといってくれますね！
macOS 10.15 になって一番苦労したのはこれかもしれない...

参考



2020年1月27日 @kimipooh




投稿者 時刻: 0 件のコメント:
ラベル: ,

2017年11月16日木曜日

LogBook プラグインを使って WordPress の重要操作ログを手軽に取ってみよう

LogBook プラグインは、WordPressの操作をログとして保存するプラグイン LogBook をリリースしました（TaroSky）で紹介されている通り、ログ関連のプラグインです。

開発した宮内氏は、筆者も WordPress 管理運用をする上で欠かすことのできないコマンドラインツール WP-CLI チームの日本唯一のコミッターです。WP-CLIのコミッターになってからの４週間でやったことと感じたこと（Capital P）での宮内氏の発言をみるだけでも、ものすごく沢山のコミットを積極的にされているのが伺えます（というか GitHUBみたら、最近の1年間は少なくても毎日なにかの更新されてます @@!）。

また見逃していましたが、「WP-CLIをつかってWordPressのDBをコマンド1回で別のサーバーに引っ越す」ってのは、すごすぎですよね！

また WP-CLI で引っかかるメモリ問題に関してもしっかり記事「WP-CLI でメモリ不足のエラーが出る時の対処法（Quiita）」をかいていて、これも活用させてもらってます。

さらには、最近 Google Analytics を埋め込むプラグインが Jetpack と相性が悪いのが動作しなくなったサイトがあったときに、宮内氏が開発されている WP Total Hacks にもお世話になってます。

その宮内氏が、サイトの重要なイベントに対して負荷をあまりかけずにログを記録するというプラグインを開発したとなれば、これはもう使ってみなくちゃいけません！

WP-CLI からプラグインのアップデートしたら





フムフム、サーバー上（127.0.0.1）から、WP-CLI にてプラグインを２度アップデートしたと記録に入っていますネ！その通り！

管理画面からプラグインを停止・有効化してみたら




ホウホウ、筆者端末のIPアドレスから、ユーザー kitani （筆者）で Antivirus プラグインを停止したと。

あれ、「なし」が入っているのはバグかな (^^;　って思ったら、こちらの特定１サイトのみの現象でした。これはこのプラグインではなく別の何かに原因がありそうですね。

WP-CLI から バックアップ > プラグイン更新 > コア更新 > 翻訳更新 > プラグイン更新 をしてみたら




むむ、コア更新 > 翻訳更新しか記録されていませんね。
なぜかを検証してみましょう。

まずバックアップから翻訳更新までは、ちょっと特殊な更新方法をしています。
（wp は /usr/local/bin/wp）

  1. wp backwpup --jobid=ID番号
  2. wp plugin list | cut -d '|' -f 2 | awk '{print "/usr/local/bin/wp plugin update "$1}' | sh
     ※アクティブプラグインだけ更新
  3. wp core update 
  4. wp core update-db
  5. wp core language update
  6. wp plugin list | cut -d '|' -f 2 | awk '{print "/usr/local/bin/wp plugin update "$1}' | sh 

という流れになっていて、赤文字のところだけが記録されています。

これを次のコマンドに変更して実行してみました。
  1. wp backwpup --jobid=ID番号
  2. wp plugin --all 
     ※アクティブプラグインだけ更新
  3. wp core update 
  4. wp core update-db
  5. wp core language update
  6. wp plugin --all 
するとプラグインも認識しました。
6番目は更新プラグインがないのでログには記録されていません。
※２度目のプラグイン更新の意味は、時々 WordPress の新バージョンのみ更新可能なプラグイン（プラグイン新バージョンが新しい WordPress を求めている場合）があり、新バージョンにしてから更新リストに出てくる時があるため。



個別のプラグイン更新（wp plugin update ◯◯）はちゃんと登録できているので書き方なんですかねぇ。まぁもうcut を使ってアクティブプラグインだけ更新するのはやめたのでいいんですけどね。
※なお cut などを間に挟むようなことをしていたのは、特定プラグインを除くなどの目的だったのだが、wp plugin update --all --exclude=logbook などで logbook 以外のプラグインすべてをアップデートとかできちゃうので、もう不要なのですよね。

２，３のサイトで数日テストして問題ないようなら、
【備忘録】WP-CLI エイリアスを利用したリモートサーバーの WordPress 管理 #wckyoto2017
を参考に、
wp @all plugin install logbook
wp @all plugin activate logbook
で手持ち端末から WordPress やサーバーにログインせずに、一括インストールと有効化するかなー

ってことで終わりにしようと思いましたが、このプラグイン、日本語化されていないのですよねぇ。個人的には翻訳不要なのですが、翻訳する分量が 70ぐらいなので翻訳してみるかぁと思ってやってみました。

LogBook プラグインの翻訳




最近の WordPress プラグイン翻訳は、https://translate.wordpress.org より手軽にすることができます。自分のプラグインならどのような場面でその言葉を使っているかわかっていますが、他人が開発したプラグインは、その利用場面によって翻訳内容が変わるときがあります。
また翻訳するにあたっては、


を参考に、長音文字、受動態はできるだけ能動態へ変換する、半角文字と全角文字の間には、半角文字1字分のスペースを入れる、などのよくあるものに特に注意を払いながら訳していくことになります。
翻訳（実際には提案）が完了したら、日本語版 WordPress Slack の #requests チャネルで翻訳の承認を依頼します。そうすれば、翻訳の達人の皆さんがチェックをしてくださることでしょう、きっと。最終的には、承認権限をもっている方によって承認されれば、めでたくみんなが使えるようになるってことです。

各プラグインの翻訳トップページに移動するには、各プラグインのダウンロードページにアクセスし、下記のように出てくれば、まだ日本語翻訳されていないことになります。


下図のように表示されれば、少なくても一度は翻訳済みになります。
ただし、プラグインが更新されていくなかで、翻訳が不十分になっているケースもあります。「Help translate it!」あるいは「翻訳の改善のご協力ください」のいずれかのリンクをクリックすることでそのプラグインの翻訳トップに移動します。


LogBook は翻訳して承認待ちなので、Waiting に入っています。



すでに 100%翻訳されていて、承認済みの場合には下記のように 100% の表示になります。



確か 95% を超えて、これが承認されればプラグイン本体に翻訳が反映されるようですね！


2017年11月16日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2017年7月4日火曜日

【注意】WordPress プラグイン「Responsive Lightbox by dFactory」にXSS脆弱性あり（要更新）

JVN#39819446
WordPress 用プラグイン Responsive Lightbox におけるクロスサイトスクリプティングの脆弱性 が出てるよ〜うち入れてたっけ？

という同僚の声が聞こえてきたので、早速先日導入した WP-CLIのエイリアス機能を使って調べてみました。
手持ちのMacマシンから、

  1. ターミナル起動
  2. script check-plugins-wps.txt
  3. wp @all plugin list
  4. exit

で、check-plugins-wps.txt をテキストエディタで開き、lightboxは使われていないことを確認。

  • wp @all plugin list |grep lightbox 

だけでもいけるが、じっくり見たほうが良さげかなぁと思って一度ファイルへプラグインリストを書き出してみた。

プラグインアップデートは、

wp @all  plugin update responsive-lightbox 

をすれば一発でできちゃいますね！
このアップデート状況を保存しておきたければ、 script を使って

script update-responsive-lightbox.txt
wp @all  plugin update responsive-lightbox 
exit

ってしておけば、exitするまでにターミナルに出てくる文字や入力した文字も含めて、 update-responsive-lightbox.txt に保存できるから、後から見直すのが楽です。

もし該当プラグインが入ってなければ、
Warning: The 'responsive-lightbox' plugin could not be found.
Error: No plugins updated.
が出るので一括でやってしまっても問題なし。

便利なエイリアスについては


に纏めてます。

2017年7月4日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2017年3月7日火曜日

【備忘録】WordPress 4.7.3 で修正されたメディアアップロードの中身

【備忘録】WordPress 4.7.1 よりメディアアップロード時のMIMEチェックにファイル本体のチェック機能が付与されていた・・・ で finfo_open 関数の問題でアップロードできないファイルが出てきた問題について、
にて、WordPress 4.7.3で修正されるよ〜という情報があったわけですが、実際にはどうなったのでしょうか。
をみても、原文にも書かれてません。
ならばとコードをチェックしてみました。


wp-include/functions.php
2316行〜2334行 ( wp_check_filetype_and_ext 関数内）

の部分ですね。
そして今回変更があったのは、 2322〜2333行でした。

変更前


If ($real_mime !== $type) {
  $type = ext = false;
}

finfo_open でアップロードされたファイルのコンテンツをチェックした上でのMIMEタイプ（$real_mime）と、アップロードされたファイルの拡張子に割り当てられたMIMEタイプ（$type）とが一致しなければ、セキュリティを理由のブロックしていました。


変更後


if ( $real_mime && ( $real_mime !== $type ) && ( 0 === strpos( $real_mime, 'application' ) ) ) {
    $allowed = get_allowed_mime_types();
    if ( ! in_array( $real_mime, $allowed ) ) {
            $type = $ext = false;
    }
}

  1. finfo_open でアップロードされたファイルの中身をチェックし、MIMEタイプデータ（$real_mime）がある。
  2. 「１」のMIMEタイプ（$real_mime）とアップロードされたファイルの拡張子に割り当てられたMIMEタイプ（$type）と一致しない
  3. 「１」のMIMEタイプ（$real_mime）データが「application」から始まる場合
  4. 「１」のMIMEタイプ（$real_mime）が、WordPress のMIMEタイプ（$allowed）に登録されていない

この４つの条件を「すべて」満たす場合のみ、セキュリティを理由にブロックする。

と変更されていますね。
つまり変更後は、このMIMEチェックがかなり限定されてますね。
  • アップロードしたファイルの中身と拡張子が一致しない場合、中身チェックのMIMEが application の時のみ、WordPressに登録されたMIMEかどうかチェックする

具体例


テキストデータ（sample.txt）の拡張子だけ pdfに変更（sample.pdf）し、これをアップロードしてみました。

  • finfo_open でのMIMEタイプは「text/plain」($real_mime）
  • アップロードファイルの拡張子に割り当てられたMIMEタイプは「application/pdf」（$type）

となります。このケースでは、変更後にはアップロードできちゃいます。
なぜなら、「３」の条件に当てはまらないから（finfo_open でチェックしたMIMEタイプ が application で始まってないから）。

もちろん、今回紹介したチェックは finfo_open を使ったチャックの部分であり、それ以前に、WordPressに登録されたMIMEの拡張子以外はアップロードできないようチェックがあります。
なので、sample.jpeg2002 とか適当な拡張子にしてもアップロードはできませぬ。
まぁただ、 sample.png を sample.txt にしてもアップロードできちゃいますけどね、、、このあたりは WordPress 4.7.1以前に戻ったよ〜って感じでしょうね。

2017年3月7日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年2月10日水曜日

パスワード保護されたWordPressを WordPress.com で管理するためには

所有のWordPressを JetPackプラグインを介在し、WordPress.comでサイトの一元管理ができることは知っている方も多いと思います。これは2014年12月に実装されて随分経っているので今更なのですが、ようやく重い腰をあげて対応してみました。

まぁ通常だとそんなに躓かないのですが、BASIC認証などによってパスワード保護されたWordPressについてはちょろっとしたコツがいるので合わせて備忘録としてメモしておきます。

XMLRPC対策をしている場合


現在WordPressで標準搭載されているxmlrpc機能（/xmlrpc.php）は、WordPressから直接ログインせずにWordPressを管理できる機能を有しています。たとえば Microsoft WordからWordPressの記事を更新できますし、それ以外の対応ソフトからもxmlrpc.phpを介在してコンテンツを閲覧したりテーマ変更したりなどが可能です。

しかしながら、ここへの総当たり攻撃をされるとサイト全体がとても重くなったり、xmlrpc.php 自体に脆弱性があった場合には不正アクセスされる恐れもあります。

従って外部からのアクセスを遮断しているケースも多いかと思います。

そういう場合には、サーバーの設定で（.htaccess等）

<Files ~ "xmlrpc.php$">
  allow from 192.0.64.0/18
  deny from all
</Files>

をしているケースも多いと思います。
192.0.64.0/18 は、Automattic社が管理するIPアドレス全体。

xmlrpc.php は基本拒否するけれども、JetPackと連携するために WordPress.comからのアクセスのみは許可したいということです。どの範囲か分からないので、JetPackやWordPress.com提供元のAutomattic社のIPアドレスまるごと許可しているというわけです。

しかーし、サイト丸ごとパスワードロックしている場合にはダメで・・・

通常はそれでいけるのですが、このケースが厄介です。
サイトを見られたくないけど、xmlrpc.php のみ アクセスして欲しいという要望はあるわけです。そういう場合には、Satisfy設定を使いましょう。

<Files ~ "xmlrpc.php$">
  allow from 192.0.64.0/18
  deny from all
  Satisfy Any
</Files>

とまぁ一行追加するだけです。
これで、BASIC等認証をかけていた場合、OR判定になります。

つまりBASIC認証をかけていたとしても、xmlrpc.phpへのアクセスだけ、 192.0.64.0/18 からはBASIC認証を迂回して普通にアクセスできるようになります。

間違っても、サイト丸ごとのBASIC認証に対して、 192.0.64.0/18をSatisfy Anyに設定することはしないようにしましょう。それやっちゃうと、Automattic社のネットワークからローカルなサイトが丸ごと閲覧されちゃいますよ〜。

付録：あれ？JetPackプラグインいれたら画像が表示されなくなったけど？

とりあえず、JetPack設定より、Photonを無効にしてみてください。

を見ると、キャッシュが適応されるまで時間がかかるからってことですね。
しかしならばデフォルトでONにしている以上、そのことの注意喚起がないと困りますねぇ。またサイト丸ごとパスワードロックしているサイトで、有効にして2日経っても画像が表示されませんでした。もしかしたらサイトまるごとパスワードロックしている場合には、キャッシュできないのかもしれませんね。

2016年2月10日 @kimipooh
2016年2月12日 付録を追加

投稿者 時刻: 0 件のコメント:
ラベル: ,

2014年12月9日火曜日

【備忘録】コメントスパムの撃退方法（wp-comments-post.phpへのアクセス制限編）

コメントスパムが数百を超えたあたりから対応が面倒になって、Akismetを入れたりしてしのいでいたけれど、さらに面倒になったので直接的な手段にでることにしました。

  • Step 1. コメント許可を外す
  • Step 2. 「comments_template();」をコメント（無効）
  • Step 3. wp-comments-post.phpへのアクセス制限

Step 1. コメント許可を外す

コメントの許可を外す程度では、非表示になっているだけで実際にはタグとして存在するようです。まぁそうか。

続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)