Penguin
Blame: hosts_access(5)
EditPageHistoryDiffInfoLikePages
Annotated edit history of hosts_access(5) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 HOSTS_ACCESS
2 !!!HOSTS_ACCESS
3 NAME
4 DESCRIPTION
5 ACCESS CONTROL FILES
6 ACCESS CONTROL RULES
7 PATTERNS
8 WILDCARDS
9 OPERATORS
10 SHELL COMMANDS
11 % EXPANSIONS
12 SERVER ENDPOINT PATTERNS
13 CLIENT USERNAME LOOKUP
14 DETECTING ADDRESS SPOOFING ATTACKS
15 EXAMPLES
16 MOSTLY CLOSED
17 MOSTLY OPEN
18 BOOBY TRAPS
19 DIAGNOSTICS
20 FILES
21 SEE ALSO
22 BUGS
23 AUTHOR
24 ----
25 !!NAME
26
27
28 hosts_access - format of host access control files
29 !!DESCRIPTION
30
31
32 This manual page describes a simple access control language
33 that is based on client (host name/address, user name), and
34 server (process name, host name/address) patterns. Examples
35 are given at the end. The impatient reader is encouraged to
36 skip to the EXAMPLES section for a quick
37 introduction.
38
39
40 The extended version of the access control language is
41 described in the ''hosts_options''(5) document. __Note
42 that this language supersedes the meaning of__
43 ''shell_command'' __as documented
44 below.__
45
46
47 In the following text, ''daemon'' is the the process name
48 of a network daemon process, and ''client'' is the name
49 and/or address of a host requesting service. Network daemon
50 process names are specified in the inetd configuration
51 file.
52 !!ACCESS CONTROL FILES
53
54
55 The access control software consults two files. The search
56 stops at the first match:
57
58
59 Access will be granted when a (daemon,client) pair matches
60 an entry in the ''/etc/hosts.allow'' file.
61
62
63 Otherwise, access will be denied when a (daemon,client) pair
64 matches an entry in the ''/etc/hosts.deny''
65 file.
66
67
68 Otherwise, access will be granted.
69
70
71 A non-existing access control file is treated as if it were
72 an empty file. Thus, access control can be turned off by
73 providing no access control files.
74 !!ACCESS CONTROL RULES
75
76
77 Each access control file consists of zero or more lines of
78 text. These lines are processed in order of appearance. The
79 search terminates when a match is found.
80
81
82 A newline character is ignored when it is preceded by a
83 backslash character. This permits you to break up long lines
84 so that they are easier to edit.
85
86
87 Blank lines or lines that begin with a `#' character are
88 ignored. This permits you to insert comments and whitespace
89 so that the tables are easier to read.
90
91
92 All other lines should satisfy the following format, things
93 between [[] being optional:
94
95
96 daemon_list : client_list [[ : shell_command ]
97
98
99 ''daemon_list'' is a list of one or more daemon process
100 names (argv[[0] values) or wildcards (see
101 below).
102
103
104 ''client_list'' is a list of one or more host names, host
105 addresses, patterns or wildcards (see below) that will be
106 matched against the client host name or
107 address.
108
109
110 The more complex forms ''daemon@host'' and
111 ''user@host'' are explained in the sections on server
112 endpoint patterns and on client username lookups,
113 respectively.
114
115
116 List elements should be separated by blanks and/or
117 commas.
118
119
120 With the exception of NIS (YP) netgroup lookups, all access
121 control checks are case insensitive.
122 !!PATTERNS
123
124
125 The access control language implements the following
126 patterns:
127
128
129 A string that begins with a `.' character. A host name is
130 matched if the last components of its name match the
131 specified pattern. For example, the pattern `.tue.nl'
132 matches the host name `wzv.win.tue.nl'.
133
134
135 A string that ends with a `.' character. A host address is
136 matched if its first numeric fields match the given string.
137 For example, the pattern `131.155.' matches the address of
138 (almost) every host on the Eindhoven University network
139 (131.155.x.x).
140
141
142 A string that begins with an `@' character is treated as an
143 NIS (formerly YP) netgroup name. A host name is matched if
144 it is a host member of the specified netgroup. Netgroup
145 matches are not supported for daemon process names or for
146 client user names.
147
148
149 An expression of the form `n.n.n.n/m.m.m.m' is interpreted
150 as a `net/mask' pair. A host address is matched if `net' is
151 equal to the bitwise AND of the address and the `mask'. For
152 example, the net/mask pattern `131.155.72.0/255.255.254.0'
153 matches every address in the range `131.155.72.0' through
154 `131.155.73.255'.
155
156
157 A string that begins with a `/' character is treated as a
158 file name. A host name or address is matched if it matches
159 any host name or address pattern listed in the named file.
160 The file format is zero or more lines with zero or more host
161 name or address patterns separated by whitespace. A file
162 name pattern can be used anywhere a host name or address
163 pattern can be used.
164 !!WILDCARDS
165
166
167 The access control language supports explicit
168 wildcards:
169
170
171 ALL
172
173
174 The universal wildcard, always matches.
175
176
177 LOCAL
178
179
180 Matches any host whose name does not contain a dot
181 character.
182
183
184 UNKNOWN
185
186
187 Matches any user whose name is unknown, and matches any host
188 whose name ''or'' address are unknown. This pattern
189 should be used with care: host names may be unavailable due
190 to temporary name server problems. A network address will be
191 unavailable when the software cannot figure out what type of
192 network it is talking to.
193
194
195 KNOWN
196
197
198 Matches any user whose name is known, and matches any host
199 whose name ''and'' address are known. This pattern should
200 be used with care: host names may be unavailable due to
201 temporary name server problems. A network address will be
202 unavailable when the software cannot figure out what type of
203 network it is talking to.
204
205
206 PARANOID
207
208
209 Matches any host whose name does not match its address. When
210 tcpd is built with -DPARANOID (default mode), it drops
211 requests from such clients even before looking at the access
212 control tables. Build without -DPARANOID when you want more
213 control over such requests.
214 !!OPERATORS
215
216
217 EXCEPT
218
219
220 Intended use is of the form: `list_1 EXCEPT list_2'; this
221 construct matches anything that matches ''list_1'' unless
222 it matches ''list_2''. The EXCEPT operator can be used in
223 daemon_lists and in client_lists. The EXCEPT operator can be
224 nested: if the control language would permit the use of
225 parentheses, `a EXCEPT b EXCEPT c' would parse as `(a EXCEPT
226 (b EXCEPT c))'.
227 !!SHELL COMMANDS
228
229
230 If the first-matched access control rule contains a shell
231 command, that command is subjected to %
232 /bin/sh'' child process with standard input, output
233 and error connected to ''/dev/null''. Specify an `
234 ''
235
236
237 Shell commands should not rely on the PATH setting of the
238 inetd. Instead, they should use absolute path names, or they
239 should begin with an explicit PATH=whatever
240 statement.
241
242
243 The ''hosts_options''(5) document describes an
244 alternative language that uses the shell command field in a
245 different and incompatible way.
246 !!% EXPANSIONS
247
248
249 The following expansions are available within shell
250 commands:
251
252
253 %a (%A)
254
255
256 The client (server) host address.
257
258
259 %c
260
261
262 Client information: user@host, user@address, a host name, or
263 just an address, depending on how much information is
264 available.
265
266
267 %d
268
269
270 The daemon process name (argv[[0] value).
271
272
273 %h (%H)
274
275
276 The client (server) host name or address, if the host name
277 is unavailable.
278
279
280 %n (%N)
281
282
283 The client (server) host name (or
284
285
286 %p
287
288
289 The daemon process id.
290
291
292 %s
293
294
295 Server information: daemon@host, daemon@address, or just a
296 daemon name, depending on how much information is
297 available.
298
299
300 %u
301
302
303 The client user name (or
304
305
306 %%
307
308
309 Expands to a single `%' character.
310
311
312 Characters in % expansions that may confuse the shell are
313 replaced by underscores.
314 !!SERVER ENDPOINT PATTERNS
315
316
317 In order to distinguish clients by the network address that
318 they connect to, use patterns of the form:
319
320
321 process_name@host_pattern : client_list ...
322
323
324 Patterns like these can be used when the machine has
325 different internet addresses with different internet
326 hostnames. Service providers can use this facility to offer
327 FTP, GOPHER or WWW archives with internet names that may
328 even belong to different organizations. See also the `twist'
329 option in the hosts_options(5) document. Some systems
330 (Solaris, FreeBSD) can have more than one internet address
331 on one physical interface; with other systems you may have
332 to resort to SLIP or PPP pseudo interfaces that live in a
333 dedicated network address space.
334
335
336 The host_pattern obeys the same syntax rules as host names
337 and addresses in client_list context. Usually, server
338 endpoint information is available only with
339 connection-oriented services.
340 !!CLIENT USERNAME LOOKUP
341
342
343 When the client host supports the RFC 931 protocol or one of
344 its descendants (TAP, IDENT, RFC 1413) the wrapper programs
345 can retrieve additional information about the owner of a
346 connection. Client username information, when available, is
347 logged together with the client host name, and can be used
348 to match patterns like:
349
350
351 daemon_list : ... user_pattern@host_pattern ...
352
353
354 The daemon wrappers can be configured at compile time to
355 perform rule-driven username lookups (default) or to always
356 interrogate the client host. In the case of rule-driven
357 username lookups, the above rule would cause username lookup
358 only when both the ''daemon_list'' and the
359 ''host_pattern'' match.
360
361
362 A user pattern has the same syntax as a daemon process
363 pattern, so the same wildcards apply (netgroup membership is
364 not supported). One should not get carried away with
365 username lookups, though.
366
367
368 The client username information cannot be trusted when it is
369 needed most, i.e. when the client system has been
370 compromised. In general, ALL and (UN)KNOWN are the only user
371 name patterns that make sense.
372
373
374 Username lookups are possible only with TCP-based services,
375 and only when the client host runs a suitable daemon; in all
376 other cases the result is
377
378
379 A well-known UNIX kernel bug may cause loss of service when
380 username lookups are blocked by a firewall. The wrapper
381 README document describes a procedure to find out if your
382 kernel has this bug.
383
384
385 Username lookups may cause noticeable delays for non-UNIX
386 users. The default timeout for username lookups is 10
387 seconds: too short to cope with slow networks, but long
388 enough to irritate PC users.
389
390
391 Selective username lookups can alleviate the last problem.
392 For example, a rule like:
393
394
395 daemon_list : @pcnetgroup ALL@ALL
396
397
398 would match members of the pc netgroup without doing
399 username lookups, but would perform username lookups with
400 all other systems.
401 !!DETECTING ADDRESS SPOOFING ATTACKS
402
403
404 A flaw in the sequence number generator of many TCP/IP
405 implementations allows intruders to easily impersonate
406 trusted hosts and to break in via, for example, the remote
407 shell service. The IDENT (RFC931 etc.) service can be used
408 to detect such and other host address spoofing
409 attacks.
410
411
412 Before accepting a client request, the wrappers can use the
413 IDENT service to find out that the client did not send the
414 request at all. When the client host provides IDENT service,
415 a negative IDENT lookup result (the client matches
416 `UNKNOWN@host') is strong evidence of a host spoofing
417 attack.
418
419
420 A positive IDENT lookup result (the client matches
421 `KNOWN@host') is less trustworthy. It is possible for an
422 intruder to spoof both the client connection and the IDENT
423 lookup, although doing so is much harder than spoofing just
424 a client connection. It may also be that the client's IDENT
425 server is lying.
426
427
428 Note: IDENT lookups don't work with UDP
429 services.
430 !!EXAMPLES
431
432
433 The language is flexible enough that different types of
434 access control policy can be expressed with a minimum of
435 fuss. Although the language uses two access control tables,
436 the most common policies can be implemented with one of the
437 tables being trivial or even empty.
438
439
440 When reading the examples below it is important to realize
441 that the allow table is scanned before the deny table, that
442 the search terminates when a match is found, and that access
443 is granted when no match is found at all.
444
445
446 The examples use host and domain names. They can be improved
447 by including address and/or network/netmask information, to
448 reduce the impact of temporary name server lookup
449 failures.
450 !!MOSTLY CLOSED
451
452
453 In this case, access is denied by default. Only explicitly
454 authorized hosts are permitted access.
455
456
457 The default policy (no access) is implemented with a trivial
458 deny file:
459
460
461 /etc/hosts.deny:
462
463
464 ALL: ALL
465
466
467 This denies all service to all hosts, unless they are
468 permitted access by entries in the allow file.
469
470
471 The explicitly authorized hosts are listed in the allow
472 file. For example:
473
474
475 /etc/hosts.allow:
476
477
478 ALL: LOCAL @some_netgroup
479 ALL: .foobar.edu EXCEPT
480 terminalserver.foobar.edu
481
482
483 The first rule permits access from hosts in the local domain
484 (no `.' in the host name) and from members of the
485 ''some_netgroup'' netgroup. The second rule permits
486 access from all hosts in the ''foobar.edu'' domain
487 (notice the leading dot), with the exception of
488 ''terminalserver.foobar.edu''.
489 !!MOSTLY OPEN
490
491
492 Here, access is granted by default; only explicitly
493 specified hosts are refused service.
494
495
496 The default policy (access granted) makes the allow file
497 redundant so that it can be omitted. The explicitly
498 non-authorized hosts are listed in the deny file. For
499 example:
500
501
502 /etc/hosts.deny:
503
504
505 ALL: some.host.name, .some.domain
506 ALL EXCEPT in.fingerd: other.host.name,
507 .other.domain
508
509
510 The first rule denies some hosts and domains all services;
511 the second rule still permits finger requests from other
512 hosts and domains.
513 !!BOOBY TRAPS
514
515
516 The next example permits tftp requests from hosts in the
517 local domain (notice the leading dot). Requests from any
518 other hosts are denied. Instead of the requested file, a
519 finger probe is sent to the offending host. The result is
520 mailed to the superuser.
521
522
523 /etc/hosts.allow:
524
525
526 in.tftpd: LOCAL, .my.domain
527 /etc/hosts.deny:
528 in.tftpd: ALL: (/usr/sbin/safe_finger -l @%h | \
529 /usr/bin/mail -s %d-%h root)
530
531
532 The safe_finger command comes with the tcpd wrapper and
533 should be installed in a suitable place. It limits possible
534 damage from data sent by the remote finger server. It gives
535 better protection than the standard finger
536 command.
537
538
539 The expansion of the %h (client host) and %d (service name)
540 sequences is described in the section on shell
541 commands.
542
543
544 Warning: do not booby-trap your finger daemon, unless you
545 are prepared for infinite finger loops.
546
547
548 On network firewall systems this trick can be carried even
549 further. The typical network firewall only provides a
550 limited set of services to the outer world. All other
551 services can be
552 !!DIAGNOSTICS
553
554
555 An error is reported when a syntax error is found in a host
556 access control rule; when the length of an access control
557 rule exceeds the capacity of an internal buffer; when an
558 access control rule is not terminated by a newline
559 character; when the result of %
560 !!FILES
561
562
563 /etc/hosts.allow, (daemon,client) pairs that are granted access.
564 /etc/hosts.deny, (daemon,client) pairs that are denied access.
565 !!SEE ALSO
566
567
568 tcpd(8) tcp/ip daemon wrapper program.
569 tcpdchk(8), tcpdmatch(8), test programs.
570 !!BUGS
571
572
573 If a name server lookup times out, the host name will not be
574 available to the access control software, even though the
575 host is registered.
576
577
578 Domain name server lookups are case insensitive; NIS
579 (formerly YP) netgroup lookups are case
580 sensitive.
581 !!AUTHOR
582
583
584 Wietse Venema (wietse@wzv.win.tue.nl)
585 Department of Mathematics and Computing Science
586 Eindhoven University of Technology
587 Den Dolech 2, P.O. Box 513,
588 5600 MB Eindhoven, The Netherlands
589 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.