2.5.2. TCP Wrappers Configuration Files
To determine if a client is allowed to connect to a service, TCP Wrappers reference the following two files, which are commonly referred to as hosts access files:
When a TCP-wrapped service receives a client request, it performs the following steps:
The following are important points to consider when using TCP Wrappers to protect network services:
If the last line of a hosts access file is not a newline character (created by pressing the
key), the last rule in the file fails and an error is logged to either
/var/log/secure. This is also the case for a rule that spans multiple lines without using the backslash character. 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
188.8.131.52. Formatting Access Rules
The format for both
/etc/hosts.deny is identical. Each rule must be on its own line. Blank lines or lines that start with a hash (#) are ignored.
Each rule uses the following basic format to control access to network services:
— A comma-separated list of process names (
service names) or the
wildcard. The daemon list also accepts operators (refer to Section 184.108.40.206.4, “Operators”
) to allow greater flexibility.
— A comma-separated list of hostnames, host IP addresses, special patterns, or wildcards which identify the hosts affected by the rule. The client list also accepts operators listed in Section 220.127.116.11.4, “Operators”
to allow greater flexibility.
— An optional action or colon-separated list of actions performed when the rule is triggered. Option fields support expansions, launch shell commands, allow or deny access, and alter logging behavior.
More information on the specialist terms above can be found elsewhere in this Guide:
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 (
) is attempted from a host in the
domain, execute the
command to append the attempt to a special log file, and deny the connection. Because the optional
directive is used, this line denies access even if it appears in the
file. Refer to Section 18.104.22.168, “Option Fields”
for a more detailed look at available options.
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 are available:
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.
PARANOID wildcards should be used with care, because they rely on functioning DNS server for correct operation. Any disruption to name resolution may prevent legitimate users from gaining access to a service.
Patterns can be used in the client field of access rules to more precisely specify groups of client hosts.
The following is a list of common patterns for entries in the client field:
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
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
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
ALL : 192.168.0.0/255.255.254.0
When working in the IPv4 address space, the address/prefix length (prefixlen
) pair declarations (CIDR
notation) 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
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
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.
Be very careful when using hostnames and domain names. Attackers can use a variety of tricks to circumvent accurate name resolution. In addition, disruption to DNS service prevents even authorized users from using network services. It is, therefore, best to use IP addresses whenever possible.
22.214.171.124.3. Portmap and TCP Wrappers
Portmap's implementation of TCP Wrappers does not support host look-ups, which means
portmap can not use hostnames to identify hosts. Consequently, access control rules for portmap in
hosts.deny must use IP addresses, or the keyword
ALL, for specifying hosts.
portmap access control rules may not take effect immediately. You may need to restart the
Widely used services, such as NIS and NFS, depend on
portmap to operate, so be aware of these limitations.
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.
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
ALL: .example.com EXCEPT cracker.example.com
In another example from a
hosts.allow file, clients from the
network can use all services except for FTP:
ALL EXCEPT vsftpd: 192.168.0.
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