【WordPress】Jetpackと連携できない!All In One WP Security & Firewallの設定に問題があった件

今日、このサイトで下らない記事を書いてる時、昨日まであった筈のサイト・ロゴが消えてる事に気付いた。

jetpack-trouble

このロゴの提示は、Jetpackのお仕事の筈で、これにより、自サイトとJetpackの連携が壊れている事に気付く事になった。

当然、アクセス解析もログが取れず、そのページには、Jetpackから「あなたのサイトに確認を取りたい」のような内容が英語で書かれていた。
 

Jetpackと繋がらない

Jetpackと再連携を試みるも、全部はじかれる始末。連携ボタンを押しても、下のような警告が出て来るだけ。

Jetpacklに拒否される

Jetpackを利用するには、サイトが公開されていて、アクセス制限がかかってない必要があります。

サイトはちゃんと公開されてる。だから、サイトのどこかでアクセス制限掛かってるんだろうけど、それは「.htaccessのお仕事」に見えていて、しかし、それが途中で変わる・・・とかあるのか? チンプンカンプンw

実際、2日前までは、Jetpackのアクセス解析は動いていたし、昨日はサイトロゴも表示されていた。
 

自分のサイトの場合、XML-RPCの問題のようだが・・・

それで、Jetpackにはデバッグのページがあって「悪さ」をしてる箇所の断定をお願いしました。ここに自分のサイトのアドレスを入れると、異常があればそれを教えてくれます。

Jetpackのデバックページ(英語)
 
デバック

自分はこのページで上写真のような答えを貰った。

XML-RPCが正しく応答していないらしい。

しかし、自分はウェブ屋さんやIT関係の人では無いので、XML-RPCって何だ? とか、さっぱりわからん・・・。
それで、XML-RPCのトラブルについて、片っ端に検索を掛けてみたけど、自分の症例にあてはまるものが日本語サイトに限れば見つからなかった。
 

プラグインが悪さをしてる可能性

それで、プラグインが悪さしてる可能性がある噂を聞きつけ、自分のプラグインを片っ端からON/OFFしてそれを調べる事になった。
自分の場合、それほど面倒な作業ではなかった。何せ、まだ開設して数日のサイトだから、プラグインなんてものは、まだそれほど入ってないw

それでも、自分が使っている”さくらのサーバー”は、Wordpressをクイックインストールした時に、気を効かせてくれて幾つか有用なプラグインを付けてくれている。
その1つが、サイトのセキュリティを強化してくれる「All In One WP Security & Firewall」と言うもの。

しかし、まさか、それが原因だったとは・・・。いや、本当に。
 

実は、そこはセキュリティ側が守りたい場所

XML-RPCについて調べて行くにあたり、「XML-RPCを無効にしたい」と言う記事も多く目にした。なぜ無効にしたいのか? そこを攻撃してサイトのセキュリティを崩そうとする輩がいるからです。

いわしのブログ
WordPressのxmlrpc攻撃対策 .htaccessでアクセスを制限する

この記事を読めばよくわかると思うが、セキュリティを担うプラグインがそこを守りたくなるのは当然なわけで・・・。しかし、Jetpackはそこへの出入りを拒否されると使えなくなると言う事なのか・・・。何とも悩ましい感が・・・

しかし、ここで疑問。

自分は同じサーバー内でもう一つサイトを運営してて、そこもAll In One WP Security & Firewallを使っている。しかし、そこはJetpackとの連携に何の問題も抱えていない。

All In One WP Security & Firewallなんて高度なものは、自分ではどう設定していいのか全くわからないし、さくらのサーバーがどこを設定すべきか公式サイトで書いてくれてるので、両方のサイトともその通りにやった。

さくらのサポート情報: WordPressのセキュリティを強化する

なのに、なぜ、こっちのサイトだけおかしくなるんだよ・・・?
 

取り敢えず、All In One WP Security & Firewallを停止してみる

自分の疑問はさておき、先述の通り、All In One WP Security & Firewallのプラグインを一度停止してみたところ、

そしたら、Jetpackに簡単に連携できました。
 

しかし、小心者の自分は、さくらがわざわざ付けてくれたAll In One WP Security & Firewallを切ったままにしておくのも不安で、またそのプラグインをONにしてしまった。それから、もう一度、前述のさくらが書いてくれている通りに設定したら、何てことはない・・・。Jetpackとの連携は切れなかった。

ところが、話しはここで終わったわけではなかった・・・
 

.htaccessへの記載を求めるAll In One WP Security & Firewall

.htaccessへの記載を求めるAll In One WP Security & Firewall

All In One WP Security & Firewallを再びONした時から、管理画面の上の方でこのような文字がしつこく返事を求めて来る。(上の写真を拡大して確認して下さい)

この英文を書き出してみると・・・

Would you like All In One WP Security & Firewall to re-insert the security rules in your .htaccess file which were cleared when you deactivated the plugin?

大雑把に訳してみると、「プラグインのOFFで無効になったAll In One WP Security & Firewallのセキュリティルールをもう一度あなたの.htaccessに書き込みますか?」

ここが今日の一番の悩みどころ。

.htaccessとは、ここに「お約束」を書いておけば、外部からの不正アクセスなんかを防いでくれるもの。当然、YESと答えたくなる。

しかし、本当にYESと答えるべきなのか・・・?
 

そしたら、英語のWordpress orgでも、自分が思った事と同じような事を質問してる人がいた。

WordPress org Forums (英語)
"Would you like All In One WP Security & Firewall to re-insert the security rules"

この人は、イエスとノー、どっちを答えればいいのか?と聞いてるわけだが、その答えが英語である事を除けば実にわかりやすい。

When you enable the firewall rules (and some of the other features), the plugin will write some code in your .htaccess file.
If you deactivate the plugin from wordpress the plugin will automatically remove any of the code it added to your .htaccess file when it was active.
Then when you reactivate the plugin, it will ask you whether you want add the code back to the .htaccess file.
In 99.9% of the time you should click "yes" because that code is instrumental to the protection of your site.
The only time you would click "no" is when you are having some issues with the functionality of your site and which you suspect may be occurring due some of the .htaccess rules.

これは真面目に訳します。

「ファイアウォール(All In One WP Security & Firewall)のルールやその他の幾つかの機能を適用すると、そのプラグインはあなたの .htaccessファイルに幾つかのコードを書き込みます。その後、あなたがプラグインの使用を停止すると、アクティブにしていた時にあなたの .htaccessに加えていたコードを自動的に消去します。その為、再びその使用を開始した時、.htaccessのファイルにそのコードを戻したいかどうかあなたに尋ねる事になります。
そのコードがあなたのサイトを保護する助けになっているので、「イエス」を99%選ぶべきです。あなたのサイトが何かしらの機能的な問題を抱えたか、.htaccessのルールが原因だろうと推測されるような場合だけ、「NO」をクリックするべきです。」(訳:管理人 Makoto)

 

「No」と答えないとJetpackは使えない・・・

残念ながら、実はここで「YES」を返すと、Jetpackが使えなくなってしまう。

少なくともさくらの指示通りに設定した状態下では・・・。3回ほどしつこく検証してみた結果です。

だから、Jetpackを使い続けるには、.htaccessの追記(セキュリティの強化)を拒否する「NO」と答えなくてはいけない。

 

しかし、先ほど紹介した海外の人の回答を読んでしまうと、.htaccessにこのルールを書いておかなくて大丈夫なのか?と不安になる。

それで、自分のところの.htaccessを見て来たところ、All In One WP Security & Firewallがそこに何も書いていないわけではなかった。こういうコードはさっぱりなので、ロボット関係についての記載がある・・・程度しかわからないのが辛い・・・

Jetpackの便利機能は、アクセス解析とか言う複雑なものでなければ(これだってGoogleの方が良いんだし)、Wordpressの中級者以上なら、自分で何とかなりそうなものも多いような気がしてる。この辺をどう思うかは、それぞれのスキルと価値観によるところなんだろうけど・・・。
 

結局のところ、今日の一番の謎は・・・

未だ、腑に落ちないのは、Jetpackを開始してから2日くらいは機能していたそれが、なぜ突然All In One WP Security & Firewallによって拒否されたのか?

その間、All In One WP Security & Firewallを停止するような事はしてないし、1つ覚えてるのは、ついこの間までは、.htaccessに一行しか書いてなかったと言う事で・・・(何かの設定ミスだったのか?)

多分、All In One WP Security & Firewallは、一度ONにするとそれを気まぐれに停止する人は殆ど居ないと思うので、All In One WP Security & Firewallから.htaccessの書き加えを要求されるような事はあまり起きないのかもしれない。

海外には、このAll In One WP Security & Firewallとjetpackの関係について質問してる人がかなり居た。Jetpackもブルートフォースの攻撃に対するセキュリティをうたっていて、All In One WP Security & Firewallと同居が可能か、質問してる人も居た。

参照記事:All In One WP Security & Firewall plugin vs Jetpack Protect

これらの関係記事を片っ端に読めば、自分に起きた謎についても明らかになる場合があるのか・・・

Related Post

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

8 + twenty =

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)