|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
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>: <client list> [: <option>: <option>: ...]
|
The following is a basic sample hosts access rule:
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.
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:
-
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:
-
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:
-
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 authpriv syslog 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.
|
Option fields also allow administrators to explicitly allow or
deny hosts in a single rule by adding the allow or deny directive as
the final option.
For instance, the following two rules allow SSH connections from
client-1.example.com, but deny connections
from client-2.example.com:
sshd : client-1.example.com : allow
sshd : client-2.example.com : deny
|
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:
in.telnetd : .example.com \
: spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
: allow
|
-
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:
sshd : .example.com \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny
|
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.
|
|
|
