投稿者: o6asan

デジタル証明書と認証局。

投稿アップデート情報　　早速の追記(9/11)　　追記２(9/13)

　前記事を読み直してみて，「だから何？」と自分が思ったので，別表題にて追記。

　「デジタル証明書と認証局」の基本については，下の２記事がわかりやすく感じたので，読んでみてください。掲載されたのが相当古いけど，基本の理解にはお役立ちだと思います。

1. のほうは全ページ読むには無料会員なってログインしないといけないですが，両方合わせて読めば，ログインしなくてもなんとなく雰囲気はわかると思います。

　ということで，我々一般ユーザとしてはどうやって対処すればいいのということになるのですが，シマンテックのセキュリティ関係のブログにこの4件があがっていました。しかし，この4件は今回の事件が無くても当然やるべきことだし。

最新のルート証明書を手に入れるために，ブラウザ(IEやFirefoxなど)をアップデートする。
EV SSL証明書が導入されている場合は，ブラウザのアドレスバーが緑に変わるのでこれを確認。
公認のトラストマークを探して確認する。
安全な環境を表す“https”の’s’がついているのをページが変わるごとに確認する。

　2. と3. についてだけど，2. については，IE8から対応しているようだが，EV SSL証明書しているはずの「日本ベリサイン」でさえ，うちのはグリーンになってくれなかった。なんでか分らんけど。いつもはIE8をほとんど使わないので今日にいたるまで気づかなかったという体たらく（ハハッ）。Firefoxは，なった。右の図のアドレスバーのところを見てください。
　3. については，昨日書いたAmazonでは見つけ出せなかった。見つけ出せた方，教えてください。m(_”_)m
　昔は入り口で見たような気がするんだけど，大きいサイトだから今でもどっかにはあるんでしょうが。これだけの大会社になると企業の知名度だけで信用されるだろうから，実際の通信の安全性だけが確保されていればトラストマークの表示の有無は大勢に影響はないのでしょう。

　さっきも書きましたが，上記の4つは，1. のルート証明書で証明されている会社自体が信頼できないという今回のような事態が起こらなくてもやるべきことです。
　今回，G-Mailを利用している場合など，もしかしたらすでに情報を抜かれているのに気づいていないだけかもしれません。すでに受けた被害については自分で調べて警察に行くしかないでしょうが，今後受けないためには次のことをしましょうということらしいです。これは，TechCrunch Japanの翻訳記事からです。しかし，機械翻訳だろうか，すごい読みにくい記事。

パスワードを変える。
アカウントリカバリオプション(第２のメールアドレスや電話番号など)を確認，アップデートする。
自分のアカウントにアクセスさせているWebサイトやアプリケーションをチェックし，よく知らないものは解約する。
自分のGmail(他のメールでも同じ)の設定のうち，疑わしい転送アドレスや委任アカウントをチェックする。
Webブラウザの画面に現れる警告メッセージに注意し，それらをうかつにクリックしないこと。

　対象は，もちろん，Gmailユーザなんだけども，他のウェブメールを使っている方にも役立つ手順だと思います。

　これで，いくらか補足になって言いたかったことが皆様に伝わるでしょうか。

早速の追記
　ここ２・３日，バタバタしてTwitterに行ってなかったんですが，今(13:00)行ったら，認証が消えてました。右の画像を見てください。これは，Firefox6.0.2の場合ですが，IE8ではまだ，前のと同じ認証メッセージが出ます。ブラウザごとに対応が違うんだ。そういう話は聞いてはいましたが，初体験です。しかし，Twitterのつぶやきを書くページは，アドレスバーの左端がいつも赤丸の状態だったかどうか記憶が定かでない。見てるようで見ていないもんです。

追記２(9/13)：
　FirefoxのTwitterに緑が戻ってきました。認証局がVerisignになっています。
　Twitterの利用のときに私はいつもhttpsだけで利用しているのですが，上の青いTwitterアイコンだけの表示にちょっと違和感を感じたんです。しかし，どんな状態だったかというしっかりした記憶はなかった。でもやはり，ここはグリーンバーが正常なんですね。

タグセキュリティ

everyday life

Amazonのデジタル証明書の表示方法。

　一昨日書くつもりだった記事が，サイト移転に手間取ったせいで今日になってしまった。でも，書いておきたかった件なので，やはりアップしておこう。

　今回，DigiNotarの不正証明書発行による被害の話の関係で，仕事のときに個人情報保護のためにSSLで通信しようと私的デジタル証明書を作ったときのことを思い出した。

　私的というのは，公的機関の証明を受けていないということで，SSL通信の効果としては何も問題はない。もちろん，安全についての注意すべき点も，公的ものと同じだ。ただ，零細で斜陽の勤め先だったので，公的機関（例えば，VeriSignとか―こっちは今のところ問題は報告されていない―今回問題になったDigiNotarとか）で証明を受けるための予算を出してもらえなかった。使ってもらう相手先もだいたい決まっているので，使用開始の前にオフラインでお願いをすることにしていた。

　で，実際に相手先にお願いをする前に，同僚に使い勝手を試してもらったのだが，事前にかなり詳しく説明した（口頭でだった。これが問題だったかも。）にもかかわらず，明朝の報告で通信はできたが，私が言ったようなメッセージは出なかったといった人がひとりいた。実際に，仕事場で私が手順通りにやって見せ，警告画面ってこれのことだよと指摘すると，そういえばそんなのあったという話になった。

　私的証明書だと必ず警告が出るはずだが，それでも上記のように気づかない場合もある。しかもこんなのが出るよと口を酸っぱくして念押ししていてさえだ。無意識に，マウスで「はい」をクリックしていってしまうのだ。ブラウザによってメッセージの出方が違うのも問題だ。バージョン違いだけで様子が違うこともある。
　ましてや，WindowsUpdateなどで知らないうちにインストールされているルート証明書の場合だと，存在すら知らない人が結構多いだろう。
　今回，気をつけなさいと言われても何に気をつけるんだと困っている人も多いかもしれない。今どきだから，オンラインショッピングなどをすることは多いだろう。だから，実は，デジタル証明書のお世話になっているんだが，気づかずに使っているってことだ。

　というわけで，今日はデジタル証明書ってこんなものなんですよという話を，Amazon.co.jpを例にしようと思う。しかし，初めから問題があるんだ。さっき書いたようにブラウザごとに表示のしかたが違う。ブラウザ全種について説明するなんて不可能だから，「なんとかのツッパリ」にもならないかもしれない。まぁ，でもやらないよりはいいだろうという程度。他のブラウザの方は，頑張って自力でやってみてください。
　それから，ブラウザとしてはインターネット・エクスプローラの利用者が一番多いだろうからこれで行くが，我が家には，バージョン8しかないので，ご了承願う。

　前置きはこのくらいにして―相変わらず長いという突っ込みは無し!!―本題に入る。画像のアップの都合上横幅を狭くしているので，気をつけてほしい。

http://www.amazon.co.jp/にアクセスすると，図１のようなページが表示される。(1)のところがhttp://になっていることを覚えておいてほしい。
Amazonで買い物をするにはサインインをする必要がある。先に品物を選んで，後にサインインという人も多いだろうが，今回の場合は，すぐにサインインボタンを押してみよう。すでにAmazonのアカウントを持っている人は(2)，初めての人は(3)をクリックする。実は，どちらをクリックしても現れるページは同じである。
クリックすると，図２のように「セキュリティの警告」窓が現れる。過去のどこかの時点で，図２の赤丸の部分にチェックを入れてOKをクリックしたことがある人は，これが出ずに図３の画面になる。警告画面が出た人は，赤丸のところはチェックを入れないままにしておこう。そして，OKをクリックする。図３の画面になる。(4)のところがhttps://になり，(5)のところにカギマークが現れたことに注意。
次は，このカギマークをクリック。図４のように「Webサイトの認証」窓が現れる。ここでは，「VeriSign」という会社がwww.amazon.co.jpを認証している。(6)をクリックすると，Windows Internet Explolerのヘルプのページが現れ，ここにはサイトの信頼性を判断する方法が列記されていてとても大事なのだが，今回は信頼性のチェックではなく，証明書を表示してみるのが目的なので，(6)ではなく(7)をクリックする。
パッと新しい窓が開く。これがデジタル証明。（図５）
「全般」「詳細」「証明のパス」とタブが３つある。各タブを押して内容をみてほしい。この証明書が通信を暗号化して安全を図り，そのおおもとの認証がVeriSignのものであることがわかる。
これがあるからと言って絶対安全というわけではない。この記事の初めの方に書いたが，この種の証明書は私のような個人にも作れるのだ。ただ，その私的証明書の場合は，VeriSignのような会社の認証はついていない。親しい人とSSLを利用してより安全な通信をしたければそれでもかまわないが，Amazonのように不特定多数のお客様と取引したければ，どこか信用あるところに認証してもらう必要がある。それがこの場合，VeriSignなのだ。

　こう書けば，VeriSignと同種の会社であるDigiNotarが引き起こしたことが大変に困ったことで，しかもその規模がわからないということは，深刻な事態だということがわかる。各ブラウザのベンダーが，DigiNotarの証明書が使えないように，アップデートで素早く対応したことも納得できると思う。

追記(9/11)：　次記事に書き足りないと感じたことを書きました。

タグ TroubleShooting, Vulnerability, セキュリティ

everyday life

本家のお世話-#10。（リンク切れ）

　昨日は，ほぼ12時間のサーバダウン，失礼いたしました。
　前もってご連絡のできないドジによるダウンで，WordPressのマルチサイトがらみでは２度目。今回はたぶんデータベースの処理のミスだと思うが，まあーったく困ったもんだ。メッ。—–>> 自分

　今朝，アクセス解析を見ていて気づいたが，我が家には日本語zipファイルを落としに来る方がいらっしゃる。その大事な目玉商品のリンクを直し忘れていた。orz
　大概気をつけたけど，リンク切れチェックをしていないので，まだどこかに「切れ」が残っているかもしれない。

　それから，動画関係がうまくいっていない。自鯖に動画専用サーバを建ててやっていた分はもちろんだが，ファイル用のディレクトリ(blog-j/files)に置いてある分についてもうまくいかない。それに動画用のタグがソースから消えているんだけど，これはなんでだろう。
　この間，りりさんにつきあってもらってサブドメインタイプのWordPressネットワークのマルチサイトを試したときも動画でいろいろと起きたが，今回も手を焼きそう。

　まぁ，昨日の今頃に比べると天国だけど……。昨日は本当に「どうしよう」と思ったよ。最悪，自鯖の電源を入れるという手は残っていたが（笑）。

タグ日本語化

WordPress

本家のお世話-#9。

　ミッション完了。
　いやー，参った。思いもかけないところで，穴に落ちました。

　今朝11時ごろ，この間からやっていたXREA+上でのサイトの一本化が終わったので，さくっとドメインを書き換えて，o6asan.comのファイルの場所を，自鯖からXREA+に移そうと，DNS転送設定を変更後しばらくして，XREA+にアクセスしたら，WordPress遣いにはおなじみの「データベース接続が確立できません。」が出る。

　しばらくやっていたけど，らちが明かないので，自鯖は落としたまま，XREA+は非公開のまま，頭を冷やしに休憩に入った。

　夕食後，改めて取り掛かり先ほど完了。何とか，8日中に終わった。よかったよかった。

　何が悪かったのか，落ち着いて考えてみたんだけど，多分，XREA+のサーバ上の前のデータベース・ファイルを入れ物としてそのまま使おうとしたのがいけなかった。ドメインも変わるわけだから，データベース君にしてみれば，縁も所縁もないところからのアクセスになるわけだもんね。たぶんこれが原因だと思う。しかし，参りました。

　自鯖のリニューアルが済み次第，すぐに，ファイルの実場所は元に戻すつもりだったけど，当分このままで行こうっと。懲りた。

　ところで，日英両ブログとも見かけはほとんど変わっていない。私の苦労の跡が少しは見えるのは，/だから，見に行って労ってやってください。<<—–ヘヘヘ，強要です（爆）。

　見捨てたはずのIE6でも，そこそこレイアウトが狂わずに見えるとこまでは，こぎつけたよ。

　今日はさ，実は別記事の予定があったんだけど，何も書けなかった。明日（9日）書きます。

追記(9/12)：
　css2.1の仕様で勘違いがありました。http://o6asan.comのテーマで，外箱に影をつけるために，box-shadowを使っているのですが，これはcss3でした。したがってここだけはcss2.1の仕様に外れてます。ごめんなさい。でも，影が捨てがたいのでこのままにしておきます。

Vulnerability

マイクロソフトセキュリティアドバイザリ (2607712)更新。

投稿者作成者: o6asan
投稿日 2011年9月7日
マイクロソフトセキュリティアドバイザリ (2607712)更新。への2件のコメント

投稿アップデート情報　　追記(9/15)

　マイクロソフトセキュリティアドバイザリ (2607712)の件ですが，アドバイザリ 2607712 更新 – DigiNotar 社のデジタル証明書を削除する更新プログラムを公開というアナウンスがあったのとともに，Windows Update でパッチが配布されているようです。

　ネットにつないであって自動更新にされている方は，もうインストールされているのではないかと思いますが，コントロールパネルで更新プログラムの見える状態にして，2011/09/07の日付でKB2607712があればパッチあては完了しています。

　うちには，IE8しかないのですが，メニューバーからツール>>インターネットオプション>>コンテンツ>>証明書>>信頼された証明機関と進み，今回問題の発行先―たとえばDigiNotar Root CA―をクリックしたのち表示をクリックすると図１が現れます。「この証明書は証明機関から失効されています。」になっていれば，O.K.
　KB2607712がコントロールパネルの一覧にあるにもかかわらず証明書の失効が済んでいなければ，ここに行って手動でダウンロードして当てておいたほうがいいでしょうね。今のところ説明は英文しかありませんが，そのうち日本語版が出ると思いますし，パッチ自体はすでに日本語版が出ています。FireFoxやThunderbird・SeaMonkeyなどもアップデートが出ています。IE以外のブラウザの方も早めに対処しましょう。

　しかし，DigiNotarの不正証明書発行による被害はどんどん広がっているようで，どこで遭遇して被害にあうかわからないので，各プログラムのアップデートはしっかりやっておいたほうがいいと思いますよ。

追記(9/15)：
　昨日づけで，2607712のパッチともいうべき，2616676が出たようです。正常なアップデートが行われていれば，9月の定例更新とともに自動更新されるようですが，既知の問題の報告があります。
　Windows XP とWindows Server 2003 については，必ず先に，2607712を当てておいてくださいということらしいです。
　うーん，しかしうちに来る方のキーワードを見ていると，2607712がうまくインストールできない場合があるようなんだが，それの対処法は書いていないようだ。

タグセキュリティ

WordPress

本家のお世話-#8。

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

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

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

「ビジュアルリッチエディターを使用しない」をチェック。これは好き好き。
この時点では，ユーザー名とニックネームが同じなので，ニックネームをo6asanに変更。
ブログ上の表示名もo6asanに変更。
プロフィールの更新をクリック。

「設定」>>「ネットワーク設定」へ移動。
アップロード設定のメディアアップロードのボタンの画像・動画・音楽にチェック。
日本語デフォルトで使う場合は，ここで初期設定言語をJapaneseにする。
プラグインを削除しようとしたらエラーが出るので，/public_html/wp-admin の.htaccessに
　　　　<Files plugins.php>
　　　　AddHandler application/x-httpd-phpcgi .php
　　　　</Files>
を追加。（PHPのセーフモード対策。）
プラグインを追加しようとしたらエラーが出るので，/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については，初めは子サイトでうまく動かなかった。やっているうちに動かせる方法が分かったので，フォーラムに投稿した。同じ使い方をする場合はこちらを読んでほしい。。
ビジュアルエディターは使わない設定にしているが，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;
```
の部分をコメントアウト（あるいは削除）し，以下の２行に書き換える。
　　　　　　　　echo get_file($basepath . ‘/wp-tinymce.js’);
　　　　　　　　exit;

追記２(2012/7/16)
　上記のことについて，Xreaではwp-includes/js/tinymceの直下に，以下の内容の.htaccessを置くことで，同様の効果を得ることができる。
　　　<Files wp-tinymce.php>
　　　AddHandler application/x-httpd-php5cgi .php
　　　</Files>
　Xreaの場合は，こっちを使ったほうが簡単だし，バージョンアップのときも気にしなくてよい。
サイトを追加する。
- サイトのアドレス：BLOG1（英字は小文字のみ。うっかり，最後に / をつけないこと。これでハマった。）
- サイトのタイトル：ブログ１
- 管理者メールアドレス：hoge@example.com
この後，XREAの管理画面から，「ツール」>>「ファイル所有者の修正」をやっておく。やっておかなかったら，データのインポートでエラーが出る。まぁ，その時点でやっても問題ないけど。
どこで追加したか忘れたが，/public_html/wp-admin の.htaccessには以下の２つも追加しておく。忘れると，あとでやるインポートやテーマのインストールがうまくいかない。
　　　　<Files themes.php>
　　　　AddHandler application/x-httpd-phpcgi .php
　　　　</Files>
　　　　<Files admin.php>
　　　　AddHandler application/x-httpd-phpcgi .php
　　　　</Files>
各サイトの管理画面から「設定」に行き，一般的な設定（一般～パーマリンク設定）をする。WordPressの場合は，全体を非公開にする設定がない（？）ので，テストサイトへのアクセス制限は.htaccessで行う。
全体の比率の関係でサイト全体の言語を英語にしているので，日本語ブログの設定を忘れないように日本語に直しておく。
作成したすべてのサイトのAkismet API キーを有効にする。
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の場合，分割したそれぞれにヘッダーをつけておかないといけなかった。
忘れるところだったが，最後の２行
　　　　　</channel>
　　　　　</rss>
があると，ファイルサイズが小さくてもエラーが出る。なんでだかわからないが，分割ファイルをアップしたときに怪我の功名で気づいた。エラーメッセージは，下記のようなものだった。
　　　　　Import WordPress
　　　　　*** glibc detected *** corrupted double-linked list: 0x088210f0 ***
MovableTypeのタグ関係がうまく移せなかったので，手作業で処理した。大した量じゃなかったからいいけど，この件はもうちょっと勉強しないといけないみたい。
画像をアップしようとしたら，「ディレクトリ /virtual/o6asan/public_html/wp-content/uploads を作成できませんでした。」が出たので，FTP接続してディレクトリ uploads（パーミッションは707）を作成。
画像の表示ができない(これも前と同じ)ので，/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に制限に変更。

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

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

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

タグ .htaccess, Ajax Edit Comments, plugin, TroubleShooting, XREA

WordPress

本家のお世話-#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のマルチサイトの使いやすさが上がってくるのもそう時間はかからない気がする。いちいち動的にページを表示するのでサーバのその都度の負担は若干大きいかもしれないが，うちのサイト程度では，問題にもならないだろう。主なコンテンツは２つのブログだから使い慣れていない汎用CMSよりも使い慣れたのがいいだろうということもある。
　MovableTypeももともとオープンソースのMTOSを使っていたので，費用の点ではこちらも無料だが，Perl系のMovableTypeとPHP系のWordPressでは，素人には後者の方がアップデート管理がしやすい気がする。PHPは膏薬(？)のようにどこにでもくっつくので，そのせいだろうか。反面，セキュリティではあっちこっち危ないということがあるのだろう。

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

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

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

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

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

タグ .htaccess, CMS, plugin, TroubleShooting, XREA, セキュリティ

Vulnerability

マイクロソフトセキュリティアドバイザリ (2607712)

　マイクロソフトセキュリティアドバイザリ (2607712)の件で，ブラウザの証明機関から昨日インストールしているDigiNotarを削除したんだけど，今日ニュースを読んでいると，このことは結構問題を含んでいるようだ。

　もちろん，Google の一部サイトに対して発行された不正な SSL 証明書の問題ということで，これ自体困ったものなんだが，エフセキュアの「Diginotar」がBlack.Spookとイランのハッカーによりハッキングとか読んでると，「Diginotar」の対応にかなりの疑問を呈している。書いていることのスタンスが23日に米Comodoが同じようなことを発表したときと違っているようだ。もちろん，執筆者も違うわけだが。そのときの記事というのは，これ。これを読むと，コードサイニングの悪用というのは，とっても怖いですね。

　今回のことに対して，MSやMozillaはまたすぐに対応するだろうけど。どこか，証明書発行システムの根本的な見直しが必要なのかもしれない。まぁ，こういうことは，いたちごっこですが……

追記(9/1)：Firefox 6.0.1，出ました。

追記(9/6)：
　ここのところ，サイトのCMSをWordPressに一本化することにスタックしているのだが，この追記は書いておくべきだろう。
　「Diginotar」の件はますます痛い話になってきた。現在，ネット上での商売でデジタル証明書というは欠かすことにのできないものになっているんだから，こんなんあり得ないでしょう。こんなんとは，以下の記事のの中に書いてある「Diginotar」の対応ということだけど。
　MozillaがDigiNotarのCA認定を取り消し、政府関連証明書も失効とか，Mozillaのこの対応も無理ないと思う。
　後で気づいたが，Googleもこんなん書いてる。特に9/3のアップデートの内容に注目。

タグセキュリティ

Vulnerability

PHPやらApacheやら。

投稿アップデート情報　　追記(8/28)　追記２(8/29)　追記３(8/31)　追記４(9/16)

　Apache Killerの件のパッチはいつになったら，出るんだろう。Apache HTTPD Security ADVISORYの記事の最初の時刻は，8/24 16:16:39 GMT（日本時間8/25 00:16:39 だっけ。イギリスはまだ夏時間だよね。）になっていて，48時間でパッチを出したいと書いているのだが，8/26 10:35:31 GMT（日本時間8/26 18:35:31）の記事では，あと１日みたいなことを書いてある。もうすぐ経過するよね。今度は出るだろうか。

　こういうことって，素人に毛の生えたようなサーバ管理者（もちろん自分のこと!!　こんなところで威張ってどうするんだ―爆）には，頭痛の種。どうすればいいかよくわからん。Bug 51714からDoS Exploit for mentioned vulnerabilityを落として試してみようとしたら，バスター君の異議で落とせなかった。ブラウザで見るだけでなく，ダウンロード自体ができない。この辺を弄るのも面倒なので，やめることにした。

　Apache LoungeのWarning Security issue :: DoS attack with range requests !のSteffenの書き込みにしたがって，手当てをしておくべきだろうか。うちのような零細なところに故意に攻撃してくるとは思えないけど，「下手な鉄砲も数撃ちゃ当たる」でバカなことをやる頭の悪いハッカーがいたら，流れ弾に当たらないとも限らない。どうせ今まで，おどおどしながら手をこまねいていたんだから，パッチが出るのを待っていようかな。modsecurity_crs_20_protocol_violations.confを利用するのなら，あんまりよくわからなくても手当てだけはできそうだから，やっぱりやっておこうかな。

　しかし，この間のPHP ver.5.3.7のとんでもないバグといいい，こういうことがあるときには続くものですね。

追記(8/28)：
　結局，24時間以上たっても，正規のパッチは出ていないもよう。
　ということで昨日，やっぱりやっておいた方がいいかなと思ったことについてだけど，徳丸さんが，
　　　　　訂正:mod_securityのCore Rule Set 2.2.2に含まれるApache Killerルールは
　　　　　とても効果があるけど、Rangeヘッダのみの対応で、Request-Rangeヘッダには
　　　　　対応していないので、他の回避策をとった方が良さそうですね
とつぶやいておられたので，どうしたらいいかなと思いつつ寝た。朝，Twitterを見に行ったら，日記を書いたとつぶやいておられたので，早速見に行った。さすがに徳丸さんで，詳しい検証付きで「Apache killerは危険～Apache killerを評価する上での注意～」を書いておられた。

　徳丸さんは，Apache2.2系を使っておられるとのことなので，この記事を参考に，httpd.confを手直しした。いつも，お世話になります（拝）。あまりにも常識なので，徳丸さんが書いていないことの備忘（汗）。
　　　　　LoadModule headers_module modules/mod_headers.so　のアンコメント。
　　　　　Apacheの再起動。
と思ったら，再起動については，Twitterでつぶやいておられた（爆）。

追記２(8/29)：
　パッチはまだ出ていない。Apache Killer (CVE-2011-3192)には，「はっきりと攻撃元のログが残ってしまうので、むやみに撃つのはやめたほうがいいかなと思います。」と書いてある。（笑）

追記３(8/31)：対応のApache 2.2.20が出ました。

追記４(9/16)：
　アパッチ本家で2.2.21(released 2011-09-13)が出ました。2011-09-14 06:06リリースのCVE-2011-3192.txtがこの件のADVISORYの最終版のよう。
　Loungeでも，Apache 2.2.21 releasedということらしいです。9/8にサイトをXREA+に移したため，サーバのセキュリティアップデートが喫緊の課題でなくなったため，書き込みが遅くなってしまいました。「対岸の火事」と思うと対応がいい加減になるという典型です。お粗末。

タグ TroubleShooting, Vulnerability

WordPress

WordPress日本公式キャラクター。

　ご存知の方も多いと思いますが，WP日本公式キャラクターの名前が「ワプー（アルファベット表記：Wapuu）」に決まりました。10日に一度別名に決まったのですが，既存のものとの兼ね合いで，12日に変更されました。

　このイラストは，WordCamp Fukuoka 2011（九州産業大学で2/19に開催）でお目見えしました。デザインは，カネウチカズコさんで，GPLライセンスになっています。

　名前の募集が始まったのは，６月25日でした。私も応募はしてみました（笑）。67個の候補が集まったそうで，投票は８月２日に開始されました。その集計の結果「ワプー」は２位だったのですが，１位の名前が既存の会社の名称とかぶるためこちらになったそうです。

　前置きが長くなりました。その「ワプー」を右サイドバーの下の方に載せるようにしてみました。redcockerさんが作られたプラグインを利用させていただきました。