xinetd.confのヘルプ・マニュアル
日本語 英語
xinetd.conf --help
man xinetd.conf
XINETD.CONF(5) XINETD.CONF(5)
名前
xinetd.conf - 拡張されたインターネットサービスデーモンの設定ファイル
説明
xinetd.conf は xinetd によって提供されるサービスを決定する設定ファイル
である。行の最初の空白ではない文字が ’#’ ならばコメント行とみなされる。
空行は無視される。
ファイルは以下の形式のエントリからなる:
service
{
<属性> <値> <値> ...
...
}
代 入演算子 assign_op は ’=’, ’+=’, ’-=’ のいずれかである。殆んどの属性
は単純な代入演算子である ’=’ のみをサポートする。値が値の組合せであるよ
う な属性は、すべての代入演算子をサポートする。そのような属性については
、 ’+=’ は組合せに値を追加することを、 ’-=’ は組合せから値を削除する こ
と を意味する。どの属性がどの演算子をサポートするかは、すべての属性につ
いて述べた後に記述する。
各エントリは service_name で識別されるサービスについて定義する。
id この属性はサービスを識別するのに用いられる。サービスの
中には違うプロトコルを使えるものがあり、その場合は設定
ファイルの別のエントリに記述されるので、そうしたときに
有 用である。デフォルトではサービス id は service_name
と同じである。
type 以下の値の任意の組合せである:
RPC RPC を使ったサービスである
INTERNAL xinetd によって提供されるサービス
TCPMUX/TCPMUXPLUS
well-known(良く知られた)TCPMUX ポートを 使
う 、RFC 1078 プロトコルによって開始される
サービス。後述する TCPMUX サービスについて
書かれた節を参照のこと。
UNLISTED 標準的なシステムファイル (RPC サービスなら
/etc/rpc, RPC でないサービスなら /etc/ser-
vices) にはないサービス
flags 以下のフラグの任意の組合せである:
INTERCEPT パケットまたはすでに受けつけた接続を、それ
が受け付けてよい場所から来ているのかを確か
めるために横取りする (内部サービスまたはマ
ルチスレッドサービスは横取りできない)。
NORETRY フォークに失敗しても再試行しない。
IDONLY リモート側が、リモートのユーザを識別してい
るときのみ接続を受け付ける (すなわち、リモ
ートホストは ident サーバを動かさなけれ ば
な らない)。ログオプション USERID が使われ
てない場合には、このフラグは効果がない。
NAMEINARGS "server_args" の最初の引き数を、サーバが実
行 される際の argv[0] にする。これにより、
普通の inetd のように "server" を tcpd に
し 、サーバー名を "server_args" に入れるこ
とで、tcpd を使うことができる。
NODELAY サービスが TCP のサービスで NODELAY フラグ
が立てられている場合、ソケットに TCP_NODE-
LAY フラグを立てる。サービスが TCP のサ ー
ビスでなければ、このオプションは効果がない
。
KEEPALIVE サービスが TCP のサービスで、KEEPALIVE フ
ラ グ が 立 て ら れ た 場合は、ソケットに
SO_KEEPALIVE フラグが立てられる。サービ ス
が TCP のサービスでなければ、このオプショ
ンは効果がない。
NOLIBWRAP サービスへのアクセスを判断するの に 、tcp-
wrap の内部呼び出しを行わない。 xinetd の
ように長い時間動くプロセスには libwrap 機
能が使えないので、これは必要になる; その様
な場合には tcpd プログラムを明示的に起動す
る こ とができる(NAMEINARGS フラグの項を見
よ)。
SENSOR サービスの代わりに、指定されたポートへのア
クセスを検知するセンサーを使う。注意: これ
はステルススキャンを検知しない。必要ないと
いうことが分かっているサービスにのみ、この
フラグを用いるべきである。このサービスのポ
ー ト へ ア ク セスがあると、IP アドレスが
no_access リストへ追加される。以降の 同 じ
IP アドレスからのアクセスは、deny_time で
設定した期限が切れるまで拒否される。このリ
ストへ費やす時間の長さは、deny_time 属性で
設定が可能である。また、SENSOR フラグが 指
定された場合、同じ行に何が書かれていようと
、サーバに INTERNAL 属性が指定 さ れ た と
xinetd はみなす。あと一つ覚えておくべき重
要なことは、socket_type を stream に設定し
た場合は、 wait 属性は no に設定されなけれ
ばならないということである。
IPv4 サービスを IPv4 サービス(AF_INET)にする。
IPv6 IPv6 がシステムで有効であれば、サービス を
IPv6 サービス(AF_INET6)にする。
disable "yes" または "no" の真偽値をとる。これによりサービスが
使用不能になり、起動されなくなる。 DISABLE フラグに 関
する記述を見よ。
socket_type この属性に指定可能な値は以下:
stream ストリーム型サービス
dgram データグラム型サービス
raw IP への直接制御が必要なサービス
seqpacket 信頼できる連続的なデータグラム交換が必要な
サービス
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 アドレスのリストで、以下の方法の任意の組合せである:
a) %d.%d.%d.%d形式の数値アドレス。右端の部分が 0 で
あ れ ば ワ イ ル ド カードとして扱われる (例えば
、128.138.12.0 は 128.128.12 サブネットのすべての
ホ ストに合致する)。 0.0.0.0 はすべてのインターネ
ットアドレスに 合 致 す る 。 IPv6 ホ ス ト は
abcd:ef01::2345:6789 の よ うな形式で指定する。
IPv4 の場合のワイルドカードに関するルールは、IPv6
アドレスには適用されない
b) %d.%d.%d.{%d,%d,...}形式の組合せアドレス。 4 つす
べての部分が必要 な わ け で は な い ( す な わ
ち%d.%d.{%d,%d,...%d} 形式も可である)。しかし、組
合せの部分はアドレスの最後でなければならない。 こ
の形式は IPv6 ホストでは使えない。
c) (/etc/networks から得られる)ネットワーク名。この
形式は IPv6 ホストでは使えない。
d) ホスト名。 xinetd への接続がなされると、逆引き が
行 われ、得られた正規名(canonical name)と指定され
たホスト名が比較される。 .domain.com 形式のドメイ
ン 名を指定することもできる。クライアント IP の逆
引き結果が .domain.com 内部なら、そのクライアント
は合致したことになる。
e) 1.2.3.4/32 形式の 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 サービスのログ出力がどこに送られるかを指定する。二つの
形式がある:
SYSLOG syslog_facility [syslog_level]
ログ出力は指定された機能分類(facility)で syslog
に 送られる。指定可能な機能分類は daemon, auth,
authpriv, user, mail, lpr, news, uucp, ftp,
local0-7 で ある。指定可能なレベル名は emerg,
alert, crit, err, warning, notice, info, debug
で ある。レベル指定がない場合には、メッセージは
info レベルで記録される。
FILE file [soft_limit [hard_limit]]
ログ出力は file に追加され、そのファイルが無 け
れ ば作成される。ログファイルのサイズに関しては
、二つの制限をオプションで指定できる。一つ目 の
制限は弱い制限(soft_limit)である; xinetd はこの
制限を最初に越えたときにログ出力を行う (xinetd
が syslog に出力する場合は、メッセージは優先度
レベル alert で送られる)。二つ目の制限は強い 制
限(hard_limit)である; xinetd は影響があるサービ
ス (ログファイルとして共通のログファイルを使 っ
ている場合には、二つ以上のサービスが影響受ける)
のログ出力を中止し、その様にしたというメッセ ー
ジをログ出力する (xinetd が syslog に出力する場
合は、メッセージは優先度レベル alert で送 ら れ
る)。強い制限が指定されていない場合は、デフォル
トは弱い制限を 1% 増やした値である。ただし、 増
や す サ イ ズ は パ ラ メータ LOG_EXTRA_MIN と
LOG_EXTRA_MAX (デフォルトは 5K と 20K で、こ れ
ら の定数は(コンパイル時に) config.h で定義され
る) の間になければならない。
log_on_success サーバ起動時と終了時にどの情報をログ出力するかを指定す
る (サービス id はログエントリに必ず含まれる)。以下の
値の任意の組合せが指定可能である:
PID サーバのプロセスIDを出力する (サービ ス が
xinetd によって実装され、他のプロセスへと
フォークされない場合には、プロセス ID とし
て 0 が出力される)
HOST リモートホストのアドレスを出力する
USERID RFC 1413 で示される ident(identification)
プロトコルを使って、リモートユーザのユーザ
ID を出力する。このオプションはマルチスレ
ッドなストリームサービスにのみ使用できる。
EXIT サーバが終了したことを、終了ステータスまた
は終了シグナルと共に出力する (PID オプショ
ンが指定されている場合にはプロセスIDも出力
される)
DURATION サービスセッションの時間を出力する
log_on_failure サーバが起動できなかった場合 (リソースが足りなかった場
合と、アクセス制御による制限による場合のどちらでも) に
どの情報をログ出力するかを指定する。サービスのidは失敗
した理由と共に常にログエントリに含まれる。以下の値の任
意の組合せが指定可能である:
HOST リモートホストのアドレスを出力する
USERID RFC 1413 で示されるident プロトコルを使 っ
て、リモートユーザのユーザ ID を出力する。
このオプションはマルチスレッドなストリーム
サービスにのみ使用できる。
ATTEMPT 失敗があったことを出力する (このオプション
は他のすべてのオプションに含まれる)。
rpc_version RPC サービスの RPC バージョンを指定する。バージョン に
は一つの数か、number-number 形式の範囲を指定できる。
rpc_number リストにない(UNLISTED) RPCサービスの番号を指定する (サ
ービスが標準的なシステムファイルにリストされているなら
、この属性は無視される)。
env この属性の値は ’name=value’ 形式の文字列のリストである
。これらの文字列はサーバが起動する前に、環境に加えられ
る (すなわち、サーバの環境は xinetd の環境に指定された
文字列を加えたものである)。
passenv この属性の値は xinetd の環境変数のリストで、その環境が
サ ーバへと渡される。空のリストは、 env 属性を使って明
示的に指定されたものを除いて、どの変数もサーバへと渡さ
れ ないことを意味する (この属性と env の組合せによって
、サーバにどの環境が渡されるかを正確に指定できるという
ことである)
port サービスのポートを指定する。 /etc/services ファイルに
リストされているサービスに対してこの属性が指定された場
合、その値とファイルにあるポート番号とは等しくなければ
ならない。
redirect TCP サービスの他ホストへの転送を指定する。このポートへ
の接続を xinetd が受け取ったら、プロセスを起動し、指定
されたホストのポート番号への接続を確立し、二つのホスト
の間ですべてのデータを転送する。このオプションは、内部
マシンが外界から見えない場合に有用である。書式は redi-
rect = (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" 属 性 と "DIS-
ABLE" フラグは、この属性でリストされたかに関係なくサー
ビスが有効になるのを防ぐことができることに注目せよ。
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 の mal-
loc の実装方法の関 係 で 、 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 そして数値である。 FOR-
EVER では、xinetd が再起動されるまでその IP アドレスは
消去されない。 NEVER は迷惑な IP アドレスをログに取 る
効果だけである。典型的な値は 60 分である。これなら、正
当な目的でその IP アドレスが再利用されるのを許可する一
方 で、殆んどの DoS 攻撃を防ぐことができる。このオプシ
ョンは SENSOR フラグとの組合わせで用いること。
それぞれのサービスで以上の属性をすべて指定する必要はない。必要な属性 は
以下の通り:
socket_type
user (非内部サービスのみ)
server (非内部サービスのみ)
wait
protocol (RPC と リストにない(UNLISTED)サービスのみ)
rpc_version (RPC サービスのみ)
rpc_number (リストにない RPC サービスのみ)
port (リストにない非 RPC サービスのみ)
以下の属性はすべての代入演算子をサポートする:
only_from
no_access
log_on_success
log_on_failure
passenv
env (’-=’ 演算子はサポートしない)
こ れらの属性は一つのサービスエントリで複数回あらわれてもよい。残りの属
性は ’=’ 演算子のみをサポートし、一つのサービスエントリで一回以下しか現
れない。
また、設定ファイルは以下の形式のデフォルトエントリを一つ持つ。
defaults
{
<属性> = <値> <値> ...
...
}
こ のエントリは、そのサービスで属性値が指定されなかった場合の、デフォル
トの属性値を決定する。指定可能なデフォルトの属性は:
log_type
bind
per_source
umask
log_on_success (積算効果)
log_on_failure (積算効果)
only_from (積算効果)
no_access (積算効果)
passenv (積算効果)
instances
disabled (積算効果)
enabled (積算効果)
積算効果を持つ属性は、複数回指定することができ、その度に積み上げられ る
(すなわち ’=’ は ’+=’ と同じことをする)。 disabled の例外を除いて、サー
ビスエントリで指定された場合と同じ意味を持つ。 disabled は、設定ファ イ
ル にエントリがあるものでさえも使用不可にする。これにより、コメントアウ
トする代わりに、 disabled 属性を使って使用不可にするサービスを、素早 く
再 設定できる。この属性の値は、スペースで区切られた、サービス id のリス
トである。 enabled は disabled と同じ特性を持つ。違いは enabled は使 用
可能にするサービスのリストであるということだ。もし enabled が指定された
場合、指定されたサービスだけが使用可能になる。 enabled が指定されなかっ
た 場合は、すべてのサービスが使用可能と仮定され、 disabled にリストされ
たものが除外される。
内部サービス
xinetd は以下のサービスを内部的に提供する (ストリーム型、データグラム型
の両方とも): echo, time, daytime, chargen, discard である。 xinetd が他
のプロセスへと fork する必要がないということを除けば、これらのサービ ス
は 、 他のサービスと同様にアクセス制限の下にある。これら (time, daytime
と、データグラム型の echo, chargen, discard) は instances の数に制限 が
ない。
xinetd は また、二つの UNLISTED なストリーム型内部サービスを提供する:
servers と services である。前者は実行しているサーバの情報を表示し、 一
方 後者は現在有効なサービスのリストを提供する。一行に一つのサービスで、
各行はサービス名・プロトコル(例えば "tcp")・ポート番号からなる。
今や管理インタフェースがあり、それは内部サービスである。 サ ー ビ ス 名
"xadmin" は予約されており、それは常に内部サービスである。このサービスに
はポート番号を指定しなければならず、多分 IP ベースのアクセス制御もし な
け ればならないだろう。なぜならば、これを執筆している時点では、パスワー
ド保護を何も持たないからである。このポートに telnet し、xinetd にいくら
かの問い合わせをすることができる。
TCPMUX サービス
xinetd は RFC 1078 に準拠した TCPMUX サービスをサポートする。サービスが
それに対応する well-known ポートを持たなくても、 well-known ポートで あ
る TCPMUX を通じてアクセスができる。
TCPMUX を通じてアクセスされるサービスは、それぞれ /etc/xinetd.conf にサ
ービスエントリーを持つか、もしくは includedir ディレクトリの設定ファ イ
ルにサービスエントリがなければならない。
service_name フィールド(各 xinetd の設定ファイルで、サービスの最初で定
義される)は xinetd に(RFC 1078 プロトコルによって)渡される文字列に等 し
く な ければならない。それはリモートのサービス要求者が最初に well-known
ポートである TCPMUX にアクセスしたときに渡される。プライベートなプロ ト
コ ルは高い確率で一意になるサービス名を使うべきだ。ひとつの方法は、ドメ
イン名の前にサービス名を付加することである、
type フィールドは TCPMUX または TCPMUXPLUS のどちらかである 。 TCPMUX-
PLUS が指定された場合、 xinetd はサービスを初期化する前にプロセス呼び出
して、 (RFC 1078 で定義される)プロトコルの最初のハンドシェイクを処理 す
る 。 type が TCPMUX の場合は、ハンドシェークを遂行するために開始されて
いるサーバが対処する。
サービスが標準的なシステムファイル (RPC サービスなら、 /etc/rpc, RPC サ
ー ビスでないなら /etc/services など) に無い場合は、 type には UNLISTED
も指定する。
これらのサービスに対する socket_type は stream でなければならず、 ま た
protocal は tcp でなければならない。
以下は TCPMUX サービス設定のサンプルである。
service myorg_server
{
disable = no
type = TCPMUX
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/etc/my_server_exec
}
well-known ポートの TCPMUX を通じてアクセスされる各サービスのサービスエ
ントリの他に、TCPMUX 自身のサービスエントリも xinetd の設定の中に含まれ
なければならない。以下のサンプルを見よ:
service tcpmux
{
type = INTERNAL
id = tcpmux
socket_type = stream
protocol = tcp
user = root
wait = no
}
注意
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 で行われた。
データグラムサイズ(バイト) 遅延(ミリ秒)
-------------------------- ------------
64 1.19
256 1.51
1024 1.51
4096 3.58
送信バイト バンド幅減少
---------- ------------
10000x64 941 (1.2%)
10000x256 4,231 (1.8%)
10000x1024 319,300 (39.5%)
10000x4096 824,461 (62.1%)
例
#
# xinetd のサンプル設定ファイル
#
defaults
{
log_type = FILE /var/log/servicelog
log_on_success = PID
log_on_failure = HOST RECORD
only_from = 128.138.193.0 128.138.204.0
only_from = 128.138.252.1
instances = 10
disabled = rstatd
}
#
# 注意 1: protocol 属性は必要ない
# 注意 2: instances 属性はデフォルト値を上書き
#
service login
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/etc/in.rlogind
instances = UNLIMITED
}
#
# 注意 1: instances 属性はデフォルト値を上書き
# 注意 2: log_on_success フラグは引き数
#
service shell
{
socket_type = stream
wait = no
user = root
instances = UNLIMITED
server = /usr/etc/in.rshd
log_on_success += HOST RECORD
}
service ftp
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.ftpd
server_args = -l
instances = 4
log_on_success += DURATION HOST USERID
access_times = 2:00-9:00 12:00-24:00
}
# telnet セッションを、8 メガバイトのメモリーと子プロセスを
# 合計 20 CPU 秒に制限
service telnet
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/etc/in.telnetd
rlimit_as = 8M
rlimit_cpu = 20
}
#
# このエントリとその次は、内部サービスを指定する。
# 違うソケットタイプの同じサービスなので、
# 各エントリを唯一に識別するために id 属性を用いる
#
service echo
{
id = echo-stream
type = INTERNAL
socket_type = stream
user = root
wait = no
}
service echo
{
id = echo-dgram
type = INTERNAL
socket_type = dgram
user = root
wait = no
}
service servers
{
type = INTERNAL UNLISTED
protocol = tcp
port = 9099
socket_type = stream
wait = no
}
#
# RPC サービスのサンプル
#
service rstatd
{
type = RPC
socket_type = dgram
protocol = udp
server = /usr/etc/rpc.rstatd
wait = yes
user = root
rpc_version = 2-4
env = LD_LIBRARY_PATH=/etc/securelib
}
#
# リストにないサービスのサンプル
#
service unlisted
{
type = UNLISTED
socket_type = stream
protocol = tcp
wait = no
server = /home/user/some_server
port = 20020
}
関連項目
xinetd(1L),
xinetd.log(5)
Postel J., Echo Protocol, RFC 862, May 1983
Postel J., Discard Protocol, RFC 863, May 1983
Postel J., Character Generator Protocol, RFC 864, May 1983
Postel J., Daytime Protocol, RFC 867, May 1983
Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983
M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078, Nov 1988
StJohns M., Identification Protocol, RFC 1413, February 1993
バグ
INTERCEPT フラグが使われなかった場合、 wait が yes で socket_type が
stream のときは、リモートホストアドレスのアクセス制御は行われない。
INTERCEPT フ ラグが使われなかった場合、 wait が yes で socket_type が
dgram のサービスのリモートホストアドレスによるアクセス制御は、最初の パ
ケ ットにのみ行われる。アクセス制御リストにないホストからのパケットをサ
ーバは受け付けてしまう。これは RPC サービスの場合に起きる。
環境変数に 空白を入れる方法がない。
wait が yes で socket_type が stream のとき、接続が受け付けられた場合の
み、ソケットがサーバへ渡される。
INTERCEPT フラグは、内部サービスとマルチスレッドサービスではサポートさ
れない。
14 June 2001 XINETD.CONF(5)