2.6.2. TCP Wrapper の設定ファイル

クライアントがサービスへの接続を許可されるかを決定するために、TCP Wrapper は、一般的にホストアクセス (hosts access) ファイルと呼ばれる、以下の 2 つのファイルを参照します。
  • /etc/hosts.allow
  • /etc/hosts.deny
TCP でラップされたサービスがクライアントの要求を受け取ると、以下の手順が実行されます。
  1. /etc/hosts.allow を参照します。 — TCP でラップされたサービスは /etc/hosts.allow ファイルを順番に解析し、そのサービスに指定された最初のルールを適用します。マッチするルールを見つけると、接続を許可し、見つからなければ、次のステップに進みます。
  2. /etc/hosts.denyを参照します。 — TCP でラップされたサービスは /etc/hosts.deny ファイルを順番に解析します。マッチするルールを見つけると、接続を拒否し、見つからなければ、サービスへのアクセスを許可します。
TCP Wrapper を使ってネットワークサービスを保護する際に考慮する重要なポイントは以下の通りです。
  • hosts.allow にあるアクセスルールが最初に適用されるので、それらのルールが hosts.deny で指定されたルールよりも優先されます。そのため、サービスへのアクセスが hosts.allow で許可されると、hosts.deny にある同じサービスへのアクセス拒否ルールは無視されます。
  • 各ファイルにあるルールは上から下に読み込まれ、指定されたサービスに最初にマッチするルールのみが適用されます。ルールの順序は極めて重要です。
  • サービスについてのルールがどのファイルにも見つからないか、またはいずれのファイルも存在しなければ、サービスへのアクセスは許可されます。
  • TCP でラップされたサービスは、ホストのアクセスファイルからのルールをキャッシュしません。そのため、hosts.allowhosts.deny のすべての変更は、ネットワークサービスを再起動しなくても直ちに有効になります。

警告

ホストのアクセスファイルの最後の行が改行文字 (Enter キーを押して作成される)でなければ、ファイルにある最後のルールは失敗して、エラーが /var/log/messages または /var/log/secure のどちらかにログ記録されます。バックスラッシュ文字を使用しない、複数行にわたるルールについても同様です。以下の例は、これらのいずれかの状況によるルールの失敗を示す、ログメッセージの関連部分を示しています。
warning: /etc/hosts.allow, line 20: missing newline or line too long

2.6.2.1. アクセスルールのフォーマット

/etc/hosts.allow/etc/hosts.deny のフォーマットは同じです。 各ルールはそれぞれの行に置かれる必要があります。空行またはハッシュ (#) で始まる行は無視されます。
各ルールは、ネットワークサービスへのアクセスを制御するために以下の基本的なフォーマットを使用します。
<daemon list> : <client list> [: <option> : <option> : …]
  • <daemon list> — コンマ区切りのプロセス名 (サービス名ではない) の一覧、または ALL ワイルドカード。デーモンの一覧は、柔軟性を高めるために演算子 (「演算子」を参照) も受け付けます。
  • <client list> — ルールによって影響されるホストを特定するためのホスト名、ホスト IP アドレス、特別なパターン、またはワイルドカードのコンマ区切りのリスト。クライアントリストは、柔軟性を高めるために「演算子」にリストされた演算子も受け付けます。
  • <option> — ルールが起動されたときに実行されるオプションのアクション、またはアクションのコロン区切りのリスト。オプションのフィールドは、拡張、シェルコマンドの起動、アクセスの許可または拒否、および他のロギング動作をサポートします。

注記

上記の用語についての詳細は、このガイドの以下の箇所を参照してください。
以下は、ホストアクセス規則の基本的なサンプルです。
vsftpd : .example.com
このルールは、TCP Wrapper に対し、example.com ドメインにあるすべてのホストからの FTP デーモン (vsftpd) への接続を待つよう指示します。このルールが hosts.allow に表示される場合、接続は受け付けられます。このルールが hosts.deny に表示される場合は、接続は拒否されます。
次のホストアクセスルールのサンプルはさらに複雑で、2 つのオプションフィールドを使用しています。
sshd : .example.com  \
	: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
	: deny
それぞれのオプションフィールドの前にはバックスラッシュ (\) が付けられることに注意してください。バックスラッシュを使用すると、長さが原因となるルールの失敗を防ぐことができます。
このサンプルルールは、以下のことを記述しています。example.com ドメインにあるホストが SSH デーモン (sshd) への接続を試みると、echo コマンドが実行されて特殊なログファイルにこの試行が追加され、接続が拒否されます。オプションの deny 指示文が使われているので、この行は hosts.allow ファイルに表示されても、アクセスは拒否されます。利用可能なオプションについての詳細は、「オプションフィールド」を参照してください。
2.6.2.1.1. ワイルドカード
ワイルドカードは、TCP Wrapper がデーモンやホストのグループにより簡単にマッチできるようにします。ワイルドカードはアクセスルールのクライアントリストフィールドで最も頻繁に使われます。
以下のワイルドカードを利用できます。
  • ALL — すべてにマッチします。デーモンリストとクライアントリストの両方に対して使用できます。
  • LOCAL — ローカルホストなどのピリオド (.) を含まないすべてのホストにマッチします。
  • KNOWN — ホスト名またはホストアドレスが既知であるか、またはユーザーが既知であるすべてのホストにマッチします。
  • UNKNOWN — ホスト名またはホストアドレスが未知であるかユーザーが未知であるか、またはユーザーが未知であるすべてのホストにマッチします。
  • PARANOID — ホスト名を取得するために逆 DNS ルックアップがソース IP アドレス上で実行されます。次に、DNS ルックアップが IP アドレスを解決するために実行されます。 2 つの IP アドレスが一致しない場合、接続が切断され、ログが更新されます。

重要

KNOWNUNKNOWN、および PARANOID のワイルドカードが正常に動作ために DNS サーバーの機能に依存しているので、注意して使用する必要があります。名前解決が中断されると、正当なユーザーによるサービスへのアクセスが妨害される可能性があります。
2.6.2.1.2. パターン
パターンをアクセスルールのクライアントフィールドで使用すると、クライアントホストのグループをより正確に指定することができます。
以下は、クライアントフィールドのエントリーについての一般的なパターンのリストです。
  • ピリオド (.) で始まるホスト名 —ホスト名の始めにピリオドを置くことにより、その名前についてリストされる構成部分を共有するすべてのホストにマッチします。以下の例は example.com ドメイン内のすべてのホストに適用されます。
    ALL : .example.com
  • ピリオド (.) で終わる IP アドレス — IP アドレスの終わりにピリオドを置くことにより、IP アドレスの最初の数値のグループが同じのすべてのホストにマッチします。以下の例は 192.168.x.x ネットワーク内のすべてのホストに適用されます。
    ALL : 192.168.
  • IP アドレス/ネットマスクのペア — ネットマスク表現は、IP アドレスの特定のグループへのアクセスを制御するためのパターンとしても使われます。192.168.0.0 から 192.168.1.255 までのアドレス範囲を持つすべてのホストに適用されます。
    ALL : 192.168.0.0/255.255.254.0

    重要

    IPv4 アドレス空間で動作している際には、アドレス/プレフィックスの長さ (prefixlen) のペアの宣言 (CIDR 表記) はサポートされません。IPv6 ルールのみがこの形式を利用できます。
  • [IPv6 アドレス]/プレフィックス長のペア — [ネット]/プレフィックス長の組み合わせは IPv6 アドレスの特定グループに対するアクセスを制御するためのパターンとして使用することができます。以下の例は、3ffe:505:2:1:: から3ffe:505:2:1:ffff:ffff:ffff:ffff までのアドレス範囲を持つすべてのホストに適用されます。
    ALL : [3ffe:505:2:1::]/64
  • アスタリスク (*) — アスタリスクは、他のタイプのパターンを含むクライアントリストと混在しない限り、ホスト名または IP アドレスのグループ全体にマッチするために使用できます。以下の例は example.com ドメイン内にあるすべてのホストに適用されます。
    ALL : *.example.com
  • スラッシュ (/) — クライアントリストがスラッシュで始まる場合、それはファイル名として処理されます。これは、多数のホストを指定するルールが必要な場合に役立ちます。以下の例では、TCP Wrapper がすべての Telnet 接続で /etc/telnet.hosts ファイルを参照します。
    in.telnetd : /etc/telnet.hosts
あまり使われない他のパターンも TCP Wrapper によって受け付けられます。詳細は、hosts_access man(5) ページを参照してください。

警告

ホスト名とドメイン名を使用するときは特に注意してください。正確な名前解決を防ぐために、攻撃者は様々なトリックを仕掛けます。さらに、DNS サービスの中断により、許可されているユーザーがネットワークサービスを使用することもできなくなります。そのため、可能な場合は常に IP アドレスを使用するのが最善の策です。
2.6.2.1.3. Portmap と TCP Wrapper
Portmap の TCP Wrapper の実装は、ホストの検索をサポートしません。このことは、 portmap はホストの識別にホスト名を使用できないことを意味します。結果として、 hosts.allowhosts.deny における portmap のアクセス制御ルールでは、ホストを指定するために IP アドレスを使用するか、またはキーワード ALL を使用する必要があります。
portmap アクセス制御ルールへの変更は直ちに反映されません。そのため、portmap サービスを再起動する必要があります。
NIS および NFS などの広く使われるサービスの動作は portmap に依存します。そのため、これらの制限を把握しておいてください。
2.6.2.1.4. 演算子
現在、アクセス制御ルールは演算子 EXCEPTを受け付けます。これは、ルールのデーモンリストとクライアントリストの両方で使用することができます。
EXCEPT 演算子は、同じルール内でより幅広くマッチさせるために特定の例外を許可します。
hosts.allow ファイルの以下の例では、すべての example.com ホストは、cracker.example.com を除くすべてのサービスに接続することが許可されます。
ALL : .example.com EXCEPT cracker.example.com
hosts.allow ファイルの他の例では、192.168.0.x ネットワークのクライアントは FTP を除くすべてのサービスを使用できます。
ALL EXCEPT vsftpd : 192.168.0.

注記

組織的には、EXCEPT 演算子を使用しない方が容易になる場合が多く、これにより、他の管理者は EXCEPT 演算子をソートせずに、サービスへのアクセスを許可/拒否されるホストを判断するのに適切なファイルを素早くスキャンすることができます。