1.TH HOSTS_ACCESS 5
2.SH NAME
3hosts_access \- format of host access control files
4.SH DESCRIPTION
5This manual page describes a simple access control language that is
6based on client (host name/address, user name), and server (process
7name, host name/address) patterns. Examples are given at the end. The
8impatient reader is encouraged to skip to the EXAMPLES section for a
9quick introduction.
10.PP
11An extended version of the access control language is described in the
12\fIhosts_options\fR(5) document. The extensions are turned on at
13program build time by building with -DPROCESS_OPTIONS.
14.PP
15In the following text, \fIdaemon\fR is the the process name of a
16network daemon process, and \fIclient\fR is the name and/or address of
17a host requesting service. Network daemon process names are specified
18in the inetd configuration file.
19.SH ACCESS CONTROL FILES
20The access control software consults two files. The search stops
21at the first match:
22.IP \(bu
23Access will be granted when a (daemon,client) pair matches an entry in
24the \fI/etc/hosts.allow\fR file.
25.IP \(bu
26Otherwise, access will be denied when a (daemon,client) pair matches an
27entry in the \fI/etc/hosts.deny\fR file.
28.IP \(bu
29Otherwise, access will be granted.
30.PP
31A non-existing access control file is treated as if it were an empty
32file. Thus, access control can be turned off by providing no access
33control files.
34.SH ACCESS CONTROL RULES
35Each access control file consists of zero or more lines of text. These
36lines are processed in order of appearance. The search terminates when a
37match is found.
38.IP \(bu
39A newline character is ignored when it is preceded by a backslash
40character. This permits you to break up long lines so that they are
41easier to edit.
42.IP \(bu
43Blank lines or lines that begin with a `#\' character are ignored.
44This permits you to insert comments and whitespace so that the tables
45are easier to read.
46.IP \(bu
47All other lines should satisfy the following format, things between []
48being optional:
49.sp
50.ti +3
51daemon_list : client_list [ : shell_command ]
52.PP
53\fIdaemon_list\fR is a list of one or more daemon process names
54(argv[0] values) or wildcards (see below).
55.PP
56\fIclient_list\fR is a list
57of one or more host names, host addresses, patterns or wildcards (see
58below) that will be matched against the client host name or address.
59.PP
60The more complex forms \fIdaemon@host\fR and \fIuser@host\fR are
61explained in the sections on server endpoint patterns and on client
62username lookups, respectively.
63.PP
64List elements should be separated by blanks and/or commas.
65.PP
66With the exception of NIS (YP) netgroup lookups, all access control
67checks are case insensitive.
68.ne 4
69.SH PATTERNS
70The access control language implements the following patterns:
71.IP \(bu
72A string that begins with a `.\' character. A host name is matched if
73the last components of its name match the specified pattern. For
74example, the pattern `.tue.nl\' matches the host name
75`wzv.win.tue.nl\'.
76.IP \(bu
77A string that ends with a `.\' character. A host address is matched if
78its first numeric fields match the given string. For example, the
79pattern `131.155.\' matches the address of (almost) every host on the
80Eind\%hoven University network (131.155.x.x).
81.IP \(bu
82A string that begins with an `@\' character is treated as an NIS
83(formerly YP) netgroup name. A host name is matched if it is a host
84member of the specified netgroup. Netgroup matches are not supported
85for daemon process names or for client user names.
86.IP \(bu
87An expression of the form `n.n.n.n/m.m.m.m\' is interpreted as a
88`net/mask\' pair. A host address is matched if `net\' is equal to the
89bitwise AND of the address and the `mask\'. For example, the net/mask
90pattern `131.155.72.0/255.255.254.0\' matches every address in the
91range `131.155.72.0\' through `131.155.73.255\'.
92.IP \(bu
93A string that begins with a `/\' character is treated as a file
94name. A host name or address is matched if it matches any host name
95or address pattern listed in the named file. The file format is
96zero or more lines with zero or more host name or address patterns
97separated by whitespace. A file name pattern can be used anywhere
98a host name or address pattern can be used.
99.SH WILDCARDS
100The access control language supports explicit wildcards:
101.IP ALL
102The universal wildcard, always matches.
103.IP LOCAL
104Matches any host whose name does not contain a dot character.
105.IP UNKNOWN
106Matches any user whose name is unknown, and matches any host whose name
107\fIor\fR address are unknown. This pattern should be used with care:
108host names may be unavailable due to temporary name server problems. A
109network address will be unavailable when the software cannot figure out
110what type of network it is talking to.
111.IP KNOWN
112Matches any user whose name is known, and matches any host whose name
113\fIand\fR address are known. This pattern should be used with care:
114host names may be unavailable due to temporary name server problems. A
115network address will be unavailable when the software cannot figure out
116what type of network it is talking to.
117.IP PARANOID
118Matches any host whose name does not match its address. When tcpd is
119built with -DPARANOID (default mode), it drops requests from such
120clients even before looking at the access control tables. Build
121without -DPARANOID when you want more control over such requests.
122.ne 6
123.SH OPERATORS
124.IP EXCEPT
125Intended use is of the form: `list_1 EXCEPT list_2\'; this construct
126matches anything that matches \fIlist_1\fR unless it matches
127\fIlist_2\fR. The EXCEPT operator can be used in daemon_lists and in
128client_lists. The EXCEPT operator can be nested: if the control
129language would permit the use of parentheses, `a EXCEPT b EXCEPT c\'
130would parse as `(a EXCEPT (b EXCEPT c))\'.
131.br
132.ne 6
133.SH SHELL COMMANDS
134If the first-matched access control rule contains a shell command, that
135command is subjected to %<letter> substitutions (see next section).
136The result is executed by a \fI/bin/sh\fR child process with standard
137input, output and error connected to \fI/dev/null\fR. Specify an `&\'
138at the end of the command if you do not want to wait until it has
139completed.
140.PP
141Shell commands should not rely on the PATH setting of the inetd.
142Instead, they should use absolute path names, or they should begin with
143an explicit PATH=whatever statement.
144.PP
145The \fIhosts_options\fR(5) document describes an alternative language
146that uses the shell command field in a different and incompatible way.
147.SH % EXPANSIONS
148The following expansions are available within shell commands:
149.IP "%a (%A)"
150The client (server) host address.
151.IP %c
152Client information: user@host, user@address, a host name, or just an
153address, depending on how much information is available.
154.IP %d
155The daemon process name (argv[0] value).
156.IP "%h (%H)"
157The client (server) host name or address, if the host name is
158unavailable.
159.IP "%n (%N)"
160The client (server) host name (or "unknown" or "paranoid").
161.IP %p
162The daemon process id.
163.IP %s
164Server information: daemon@host, daemon@address, or just a daemon name,
165depending on how much information is available.
166.IP %u
167The client user name (or "unknown").
168.IP %%
169Expands to a single `%\' character.
170.PP
171Characters in % expansions that may confuse the shell are replaced by
172underscores.
173.SH SERVER ENDPOINT PATTERNS
174In order to distinguish clients by the network address that they
175connect to, use patterns of the form:
176.sp
177.ti +3
178process_name@host_pattern : client_list ...
179.sp
180Patterns like these can be used when the machine has different internet
181addresses with different internet hostnames. Service providers can use
182this facility to offer FTP, GOPHER or WWW archives with internet names
183that may even belong to different organizations. See also the `twist'
184option in the hosts_options(5) document. Some systems (Solaris,
185FreeBSD) can have more than one internet address on one physical
186interface; with other systems you may have to resort to SLIP or PPP
187pseudo interfaces that live in a dedicated network address space.
188.sp
189The host_pattern obeys the same syntax rules as host names and
190addresses in client_list context. Usually, server endpoint information
191is available only with connection-oriented services.
192.SH CLIENT USERNAME LOOKUP
193When the client host supports the RFC 931 protocol or one of its
194descendants (TAP, IDENT, RFC 1413) the wrapper programs can retrieve
195additional information about the owner of a connection. Client username
196information, when available, is logged together with the client host
197name, and can be used to match patterns like:
198.PP
199.ti +3
200daemon_list : ... user_pattern@host_pattern ...
201.PP
202The daemon wrappers can be configured at compile time to perform
203rule-driven username lookups (default) or to always interrogate the
204client host. In the case of rule-driven username lookups, the above
205rule would cause username lookup only when both the \fIdaemon_list\fR
206and the \fIhost_pattern\fR match.
207.PP
208A user pattern has the same syntax as a daemon process pattern, so the
209same wildcards apply (netgroup membership is not supported). One
210should not get carried away with username lookups, though.
211.IP \(bu
212The client username information cannot be trusted when it is needed
213most, i.e. when the client system has been compromised. In general,
214ALL and (UN)KNOWN are the only user name patterns that make sense.
215.IP \(bu
216Username lookups are possible only with TCP-based services, and only
217when the client host runs a suitable daemon; in all other cases the
218result is "unknown".
219.IP \(bu
220A well-known UNIX kernel bug may cause loss of service when username
221lookups are blocked by a firewall. The wrapper README document
222describes a procedure to find out if your kernel has this bug.
223.IP \(bu
224Username lookups may cause noticeable delays for non-UNIX users. The
225default timeout for username lookups is 10 seconds: too short to cope
226with slow networks, but long enough to irritate PC users.
227.PP
228Selective username lookups can alleviate the last problem. For example,
229a rule like:
230.PP
231.ti +3
232daemon_list : @pcnetgroup ALL@ALL
233.PP
234would match members of the pc netgroup without doing username lookups,
235but would perform username lookups with all other systems.
236.SH DETECTING ADDRESS SPOOFING ATTACKS
237A flaw in the sequence number generator of many TCP/IP implementations
238allows intruders to easily impersonate trusted hosts and to break in
239via, for example, the remote shell service. The IDENT (RFC931 etc.)
240service can be used to detect such and other host address spoofing
241attacks.
242.PP
243Before accepting a client request, the wrappers can use the IDENT
244service to find out that the client did not send the request at all.
245When the client host provides IDENT service, a negative IDENT lookup
246result (the client matches `UNKNOWN@host') is strong evidence of a host
247spoofing attack.
248.PP
249A positive IDENT lookup result (the client matches `KNOWN@host') is
250less trustworthy. It is possible for an intruder to spoof both the
251client connection and the IDENT lookup, although doing so is much
252harder than spoofing just a client connection. It may also be that
253the client\'s IDENT server is lying.
254.PP
255Note: IDENT lookups don\'t work with UDP services.
256.SH EXAMPLES
257The language is flexible enough that different types of access control
258policy can be expressed with a minimum of fuss. Although the language
259uses two access control tables, the most common policies can be
260implemented with one of the tables being trivial or even empty.
261.PP
262When reading the examples below it is important to realize that the
263allow table is scanned before the deny table, that the search
264terminates when a match is found, and that access is granted when no
265match is found at all.
266.PP
267The examples use host and domain names. They can be improved by
268including address and/or network/netmask information, to reduce the
269impact of temporary name server lookup failures.
270.SH MOSTLY CLOSED
271In this case, access is denied by default. Only explicitly authorized
272hosts are permitted access.
273.PP
274The default policy (no access) is implemented with a trivial deny
275file:
276.PP
277.ne 2
278/etc/hosts.deny:
279.in +3
280ALL: ALL
281.PP
282This denies all service to all hosts, unless they are permitted access
283by entries in the allow file.
284.PP
285The explicitly authorized hosts are listed in the allow file.
286For example:
287.PP
288.ne 2
289/etc/hosts.allow:
290.in +3
291ALL: LOCAL @some_netgroup
292.br
293ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
294.PP
295The first rule permits access from hosts in the local domain (no `.\'
296in the host name) and from members of the \fIsome_netgroup\fP
297netgroup. The second rule permits access from all hosts in the
298\fIfoobar.edu\fP domain (notice the leading dot), with the exception of
299\fIterminalserver.foobar.edu\fP.
300.SH MOSTLY OPEN
301Here, access is granted by default; only explicitly specified hosts are
302refused service.
303.PP
304The default policy (access granted) makes the allow file redundant so
305that it can be omitted. The explicitly non-authorized hosts are listed
306in the deny file. For example:
307.PP
308/etc/hosts.deny:
309.in +3
310ALL: some.host.name, .some.domain
311.br
312ALL EXCEPT in.fingerd: other.host.name, .other.domain
313.PP
314The first rule denies some hosts and domains all services; the second
315rule still permits finger requests from other hosts and domains.
316.SH BOOBY TRAPS
317The next example permits tftp requests from hosts in the local domain
318(notice the leading dot). Requests from any other hosts are denied.
319Instead of the requested file, a finger probe is sent to the offending
320host. The result is mailed to the superuser.
321.PP
322.ne 2
323/etc/hosts.allow:
324.in +3
325.nf
326in.tftpd: LOCAL, .my.domain
327.PP
328.ne 2
329/etc/hosts.deny:
330.in +3
331.nf
332in.tftpd: ALL: (/some/where/safe_finger -l @%h | \\
333 /usr/ucb/mail -s %d-%h root) &
334.fi
335.PP
336The safe_finger command is intended for use in back-fingering and should be
337installed in a suitable place. It limits possible damage from data sent
338by the remote finger server. It gives better protection than the
339standard finger command.
340.PP
341The expansion of the %h (client host) and %d (service name) sequences
342is described in the section on shell commands.
343.PP
344Warning: do not booby-trap your finger daemon, unless you are prepared
345for infinite finger loops.
346.PP
347On network firewall systems this trick can be carried even further.
348The typical network firewall only provides a limited set of services to
349the outer world. All other services can be "bugged" just like the above
350tftp example. The result is an excellent early-warning system.
351.br
352.ne 4
353.SH DIAGNOSTICS
354An error is reported when a syntax error is found in a host access
355control rule; when the length of an access control rule exceeds the
356capacity of an internal buffer; when an access control rule is not
357terminated by a newline character; when the result of %<letter>
358expansion would overflow an internal buffer; when a system call fails
359that shouldn\'t. All problems are reported via the syslog daemon.
360.SH IMPLEMENTATION NOTES
361Some operating systems are distributed with TCP Wrappers as part of the
362base system. It is common for such systems to build wrapping functionality
363into networking utilities. Notably, some systems offer an \fIinetd\fR(8)
364which does not require the use of the \fItcpd\fR(8). Check your system's
365documentation for details.
366.SH FILES
367.na
368.nf
369/etc/hosts.allow, (daemon,client) pairs that are granted access.
370/etc/hosts.deny, (daemon,client) pairs that are denied access.
371.ad
372.fi
373.SH SEE ALSO
374.nf
375tcpd(8) tcp/ip daemon wrapper program.
376tcpdchk(8), tcpdmatch(8), test programs.
377.SH BUGS
378If a name server lookup times out, the host name will not be available
379to the access control software, even though the host is registered.
380.PP
381Domain name server lookups are case insensitive; NIS (formerly YP)
382netgroup lookups are case sensitive.
383.SH AUTHOR
384.na
385.nf
386Wietse Venema (wietse@wzv.win.tue.nl)
387Department of Mathematics and Computing Science
388Eindhoven University of Technology
389Den Dolech 2, P.O. Box 513,
3905600 MB Eindhoven, The Netherlands
391\" @(#) hosts_access.5 1.20 95/01/30 19:51:46
392\" $FreeBSD: head/contrib/tcp_wrappers/hosts_access.5 51495 1999-09-21 09:09:57Z sheldonh $
2.SH NAME
3hosts_access \- format of host access control files
4.SH DESCRIPTION
5This manual page describes a simple access control language that is
6based on client (host name/address, user name), and server (process
7name, host name/address) patterns. Examples are given at the end. The
8impatient reader is encouraged to skip to the EXAMPLES section for a
9quick introduction.
10.PP
11An extended version of the access control language is described in the
12\fIhosts_options\fR(5) document. The extensions are turned on at
13program build time by building with -DPROCESS_OPTIONS.
14.PP
15In the following text, \fIdaemon\fR is the the process name of a
16network daemon process, and \fIclient\fR is the name and/or address of
17a host requesting service. Network daemon process names are specified
18in the inetd configuration file.
19.SH ACCESS CONTROL FILES
20The access control software consults two files. The search stops
21at the first match:
22.IP \(bu
23Access will be granted when a (daemon,client) pair matches an entry in
24the \fI/etc/hosts.allow\fR file.
25.IP \(bu
26Otherwise, access will be denied when a (daemon,client) pair matches an
27entry in the \fI/etc/hosts.deny\fR file.
28.IP \(bu
29Otherwise, access will be granted.
30.PP
31A non-existing access control file is treated as if it were an empty
32file. Thus, access control can be turned off by providing no access
33control files.
34.SH ACCESS CONTROL RULES
35Each access control file consists of zero or more lines of text. These
36lines are processed in order of appearance. The search terminates when a
37match is found.
38.IP \(bu
39A newline character is ignored when it is preceded by a backslash
40character. This permits you to break up long lines so that they are
41easier to edit.
42.IP \(bu
43Blank lines or lines that begin with a `#\' character are ignored.
44This permits you to insert comments and whitespace so that the tables
45are easier to read.
46.IP \(bu
47All other lines should satisfy the following format, things between []
48being optional:
49.sp
50.ti +3
51daemon_list : client_list [ : shell_command ]
52.PP
53\fIdaemon_list\fR is a list of one or more daemon process names
54(argv[0] values) or wildcards (see below).
55.PP
56\fIclient_list\fR is a list
57of one or more host names, host addresses, patterns or wildcards (see
58below) that will be matched against the client host name or address.
59.PP
60The more complex forms \fIdaemon@host\fR and \fIuser@host\fR are
61explained in the sections on server endpoint patterns and on client
62username lookups, respectively.
63.PP
64List elements should be separated by blanks and/or commas.
65.PP
66With the exception of NIS (YP) netgroup lookups, all access control
67checks are case insensitive.
68.ne 4
69.SH PATTERNS
70The access control language implements the following patterns:
71.IP \(bu
72A string that begins with a `.\' character. A host name is matched if
73the last components of its name match the specified pattern. For
74example, the pattern `.tue.nl\' matches the host name
75`wzv.win.tue.nl\'.
76.IP \(bu
77A string that ends with a `.\' character. A host address is matched if
78its first numeric fields match the given string. For example, the
79pattern `131.155.\' matches the address of (almost) every host on the
80Eind\%hoven University network (131.155.x.x).
81.IP \(bu
82A string that begins with an `@\' character is treated as an NIS
83(formerly YP) netgroup name. A host name is matched if it is a host
84member of the specified netgroup. Netgroup matches are not supported
85for daemon process names or for client user names.
86.IP \(bu
87An expression of the form `n.n.n.n/m.m.m.m\' is interpreted as a
88`net/mask\' pair. A host address is matched if `net\' is equal to the
89bitwise AND of the address and the `mask\'. For example, the net/mask
90pattern `131.155.72.0/255.255.254.0\' matches every address in the
91range `131.155.72.0\' through `131.155.73.255\'.
92.IP \(bu
93A string that begins with a `/\' character is treated as a file
94name. A host name or address is matched if it matches any host name
95or address pattern listed in the named file. The file format is
96zero or more lines with zero or more host name or address patterns
97separated by whitespace. A file name pattern can be used anywhere
98a host name or address pattern can be used.
99.SH WILDCARDS
100The access control language supports explicit wildcards:
101.IP ALL
102The universal wildcard, always matches.
103.IP LOCAL
104Matches any host whose name does not contain a dot character.
105.IP UNKNOWN
106Matches any user whose name is unknown, and matches any host whose name
107\fIor\fR address are unknown. This pattern should be used with care:
108host names may be unavailable due to temporary name server problems. A
109network address will be unavailable when the software cannot figure out
110what type of network it is talking to.
111.IP KNOWN
112Matches any user whose name is known, and matches any host whose name
113\fIand\fR address are known. This pattern should be used with care:
114host names may be unavailable due to temporary name server problems. A
115network address will be unavailable when the software cannot figure out
116what type of network it is talking to.
117.IP PARANOID
118Matches any host whose name does not match its address. When tcpd is
119built with -DPARANOID (default mode), it drops requests from such
120clients even before looking at the access control tables. Build
121without -DPARANOID when you want more control over such requests.
122.ne 6
123.SH OPERATORS
124.IP EXCEPT
125Intended use is of the form: `list_1 EXCEPT list_2\'; this construct
126matches anything that matches \fIlist_1\fR unless it matches
127\fIlist_2\fR. The EXCEPT operator can be used in daemon_lists and in
128client_lists. The EXCEPT operator can be nested: if the control
129language would permit the use of parentheses, `a EXCEPT b EXCEPT c\'
130would parse as `(a EXCEPT (b EXCEPT c))\'.
131.br
132.ne 6
133.SH SHELL COMMANDS
134If the first-matched access control rule contains a shell command, that
135command is subjected to %<letter> substitutions (see next section).
136The result is executed by a \fI/bin/sh\fR child process with standard
137input, output and error connected to \fI/dev/null\fR. Specify an `&\'
138at the end of the command if you do not want to wait until it has
139completed.
140.PP
141Shell commands should not rely on the PATH setting of the inetd.
142Instead, they should use absolute path names, or they should begin with
143an explicit PATH=whatever statement.
144.PP
145The \fIhosts_options\fR(5) document describes an alternative language
146that uses the shell command field in a different and incompatible way.
147.SH % EXPANSIONS
148The following expansions are available within shell commands:
149.IP "%a (%A)"
150The client (server) host address.
151.IP %c
152Client information: user@host, user@address, a host name, or just an
153address, depending on how much information is available.
154.IP %d
155The daemon process name (argv[0] value).
156.IP "%h (%H)"
157The client (server) host name or address, if the host name is
158unavailable.
159.IP "%n (%N)"
160The client (server) host name (or "unknown" or "paranoid").
161.IP %p
162The daemon process id.
163.IP %s
164Server information: daemon@host, daemon@address, or just a daemon name,
165depending on how much information is available.
166.IP %u
167The client user name (or "unknown").
168.IP %%
169Expands to a single `%\' character.
170.PP
171Characters in % expansions that may confuse the shell are replaced by
172underscores.
173.SH SERVER ENDPOINT PATTERNS
174In order to distinguish clients by the network address that they
175connect to, use patterns of the form:
176.sp
177.ti +3
178process_name@host_pattern : client_list ...
179.sp
180Patterns like these can be used when the machine has different internet
181addresses with different internet hostnames. Service providers can use
182this facility to offer FTP, GOPHER or WWW archives with internet names
183that may even belong to different organizations. See also the `twist'
184option in the hosts_options(5) document. Some systems (Solaris,
185FreeBSD) can have more than one internet address on one physical
186interface; with other systems you may have to resort to SLIP or PPP
187pseudo interfaces that live in a dedicated network address space.
188.sp
189The host_pattern obeys the same syntax rules as host names and
190addresses in client_list context. Usually, server endpoint information
191is available only with connection-oriented services.
192.SH CLIENT USERNAME LOOKUP
193When the client host supports the RFC 931 protocol or one of its
194descendants (TAP, IDENT, RFC 1413) the wrapper programs can retrieve
195additional information about the owner of a connection. Client username
196information, when available, is logged together with the client host
197name, and can be used to match patterns like:
198.PP
199.ti +3
200daemon_list : ... user_pattern@host_pattern ...
201.PP
202The daemon wrappers can be configured at compile time to perform
203rule-driven username lookups (default) or to always interrogate the
204client host. In the case of rule-driven username lookups, the above
205rule would cause username lookup only when both the \fIdaemon_list\fR
206and the \fIhost_pattern\fR match.
207.PP
208A user pattern has the same syntax as a daemon process pattern, so the
209same wildcards apply (netgroup membership is not supported). One
210should not get carried away with username lookups, though.
211.IP \(bu
212The client username information cannot be trusted when it is needed
213most, i.e. when the client system has been compromised. In general,
214ALL and (UN)KNOWN are the only user name patterns that make sense.
215.IP \(bu
216Username lookups are possible only with TCP-based services, and only
217when the client host runs a suitable daemon; in all other cases the
218result is "unknown".
219.IP \(bu
220A well-known UNIX kernel bug may cause loss of service when username
221lookups are blocked by a firewall. The wrapper README document
222describes a procedure to find out if your kernel has this bug.
223.IP \(bu
224Username lookups may cause noticeable delays for non-UNIX users. The
225default timeout for username lookups is 10 seconds: too short to cope
226with slow networks, but long enough to irritate PC users.
227.PP
228Selective username lookups can alleviate the last problem. For example,
229a rule like:
230.PP
231.ti +3
232daemon_list : @pcnetgroup ALL@ALL
233.PP
234would match members of the pc netgroup without doing username lookups,
235but would perform username lookups with all other systems.
236.SH DETECTING ADDRESS SPOOFING ATTACKS
237A flaw in the sequence number generator of many TCP/IP implementations
238allows intruders to easily impersonate trusted hosts and to break in
239via, for example, the remote shell service. The IDENT (RFC931 etc.)
240service can be used to detect such and other host address spoofing
241attacks.
242.PP
243Before accepting a client request, the wrappers can use the IDENT
244service to find out that the client did not send the request at all.
245When the client host provides IDENT service, a negative IDENT lookup
246result (the client matches `UNKNOWN@host') is strong evidence of a host
247spoofing attack.
248.PP
249A positive IDENT lookup result (the client matches `KNOWN@host') is
250less trustworthy. It is possible for an intruder to spoof both the
251client connection and the IDENT lookup, although doing so is much
252harder than spoofing just a client connection. It may also be that
253the client\'s IDENT server is lying.
254.PP
255Note: IDENT lookups don\'t work with UDP services.
256.SH EXAMPLES
257The language is flexible enough that different types of access control
258policy can be expressed with a minimum of fuss. Although the language
259uses two access control tables, the most common policies can be
260implemented with one of the tables being trivial or even empty.
261.PP
262When reading the examples below it is important to realize that the
263allow table is scanned before the deny table, that the search
264terminates when a match is found, and that access is granted when no
265match is found at all.
266.PP
267The examples use host and domain names. They can be improved by
268including address and/or network/netmask information, to reduce the
269impact of temporary name server lookup failures.
270.SH MOSTLY CLOSED
271In this case, access is denied by default. Only explicitly authorized
272hosts are permitted access.
273.PP
274The default policy (no access) is implemented with a trivial deny
275file:
276.PP
277.ne 2
278/etc/hosts.deny:
279.in +3
280ALL: ALL
281.PP
282This denies all service to all hosts, unless they are permitted access
283by entries in the allow file.
284.PP
285The explicitly authorized hosts are listed in the allow file.
286For example:
287.PP
288.ne 2
289/etc/hosts.allow:
290.in +3
291ALL: LOCAL @some_netgroup
292.br
293ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
294.PP
295The first rule permits access from hosts in the local domain (no `.\'
296in the host name) and from members of the \fIsome_netgroup\fP
297netgroup. The second rule permits access from all hosts in the
298\fIfoobar.edu\fP domain (notice the leading dot), with the exception of
299\fIterminalserver.foobar.edu\fP.
300.SH MOSTLY OPEN
301Here, access is granted by default; only explicitly specified hosts are
302refused service.
303.PP
304The default policy (access granted) makes the allow file redundant so
305that it can be omitted. The explicitly non-authorized hosts are listed
306in the deny file. For example:
307.PP
308/etc/hosts.deny:
309.in +3
310ALL: some.host.name, .some.domain
311.br
312ALL EXCEPT in.fingerd: other.host.name, .other.domain
313.PP
314The first rule denies some hosts and domains all services; the second
315rule still permits finger requests from other hosts and domains.
316.SH BOOBY TRAPS
317The next example permits tftp requests from hosts in the local domain
318(notice the leading dot). Requests from any other hosts are denied.
319Instead of the requested file, a finger probe is sent to the offending
320host. The result is mailed to the superuser.
321.PP
322.ne 2
323/etc/hosts.allow:
324.in +3
325.nf
326in.tftpd: LOCAL, .my.domain
327.PP
328.ne 2
329/etc/hosts.deny:
330.in +3
331.nf
332in.tftpd: ALL: (/some/where/safe_finger -l @%h | \\
333 /usr/ucb/mail -s %d-%h root) &
334.fi
335.PP
336The safe_finger command is intended for use in back-fingering and should be
337installed in a suitable place. It limits possible damage from data sent
338by the remote finger server. It gives better protection than the
339standard finger command.
340.PP
341The expansion of the %h (client host) and %d (service name) sequences
342is described in the section on shell commands.
343.PP
344Warning: do not booby-trap your finger daemon, unless you are prepared
345for infinite finger loops.
346.PP
347On network firewall systems this trick can be carried even further.
348The typical network firewall only provides a limited set of services to
349the outer world. All other services can be "bugged" just like the above
350tftp example. The result is an excellent early-warning system.
351.br
352.ne 4
353.SH DIAGNOSTICS
354An error is reported when a syntax error is found in a host access
355control rule; when the length of an access control rule exceeds the
356capacity of an internal buffer; when an access control rule is not
357terminated by a newline character; when the result of %<letter>
358expansion would overflow an internal buffer; when a system call fails
359that shouldn\'t. All problems are reported via the syslog daemon.
360.SH IMPLEMENTATION NOTES
361Some operating systems are distributed with TCP Wrappers as part of the
362base system. It is common for such systems to build wrapping functionality
363into networking utilities. Notably, some systems offer an \fIinetd\fR(8)
364which does not require the use of the \fItcpd\fR(8). Check your system's
365documentation for details.
366.SH FILES
367.na
368.nf
369/etc/hosts.allow, (daemon,client) pairs that are granted access.
370/etc/hosts.deny, (daemon,client) pairs that are denied access.
371.ad
372.fi
373.SH SEE ALSO
374.nf
375tcpd(8) tcp/ip daemon wrapper program.
376tcpdchk(8), tcpdmatch(8), test programs.
377.SH BUGS
378If a name server lookup times out, the host name will not be available
379to the access control software, even though the host is registered.
380.PP
381Domain name server lookups are case insensitive; NIS (formerly YP)
382netgroup lookups are case sensitive.
383.SH AUTHOR
384.na
385.nf
386Wietse Venema (wietse@wzv.win.tue.nl)
387Department of Mathematics and Computing Science
388Eindhoven University of Technology
389Den Dolech 2, P.O. Box 513,
3905600 MB Eindhoven, The Netherlands
391\" @(#) hosts_access.5 1.20 95/01/30 19:51:46
392\" $FreeBSD: head/contrib/tcp_wrappers/hosts_access.5 51495 1999-09-21 09:09:57Z sheldonh $