xinetd.conf

名前

説明

 
service <service_name>
{

<属性> <assign_op> <値> <値> ...
...

}

id

この属性はサービスを識別するのに用いられる。 サービスの中には違うプロトコルを使えるものがあり、 その場合は設定ファイルの別のエントリに記述されるので、 そうしたときに有用である。 デフォルトではサービス id は service_name と同じである。

type

以下の値の任意の組合せである:

flags

以下のフラグの任意の組合せである:

disable

"yes" または "no" の真偽値をとる。 これによりサービスが使用不能になり、起動されなくなる。 DISABLE フラグに関する記述を見よ。

socket_type

この属性に指定可能な値は以下:

protocol

サービスに使われるプロトコルを指定する。 プロトコルは /etc/protocols になければならない。 この属性が指定されなかった場合、サービスのデフォルトのプロトコルが使われる。

wait

この属性はサービスがシングルスレッドか、マルチスレッドかを決定する。 値が yes ならシングルスレッドである; すなわち xinetd は、サーバーを起動したらそのサーバが死ぬまでは、 そのサービスへの要求に対する処理を停止する。 値が no ならサービスはマルチスレッドであり、 xinetd はサービスへの新たな要求を処理し続ける。

user

サーバプロセスの uid を指定する。 ユーザ名は /etc/passwd になければならない。 xinetd の実効ユーザIDがスーパーユーザーではない場合には、 この属性は効果がない。

group

サーバプロセスの gid を指定する。 グループ名は /etc/group になければならない。 xinetd の実効ユーザIDがスーパーユーザーではない場合には、 この属性は効果がない。

instances

サーバが同時にいくつサービスできるかを指定する(デフォルトは無制限)。 この属性の値は数値か、もしくは無制限を意味する UNLIMITED のどちらかである。

nice

サーバーの優先度を指定する。 値は(負の)数値である; 詳しくは nice(3)(訳注:Linux では nice(2))を見よ。

server

そのサービスのために実行するプログラムを指定する

server_args

サーバに渡される引き数を指定する。 inetd とは違い、サーバ名は server_args には含めない。

only_from

そのサービスを可能にするリモートホストを指定する。 値は IP アドレスのリストで、以下の方法の任意の組合せである:

値の指定をせずにこの属性を指定すると、 いかなるユーザにもサービス使用不可となる。

no_access

そのサービスが使用できないリモートホストを指定する。 値の指定方法は only_from と同じである。 これら二つの属性により xinetd は場所に基づいたアクセス制御を行う。 サービスに対しこの二つのどちらも指定されない場合には、 そのサービスは誰でも使用可になる。 サービスに対しこの二つが共に指定された場合には、 リモートホストのアドレスがよりよく(より正確に)合致した方に基づき、 そのサービスがそのホストで使用できるかどうかが決定される (例えば、 only_from リストに 128.138.209.0 があり、 no_access リストに 128.138.209.10 があった場合には、 アドレスが 128.138.209.10 のホストはそのサービスへはアクセスできない)。

access_times

サービスが使用できる時間間隔を指定する。 間隔の形式は 時:分-時:分 である (間隔の境界での接続は受け付けられる だろう)。 時間は 0 から 23 の範囲で、分は 0 から 59 である。

log_type

サービスのログ出力がどこに送られるかを指定する。 二つの形式がある:

log_on_success

サーバ起動時と終了時にどの情報をログ出力するかを指定する (サービス id はログエントリに必ず含まれる)。 以下の値の任意の組合せが指定可能である:

log_on_failure

サーバが起動できなかった場合 (リソースが足りなかった場合と、アクセス制御による制限による場合のどちらでも) にどの情報をログ出力するかを指定する。 サービスのidは失敗した理由と共に常にログエントリに含まれる。 以下の値の任意の組合せが指定可能である:

rpc_version

RPC サービスの RPC バージョンを指定する。 バージョンには一つの数か、 number-number 形式の範囲を指定できる。

rpc_number

リストにない(UNLISTED) RPCサービスの番号を指定する (サービスが標準的なシステムファイルにリストされているなら、 この属性は無視される)。

env

この属性の値は 'name=value' 形式の文字列のリストである。 これらの文字列はサーバが起動する前に、環境に加えられる (すなわち、 サーバの環境は xinetd の環境に指定された文字列を加えたものである)。

passenv

この属性の値は xinetd の環境変数のリストで、 その環境がサーバへと渡される。 空のリストは、 env 属性を使って明示的に指定されたものを除いて、 どの変数もサーバへと渡されないことを意味する (この属性と env の組合せによって、 サーバにどの環境が渡されるかを正確に指定できるということである)

port

サービスのポートを指定する。 /etc/services ファイルにリストされているサービスに対してこの属性が指定された場合、 その値とファイルにあるポート番号とは等しくなければならない。

redirect

TCP サービスの他ホストへの転送を指定する。 このポートへの接続を xinetd が受け取ったら、プロセスを起動し、 指定されたホストのポート番号への接続を確立し、 二つのホストの間ですべてのデータを転送する。 このオプションは、内部マシンが外界から見えない場合に有用である。 書式は redirect = (IPアドレス) (ポート) である。 IP アドレスの代わりにホスト名を使うこともできる。 ホスト名検索は xinetd が起動した時の一回のみ行われ、 最初に返された IP アドレスが xinetd が再起動されるまで使われる。 このオプションが指定された場合には "server" 属性は必要ではない。 "server" 属性が指定されても、こちらの属性の方が優先される。

bind

マシンの特定のインタフェースにサービスを割り当てることを指定する。 これは、安全なインタフェースであるローカルインタフェースで待ち(listen)、 外部インタフェースではそうしないような telnet サーバが 作成できることを意味する。 また、あるインタフェースのあるポートで何かしている場合に、 同時に違うインタフェースの同じポートで全く違ったことができる。 書式は bind = (インタフェースの IP アドレス) である。

interface

bind に同じ。

banner

サービスへの接続が確立された時に、 リモートホストで表示されるファイルの名前を指定する。 このバナーはアクセス制御に関係なく表示される。 接続がなされた場合には *いつでも* これが表示されるはずである。

banner_success

サービスへの接続が許可された時に、 リモートホストで表示されるファイルの名前を指定する。 このバナーはサービスへのアクセスが許可されるとすぐに表示される。

banner_fail

サービスへの接続が拒否された時に、 リモートホストで表示されるファイルの名前を指定する。 このバナーはアクセスが拒否されるとすぐに表示される。 ユーザに対し、そのユーザが何か悪いことをしたということ、 そしてこれ以上何もするなということを通知するのに有用である。

per_source

発信元 IP アドレスごとの、そのサービスに対する最大サービス数を指定する。 引き数には一つの整数か "UNLIMITED"(無制限) をとる。 このオプションは、デフォルトセクション(後述)で指定することも可能である。

cps

入ってくる接続の割合の制限。 二つの引き数を取る。 最初の引き数は 1 秒あたりに処理する接続数である。 入ってくる接続の割合がこの値より大きくなると、 サービスは一時的に使用不可になる。 二つ目の引き数は、使用不可になってから再び使用可能になるまでに待つ秒数である。 この設定のデフォルトは、50 の入ってくる接続と、待つのは 10 秒である。

max_load

サービスが接続の受け付けを停止するようになる負荷(load)値を、 浮動小数点数で指定する。 例えば、2 や 2.5 である。 負荷がこの値になると、サービスは接続の受け付けを停止する。 これは 1 分間の平均負荷値(load average)である。 これは OS に依存した機能で、Linux と Solaris でだけサポートされる。

groups

"yes" または "no" を引き数にとる。 groups 属性が "yes" の場合、サーバの実効 UID でアクセスできる グループにアクセスできるようにサーバが実行される。 groups 属性が "no" の場合、サーバは他のグループなしで実行される。 多くの BSD システムでは、この属性は "yes" にされなければならない。 このオプションは、デフォルトセクションで指定することも可能である。

umask

サービスが継承する umask を指定する。 8進数で指定する。 全てのサービスの umask を設定するために、"defaults" セクションで 指定することも可能である。 xinetd は自分自身の umask を、継承した umask と 022 との OR に設定する。 umask オプションが指定されなければ、この xinetd の umask 値が全ての 子プロセスに継承される。

enabled

有効にするサービス名のリストを指定する。 この属性の引数としてリストされたサービスだけが有効になる。 すなわち、残りのサービスは無効になる。 "disable" 属性と "DISABLE" フラグは、この属性でリストされたかに関係なく サービスが有効になるのを防ぐことができることに注目せよ。

include

"include /etc/xinetd/service" という形式で、ファイル名を指定する。 そのファイルは新たな設定ファイルとして解析(parse)される。 xinetd.conf の include が指定された場所にファイルを貼り付けるのとは、 同じではない。 取り込まれたファイルは xinetd.conf と同じ形式でなければならない。 サービス定義の内部でこの属性を指定してはいけない。 サービス定義の外側で指定されなければならない。

includedir

"includedir /etc/xinetd.d" という形式でディレクトリ名を指定する。 そのディレクトリのすべてのファイル(ただし名前にドット('.')を含むファイルと、 名前がチルダ('~')で終わるファイル以外) は xinetd 設定ファイルとして解析される。 ファイルは C ロケールでのアルファベット順で解析される。 includedir はサービス定義の内部で指定されてはならない。

rlimit_as

サービスの、アドレス空間資源の制限を設定する。 パラメータが一つ必要で、制限するバイト数 (キロバイト・メガバイトを指定するのに K, M が使える)を表す正の整数か、 "UNLIMITED" (無制限)を指定する。 Linux の libc の malloc の実装方法の関係で、 rlimit_data, rlimit_rss, rlimit_stack よりもこの制限を設定する方が有用である。 この資源制限は Linux システムでのみ実装されている。

rlimit_cpu

サービスが使える最大 CPU 時間(秒単位)を設定する。 パラメータが一つ必要で、CPU 時間を制限する正の整数か、 "UNLIMITED" (無制限)を指定する。

rlimit_data

サービスの最大データサイズの制限を設定する。 パラメータが一つ必要で、バイト数を表す正の整数か、 "UNLIMITED" (無制限)を指定する。

rlimit_rss

サービスの最大常駐サイズの制限を設定する。 この値を小さくすれば、メモリが少ない時に プロセスがディスクへとスワップアウトされる候補になりやすくなる。 パラメータが一つ必要で、バイト数を表す正の整数か、 "UNLIMITED" (無制限)を指定する。

rlimit_stack

サービスの最大スタックサイズを設定する。 パラメータが一つ必要で、バイト数を表す正の整数か、 "UNLIMITED" (無制限)を指定する。

deny_time

SENSOR を作動させた何者かの IP アドレスからの、全てのサービスへのアクセスを 拒否する期間。単位は分。 指定可能なオプションは FOREVER, NEVER そして数値である。 FOREVER では、xinetd が再起動されるまでその IP アドレスは消去されない。 NEVER は迷惑な IP アドレスをログに取る効果だけである。 典型的な値は 60 分である。 これなら、正当な目的でその IP アドレスが再利用されるのを許可する一方で、 殆んどの DoS 攻撃を防ぐことができる。 このオプションは SENSOR フラグとの組合わせで用いること。

defaults
{

<属性> = <値> <値> ...
...

}

内部サービス

TCPMUX サービス

service myorg_server
{

}

service tcpmux
{

}

注意

1.

以下のサービス属性は、再設定で変更することができない: socket_type, wait, protocol, type である。

2.

属性 only_from と no_access が(直接、 defaultsのどちらでも)指定されなかったサービスは、 アドレスの照合は成功したものとして扱われる (すなわち、アクセスは拒否されない)。

3.

アドレス照合はリモートホストの IP アドレスとを基にしており、 ドメインアドレスには依らない。 長い時間がかかるリモートホストの名前検索を避けられるので、そうなっている (なぜならば、 xinetd は単一スレッドであり、 名前検索はデーモンがその検索を終えるまで、 他の全ての要求を受け付けるのを妨げるからである)。 この枠組の悪い面は、リモートホストの IP アドレスが変わってしまうと xinetd を再設定するまでは、アクセスが拒否されてしまうことである。 アクセスが実際に供されるかどうかは、 新たな IP アドレスが許可されたアクセスにあるかどうかによる。 例えば、ホストの IP アドレスが 1.2.3.4 から 1.2.3.5 に変更され、 only_from が 1.2.3.0 と指定されていれば、アクセスは拒否されない。

4.

ログオプション USERID が指定され、もしリモートホストが ident サーバを動かしてないか、または ident サーバが壊れた返事を送り返してきたら、 サービスフラグ IDONLY が使われない限り、アクセスは拒否されない。

5.

プロセスをフォークし、 それがリモートホストとローカルサーバの間でフィルタとして振舞うことにより、 横取りが機能する。 これは明らかに性能に影響を及ぼすので、 各サービスごとのセキュリティと性能との間の妥協は、あなたに任されている。 以下の表は横取りのオーバーヘッドを示す。 最初の表は様々なデータグラムサイズでの、UDP ベースのサービスにおけるデータグラムあたりのオーバーヘッドである。 TCP ベースのサービスについては、横取りによるバンド幅の減少を計測した。 計測の間は、ある量のデータをクライアントからサーバへ送った (時間のオーバーヘッドは UDP ベースのサービスと同じはずだが、 連続するデータ転送の最初のパケットだけにかかる)。 データ量は表の システムコール数xシステムコールあたりのデータ量 から得られる。すなわち、各 send(2) システムコールはそれほど多くのデータを転送した。 バンド幅の減少は、秒あたりのバイト数と、 横取りが行われなかった場合からの割合で与えられる。 全ての計測は SunOS 4.1 が走る SparcStation IPC で行われた。

例

#
# xinetd のサンプル設定ファイル
#

defaults
{

}

#
# 注意 1: protocol 属性は必要ない
# 注意 2: instances 属性はデフォルト値を上書き
#
service login
{

}

#
# 注意 1: instances 属性はデフォルト値を上書き
# 注意 2: log_on_success フラグは引き数
#
service shell
{

}

service ftp
{

}

# telnet セッションを、8 メガバイトのメモリーと子プロセスを
# 合計 20 CPU 秒に制限
service telnet
{

}

#
# このエントリとその次は、内部サービスを指定する。
# 違うソケットタイプの同じサービスなので、
# 各エントリを唯一に識別するために id 属性を用いる
#
service echo
{

}

service echo
{

}

service servers
{

}

#
# RPC サービスのサンプル
#
service rstatd
{

}

#
# リストにないサービスのサンプル
#
service unlisted
{

}

関連項目

バグ