自宅とは？

このサイトは非固定 IP アドレスで独自ドメイン（ miloweb.net ）を取得し、自宅のサーバより発信しています。
ご質問メールについてLinux に関するご質問をメールで頂くことが多々ありますが多忙の為お返事を書くことができません。ご質問はお気軽に BBS へご投稿頂きます様、よろしくお願いいたします。
CentOS のインストールを図解しています。インストール中にソフトウェアRAIDのレベル1（RAID1)の構築を行っています。
Linux はコマンドだけで操作する OS ではありません！Windows の様に GUI での設定が可能です！
このサイトは私の調べた Linux で自宅サーバを全て無料で構築する(ソフトウェア的に)方法や、その手順を私の自宅の構成に沿ってご紹介します。これから自宅サーバを立ち上げる方のお役に立てれば光栄です。
ここに掲載している情報は私自身が調べたものや偏見などがありますので、間違っているものや見当違いのものがあるかもしれません。
ほとんどのコンテンツはインストール／設定時に私が書いておいたメモをそのまま html 化したので、間違っているものや、バージョンが低いものがあるかもしれません。
ここで紹介しているルータやOSでないとできないというワケではありません！ここで紹介しているのはあくまで「例」です
このサイトは、管理者である kensuke が Vine Linux で自宅サーバ構築時のメモを HTML 化し、公開しているサイトです。
当サイト内のドキュメントの著作権は、管理者である kensuke に帰属しています。無断で一部または全てを転載、複製、放送、翻訳することは、著作権の侵害に相当します。
また、当サイト内のドキュメントを利用した事により発生した損害については、その規模に関わらず 私（ kensuke ） は責任を負えません。記事内容が正確なものであるよう努力はしておりますが、誤った情報が含まれていないとも限りませんので、あらかじめご了承頂けますようお願いします。記事内容の実行は、あくまで自己責任でお願いします。私（ kensuke ）の趣味で運営しているサイトだということをご理解下さい。
当サイトはリンクフリーです。相互リンクも大歓迎です！当サイトへリンクを貼っていただける方は、出来るだけトップページ（ http://www.miloweb.net/ ）にリンクを貼って頂きたいのですが、どのページでも構いません。
リンクに関する事は、当サイト内「 リンク 」で説明していますので、リンクを貼って下さる方はご一読下さい。
自宅のパソコンをWebサーバとしてWWW(World Wide Web)に公開する事を総称して「自宅サーバ」と呼びます。
プロバイダからグローバルIPアドレスが割り振られている（非固定グローバルIPアドレスでも可能です）。
自宅サーバ構築前にご使用のプロバイダに確認されることをお勧めいたします。 （2007/02/21 文面修正）
このサイトを見てくださった方に今さら「Linux は動作が軽くて、無料で・・・」なんて言ってもしょうがないですよね。
個人的にRed Hat Linux はミーハーっぽい気がする・・・Linux を知れば知るほど他のディストリビューションの魅力に気付きます
Windows2000 でサーバを構築する時にはこうは行きません。こんなヘッポコマシンでも安定して動作する所も Linux の良い所なんでしょうネ。

[ 134] Linux で自宅サーバ [ Home Server Technical. ]
[引用サイト]　 http://www.miloweb.net/

この「自宅サーバーWebRing（ウェブリング）」は、自宅サーバー（ホームサーバー）に関する情報を提供するホームページを輪（リング）のように相互リンクするものです。ホームページを訪れた方々は、このリングの中をたどっていくことにより、「自宅サーバー」という同じテーマをもったホームページを効率よく次々と訪問することが出来ます。
この「自宅サーバーWebRing（ウェブリング）」に参加している各ホームページには、下記のようなナビゲーション・バーが置いてあり、これを利用して相互リンクしています。 これから自宅サーバーを構築される方は、次項以降を読まれる必要はありません。是非、下記のナビゲーション・バーをクリックして、各参加サイトをご訪問願います。もし、自宅サーバーを構築されるOSを決められている場合は、「登録サイト一覧」や「おいでんリンク」をご覧になる方がよいかもしれません。
すでに自宅サーバー（ホームサーバー）をご構築されて構築時の要領（ノウハウ）をWebページに記載されている方は、次項以降をご一読され、是非このWebRing（ウェブリング）にご参加されます様、御願い致します。尚、この自宅サーバーWebRing（ウェブリング）は、現在、「鷹の巣」（たかのす）によって管理されています。
現在は、EasyRINGというフリーなCGI（Perl5）を改造し、プロバイダに設置して、利用しております。
このナビゲーション・バーには、「リングに参加しているホームページの一覧」、「次（前）のホームページへの移動」、
さて、自宅サーバーに関する情報を提供するホームページを運営されている皆さん！この「自宅サーバーWebRing」に参加しませんか？
皆さんが参加することで、この輪（リング）が大きくなっていきます。リングが大きくなればなるほど、このリングをたどる多くの人に皆さんのホームページを知ってもらう事ができます。（アクセス数が増えます！）もちろんご参加は、無料です。
また、参加サイトのトップページには、このWebRingの登録サイト一覧のWebページ（静的なHTMLファイルで、2003年4月13日現在、GoogleのPageRankは4）より、アンカー（ハイパーリンク）されますので、ロボット型検索エンジンで多少検索されやすくなります。
これ以外にGoogleの宝くじPageRankもランダムに贈呈（約1ヶ月間）しています。詳細は、「ページランクとGoogle toolbarについて by Eva」をご参照願います。
自分のウェブページを持っていること。ウェブページが自宅サーバー内でなくてもかまいません。プロバイダのウェブページ等でも結構です。自宅サーバーが時限サーバーである場合は、このリングが提供するプロバイダのウェブページの入口ページを利用して、バナー表示を行い、自宅サーバー開設時間帯のみ自宅サーバーに案内することも出来ます。
ナビゲーション・バーをトップページに貼ること。テキストだけなので、背景色を工夫して、目立たせること。
リングが「壊れたリング」にならない様、サイト保守等でサーバーを停止する場合は、一時的にリングから外し、オフライン状態に戻すこと。
リング運用中に自宅サーバーが安定稼動されていないとリング管理者が判断したサイトは、当サイトの用意する入口ページ（プロバイダのウェブページ）を利用して、リングに参加すること。
全ての年齢で、閲覧可能なサイト内容であること。ここで言う閲覧とは、「サイト内容や文字（漢字）を読んで理解できる」という意味では、ありません。「サイト内容を見られても悪影響を及ぼさない」という意味です。
ページ移動がテキストリンクで移動出来、スクリプト・Java・ActiceX等の実行を切っていても移動出来ること。
プライバシーは、「すべてのcookieをブロック」として、サイトを閲覧致しますので、宜しくご了承願います。
参加の条件が厳しい様ですが、リング利用者の視点に立って、取り決めておりますので、何卒、ご理解の程よろしくお願い致します。
←稼動中表示ランプ（193バイト）をダウンロードして、貴サイトのホームページのドキュメントルート下に設置して下さい。
ダウンロード先は、１キロの小箱[HP素材集]さんの「ボタン」という項目の中に「but0.gif」としてあります。
貴サイトのバナーをご準備願います。もし、バナーがなければ、AUTO LOGOさんのフリー素材を使用すれば、
これは、「リングに参加しているホームページの一覧」や後述する「入口ページ」で、貴方のサイトが稼動中であることをバナーで表示します。
稼動中表示ランプとバナーの準備が出来ましたら、リングの仮登録画面から、「自宅サーバーWebRing」へ仮登録を行って下さい。
仮登録通知メールに記載（様式例）されているナビゲーション・バーを貴方のウェブページのトップページに貼り付けて下さい。
ナビゲーション・バーを設置されましたら、この電子メールにID番号を明記の上、リング管理者（鷹の巣）へ通知して下さい。
本登録が終わりましたら、本登録通知メールが送信されますので、リング登録サイト一覧に掲載されていることをご確認して下さい。
リング管理者から本登録の通知の後に、一応、ナビゲーション・バーが正常に機能しているか確認して下さい。
また、リングに本登録した後は、リングに登録されている貴方のサイトの情報やリンク形態を編集したり削除することが出来るようになります。
貴方のサイトのURLが変更になった場合や一時停止の場合やDNSサーバーが不調の場合は、速やかにサイト情報を変更するようにして下さい。
また、貴方のサイトを一時的にリングから外し、オフライン状態にすることが出来ますので、そちらもあわせてご利用下さい。
これは、リングが「壊れたリング」にならない為、大変重要ですので、サイトを登録した際には覚えておいて下さい。
この状態は、貴方のサイトを一時的にリングから外します。自宅サーバーに障害が起きたり、保守時に選択して下さい。本登録後にナビゲーション・バーを一時的になくす場合にも選択して下さい。
DNSサーバーに障害が生じた場合、サイト情報を編集する際にhttp://100.100.***.***/とIPアドレスで指定すれば、入口ページから、自宅サーバーへのリンクが可能になります。
ご利用者の為に自宅サーバーWebRingは、リンク切れがない様、極力、努力してシステムを考えています。トップページにナビゲーション・バーを設置されていないサイトは、次のサイトに移動ができませんので、発見次第、即座に仮登録状態にさせて頂きます。ホームページの保守などで一時的にナビゲーション・バーを設置できない場合は、必ず「オフライン状態」にして、一時的に自宅サーバーWebRingのRingから抜けて下さい。
リング内に登録されている、サイトの一覧が表示されます。リングで一覧といった場合こちらを指すことが多いです。
日次・月次アクセス数および合計アクセス数と参加サイトの月間稼働率（目安）の順位とWebRingから参加サイトへの月間アクセス数を表示しています。
今後、プロバイダが変わったり、管理者が変わったりした場合は、ナビゲーション・バーのリンク先の変更をお願いする場合があります。
現在までに、数回URLを引越した悪い実績があります。URLを引越す場合は、数ヶ月程度の移行期間を設けて、サイト全体の引越し(URL転送)についての覚書に記載しています様なURL転送を実施します。
この「自宅サーバーWebRing」参加サイトは、連絡可能な電子メールアドレスが公開されます。（稼動検査連絡用電子メールアドレスは非公開）メールアドレス収集ソフトから、メールアドレスを極力収集されない様にするためにメールアドレスは、HTMLエンティティ出力形式に変更して表示されます。詳細は、メールアドレスの保護（メールアドレス収集ソフトに負担を強いる）をご一読願います。
2005年03月28日以降、参加サイトへの連絡は、CGIのフォームメール（PostMail）に変更しました。メールアドレスは、公開されません。
現在、inktomi系(MSN,Yahoo)の検索エンジンのクローラには、CGIで動的に表示されるアンカーのURLをたどれなくして、データ収集の拒否を行なっています。
これは、inktomi系(MSN,Yahoo)の検索エンジンの場合、CGIでURL転送すると転送元のCGIのURLが検索エンジンに登録されてしまい、本来のURLが検索できなくなるからです。
実際のperlスクリプトは、検索エンジンのクローラに収集されたくない場合のCGIの改造例で示しています。
参加サイトは、通常、リンク形態の状態コードを「４」以上にして、自宅WWWサーバーの稼動監視対象にして下さい。この場合、「鷹の巣」のサイトより、
OPTIONSメソッドを使用している理由は、アクセスログの廃棄を容易にするためです。OPTIONSメソッドを使用する場合、「OPTIONS *」を使用すべきですが、バーチャルホストに対応する為、HTTP/1.1でファイルへのpathを指定して、以下の様なperlスクリプトでアクセスしています。(正しくは、HEADメソッドを用いなければなりません。)
ナビゲーション・バーが、テキストだけである為、ナビゲーション・バーが目立たずわかりにくいといったご指摘をお受けした場合、
「自宅サーバーWebRing」の左に下記の様なアニメーション画像の貼り付けをお願いする場合があります。
デザイン重視のWebページの場合は、ナビゲーション・バーを設置するのが非常に難しい為、リング管理者に遠慮なくご相談して下さい。
自宅サーバーWebRingホームページと連絡用掲示板(CGI)がプロバイダのサーバーに設置可能であること。
自宅サーバーWebRingホームページから、リング管理者のトップページへのアンカー（ハイパーリンク）を設置することは、禁止致します。これは、Google等の検索エンジンのPageRank機能の外乱要素（RING主催者のPageRankを不当に上げる不正な手口）になるからです。
2005年03月28日 参加サイトの公開用メールアドレスをCGIのフォームメール（PostMail）にして、隠蔽化を実施。
2004年07月09日 メールアドレスのリンクの全部をHTMLエンティティ化するスクリプト例を追記。
2004年06月18日 その他の項に「特定の検索エンジンのクローラへの収集防止対策」と「サーバー稼動検査について」を追記。
2003年04月14日 自宅サーバーWebRing（ウェブリング）の利点にロボット型検索エンジンでの利点を追記。その他、説明を補足。
2003年03月23日 ナビゲーション・バーに関する記述を追加。登録サイト一覧のサイト数を20から25に変更。
2002年12月03日 検索エンジンからのアクセス数が無視出来なくなったので、登録サイト一覧のリンク方法を一部変更。
2002年11月01日 ログ情報の内容に「日次アクセス数」と「月間稼働率（目安）の順位」を追加。アクセス数順位を廃止。
2002年10月31日 W3C勧告HTML 4.01 strict.dtdに一部対応し、スタイルシート化したのに伴い、ナビゲーション・バーのHTMLタグを変更。
自宅サーバーWebRingの参加サイトのWebサーバーの稼動検査には、下記のフリーソフトを参考にし、ソースコード流用を行いました。◆自宅サーバー道さんの「自宅サーバ稼動チェックプログラムとは」◆Dream-Seedさんのサーバー稼動チェック
Webサーバーの稼動検査に必要なPerlスクリプト作成に必要な知識やネットワークプログラミングは、下記のサイトにて勉強させて頂きました。
メールアドレスの保護は、HTMLエンティティ生成を参考（reference）にしました。フリーソフトも使用させて頂きました。

[ 135] 自宅サーバーWebRing（ウェブリング）
[引用サイト]　 http://park12.wakwak.com/~webring/

名古屋を離れてすっかり忘却していたあの喫茶店のスパゲッティの味。実は「あんかけスパ」と呼ばれる名古屋固有の特殊な料理だと理解したのは数年前。ココイチが「パスタデココ」なる店を始め、虎ノ門に店があると知り、霞ヶ関に用事があった帰りに何回か行っていた。その後、秋葉原へ転勤になると、近くに末広町店があるというので、ランチに嫌がる職場の同僚を引き連れて食べに行っていた。その店が1年前に閉店。閉店を惜しんで買った店頭売りのレトルトソースが、賞味期限切れになっていた。
というわけで食べてみた。本場は 2.2 mm のスパゲッティを使用するそうだが、ないので De Cecco の No.12 を使用。
パスタデココでは小さなソーセージを使用していたが、記憶にある馴染みの店*1では極太のジャンボフランクが2本にソースだけというスタイルだったのを思い出し、両方を再現すべく、ジャンボフランク + 炒め野菜にした。
ジャンボフランクを焼きながら、玉ねぎと、ピーマン、赤ピーマン、マッシュルーム、ベーコンを炒め（胡椒で味付け）、これをボールに移して、残った油にオリーブオイルを足して、茹で上がったスパゲッティをさっと炒める。スパゲッティの上に具を盛り付け、暖めておいたソースを周囲に垂らして完成。
うまい。炒めたスパゲッティもうまいかも。でもソースがちょっといまいちかなあ。やはりレトルトでは再現しきれていないのだろうか。
「ヨコイのソース」が有名でしばしば耳にはしていたけど、店には行ったことがない。調べてみると、他に、コーミソースのコーミが出しているソースがあるようだ。「あんかけスパ レトルト」で検索してみると他にもいろいろあるようだ。
それにしても、末広町店は閉店するし、パスタデココは愛知県以外にはほとんど進出していない。レトルトソースも他地域では売られていないようだし、どうして他の地域に広がらないのだろう？ 名古屋にいたときは興味を持たなかったが、今となっては通販ででも入手したいところ。実家の地域でも売ってるだろうか。
*1 大学の近くにあった何の変哲もない喫茶店。学部生時代、土曜に学友のアパートに転がり込み、泊まって起きた日曜の昼、食べるところがそこしかなく、いつも食べるのがそのウインナースパだった。たしかこの場所。
このブログも始めて4年半になるが、一昨日、初めていわゆる「削除依頼」を受け取った。というわけで、17日の日記に追記した。
それはともかく、その追記を書いている際に、iPod touch の Safariにセキュリティに関わるバグを発見した。これは、脆弱性と言うこともできるバグではあるが、この事実を公表することにより増大し得る危険性の差分が十分に小さいのに対して、この事実の公表で利用者が自衛できるようになることによる安全性の向上の方が十分に大きいと判断し、以下にこの事実を記す。
iPod touchで https:// のサイトに接続した際、SSLのサーバ証明書の異常を示す警告（通信路上で盗聴等が行われようとしている可能性を示す）が出たとする。ここで「キャンセル」「続ける」のどちらのボタンもタッチせずに、本体下部にある「□」印の物理ボタンを押すと、どうなるか。
「□」ボタンを押すとメニュー画面に戻るので、ここで「Safari」アイコンをタッチすると、直前に表示していたWebサイトが現れるが、ここで、さきほどのリンクをタッチして再び同じ https:// サイトにアクセスしようとしてしまったとする。
すると、本来ならば再び「オレオレ警告」が出なくてはならないのに、警告が出ずに、ページにアクセスしてしまう。（ただし日本語テキストの文字化けすることがあるようだ。）
したがって、オレオレ警告が出ている最中に「□」ボタンを押してはいけない。もし押してしまったら、その後は同じ https:// サイトへ行かないように注意しなくてはならない。
これは、https:// サイトをブックマークしている場合にも同様に注意が必要だ。ブックマークからいつものログインサイトを選択したときに、もし「オレオレ警告」が出たら「キャンセル」を押さないといけないが、慌てて「□」ボタンを押してしまうと、その後再びブックマークから同じログインサイトへ行ったとき、警告が出ず、盗聴されているのに気づかずにパスワードを送信してしまうという事態が起こり得る*1。
ブラウザを再起動すれば元の状態に戻るが、iPod touchの Safariには終了の機能がないようなので、Safariがクラッシュして落ちるのを待つか、iPod touch自体の電源を完全に切る必要がある。本体上部左にある物理ボタンを長押し（数秒間）して、「電源オフ」の赤スライダを出して、それをスライドさせて切る。（電源を入れるには再び長押しする。）
脆弱性として扱われるかはわからないが、念のため、IPAの脆弱性届出窓口に届け出て製品開発者に修正を促してみる。
*1 文字化けが起きない場合。また、テキストの文字化けが起きていても（画像ばかりの画面などの原因で）気づかない場合。
5日の日記「ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する」の続き。
Windows XPでは、デフォルト設定では、「自動」接続設定されたアクセスポイントの各SSIDを常時ブロードキャスト、つまり周囲に撒き散らしているので、SSIDのプライバシー性が特に重大だった。では、他の無線LAN対応機器はどうか。いくつか調べてみた。
以下の「自宅を特定されない使い方」で、自宅のSSIDの変更が必要かについては、5日の日記と、6日の日記「位置特定につながるSSIDの割合は約17%」を参照。（もちろん、世の中にPlaceEngine（と同様のサービス）が存在しなければ、そんなことにはならないのだが……。）
スリープから復帰した直後に（パスワード認証をする前の時点から）、直前に接続していたアクセスポイントのSSIDをprobe requestとして、約10秒間ブロードキャストする。
それに接続できない場合、その前に接続していたSSIDについて同様にブロードキャストする。それに接続できない場合はさらに前に接続していたSSIDについて同様に、と、すべての覚えているSSIDについて続く。
覚えているSSIDを削除する方法がよくわからない。キーチェインから削除すると消えるっぽい。接続中のSSIDは削除できないっぽい。
接続できるアクセスポイントのない場所で電源を入れていると、その間、周囲で自宅SSIDを傍受され得る。
接続できるアクセスポイントのある場所（勤務先等）では、自宅から持ってきて最初にスリープから復帰させた際の約10秒間、周囲で自宅SSIDを傍受され得る。
自宅を出たら、自宅アクセスポイントから十分離れて接続しなくなった時点で、スリープから復帰させ、キーチェインから当該SSIDを削除してから、目的の場所に向かう。
電源を入れたとき、直前に接続していたアクセスポイントのSSIDをprobe requestとして、約1秒間ブロードキャストする。
「設定」の「接続」の「ネットワークカード」で、「ワイヤレスネットワークの構成」から、当該SSIDの項目を選択して「メニュー」から「設定の削除」を選ぶ。
接続できるアクセスポイントのない場所で電源を入れていると、その間、周囲で自宅SSIDを傍受され得る。
接続できるアクセスポイントのある場所では、自宅から持ってきて最初に電源を入れた瞬間に、周囲で自宅SSIDを傍受され得る。
電源を入れ無線LANをオンにしたとき「ワイヤレスLAN接続」で「登録済み」となっている接続先リストの上から順に接続が試みられる。
各接続先について、接続できない間、そのSSIDをprobe requestとして30秒間ほどブロードキャストする。
電源を入れ無線LANをオンにしたとき、「登録済み」接続先リストの上の方に自宅のSSIDが登録されていると、それへの接続が試行される前に中止しないでいると、その間に周囲で自宅SSIDを傍受され得る。
それはあまりに不便なので、自宅SSIDを「登録済み」接続先リストの下の方に設定しておき、上の方に勤務先やその他のアクセスポイントを登録しておき、電源を入れ無線LANをオンにしたときに、自宅への接続が試みられる前に中止する。
電源を入れて「インターネットブラウザ」を起動しどこかへ最初にアクセスするとき、前回接続していたアクセスポイントのSSIDをprobe requestで一瞬だけブロードキャストする。
「ネットワーク接続」画面で「利用する接続を選択してください」と出た場合は、ここで選択した接続先のSSIDを1秒間ほどprobe requestとしてブロードキャストする。
自動接続をやめる。「インターネットブラウザ」の「ツール」メニューの「設定」で、「接続設定」を選び、「利用する接続」を「自動選択」ではなく「手動選択」に変更する。
「インターネットブラウザ」の接続設定が自動選択になっている場合、電源を入れて「インターネットブラウザ」を起動しどこかへ最初にアクセスするとき、前回接続していたアクセスポイントが自宅だった場合、その瞬間に周囲で自宅SSIDを傍受され得る。
「インターネットブラウザ」の「接続設定」で「手動選択」に設定（上記の通り）しておき、アクセス時に出る接続先の選択画面「利用する接続を選択してください」で、自宅SSIDを選ばないように気をつける。
電源を入れたとき、前回接続していたアクセスポイントのSSIDをprobe requestとして、一瞬だけブロードキャストする。
それ以降は、そのSSIDでのprobe requestはブロードキャストされない。（電源を切って入れ直しても。）
自宅を出て、どこでも電源を入れず、どこかで最初に電源を入れたとき、その瞬間に周囲で自宅SSIDを傍受され得る。
無線LANの「SSID」は、どれが自分の使ってよいアクセスポイントなのかを人間が見分けるための名前でもあるのだから、本来、覚えやすい名前にしておくべきものではないだろうか。
これは、接続の設定をするときだけの話ではなく、今どこにつながっているかを確認する癖を付けるという意味でも重要ではないか。ゲーム機やiPod touchのように持ち運ぶ機器が無線LAN接続をするのが普通になってきたからだ。
昨今の無線LANアクセスポイント製品は、デフォルト設定が覚えられないような番号になっていたりするが、隣の家のSSIDを自分の家のものだと間違えてしまうことがありそうだ。もちろん、逆に、ご近所がみな同じ「YBBUser」というのも困る。
セキュリティの半可通が、「SSIDは予測困難なランダムな文字列にしておくのが常識」などと「キリッ」とした顔で言うかもしれないが、それは無視してよい。WPAによる暗号化さえ正しく設定（これは元々必須）しておけば、SSIDを知られたところでセキュリティ上の問題はない。そもそも、元々SSIDは電波に載って飛んでいるので隠すことは不可能だ（ステルス機能でも隠し切れない）。
SSIDの名前をランダムにしないことに問題があるとすれば、プライバシーの観点からだろう。家庭の無線LANのSSIDにふさわしい名前の要件を列挙すると、こんな感じだろうか。
例：動物の名前、食べ物の名前、星の名前、芸能人の愛称、子供向けアニメの名前、思い出の旅行先の名前など。
例：興味をそそるような名前を避け、平凡な名前に。子供がいることを知られたくなければ、子供が好きそうなものの名前を避ける。
自分の家のSSIDと同じ名前のアクセスポイントが、暗号化なしで利用可能になっていても、接続しないこと。
「こんな銀行は嫌だ――オレオレ証明書で問題ありませんと言う銀行」……そんな冗談のような話がとうとう現実になってしまった。しかも、Microsoftが対抗策を施した IE 7 に対してさえ言ってのけるという。
この原因は、地方銀行のベンダー丸投げ体質と、劣悪ベンダーが排除されないという組織の構造的欠陥にあると推察する。
図1: 武蔵野銀行の「法人のお客さま」のページで「ログインはこちら」としてリンクされているページに現時点でも書かれている内容
ぶぎんビジネス情報サイトでは、サイトＵＲＬ（https://www.bugin.cns-jp.com/）ではなく、ベースドメイン（https://www.cns-jp.com/）でSSLサーバ証明書を取得しております。このため、本サイトにアクセスする際、ブラウザの仕様により次の警告メッセージが表示されますが、セキュリティ上の問題はございませんので、安心してぶぎんビジネス情報サイトをご利用ください。
左図の画面（ページ）が表示されましたら、「このサイトの閲覧を続行する（推奨されません）」を選択(クリック)してください。ぶぎんビジネス情報サイトのログイン画面に遷移します。
IE7.0で本サイトにアクセスされますと、アドレスバーの背景色が赤くなり、「認証エラー」と表示されますが、これは、SSLサーバ証明書をサイトURLベースドメイン（https://www.cns-jp.com/）で取得しているためです。サイト自体はSSL128bitによる暗号化通信を行っておりますので、セキュリティ上の問題はございません。
図2: 北越銀行の「ホクギンeビジネス」のページとそこから「アクセス時に表示される警告メッセージについて」としてリンクされているページに現時点でも書かれている内容
法人向け情報Webホクギンeビジネスでは、サイトＵＲＬ（https://www.hokuetsu.cns-jp.com/）ではなく、ベースドメイン（https://www.cns-jp.com/）でＳＳＬサーバ証明書を取得しております。このため、本サイトにアクセスする際、ブラウザの仕様により次の警告メッセージが表示されますが、セキュリティ上の問題はございませんので、安心して法人向け情報Web ホクギンeビジネスをご利用ください。
以下の画面（ページ）が表示されましたら、「このサイトの閲覧を続行する（推奨されません）」を選択(クリック)してください。法人向け情報Web ホクギンeビジネスのログイン画面に遷移します。
IE7.0で本サイトにアクセスされますと、アドレスバーの背景色が赤くなり、「認証エラー」と表示されますが、これは、ＳＳＬサーバ証明書をサイトＵＲＬベースドメイン（https://www.cns-jp.com/）で取得しているためです。サイト自体はSSL128bitによる暗号化通信を行っておりますので、セキュリティ上の問題はございません。
北越銀行「【法人向け情報Web ホクギンeビジネス】アクセス時に表示される警告メッセージについて」より
「オレオレ証明書」についておさらいしておくと、こうした警告を「問題ありません」と説明する出鱈目が、3年ほど前に地方自治体を中心に流行しかけたが、「オレオレ証明書」という用語が誕生して、多くの人が「問題ないわけがない」ということを認知するようになった。
11日の日記 に対して、「昨日自分で書いた『オレオレ証明書』という言い方が気に入ってきた」というトラックバック を頂いた。「オレオレ証明書」……ソレダ！ 使わせて頂く。
（略）情報セキュリティの技術者たちはこういうニセ証明書を“オレオレ証明書” と呼ぶ。（略）自治体を名乗って「ブラウザーの警告なんか無視してくれ」というのがオレオレ証明書だ。（略）
そもそも、この警告が出たら「いいえ」を押すのが当然の常識として人々にもともと理解されているはずのところが、昨今では、その常識が崩れつつある。その原因は、自治体の電子申請システムだ。自治体の愚かな行いが、銀行に対するphishing攻撃の危険性を増大させている。
そもそもWebのサーバ証明書は、Webというグローバルなアプリケーションドメインに対して設定されたそれ固有のPKIモデルで稼動しているものであり、銀行をはじめとする事業者たちはこれまで、そのモデルのルールに則って証明書を購入し運用してきた。そこへ、後からやってきた役所の連中が、そのモデルのルールを無視し、勝手認証局を立て、「私達も仲間ですよ」と利用者達をたぶらかしている。（ブラウザベンダーに対して「仲間に入れて」とお願いするのではなしに。）
民間企業だったらこんなことはしない。なぜなら、他を見回してみたときにそんなことをやっているところはないと気づくからだ。一般に、誰もやらないことを自分がやろうとするときは、何か間違っているのではないかと疑ってみるのは猿でもすることだ。それなのに、自分だけはそれをやっても許されると思ってしまうのは、役所ならではだろう。
その後、Microsoftがこれに対抗策を打ち出して、Internet Explorer 7 ではより強力なエラー表示が出るように改善された（図3）。
IE 6では、単純な警告ダイアログが出て「はい」か「いいえ」のボタンを押すだけになっており、ひとたび「はい」を押してしまうと、その先では何の異常もなかったかのようにアクセスできてしまうため、意味もわからず「はい」を押してしまう人が続出していた。
これが IE 7では、図3のように、「詐欺や、お使いのコンピュータからサーバーに送信される情報を盗み取る意図が示唆されている場合があります」ときちんと理由を示した警告文に改善されたうえ、「サイトの閲覧を続行しないことを推奨します」とまで書かれている。それでもなお、「このサイトの閲覧を続行する」という選択肢が残されているものの、「（推奨されません）」とまで書かれている。万が一これが続行された場合でも、次の図4のように、続行した先のページでは常時、異常であることを示す表示（アドレスバーが赤くなり、「証明書エラー」と出る）がなされるようになった。
ここまでしつこく異常を伝えるように改善されたのだから、IE 7（とそれが標準搭載されるWindows Vista）が普及するにつれて、このオレオレ証明書問題は自然と解決されていくだろうと思っていた*1。
ところが、実際にIE 7が普及してきた現在、これらに対してさえ、「問題ありません」だとか、「『推奨されません』をクリックしてください」と言う虫*2が沸いてきた。しかも、よりによって銀行がそれを言うのである。
フィッシング詐欺の脅威が迫っている中、「アドレスバーが赤くなって『エラー』と表示されていたら閲覧を中止しなければならない」という鉄則を利用者の常識としなければならないところに、「使ってもいい場合がある」などという嘘*3が吹聴されたら、対策が台無しであり、皆が迷惑する。
銀行に脆弱性があって放置されているとか、銀行が改竄されているとか、そういうのはある意味自業自得なのだから、周りからとやかく言われる筋合いはないと言われるかもしれないが、このような、嘘の説明を言いふらす行為は、他のまじめにやっている銀行が迷惑するだろう。金融庁が指導するか、あるいは、全銀協がこれらの銀行に対して抗議するべき事態と言える。
それにしても、なぜこんなことになってしまっているのか。2つの銀行の説明文を見ると、それらが同一の文章から作られていることがわかる。単にこの2つの銀行が馬鹿だというだけでなく、他に汚染源があると推察される。
そこで、11月2日にこれらの銀行に電話して、問題点を指摘するのと同時に、原因を探るべく取材を試みた。*4
まず、電話すると先方は第一声として、「証明書を買うかどうか検討している最中でして」と言う。話を聞くと、今年の7月に地銀ネットワークサービス株式会社から文書で通達があり、証明書を買えば警告が出なくなるとの説明を受けているという。
「地銀ネットワークサービス株式会社」とは全国地方銀行協会に加盟する全国の地方銀行が株主となって設立された共同事業会社であり、ここが「cns-jp.com」というサイトを運営している。図1、図2のエラー画面が出るWebページは、「www.bugin.cns-jp.com」と「www.hokuetsu.cns-jp.com」であるように、この「cns-jp.com」の配下にある。つまり、共同運営会社がASPサービスとしてこれらのサイトを提供しているわけである。
同じこのASPを使う銀行でも、この警告が出ないところもある。たとえば、沖縄銀行向けの「https://www.okinawa.cns-jp.com/」では警告が出ない。2006月9月12日の日記の記録では、沖縄銀行のこのページも警告が出る状態だったので、その後、沖縄銀行は証明書代金を支払ったのだろう。現在でも、以下の7つの銀行が警告が出る状態のままとなっている。
なぜこれだけの長期間にわたって、「買うかどうか検討している最中」のままなのか謎であるわけだが、それは理解できなくもない。なぜなら、銀行が証明書を取得するのではないからだ。
沖縄銀行用のサイト「www.okinawa.cns-jp.com」の証明書の発行先を見ると次のようになっている。
このように、沖縄銀行が証明書を取得したのではなく、証明書の取得者はASP提供会社である地銀ネットワークサービスになっている。それは当然で、ドメイン名が「cns-jp.com」だからだ。
つまり、証明書の取得にお金が必要というのは、システムの都合であって、銀行が証明書を買うという話ではない。実際、システム設計を変更すれば、各銀行ごとにばらばらに何枚も証明書を買う必要などない。たとえば、次のURLにすれば「www.cns-jp.com」用の証明書1枚で済む。*6
システムを作った際、SSLのことを何も考えなかった結果だ。そしていざサービスを始めてみると、SSLで警告が出るという苦情が寄せられるようになり、さてどうするかというときに、システムの欠陥を直すのではなしに、証明書を無駄に何枚も買わせて解決しようとしたわけだ。
これはシステムの設計ミスが原因なのだから、その解決に必要な費用はシステム提供者である地銀ネットワークサービスが負担するべきものだろう。それを銀行に支払いを要求しているものだから、各銀行も、意味のわからない料金を払うわけにいかないという状態になっていると思われる。
このことについては、12日に地銀ネットワークサービスにも電話して指摘した。しかし、どうもこの会社には誰もこの件についての責任者がいないようなのだ。電話で用件を伝えようとすると、用件を文書で書いて送れという。なんでわざわざ文書で書かないといけないのかと尋ねると、システムの開発を外部に出しているので、外注先に指摘の文書を見せたいのだという。
そうなると、外注の業者が自らの失敗を認めるはずがない。「このままで問題ありません」と回答することになる。「問題ありません」という回答が、地銀ネットワークサービスの案山子を素通りして、各地方銀行に配布される。そして図1と図2のような出鱈目な説明が表に出てくる。
馬鹿ばかりだ。誰一人、責任を持って自力で考えられる人がそこにはいない。これは技術がわからないからとかいった話ではない。他所がどうしているか見て廻れば異常だと感づけることであるし、外注業者を信用してはならないことは当たり前の話だ。
ちなみに、この問題は、システムを改修しなくても簡単に解決できる別の方法がある。「ワイルドカード証明書」を使えばよいだけの話だ。ワイルドカード証明書とは、サーバ証明書の発行先のCommon Name（ホスト名）を「*.cns-jp.com」という「*.」を使った名前で登録するもので、これにより、同じドメイン上のどのホストにも正しく適用できるというものだ。
ワイルドカード証明書を導入すれば一瞬で解決するし、沖縄銀行も変な別料金を負担する必要はなかった。外注先業者はそれを知らない無能業者であるか、もしかすると、知らないふりをして、無駄に証明書を買わせ、証明書取得代行の手数料で儲けようと鴨を待ち構えている可能性だってある。
証明書を買うように言われているのもおかしな話、買うのは地銀ネットワークサービスであり、あなたの銀行ではない。
削除するだけで済まされる話ではない。今まで間違った説明をしていたことを告知し、正しい使い方「赤くなっていたら使用を中止する」を周知するべき。
特に重要なのは、誤った説明を削除するという件だ。北越銀行には11月2日に説明を終え、武蔵野銀行には11月12日に説明を終え、どちらの担当者も意味を理解して納得していたが、どちらの銀行も、今もなおこの出鱈目な説明を利用者に読ませ続けている。
さすがに、IE 7 になってから「問題ありません」と説明するところはほとんど見当たらなくなった。しかし、大学はあいかわらずひどい。こういう大学で教育を受けた卒業生が将来の糞業者になっていくのだろう。高校生諸君はこれらの大学は避けたほうがいい。
現在、WebMailに接続すると、”この Web サイトのセキュリティ証明書には問題があります。”というページが表示される、あるいは、”セキュリティの警告”というウィンドウが表示される場合があります。
これは、システム移行にともなう、証明書の手続きが間に合っていないためで、セキュリティ上の問題はありません。
ページが表示された場合は、”このサイトの閲覧を続行する (推奨されません)。 ”をクリックしてください。
URLをクリックして「Web サイトのセキュリティ証明書には問題があります」のページが表示された場合は（学内のサーバですので問題ありませんので），「このサイトの閲覧を続行する (推奨されません)」をクリックしてください。
Internet Explorer 7をインストール（アップグレード）後、学内ページの一部を開こうとすると、下のエラーが表示されるようになりますが、「このサイトの閲覧を続行する（推奨されません）。」をクリックすると通常の画面が表示されますのでそのままご利用ください。
「証明書に関するセキュリティの警告」が表示されますので、「はい」や「このサイトの閲覧を続行する」をクリックしてください。
上で引用した専修大学のページは 404 Not Found になったのだが、これに関して、専修大学の方々から2通のメールを頂いた。事務計算センターの方から頂いた「一個人として専修大学の現状及び取り組みを知っていただきたい」「大学からの正式な見解を説明するものではない」というご趣旨のメールによると、平成19年度の履修登録ではたしかにオレオレ警告を無視させていたが、「セキュリティに対する認識の甘さについては反省をし、早急に改善すべき課題としてとらえ、改善への対応・対策を既に実施しています」とのことで、10月1日の大学全体のリニューアルの際に、オレオレ警告の出るSSLサーバは撤廃しているのだそうだ。Web履修登録については、平成19年度はもう終わっているので、平成20年度に向けてシステムの開発作業を計画中とのこと。
続けて専修大学教務部教務課の方から、「昨日、本学のシステム担当者からも連絡をしておりますが」との前提を置いた形で以下の通告を受けた。
今回、貴殿が書かれた標記の日記の中で、本学のＷｅｂ履修登録システムに関する記載事項がありました。昨日、本学のシステム担当者からも連絡をしておりますが、今回運用担当者として連絡をさせていただきました。
本学としましては、貴殿のご指摘のとおり、このセキュリティへの甘さについては認識をしており、平成２０年度のシステム稼動より対策を講じる手続きを既に行っておりました。
なお、貴殿が書かれたこの記載事項によって本学を希望する受験生等への影響が考えられます。ご指摘内容については真摯に受け止めており対策を行ってまいりますので、本学の記載内容をＨＰ上から削除していただければ幸いです。
このようなご心配を招くのであれば、上のような中途半端な引用で済まさず、正確に事実関係を伝えなくてはいけないと思う。
図5: 「専修大学, Ｗｅｂ履修登録」のページに2007年11月17日の時点で書かれていた内容（現在は削除）
「セキュリティについて」の部分に書かれている内容から、学外から使用することを前提としたシステムだったことがわかる。そして、「「証明書に関するセキュリティの警告」が表示されますので、「はい」や「このサイトの閲覧を続行する」をクリックしてください。」と書かれていた。
上の他の事例とは異なり、「問題ありませんので」といった説明は行われていなかった*8。そして、このページは現在削除されている。
ただ、二部のWeb履修登録のページからはまだ削除されていないようだ。また、ここからリンクされている「操作説明書」(PDF) には次の記載がある。
※ログインボタン押下後、証明書に関するセキュリティの警告が表示される場合がありますので、「はい」や「このサイトの閲覧を続行する」を選択してください。
これによると、ログイン画面に到着したときにオレオレ警告が出る――(a)というのではなく、パスワードを入力してそれを送信しようとボタンを押した瞬間に出るオレオレ警告を無視するように指示していたということのようだ。これは、(a)に比べてより危険性の高い利用手順を教えていたことになる。
一度このような手順に慣れてしまうと、それが普通の使い方だと思い込んでしまうだろう。その誤った理解を矯正しなければ問題は解決したとは言えない。
現在の専修大学 在学生・教員向けポータルサイト（これがそのリニューアルされたシステムだろうか）には、ログイン画面があるが、図7のように、「セキュリティについて」の部分で、従来のWeb履修登録システムにあったのと同じ注意書きがあるものの、警告が出た場合にどう行動するべきかについては何も書かれていない。
もし、学生がたとえば通学中に道端を歩きながら、iPod touch等を用いて livedoor Wireless経由でこのポータルを利用する際に、ログインしようとパスワードを入れてボタンを押した直後*9、SSLのサーバ証明書に異常があることを示す「オレオレ警告が」出たとしよう。*10
つまり、誤った説明を単に削除するのではなしに、これまでに説明していた操作方法は誤った使い方だったという事実、そして、今後もしこのポータルサイトを使う際に警告が出た場合は、絶対に先に進んではいけないことを、周知しなくてはならない。
また、それだけでなく、一般にどこのサイトでもこの警告が出た場合はけっして無視してはいけないものであるという正しいリテラシーを「教育」するのが本来の教育機関の役目であろう。
上に挙げた2つの地方銀行は、今現在も、嘘偽りの説明を掲示したまま顧客に読ませているが、営利企業が嘘偽りの説明を放置するのは、法令違反がない限り、営業上の自由だろう。無かったことにして終わりにする自由もある。
不特定多数に利用させることを想定していて、ルート証明書もサーバ証明書もインストールさせるつもりのないもの。
不特定多数に利用させることを想定していて、ルート証明書かサーバ証明書をインストールするよう促しているが、インストール方法として安全な手段が用意されていないもの。
不特定多数に利用させることを想定していて、ルート証明書かサーバ証明書をインストールするよう促しており、安全なインストール方法が用意されているもの。
正規の認証局から取得したサーバ証明書であるが、一部のクライアントでその認証局がルートとして登録されていないもの。
正規の認証局から取得したサーバ証明書であるが、使い方を誤っているもの。（中間認証局から取得したサーバ証明書なのに、中間認証局の証明書をサーバに設置していないために、クライアントが認証パスを検証できないもの。あるいは、サーバ証明書のホスト名と実際に使用するサーバのホスト名が一致していないものなど。）
*1 この事例は、2006月9月12日の日記「「『サイト名と一致しません』という項目のみの警告であれば問題ありません」？」でも書いていたが、当時はまだ、警告は出るものの、「問題ありません」という説明は存在していなかった。IE 7が普及するにつれておのずと過ちに気づくだろうと思って、指摘の電話はしなかったのだが、いつのまにかこんな事態になっていた。
*2 2005年8月2日の日記「どんなにセキュリティ機能を追加してもそれを設定で殺させる虫が湧いてくる」参照。
*3 今回のケースは、正規の認証局から発行されていて、ホスト名が異なるだけの証明書だから、問題がないと業者は言っているのだろうが、問題ないわけがない。盗聴者は、別のサイト用の正規の証明書を取得して、それを使って盗聴するだろう。そのとき、「赤くなっていても問題ありません」というのでは、盗聴されている状況とそうでない状況とが区別できない。「利用の都度、証明書の発行先を確認してください」という説明なら許されるかといえば、そうでもない。なぜなら、最初のエラーで証明書の発行先を確認しても、次のアクセスで、盗聴者が盗聴者用の証明書を送ってきた場合に、確認できるかが問題となる。これはブラウザの実装しだいであり、再び警告が出るとは限らない。
*4 北越銀行については、2日の時点で担当者と話すことができ、説明を完了した。武蔵野銀行については、2日は担当者から折り返しの電話が来なかったので、12日に再び電話して説明を完了した。
*6 本来は、銀行ごとのドメイン名の下にホスト名をDNS登録して、銀行のサーバ証明書を取得した方が良い。つまり、https://www.cns-jp.com/hokuetsu/ とするのではなく、https://cns.hokuetsubank.co.jp/ とするのが望ましい。インターネットバンキングならばそうするべきであることはこれまでも書いてきた（2005年2月20日の日記「フィッシング防止のため地方銀行はこうするべき」参照）。しかし、このASPは単なる情報提供サービスにすぎないことから、インターネットバンキングほどのセキュリティは必要ないという考え方もあり得るのだろう。つまり、各銀行は、この情報サービスが「地銀ネットワークサービス株式会社」の提供であることを利用者に明示して、ドメイン名が cns-jp.com であることを周知して使ってもらうというのは、あり得る選択ではある。その選択がありであるにしても、現在のこのシステムの設計は出鱈目だ。
*7 負荷分散のために銀行ごとにばらばらのホストが必要だったのかというとそうでもない。実際、警告の出るこれら7つの銀行用のサイトは、皆同じ IPアドレスで提供されており、意味もなくバーチャルホストで運営されている。
*9 ログイン画面を表示させた時点では本物のサーバ証明書で（警告なしに）接続されていても、その次のアクセスでは、攻撃者が偽のサーバ証明書を提示してくることが起こり得る。
*10 このような事態はごくごく現実的に起こり得る。livedoor Wirelessのような方式の公衆無線LANでは、偽のアクセスポイントを設置することができてしまうので、偽の方につながってしまうと、攻撃者は簡単に盗聴や改竄、偽DHCPサーバおよび偽DNSサーバの設置等ができてしまう。そんなリスクがあっても安全に使えるようにするのが SSLであり、学外から利用できて便利と謳うために SSLが必須となっているわけであろう。
ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する

[ 136] 高木浩光＠自宅の日記
[引用サイト]　 http://takagi-hiromitsu.jp/diary/



自宅とは？トップへ↑

お気に入り



  • track feed
    • seo