Host-Based Access Control Lists

Host-based access for services that use TCP wrappers is controlled by two files: /etc/hosts.allow and /etc/hosts.deny. These files use a simple format to control access to services on a server. If no rules are specified in either hosts.allow or hosts.deny, then the default rule is to allow anyone to access to the services.

Order is important since rules in hosts.allow take precedence over rules specified in hosts.deny. Even if a rule specifically denying all access to a particular service is defined in hosts.deny, hosts specifically given access to the service in hosts.allow are allowed to access the service. In addition, all rules in each file take effect from the top down. Any changes to these files take effect immediately, so restarting services is not required.

Formatting Rules

All access control rules are placed on lines within hosts.allow and hosts.deny, and any blank lines or lines that start with the hash mark (#) are ignored. Each rule needs to be on its own line. The rules must be formatted in the following manner:

 daemon_list : client_list [: spawn shell_command ]

Each of these options refers to a different part of the rule:

• daemon_list — A collection of one or more process names or special wildcards, separated by whitespace.

• client_list — One or more hostnames, host addresses, patterns, or wildcards, separated by whitespace, to use when a particular process name matches a requested service.

• shell_command — An optional component that specifies something to be done in the event a rule is utilized.

Patterns are particularly helpful when specifying groups of clients that may or may not access a certain service. If a . character is placed at the beginning of a string, all hosts that share the end of that string are applied to that rule. So, .domain.com would catch both system1.domain.com and system2.domain.com. The . character at the end of a string has the same effect, except going the other direction. This is primarily used for IP addresses, as a rule pertaining to 192.168.0. would apply to the entire class C block of IP addresses. Netmask expressions can also be used as a pattern to control access to a particular group of IP addresses. You can even use asterisks (*) or question marks (?) to select entire groups of hostnames or IP addresses, so long as you do not use them in the same string as the other types of patterns.

If a list of hostnames with access a service is too long or is difficult to control within host.allow or hosts.deny, you can also specify the full path to a file (such as /etc/telnet.hosts.deny). This file contains hostnames, host addresses, or patterns, separated by whitespace, that you want to allow or deny access to that service. This method also works well for sharing access control lists between various services, as changes would need to be made in only one file per service. The following wildcards may be used in the access control rules instead of using specific hosts or groups of hosts:

• ALL — Matches every client with a service. To allow a client access to all services, use ALL in the daemons section.

• LOCAL — Matches any host that does not contain a . character.

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

  Warning

  The KNOWN, UNKNOWN, and PARANOID wildcards should be used very carefully, as a disruption in name resolution may prevent legitimate users from gaining access to a service.

The access control language also contains a powerful operator, EXCEPT, which allows separate lists to be combined within the same rule line. When EXCEPT is used between two lists, the first list applies unless an entry from the second list matches an entity covered by the first list. EXCEPT can be used with daemon or client lists. Consider the following hosts.allow example:

# all domain.com hosts are allowed to connect # to all services except cracker.domain.com ALL: .domain.com EXCEPT cracker.domain.com 
# 123.123.123.* addresses can use all services except FTP ALL EXCEPT in.ftpd: 123.123.123.

Note

Organizationally, it usually makes more sense to use EXCEPT operators sparingly, choosing instead to place the exceptions to the rule in the other access control file. This allows all administrators to quickly scan the appropriate files to see what hosts should be allowed or denied access to which services without having to sort through the various EXCEPT operators.

The best way to manage access control with hosts.allow and hosts.deny is to use the two files together to achieve the desired results. Users who wish to prevent any hosts other than specific ones from accessing services usually place ALL: ALL in hosts.deny. Then, they place lines in hosts.allow, such as:

in.telnetd: 10.0.1.24 in.ftpd: 10.0.1. EXCEPT 10.0.1.1

Alternatively, if you wish to allow anyone to use network services except for specific hosts, leave hosts.allow blank and add any necessary restrictions to hosts.deny, such as:

in.fingerd: 192.168.0.2

Warning

Be very careful about using hostnames and domain names in both access control files, especially hosts.deny. Various tricks could be used by an attacker to circumvent rules specifying a hostname or domain name. In addition, if your system selectively allows access based on hostname and domain name information, any disruption in DNS service would prevent even authorized users from using network services. Using IP addresses whenever possible can prevent many problems when constructing access control rules, especially those that deny access.

Beyond simply allowing or denying access to services for certain hosts, TCP wrappers also supports the use of shell commands. These shell commands are most commonly used with deny rules to set up booby traps, which usually trigger actions that log information about failed attempts to a special file or email an administrator. Following is an example of a booby trap in the hosts.deny file that will write a log line containing the date and client information every time a host from the IP range 10.0.1.0 to 10.0.1.255 attempts to connect via Telnet:

in.telnetd: 10.0.1.: spawn (/bin/echo `date` %c >> /var/log/telnet.log) &

Another feature of using shell commands is support for expansions. Expansions provide the command with information about the client, server, and process involved. Following is a list of supported expansions:

• %a — The client’s IP address.

• %A — 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 — The daemon process name.

• %h — The client’s hostname (or IP address, if the hostname is unavailable).

• %H — The server’s hostname (or IP address, if the hostname is unavailable).

• %n — The client’s hostname. If unavailable, unknown is printed. If the client’s hostname and host address do not match, paranoid is printed.

• %N — The server’s hostname. If unavailable, unknown is printed. If the server’s hostname and host address do not match, paranoid is printed.

• %p — The daemon process ID.

• %s — Various types of server information, such as the daemon process and the host or IP address of the server.

• %u — The client’s username. If unavailable, unknown is printed.

For a full explanation of available shell commands, as well as some additional access control examples, see the man page for hosts_access.

Note

Special attention must be given to portmap when host access control lists. Only IP addresses or the ALL option should be used when specifying hosts to allow or deny, as hostnames are not supported. In addition, changes to the host access control lists that concern portmap may not take effect immediately. Widely used services, such as NIS and NFS, depend on portmap to operate, so be aware of these limitations before depending on hosts.allow and hosts.deny to control access.