検索

48.5.2. TCP Wrapper 設定ファイル

download PDF
クライアントがサービスに接続できるかどうかを判断するには、TCP Wrappers は、一般的に ホストアクセス ファイルと呼ばれる以下の 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.allow または hosts.deny への変更は即座に有効になります。
Warning
ホストアクセスファイルの最後の行が改行文字ではない場合( Enter キーを押して作成)、ファイルの最後のルールが失敗し、エラーが /var/log/messages または /var/log/secure のいずれかに記録されます。これは、バックスラッシュ文字を使用せずに複数の行にまたがるルールにも当てはまります。以下の例は、これらの状況のいずれかによるルール失敗に関するログメッセージの関連部分を示しています。
warning: /etc/hosts.allow, line 20: missing newline or line too long

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

/etc/hosts.allow/etc/hosts.deny の両方の形式は同じです。各ルールはそれぞれの行に指定する必要があります。ハッシュ(#)で始まる空白行または行は無視されます。
各ルールは、以下の基本形式を使用して、ネットワークサービスへのアクセスを制御します。
<daemon list>: <client list> [: <option>: <option>: ...]
  • <daemon list >: プロセス名(サービス名ではない )またはすべてのワイルドカードのコンマ区切りリスト。デーモンリストは、柔軟性を高めるために演算子( 「Operator」を参照)も受け入れます。
  • <client list >: ルールの影響を受けるホストを識別するホスト名、ホスト IP アドレス、特別なパターン、またはワイルドカードのコンマ区切りリスト。クライアントリストは、「Operator」 に記載されている演算子も受け入れ、柔軟性を高めることができます。
  • <option>: ルールがトリガーされたときに実行されるアクションのオプション のアクションまたはコロン区切りの一覧。オプションフィールドは、拡張、シェルコマンドの起動、アクセスを許可または拒否、およびロギング動作の変更をサポートします。
注記
上記の目標条件の詳細については、本ガイドの他の場所で参照できます。
以下は、基本的なホストのアクセスルールの例です。
vsftpd : .example.com
このルールは、example.com ドメインのホストから FTP デーモン(vsftpd)への接続を監視するように TCP Wrapper に指示します。このルールが 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 ファイルに表示された場合でもアクセスを拒否します。利用可能なオプションの詳細は、「オプションフィールド」 を参照してください。
48.5.2.1.1. ワイルドカード
ワイルドカードを使用すると、TCP Wrapper がデーモンまたはホストのグループとより簡単に一致できるようになります。これらは、アクセスルールのクライアントリストフィールドで最も頻繁に使用されます。
以下のワイルドカードを使用できます。
  • all: すべてに一致します。これは、デーモンリストとクライアント一覧の両方に使用できます。
  • LOCAL - localhost などのピリオド(.)を含まないホストに一致します。
  • KNOWN - ホスト名およびホストアドレスが分かっているホスト、またはユーザーが認識されているホストと一致します。
  • UNKNOWN: ホスト名またはホストアドレスが不明なホスト、またはユーザーが不明なホストと一致します。
  • PARANOID: ホスト名がホストアドレスに一致しないホストと一致します。
注意
KNOW N、 UNKNOWN、および PARANOID ワイルドカードは、正しい操作のために機能する DNS サーバーに依存するため、注意して使用する必要があります。名前解決が中断されると、正当なユーザーがサービスへのアクセスを取得できなくなる可能性があります。
48.5.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 address]/prefixlen ペア - [net]/prefixlen ペアを、特定の IPv6 アドレスのグループへのアクセスを制御するパターンとして使用することもできます。以下の例では、3ffe:505:2:1: through 3ffe:505:2:1: through 3ffe:505: 2:1:ffff:ffff:ffff : のアドレス範囲を持つホストに適用されます。
    ALL : [3ffe:505:2:1::]/64
  • アスタリスク(*): Asterisks を使用して、他のタイプのパターンを含むクライアントリストで混在しない限り、ホスト名または IP アドレスのグループ全体を照合できます。以下の例では、example.com ドメイン内の任意のホストに適用されます。
    ALL : *.example.com
  • スラッシュ(/): クライアントリストがスラッシュで始まる場合は、ファイル名として処理されます。これは、多数のホストを指定するルールが必要な場合に役立ちます。以下の例では、すべての Telnet 接続の /etc/telnet.hosts ファイルに TCP Wrapper を参照します。
    in.telnetd : /etc/telnet.hosts
他の少ないパターンも TCP Wrappers によって受け入れられます。詳細は、hosts_access の man 5 ページを参照してください。
Warning
ホスト名およびドメイン名を使用する場合は十分に注意してください。攻撃者は、さまざまなコツを使用して、正確な名前解決を回避できます。さらに、DNS サービスが中断されることにより、許可されたユーザーであってもネットワークサービスが使用できなくなります。したがって、可能な限り IP アドレスを使用することが推奨されます。
48.5.2.1.3. portmap および TCP Wrapper
Portmap の TCP Wrapper の実装は、ホストルックアップをサポートしません。つまり、portmap はホスト名を使用してホストを識別できません。したがって、hosts.allow または hosts.deny の portmap のアクセス制御ルールは、ホストの指定に IP アドレスまたはキーワード ALL を使用する必要があります。
portmap アクセス制御ルールへの変更は、すぐに有効にならない可能性があります。portmap サービスを再起動する必要がある場合があります。
NIS や NFS など、広く使用されているサービスは、動作に portmap に依存するため、これらの制限事項に注意してください。
48.5.2.1.4. Operator
現在、アクセス制御ルールは 1 つの Operator ( 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 オペレーターでソートせずに、適切なファイルをすばやくスキャンして、サービスへのアクセスが許可または拒否されるホストを確認できます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.