XFWP(1)

名前
xfwp - X ファイアウォールプロキシ

書式
xfwp [-pdt <#secs>] [-clt <#secs>] [-cdt <#secs>] [-pmport <port#>] [-config <path>] [-verify]

オプション
xfwp に指定できる固有のコマンドラインオプションを以下に示す:

-cdt
    アクティブでない xfwp クライアントに対するデータ接続(xfwp が既に X プ ロトコルを中継している接続)を閉じるまでのデフォルトの時間(604800秒)を 上書き指定する。

-clt
    xfwp クライアント待ちのポートを閉じるまでのデフォルトの時間(86400秒)を 上書き指定する(このポートは、X クライアントが X サーバに接続しようとす るときに最初に接続するxfwp のポートである)。

-config
    設定ファイルのパス/名前を指定する。

-pdt
    プロキシマネージャに対するアクティブでない接続を閉じるまでのデフォルト の時間(3600秒)を上書き指定する。

-pmport
    プロキシマネージャが接続するデフォルトのポート番号(4444)を上書き指定す る。

-verify
    それぞれのサービスリクエストにマッチする設定ファイル規則を表示する。

説明
X ファイアウォールプロキシ(xfwp)は、ファイアウォール越しに X の通信を 転送するために、ネットワークのファイアウォールホスト上で動作させるアプ リケーション層のゲートウェイプロキシである。Xサーバセキュリティ拡張お よび認証チェックと共に用いると、xfp は内部ネットワーク上に設置したX サー バのアドレスの隠蔽とサーバの接続ポリシーの強制の両方を行うための、安全、 シンプルで信頼できる機構を作ることができる。xfwp は、内部で起きた悪意 を持った行為に対する防御は行うことができない。しかし、適切に設定すれば、 認証を受けたインターネット上の外部ホストで実行された信頼できるクライア ントだけがローカルの X サーバへのアクセスを許されることを保証すること ができる。 xfwp を使用するためには、起動時に xfwp の位置がわかるように設定されて おり、ローカルの環境で動作している X プロキシマネージャが必要である。 [注意: ローカルの環境で複数の xfwp を動かすことができる。詳しくは後述 のロードバランシングについての説明を参照すること。] xfindproxy ユーティ リティを使って(これはリクエストをプロキシマネージャ経由で中継する)、ユー ザは xfwp に特定の X サーバに対するクライアントの監視ポートを割り当て ることができる。これは、内部的にはそのサーバに対する将来の接続リクエス トに関連づけられる。プロキシマネージャは、このクライアント待ちのポート 番号を xfindproxy 経由で返す。その後、xfwp のホスト名とポート番号はバ ンド外のツールによって(つまりウェブブラウザ経由で)リモートの X クライ アントに渡される。これにより、目的の X サーバではなく xfwp に接続する ことができる。

X のクライアント接続リクエストが xfwp の待ちポートの1つに届いたとき、 xfwp は接続ポートに関連づけられた X サーバに接続し、サーバの認証チェッ クおよび xfwp が持っている、リクエストを許すクライアントの設定可能なア クセス制御リストについての認証チェックを行う。チェックに失敗した場合や、 リクエストを受けたサーバが X セキュリティ拡張をサポートしていない場合 には、クライアント接続は失敗する。そうでない場合には接続は認められ、こ れに続くクライアントとサーバ間のデータは xfwp によって中継される。この 中継はクライアントが接続を閉じるか、アクティブでないクライアント接続が 設定されたタイムアウト期限を過ぎるまで行われる。xfwp は、システムサイ クルに対する要求を最小限にするため、接続上で通信を待つ間はブロックする ように設計されている。

IP パケットフィルタリングルータを使った通信
xfwp の目的は、ファイアウォールの外の X クライアントから内部ネットワー クの X サーバへのアクセスに対して、信頼できる制御をできるようにするこ とである。現時点では、このようなアクセス制御は、通常は IP パケットフィ ルタリングルータを含むファイアウォールの設定で実現する。多くの場合、こ のようなフィルタの規則では、内部ネットワークのホストに対する X サーバ のポート(範囲 6000-6xxx)へのアクセスは禁止される。 xfwp を動作させるためには、IP パケットフィルタリングルータの規則から、 ポート 6000-6xxx に対するアクセス制限を取り除かなければならない。[注意: xfwp は 6001 から始まる範囲のポートだけを割り当てる。したがって、全て の内部ネットワーク上のホストに対するポート 6000 番へのアクセスは禁止し たままでよい。] これは、内部ネットワークののファイアウォールを X クラ イアントによる無差別アクセスに対してオープンにするということではない。 xfwp は、IP パケットフィルタリングルータそのものと同様の、完全に設定可 能な規則ベースのアクセス制御システムをサポートしている。 xfwp は実際には、完全に設定可能かつX の通信専用で適用される、ルータと は別のレベルのパケットフィルタリング制御を追加する。詳しくは、 「設定ファイル」セクションを参照すること。

インストール、設定、トラブルへの対処
xfwp は通常は内部ネットワークのファイアウォールホスト上でバックグラウ ンドプロセスとして実行される。 xfwp は前述の任意のコマンドラインオプションを指定して起動することができる。 先に述べたように、xfwp はプロキシマネージャと xfindproxy ユーティリティ と組み合わせせないと利用できない。xfwp はユーザ定義の X サーバのサイト セキュリティポリシーをサポートするように設定することができるが、この場 合には、 X サーバは特定のポリシーをサポートしているかどうかを xfwp に 示す必要がある。これらの要素に関する詳しい情報については、オンラインマ ニュアルを参照すること。xfwp は、-DDEBUG オプションを付けて再コンパイ ルすることによって、デバッグ表示を有効にすることができる。

性能、ロードバランシング、リソース管理
xfwp は4種類の異なる接続を管理する。これは、プロキシマネージャ(PM)デー タ、X クライアント待機、X クライアントデータ、X サーバ接続である。xfwp を使うシステム管理者は、xfwp のサービスの性能を最適化するために、これ らの接続タイプに対するリソースの割り当てと再利用の方法を理解すべきであ る。 それぞれの接続タイプはデフォルト数の割り当てスロットとデフォルトのタイ ムアウト値を持っている。それぞれの接続に対する割り当てスロット(実際に はファイルデスクリプタ)の数は、xfwp のソースコード中に記述されている定 数である。デフォルトのタイムアウト値も xfwp のソースコード中に記述され ている定数である。タイムアウト値とは、接続にデータが流れていない状態で オープンしたままの接続が許される時間である。接続上にデータが流れると、 接続を閉じるまでの時間は自動的にリセットされる。4つの接続タイプにおけ プロセスの接続スロット全体のデフォルトの配分と、それぞれの接続タイプに 対するデフォルトのタイムアウト値の選択は、xfwp の利用モデルが含んでい る多くの仮定に基づいて決まる。 xfwp は、最大で10の PM 接続を許す。この定数は xfwp のソース中で定義さ れている。これは、それぞれの接続について最後にデータが流れてから待つ時 間のデフォルト値である3,600秒(1時間)についても同様である。 起動時には、xfwp は任意の非予約ポート(xfwp のコマンドラインで指定しな ければ、デフォルト値の 4444 が使われる)において PM 接続リクエストを待 つ。PM は通常、xfindproxy を使って PM の呼び出しが行われたときしか xfwp に接続しない。 以降は、両者のメッセージ交換が終わった後でも、デフォルトの接続有効期間 の間は PM は xfwp に接続したままである。場合によっては、これが原因で PM 接続スロットが枯渇してしまうこともある。 システム管理者は、多くの PM から1つの xfwp に接続が行われることを予想 した場合には、-pdt コマンドラインオプションを用い、アクティブでない接 続がオープン状態であることが許される範囲で望ましい有効期間を反映させた タイムアウト値を指定して xfwp を起動すべきである。 現在 xfwp は最大100のクライアントの接続待ちを行うことができる。このそ れぞれは、内部ネットワークの異なる X サーバに対応する。 xfwp クライアントリスナは、xfindproxy を呼び出して設定することができる。 最後のデータが流れた時点から86,400秒(24時間) の有効期間の間は、X クラ イアントの接続リクエストを待ち続ける。この期間を過ぎると、リスナは自動 的にクローズされ、その fd は後で割り当てられるために回収される。 クライアントの待ちポートが利用可能であることを保証するような別のタイム アウト値をどうやって選べばよいかという問題に対しては、システム管理者は (xfindproxy を使って)リスナが割り当てられた時間とクライアントが実際に xfwp への接続を試みる時間との間に予想されるずれを考慮しなければならな い。また、最初のクライアントデータ接続が閉じた後にクライアントのリスナ が再利用される見込みも考慮しなければならない。 xfwp は最大 4096 の X クライアントのデータ接続を受けつける。それぞれの 接続は、最後にデータが通信された時点から、デフォルトで 604,800秒(7 * 24 時間)の存続期間が割り当てられる。この期間が過ぎると、接続は自動的に クローズされ、その fd は将来の割り当てのために回収される。 実際には、サーバ接続はリモートの X クライアントからの接続リクエストが fwp のクライアント待ちポートのいずれかに届くまではまで確立されないので、 クライアントデータのタイムアウトはクライアント-xfwp および xfwp-サーバ の両方の接続に対して適用される。xfwp を通じて多くのクライアントデータ 接続が生じることが予想される場合、システム管理者はデフォルトのタイムア ウト値を変更することを考えるべきである。

設定ファイル
xfwp の設定ファイルは xfwp のホストマシン上にあり、X クライアントのデー タ接続を許可するか拒否するかを指定する。ファイルのパス名は起動時に指定 する。設定ファイルが指定されていなければ、xfwp を通過する全ての X クラ イアントのデータ接続リクエストは、デフォルトで許可される。ただし、この 場合にも他の X サーバ認証チェックには成功しているものとする。設定ファ イルが与えられているが、そのエントリのいずれも接続リクエストにマッチ しない場合には、デフォルトでは接続は拒否される。 設定ファイルでは、全く独立の2つの認証チェックがサポートされている。1つ は xfwp 自身が実行するものであり、もう1つは xfwp の目的のサーバへの問 い合わせの結果である。前者においては、設定ファイルでは IP パケットフィ ルタリングルータに似た記法やセマンティックが使われている。これは以下の 形式の、0個以上の「始点アドレス-終点アドレス」の規則からなる。

[#]{permit | deny} <src> <src mask> [<dest> <dest mask> [<operator> <service>]]

#   コメント文字。この行は評価されない。

permit/deny
    キーワード ``permit'' はアクセス許可を示し、キーワード ``deny'' はアク セス拒否を示す。

src 接続リクエストを出したホストとマッチさせる IP アドレス。この値は IP フォー マットで記述する。

src mask
    サブネットマスクであり、これも IP フォーマットで記述する。この値はさら に始点アドレスのマスクを調べるために使われる。マスク内でセットされてい るビットは、入ってくるアドレスのビットで、指定された src と比較すると きに無視するものを示す。

dest
    入ってくる接続リクエストの終点アドレス(つまり、クライアントが接続しよ うとしている X サーバの IP アドレス)とマッチさせる IP アドレス。

dest mask
    サブネットマスクであり、これも IP フォーマットで記述する。この値はさら に終点アドレスのマスクを調べるために使われる。マスク内でセットされてい るビットは、入ってくるアドレスのビットの内、指定された destination と 比較するときに無視するものを示す。

operator
    (service フィールドが NULL でなければ)常に ``eq'' である。

service
    ``pm'', ``fp'', ``cd'' いずれかの文字列である。これらはそれぞれプロキ シマネージャ、xfindproxy, クライアントデータに対応する。

後者の認証チェックの場合には、設定ファイルは次の形式のサイトのポリシー 規則を0個以上含む:

[#] {require | disallow} <sitepolicy>

require
    対応するサイトポリシーの少なくとも1つが X サーバに 設定されていなければならず、そうでない場合には接続を拒否しなけれ ばならないことを指定する。

disallow
    対応するサイトポリシーのいずれもが X サーバに設定されて いてはならず、そうでない場合には接続を拒否しなければならないこと を指定する。

<sitepolicy>
    ポリシー文字列を指定する。この文字列は英数字を任意に組み合わせたもので あり、対象とする X サーバだけが解釈できればよい。

XFWP の設定ファイルのエントリの評価規則
最初のタイプの設定可能な認証チェックの場合には、始点アドレスに基づいて (オプションとして終点アドレスとタイプも使用できる)それぞれの接続タイプ に対して接続の許可および拒否を行うことができる。 それぞれのファイルエントリでは、``permit'' または ``deny'' であるキー ワードと2つの始点アドレスフィールドは最低限指定しなければならない。 必要ならば destination フィールドと service フィールドを使って、非常に 細かいアクセス制御を行うことができる。

規則マッチングのアルゴリズムは以下である:

      while (チェックするエントリが残っている)
      {
        if ((<originator IP> AND (NOT <src mask>)) == src)
          [if ((<dest X server IP> AND (NOT <dest mask>)) == dest)]
            [if (service fields が存在し、かつマッチしている)]
              キーワードに応じて、接続の許可または拒否を行う
        else
          continue
      }
      if (マッチする規則がない)
        接続を拒否する

サイトのポリシー設定のチェックは、入ってくる接続リクエストに対する別の (そして X サーバだけの)認証で構成される。require(満たさなければならな い)の規則と disallow(接続禁止)の規則を任意の数だけ指定することができる が、全ての規則は同じタイプでなければならない。つまり、1つのファイルに ``require'' と ``disallow'' のキーワードをどちらも記述するとはできない。 このチェックのためのアルゴリズムは以下である:

      if (X サーバがサイトポリシー文字列のいずれかを認識する)
        if (keyword == require)
          接続を許可する
        else
          接続を拒否する
      else
        if (keyword == require)
          接続を拒否する
        else
          接続を許可する

xfwp がサイトのポリシーのチェックを行うのは、始点アドレス-終点アドレス のチェックで接続を認められた場合だけである。

例

# サーバがこれらのポリシーの1つをサポートしている場合に限り、接続が許可
# されるが、それでも適用可能な規則にマッチしていなければならない
#
require policy1
require policy2
#
# 8.7.6.5 が送ってきた pm 接続を拒否する。[注意: pm サービスを明示的に
# 許可している場合、以下に示すように destination フィールドがなければ
# ならない。]
#
deny  8.7.6.5  0.0.0.0  0.0.0.0  255.255.255.255  eq  pm
#
# xfindproxy の X サーバがどこにでも接続できるように許可する [注意: fp
# サービスを明示的に許可している場合、以下に示すように source フィール
# ドがなければならない。]
#
permit  0.0.0.0  255.255.255.255   0.0.0.0  255.255.255.255  eq  fp
#
# IP ドメイン 192.0.0.0 から送られた全ての接続タイプだけを許可する
#
permit  192.0.0.0   0.255.255.255

最初にマッチした規則が適用されるので、始点アドレス-終点アドレスの規則 は正しい順で記述しなければならない点に注意すること。解析器の文法チェッ クに加え、システム管理者が実際にマッチする規則を調べる際の補助を行うた めの特別なコマンドラインオプション(-verify)が用意されている。

バグ
xfwp は監査や記録を行うべきである。

xfwp がオープン状態に保つことができる各タイプの接続数を定義する定数は、 プラットフォームによっては大きすぎることがある。

クライアントが xfwp に接続する前に X サーバが xfwp からの接続を閉じた 場合、クライアントはハングしてしまう。

xfwp は待ちポートを割り当てる前にサーバのサイトポリシーとセキュリティ 拡張を確認すべきである。

関連項目
xfindproxy (1), Proxy Management Protocol spec V1.0, proxymngr(1), Xserver(1)

著者
Reed Augliere, consulting to X Consortium, Inc.