本家のお世話-#77。(WordPress3.6.1へアップデート)

 2・3日前に, WordPress 3.6.1 メンテナンスとセキュリティのリリースが来てたんでアップデートをやったんだが,ついでに, xrea の s370 と @pages の www39 でもアップデートしたら, @pages の www39 のほうで少し様子が変わっていた。

 しょっぱな,アクセスしたら,「データベース接続確立エラー」が表示されて,えっ。
 考えてみたら,この間うちから,【@PAGES】【お詫び】ユーザ情報流失に関するお知らせ 2013.08.28【@PAGES】【お詫び】ユーザ情報流出に関するお知らせ【第2報】2013.08.29 ナンチャラがあったときに,「データベースのパスワードも変えておいたほうがいいですよ」と言われて,パスワード変更したのに, wp-config.php の中の記述を変えてなかったんだった。テヘヘッ。
 それを直したら,当然ながらあっさり,O.K.

 ダッシュボードに入ったら,上部に「WordPress の自動更新に失敗しました。再度、更新を行ってみてください。」メッセージが出ていて,「なんだろう」と思ったが,まずは溜まっていたプラグインの更新を先に行った。いつも失敗する Jetpack の更新もスンナリ。ホーッと,思ったので, WordPress3.6.1 の自動更新をやってみたら,データベースアクセスのための設定がいらなくなっていた。しかも,あっさり,更新完了。

 ここにいたって,「なるほどな」と思った。  @pages の www39 においては,今後, WordPress 本体の更新はサーバ側がやってくれるということなんだろう。今回は,「データベース接続確立エラー」が出るような状態だったので,「WordPress の自動更新に失敗しました。再度、更新を行ってみてください。」が出たわけだ。この推測,間違っていないよね。

 ロリさんのことなんかも関係あるんだろうか。それとも,以前から計画済みだったのか。セキュリティ面からいうといい話だが,ブログが動かなくなっちゃったりするユーザがいたりして,サポートが大変だろうな。でもまぁ,その辺をきっちりやっていくのは,今後の生き残りのためには,大事なことなんだろう。一ユーザとして,陰ながら,ご健闘をお祈りいたします。

起きてびっくり,サイト改竄? at よそ様。

投稿アップデート情報  追記

 昨朝,起きて WordPress の日本語ブログのダッシュボードに入って,びっくり。フォーラムのところに,なんと,「サイト改ざん?」の文字が乱舞している。

 いや,うちではないです。よそ様です。フォーラムに初投稿がされたのは一昨日のようだが,一昨日は,芋虫くんにかまけていて,気づかなかった。まぁ,昼からは,いろいろリアルも忙しかったし。

 昨日も昨日で,朝あらかた読んで,ひとまずうちには影響がなさそうなので,予定通りでかけてしまった。(汗)

 しかしねぇ,テストサイトに使っている atpages から,一昨日こういう連絡が来たばかりだったし,
 【@PAGES】【お詫び】ユーザ情報流失に関するお知らせ 2013.08.28
さらに昨日はこれが来たので,
 【@PAGES】【お詫び】ユーザ情報流出に関するお知らせ【第2報】2013.08.29
いずこも同じようなことがあるのかなと思ったわけだ。上記の事件と同じようなといわれたら, atpages は心外かもしれないが……幸いにして,狙われなかっただけ,という気もする。
 今のところ,「ロリポップサーバーでサイト改ざんハッキング被害に遭った方への情報」から跳べる「ロリポップサイト改ざん関連情報 (2013年8月)」を読んでも,はっきりとした原因はわからないわけだが,いろんなことで似たり寄ったりかなと思う。(爆)

 「Hacked by Krad Xin」でググると,表題にこの文字列が入ったものすごい数のサイトが現れる。上記の事件の発端が一昨日だから,事件関連の記事も多いわけだが,それを除いても(年月日設定を去年1年とかしても,ということ),すごい数だ。これって,要するにスクリプトを仕組まれているんじゃないのか?

 フォーラムの話の中に,
> 一般設定のサイトタイトルがHacked by Krad Xinとなっていたのを元のサイト名に戻しました
てのがあるからねぇ。

 今回のクラックはある意味,性がいいかも知れないとか思った。だってね,一番初めに投稿した方が書いているように,クラックされたサイトで文字化けがあったわけだ。そうすると,変だなぁって,気づくよね。「深く静かに潜航」するほうが,たちが悪い。ダメージが一緒なら,早く気づけるほうが手当ても早いわけだから,不幸中の幸いだよ。「Hacked by Krad Xin」でググったときに出てくるサイトのほとんどは,気づいてないのではなかろうか。

 まぁ,「ロリポップ」では,昨年から, WAF が標準装備って謳っていたみたいだけど,あんまり役立てられていなかったようだね。徳丸さんが,「ロリポップ上のWordPressをWAFで防御する方法 」を書いているので(去年の記事を,昨日の時点でタイトル変更,追記までしている),「ロリポップ」を使っている人は,今回の手当が済んだ後は,よく読んで取り組んだほうがいいと思う。

 レンタルサーバだと,導入されていない WAF は使いようがないだろうけど, WordPress 使いとして,せめて出来ることはやっておこう。前にも書いたけど,こんなとこが参考になると思う。

  1. WordPress のセキュリティ、こんな記事は要注意
  2. WordPress使いならこれだけはやっておきたい本当のセキュリティ対策10項目
  3. Re: WordPress使いならこれだけはやっておきたい本当のセキュリティ対策10項目

 セキュリティ関係はナマモノとはいうものの,上げられてる10個のうちの半分は, WordPress に限る話ではない。 up-to-date とか,パスワード強度とか,ユーザの啓蒙とか。最後のものなんて管理者だったら,一番苦労するとこ。

 しかし,管理者になっている方は,レベルの違いはあれ,日々勉強と縁が切れないってことだ。お互いに,ガンバ!!

追記:
 読み直してみて, wp-config.php や .htaccess のパーミッションの話を全く書いていないのに気付いた。今どき,あの環境で 404 , 604 は当たり前だろうとか思っていたせいで,書き忘れたのかな。結局, wp-config.php については, 400 ってことになったようだ。
 LINUX に詳しくないので,この辺がよくわからないのだが,レンタルサーバで public_html 下のファイルのオーナーと サーバソフトウェアのオーナーが違う場合, 400 にしちまうと, wp-config.php をビジターが使えなくてエラーになりそうな気がするが,その辺,ロリはどうなってんのだろ。
 詳しい方がいらっしゃったら,よろしく。

 ところで,先日
Windows ファイアーウォールからのアラートを受容すると自動的にルールが構築される。しかし,これが甘々なのである。 今回の場合でも,デフォルトだと,すべての IP アドレス&ポート(それも, TCP だけでなく UDP まで)についてオープンしている状態になる。これじゃあんまりなので,”セキュリティが強化された Windows ファイアウォール” の機能を使って,もう少しきっちりと制限しておくべきだと思うのであった。
と書いた件だが,ほかのパーソナルファイアーウォールを入れずに,”セキュリティが強化された Windows ファイアウォール”を使い続けている。この件で少し詳しい記事を書きたいと思っているが,今のところ,思っているだけ。
 一言愚痴っておくと,「スコープ」の細かい設定がしにくい。どなたか,その部分にデータをインポートするいい方法をご存じないですか。

覚え書-#13。

 忘れないように。

  1. Apache について
     httpd.conf に “ServerTokens” を入れるのを忘れてたので, “ServerTokens Prod” を追加。
  2. FireFox について
    “network.prefetch-next” という機能があるのだが,これのデフォが true 。なんか悪いものに感染したサイトを前もって,読み込まれるといやなので, false に変更。

    “plugins.click_to_play” についても, true に変更。

    まぁ,どっちも過剰防衛って気もするが,どちらについても, “about:config” から変更できる。 ha-ha。

  3. WordPress について
    WordPress 3.5.2 が出た。セキュリティリリースということらしい。 wordpress-3.5.2-ja.zip を落としてアップデート。前にも書いたが,アップデートページに日本語バージョンが表示されないので,自動でできない。多分,マルチサイトのデフォルト言語が英語になっているせいだと思う。とにかく,いつも手動アップデートになる。

    何事もなかったが, swfupload-all.js がなくなっているのに,気づいた。

    xrea の s370 と @pages の www39 でもアップデートしておいた。こちらも特に問題なし。ただし,いつものことながら, @pages の www39 では相変わらず,自動アップデートはできなかった。

    ついでに, phpMyAdmin も phpMyAdmin4.0.4 にした。

本家のお世話-#58。(WordPress3.5.1へアップデート)

 昨日の午後もだったが,今朝もちらちら雪が降っている。積もるほどではないが,寒い。

 今日,日本語版のWordPress 3.5.1 が出た。メンテナンス & セキュリティリリースということなので,早速,アップデート。何はともあれ,先に,データベースとファイルをバックアップ。このことを書くのを忘れることがあるが,前に,痛い目に合ったので,実際の作業としては,これを飛ばすことはない。皆さんも,転ばぬ先の杖として,お忘れなく。

 いつもながら,マルチサイトの親を英語設定にしているせいで,WordPress Updates に wordpress-xxx-ja.zip が現れないので,別途ダウンロードしてアップデートする。マイナーアップデートということで,ファイル数の増減などはないようだ。

【書き忘れ】 
 ついでに, xrea の s370 と @pages の www39 についても, WordPress3.5.1へアップデートした。動きは問題ないようだ。

 xrea は大丈夫だが,相変わらず, @pages はうまく自動アップデートできない。前にも書いたが,「覚え書-#8。」のことを済ませておくと,大体のプラグインなどは自動アップデートできるようになるが,WordPress本体はうまくいかない。この間,Jetpackのアップデートもうまくいかなかったことで,アップロードサイズの制限に引っかかるのではないかという疑念が,確信に変わりつつある。

WordPress3.5へアップデート(xrea,atpages)

投稿アップデート情報  追記(12/23)

 WordPress3.5 についてのアップデートを, xrea の s370 と @pages の www39 でやってみた。

 前にも書いたが, @pages の www39 での自動アップデートはうまくいかない。やはり,phpスクリプトでのアップロード制限に引っかかっているようだ。いくらになっているか不明だが,今回, Jetpack Ver.2.0.4(5.5MB程度)もうまくいかなかったので,Maxが5MBあたりではないかと思う。

 @pages のフリースペースの場合は,FTPでも一度にアップできるのは,10MB程度。どっちでやるにしても,アップデートが面倒なので,もう少し,上限を緩めてほしいなあ。まあ,うちの場合はメインで使っているわけではないから,それほど切実ではないが(爆)。

 @pages でのテーマを Twenty Twelve にしてみた。カスタマイズが楽になっているが,デフォは味もそっけもない。Twenty xxxxx 系列は「そのままで使えるというテーマ」のつもりだったが,ここまでデフォが味もそっけもないと,WordPress完全初心者が使うについてはどうなんだろう。確かに,ものすごくカスタマイズはしやすくなっているみたいではあるが……

 xrea の方は問題なく自動更新されたが,今回も WordPress のトップディレクトリの wp-app.php が消え残った。子ディレクトリにおいては,変更のあったファイルについて,自動で削除もやってくれるんだが,トップディレクトリのものはこの間も残った。トップにはいろんなものがある可能性があるということで用心なんだろうか。しかし,wp-という接頭詞は,そういうときの識別のためのものだと思うんだが。

 更新後の動作については,どちらの場合も問題なく動いているようだ。どっちも,あまり利用していないので,さしたるプラグインは使っていない。

追記(12/23):
 Twenty Twelve について上のようなことを書いたが,Twenty Twelve の基本的な考え方は,以下の通りらしい。よく調べないでうかつなことを書いてはいけないという見本のようなものだな(汗)。

 「3.5 には、新しいデフォルトテーマ Twenty Twelve(http://wordpress.org/extend/themes/twentytwelve) が含まれています。このテーマは、何も追加の作業をしなくてもモバイルデバイスで美しく表示されるレスポンシブなテーマです。Twenty Twelve は、WordPress のデフォルトテーマとしては初の、ブログだけではなく一般的なサイトでも使えるデザインとなっています。」  引用元は,ここ

本家のお世話-#49。(WordPress3.4.2へアップデート)

 いつもに比べてアナウンスが遅いなあと思っていたWordPress 3.4.2の日本語版が,本日リリースされた。メンテナンスとセキュリティの関係ということ早速アップデート。

 本家はマルチサイトなので,アップデートすると上部に,
 「更新していただきありがとうございます ! ネットワークの更新ページへ移動して、すべてのサイトをアップグレードしてください。」
が表示される。リンクをクリックして,
  Update Network
に行き,
 「You can update all the sites on your network through this page. It works by calling the update script of each site automatically. Hit the link below to update.」
の左下にあるボタンをポチッと。

 ついでに,XREAと@pagesも3.4.2にした。XREAは自動でできたが,@pagesは無理。これはやはりアップロードファイルのサイズ制限のせいだと思う。

 更新後の動作については,3つとも,特に問題無し。

WordPress3.4.1へアップデート(xrea,atpages)

 xreaのs370と@pagesのwww39で表題のアップデートをやってみた。

 プラグインについては,どちらもtmpフォルダを作ってパーミッションを707にしておくとか,wp-config.phpにそのことを書き込んでおくとかの手当てで,うまくいくことは確認済みだったので,あっさり行くだろうと思ったら,@pagesのwww39の方でずっこけた。どうしてもうまくいかない。xreaのs370と@pagesのwww39のどっちにおいても,WP Multibyte Patchをアップデートしなければいけなかったので,こっちを先にやったのだが,それについてはうまくいった。

 本体のアップデート時の@pagesのエラーメッセージでは,.tmpのupgradeフォルダへの書き込みで失敗しているようだったので,これのパーミッションを変えてみたがダメ。

 やってるうちに,@pagesの方は,FTPでのファイルのやり取りもできない状態になってきた。考えるに,FTPでのこの一時に扱えるファイルの大きさ制限が足を引っ張っているのではないかいな。でないと,プラグインのアップデートとの違いが理解できないヨ。wordpress-3.4.1-ja.zipはそれだけで5MBを超えてるから,展開されるともっと大きいんだろう。仕方ないなということで,時間をおいてから手動でアップデートした。

 xreaの方は問題なく自動更新されたが,WordPressのトップディレクトリのwp-pass.phpとwp-register.phpについては自動では削除してくれなかったので,あとでFTPから手動で削除した。

 更新後の動作については,どちらの場合も問題なく動いているようだ。

@pagesのサーバー,復旧。

投稿アップデート情報  追記(5/1)

 なんかね,「Broken Link Checker」が,4/27 @23:15 付けで
     http://atpages.jp/admin/login.php について,「サーバーが見つかりません」
を出してててさ,juneさんとこのサブブログも,SoRAさんところもつながらなくて,ググッたら, @PAGES お問い合わせフォーム というのがあった。

 さらに,今日にいたり,「【重要】【@PAGES】接続障害に関するお詫びとご対応状況のお知らせ」というメールが来た。@15:19になっている。上記の@PAGES お問い合わせフォームにおいては,「【緊急4】(復旧)2012年04月28日 接続障害に関するお詫びとご対応状況のお知らせ(19時現在)」というのが,増えてるが,誰が何をやらかしたんだろう。詳しい経緯は,いまだに不明。

 我が家みたいな自宅サーバじゃないから,有料会員の賠償とか大変だろうなあ。ご愁傷様です。

 今は,我が家のサブや知人関係は,すでにアクセス可能。全部戻ったのかな。しかし,いまのところすごく不安定みたいだ。@21:40

追記(5/1):
 以下のようなメールが来た。
————————————————————————————————————————————–
Subject: 【@Pages】接続障害復旧のお知らせ
From: “[@PAGES]” <atpages@xxxxxxxx.com>
Date: 2012/05/01 17:49
To: o6asan@xxxxxx.com

いつも@Pagesをご利用いただきありがとうございます。
26日からatpages.jpドメインのすべてのサーバに対する接続障害が発生し、
ユーザの皆様には多大なご迷惑をおかけしましたことをお詫び申し上げます。

━━ 目 次 ━━━━━━━━━━━
1.障害と現在の対応状況について
2.atpage.jpについて
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1.障害と現在の対応状況について
ドメイン管理会社から連絡があり、ネームサーバーの登録を復活するという旨の
返信をいただきました。

弊社で確認したところ、atpages.jpドメインでの接続について
一部回復を確認しており、今後順次回復していくと予定しております。

なお、ドメイン管理会社より停止理由を頂いておりますが、継続し
協議を行い、再発防止に努める予定です。

2.atpage.jpについて
本日より、5月末までの間、atpage.jpへ接続された場合には、
atpages.jpへ転送するように設定を行います。
6月以降につきましては、転送処理は行いませんので、
atpages.jpをご利用いただきますようお願いたします。

この度はご不便をおかけし、誠に申し訳ございません。
重ねてお詫び申し上げます。

今後とも@Pagesをどうぞよろしくお願い致します。
————————————————————————————————————————————–
 しかし,何が原因だったのだろうね。サーバのソフトやハードの不具合による接続障害って言うのはよくあるけど,今回は,atpages.jpに対するネーム・サーバの割り当てが消えてる状態だったからねぇ。誰かがものすごーいドジをやらかしたとしか思えないんだが。

 今回のwho isの状態を見たときにすぐに思い出したのは,レジストラの延長を忘れて顧客のSITEが全部使えなくなったって言うどっかのホスティングサービスの話だったが,今に至るもネット上にそんな話は沸いてないから,違うんだろう。ますます謎だ。しかし,大型連休前で,サービス側もクライアント側も,担当者は焦ったろうなぁ。上にも書いたが,本当にご愁傷様です。何とかなったようで,よかったなぁ。

覚え書-#8。

 WordPress3.3.1を,XREAや@pagesにインストールしたときの注意点を,まとめておこうかなと思ったんだけど,書き始めるとめんど臭くなってきた。で,題名が覚え書になった(爆)。

 関連する記事は,このブログで検索ワードとして「tmp wordpress」や「AddHandler application/x-httpd-phpcgi .php」を使って調べたときに出てくるものになるナ。

 XREA・@pagesの共通の特徴はLAMP系であることだが,これはレンタルサーバとしてはごく普通のことだから,特記すべき点はPHPがセーフモードで動いていることだろう。PHPのセーフモードは,PHP5.3.0から非推奨になったが,XREAも@pagesもPHP5.2系を使っているようだ。憶測だが,稼働中のレンタルサーバでは,今までセーフモードを使っていたところを変更して,同等のセキュリティを実現するのは,なかなか難しいのかもしれない。

 両者のフリースペースを比べた場合,いろんなことができる自由度はXREAのほうが高いが,設定の面倒さもXREAのほうが高い気がする。また,XREAのフリースペースは,現時点では,Value-Domain関連の有料サービスを使っていないと借りられないから,無料レンタルサーバとしては一般的とはいえない。

 XREA・@pages,どちらの場合も稼働しているサーバは複数で,サーバごとに少しずつ設定が異なるので,注意が必要である。また,XREAでの設定はCORESERVERにも大体使えると思ってよい。

 PHPがセーフモードで動いているとmkdirの使用が制限されるようだから,おおもとのWordPressのスクリプト群のアップロードのときに,前もってFTPクライアントで子ディレクトリを手作業で作っておくと,幸せになれるようだ。それに,1回にアップロードできるファイルサイズの制限に引っかかる場合なんかもあるから,小分けにしてアップロードしたほうがいいようだ。「急がば回れ」だね。

 インストールがすんだら,FTPクライアントでドキュメントルートにtmpを作り,パーミッションを707にして,wp-config.phpの「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」の行より上に
 XREAの場合は,
  define( ‘WP_TEMP_DIR’ , ‘/virtual/ID/public_html/tmp/’);
 @pagesの場合は,
  define (‘WP_TEMP_DIR’, ‘/usr/local/www/htdocs/ユーザーID/public_html/tmp/’);
を追加。再度,wp-config.phpをアップロード。注意としては,wp-config.phpの編集には,BOMの管理のできるテキストエディタを使い,保存時にはBOMを付与しない形で保存するってこと。

 wp-contentの直下にuploadsを作り,パーミッションを707にする。これは,XREA・@pages,どちらも同じ。同じところに,upgradeも作っておく。upgradeのパーミッションについては,やはり,707にしておくほうがいいのかどうか。XREAでは,しなくてもO.K.のようだし,@pageでは,しておいてもエラーが出るし?????しかし,作っておかなければいけないのは,確かみたい。

 tmp,uploads,upgradeあたりの設定を済ませておかないと,「ファイルストリーミングの送り先となるディレクトリが存在しないか、書き込み不可になっています。」が出るようだ。

 あとは,XREA関連になる。XREAでPHPをモジュール版で動かすとき,制限がきついためにうまく動かないことかある。これを回避する方法として,.htaccessを使って,「(新)PHPをCGIとして動かす方法について」というのが提供されている。
 .htaccessに
   AddHandler application/x-httpd-phpcgi .php
を記入して該当のスクリプトをGCIとして動かしてやるというものなのだが,WordPressのインストールディレクトリにこれを入れて,どれもこれもCGIモードで動かすとなるとmodule版を使う意味がない。そこで,必要最低限のスクリプトを指定してやったほうがいい。
 現在のところで,私が指定しているのは以下のものだけ。.htaccessの場所はwp-adminの直下と,wp-includes/js/tinymceの直下である。

 wp-adminの直下の.htaccessの内容。
   LayoutIgnoreURI *

   <Files admin.php>
   AddHandler application/x-httpd-php5cgi .php
   </Files>
   <Files update.php>
   AddHandler application/x-httpd-php5cgi .php
   </Files>
   <Files plugins.php>
   AddHandler application/x-httpd-php5cgi .php
   </Files>
   <Files themes.php>
   AddHandler application/x-httpd-php5cgi .php
   </Files>

 AddHandler application/x-httpd-php5cgi .php は AddHandler application/x-httpd-phpcgi .php でも動くんだが,PHP5を使っている場合は,こちらを使ってくれと「PHPをCGIとして動かす方法について」に書いてあるので,指示通りにしているのだ。
 LayoutIgnoreURI * は,XREAの広告が自動挿入されるとダッシュボードのJavaScriptがまともに動いてくれないので,これを回避するために入れてある。はやわかりXREAの「自動挿入広告」のFAQのページを読んで,ダッシュボードには広告を挿入しなくても違反にはならないと判断している。当然ながら,XREA+やCORESERVERなどの有料サービスであれば,LayoutIgnoreURI * は,いらない。

 wp-includes/js/tinymceの直下の.htaccessの内容。
   <Files wp-tinymce.php>
   AddHandler application/x-httpd-php5cgi .php
   </Files>
 これは,ネットワークの作成-#3。の2.で書いた,「ビジュアルエディターが使えなかった件」の対策。こっちのほうが簡単だし,バージョンアップのときに気にしなくてよい。

 まぁ,こんなところかな。結構長くなっちゃったな。この件は,思い出したらまたここに足していこう。

 ところで,PHP5.4.0が出てますな。

覚え書-#7。

 XREAと@pagesにWordPress3.3.1のシングルサイトを構築したけど,XREAのサイトからは通知メールが来るが,@pagesのサイトから通知メールが来ない。というわけで,の「WP Mail SMTP」をインストールした。

 今度もうまく働いてくれるだろうか。一応,テストメールは無事に来た。