1HOSTS_ACCESS(5) File Formats Manual HOSTS_ACCESS(5)
2
6 hosts_access - format of host access control files
7
9 This manual page describes a simple access control language that is
10 based on client (host name/address, user name), and server (process
11 name, host name/address) patterns. Examples are given at the end. The
12 impatient reader is encouraged to skip to the EXAMPLES section for a
13 quick introduction.
14 An extended version of the access control language is described in the
16 hosts_options(5) document. The extensions are turned on at program
17 build time by building with -DPROCESS_OPTIONS.
18 In the following text, daemon is the the process name of a network dae‐
20 mon process, and client is the name and/or address of a host requesting
21 service. Network daemon process names are specified in the inetd con‐
22 figuration file.
23
25 The access control software consults two files. The search stops at the
26 first match:
27 · Access will be granted when a (daemon,client) pair matches an
29 entry in the /etc/hosts.allow file.
30 · Otherwise, access will be denied when a (daemon,client) pair
32 matches an entry in the /etc/hosts.deny file.
33 · Otherwise, access will be granted.
35 A non-existing access control file is treated as if it were an empty
37 file. Thus, access control can be turned off by providing no access
38 control files.
39
41 Each access control file consists of zero or more lines of text. These
42 lines are processed in order of appearance. The search terminates when
43 a match is found.
44 · A newline character is ignored when it is preceded by a back‐
46 slash character. This permits you to break up long lines so that
47 they are easier to edit.
48 · Blank lines or lines that begin with a `#´ character are
50 ignored. This permits you to insert comments and whitespace so
51 that the tables are easier to read.
52 · All other lines should satisfy the following format, things
54 between [] being optional:
55 daemon_list : client_list [ : shell_command ]
57 daemon_list is a list of one or more daemon process names (argv[0] val‐
59 ues) or wildcards (see below).
60 client_list is a list of one or more host names, host addresses, pat‐
62 terns or wildcards (see below) that will be matched against the client
63 host name or address.
64 The more complex forms daemon@host and user@host are explained in the
66 sections on server endpoint patterns and on client username lookups,
67 respectively.
68 List elements should be separated by blanks and/or commas.
70 With the exception of NIS (YP) netgroup lookups, all access control
72 checks are case insensitive.
73
75 The access control language implements the following patterns:
76 · A string that begins with a `.´ character. A host name is
78 matched if the last components of its name match the specified
79 pattern. For example, the pattern `.tue.nl´ matches the host
80 name `wzv.win.tue.nl´.
81 · A string that ends with a `.´ character. A host address is
83 matched if its first numeric fields match the given string. For
84 example, the pattern `131.155.´ matches the address of (almost)
85 every host on the Eindhoven University network (131.155.x.x).
86 · A string that begins with an `@´ character is treated as an NIS
88 (formerly YP) netgroup name. A host name is matched if it is a
89 host member of the specified netgroup. Netgroup matches are not
90 supported for daemon process names or for client user names.
91 · An expression of the form `n.n.n.n/m.m.m.m´ is interpreted as a
93 `net/mask´ pair. An IPv4 host address is matched if `net´ is
94 equal to the bitwise AND of the address and the `mask´. For
95 example, the net/mask pattern `131.155.72.0/255.255.254.0´
96 matches every address in the range `131.155.72.0´ through
97 `131.155.73.255´.
98 · An expression of the form `[n:n:n:n:n:n:n:n]/m´ is interpreted
100 as a `[net]/prefixlen´ pair. An IPv6 host address is matched if
101 `prefixlen´ bits of `net´ is equal to the `prefixlen´ bits of
102 the address. For example, the [net]/prefixlen pattern
103 `[3ffe:505:2:1::]/64´ matches every address in the range
104 `3ffe:505:2:1::´ through `3ffe:505:2:1:ffff:ffff:ffff:ffff´.
105 · A string that begins with a `/´ character is treated as a file
107 name. A host name or address is matched if it matches any host
108 name or address pattern listed in the named file. The file for‐
109 mat is zero or more lines with zero or more host name or address
110 patterns separated by whitespace. A file name pattern can be
111 used anywhere a host name or address pattern can be used.
112 · Wildcards `*´ and `?´ can be used to match hostnames or IP
114 addresses. This method of matching cannot be used in conjunc‐
115 tion with `net/mask´ matching, hostname matching beginning with
116 `.´ or IP address matching ending with `.´.
117
119 The access control language supports explicit wildcards:
120 ALL The universal wildcard, always matches.
122 LOCAL Matches any host whose name does not contain a dot character.
124 UNKNOWN
126 Matches any user whose name is unknown, and matches any host
127 whose name or address are unknown. This pattern should be used
128 with care: host names may be unavailable due to temporary name
129 server problems. A network address will be unavailable when the
130 software cannot figure out what type of network it is talking
131 to.
132 KNOWN Matches any user whose name is known, and matches any host whose
134 name and address are known. This pattern should be used with
135 care: host names may be unavailable due to temporary name server
136 problems. A network address will be unavailable when the soft‐
137 ware cannot figure out what type of network it is talking to.
138 PARANOID
140 Matches any host whose name does not match its address. When
141 tcpd is built with -DPARANOID (default mode), it drops requests
142 from such clients even before looking at the access control
143 tables. Build without -DPARANOID when you want more control
144 over such requests.
145
147 EXCEPT Intended use is of the form: `list_1 EXCEPT list_2´; this con‐
148 struct matches anything that matches list_1 unless it matches
149 list_2. The EXCEPT operator can be used in daemon_lists and in
150 client_lists. The EXCEPT operator can be nested: if the control
151 language would permit the use of parentheses, `a EXCEPT b EXCEPT
152 c´ would parse as `(a EXCEPT (b EXCEPT c))´.
153
155 If the first-matched access control rule contains a shell command, that
156 command is subjected to %<letter> substitutions (see next section).
157 The result is executed by a /bin/sh child process with standard input,
158 output and error connected to /dev/null. Specify an `&´ at the end of
159 the command if you do not want to wait until it has completed.
160 Shell commands should not rely on the PATH setting of the inetd.
162 Instead, they should use absolute path names, or they should begin with
163 an explicit PATH=whatever statement.
164 The hosts_options(5) document describes an alternative language that
166 uses the shell command field in a different and incompatible way.
167
169 The following expansions are available within shell commands:
170 %a (%A)
172 The client (server) host address.
173 %c Client information: user@host, user@address, a host name, or
175 just an address, depending on how much information is available.
176 %d The daemon process name (argv[0] value).
178 %h (%H)
180 The client (server) host name or address, if the host name is
181 unavailable.
182 %n (%N)
184 The client (server) host name (or "unknown" or "paranoid").
185 %p The daemon process id.
187 %s Server information: daemon@host, daemon@address, or just a dae‐
189 mon name, depending on how much information is available.
190 %u The client user name (or "unknown").
192 %% Expands to a single `%´ character.
194 Characters in % expansions that may confuse the shell are replaced by
196 underscores.
197
199 In order to distinguish clients by the network address that they con‐
200 nect to, use patterns of the form:
201 process_name@host_pattern : client_list ...
203 Patterns like these can be used when the machine has different internet
205 addresses with different internet hostnames. Service providers can use
206 this facility to offer FTP, GOPHER or WWW archives with internet names
207 that may even belong to different organizations. See also the `twist'
208 option in the hosts_options(5) document. Some systems (Solaris, Free‐
209 BSD) can have more than one internet address on one physical interface;
210 with other systems you may have to resort to SLIP or PPP pseudo inter‐
211 faces that live in a dedicated network address space.
212 The host_pattern obeys the same syntax rules as host names and
214 addresses in client_list context. Usually, server endpoint information
215 is available only with connection-oriented services.
216
218 When the client host supports the RFC 931 protocol or one of its
219 descendants (TAP, IDENT, RFC 1413) the wrapper programs can retrieve
220 additional information about the owner of a connection. Client username
221 information, when available, is logged together with the client host
222 name, and can be used to match patterns like:
223 daemon_list : ... user_pattern@host_pattern ...
225 The daemon wrappers can be configured at compile time to perform rule-
227 driven username lookups (default) or to always interrogate the client
228 host. In the case of rule-driven username lookups, the above rule
229 would cause username lookup only when both the daemon_list and the
230 host_pattern match.
231 A user pattern has the same syntax as a daemon process pattern, so the
233 same wildcards apply (netgroup membership is not supported). One
234 should not get carried away with username lookups, though.
235 · The client username information cannot be trusted when it is
237 needed most, i.e. when the client system has been compromised.
238 In general, ALL and (UN)KNOWN are the only user name patterns
239 that make sense.
240 · Username lookups are possible only with TCP-based services, and
242 only when the client host runs a suitable daemon; in all other
243 cases the result is "unknown".
244 · A well-known UNIX kernel bug may cause loss of service when
246 username lookups are blocked by a firewall. The wrapper README
247 document describes a procedure to find out if your kernel has
248 this bug.
249 · Username lookups may cause noticeable delays for non-UNIX users.
251 The default timeout for username lookups is 10 seconds: too
252 short to cope with slow networks, but long enough to irritate PC
253 users.
254 Selective username lookups can alleviate the last problem. For example,
256 a rule like:
257 daemon_list : @pcnetgroup ALL@ALL
259 would match members of the pc netgroup without doing username lookups,
261 but would perform username lookups with all other systems.
262
264 A flaw in the sequence number generator of many TCP/IP implementations
265 allows intruders to easily impersonate trusted hosts and to break in
266 via, for example, the remote shell service. The IDENT (RFC931 etc.)
267 service can be used to detect such and other host address spoofing
268 attacks.
269 Before accepting a client request, the wrappers can use the IDENT ser‐
271 vice to find out that the client did not send the request at all. When
272 the client host provides IDENT service, a negative IDENT lookup result
273 (the client matches `UNKNOWN@host') is strong evidence of a host spoof‐
274 ing attack.
275 A positive IDENT lookup result (the client matches `KNOWN@host') is
277 less trustworthy. It is possible for an intruder to spoof both the
278 client connection and the IDENT lookup, although doing so is much
279 harder than spoofing just a client connection. It may also be that the
280 client´s IDENT server is lying.
281 Note: IDENT lookups don´t work with UDP services.
283
285 The language is flexible enough that different types of access control
286 policy can be expressed with a minimum of fuss. Although the language
287 uses two access control tables, the most common policies can be imple‐
288 mented with one of the tables being trivial or even empty.
289 When reading the examples below it is important to realize that the
291 allow table is scanned before the deny table, that the search termi‐
292 nates when a match is found, and that access is granted when no match
293 is found at all.
294 The examples use host and domain names. They can be improved by includ‐
296 ing address and/or network/netmask information, to reduce the impact of
297 temporary name server lookup failures.
298
300 In this case, access is denied by default. Only explicitly authorized
301 hosts are permitted access.
302 The default policy (no access) is implemented with a trivial deny file:
304 /etc/hosts.deny:
306 ALL: ALL
307 This denies all service to all hosts, unless they are permitted access
309 by entries in the allow file.
310 The explicitly authorized hosts are listed in the allow file. For
312 example:
313 /etc/hosts.allow:
315 ALL: LOCAL @some_netgroup
316 ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
317 The first rule permits access from hosts in the local domain (no `.´ in
319 the host name) and from members of the some_netgroup netgroup. The
320 second rule permits access from all hosts in the foobar.edu domain
321 (notice the leading dot), with the exception of terminalserver.foo‐
322 bar.edu.
323
325 Here, access is granted by default; only explicitly specified hosts are
326 refused service.
327 The default policy (access granted) makes the allow file redundant so
329 that it can be omitted. The explicitly non-authorized hosts are listed
330 in the deny file. For example:
331 /etc/hosts.deny:
333 ALL: some.host.name, .some.domain
334 ALL EXCEPT in.fingerd: other.host.name, .other.domain
335 The first rule denies some hosts and domains all services; the second
337 rule still permits finger requests from other hosts and domains.
338
340 The next example permits tftp requests from hosts in the local domain
341 (notice the leading dot). Requests from any other hosts are denied.
342 Instead of the requested file, a finger probe is sent to the offending
343 host. The result is mailed to the superuser.
344 /etc/hosts.allow:
346 in.tftpd: LOCAL, .my.domain
347 /etc/hosts.deny:
349 in.tftpd: ALL: spawn (/some/where/safe_finger -l @%h | \
350 /usr/ucb/mail -s %d-%h root) &
351 The safe_finger command comes with the tcpd wrapper and should be
353 installed in a suitable place. It limits possible damage from data sent
354 by the remote finger server. It gives better protection than the stan‐
355 dard finger command.
356 The expansion of the %h (client host) and %d (service name) sequences
358 is described in the section on shell commands.
359 Warning: do not booby-trap your finger daemon, unless you are prepared
361 for infinite finger loops.
362 On network firewall systems this trick can be carried even further.
364 The typical network firewall only provides a limited set of services to
365 the outer world. All other services can be "bugged" just like the above
366 tftp example. The result is an excellent early-warning system.
367
369 An error is reported when a syntax error is found in a host access con‐
370 trol rule; when the length of an access control rule exceeds the capac‐
371 ity of an internal buffer; when an access control rule is not termi‐
372 nated by a newline character; when the result of %<letter> expansion
373 would overflow an internal buffer; when a system call fails that
374 shouldn´t. All problems are reported via the syslog daemon.
375
377 /etc/hosts.allow, (daemon,client) pairs that are granted access.
378 /etc/hosts.deny, (daemon,client) pairs that are denied access.
379
381 tcpd(8) tcp/ip daemon wrapper program.
382 tcpdchk(8), tcpdmatch(8), test programs.
383
385 If a name server lookup times out, the host name will not be available
386 to the access control software, even though the host is registered.
387 Domain name server lookups are case insensitive; NIS (formerly YP) net‐
389 group lookups are case sensitive.
390
392 Wietse Venema (wietse@wzv.win.tue.nl)
393 Department of Mathematics and Computing Science
394 Eindhoven University of Technology
395 Den Dolech 2, P.O. Box 513,
396 5600 MB Eindhoven, The Netherlands
397 HOSTS_ACCESS(5)