Red Hat LINUX 7.2 Reference Manual page 148

148
Organizationally, it usually makes more sense to use EXCEPT operators spar-
ingly, 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:
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:
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 informa-
tion 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) &
Chapter 9:TCP Wrappers and xinetd
Note
10.0.1.24 or in.ftpd:
192.168.0.2.
WARNING
10.0.1.