17.4. xinetdの設定ファイル

17.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)。

• USERID — 全てのマルチスレッドシステムの為に RFC 1413で定義された方法を使用しているリモートユーザーをログします (log_on_failureとlog_on_success)。

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

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

xinetdサービスのユーザーは、TCPラッパーホストアクセス規則を使用するか、 xinetd設定ファイル経由でアクセス制御をするか、あるいは両方を選択できます。 TCPラッパーホストアクセス制御ファイルの使用に関する詳細は、 項17.2でご覧ください。

このセクションでは、xinetdを使用してのサービスへのアクセス制御について 説明します。

	注記
	TCPラッパーとは異なり、xinetd の管理者が xinetd サービスを再起動した場合にのみ、アクセス制御への変更が反映されます。 また、TCPラッパーとは異なり、xinetdを通してのアクセス制御は、xinetdによって制御されるサービスにしか影響しません。

xinetd ホストアクセス制御は、TCPラッパーで使用されている方法と異なります。TCPラッパーが全てのアクセス設定を2つのファイル、/etc/hosts.allowと /etc/hosts.deny に配置するのに対して、xinetd のアクセス制御は /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 アクセス制御と併用する場合、注意が必要です。設定ミスは良からぬ結果を招くことになります。

17.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 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に接続されているように見えます。

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

17.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 Enterprise Linux セキュリティガイドのサーバーのセキュリティの章を参照してください。また、xinetd.confの man ページも参照して下さい。。