version 1, including all changes.
.
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 |
---- |