Host-Based Access Control Lists

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 comment character (#) are ignored. Each rule needs to be on a separate line.

The rules must be formatted in the following manner:

<daemon_list>: <client_list>[: <shell_command> ]

Each of these options refer 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. By placing a "." character 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 your list of hostnames that may access a particular 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 should contain different hostnames, host addresses, or patterns, separated by whitespace, that you want to allow or deny access to that service. This method also works well to share access control lists between various services, as changes would only need to be made in one file to affect each 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 that particular service or even every service using access control. The ALL wildcard can also apply to daemons.

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

	Caution
	The KNOWN, UNKNOWN, and PARANOID wildcards should be used very carefully, as a disruption in name resolution may make prevent legitimate users from gaining access to a network 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 work through various EXCEPT operators and work out the appropriate logic.

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 that 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 portmap, in.telnetd: 10.0.1.24 or in.ftpd: 10.0.1. EXCEPT 10.0.1.1, to selectively let certain hosts in.

Alternatively, some administrators allow anyone to use network services except for specific hosts. In this case, nothing is placed in hosts.allow and any necessary restrictions are placed in 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 them by 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, the access control language also supports the use of shell commands when that rule is utilized. 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. This is an example of a booby trap located in the hosts.deny file which will write a log line containing the date and client information every time a host from the 10.0.1.0 to 10.0.1.255 range attempts to connect via Telnet:

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

Various expansions containing specific information about the client, server, and process involved are available to the shell commands:

• %a — The client's IP address.

• %A — The server's IP address.

• %c — Various types 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 examination of shell commands, as well as some additional access control examples, review the hosts_access(5) man page.

Note

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