連載 / UN Ⅸの玉手箱ー① としてセットアップすれば NIS や /etc/hosts は無視さ れることに注意してください。 これを変更し、たとえは、、 DNS → /etc/hosts → NIS" という順番でホスト情報を検索させるには、以下のように /etc/irs. conf のホスト情報に関する部分を変更します。 hosts hosts hosts dns continue 10Ca1 C ont inue IIIS /etc/irs. conf のホスト情報以外に関する部分について は、オンライン・マニュアル irs. conf(5) などを参照して ください。 S01aris の /etc/nsswitch. conf Solaris かイ吏う /etc/nsswitch. conf についての岩田は、 man nsswitch. conf" を参照してください。記述方法 は BSD/OS に似ています。また、サンプルとして /etc/ nsswitch. nis や /etc/nsswitch. files などが用意されてい るので、これらも参照してください。 ホストやサービスに対するアクセス制御 前回紹介したホスト自身がもつホスト名や IP アドレス などの設定に加え、 ここて紹介したホスト情報に関する設 定をおこなえは、ユーサーがネットワーク・コマンドの引 数に指定したホスト名を正しく IP アドレスに変換し、相 手ホストと通信することができます。 しかし、ネットワークエ韆竟、とくにインターネットに ホストを接続して運用する場合、セキュリティにはつねに 気を配る必喫があります。ホストやネットワークに対する 攻撃には、ネットワークを流れる IP バケットを盜聴し てデータの内容を調べたり、パスワードのクラッキングに よってあるユーザーになりすまし、サービスを不正利用し たりマシンにダメージをえるなど、しつにさまざまなも のがあります。 これらをより完全に防ぐには、通信データを暗号化した り、暙号を用いて通イ計目手の身許を石忍する ( 認証 ) など、 特別な機構が必要です。しかし、それ以前に、ホストのセ キュリティを保っための基本的な姿勢は、、不要なサーピス は提供しない " ことにあるのではないでしようか。 OS によって多少の違いはありますが、 UNIX をインス トールすると、 ftp や finger など、いくつかのネットワー UNIX MAGAZINE 1999 ユ ク・サービスに対しては、他のホストからのリクエストに 応してサーバーか起ける設定になっているはすです。自 分の使っているマシンカ甘是供するサーピスを把握していな いと、万かン - 一そのサーピスのサーバー・プログラムにバグ や設定ミスなどがあった場合、そこを突かれて攻撃されな いともかぎりません。したがって、マシンをネットワーク に接続している場合、そのマシンで動くサーバーを調べて 不要なものは起動しないように設定しておけば、攻撃され る可能性を多少なりとも減らせます。 そこでここからは、 /etc に置かれているファイルのう ち、他のホストからのアクセス制御に嬲里したものをいく つかとりあげます。 信頼するホストの設定 UNIX のコマンドには、ローカルなホスト上で実行す るコマンドをネットワークに対応させたものがいくつかあ ります。たとえは、ファイルをコピーする cp コマンド をネットワークに対応させ、リモートホストとのあいだで ファイルのコピーをおこなう rcp コマンドや、リモートマ シンにログインするための rlog ⅲ、リモートマシンでシェ ルを実行するための rsh などがあります。各コマンドの 詳細は、オンライン・マニュアル rcp(l) や rlogin(l) 、 rsh(l) などをご覧ください。それぞオリジナルのコマ ンド名の寬こ r という文字カ咐けられているため、 れらを糸尓して、、 r コマンド " と呼ふ、こともあります。 通常、 r コマンドをリモートホストに対して実行する と、 rlogin の場合は確認のパスワードを求めらその 他 (rsh や rcp) の場合は「アクセス権限がない」と断わ られます 10 。これに対し、 r コマンドの対象となるリモー トホスト側で、、イ頁するホスト ( およびューサー ) " を設定 しておくと、 rl 。 g ⅲの場合はパスワード・チェックなし でリモートマシンにログインできますし、 rcp や rsh コマ ンドも実行できるようになります。 信頼できるホストとユーサーは、システム本で設定す ることも、ユーザーごとに設定することもできます。 システム本で信頼するホストとユーサーを指定するに は、 /etc/hosts. equiv ファイルを用います。フォーマッ トは OS によって彳少に異なりますが、基本的な書き方は 10 FreeBSD では "Permission denied" 、 BSD/OS では、、 Log ⅲ incorrect" というエラーメッセージが表示されるはすです。 117
null ホスト情報の管理とアクセス制御 前回は、ネットワーク上でホストを識別するための仕組 みと、あるホストから送られるデータ ()P バケット ) が どのようにして相手ホストまて届くかについて説明しまし た。さらに、 FreeBSD や BSD/OS での具イ勺な設定方 法を紹介しましたが、これらの設定はローカルホスト自身 に関するものです。人間の世界になぞらえると、自分の名 前 ( ホスト名 ) と電話番号 ()P アドレス ) が明らかになっ たようなものです。 しかし、電話をかけるには、相手の電話番号を正しく把 握していなけれはなりません。番号を知らなけれは電話を かけられませんし、番号を間違うと「おかけになった電 話番号は現在使われておりません」と冷たくあしらわれた り、「どこにかけとんしや、ポケ ! 」と怒鳴られたりします。 現実の世界では、イ万録に名前や電話番号などを言当求し ておき、必要なときにそれを見て名前から電話番号を確か めます。同しことが、コンピュータ・ネットワークの世界 についてもいえます。前回お話ししたように、 IP バケッ トを送るためには相手ホストの IP アドレスが必要です。 しかしはとんどの場合、ユーザーが telnet や rlogin など のネットワーク・コマンドを実行する際、コマンドの引数 として指定するのは相手のホスト名です。したがって、相 手のホスト名と IP アドレスを対応つ、ける、、住所録 " のよ うな仕組みか必要となります。 そこで今回は、ホスト情報 ( ホスト名と IP アドレス ) を管理するための仕組みを紹介します。ホスト情報の管理 ガ去はいくつかありますが、これらについて簡単に触れた あと、実際の設定去を説明します。 また、ホストをネットワークに接続して利用する場合、 あるホストカ甘是供するサービスや、サービスを利用できる ホストを限定したいことがあります。厳密なアクセス制 110 御では、暗号を用いた認証のような特別な機構が必要で すが、 こでは相手ホストのホスト名や IP アドレスを べースとした、単純なアクセス制御の去と設定も紹介し ます。 ホスト情報の管理 前回説明したように、ホスト名はドメイン名と組み合わ せる (FQDN) ことにより、ネットワークに接続されたホ ストを一意に特定できます。一方、 IP アドレスは ( サプ ネットも含む ) ネットワーク番号とホスト番号から構成さ 両者を用いてネットワーク上のホストを一意に特定し ます。 IP アドレスとホスト名 (FQDN) は独立した概念なの で、そのままではホスト名から IP アドレス ( あるいはそ の逆 ) を知ることはできません。これらを対応づけるには、 、、イ形のような対応表が必要になります。 、、ホスト情報の管理 " とは、対応表であるデータベースを 正しく管理することを意味します。ネットワークに対して 新たなホストを接続する場合は、データベースに新しいェ ントリ ( ホスト名と IP アドレスの繝を追加しなけれは なりませんし、ホスト名あるいは IP アドレスを変更した り、ホストをネットワークから外す場合 1 にも、エントリ の変更や削除などの作業が必要です。 前回は IP バケットを相手に送り届けるための仕組み ( 糸響翻のを紹介しましたが、いくら糸響各制御の設定が 正しくても、このデータベースカ墹違っていれは正しい相 手と通信できません。したがって、ホスト名と IP アドレ 1 嵂章やメンテナンスなどで一印判勺にネットワークに孑Æできない場合を除 きます。 UNIX MAGAZINE 1999.1
連載 / UN Ⅸの玉手箱ー① 以下のとおりです。 118 あわせて紹介する予定です。 14 ネットグルーフ。の設定力 1 去については、次可に NIS サーバーの言置と し、何も指定しなかった場合と同しように扱われます。 13 ホスト名やユーサー名の前に、十 " を指定した場合は信頼することを意未 は /root) の下に銜主する、 . rhosts" ファイルを作成します。 は、 root のホーム・ディレクトリ (FreeBSD や BSD/OS の場合 設疋は適用されません。 root の権限で r コマンドを実行したい場合 12 ただし、スーパーユーサー (root) については /etc/hosts. equiv の 合、こクのようにホスト名だけを指定することかできます。 を指定します。ただし、ホスト名だけでそのホストにアクセス可能な場 11 通常、、イ頁するホスト名 " の部分には FQDN あるいは IP アドレス . rhosts というファイルを作成しておくと、ユーザーごと よは、しますが、各ューザーのホーム・ディレクトリに /etc/hosts. equiv の設定はシステム全体に影響をお 、、@ネットグループ名 " を指定します 14 ループを指定する場合は、ホスト名やユーサー名の部分に やユーサー名の前に ーを付けます 13 。一方、ネットグ 信頼しないホストやユーザーを指定するには、ホスト名 のグループをまとめて扱えます。 ネットグループを指定することにより、ホストやユーザー いユーサーを指定できるはか、ホストやユーサーの部分に ーマットカ去張されており、信頼しないホストと信頼しな さらに、 FreeBSD の場合は /etc/hosts. equiv のフォ 限で ) r コマンドを実行することができます。 うューサーだけが、 nullpc に対して ( ューザー null の権 と己すると、 (FreeBSD の場合は ) mypc の null とい mypc Ⅱ u11 ば nullpc の /etc/hosts. equiv に、さきほどの例の代わ たホストの指定したユーサーだけを信頼します。たとえ で区切って ) 信頼するユーザー名を指定すると、指定し 一方、信頼するホスト名のあとに ( 空白あるいはタブ 行できるようになります 12 ューサー名が一致する場合のみ、 r コマンドが無条件で実 されます 11 。すると、ローカルホストとリモートホストの という行を書いておくと、 mypc は信頼するホストとみな mYPC であったとしましよう。 nullpc の /etc/hosts. equiv に pc" 、 r コマンドの対象であるリモートホストが、、 nullpc" こで、 r コマンドを実行するローカルホストが、、 my- 信頼するホスト名 [ 信頼するユーサー名 ] に信頼するホストとユーザーを設定することができます。 ~/. rhosts のフォーマットは /etc/hosts. equiv と同しで す。たとえは、 nullpc というホストの null というユー ザーのホーム・ディレクトリに . rhosts ファイルを作成 し、以下のように言当したとしましよう。 mypc somepc nil すると、 mypc のユーサ、一 null と、 somepc のユー サーⅲ 1 は、 nullpc に対してユーサー null の権限で r コ マンドを実行することができます。 2 番目の書き方は、自 うゞもっているアカウントのユーサー名がホストごとに異 なる場合のてす 15 hosts. equiv と . rhosts についてのラも hosts. equiv と . rhosts を使う場合には注意が必要で す。あるユーザーのアカウントカ坏正に使われている場 合、 hosts. equiv や . rhosts で信頼するホストやユーザー として設定していると、そのホストやはかのユーサーか不 正に利用される危険があるからです。したがって、理想 的にはこれらのファイルを使わないはうがいいでしよう。 しかし、現実にはそうもいきません。たとえは、部門内 の LAN などで複数のホストか緊密に関係している場合で す。信頼するホストやユーサーは、 LAN の内部 ( 糸内 ) のホストやユーザーにとどめるべきです。他サイトのホス トを記するのは、まるで、、どうぞ侵入してください " と いわんはかりの行為です。 hosts. equiv ファイルは、ある部門内の LAN に接続 されたホストがあり、これらを統一的に管理するシステム 管理者がいる場合には有効でしよう。 逆に、 1 人に 1 台以 E の UNIX マシンカリり当てられ ており、それらのマシンが LAN に接続され、各ューサー の管理に任されている状況では、 hosts. equiv ファイルで はなく、各ューサーの ~/. rhosts ファイルを使うほうがま だましです。 hosts. equiv や . rhosts には便利な一面もありますが、 設定や管理の形態によってはセキュリティのレベルを一 - ドげ ることにつながります。これらのファイルを使う場合は、 十分に注意してください。 15 ただし、 somepc のユーサー nil が r コマンドを夫行する場合、たと えば "rlogin -l null nullpc" のようにユーサー null の限で実行 することを明示しなけれはなりません。 UNIX MAGAZINE 1999.1
スのデータベースを正しく管理することは、ネットワーク 環竟でホストを利用するためのもっとも基本的な設定であ るといえます。 ローカル管理とリモート管理 ホスト名と IP アドレスのデータベースを管理するには いくっかのガ去がありますが、いずれの去であ最終 的にはホストやネットワークの管理者が手作業で糸財寺する ことになります。データベースを誰 ( どのホスト ) がもつ かによって、管理ガ去は以下の 2 つに大きく分かれます。 連載 / IJN Ⅸの玉手箱ー① 前者を、、ローカル管理 " 、後者を ・特定のホスト ( サー。ー ) がデータベースをもち、残り すべてのホストがローカルにデータベースをもつガ去 、、リモート管理 " と呼ぶことにします。 こでは便宜的に のホストはサーバーに間い合わせる・去 UNIX MAGAZINE 1999 ユ hosts) というファイルか 1 司凵齬リをもっています。 トールされているディレクトリ *hosts" ( たとえ tiC:*Windows* 2 Windows 95 / 98 や Windows NT では、、、 Windows カゞインス NIS のサーバーにはマスターとスレープの 2 不頁があり NIS は、 1 つのサーバーでデータベースを管理します。 情報を得るため、データベースをもつ必がありません。 トは、必要なときにサーバーに間い合わせることによって データベースを特定のサーバーカ理します。クライアン テムでは、図 l-b のように、ホスト名と IP アドレスの (Domain Name System) が代表的です。これらのシス で、 NIS (Network lnformation Service) や DNS そこで考案されたのがリモート管理に分類される方法 NIS と DNS スか起こる可能生も高くなります。 新の手間も増え、更新を忘れたり登録を間違うといったミ はそれでもよかったのですが、ホストの台数に比例して更 した。ネットワークに接続されるホストの数が少ないうち ホストがもつデータベースを更新しなければなりませんで はこのガ去しかなく、ホスト情報に変更があった場合は全 UNIX マシンでネットワーク竟を構築し始めた当初 します 2 。 では、 /etc/hosts というファイルがデータベースに相当 れたホストすべてがデータベースをもつ去です。 UNIX ローカル管理は図 1 ー a のように、ネットワークに接続さ 図 1 ホスト情報データベースの里 ( a ) ローカル管理 ホスト情報 データベース ロ ホスト情報 データベース ( b ) リモート管理 サーバー ロ アータベース 問合せ 応答 クライアント ロ ホスト情報 データベース データベース ロ ロ クライアント クライアント ますが、スレープはマスターがもつオリジナルデータのコ ピーをもっているサーバーであり、マスターか利用できな いときの代替サー ーとして機能します。 NIS を階層的 な管理が - 可能なように拡張した NIS 十というシステムも あり、 SoIaris などてイ吏用されています。 これに対し、 DNS は管理範囲ごとにサーバーを置き、 その管理範川内の情報をデータベースて管理します。クラ イアントはつねに管理範囲内のサーバーに対して問合をを おこないますが、管理乖観月外のホストに関す引帯にを知り たい場合は、そのサーバーが別のサーバーに対して問い合 わせて結果をクライアントに返します。 いすれの場合も、サーバーのもっデータベースは管理 者が手竹喋て財寺しなけれはなりません。しかし、データ べースはサーバーて集中的に管理されているため、ローカ ル管理にくらべてイ 1 喋の負担はかなり軽減されます。さら に、 NIS や DNS ではホスト名と IP アドレス以外の情報 を管理してクライアントに提供できます。たとえば、 NIS は前々回に紹介したパスワード情報やグループ情報をはし めとするさまざまな情報を扱うことができ、 DNS はそれ ぞれの管理範囲にあるメールサーバーなどの情報を提供す 111
連載 UN Ⅸの玉手箱ー① ることができます。 このように書くと、リモート管理はいいことすくめの 112 にホスト名を指定すれば大丈夫です。正式なホスト名のあ ワークでドメイン名を付けすに運用している場合は、たん ト名とは FQDN を意味しますが、プライベートなネット フ ) で区切って正式なホスト名を記します。正式なホス 最初にホストの IP アドレスを書き、空白 ( あるいはタ IP アドレス正式なホスト名 [ 別名 ] [ 別名 ] 指定します ( 、、 # " 以降はコメントとみなされます ) 。 レスの組を以下のようなフォーマットで 1 行に 1 組すっ べースです。中身はテキスト形式で、ホスト名と IP アド スト名と IP アドレスの対応つ、けをおこなうためのデータ /etc/hosts はすべての UNIX マシンがもっており、ホ /etc/hosts ための設定を紹介します。 して利用する際の設定と、これらを組み合わせて利用する NIS および DNS のそれぞれについて、クライアントと 以降では、ローカルなデータベース (/etc/hosts) と ネットワークの運用をとりあえすは続けられます。 おけは、これらのサーバーか利用できなくなったときも、 各クライアントのデータベース (/etc/hosts) に登録して トワーク内のファイルサーバーやメールサーバーなど ) を ることができます。さらに、必要最小限の情報 ( 組織ネッ は DNS サーバーに間い合わせるといったように使い分け NIS サーバーを利用し、そこで情幸ゞみつからないときに したがって、細織ネットワーク内の清報を参照するには 理することを目指したシステムです。 ノヾ 一群がインターネット本のホスト情報をうまく分散管 バーが他のサーバーと協調することにより、これらのサー テムです。一方の DNS は、各管理範囲に設けられたサー 囲でさまざまな情報を集中管理するために考案されたシス NIS はもともと、系内ネットワークなど限られた範 ー引勺です。 それぞオしの特徴を活かすように組み合わせて利用するのが したがって、これらのガ去は排他的に使うのではなく、 でダウンしてしまうと情報か得られなくなります。 め、 ( イサーバーも含めて ) サーバーがなんらかの理由 クライアントは情報を管理するサーバーに依存しているた ようにみえますが、問題もあります。リモート管理では、 とには、複数の別名 (alias) を指定できます。正式なホス ト名として FQDN を指定した場合は、 1 番目の別名とし てホスト名を与えるのが一搬的です。 /etc/hosts の例を以下に示します。 127 . 0 . 0 . 1 localhost 192 .168.1.10 mypc. f00. co ・ JP mypc 192.168.1.11 nullpc . f00. co ・ jp nullpc fs 192.168.1.15 somepc . f00. co. jp somepc 最初の行にある、、 127.0.0.1 " という IP アドレスには、 、、 localhost" というホスト名か割り当てられています。 れは自分自身を示す IP アドレスで、マシン内のプロセス どうしがネットワーク通信をおこなう際に利用されます。 FreeBSD や BSD/OS も含め、ほとんどの UNIX マシ ンでは最初からこのエントリか定義されています。 こでは 2 行目以降カ噺たに追加したエントリで、たと えは 3 行目は、、 192.168.1.10 " という IP アドレスに対し て、、 mypc. foo ・ co. jp' という FQDN を割り当て、さらに mypc " という別名を割り当てています。 ューザーが telnet などのコマンドの引数に、、 mypc" を えた場合、マシンは /etc/hosts を最初の行から順に検 索し、マッチした行の IP アドレス ( ここでは 192.168.1. 10 ) を使ってアクセスをおこないます。正式なホスト名と して FQDN (mypc. foo ・ co. (p) を指定した場合、ホスト 名を別名として登録しておかないと、ホスト名のみ (my- (c) をコマンドの引数として与・えても検索は失敗すること に注意してください。 さらに、 4 行目の nullpc には、、 fs " という別名か設定し てあります。 nu Ⅱ pc がファイルサーバーであるとすると、 このような別名を各ホストの /etc/hosts に設疋しておけ ば、 fs (file server) というホスト名でファイルサーバー にアクセスでき、提供しているサービスをホスト名から連 想しやすくなる利点があります。 大規模な糸では、 NIS や DNS を使えることが多いの で、 /etc/hosts は OS をインストールしたときのままで 運用できるケースも多いようです。しかし、 NIS や DNS が一一日判勺に使えなくなるような事態に備え、メールサー ーやファイルサーバーといった重要なホストをはしめ、頻 繁に通信をおこなうホストは /etc/hosts に登録しておく といいでしよう。ただし、情報に変更があった場合は速 やかに /etc/hosts に反映させるのをお忘れなく。 UNIX MAGAZINE 1999.1
DAEM 〇 NS & DRAG NS 0 サプネットの適刀な構成法 •William LeFebvre アドレス空間を有効利用するため、 IP ネットワーク を複数のサプネットに分割する手法がよく利用されてい る。しかし、サプネットの彳難リを誤解していると、設引、 を誤って混乱を招く可能性がある。また、クラスレスな 糸子路制御方式 (CIDR: CIassIess Inter-Domain Rout- ing) の出現もこの問題を複雑にしている。今回は、伝 統的なサプネットの構成法とその制約事項を紹介したあ と、クラスレスな辛各制御によってサプネットのルール がどのように変わるかを考察する。 IP アドレスに詳しい人であれは、クラス A 、 B 、 C と いう 3 つのアドレスクラスをご存しだろう。それぞれの クラスは、アドレスのネットワーク部とホスト部の境界 が異なる。各クラスの境界は図 1 のようになっている。 バケットが、ローカルではないネットワーク (nonlocal network) 1 に送られる場合は、経路に対するすべての判 断はアドレスのネットワーク部だけをもとにしておこな われる。 IANA (lnternet Assigned Numbers Authority) は、 IP ネットワークのネットワーク番号の発行権限を InterNIC に委譲している。ある組織がネットワーク ( ネットワーク番号 ) をケえられると、ネットワークの アドレスをさらに分割してサプネットを構成することが できる 2 。 内部ネットワークを設言 1 するときは、はしめにサプネ 1 、 distant network" と呼ぶこともある ( 訳注 : 本文では、リモート・ ネットワーク " と呼」 : ) 。 2 訳注 : 現状では、内部ネットワークにはプライベート・アドレ ス ( 10.0.0.0 ~ 10.255.255.255 / 8 、 172.16.0.0 ~ 172.31.255. 255 / 12 、 192.168.0.0 ~ 192.168.255.255 / 16 ) を使い、割り当て られたネットワーク番号 ( グローバル・アドレス ) はファイアウォー ルの外側のホストだけに使うのが一 -- 勺である。 UNIX MAGAZINE 1999.1 from UNIX REVI. EW 図 1 IP アドレスのクラス 31 クラス A クラス B クラス C 133 ネットワーク部 ネットワーク部 ネットワーク部 170 6 ( 例 ) ホスト部 ホスト部 ホスト部 ット番号とホスト番号の境界を決めなければならない。 この作業をすることで、 2 つの部分から構成されていた アドレスは、ネットワーク部とサプネット部、ホスト部 の 3 つに分割されることになる。選択した境界はサプ ネットマスクとして表現され、通常は 10 進数をドット で区切った表記が用いられる。値が 1 のビットは、アド レスのネットワーク部かサプネット部に対応する。たと えば、 255.255.255.0 は標準的なクラス C のネットマ スクに相当する。 255.255.255.224 の場合は、最後のオ クテットの 3 ピット目が境界で、残りの 5 ビットがア ドレスのホスト部になる。 サプネットの境界か決まったら、内部ネットワークの それぞれにサプネット番号を割り当てる。ホストのアド レスは各サプネット内で割り当てることができる。この 時点で、 2 つのホストアドレスが予約されていることに 注意してほしい。ホストアドレスが 0 の場合は物理ネッ トワーク物本を表し、ホストアドレスのピットがすべて 1 の場合はプロードキャスト・アドレスになる。 あるサイトが 133.170.0.0 というクラス B のネット ワーク番号を割り当てられているとしよう ( 図 2 ) 。ネッ トワークの設言としては、アドレスの 3 番目のオクテッ 105
コミュニケーション用 サーバーの インストールと運用 0 小山洋一 sendma ⅱを用いたメール配送系の構築 大学の友人やクラブの後輩たちと話していると、電子 メールの設疋についての相談を受けることがときどきあり ます。当然ながら口頭で説明するのですが、そのときに 、 CF" を「シーエフ」と翫んでしまうと、、 sendmail.cf と区別がつかないので、どう読むべきか毎回・悩みます。「大 文字のはうのシーエフ」とか「ツールのほうのシーエフ」 のように表現することが多かったのですが、どうも冗長な ので、いい言い方はないものか思案中です。 sendmail.cf のほうは略さすに「センドメール・シーエフ」と言えばい いので、こっちは簡単なのですが・ 今回は、 sendmail を用いたメールシステムの構築につ いて、実際の運用形態に即した設定例を紹介します。 ホストの構成を考える メールシステムの構築は、 Web サーバーの立ち上げな どにくらべて難しい場合が多いようです。その理由とし ーはホスト単体で運用できるのに対し、 て、 Web サー メールシステムの構築はサイト内のホストをすべて有機的 に結びつける作業で、各ホストを単体で考えるだけでは適 切な解か導けないということがあります。 UNIX 系の OS を運用する場合、各ホストは、直接メー ルの受信はできなくても、発信だけはできるようにしてお く必があります。ですから、サイト内に新規のホストを 導入するたびに設定が必要になりますが、その際に手間が 多くかかるような運用形態は避けたいところです。 そこで、基本的には次のような形態にします。 1. サイト内のメールスプールのホストを 1 台に絞る。その ホストで POP サーバーを動かしておけは、他のホスト 上の MUA でメールを受け取ることもできる。 34 2. 他のホストは、ほとんど何もせすにスプールホスト一云 送するだけの設定にする。これにより、サイトの運用形 態が多少変化しても、設定の変更はイ腰となる。 これについては 11 月号て紹介しました。今回はそのノヾ リエーションを考えてみます。 こでは、 sendmail のバージョンは 8.9 以降を用いる こととし、 CF-TYPE には R8V8 または R8V8-nuII を 指定します。ただし、バージョン 8.8 以降ならばここて解 説する機能はすべて備えているので、 sendmail-8.8. x を 利用してもかまいません。その場合は、 CF-TYPE の指 定をそれぞれ R8V7 、 R8V7-null に読み替えてください。 掲載したリストは Standards/sendmail-v8. def (CF- TYPE=R8V8 の場合 ) または Standards/nuII-v8. def (CF-TYPE=R8V8-nuII の場合 ) をベースにして、変更 の必要な行のみを抜き出したものです。変数名の出現頂序 は、これらのファイルに合わせています。 実際にサイトを構築するときは、リストに掲載した部分 だけを使って def ファイルを作成してもかまいません。 しかし、その他の設定変更をおこなう場合にも便利なよう に、上記のファイルをコピーしてそれをベースに編集する ことをお勧めします。 また、 OS-TYPE としては bsd4.4 (FreeBSD などが 該当 ) を指定していますが、これは使用している OS に合 わせて設正してください。 ハプホストの利用 サイト内のユーザー数やホスト数などが増加してくる と、サイトの内部をさらに複数のサブドメインに分けて運 用したくなります。たとえば、ある大学において、最初は UNIX MAGAZINE 1999.1
コードの言当をサポる目的で用いることはできません。 般に、防火壁内部のホスト構成を完全に隠したいといった 事がないかぎり使うべきではないでしよう。 ハプホスト構築の利点 ( セキュリティの確保 ) ところで、外部からのメールはハプホストが受信し、そ のあとでスフ。ールホストに中幻医されるので、スフ。ールホス ト自体は外部からのメールを直接受け取れなくてもかまい ません 3 。つまり、 MX として外部に公開するホストと、 メールスフ。ールをもつホストを区男けることができます。 メールスフールをもつホストは、ユーサーのメールとい う機密清報や、 POP のパスワードのデータベースなどを ー尉寺しているはすなので、防火壁内部に隠して外部からの 攻撃を受けにくくしたいところです。 11 月号で紹介した 単純な構成では、スプールホストが MX を兼ねているた め、これは不可能でした。さきの設定例のように、外部に 公開すべきなのは MX だけであり、スプールホストはか ならすしも公開しなくてもよいという点に着目すれは、サ イトのセキュリティ・レベルを上げることができます。 また、メールの不正リレーに関する間題が発生するの も、内部から外部に送り出す際に j 面茴するホストと、外部 からのメールを受け取るホストか区別されていないためで す。、、送信時の中継専用ホスト " と、、受信専用ホスト " を 独立させてしまえば、前者は外部からの SMTP 接続を受 ける必要はなくなり、後者は自分が受信する以タ ) メール をすべてエラーにしてしまってもよいのです。 具体的に考えてみます。ます、防火壁担当のルータに IP フィルタリングの機能があるなら、スプールホストを 防火壁内に入外部からスプールホストに向けた TCP コネクション確立要求のバケットを落とすようにしておく と、、スプールホストから外部に向かう SMTP 接続は可 能だが逆は不可能 " という状態を作りだせます。 研究室単位で防火壁を設けているような場合、ハプホス トは防火壁外に置くことになるでしようから、ハプホスト からの SMTP コネクション確立要求は通す必要がありま すが、そオ・汐 ) TCP コネクション確立要求はすべて落 としてしまう設定にします。 このようにすると、スプールホストが、、送イ創寺の中継専 3 ただし、研究室ローカルのメーリングリストに外部からメールを送れるよ うにする必があるのなら、このかぎりではありません。 UNIX MAGAZINE 1999 ユ ON 旧 Security ー 0 ′第 CO れ 000gd 0 d 、 機能概要 アプリケーションをそのままサポート。 HTTP 、 FTP 、 SQL*NET 、 Telnet 、 Lotus Notes 等の TCP/IP ・ TCP/IP アプリケーションの変更不要 強力な監査ログ機能と日毎、週毎、月毎の統計機能を装備。 ・ログ記録 データ整合性を MD5 によるハッシュチェックで保持。 ・データの整合性保証 宛先ホスト名、ボート、および U 日 L アドレスでの制御が可能。 ・アクセス制御 56 ビットの DES アルゴリズムを採用。 ・暗号化 ISO 規格の Sma 「 tCa 「 d 、仮想 Sma 「 tCa 「 d をサボート。 ・認証 ン登録で迅速に対応できます。 ークで、問題となるユーザ登録、鍵の配布にもオンライ また、エレクトロニックコマース等の大規模なネットワ ットは、この 1 つのツールで全て OK 。 統合セキュリテイミドルウェアですので、工クストラネ VPN に必要な 5 つのセキュリティ要件をサポートする 暗号化、アクセス制御、データ整合性保証、ログ記録の VPN(VirtuaIP 「 ivate Netwo 「 k ) を構築するツールです。 Sma 「 tGATE は、 1 台 1 台のクライアントを対象とした 優れたコストパフォ - マンス オ - ルインワンバッケ - ジで 総合セキュリテイミドルウェア 工クストラネット時の 5E0 G ー 動作環境 SmartGATE サーバー ・ SOIa 「 is 2.5 以上 SUN OS 4.1. X HP-UX 10.01 以上 ・ BSDI 2.1 WindowsN T ・標準価格 Sma 「 tPass Windows3.1 Windows95 ・ WindowsNT Sma 「 tGATE サーバー (Smart GATE クライアント 1 0 ライセンス付 ) SmartPass (SmartGATE クライアント ) 1 ライセンス SmartPass (SmartGATE クライアント ) 100 ライセンス SmartPass (SmartGATE クライアント ) 1000 ライセンス 価格 148 万円 19 旧 00 円 160 万円 000 万円 ◆住友金属ステム開発楷式会社 ソフトウェアプロダクト部 〒 108-0073 東京都港区三田 3 丁目 1 1 番 36 号 ( 三田日東ダイビル ) FAX. 08-5476-9886 Phone. 03-5476-9825 セキコリテイセミナー好評実施中 ! お問い合わせは sg-info@ssd.co.jp 最新情報は http://www.smisoft.ssd.co.jp に掲載中 ! 資料請求 No. 00A 37
連載 / コミュニケーション用サーパーのインストールと運用ー① 用ホスト " として機能し、ハプホストが外部からのメー ルを受信するための MX ホスト " として機能します。 防火壁内部のホスト ( ノ、プホストを除く ) は外界から遮 断されますから、 sendmail 側でメールの不正リレー対策 をおこなわなくても十分に安全性か確保されます。これ は、 MTA として sendmail 以外のツールを使う場合に も有効な手法だと思われます。 また、複数台のハプホストを用意し、同一の優先度の MX レコードを各ハプホストに向けるようにしておけば、 メール処理の負荷分散ができます。同一の優先度の MX レコードがある場合は、送信側でどれか 1 つが選ばれま す。この際、ハプホストの 1 台がダウンしていても、送信 側か接続の失敗を検出して他の MX レコードを利用して くれますから、障害にも強くなります。 これは、 use@daigaku ・ ac. jp のメールがどのハプホ ストに届いたとしても、、ローカル宛 " として処理するよう な sendmail.cf を作り、それぞれのハプホストに同一の aliases データベースをもたせることで矩見できます。 端末型ダイヤルアッフ境 個人で複数の PC を所有し、家庭内に LAN を構築して いる方も多いでしよう。その場合、外部との接続は個人用 の端末型ダイヤルアップの契約で、 NAT や IP masquer- ade などを利用することが多いのではないでしようか。 この場合、外部との電子メールのやりとりに関しては、 ISP (lnternet Service Provider) の SMTP サーバー や POP サーバーに MUA から直接接続して利用するの が簡単です。しかし、外部と接続していない状態でメール をゆっくり書きたいこともあるでしよう。これは、 MUA が「送信トレイ」のような機能をサポートしていれば簡単 ですが、 UNIX 系の OS で動く MUA では、 sendmail の キュー処理イ冓に頼っている ( つまり、メールを書き終っ た時点で、すぐに MUA から MTA への送信をおこな う ) ものが多いようです。こういった MUA を使う場合、 SMTP サーバーとして ISP 上のホストを用いる設定で は、メールを書き終って送信する際には ISP と接続され /usr/lib/sendmail を起重丿庁る MUA に対応する。 送するように設定 (nuII-v8. def を利用 ) し、送イ訓叔こ ・スプールホスト以汐 ) ホストでは、スフールホストに転 Fr 。 m : などを書き換える。 部に発信する際に、正規のメールアドレスに合わせて 名が付いてしまっても大丈夫なように、 LAN から外 場合、 LAN 内から発信されたメールにそのドメイン ・ LAN のホストに仮のドメイン名を付けて運用している るように設定する。 MUA はメール送イにはそのホストに対して送信す こでは、 LAN 内のホストの IP アドレ にしておく。 はないので、 LAN 内からの接続のみを受け付けるよう ・これらのホストは外部からの SMTP 接続を受ける必要 スは 192.168.0. x の範囲で付けているとする。 ・念のため、 Message-ID は ISP のメールサー けさせることにする。 ーに付 ている必要があります。 そこで、次のような設定例を紹介します。 ・ LAN 内にスプールホストを 1 台準備し、 38 LAN 内の この場合の def ファイルの設定例を、図 6 ~ 7 に示し ファイルを作ります。 コマンドを用いて hash 形式で /etc/ut. 10Ca1. db という 用する設疋をおこなっているので、次のように makern 叩 USERTABLE-MAPS に hash 形式のデータベースを利 式のデータベース・ファイルに変換します。この例では、 というファイルに記述したのち ( 図 8 参照 ) 、通切な形 能を用いて実現しています。この対応表は / etc / ut. 1 。 cal でのメールアドレスへの書奐えを、 CF の usertable の機 す。そして、 LAN 内で用いているユーサー名から ISP サーバー名に従って、 DEFAULT-RELAY を指定しま スプールホストの設定では、契約した ISP の SMTP を SPOOL-HOST として指定します。 spoolhost. private-network. jp のようになります。これ メイン名を付けていたとすると、スプールホストの名前は ます。 LAN 内では private-network. jp といった仮のド makemap コマンドは、 sendmail の配布ノ、ツケージに chmod og—w ut .10Ca1. db chown root ut .10Ca1. db # makemap hash ut .10Ca1. db く ut .10Ca1 cd /etc % /bin/su UNIX MAGAZINE 1999.1 添付されていなければこれを利用してください。 含まれる makemap ディレクトリ以下にあるので、 OS に
Daemons & Dragons ただし、経路テープルをチェックしても、ネットマ てからのことである。 スクの値は表示されない。あるネットワークに対する経 こで、図 3 の H というホストに注目してみよう。こ 路を経路テープルに追加するときは、ホストのインター のホストはネットワーク 133.170.0.0 に直接接続してい フェイスをチェックし、そのネットワークのサプネット ない。ホスト H から送出される 133.170.2.1 宛のバケッ のどれかに直接接続されていないかどうかを調べる。直 トは、明らかにルータ B に送られるべきである。一方、 接接続されていれは、対応するインターフェイスのネッ 133.170.31.1 宛のバケットはルータ C に送られるべき トマスクか習各のネットマスクとして使われる。そうで である。 IP における糸習各制御アルゴリズムによれは、同 ない場合は、そのネットワークはリモート・ネットワー ーのリモート・ネットワークを目的地とするバケットは、 クであると判断され、ネットマスクはアドレスのクラス 基本的にすべて同し糸習各を使って送るという前提になっ ( クラス A 、 B 、 C のいすれか ) に応した値になる。 ている。したがって、ホスト H は 133.170.0.0 / 16 のネ ットワーク物本に対する糸習各を 1 つしかもたない。その いくつかのシステムでは、 /etc/netmasks ファイ ためサプネットを区別できす、間題が発生してしまう。 ルを用いてネットマスクを指定することができる。 さらにこの場合は、ホスト H に対する正しいデフォル のようなシステムでは、 ifconfig のパラメータとし トルータを選ぶことさえ不可能である。以 . E が、サプネ て、、 netmask 十 " を与・えると、ネットワークに対応す ットか隣接していなけれはならない理由である。ホスト るネットマスクを /etc/netmasks から検索する。ファ ルートを使えばむりやりこの構成で運用することもでき イルの書式は単純で、シェルで使われるコメントの記 るが、そのような設定を系財寺しようとしてもすぐに手に 述方法に対応している 4 。ファイルの各行には、 10 進 負えなくなるだろう。 数とドットで表記した 2 つの値をスペースで区切って それでは、図 4 のホスト H はどうだろうか。この場 記述する。最初の値はネットワーク番号 ( アドレスの 合、ホスト H は 133.170.0.0 / 16 に対する単一の糸齧各を ホスト部は 0 で指定 ) で、 2 番目には指定したネット 経路テープルに設定できるので、経路制御はうまく機能 ワークに対するネットマスクを記述する。たとえは、 してバケットが目的地に正しく届く。糸各がすべてのサ 、、 133.170.0.0 255.255.255.0 " という行は、、、ネットワ プネットに対して最適であるとはいえないが、動作する ーク 133.170.0.0 は 24 ヒ、ツトのサプネットマスクを使 ことはたしかである。ホスト H は 133.170.0.0 / 16 のサ ことを意味する。このファイルは NIS データベース つ プネットの分割については認識していないので、ネット に置くこともできる。 ワークのすべてのサプネットに対して最適な経路を用意 他のシステムのなかには、 /etc/networks ファイル するのは不可能である。これは、ネットワークを 3 層構 に記述した仮想的なネットワーク名を使ってネットマ 造で設計したために発生する問題である。クラスレスな スクを指定できるものもある。 /etc/networks ファイ 経路制御をおこなえはこれらの問題は解消されるが、 ルは、通常はネットワーク・アドレスに対して名前を れについては彳刻する。 付けるために利用されている。たとえは、 133.170.0.0 に example-net という名前を付けることが可能である。 UNIX におけるネットマスク はとんどの ifconfig コマンドは、 netmask というパラ メータのあとに名前を指定することができる。名前を指 ネットマスクはネットワーク・インターフェイスに 定すると、 /etc/networks ファイルでネットワークの 割り当てられ、 ifc 。ⅲ g コマンドを使って設定する。イ 名前カ鹸索され、名前に対応する値がネットマスクとし ンターフェイスをセットアップするときは、 IP アドレ て使われる。たとえば、 ifconfig コマンドに、、 netmask スとネットマスクを以下のように指定する ( 誌面の都合 example-mask" と指定すると、 /etc/networks にある 上、で折り返しています ) 。 対応するエントリ、、 example-mask 255.255.255.0 " が # ifconfig 1e0 inet 133.170.1.1 netmask 疇 - 4 つまり、 # で始まる行はコメントとみなされる。 255 . 255.255.0 108 UNIX MAGAZINE 1999.1