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:
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.
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
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> — A comma
separated list of process names (not service
names) or the ALLwildcard (refer to Section 17.2.1.1 Wildcards). The daemon list also
accepts operators (refer to Section 17.2.1.4 Operators) to allow greater
flexibility.
<client list> — A comma
separated list of hostnames, host IP addresses, special
patterns (refer to Section 17.2.1.2 Patterns), or special wildcards
(refer to Section 17.2.1.1 Wildcards) which
identify the hosts effected by the rule. The client list also
accepts operators listed in Section 17.2.1.4 Operators to allow greater
flexibility.
<option> — An optional
action or colon separated list of actions performed when the rule
is triggered. Option fields support
expansions (refer to Section 17.2.2.4 Expansions),
launch shell commands, allow or deny access, and alter
logging behavior (refer to Section 17.2.2 Option Fields).
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:
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.
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.
Caution
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.
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.
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.
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.
In addition to basic rules allowing and denying access, the Red Hat Enterprise Linux
implementation of TCP wrappers supports extensions to the access
control language through option fields. By using option fields within
hosts access rules, administrators can accomplish a
variety of tasks such as altering log behavior, consolidating access
control, and launching shell commands.
Option fields let administrators easily change the log facility
and priority level for a rule by using the
severity directive.
In the following example, connections to the SSH daemon from any
host in the example.com domain are logged to the
default authprivsyslog
facility (because no facility value is specified) with a priority of
emerg:
sshd : .example.com : severity emerg
It is also possible to specify a facility using the
severity option. The following example logs any
SSH connection attempts by hosts from the
example.com domain to the
local0 facility with a priority of
alert:
sshd : .example.com : severity local0.alert
Note
In practice, this example does not work until the syslog daemon
(syslogd) is configured to log to the
local0 facility. Refer to the
syslog.conf man page for information about
configuring custom log facilities.
By allowing access control on a per-rule basis, the option field
allows administrators to consolidate all access rules into a single file:
either hosts.allow or
hosts.deny. Some consider this an easier way of
organizing access rules.
Option fields allow access rules to launch shell commands through
the following two directives:
spawn — Launches a shell command as
a child process. This option directive can perform tasks like
using /usr/sbin/safe_finger to get more
information about the requesting client or create special log
files using the echo command.
In the following example, clients attempting to access Telnet
services from the example.com domain are
quietly logged to a special file:
twist — Replaces the requested
service with the specified command. This directive is often used
to set up traps for intruders (also called "honey pots"). It can
also be used to send messages to connecting clients. The
twist directive must occur at the end of the
rule line.
In the following example, clients attempting to access FTP
services from the example.com domain are
sent a message via the echo command:
vsftpd : .example.com \
: twist /bin/echo "421 Bad hacker, go away!"
For more information about shell command options, refer to the
hosts_options man page.
Expansions, when used in conjunction with the
spawn and twist directives,
provide information about the client, server, and processes
involved.
Below is a list of supported expansions:
%a — Supplies the client's IP address.
%A — Supplies the server's IP address.
%c — Supplies a variety of client
information, such as the username and hostname, or the username
and IP address.
%d — Supplies the daemon process name.
%h — Supplies the client's hostname (or IP address,
if the hostname is unavailable).
%H — Supplies the server's hostname (or IP address,
if the hostname is unavailable).
%n — Supplies the client's hostname. If unavailable,
unknown is printed. If the client's
hostname and host address do not match,
paranoid is printed.
%N — Supplies the server's
hostname. If unavailable, unknown is
printed. If the server's hostname and host address do not match,
paranoid is printed.
%p — Supplies the daemon process
ID.
%s —Supplies various types of
server information, such as the daemon process and the host or
IP address of the server.
%u — Supplies the client's
username. If unavailable, unknown is printed.
The following sample rule uses an expansion in conjunction with the
spawn command to identify the client host in a
customized log file.
When connections to the SSH daemon (sshd) are
attempted from a host in the example.com domain,
execute the echo command to log the attempt,
including the client hostname (by using the %h
expansion), to a special file:
Similarly, expansions can be used to personalize messages back to
the client. In the following example, clients attempting to access FTP
services from the example.com domain are informed
that they have been banned from the server:
vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"
For a full explanation of available expansions, as well as
additional access control options, refer to section 5 of the man
pages for hosts_access (man 5
hosts_access) and the man page for
hosts_options.
For additional information about TCP wrappers, refer to Section 17.5 Additional Resources. For more information
about how to secure TCP wrappers, refer to the chapter titled
Server Security in the
Red Hat Enterprise Linux Security Guide.
