検索

このコンテンツは選択した言語では利用できません。

17.2. TCP Wrappers Configuration Files

download PDF
To determine if a client machine is allowed to connect to a service, TCP wrappers reference the following two files, which are commonly referred to as hosts access files:
  • /etc/hosts.allow
  • /etc/hosts.deny
When a client request is received by a TCP wrapped service, it takes the following basic steps:
  1. References /etc/hosts.allow. — The TCP wrapped service sequentially parses the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule, it allows the connection. If not, it moves on to the next step.
  2. References /etc/hosts.deny. — The TCP wrapped service sequentially parses the /etc/hosts.deny file. If it finds a matching rule, it denies the connection. If not, access to the service is granted.
The following are important points to consider when using TCP wrappers to protect network services:
  • Because access rules in hosts.allow are applied first, they take precedence over rules specified in hosts.deny. Therefore, if access to a service is allowed in hosts.allow, a rule denying access to that same service in hosts.deny is ignored.
  • The rules in each file are read from the top down and the first matching rule for a given service is the only one applied. The order of the rules is extremely important.
  • If no rules for the service are found in either file, or if neither file exists, access to the service is granted.
  • TCP wrapped services do not cache the rules from the hosts access files, so any changes to hosts.allow or hosts.deny take effect immediately without restarting network services.

Warning

If the last line of a hosts access file is not a newline character (created by pressing the Enter key), the last rule in the file fails and an error is logged to either /var/log/messages or /var/log/secure. This is also the case for a rule that spans multiple lines without using the backslash. The following example illustrates the relevant portion of a log message for a rule failure due to either of these circumstances:
warning: /etc/hosts.allow, line 20: missing newline or line too long

17.2.1. Formatting Access Rules

The format for both /etc/hosts.allow and /etc/hosts.deny are identical. Any blank lines or lines that start with a hash mark (#) are ignored, and each rule must be on its own line.
Each rule uses the following basic format to control access to network services:
<daemon list>: <client list> [: <option>: <option>: ...]
The following is a basic sample hosts access rule:
vsftpd : .example.com
This rule instructs TCP wrappers to watch for connections to the FTP daemon (vsftpd) from any host in the example.com domain. If this rule appears in hosts.allow, the connection is accepted. If this rule appears in hosts.deny, the connection is rejected.
The next sample hosts access rule is more complex and uses two option fields:
sshd : .example.com  \
: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
: deny
Note that each option field is preceded by the backslash (\). Use of the backslash prevents failure of the rule due to length.
This sample rule states that if a connection to the SSH daemon (sshd) is attempted from a host in the example.com domain, execute the echo command (which logs the attempt to a special file), and deny the connection. Because the optional deny directive is used, this line denies access even if it appears in the hosts.allow file. For a more detailed look at available options, refer to Section 17.2.2, “Option Fields”.

17.2.1.1. Wildcards

Wildcards allow TCP wrappers to more easily match groups of daemons or hosts. They are used most frequently in the client list field of access rules.
The following wildcards may be used:
  • ALL — Matches everything. It can be used for both the daemon list and the client list.
  • LOCAL — Matches any host that does not contain a period (.), such as localhost.
  • KNOWN — Matches any host where the hostname and host address are known or where the user is known.
  • UNKNOWN — Matches any host where the hostname or host address are unknown or where the user is unknown.
  • PARANOID — Matches any host where the hostname does not match the host address.

Warning

The KNOWN, UNKNOWN, and PARANOID wildcards should be used with care as a disruption in name resolution may prevent legitimate users from gaining access to a service.

17.2.1.2. Patterns

Patterns can be used in the client list field of access rules to more precisely specify groups of client hosts.
The following is a list of the most common accepted patterns for a client list entry:
  • Hostname beginning with a period (.) — Placing a period at the beginning of a hostname matches all hosts sharing the listed components of the name. The following example applies to any host within the example.com domain:
    ALL : .example.com
  • IP address ending with a period (.) — Placing a period at the end of an IP address matches all hosts sharing the initial numeric groups of an IP address. The following example applies to any host within the 192.168.x.x network:
    ALL : 192.168.
  • IP address/netmask pair — Netmask expressions can also be used as a pattern to control access to a particular group of IP addresses. The following example applies to any host with an address range of 192.168.0.0 through 192.168.1.255:
    ALL : 192.168.0.0/255.255.254.0

    Important

    When working in the IPv4 address space, the address/prefix length (prefixlen) pair declarations are not supported. Only IPv6 rules can use this format.
  • [IPv6 address]/prefixlen pair — [net]/prefixlen pairs can also be used as a pattern to control access to a particular group of IPv6 addresses. The following example would apply to any host with an address range of 3ffe:505:2:1:: through 3ffe:505:2:1:ffff:ffff:ffff:ffff:
    ALL : [3ffe:505:2:1::]/64
  • The asterisk (*) — Asterisks can be used to match entire groups of hostnames or IP addresses, as long as they are not mixed in a client list containing other types of patterns. The following example would apply to any host within the example.com domain:
    ALL : *.example.com
  • The slash (/) — If a client list begins with a slash, it is treated as a file name. This is useful if rules specifying large numbers of hosts are necessary. The following example refers TCP wrappers to the /etc/telnet.hosts file for all Telnet connections:
    in.telnetd : /etc/telnet.hosts
Other, lesser used, patterns are also accepted by TCP wrappers. Refer to the hosts_access man 5 page for more information.

Warning

Be very careful when using hostnames and domain names. Attackers can use a variety of tricks to circumvent accurate name resolution. In addition, disruption in DNS service prevents even authorized users from using network services.
It is, therefore, best to use IP addresses whenever possible.

17.2.1.3. Portmap and TCP Wrappers

When creating access control rules for portmap, do not use hostnames as portmap's implementation of TCP wrappers does not support host look ups. For this reason, only use IP addresses or the keyword ALL when specifying hosts in hosts.allow or hosts.deny.
In addition, changes to portmap access control rules may not take affect immediately without restarting the portmap service.
Widely used services, such as NIS and NFS, depend on portmap to operate, so be aware of these limitations.

17.2.1.4. Operators

At present, access control rules accept one operator, EXCEPT. It can be used in both the daemon list and the client list of a rule.
The EXCEPT operator allows specific exceptions to broader matches within the same rule.
In the following example from a hosts.allow file, all example.com hosts are allowed to connect to all services except cracker.example.com:
ALL: .example.com EXCEPT cracker.example.com
In the another example from a hosts.allow file, clients from the 192.168.0.x network can use all services except for FTP:
ALL EXCEPT vsftpd: 192.168.0.

Note

Organizationally, it is often easier to avoid using EXCEPT operators. This allows other administrators to quickly scan the appropriate files to see what hosts are allowed or denied access to services, without having to sort through EXCEPT operators.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.