自宅とは？

このサイトは非固定 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 の良い所なんでしょうネ。

[ 58] 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）にしました。フリーソフトも使用させて頂きました。

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

「オレオレ証明書」の問題が広く認知されるようになってきたのはよいが、オレオレ警告が出たとき、「お、オレオレじゃん。どうなってんの？このサイト」と、野次馬的に興味本位で「はい」を押して先を見に行ってしまう人も出てきているのではないかと心配になった。
大学や自治体サイトに「問題ありませんので」と書かれているのを見たことがあるので、「はい」を押して先に進むのが普通と思っている人
「オレオレ証明書」という話を聞いたことがあるので、これが出るサイトは駄目サイトだと思っていて、どうなっているか見に行ってしまう人
「オレオレ証明書」のことは理解しているつもりで、警告を無視したアクセス先で重要な情報（パスワード等）の入力さえしなければ問題ないと思っていて、どうなっているか見に行ってしまう人
正しく理解していて、オレオレ警告が出たときは基本的に「いいえ」を押すようにしているが、正しい手順を経てその先を見に行くこともある人
「オレオレ警告が出たらそこは駄目サイト」という理解は誤りだ。閲覧している人がそのタイミングで（通信路上で）攻撃を受けているだけで、サイト自体は正常である場合もある。オレオレ証明書が問題なのは、サイト自体が異常な設定をしていると、サイトが異常なのか、閲覧者が攻撃を受けているのか、区別つかないという点にある。上記のうち正しい行動は、1.と 5.と 6.だけである。
これまで、オレオレ警告時は「いいえ」を押してアクセスしないのが当然であるとし、もし「はい」を押して先に進んだ場合にどんな危険があるのかについては、あまり具体的に整理してこなかった。上記4.のパターンの「重要な情報（パスワード等）の入力さえしなければ問題ないと思っていて、どうなっているか見に行ってしまう」という行動が、どのように危険なのかを以下に整理してみる。
たとえば、銀行やネットショップでログイン中のとき（パスワードを送信するときは警告は出なかったとして）、あるタイミングでオレオレ警告が出たとしよう。「あ、オレオレ証明書じゃん。どうなってんの？このサイト」と、とりあえず警告を無視して先に進んだとしよう。その瞬間何が起きるだろうか。
つまり、図1の画面で「はい」ボタンを押した瞬間、また、図2の画面で「推奨されません」のリンクをクリックした瞬間、図3の画面で「OK」ボタンを押した瞬間、図4の画面で「承認する」ボタンを押した瞬間、図5の画面で「Continue」を押した瞬間、図6の画面で「続ける」を押した瞬間、図7の画面で「はい」を押した瞬間、何が起きるだろうか。
もし通信路上に盗聴者がいた場合*2、そのcookieは盗聴される。セッションIDが格納されているcookieが盗聴されれば、攻撃者によってそのセッションがハイジャックされてしまう。
「重要な情報さえ入れなければいいのだから」という認識で、オレオレ警告を無視して先を見に行ってしまうと、ログイン中のセッションをハイジャックされることになる。
さすがに、銀行を利用している最中でオレオレ警告が出たときに、興味本位で先に進む人はいないかもしれないが、銀行を利用した後、ログアウトしないで、別のサイトへ行ってしまった場合はどうだろうか。通常、銀行は数十分程度で強制ログアウトさせる作りになっているはずだが、その数十分の間に、通信路上の盗聴者により、銀行サイトへリダイレクトさせられた場合どうだろうか。
閲覧者としては、ニュースなどを読んでいる最中に突然オレオレ警告が出るという体験をする。ここで、ニュースサイトが出している警告だと思い込んで、そのまま「はい」で先に進むと、さっきまで利用していた銀行にアクセスしてしまい、送信するcookieを盗聴されてしまう。
このことは、17日の日記「こんな銀行は嫌だ」の件に関係する。電話で問題点を指摘した際、こんなやりとりがあった。
私: どういう責任を感じてるんですかね。これ間違ったことを、嘘を教えているわけでしょ？ おたくのユーザに、赤くなってても使って大丈夫だと教えてるわけでしょ？ 推奨されませんとまで書いてあるのに、それを押せと、言ってる。「セキュリティ上の問題はございません」て書いてあるでしょ？ そういうものだって理解しますよね？ これ読んだ人は。赤くなっていても問題ないのだと、教えられるわけですよね？ そういう誤った知識を植えつけてしまったことに対する責任をどう考えてるんですか？ おたくは。
私: どういうふうに検討されるんですか？ 間違ったことを書いてましたと、赤くなってるときは使ってはいけないのに、
銀: あのー……。そうか……。……。これは、すべての場合のInternet Explorerをご利用の場合にというアナウンスではないんですけどもね。
銀: Internet Explorer 7で推奨されませんと出たときの、すべての場合でそのまま押してくださいと申してるものではないんですども。
つまり、銀行側の言い分として、この警告を無視してよいと言っているのは「ビジネス情報サイト」についてだけであって、他のサイトについては言っていないというわけだ。しかし、次の被害シナリオが考えられる。
この銀行のインターネットバンキングを利用した人が、インターネットバンキングをログアウトしないで、「ビジネス情報サイト」を閲覧しに行ったとする。このとき、通信路上の盗聴者が、閲覧者のブラウザをインターネットバンキングのサイトへとリダイレクトさせ、通信路上でサーバ証明書を攻撃者所有の証明書に置き換えたとする。そうすると閲覧者のブラウザにはオレオレ警告が出るわけだが、閲覧者は、いつもの「ビジネス情報サイト」にアクセスしようとしていると思っているので、そのオレオレ警告を無視して「はい」を押してしまう。この瞬間、インターネットバンキングサイトに（盗聴されながら）アクセスすることとなり、cookieを盗聴され、セッションハイジャックされてしまう。
もっと酷いことに、これはその銀行だけで被害が済む話ではない。閲覧者が、他の銀行であるメガバンク等にも口座を持っていて、メガバンクのインターネットバンキングにログインしている最中に、この地銀の「ビジネス情報サイト」を閲覧しに行ったら、真面目にサイトを作っているメガバンクの方で被害が出てしまう。
cookie窃用によるセッションハイジャックだけならば、たいして重大でない場合もある。セキュリティを重視したサイトでは、たとえセッションハイジャックされても重大な被害が出ない構成にしていることがある。たとえば、個人情報を閲覧する画面に入る際には再びパスワードの入力を必要とするとか、振込み操作を実行するにはワンタイムパスワードの入力を必要とするといった構成だ。*3
しかし、cookie窃用によるセッションハイジャックとは異なり、今想定しているケースでは、通信路上に盗聴者が入っている（SSLを使っているのにオレオレ警告を無視した）のであるから、常時、通信内容を盗聴されたり改竄されている可能性がある。
したがって、本人が、個人情報閲覧画面に入ろうとしてパスワードを送信したとき（そのパスワードも盗まれるが）閲覧する個人情報は盗聴されるし、また、たとえワンタイムパスワードを使っていても、9月23日の日記で書いたman-in-the-middle攻撃の場合と同じ危険がある。（IE 7 ではアドレスバーが赤くなっているので異常な状況を判別できるが、それ以外のブラウザでは、オレオレ警告を無視した後の状態であることを判別できない。）
銀行では比較的短時間で強制ログアウトさせられるが、長時間ログインしっぱなしで使う、ブログやSNSサイト等では、これが現実となる可能性がより高くなるだろう。
また、ログイン中でなければ大丈夫というものでもない。オレオレ警告は1度しか出ない点に注意が必要である。
あるタイミングでオレオレ警告が出たとする――(a)。「ログイン中でないから大丈夫だろう」「何も入力しなければ大丈夫だろう」と興味本位で先に進めてみたとする。そのときは何も起きなかったとする。それから何日かして、そのことをすっかり忘れているときに、インターネットバンキングを利用するとき、実はそれは盗聴されているということが起こり得る。
つまり、(a)のオレオレ警告は通信路上の盗聴者がしかけたオレオレ証明書によるものであり、それを一旦受け入れてしまった閲覧者は、その後、同じ盗聴者がいる通信路上でアクセスすると、警告なしに盗聴されてしまう。ログインしようとパスワードを送信する時点から盗聴される。（IE 7 ではアドレスバーが赤くなっているので異常な状況を判別できるが、それ以外のブラウザでは、オレオレ警告を無視した後の状態であることを判別できない。）
これを回避するには、ブラウザを再起動する必要がある。昨今のWindowsは安定して動くので、何週間にもわたって起動しっぱなしで使うのが普通になっている。iPod touch の場合は Safariを再起動する手段さえ用意されていない（11月23日の日記参照）。
オレオレ警告をあえて無視して先を見に行こうとするとき、証明書の内容を確認すれば大丈夫と言えるだろうか？
たしかに、警告の内容と証明書の内容によっては見に行って大丈夫な場合もある。しかし、大丈夫かどうかは、素人には判別が難しい。
たとえば、11月17日の日記の地銀ネットワークサービスのビジネス情報サイトの場合、発行先が「www.cns-jp.com」となっていて、アクセス先のサーバと食い違っているために警告が出ている。したがって、証明書の内容を表示させて確認し、発行先が「www.cns-jp.com」であることを目視確認すれば、見に行っても大丈夫だと言うことも可能だ（ブラウザによっては）。
しかしそのとき、証明書の発行者が正規の認証局であることも同時に確認しなければならない。つまり、Intnernet Explorer ならば、図8の (a) と (b) のどちらなのかを見分けなくてはならない。
PSPの場合、図7の1つ目と2つ目の警告を見分ける必要があるが、それらの意味の違いをいったいどれだけの人が理解できるというのだろう？
また、Internet Explorer 7 では、アクセスする前に証明書の内容を確認することができなくなった。図2のように、証明書を確認するためのボタンやリンクは存在しない。確認するには、一旦「このサイトの閲覧を続行する（推奨されません）」をクリックして先へ進み、図9の「証明書のエラー」となっている部分をクリックして初めて証明書の内容を閲覧できる構造になっている。その画面を見た時点で既に盗聴者にcookieが送信されているので、後の祭りだ。
iPod touchにいたっては、証明書の内容を確認する機能がそもそも存在しない（上記の図6および、10月20日の日記参照）。
加えて、Firefox 2 と Safari 2 には別の危険性があることが、先週 Bugtraqに投稿された記事で指摘された。
オレオレ警告を無視してしまうと、その後、同じオレオレ警告は出なくなるわけだが、「同じ」というのはどこで判別されるのか。
Firefox 2 では、証明書単位で覚えておく実装になっているようだ。そのため、次の挙動が起こり得る。
サイト A へ接続する際に、不明な認証局から発行されたオレオレ証明書（ホスト名は A として発行されている）が提示された場合、
ブラウザは、「未知の認証局により認証されています」の警告は省略するけれども、ホスト名が B であるはずのところ A になっているという警告（図10）を出す。
つまり、サイト A でオレオレ証明書を受け入れた閲覧者は、証明書の内容を目視確認して、サイト A 用の証明書だと承知の上で受け入れたのであろうから、サイト A で盗聴の危険に晒されるのは閲覧者の自己責任である ―― という立場をとることが可能だ。
もし、サイト A への接続時に、図3の警告だけでなく図10の警告も現れて、そのオレオレ証明書がサイト B 用のものであると示されていた場合は、閲覧者は、B が重要なサイトでないかを確認しなければならない。もし、B が重要なサイトなのにそのオレオレ証明書を受け入れてしまうと、後に B のサイトへ行った際に、警告は出ず、盗聴されてしまうことになる。
したがって、Firefox 2 では、オレオレ警告時に見るべきは証明書の発行先のホスト名であると言える。
具体的に言うと、たとえば「ビジネス情報サイト」を訪れたときに、通信路上の盗聴者により、攻撃者自作のオレオレ証明書が提示されたとする。まず図3の警告が出るが、「『ビジネス情報サイト』だからどうでもよい」という判断でこれを受け入れたとする。さらに図10の警告も出たときに、内容をよく見ないで受け入れたとする。そのとき、実は図10の警告に、
と書かれていたとすると、それは危険な状態となる。インターネットバンキングの本物サイトである、「https://ib.○○bank.co.jp/」にアクセスしたときに、通信路上で盗聴者がその偽サーバ証明書を使っていても警告が出ない事態となる。
閲覧者は、オレオレ警告を無視するときは、「"○○" のものです」の部分を目視して、どうでもよいサイトであることを確認しなければならない。これを怠るのは閲覧者の自己責任である ―― というわけだ。Firefox 2 はそのような方針で作られていると言える。
ところが、先週Bugtraqに投稿された指摘によると、証明書の「subjectAltName」欄まで見なければ、確認したことにならないという。
図10で「"○○" のものです」と表示されているのは、証明書の「Subject」欄の「CN」欄の文字列になっている。ところが、証明書の標準規格である「X.509」（RFC 3280参照）は「subjectAltName」という欄を定義しており、ここにも証明書の有効なホスト名を記載できるようになっている。そして、最近のWebブラウザはこの「subjectAltName」をサポートしており、この欄も見ている。
Firefox 2 は、図10の警告で「"A" のものです」と表示していても、それは「Subject」欄の「CN」欄の値であって、それとは別に「subjectAltName」欄に「B」と書かれていたなら、その証明書を受け入れてしまうと、B のサイトに行ったときに盗聴されていても警告が出ないという事態になってしまう。
そのため、指摘者は、図10の警告で「subjectAltName」欄の内容も表示するべきだという提案をしている。
これに対し、Mozillaプロジェクトは、Firefox 2 では直さないとしているそうだ。（先ごろベータテストが開始されたばかりの）Firefox 3 では、オレオレ警告の出し方を変更しているためこの問題はないようだ。
セキュリティにかかわる件であるのに直さないというのは、このケースでは理解できる。なぜなら、そもそも、オレオレ警告を無視しながら安全に使おうとすること自体に無理があると思うからだ。
ちなみに、Intrenet Explorer と Opera にはこの問題がないとのこと。Internet Explorerでは、オレオレ警告を無視した後の「同じオレオレ警告の省略」は、アクセスしたサイトのホスト名ごとに管理しているらしい。つまり、サイト B 用に発行されたオレオレ証明書をサイト A への接続時に無視しても、サイト B に接続するときには、同じオレオレ証明書が提示されても再び警告を出すようになっているようだ。
Firefox と Internet Explorer を比較すると、オレオレ警告に対してユーザがどう対処するべきかの考え方に違いがあるように思える。
Firefox は、ユーザの自己責任の下、証明書の内容を確認して受け入れる仕組みを用意する方向性で設計されている。対して、Internet Explorerは、IE 7 での改良で、警告時に証明書の内容を表示する機能を省いてしまい、そもそも確認できないように設計変更された。これは、「ユーザに確認することは無理だから、警告発生時にはアクセスを継続するな」（「推奨されません」）という方針で設計されていると言えるだろう。
Firefox はプロ向け、マニア向けと言えるかもしれないが、受け入れても大丈夫な証明書であることをきちんと確認できるだろうか。
IE 7 と同様に、ダイアログウィンドウでの警告はやめて、画面全体でエラーが表示されるように改善された。（どのサイトにアクセスしようとして出たエラーなのか、アドレスバーで確認できるようになっている。）
それでもアクセスを継続する手段は残されているのだが、IE 7 と異なるのは、IE 7 では「証明書のエラー」のまま、アドレスバーの赤い表示でアクセスを継続させるのに対して、Firefox 3 では、証明書の内容を確認して、証明書を登録してからアクセスするようになっている。図11の「例外として扱うこともできます」の部分をクリックすると、図12のようになる。
「例外を追加」ボタンを押すと図13のウィンドウが現れる。ここで何を確認すれば安全と言えるのか、一般の人たちにそれが理解可能だろうか？*4
たとえ、それぞれのブラウザで安全にオレオレ警告を扱う方法が用意されているとしても、それは、たまたまそのブラウザがそのような実装になっているというだけで、SSLの仕様に基づいた挙動ではないという点に注意したい。サーバ証明書の正当性検証ができない状況は、致命的エラーなのであって、そのときに例外的に扱う方法は定義されていない。
図13: Firefox 3 曰く「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません」
「本物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません」とあるように、本物の銀行や公共サイトがこのような操作を強いることがあってはならない。
また、Firefox 3 の「セキュリティ例外を承認」の機能は、興味本位で見に行くためのものではない。Firefox 2 までの「このセッションの間だけ一時的に証明書を受け入れる」（図3）の機能は廃止された。「セキュリティ例外の承認」は、「今後この証明書を受け入れる」を選択した場合に相当する。「証明書マネージャ」（図14）で受け入れ済み「サーバ証明書」のリストから削除するまで、この状態は続いてしまうので注意が必要だ。
話が長くなったが結論は単純で、「オレオレ警告が出たらいかなる場合もアクセスを中止すること」と心得ておけばよい。
興味本位でオレオレ警告の出るサイトを見に行く場合には、十分な知識を持って適切な手順でブラウザを使用しないと、被害に遭う危険性がある。
*2 このような事態はごくごく現実的に起こり得る。最も現実的な例としては、たとえばlivedoor Wirelessのような方式の公衆無線LANでは、偽のアクセスポイントを設置することができてしまうので、偽の方につながってしまうと、攻撃者は簡単に盗聴や改竄、偽DHCPサーバおよび偽DNSサーバの設置等ができてしまう。そんなリスクがあっても安全に使えるようにするのが SSLであり、銀行等が顧客に対して「SSLを使用しています」と胸を張って約束するのはそのためであろう。
*3 クロスサイトスクリプティング脆弱性に備えてこのような作りにしているサイトはけっこうある。また、ブログやSNSサイトのように、SSLを一部のページにしか使っていないサイトの場合、セッションハイジャックは重大な脅威でないという方針をとっている場合がある。つまり、パスワードを保護するためだけにSSLを使い、http:// のページでセッションハイジャックされても、重大なページへ入るには再びパスワードの入力を要求する作りにしていることがある。
*4 ここで、「セキュリティ例外を承認」を押した場合、「サーバ」欄に書かれているURLに対してだけ、この例外が適用されるようなので、このURLのサイトの重大性だけ判断すればよいように思えるが、これで正しいだろうか……。
名古屋を離れてすっかり忘却していたあの喫茶店のスパゲッティの味。実は「あんかけスパ」と呼ばれる名古屋固有の特殊な料理だと理解したのは数年前。ココイチが「パスタデココ」なる店を始め、虎ノ門に店があると知り、霞ヶ関に用事があった帰りに何回か行っていた。その後、秋葉原へ転勤になると、近くに末広町店があるというので、ランチに嫌がる職場の同僚を引き連れて食べに行っていた。その店が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と同じ名前のアクセスポイントが、暗号化なしで利用可能になっていても、接続しないこと。

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



自宅とは？トップへ↑

お気に入り



  • track feed
    • seo