Host-Based Access Control Lists

Host-based access for services that use TCP wrappers is controlled by two files: hosts.allow and hosts.deny. These files, located in the /etc directory, use a simple format to control access by particular systems or users to certain services on a server.

The default rule is to allow anyone to access to the services if no rules are specified in either hosts.allow or hosts.deny. 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 it. All rules in each file take effect from the top down, so the order in which the rules are placed can be important.

Any changes to these files take effect immediately on the affected services; restarting of the 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 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>[: spawn <shell_command> ]

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

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, would catch both and 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:


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 hosts are allowed to connect
# to all services except

# 123.123.123.* addresses can use all services except FTP
ALL EXCEPT in.ftpd: 123.123.123.


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: or in.ftpd: 10.0.1. EXCEPT, 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:


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 to range attempts to connect via Telnet:

in.telnetd: 10.0.1.: spawn (/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:

For a full examination of shell commands, as well as some additional access control examples, review the hosts_access(5)man page.


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.