Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

2.6.2. TCP Wrapper 設定ファイル

クライアントがサービスへの接続を許可されているかどうかを確認するには、TCP Wrapper は、ホストアクセスファイルと呼ばれる以下の 2 つの ファイル を参照します。
  • /etc/hosts.allow
  • /etc/hosts.deny
TCP でラップされたサービスがクライアント要求を受信すると、以下の手順が実行されます。
  1. 参照 /etc/hosts.allow- TCP-wrapped サービスは /etc/hosts.allow ファイルを順番に解析し、そのサービスに指定された最初のルールを適用します。一致するルールを見つけると、接続を許可します。そうでない場合は、次の手順に移動します。
  2. 参照 /etc/hosts.deny- TCP-wrapped サービスは /etc/hosts.deny ファイルを順次解析します。一致するルールが見つかると、接続を拒否します。そうでない場合には、サービスへのアクセスを付与します。
ネットワークサービスを保護するために TCP Wrappers を使用する際に考慮すべき重要な点を以下に示します。
  • のアクセスルールは最初に適用 hosts.allow されるため、はで指定されているルールよりも優先され hosts.denyます。そのため、サービスへのアクセスが許可されると hosts.allow、同じサービスへのアクセスを拒否するルール hosts.deny は無視されます。
  • 各ファイル内のルールは上部から読み取られ、指定のサービスの最初のマッチングルールは適用されます。ルールの順序が非常に重要です。
  • ファイルのルールが見つからない場合や、ファイルが存在しない場合は、サービスへのアクセスが許可されます。
  • TCP でラップされたサービスは、ホストアクセスファイルからルールをキャッシュしないため、ネットワークサービスを再起動せずに、に対する変更は即座に hosts.allow hosts.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 ワイルドカード。デーモンリストは、オペレーター（を参照 「Operator」）を受け入れて柔軟性を向上させます。
  • <client list>: ルールの影響を受けるホストを識別するホスト名、ホスト IP アドレス、特殊パターン、またはワイルドカードのコンマ区切りリスト。クライアントリストは、にリストされているオペレーターも受け入れ、柔軟性が向上 「Operator」 します。
  • <option>: ルールがトリガーされる際に実行されるアクションのオプションまたはコロン区切りのアクションリストです。オプションフィールドは、拡張、シェルコマンドの起動、アクセスの許可または拒否、ロギングの動作の変更をサポートします。
注記
上記の用語の一部の詳細については、本ガイドの他の箇所で参照してください。
以下は、ホストアクセスルールの基本例です。 
vsftpd : .example.com
このルールは 、example.com ドメインのホストから FTP デーモン(vsftpd)への接続を監視するように TCP Wrappers に指示します。このルールがに表示されると hosts.allow、接続が許可されます。このルールがに表示されると hosts.deny、接続は拒否されます。
次のホストアクセスルールの例はより複雑で、以下の 2 つのオプションフィールドを使用します。 
sshd : .example.com  \
	: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
	: deny
各オプションフィールドの前にバックスラッシュ(\)が設定されていることに注意してください。バックスラッシュを使用すると、長さが原因でルールの失敗を防ぐことができます。
このサンプルルールは、SSH デーモン(sshd)への接続が example.com ドメインのホストから試行された場合、echo コマンドを実行して特別なログファイルに追加し、接続を拒否していることを示しています。オプションの deny ディレクティブが使用されるため、この行は hosts.allow ファイルに記載されている場合でもアクセスを拒否します。利用可能なオプション 「オプションフィールド」 の詳細は、を参照してください。
2.6.2.1.1. ワイルドカード
ワイルドカードを使用すると、TCP Wrapper がデーモンまたはホストのグループと簡単に一致できるようになります。これらは、アクセスルールのクライアントリストフィールドで最も頻繁に使用されます。
以下のワイルドカードを使用できます。
  • ALL : すべてと一致します。デーモンリストとクライアント一覧の両方に使用できます。
  • LOCAL : localhost など、ピリオド(.)が含まれないホストと一致します。
  • KNOWN : ホスト名およびホストアドレスが分かっているホスト、またはユーザーが分かっている場所を照合します。
  • UNKNOWN : ホスト名またはホストアドレスが不明なホスト、またはユーザーが不明な場所を照合します。
  • PARANOID : ホスト名を取得するために、ソース IP アドレスで逆引き DNS ルックアップが実行されます。次に、IP アドレスを解決するために DNS ルックアップが実行されます。2 つの IP アドレスが接続に一致しない場合、ログは更新されます。
重要
、KNOWN UNKNOWN、および 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 address]/prefixlen pair - [net]/prefixlen ペアは、IPv6 アドレスの特定グループへのアクセスを制御するパターンとしても使用できます。以下の例では、3ffe:505: 2:1:: 3ffe:505:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff: ffff:ffff までのアドレス範囲が 3ffe:505:2:1:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 
    ALL : [3ffe:505:2:1::]/64
  • アスタリスク(*)- アスタリスクは、他のタイプのパターンが含まれるクライアント一覧で混在しない限り、ホスト名または IP アドレスのグループ全体を一致させるために使用できます。以下の例では、example.com ドメイン内のホストに適用されます。 
    ALL : *.example.com
  • スラッシュ(/)- クライアント一覧がスラッシュで始まる場合は、ファイル名として処理されます。これは、多数のホストを指定するルールが必要な場合に役立ちます。以下の例では、すべての Telnet 接続について TCP Wrappers を /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.allow またはのポートマップのアクセス制御ルールは、ホストを指定する ALLために IP アドレスまたはキーワードを使用する hosts.deny 必要があります。
portmap アクセス制御ルールの変更はすぐには反映されない場合があります。portmap サービスを再起動する必要がある場合があります。
NIS や NFS などの広く使用されているサービスは、操作 portmap に依存するため、これらの制限に注意してください。
2.6.2.1.4. Operator
現時点で、アクセス制御ルールは、1 つのオペレーター（）を受け入れ EXCEPTます。デーモンの一覧とルールのクライアントリストの両方で使用できます。
EXCEPT Operator は、同一ルール内で特定の例外のマッチをさらに増やすことができます。
以下の例では hosts.allow、example.com ホストはすべて attacker. example.com 以外のすべてのサービスに接続できます。 
ALL : .example.com EXCEPT attacker.example.com
hosts.allow ファイルからの別の例では、192.168.0.x ネットワークからのクライアントは FTP 以外のサービスを使用できます。 
ALL EXCEPT vsftpd : 192.168.0.
注記
組織的には、Operator の使用を避けることが容易に EXCEPT なります。これにより、他の管理者は適切なファイルをすばやくスキャンして、EXCEPT Operator をソートしなくても、どのホストがサービスへのアクセスを許可または拒否されているかを確認することができます。