17.2. TCPラッパーの設定ファイル
サービスにクライアントマシンが接続を許可されるかどうか決定するために、 TCPラッパーは次の2つのファイルを参照します。これは一般的にホストアクセスファイルと 呼ばれるものです：
/etc/hosts.allow
/etc/hosts.deny
クライアントの要求が TCPラップしたサービスで受け付けられた時、次のような基本ステップが取られます:
/etc/hosts.allow を参照する。 — TCP ラップしたサービスは順番に/etc/hosts.allowファイルを構文解析して、そのサービスに指定されている最初の規則を適用します。適合する規則があれば、接続を許可します。そうでなければ、次のステップへと移動します。
/etc/hosts.deny を参照する。 — TCP ラップしたサービスは順番に/etc/hosts.deny ファイルを構文解析します。適合する規則があれば、接続は拒否されます。そうでなければ、そのサービスへのアクセスは認可されます。
TCPラッパーを使用してネットワークサービスを保護する場合、次の重要な点を考慮する必要があります。
hosts.allow 内のアクセスの規則が最初に適用される為、これらの規則は hosts.deny 内に指定してある規則より優先されます。そのため、hosts.allow でサービスへのアクセスが許可された場合、hosts.deny の同じサービスに対するアクセス拒否の規則は無視されます。
各ファイル内の規則が上から下に読まれ、１つのサービスに対して適用されるのは最初に適合する規則の1つだけです。したがって、規則の配置順序は非常に重要です。
どちらのファイルにもそのサービス用の規則がない場合、あるいはどちらのファイルも存在しない場合、そのサービスへのアクセスは承認されます。
TCPラップのサービスは、ホストのアクセスファイル規則をキャッシュしません。そのため、hosts.allow または hosts.deny への変更は、ネットワークサービスを再開始しなくても直ちに反映されます。
 | 警告 | |
|---|---|---|
ホストアクセスファイルの最後の行が改行マーク(
|
17.2.1. アクセス規則のフォーマット
/etc/hosts.allow と /etc/hosts.deny のフォーマットは全く同じです。「#」マークで始まる行、又は空白行はすべて無視されます。各規則はその独自の行になければなりません。
それぞれの規則は以下のような基本フォーマットを使用してネットワークサービスへのアクセスを制御します：
<daemon list>: <client list> [: <option>: <option>: ...] |
<daemon list> — プロセス名(サービス名ではない)、または、ALL ワイルドカードのカンマで区切られたリスト (項17.2.1.1を参照)。また、デーモンリストには演算子を入れてより高い柔軟性を与えることができます。(項17.2.1.4を参照)。
<client list> — ホスト名や、ホストIPアドレスや、特殊パターンや (項17.2.1.2を参照)、特殊ワイルドカード (項17.2.1.1を参照)のカンマで区切られたリストです。規則により影響されるホストを識別します。また、クライアントリストには、項17.2.1.4に記載されている演算子を入れてより高い柔軟性を与えることもできます。
<option> — 規則が発動された時に実施される 1つのオプション動作、又はカンマで区切られた複数動作のリスト。オプションのフィールドは拡張(項17.2.2.4を参照)のサポート、シェルコマンドの起動、アクセスの許可/拒否、ロギング動作の変更などを行ないます (項17.2.2を参照)。
以下に基本的なホストのアクセス規則のサンプルを示します：
vsftpd : .example.com |
この規則は、example.comドメインのホストすべてからの FTPデーモン(vsftpd)への接続を監視するようTCPラッパーに指示します。この規則が 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 ファイル内に存在しても、この行はアクセスを拒否します。利用できるオプションの詳細は項17.2.2を参照してください。
17.2.1.1. ワイルドカード
ワイルドカードの使用により、TCPラッパーはデーモンやホストのグループをより簡単に照合できます。これらはアクセス規則のクライアントリストフィールドの中で多く使用されます。
以下のようなワイルドカードが使用できます：
ALL — すべてを照合します。これはデーモンリストとクライアントリストの両方に使用できます。
LOCAL — ローカルホストなど、ピリオド(.)のないホストをすべて照合します。
KNOWN — ホスト名、ホストアドレス、あるいはユーザーが既に判っているホストを照合します。
UNKNOWN — ホスト名、ホストアドレス、あるいはユーザーが不明なホストをすべて照合します。
PARANOID — ホスト名とホストアドレスが一致しないホストをすべて照合します。
 | 注意 |
|---|---|
KNOWN、UNKNOWN、PARANOID のそれぞれのワイルドカードは、名前解決中で問題となると正式なユーザーがサービスへのアクセスを取得するのを阻止する可能性がありますので、注意して使用して下さい。 |
17.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)の組み合わせ申告はサポートされません。 IPv6 の規則しかこの形式を使用することができません。
[IPv6 アドレス]/prefixlen の組合せ — [net]/prefixlen の組合せもパターンとして、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
スラッシュ(/) — クライアントリストがスラッシュで始まる場合、それはファイル名と して取り扱います。これは、多量のホストを指定する規則が必要な場合に役に 立つものです。次の例では、全てのTelnet接続の為の/etc/telnet.hosts ファイルへのTCPラッパーを対称にしています：
in.telnetd : /etc/telnet.hosts
TCPラッパーで認可されるパターンには、他に使用頻度の低いものがあります。 詳細についてはhosts_accessの man 5ページを参照して ください。
| 警告 |
|---|---|
ホスト名とドメイン名を使用するときは、十分に注意をしてください。 攻撃者は多様なトリックを使って、正確な名前解決を邪魔します。 また、DNSサービスにおける妨害は、権限のあるユーザーでさえもネットワークサービスが使用できないようにしてしまいます。 したがって、可能な限り、IPアドレスを使用するのが最善の策です。 |
17.2.1.3. ポートマップとTCPラッパー
portmap のアクセス制御規則を作成するとき、 portmap の TCP ラッパー実装はホストのルックアップをサポートしないので、ホスト名は使用しないで下さい。この理由で、ホストを指定する時は、 IPアドレスかキーワード ALL のみを、hosts.allow 又は、hosts.deny で使用してください。
また、portmap アクセスコントロール規則への変更は、 portmap サービスを再起動させないとすぐには反映されない場合があります。
NIS や NFS など幅広く使用されているサービスは portmap に依存して運用されているので、これらの制限に気をつけて下さい。
17.2.1.4. 演算子
現在、アクセス制御規則は、1つの演算子、EXCEPT を受け付けます。これはデーモンリストと規則内のクライアントリストで使用できます。
EXCEPT 演算子の使用により、同じ規則内でより幅広い照合へと特別な拡張が可能になります。
次の hosts.allow からの例では、cracker.example.com 以外の全ての example.com ホストからの、全てのサービスへの接続が許可されます：
ALL: .example.com EXCEPT cracker.example.com |
もう1つのhosts.allowファイルからの例では、192.168.0.xの ネットワークからのクライアントはFTP以外は、すべてのサービスを使用できます：
ALL EXCEPT vsftpd: 192.168.0. |
 | 注記 |
|---|---|
組織的には、EXCEPT演算子の使用を避けた方が管理が楽なことが多く、これにより、他の管理者が、EXCEPT演算子をソートせずに、どのホストがサービスに対するアクセスを許可/拒否されるべきかを判断するのに該当ファイルをすばやく調べることができます。 |
17.2.2. オプションフィールド
アクセスの許可と拒否についての基本的な規則の他に、Red Hat Enterprise Linux の TCPラッパーの実装はオプションフィールドを 通じてアクセス制御言語への拡張をサポートしています。ホストアクセス規則内のオプションフィールドを 使用することにより、管理者はログの動作の変更、アクセス制御の確定、及びシェルコマンドの始動などの各種タスクを達成することが出来ます。
17.2.2.1. ロギング
オプションフィールドにより管理者は、severityディレクティブを使用してログ設備と規則の優先度を簡単に変更することができます。
以下の例では、example.comドメインのいずれのホストからのSSHデーモンへの接続も、emergの優先度を持つデフォルトのauthprivsyslog 設備 (設備値が指定されていない為)にログされます。
sshd : .example.com : severity emerg |
severityオプションを使用して設備を指定することもできます。次の例では、alertの優先度を持つ local0 設備への example.comドメインのホストによる SSHサービス接続の試行をログします：
sshd : .example.com : severity local0.alert |
| 注記 |
|---|---|
実際には、この例は local0設備へ syslogデーモン(syslogd)がログするように設定されるまで、機能しません。カスタムログ設備の設定に関する詳細については syslog.confの manページをお読み下さい。 |
17.2.2.2. アクセスの制御
オプションフィールドにより、管理者はallow又はdeny ディレクティブを最終オプションとして追加することで、1つの規則内で明確に許可、あるいは 拒否ができるようになります。
例えば、次の2つの例は、client-1.example.comからの SSH接続を許可しますが、client-2.example.comからの 接続を拒否します：
sshd : client-1.example.com : allow sshd : client-2.example.com : deny |
アクセス制御を規則単位ベースで許可することにより、オプションフィールドは管理者が全てのアクセス規則を1つのシングルファイル、hosts.allow、又はhosts.denyに統合できるようにします。幾らかの人々にとっては この方法がアクセス規則を簡単に構成させてくれるでしょう。
17.2.2.3. シェルコマンド
オプションフィールドにより、アクセス規則は次の2つのディレクティブを通じて シェルコマンドを始動できます：
spawn — シェルコマンドを子プロセスとして 始動できます。このオプションディレクティブは/usr/sbin/safe_fingerの 使用などのタスクを実行し、要求しているクライアントの情報を得たり、echo コマンドを使用して特殊なログファイルを作成したりします。
次の例では、example.comドメインからTelnetサービスへ アクセスを試行するクライアントは、密かに特殊なファイルにログされます：
in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow
twist — 要求されたサービスを指定されたコマンドで入れ換えます。このディレクティブは侵入者に対する仕掛け(蜜の壷といいます)をするのによく使用されます。また接続しているクライアントにメッセージを送信するため にも使用されます。twistディレクティブは、規則行の末尾に 置く必要があります。
以下の例では、example.com ドメインから FTPサービスへアクセスを試行しているクライアントが echoコマンドによりメッセージを受け取ります。
vsftpd : .example.com \ : twist /bin/echo "421 Bad hacker, go away!"
シェルコマンドのオプションに関する情報は hosts_optionsの manページを参照してください。
17.2.2.4. 拡張
拡張は、spawnやtwistディレクティブと一緒に使用して、関連したクライアント、サーバー、プロセスの情報を提供します。
以下にサポートされている拡張のリストを示します：
%a — クライアントのIPアドレスを提供
%A — サーバーのIPアドレスを提供
%c — ユーザー名とホスト名、又はユーザー名と IPアドレスなどのような各種のクライアントの情報を提供します。
%d — デーモンのプロセス名を提供
%h — クライアントのホスト名 (又は、それがない場合、 IPアドレス)を提供
%H — サーバーのホスト名 (又は、それがない場合、 IPアドレス)を提供
%n — クライアントのホスト名を提供。ホスト名がない場合は、 unknownが出力される。クライアントのホスト名とホストアドレスが一致しない場合は、paranoidが出力される。
%N — サーバーのホスト名を提供。ホスト名がない場合は、 unknownが出力される。サーバーのホスト名とホスト アドレスが一致しない場合、paranoidが出力される。
%p — デーモンのプロセス ID を提供
%s — デーモンのプロセスとサーバーのホスト又は IP アドレスなど、さまざまなタイプのサーバー情報を提供
%u — クライアントのユーザー名を提供。 ユーザー名がない場合はunknownが出力される。
以下の規則のサンプルは、spawnコマンドと一緒に拡張を使用して カスタマイズログファイルの中のクライアントホストを識別しています。
SSHデーモン(sshd)への接続がexample.com ドメインのホストから試行されると、echoコマンドを実行して、 クライアントのホスト名(%h拡張を使用)を含む試行を特殊ファイルへログします:
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \ : deny |
同様に、拡張はクライアントに送り返すメッセージを個人化するのに使用されます。次の例では、example.com ドメインから FTPサービスへアクセスを試行しているクライアントは、彼らがサーバーに立ち入り禁止となったことを通知されています：
vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!" |
利用できる拡張、及び追加のアクセス制御オプションに関する総合説明は、 hosts_accessの man ページのセクション5 (man 5 hosts_access)またはhosts_options の manページを参照してください。
TCPラッパーについての詳細は、項17.5 を参照してください。TCPラッパーで安全を確保する方法については、 Red Hat Enterprise Linux セキュリティガイドのサーバーのセキュリティ の章を参照してください。