xinetdを使用するアクセス制御

/etc/xinetd.conf

xinetd.confファイルは、xinetdが制御するサービスのすべての設定ファイルの基礎となります。サービスに特有なファイルも、xinetdを起動するたびに解析されます。デフォルトで、xinetd.confにはすべてのサービスに適用されるいくつかの基本的な設定が含まれています。

defaults
{
	instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success		= HOST PID
        log_on_failure		= HOST
}

includedir /etc/xinetd.d

これらの行は、xinetdの動作のさまざまな面を制御します。

• instances特定のサービスが同時に処理できるリクエストの最大数を設定します。

• log_typeauthprivログを使用するようxinetdに指定します。デフォルトのログは、/etc/syslog.confで/var/log/secureに設定されています。FILE /var/log/xinetdlogを指定すると、xinetdのログは/var/log/xinetdlogという独立したファイルに記録されます。

• log_on_success接続に成功した場合に何を記録するかxinetdに指定します。デフォルトでは、リモートホストのIPアドレスとリクエストを処理するサーバーのプロセスIDが記録されます。

• log_on_failure接続に失敗した場合、あるいは接続が許可されていない場合に何を記録するかをxinetdに指定します。多くの場合、各サービスごとに/etc/xinetd.confのlog_on_successとlog_on_failureの設定を追加します。したがって、通常は各サービスごとに成功したか、あるいは失敗した接続によって、ここに示したものより多くの情報が記録されます。

/etc/xinetd.confとサービスに特有なxinetd設定ファイルでは、さまざまなロギングオプションを使用できます。

• ATTEMPT接続の失敗を記録します（log_on_failure）。

• DURATIONリモートシステムがサービスを使用した時間の長さを記録します（log_on_success）。

• EXITサービスの終了ステータスか停止シグナルを記録します（log_on_success）。

• HOSTリモートホストのIPアドレスを記録します（log_on_failureとlog_on_success）。

• PIDリクエストを受信したサーバーのプロセスIDを記録します（log_on_success）。

• RECORDサービスを開始できなかった場合にリモートシステムに関する情報を記録します。このオプションを使用できるのは、loginやfingerなど、特定のサービスだけです（log_on_failure）。

• USERIDすべてのマルチスレッドストリームサービスについてRFC 1413で定義されている方法を使用したリモートユーザーを記録します（log_on_failureとlog_on_success）。

/etc/xinetd.confでは、特定のIPアドレスから特定のサービスへの接続の最大数を制限するper_sourceなど、その他のオプションも使用できます。

/etc/xinetd.dディレクトリのファイル

/etc/xinetd.confの最後にincludedir /etc/xinetd.dという文があるので、xinetdが起動するたびに/etc/xinetd.dディレクトリのさまざまなファイルが読み込まれます。これらのファイルは、finger、ipop3、rloginなどの名前で、xinetdが制御するさまざまなサービスに関係があります。

/etc/xinetd.dのファイルでは、/etc/xinetd.confの場合と同じ規約とオプションが使用されます。これらが各サービスごとに独立したファイルになっているのは、xinetdが扱うサービスの追加と削除を他のサービスに影響を与えず簡単に行えるようにするためです。

これらのファイルの構造を調べるため、wu-ftpファイルを調べてみましょう。

service ftp
{
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/in.ftpd
        server_args             = -l -a
        log_on_success          += DURATION USERID
        log_on_failure          += USERID
        nice                    = 10
        disable                 = yes
}

1行目では、設定するサービスの名前を定義しています。かっこ内の行には、このサービスを起動して使用する方法を定義する各種の設定が含まれています。wu-ftpファイルには、FTPサービスが使用するソケットタイプ（dgramではなくstream）、バイナリ実行ファイルの使用、バイナリに渡す引数、/etc/xinetd.confの設定に加えて記録する情報、サービスを実行する優先順位などが記述されています。

特定のサービスでxinetdを使用すると、DoS（Denial of Service）アタックに対する基本的な保護にもなります。max_loadオプションでは、CPU使用率のしきい値を浮動小数点数値で指定して、特定のサービスについて受け付けることができる最大の接続数を設定できます。これによって、システムの負荷が特定のサービスに集中することがなくなります。cpsオプションでは、毎秒ごとに可能な接続数の上限を設定する整数値を指定します。この値を3などのように小さい値に設定すると、アタッカーは特定のサービスに対して同時に多数のリクエストを送信することができなくなります。

xinetd内のアクセス制御

xinetdサービスのユーザーは、TCPラッパーのホストアクセス制御ファイル（hosts.allowとhosts.deny）の使用とxinetd設定ファイルによるアクセス制御のいずれか、あるいは両方を選択できます。TCPラッパーのホストアクセス制御ファイルの使用については、ホストベースのアクセス制御リスト項を参照してください。このセクションでは、xinetdを使用してサービスへのアクセスを制御する方法について説明します。

	注意
	TCPラッパーのホストアクセス制御ファイルとは異なり、xinetd設定ファイルの変更を反映させるには、xinetdサービスと、変更の影響を受けるサービスを再起動する必要があります。

xinetdの各種設定ファイルで可能なホストアクセス制御は、TCPラッパーの方法と異なります。TCPラッパーでは/etc/hosts.allowと/etc/hosts.denyという2つのファイルですべてのアクセス設定を行いますが、/etc/xinetd.dの各サービスのファイルにはサービスの使用を許可するホストに基づくアクセス制御規則を記述できます。

xinetdのファイルでは、次のようなオプションを使用してホストアクセスを制御できます。

• only_fromサービスの使用を許可するホストを指定します。

• no_accessサービスの使用を禁止するホストを指定します。

• access_times特定のサービスを使用できる時間帯を指定します。時間帯は、24時間制のHH:MM-HH:MMという形式で指定します。

only_fromオプションとno_accessオプションでは、IPアドレスかホスト名の一覧を使用できます。ネットワーク全体を指定することもできます。TCPラッパーと同じように、xinetdのアクセス制御を適切なロギング設定と組み合わせると、リクエストを阻止するだけでなく、サービスにアクセスしようとする試みをすべて記録できます。

たとえば、次の/etc/xinetd.d/telnetファイルを使用すると、特定のネットワークグループがシステムにtelnetアクセスできなくなり、正当なユーザーでもログインできる時間帯が制限されます。

service telnet
{
        disable         = no
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        no_access       = 10.0.1.0/24
        log_on_success  += PID HOST EXIT
        access_times    = 09:45-16:15
}

この例では、10.0.1.2など10.0.1.0/24サブネットのシステムがbooホストにtelnetアクセスしようとすると、"Connection closed by foreign host"というメッセージが出力されます。さらに、次のようにログインの試行が/var/log/secureに記録されます。

May 15 17:35:47 boo xinetd[16188]: START: telnet pid=16191 from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2
May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2
May 15 17:38:49 booxinetd[16252]: EXIT: telnet status=0 pid=16256

バインドとポートのリダイレクト

xinetdのサービス設定ファイルでは、特定のIPアドレスにサービスをバインドすることや、受信したリクエストを別のIPアドレス、ホスト名、ポートにリダイレクトすることもできます。

バインドはサービス設定ファイルのbindオプションで制御され、システムで使用している特定のIPアドレスにサービスをリンクして、そのIPアドレスを使用するリクエストのみがサービスにアクセスできるようにします。これは、1台はインターネットに対するネットワークアダプタ、別の1台は内部ネットワークに接続、というように複数のマシンをファイアウォールとして使用する場合など、複数のネットワークアダプタと複数のIPアドレスを使用しているシステムで特に便利です。これによって、インターネット接続でTelnetやFTPなどのサービスに接続しようとするアタッカーはサービスに接続できませんが、内部のユーザーは内部ネットワークに接続されたNICによってサービスに接続できます。

redirectオプションでは、IPアドレスかホスト名に続いてポート番号を指定します。このオプションを設定すると、サービスに対するリクエストは指定された場所にリダイレクトされます。この機能を使用すると、同じシステム上にある別のポート番号の指定、同じマシン上にある別のIPアドレスへのリクエストのリダイレクト、まったく異なるシステムとポート番号へのリクエストのシフトか、あるいはこれらの組み合わせが可能になります。このようにすると、あるシステム上にある特定のサービスに接続したユーザーを別のシステムに転送できます。

xinetdデーモンは、リクエストを送信したクライアントマシンと実際にサービスを提供するホストが接続されている間だけ有効なプロセスを生成し、2つのシステム間でデータを転送することによって、このリダイレクトを実現します。

bindオプションとredirectオプションの本当の長所は、これらを同時に使用するとわかります。あるシステム上にある特定のIPアドレスにサービスをバインドし、そのサービスに対するリクエストを1番目のマシンだけがアクセスできる2番目のマシンにリダイレクトすると、内部システムを使用してまったく異なるネットワークのサービスを提供できます。あるいは、特定のIPアドレスからしかサービスにアクセスできないように制限して、そのサービスに対するリクエストを特にそのサービス用に設定した別のマシンにリダイレクトすることもできます。

例として、FTPサービスについて次のように設定したファイアウォールとして使用するシステムを考えてみましょう。

service ftp
{
        socket_type		= stream
        wait			= no
        user			= root
        server			= /usr/sbin/in.ftpd
        server_args		= -l -a
        log_on_success		+= DURATION USERID
        log_on_failure		+= USERID
        bind                    = 123.123.123.123
        redirect                = 10.0.1.13 21
}

このファイルのbindオプションとredirectオプションでは、インターネットに接続された外部IPアドレス（123.123.123.123）にFTPサービスをバインドしています。さらに、123.123.123.123に送信されたFTPサービスのリクエストは、2番目のネットワークアダプタを介して、ファイアウォールと内部システムのみがアクセスできる内部IPアドレス（10.0.1.13）にリダイレクトされます。そして、ファイアウォールが2つのシステム間の通信を行い、接続元のシステムからは123.123.123.123に接続しているように見えますが、実際は別のマシンに接続されます。

この機能は、1つの固定されたIPアドレスしかない広帯域接続のユーザーで特に便利です。NAT（Network Address Translation）を使用すると、ゲートウェイマシンの背後にある内部専用のIPアドレスを使用するシステムは、ゲートウェイシステムの外部からは使用できなくなります。しかし、xinetdが制御するサービスをbindオプションとredirectオプションで設定すると、サービスを提供するよう設定された内部マシンと外部システムの間で一種のプロキシとしてゲートウェイマシンを機能させることができます。さらに、xinetdの各種のアクセス制御とロギングオプションを使用すると、リダイレクトするサービスの同時接続数を制限するなど、保護を追加することができます。