|
|
|
|
|
Red Hat Enterprise Linux 9 Essentials Book now available.
Purchase a copy of Red Hat Enterprise Linux 9 (RHEL 9) Essentials Red Hat Enterprise Linux 9 Essentials Print and eBook (PDF) editions contain 34 chapters and 298 pages
|
2.3.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:
-
/etc/hosts.allow
-
/etc/hosts.deny
When a TCP-wrapped service receives a client request, it performs the following steps:
-
It 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.
-
It 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, it grants access to the service.
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.
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
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.
More information on some of the 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 ( sshd ) is attempted from a host in the example.com domain, execute the echo command to append the attempt to a special log 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. Refer to Section 2.3.2.2, “Option Fields” for a more detailed look at available options.
|
|
|