120

Chapter 8. TCP Wrappers and

xinetd

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.

8.2.1. 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 its own

line.

The rules must be formatted in the following manner:

D

daemon_list :

D

client_list [: spawn

D

shell_command

]

E

E

E

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 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 to share access control lists between

various services, as changes would only need to be made in 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 the

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.