15.4. xinetdの設定ファイル

15.4.3.1. ロギングオプション

以下のロギングオプションは、/etc/xinetd.confと /etc/xinetd.d/ディレクトリ内のサービス特有の 設定ファイルの両方で利用できます。

以下により一般的に使用されているロギングオプションの一覧を表示します：

• 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)。

ロギングオプションの総合的リストについては、xinetd.confのmanページを 御覧下さい。

15.4.3.2. アクセス制御のオプション

xinetdのユーザーは、TCPラッパーホストアクセス規則の使用か、 xinetd設定ファイル経由でのアクセス制御の用意か、又はその 両方を選択できます。TCPラッパーホストアクセス制御ファイルの使用に関する情報は 項15.2で見ることができます。このセクションでは サービスへのアクセスを制御するためのxinetdの使用を説明します。

	注意
	TCPラッパーとは異なり、xinetdの管理者がxinetdサービスを 再起動した場合にのみ、アクセス制御への変更が反映されます。

xinetdホストアクセス制御は、TCPラッパーで使用されている方法と 異なります。TCPラッパーが全てのアクセス設定を2つのファイル、/etc/hosts.allowと /etc/hosts.denyに配置するのに対して、/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ネットワークのクライアントシステムが、 Telnetサービスにアクセスを試みた場合、以下のように表示したメッセージを受け取る ことになります：

Connection closed by foreign host.

さらに、彼らのログイン試行は、次のように/var/log/secureの 中に記録されます：

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 boo xinetd[16252]: EXIT: telnet status=0 pid=16256

TCPラッパーをxinetdアクセス制御と併用する場合、2つの アクセス制御メカニズム間の関係を理解することが重要です。

クライアントが接続の要求をした時、xinetdによって続けられる 動きの順序を以下に示します：

1. xinetdデーモンはlibwrap.aライブラリコールを 経由して、TCPラッパーホストアクセス規則にアクセスします。もし拒否の規則がクライアントホストに 適合するならば、その接続は切断されます。許可の規則がクライアントホストと適合する場合、接続が xinetdに渡されます。

2. xinetdデーモンは、xinetdサービスと 要求されたサービスの両方の為に、自身のアクセス制御規則をチェックします。もし、 拒否の規則がクライアントホストに適合する場合、接続は切断されます。その他の 場合は、xinetdは要求されたインスタンスを開始して接続の 制御を渡します。

	重要
	TCPラッパーアクセス制御をxinetdアクセス制御と併用する場合、 注意が必要です。設定ミスは良からぬ結果を招くことになります。

15.4.3.3. バインドとリダイレクトオプション

xinetd用のサービス設定は、サービスをあるIPアドレスに バインドし、そのサービス用の要求を別のIPアドレス、ホスト名、あるいは ポートへリダイレクトします。

バインディングは、サービス特有の設定ファイルの中でbindオプションと 共に制御されており、サービスをシステム上のIPアドレスと連結します。設定されると、 bindオプションは、正式なIPアドレスの為の要求のみをそのサービスへ アクセスする許可をします。この方法で異なるサービスは異なるネットワークインターフェイスに 需要ベースでバインドできます。

これは、特に複数のネットワークアダプターか、複数のIPアドレスを設定したシステムには 便利なものです。このようなシステムでは、Telnetなどの安全でないサービスはプライベートな ネットワークに接続されているインターフェイス上でのみリッスンするようにして、インターネット 接続のインターフェイスではリッスンしないように設定できます。

redirectオプションは、IPアドレス又はホスト名とそれに続く ポート番号を受け付けます。サービスを設定して、このサービス用の要求を全て 指定したホストか、又はポート番号にリダイレクトできるようにします。この機能は 同じシステム上のポートから別のポートへポイントする、あるいは要求を同じマシン上の 別のIPアドレスへリダイレクトする、あるいは要求を全く別のシステムとポート番号へ 移動する、あるいはこれらのオプションの組合せをする場合に使用できます。この様に して、システム上の特定のサービスに接続しているユーザーは、問題なく他のシステムへ 回送されるようにできます。

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

bindとredirectオプションの利点は、 それらが一緒に使用される時にはっきりと判別できます。サービスをシステム上の 特定のIPアドレスにバインドして、その後そのサービス用の要求を1番目のマシンだけが 見ることができる2番目のマシンにリダイレクトすることにより、内部のシステムが 全く別のネットワークの為にサービスを提供することに使用できます。別の方法として 複数ホームのマシン上の特定のサービスが、既知のIPアドレスへの露呈されることを 制限したり、またそのサービスの要求をその目的用に特定の設定をしたマシンへ リダイレクトするのに使用できます。

例えば、Telnetサービス用にこの設定でファイアウォールとして使用されている システムを考えて見ましょう：

service telnet
{
        socket_type		= stream
        wait			= no
        server			= /usr/sbin/in.telnetd
        log_on_success		+= DURATION USERID
        log_on_failure		+= USERID
        bind                    = 123.123.123.123
        redirect                = 10.0.1.13 21 23
}

このファイル内のbindとredirectオプションは、 マシン上のTelnetサービスがインターネットに向けた外部IPアドレス(123.123.123.123)に バインドされていることを確定します。さらには、123.123.123.123に送信された Telnetサービスへの要求は2番目のネットワークアダプターを通じて、内部IPアドレスの 10.0.1.13にリダイレクトされ、これはファイアウォールと内部のシステムしかアクセス できないようになっています。ファイアウォールはその後、その2つのシステム間で通信を しますので、接続しているシステムは実際には別のマシンに接続されている状態でも 123.123.123.123に接続されているように見えます。

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

15.4.3.4. リソース管理のオプション

xinetdデーモンは、DoS(Denial of Serviceサービスの拒否)攻撃から に対する基本的レベルの保護を追加することができます。以下のリストでは、そのような 終りのない攻撃を制限できるディレクティブを表示します：

• per_source — ソースIPアドレス毎のサービス用の インスタンスの最大数を定義します。これは整数のみを引数として受け付け、 xinetd.conf内とxinetd.d/のサービス 特有の設定ファイル内で使用できます。

• cps — 毎秒の接続最大数を定義します。 このディレクティブは中間にスペースを入れた2つの整数引数を使います。 1番目は1秒間に接続が許可される最大数です。2番目はサービスを再開始 する時にxinetdが待機する必要のある時間の秒数です。 整数のみを引数として受け付け、xinetd.conf内と xinetd.d/ディレクトリのサービス特有の設定 ファイル内の両方で使用できます。

• max_load — サービスのCPU使用限界を 定義します。これは引数に小数点を受け付けます。

他にも利用できるxinetd用のリソース管理オプションは あります。詳細はRed Hat Linux セキュリティ ガイド内のサーバー セキュリティという章を御覧下さい。また、xinetd.confの manページも参照して下さい。