Formatting Access Rules - Red Hat ENTERPRISE LINUX 4.5.0 Reference Manual

the service is granted.
The following are important points to consider when using TCP wrappers to protect network
services:
• Because access rules in
specified in
hosts.deny
denying access to that same service in
• 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
or
hosts.allow hosts.deny
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
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

2.1. Formatting Access Rules

The format for both
/etc/hosts.allow
lines that start with a hash mark (
Each rule uses the following basic format to control access to network services:
<daemon list>: <client list> [: <option>: <option>: ...]
• — A comma separated list of process names (not service names) or the
<daemon list>
wildcard (refer to
ALL
(refer to Section 2.1.4,
are applied first, they take precedence over rules
hosts.allow
. Therefore, if access to a service is allowed in
hosts.deny
take effect immediately without restarting network services.
or
and
/etc/hosts.deny
) are ignored, and each rule must be on its own line.
#
Section 2.1.1, "Wildcards"). The daemon list also accepts operators
"Operators") to allow greater flexibility.
is ignored.
. This is also the case for a rule
/var/log/secure
are identical. Any blank lines or
Formatting Access Rules
, a rule
hosts.allow
311