hosts_access.5 (2010 09)

h
hosts_access(5) hosts_access(5)
A positive IDENT lookup result (the client matches
KNOWN@host) is less reliable. It is possible for an
intruder to spoof both the client connection and the IDENT lookup, although doing so is much harder
than spoofing just a client connection. It may also be possible that the client’s IDENT server is lying.
NOTE: IDENT lookups do not work with UDP services.
EXAMPLES
The language is flexible enough that different types of access control policy can be expressed with a
minimum of effort. Although the language uses two access control tables, the most common policies can
be implemented with one of the tables being trivial or even empty.
When reading the examples below, it is important to realize that the allow table is scanned before the
deny table. The search terminates when a match is found, and access is granted when no match is found
at all.
The examples use host and domain names. They can be improved by including address and/or
network/netmask information to reduce the impact of temporary name server lookup failures.
Mostly Closed Access Control
In this example, access is denied by default. Only explicitly authorized hosts are permitted access.
The default policy (no access) is implemented with a trivial deny file:
/etc/hosts.deny:
ALL: ALL
This denies all services to all the hosts unless they are permitted access by entries in the allow file.
The explicitly authorized hosts are listed in the allow file. For example:
/etc/hosts.allow:
ALL: LOCAL @some_netgroup
ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
The first rule permits access from hosts in the local domain (there is no dot "." in the host name) and from
members of the some_netgroup netgroup. The second rule permits access from all hosts in the
foobar.edu domain (notice the leading dot "." in .foobar.edu), with the exception of
terminalserver.foobar.edu.
Mostly Open Access Control
Here, access is granted by default. Only explicitly specified hosts are refused service.
The default policy (access granted) makes the allow file redundant so that it can be omitted. The expli-
citly non-authorized hosts are listed in the deny file. For example:
/etc/hosts.deny:
ALL: some.host.name, .some.domain
ALL EXCEPT fingerd: other.host.name, .other.domain
The first rule denies some hosts and domains all services. The second rule still permits finger requests
from other hosts and domains.
Setting Traps
The next example permits
tftp requests from hosts in the local domain (notice the leading dot).
Requests from any other hosts are denied and instead of the requested file, a finger probe is sent to the
offending host. The result is mailed to the superuser.
/etc/hosts.allow:
tftpd: LOCAL, .my.domain
/etc/hosts.deny:
tftpd: ALL: spawn (/usr/bin/sffinger -l @%h | \
/usr/bin/mailx -s %d-%h root) &
The sffinger command comes with tcp wrappers. It limits possible damage from data sent by the
remote finger server. It gives better protection than the standard finger command.
The expansion of the
%h (client host) and %d (service name) sequences is described earlier in the "Shell
Commands" section.
4 Hewlett-Packard Company − 4 − HP-UX 11i Version 3: September 2010