Red Hat ENTERPRISE LINUX 3 Reference Manual

Also see for ENTERPRISE LINUX 3 - SECURITY GUIDE: Tuning guide Installation guide Installation guide Installation guide Manual

Contents

Chapter 16. TCP Wrappers and xinetd 2411. 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 amatching rule, it allows the connection. If not, it moves on to step 2.2. References /etc/hosts.deny. — The TCP wrapped service sequentially parses the/etc/hosts.deny file. If it finds a matching rule is denies the connection. If not, access tothe 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 inhosts.deny. Therefore, if access to a service is allowed in hosts.allow, a rule denying accessto 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 isthe only one applied. Therefore 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 isgranted.• TCP wrapped services do not cache the rules from the hosts access files, so any changes tohosts.allow or hosts.deny take effect immediately without restarting network services.WarningIf 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 rules that span multiple lines without using the backslash. The followingexample illustrates the relevant portion of a log message for a rule failure due to either of thesecircumstances:warning: /etc/hosts.allow, line 20: missing newline or line too long16.2.1. Formatting Access RulesThe format for both /etc/hosts.allow and /etc/hosts.deny are identical. Any blank lines orlines 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:qdaemon list r : q client list r [: q optionr : q option r : ...]• s daemon listt — A comma separated list of process names (not service names) or the ALLwildcard (see Section 16.2.1.1 Wildcards). The daemon list also accepts operators listed in Section16.2.1.4 Operators to allow greater flexibility.• s client listt — A comma separated list of hostnames, host IP addresses, special patterns(see Section 16.2.1.2 Patterns), or special wildcards (refer to Section 16.2.1.1 Wildcards) whichidentify the hosts effected by the rule. The client list also accepts operators listed in Section 16.2.1.4Operators to allow greater flexibility.• s optiont — An optional action or colon separated list of actions performed when the ruleis triggered. Option fields support expansions (refer to Section 16.2.2.4 Expansions), launch shellcommands, allow or deny access, and alter logging behavior (refer to Section 16.2.2 Option Fields).The following is a basic sample hosts access rule: