ホスト情報の管理とアクセス制御


目次

はじめに
ホスト情報の管理
 ・ローカル管理とリモート管理
 ・NISとDNS
 ・/etc/hosts
 ・NIS
 ・DNS
  ・DNSによる検索の仕組み
  ・クライアントからのDNSの利用
 ・/etc/hostsとNIS、DNSの併用
  ・FreeBSDの/etc/hosts.conf
  ・BSD/OSの/etc/irs.conf
  ・Solarisの/etc/nsswitch.conf
ホストやサービスに対するアクセス制御
 ・信頼するホストの設定
 ・hosts.equivと.rhostsについての注意
 ・サービスに対するアクセス制御
 ・FreeBSDの/etc/inetd.conf

一つ前へ


はじめに

 ホスト情報(ホスト名とIPアドレス)を管理する仕組みについて説明します。
 ホスト情報の管理方法はいくつかありますが、これらについて簡単に触れた後、実際の設定方法を説明します。

ホスト情報の管理

 ホスト名はドメイン名と組み合わせる(FQDN)ことにより、ネットワークに接続されたホストを一意に特定できます。一方IPアドレスは(サブネットを含む)ネットワーク番号とホスト番号から構成され、両者を用いてネットワーク上のホストを一意に特定されます。
 IPアドレとスホスト名(FQDN)は独立した概念なので、そのままではホスト名からIPアドレス(あるいはその逆)を知ることはできません。これらを対応づけるには、"住所録" のような対応表が必要になります。
 "ホスト情報の管理" とは、対応表であるデータベースを正しく管理することを意味します。ネットワークに対して新たなホストを接続する場合は、データベースに新しいエントリ(ホスト名とIPアドレスの組)を追加しなければなりませんし、ホスト名あるいはIPアドレスを変更したり、ホストをネットワークから外す場合にも、エントリーの変更や削除などの作業が必要です。
 IPパケットを相手に送り届ける仕組み(経路制御)で説明していますが、いくら経路制御の設定が正しくても、このデータベースが間違っていれば正しい相手と通信できません。したがって、ホスト名とIPアドレスのデータベースを正しく管理することは、ネットワーク環境でホストを利用するための最も基本的な設定であるといえます。

ローカル管理とリモート管理

 ホスト名とIPアドレスのデータベースを管理するにはいくつかの方法がありますが、いずれの方法であれ、最終的にはホストやネットワークの管理者が手作業で維持することになります。データベースを誰(どのホスト)がもつかによって、管理方法は以下の2つにわかれます。

 ・すべてのホストがローカルにデータベースをもつ方法
 ・特定のホスト(サーバー)がデータベースをもち、残りのホストはサーバーに問い合わせる方法

 ここでは便宜的に、前者を"ローカル管理"、後者を"リモート管理" と呼ぶことにします。
 ローカル管理は、ネットワークに接続されたすべてのホストがデータベースをもつ方法です。UNIXでは、/etc/hosts というファイルがデータベースに相当します(Windows95/98/NT では、"Windowsがインストールされているディレクトリ\hosts" (たとえばC:\windows\hosts)というファイルが同じ役割をもっています )。
 UNIXマシンでネットワーク環境を構築し始めた当初はこの方法しかなく、ホスト情報に変更があった場合は全ホストがもつデータベースを更新しなければなりませんでした。ネットワーク接続されたホストが少ないうちはそれでもよかったのですが、ホスト台数に比例して手間も増え、ミスが起こる可能性も高くなります。

NISとDNS

 そこで考案されたのがリモート管理に分類される方法で、NIS(Network Information Service)や DNS(Domain Name System)が代表的です。これらのシステムでは、ホスト名とIPアドレスのデータベースを特定のサーバが管理します。クライアントは、必要なときにサーバに問い合わせることによって情報を得るため、データベースをもつ必要がありません。
 NISは、1つのサーバでデータベースを管理します。NISのサーバにはマスターとスレーブの2種類がありますが、スレーブはマスターがもつオリジナルデータのコピーをもっているサーバーであり、マスターが利用できない時の代替サーバとして機能します。NISを階層的な管理が可能なように拡張したNIS+というシステムもあり、Solaris などで使用されています。
 これに対し、DNSは管理範囲ごとにサーバを置き、その管理範囲内の情報をデータベースで管理します。クライアントはつねに管理範囲内のサーバに対して問い合わせをおこないますが、管理範囲外のホストに関する情報を知りたい場合は、そのサーバが別のサーバに対して問い合わせて結果をクライアントに返します。
 いずれの場合も、サーバのもつデータベースは管理者が手作業で維持しなければなりません。ローカル管理にくらべて作業の負担はかなり軽減されます。さらに、NISやDNSではホスト名とIPアドレス以外の情報を管理してクライアントに提供できます。たとえば、NISはパスワード情報やグループ情報をはじめとするさまざまな情報を扱うことができ、DNSはそれぞれの管理範囲にあるメールサーバなどの情報を提供することができます。
 リモート管理の欠点は、クライアントは情報を管理するサーバに依存しているため、サーバがなんらかの理由でダウンしてしまうと情報が得られなくなります。
 したがって、これらの方法は排他的に使うのではなく、それぞれの特徴を活かすように組み合わせて利用するのが一般的です。
 NISはもともと、組織内ネットワークなど限られた範囲でさまざまな情報を集中管理するために考案されたシステムです。一方のDNSは、各管理範囲に設けられたサーバが他のサーバと協調することにより、これらのサーバ群がインターネット全体のホスト情報うまく分散管理することを目指したシステムです。
 したがって、組織ネットワーク内の情報を参照するにはNISサーバを利用し、そこで情報がみつからないときにはDNSサーバに問い合わせるといったように使い分けることができます。さらに、必要最小限の情報(組織ネットワーク内のファイルサーバやメールサーバなど)を各クライアントのデータベース(/etc/hosts)に登録しておけば、これらのサーバが利用できなくなったときも、ネットワークの運用をとりあえずは続けられます。
 以降では、ローカルなデータベース(/etc/hosts)とNISおよびDNSのそれぞれについて、クライアントとして利用する際の設定と、これらを組み合わせて利用するための設定を紹介します。

/etc/hosts

 /etc/hosts はすべてのUNIX(Windows)マシンがもっており、ホスト名とIPアドレスの対応づけをおこなうためのデータベースです。中身はテキスト形式で、ホスト名とIPアドレスの組を以下のようなフォーマットで1行に1組ずつ指定します("#" 以降はコメントとみなされます)。

 IPアドレス 正式なホスト名[別名][別名]...

 最初にホストのIPアドレスを書き、空白(あるいはタブ)で区切って正式なホスト名を記述します。正式なホスト名とはFQDNを意味しますが、プライベートなネットワークでドメイン名を付けずに運用している場合は、たんにホスト名を指定すれば大丈夫です。正式なホスト名のあとには、複数の別名(alias) を指定できます。正式なホスト名としてFQDNを指定した場合は、1番目の別名としてホスト名を与えるのが一般的です。
 /etc/hosts の例を以下に示します。

127.0.0.1 localhost
#
192.168.1.10 mypc.foo.co.jp mypc
192.168.1.11 nullpc.foo.co.jp nullpc fs
192.168.1.15 somepc.foo.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.jp)を指定した場合、ホスト名を別名として登録しておかないと、ホスト名のみ(mypc)をコマンドの引数として与えても検索は失敗することに注意してください。
 さらに、4行目の nullpc には "fs" という別名が設定してあります。nullpc がファイルサーバであるとすると、このような別名を各ホストの /etc/hosts に設定しておけば、fs(file server)というホスト名でファイルサーバにアクセスでき、提供しているサービスをホスト名から連想しやすくなる利点があります。
 大規模な組織では、NISやDNSを使えることが多いので、/etc/hosts はOSをインストールしたときのままで運用できるケースも多いようです。しかし、NISやDNSが一時的に使えなくなるような事態に備え、メールサーバやファイルサーバといった重要なホストをはじめ、頻繁に通信をおこなうホストは /etc/hosts に登録しておくといいでしょう。ただし、情報に変更があった場合は速やかに /etc/hosts に反映させるのをお忘れなく。

NIS

 NISの概要とNISクライアントのセットアップについては、UNIXマガジン1998年11月号(UNIXの玉手箱)に紹介されています。
 あるホストをNISクライアントとして利用する場合、NISドメイン名を設定して ypbind デーモンを起動すれば、NISサーバからホスト情報を得ることができます。
 NISサーバでは、ホスト情報は hosts.bynamehosts.byaddr というマップで管理されます。前者はホスト名をキーとしてIPアドレスを管理検索するためのマップで、後者はIPアドレスをキーとしてホスト名を得るためのマップです。hosts.byname マップは、"hosts" という名前で指定できるようになっています。
 ypbind が正常に動いていれば、ypcat コマンドで hosts マップの一覧を表示したり、ypmatch コマンドで特定のホスト情報を検索することができます。

bash$ ypcat hosts
192.168.1.10 mypc.foo.co.jp mypc
192.168.1.11 nullpc.foo.co.jp nullpc fs
192.168.1.15 somepc.foo.co.jp somepc
       ・
       ・
bash$ ypmatch somepc hosts
192.168.1.15 somepc.foo.co.jp somepc
bash$ ypmatch 192.160.1.11 hosts.byaddr
192.168.1.11 nullpc.foo.co.jp nullpc fs
bash$ ■

 ただし、NISクライアントとしてセットアップしただけの状態では、NISサーバからの hosts マップの参照はできますが、telnet や rlogin などのネットワーク・コマンドを実行する際、ホスト名からIPアドレスへの変換はおこなわれません。
 実際に他のホストにアクセスする際に、ホスト名からIPアドレス(あるいはその逆)を得るための情報源としてNISを利用するには、NISを使うことをマシンに教えてやらなければなりません。旧いOSでホスト名とIPアドレスの変換にNISを使うには、変換をおこなうC言語のライブラリ関数をNIS対応のものに入れ替える必要がありました(具体的には、gethostbyname()などのライブラリ関数を指します)。
 これに対して、FreeBSD や BSD/OS では、情報源として /etc/hosts、NIS、DNSのどれを利用するかといったことや、複数の情報源を併用する場合の優先順位を設定ファイルで指定できるようになっています。具体的な設定方法についてはDNSのあとに紹介するので、NISのホスト情報を利用する場合はそちらを参照し、適切に設定してください。
 なお、FreeBSD マシンをNISサーバとして設定する方法については、別項で説明します。
 BSD/OSには、残念ながらNISサーバに必要なデーモン・プログラム(ypserv)などが付属していません。

DNS

 DNSはホスト情報をインターネット全体で分散管理することを目指し、米国のインターネットの前身であるARPA-NET で開発されたシステムです。DNS自体はサーバの構成や問い合わせなどのプロトコルを定めた"仕様"であり、RFC1034やRFC1035などで規定されています。
 DNSの仕様にもとづき、カリフォルニア大学バークレイ校が実装したサーバなどのプログラム群がBIND(Berkeley Internet Name Domain)と呼ばれるパッケージで、BSD系のUNIXのみならず、多くのUNIXで使われています。
 DNSの仕組みやプロトコルの詳細については、UNIXマガジン「Communication Notes-BINDによる名前管理(1)〜(5)」、「UNIX知恵袋ーネームサーバー(1)〜(4)」が参考になります。
 あるDNSサーバが管理するネットワークの範囲はゾーン(zone)と呼ばれます。ゾーンはDNSサーバが属するドメインに対応する場合もありますし、そのドメインに加えて(複数の)下位ドメインも含む場合もあります。ここでいうドメインとは、FQDNのドメイン名が示すドメインと同じで、UNIXのファイルシステムのようにツリー状の階層構造をもちます。
 ツリーの頂点は”ルートドメイン”と呼ばれ、ルートドメインの直下は国などを表すドメインで構成されます。たとえば、日本であれば "jp"、英国であれば "uk" などとなっています。
 国を表すドメインの下は組織の種類や地域を表すドメインで構成され、jpドメイン(日本)の場合、企業を表す "co" ドメイン、大学などを表す "ac" ドメインなどがあります。これらのドメインの下は、個々の組織を表すドメインで構成されます。例えばNTTであれば、 "ntt.co.jp" というドメインが割り当てられており、「日本の企業であるNTTという組織」であることを表します。(jpドメインの下にどのようなサブドメインがあるかは、JPNICのホームページ(http://www.nic.ad.jp/)で見れます)
 大雑把にいうと、DNSでは、これらのドメインごとにDNSサーバを置き、あるドメインのDNSサーバはそのドメインに属するホストのホスト名とIPアドレスを管理します。さらに、DNSサーバは自分のドメインと直接関係する下位ドメインのDNSサーバに関する情報ももっています。

DNSによる検索の仕組み

 たとえば,上図のようなドメイン構成を考えてみましょう。co.jp ドメインの下に、ntt.co.jp および foo.co.jp という2つのサブドメインがあります。
 ここで、foo.co.jp に属するホスト(クライアント)がホスト "east.ntt.co.jp" のIPアドレスを検索する場合、大まかな手順は以下のようになります。

1.クライアントは自分のドメイン "foo.co.jp" のDNSサーバに対し、"east.ntt.co.jp" というホストのIPアドレスを問い合わせる。

2.foo.co.jp のDNSサーバは、問い合わせの対象となるホスト名から ntt.co.jp というドメイン名を得る。このドメインは自分のドメインとは異なり、しかも自分の下位ドメインでもないので、ルートドメインのDNSサーバに対して「ntt.co.jp ドメインのDNSサーバは誰か」という問い合わせをおこなう。ルートドメインは下位にjpドメインをもつので、jpドメインのDNSサーバに同様の問い合わせをおこなう。

3.2の問い合わせをルートから下位ドメインの方向へ再帰的に繰り返し、やがて co.jp ドメインのDNSサーバにたどり着く。co.jp ドメインは ntt.co.jp を下位ドメインにもつため、ntt.co.jp のDNSサーバが判明する。

4.foo.co.jp のDNSサーバは、ntt.co.jp のDNSサーバに対し、"east.ntt.co.jp" というホストのIPアドレスを問い合わせる。

5.ntt.co.jp のDNSサーバは、自分のデータベースを検索し、結果を foo.co.jp のDNSサーバに返す。

6.foo.co.jp のDNSサーバは、問い合わせをおこなったクライアントに対して結果を返す。

 このように、クライアントは自分と同じドメインのDNSサーバさえ知っていればよく、問い合わせに応じてDNSサーバどうしが通信をおこなうことにより、インターネット上のホスト情報を入手できます。したがって、クライアントからは同じドメインのDNSサーバが、インターネットに接続されたすべてのホスト情報管理する巨大なデータベースをもっているようにみえます。なお、問い合わせの結果はDNSサーバにキャッシュの有効期間内に同じホストに対する問い合わせが発生すると、キャッシュにある情報が利用されます。

クライアントからのDNSの利用

 クライアントとしてDNSを利用したい場合は /etc/resolv.conf ファイルで設定をおこないます。/etc/resolv.conf はテキスト形式ファイルで、空白またはタブで区切られたキーワードと値の組を1行に1つずつ書きます(キーワードは行の先頭から書かなくてはなりません。また、"#" 以降はコメントとみなされます)。FreeBSD と BSD/OS、Solaris の場合、以下に挙げる3種類のキーワードがあります。

nameserver
 値として、問合せをおこなう DNS サーバのIPアドレスをドット表記で指定します。組織によっては、DNSサーバにかかる負荷を分散させたり、あるサーバがダウンしたときにも他のサーバが処理を代行できるよう、同じドメイン内に複数のDNSサーバを置いていることがあります。複数のDNSサーバを利用したい場合は、nameserver キーワードを用いてそれぞれのDNSサーバのIPアドレスを1つずつ指定します(FreeBSDとSolarisでは、最大3つのDNSサーバを指定することができます。この場合、/etc/resolv.conf にかかれた順番に従ってDNSサーバに問い合わせます)。なお、/etc/resolv.conf に nameserver というキーワードが書かれていないと、ローカルホストがDNSサーバとみなされます。

domain
 値として、クライアントが属するドメイン名(ローカルドメイン)を与えます。domain キーワードを設定しておくと、問い合わせにホスト名のみを用いた場合、ローカルドメインのホストが検索の対象となります。domain キーワードを省略すると、hostname コマンドで与えたホスト名(FQDN)に含まれるドメイン名がローカルドメインとして扱われます。このホスト名にドメイン名が含まれない場合は、問い合わせの対象となるホストはルートドメインに属するものとみなされ、ルートドメインのDNSサーバに問い合わせがおこなわれるので注意が必要です。

serch
 通常、問い合わせの対称となるホストをFQDNではなくホスト名のみで与えられた場合、ホストの検索は domain キーワードで得られるドメイン(ローカルドメイン)に対しておこなわれます。
 これに対し、search キーワードの値としてドメインのリストを指定すると(最大6つ(全体で256文字以下)のドメインをスペースで区切って指定できます)、指定されたドメインが順番に検索されます。当然、ドメインがローカルドメインでない場合は検索に時間がかかるため、通常は指定しないほうがいいでしょう。
 たとえば、foo.co.jp のDNSサーバのIPアドレスが 192.168.1.2 である場合、このドメインに属するクライアントの /etc/resolv.conf は以下のようになります。

domain foo.co.jp
nameserver 192.168.1.2 # ns.foo.co.jp

 FreeBSDの場合、OSのインストール時にDNSクライアントの設定をしていなければ、/etc/resolv.conf ファイルは作成されません。このような場合はエディタなどを使って新たに作成する必要があります。BSD/OS と Solaris の場合も同様に、/etc/resolv.conf ファイルを新たに作成します。

/etc/hostsとNIS、DNSの併用

 ホスト名とIPアドレスを管理する仕組みとして、ローカルな /etc/hosts とNISおよびDNSの3つを紹介したが、これらを組み合わせれば、相互補完的に利用することができます。
 最近のUNIXは、どの情報源をどの順番で検索するかを指定でき、FreeBSD は /etc/host.conf、BSD/OS は /etc/irs.conf、Solaris は /etc/nsswitch.conf というファイルを使って設定します。

FreeBSDの/etc/hosts.conf

 FreeBSDが利用する /etc/hosts.conf ファイルは単純で、/etc/hosts は "hosts"、NISは "nis" 、DNSは "bind" というキーワードに対応しています。これらのキーワードを使い、利用したい情報源を検索する順番に列挙します(キーワードは1行に1つずつ指定し、"#" 以降はコメントとみなされます)。
 FreeBSDをインストールした直後の /etc/host.conf は、以下のようです。

# $ID: host.conf,v1.2 1993/11/07 01:02:57 wollman Exp $
# Default is to use the nameserver first
bind
# If that doesn't work, then try the /etc/hosts file
hosts
# If you have YP/NIS configured, uncomment the next line
# nis

bind(DNS) と hosts(/etc/hosts) を使い、nis(NIS) はコメントアウトされて使わない設定になっています。NISを利用するときは、キーワード nis の先頭にある "#" を削除します。この場合、ホスト情報を検索する手順は以下のようになります。

1.最初にDNSサーバに問合せをおこない、検索に失敗したらローカルな /etc/hosts ファイルを参照する。
2./etc/hosts を検索して該当するエントリがみつからなければ、NISサーバに問合せる。
3.NISサーバに問い合せても情報がみつからなければエラーとなる。

 この順番が気に入らなければ、希望する順にキーワードを並べ替えます。NISが利用できるなら、NISを優先的に使うほうが効率がいいと思うかもしれません。しかし、DNSが利用できる環境では、ローカルドメインのホスト情報もDNSサーバがもっています。利用しているネットワーク環境にもよりますが、ふだんはまず最初にDNSサーバに問い合せ、DNSサーバがなんらかの理由で一時的に利用できないときにNISや /etc/hosts のホスト情報を検索するような設定のほうが妥当でしょう。
 なお、FreeBSDではOSのインストール時にDNSの設定ができますが、設定する/しないにかかわらず、/etc/host.conf の中身は同じです。これだと、「DNSクライアントを設定していないのに、毎回DNSサーバを参照しようとして効率が悪いんじゃないか」と不安になるかもしれません。しかし、/etc/resolv.conf ファイルがなければ、即座にDNSサーバへの問い合せをあきらめて次の情報源(この例では /etc/hosts)を参照するため、実際の処理速度はほとんど変わりません。

BSD/OSの/etc/irs.conf

 一方、BSD/OSが利用する /etc/irs.conf はホスト情報だけでなく、パスワード情報やグループ情報の検索順なども指定します。/etc/irs.conf のフォーマットは以下のとうりで、3つのフィールドからなるエントリを1行ずつ書きます。"#" 以降はコメントとみなされます。

情報の種類 情報源 動作オプション

 最初のフィールドには、検索の対象となる情報の種類を指定します。パスワード情報は "passwd"、グループ情報は "group" で、ホスト情報は "hosts" を指定します。
 2番目のフィールドには利用する情報源を指定します。ホスト情報の検索に利用できる情報源としては、"local" (ローカルな /etc/hosts)、"nis"(NIS)、"dns"(DNS)が指定できます。
 3番目のフィールドには、指定した情報源に対して検索をおこなったあとの動作を指定します。ホスト情報なら、このフィールドは "continue" というキーワードを指定したときだけ意味をもち、その情報源から情報が得られなかった場合、次のエントリに書かれた情報源を検索します。"continue" を指定しなければ、検索結果にかかわらずそこで検索処理を中止します。
 BSD/OSをインストールした直後の状態では、/etc/irs.conf のホスト情報に関する部分は以下のように設定されています。

hosts    dns  
#hosts    nis   continue
hosts    local

 最初にDNSを参照するものの、dnsの行には continue オプションが指定されていないため、あとに続く /etc/hosts は参照されずに終わってしまいそうです。これには例外があり、DNSに関しては、/etc/resolv.conf ファイルがなければ dns キーワードが書かれている行は処理がスキップされ、次の行に移ります。このため、上記のような設定では、/etc/resolv.conf の有無によって動作が以下のように変わります。

●/etc/resolv.conf がねければ、次の行以降の情報源を検索する、nis の行はコメントアウトされているため、その次の行、つまりローカルな /etc/hosts が検索される。
●/etc/resolv.conf があれば、指定されたDNSサーバに問い合せをおこなう。問い合せの結果にかかわらず、次の行以降は処理されない。

 したがって、この状態で nis の行頭にある "#" を削除してNISを情報源に加えたとしても、DNSクライアントとしてセットアップすればNISや /etc/hosts は無視されることに注意してください。
これを変更し、たとえば "DNS→/etc/hosts→NIS" という順番でホスト情報を検索させるには、以下のように /etc/irs.conf のホスト情報に関する部分を変更します。

hosts   dns   continue
hosts   local  continue
hosts   nis

 /etc/irs.conf のホスト情報以外に関する部分については、オンライン・マニュアル irs.conf(5) などを参照してください。


Solarisの/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 など、いくつかのネットワーク・サービスに対しては、たのホストからのリクエストに応じてサーバが起動する設定になっているはずです。自分の使っているマシンが提供するサービスを把握していないと、万が一そのサービスのサーバ・プログラムにバグや設定ミスなどがあった場合、そこを突かれて攻撃されないともかぎりません。したがって、マシンをネットワークに接続している場合、そのマシンで動くサーバを調べて不要なものは起動しないように設定しておけば、攻撃される可能性を多少なりとも減らせます。
 そこで、/etc に置かれているファイルのうち、他のホストからのアクセス制御に関連したものをいくつかとりあげます。


信頼するホストの設定

 UNIXのコマンドには、ローカルなホスト上で実行するコマンドをネットワークに対応させたものがいくつかあります。例えば、ファイルをコピーする cp コマンドをネットワークに対応させ、リモートホストとのあいだでファイルのコピーをおこなう rcp コマンドや、リモートマシンにログインする rlogin 、リモートマシンでシェルを実行するための rsh などがあります。各コマンドの詳細は、オンライン・マニュアル rcp(1) や rlogin(1) 、rsh(1) などをご覧ください。各々オリジナルのコマンド名の先頭に "r" という文字が付けられているため、これらを総称して "rコマンド" と呼ぶこともあります。
 通常、r コマンドをリモートホストに対して実行すると、rlogin の場合は確認のパスワードを求められ、その他(rsh や rcp)の場合は「アクセス権限がない」と断られます(FreeBSDでは"Permission denied"、BSD/OSでは "Login incorrect"というエラーメッセージが表示されるはずです)。これに対し、r コマンドの対象となるリモートホスト側で "信頼するホスト(およびユーザ)" を設定しておくと、rlogin の場合はパスワード・チェックなしでリモートマシンにログインできますし、rcp や rsh コマンドも実行できるようになります。
 信頼できるホストとユーザは、システム全体で設定することも、ユーザーごとに設定することもできます。
 システム全体で信頼するホストとユーザーを指定するには、/etc/hosts.equiv ファイルを用います。フォーマットはOSによって微妙に異なりますが、基本的な書き方は以下のとおりです。

信頼するホスト名 [信頼するユーザー名]

 ここで、r コマンドを実行するローカルホストが "mypc" 、r コマンドの対象であるリモートホストが "nullpc" であったとしましょう。nullpc の /etc/hosts.equiv に、

mypc

という行を書いておくと、mypc は信頼するホストとみなされます(通常、"信頼するホスト名" の部分には FQDN あるいは IP アドレスを指定します。ただし、ホスト名だけでそのホストにアクセス可能な場合、この例のようにホスト名だけを指定することができます)。すると、ローカルホストとリモートホストのユーザー名が一致する場合のみ、r コマンドが無条件で実行できるようになります(ただし、root については /etc/hosts.equiv の設定は適用されません。root の権限で r コマンドを実行したい場合は、root のホーム・ディレクトリ(FreeBSDやBSD/OSの場合は /root)の下に後述する ".rhosts" ファイルを作成します)。
 一方、信頼するホスト名のあとに(空白あるいはタブで区切って)信頼するユーザー名を指定すると、指定したホストの指定したユーザーだけを信頼します。例えば nullpc の /etc/hosts.equiv に、さきほどの例の代わりに、

mypc null

と記述すると、(FreeBSD の場合は)mypc の null というユーザーだけが、nullpc に対して(ユーザー null の権限で) r コマンドを実行することができます。
 さらに、FreeBSD の場合は /etc/host.equiv のフォーマットが拡張されており、信頼しないホストと信頼しないユーザーを指定できるほか、ホストやユーザーのグループをまとめて扱えます。
 信頼しないホストやユーザーを指定するには、ホスト名やユーザー名の前に "_" を付けます(ホスト名やユーザー名の前に "+" を指定した場合は信頼することを意味し、何も指定しなかった場合と同じように扱われます)。一方、ネットグループを指定する場合は、ホスト名やユーザ名の部分に "@ネットグループ名" を指定します。
 /etc/hosts.equiv の設定はシステム全体に影響をおよぼしますが、各ユーザーのホーム・ディレクトリに .rhosts というファイルを作成しておくと、ユーザーごとに信頼するホストとユーザを設定することができます。 ~/.rhosts のフォーマットは /etc/hosts.equiv と同じです。例えば、nullpc というホストの null というユーザーのホーム・ディレクトリに .rhosts ファイルを作成し、以下のように記述したとしましょう。

mypc
somepc nil

 すると、mypc のユーザー null と、somepc のユーザー nil は、nullpc に対してユーザー null の権限で r コマンドを実行することができます。2番目の書き方は、自分が持っているアカウントのユーザー名がホストごとに異なる場合の記述です(ただし、somepc のユーザー null が r コマンドを実行する場合、たとえば "rlogin -l null nullpc" のようにユーザー null の権限で実行することを明示しなければなりません)。


hosts.equivと.rhostsについての注意

 hosts.equiv と .rhosts を使う場合には注意が必要です。あるユーザのアカウントが不正に使われている場合、hosts.equiv や .rhosts で信頼するホストやユーザーとして設定していると、そのホストやほかのユーザーが不正に利用される危険性があるからです。したがって、理想的にはこれらのファイルを使わない方がいいでしょう。
 hosts.equiv ファイルは、ある部門内のLANに接続されたホストがあり、これらを統一的に管理するシステム管理者がいる場合には有効でしょう。
 逆に、1人に1台以上のUNIXマシンが割り当てられており、それらのマシンがLANに接続され、各ユーザーの管理に任されている状況では、hosts.equiv ファイルではなく、各ユーザーの ~/.rhosts ファイルを使うほうがまだましです。これらのファイルを使う場合は、十分に注意しましょう。


サービスに対するアクセス制御

 多くのネットワーク・サービスは、"サーバ・クライアント" モデルにもとづいており、TCPやUDPでは "ポート" によってサービスが識別されます。たとえば、電子メールのサーバである sendmail というプログラムは25番ポート(smtp)を監視し、クライアントプログラムはメール・サーバの25番ポートにアクセスすることで、sendmail と通信がおこなえます。
 sendmail などはマシンの起動時に実行され、クライアントからのアクセスに即座に対応できるよう、デーモンプロセスとして動作し続けるタイプのサーバ・プログラムです。これに対し、FTPサーバ(ftpd) や finger サーバ(fingerd) などのように、クライアントからのアクセスがあった時点でサーバ・プログラムを起動すればいいものもあります。便宜的に、前者を "常駐型" のサービス、後者を "非常駐型" のサービスと呼ぶことにします。

inetd

 非常駐型のサービスについては、UNIXではinetdというデーモンがまとめて管理します。"他のデーモンえお起動するためのデーモン" であることから、inetd は "スーパーデーモン" とも呼ばれます。inetd は自分が管理しているサービスに対応するポートを監視し、クライアントからいずれかのポートにアクセスがあると、対応するサービスのデーモン(サーバ・プログラム)を起動します。たとえば、(クライアント・プログラムである)finger コマンドをあるホストに対して実行すると、finger コマンドは指定したホストの79番ポートにアクセスします。指定されたホストの inetd が79番ポートへのアクセスを検出すると、inetd は finger デーモン(fingerd) を起動します。この際、クライアントから送られて来たデータは inetd を通じて起動したデーモンの標準入力に送られ、起動したデーモンの応答メッセージはデーモンの標準出力を介して inetd に、そして inetd からクライアントへと送られます。
 inetd がどのポート(サービス)を監視し、それらのポートにアクセスがあった場合にどのプログラムが起動するかは、/etc/inetd.conf というファイルで設定します。/etc/inetd.conf は、inetd が監視するポート(サービス)ごとのエントリを1行ずつ記述します。各エントリは7つのフィールドで構成され、それぞれのフィールドは空白あるいはタブで区切ります。各フィールドがもつ意味は以下のようになっています。 ("#" で始まる行は、コメントとみなされます)

1.サービス名
inetd が監視するポートをサービス名で指定します。ここで指定したサービス名は /etc/services ファイルを使ってポート番号に変換されます。

2.ソケットタイプ
あるプロセスが他のプロセスと通信を行う場合、プロセスは "ソケット" と呼ばれる仮想的な受け口を利用します。ネットワーク通信をおこなう場合、ソケットはあるポートに接続され、ソケットへの書込みが相手へのデータ送信、ソケットからの読出しが相手からのデータ受信となります。相手との通信にTCPとUDPのどちらを使うかによって、プロセスが利用するソケットの種類が異なります。TCP はストリーム型、UDP はデータグラム型の通信をおこなうため、前者の場合は "stream" を、後者の場合は "dgram" を指定します。

3.プロトコル
基本的に、TCP を用いる場合は "tcp" 、UDP を用いる場合は "udp" を指定します。

4.
サーバー・プログラムの終了まで inetd が待つかどうかあるポートに対応するデーモンを起動した際 、inetd がデーモンの終了を待つかどうかを指定します。基本的に、TCP を用いる場合は "nowait"、UDP を用いる場合は "wait" を指定します。

5.ユーザ名
デーモンを起動する際、どのユーザーの権限で起動するかを指定します。

6.起動するサーバー・プログラムの名前
起動するデーモン(サーバー・プログラム)の名前を絶対パスで指定します。inetd が監視するサービスのなかには、inetd が直接処理をおこなってクライアントに応答するものがあります。たとえば daytime サービス(13番ポート)はサーバーの時刻を date コマンドと同じ形式で返しますが、クライアントから13番ポートにアクセスがあった場合、inetd は他のデーモンを起動せずに直接処理をしてクライアントに結果を送ります。

nullpc$ telnet mypc daytime
Trying 192.160.1.10...
Connected to mypc.
Escape character is '^]'.
Tue Nov 24 14:12:54 1998
Connection closed by foreign host.
nullpc$ ■

inetd が直接処理をおこなうサービスに関しては、このフィールドは "internal" と指定し、次のフィールドには何も書かずにおきます。

7.サーバー・プログラムに対する引数
サーバー・プログラムを起動する際の引数を、

プログラム名 引数

の形で指定します(ここで指定するプログラム名は絶対パスではなく、たんにプログラムのファイル名だけを指定します)。



FreeBSDの/etc/inetd.conf

 FreeBSDでは、インストール直後の /etc/inetd.conf は以下のとうりです。

#
# Internet server configuration database
#
#   @(#)inetd.conf 5.4(Berkeley) 6/30/90
#
ftp   stream tcp  nowait root   /usr/libexec/ftpd    ftpd -l
telnet  stream tcp  nowait root   /usr/libexec/telnetd   ftpd
shell  stream tcp  nowait root   /usr/libexec/rshd   rshd
login  stream tcp  nowait root   /usr/libexec/rlogind   rlogind
finger  stream tcp  nowait nobody  /usr/libexec/fingerd   fingerd -s
#exec  stream tcp  nowait root   /usr/libexec/rexecd   rexecd
#uucpd  stream tcp  nowait root   /usr/libexec/uucpd   uucpd
#nntp  stream tcp  nowait usenet  /usr/libexec/nntpd   nntpd
・・・・・・・・

最初の5行はコメントで、その次の行で FTP サービスに対するエントリが記述されています。ftp のエントリに対する各フィールドの意味は以下のようになります。

1.サービス名は "ftp"
2.ストリーム型のサービスである。
3.TCP を用いて通信をおこなう。
4.inetd は起動したデーモンの終了を待たない(起動したデーモン(ftpd)の終了を待たずに、ftpポートへの新たなアクセスを受け付けることを意味します)。
5.サーバ・プログラムをスーパーユーザー(root)の権限で実行する。
6.起動するサーバ・プログラムの絶対パス名は "/usr/libexec/ftpd" 。
7.サーバ・プログラム起動時の引数は "-l" 。

 上の例では、/etc/inetd.conf の冒頭部分しか挙げていませんが、ファイルの内容をみていくと、行頭に "#" を付けてコメントアウトされたエントリが多いのに気づくでしょう。コメントアウトされたエントリについては、対応するポートにアクセスがあっても inetd は無視します。これらのポートに対して常駐する(つまり、inetdが管理していない)デーモンがあれば話は別ですが、そうでなければポートに対するアクセスは拒否されます。
 したがって、/etc/inetd.conf の各エントリを吟味し、不必要なサービスがあれば、該当するエントリをコメントアウトすればいいことになります。
 なお、/etc/inetd.conf ファイルを変更した場合は、inetd を再起動するか、あるいは HUP シグナルを送って /etc/inetd.conf の内容を再度読み込ませる必要があります。後者の場合、まず最初に ps コマンドで inetd のプロセスID を調べ、そのプロセスIDに対して "kill -HUP" を実行します(FreeBSDの場合、inetdのプロセスIDは /var/run/inetd.pid に記述されるため、"kill -HUP 'cat /var/run/inetd.pid'" を実行します)。

bash# ps x |grep inetd
 128 ?? Is  0:00.04 inetd
bash# kill -HUP 128
bash# ■




一つ前へ