User guide

Chapter 2. Securing Your Network

• 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 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

2.3.2.1. Formatting Access Rules

The format for both /etc/hosts.allow and /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:

<daemon list>: <client list> [: <option>: <option>: ...]

• <daemon list> — A comma-separated list of process names (not service names) or the ALL

wildcard. The daemon list also accepts operators (refer to Section 2.3.2.1.4, “Operators”) to allow

greater flexibility.

• <client list> — 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 2.3.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, launch shell commands, allow or deny access, and alter

logging behavior.