version 1, including all changes.
.
Rev |
Author |
# |
Line |
1 |
perry |
1 |
TCPD |
|
|
2 |
!!!TCPD |
|
|
3 |
NAME |
|
|
4 |
DESCRIPTION |
|
|
5 |
LOGGING |
|
|
6 |
ACCESS CONTROL |
|
|
7 |
HOST NAME VERIFICATION |
|
|
8 |
HOST ADDRESS SPOOFING |
|
|
9 |
RFC 931 |
|
|
10 |
EXAMPLES |
|
|
11 |
EXAMPLE 1 |
|
|
12 |
EXAMPLE 2 |
|
|
13 |
EXAMPLE 3 |
|
|
14 |
BUGS |
|
|
15 |
FILES |
|
|
16 |
SEE ALSO |
|
|
17 |
AUTHORS |
|
|
18 |
---- |
|
|
19 |
!!NAME |
|
|
20 |
|
|
|
21 |
|
|
|
22 |
tcpd - access control facility for internet services |
|
|
23 |
!!DESCRIPTION |
|
|
24 |
|
|
|
25 |
|
|
|
26 |
The ''tcpd'' program can be set up to monitor incoming |
|
|
27 |
requests for ''telnet'', ''finger'', ''ftp'', |
|
|
28 |
''exec'', ''rsh'', ''rlogin'', ''tftp'', |
|
|
29 |
''talk'', ''comsat'' and other services that have a |
|
|
30 |
one-to-one mapping onto executable files. |
|
|
31 |
|
|
|
32 |
|
|
|
33 |
The program supports both 4.3BSD-style sockets and System |
|
|
34 |
V.4-style TLI. Functionality may be limited when the |
|
|
35 |
protocol underneath TLI is not an internet |
|
|
36 |
protocol. |
|
|
37 |
|
|
|
38 |
|
|
|
39 |
Operation is as follows: whenever a request for service |
|
|
40 |
arrives, the ''inetd'' daemon is tricked into running the |
|
|
41 |
''tcpd'' program instead of the desired server. |
|
|
42 |
''tcpd'' logs the request and does some additional |
|
|
43 |
checks. When all is well, ''tcpd'' runs the appropriate |
|
|
44 |
server program and goes away. |
|
|
45 |
|
|
|
46 |
|
|
|
47 |
Optional features are: pattern-based access control, client |
|
|
48 |
username lookups with the RFC 931 etc. protocol, protection |
|
|
49 |
against hosts that pretend to have someone elses host name, |
|
|
50 |
and protection against hosts that pretend to have someone |
|
|
51 |
elses network address. |
|
|
52 |
!!LOGGING |
|
|
53 |
|
|
|
54 |
|
|
|
55 |
Connections that are monitored by ''tcpd'' are reported |
|
|
56 |
through the syslog(3) facility. Each record contains |
|
|
57 |
a time stamp, the client host name and the name of the |
|
|
58 |
requested service. The information can be useful to detect |
|
|
59 |
unwanted activities, especially when logfile information |
|
|
60 |
from several hosts is merged. |
|
|
61 |
|
|
|
62 |
|
|
|
63 |
In order to find out where your logs are going, examine the |
|
|
64 |
syslog configuration file, usually |
|
|
65 |
/etc/syslog.conf. |
|
|
66 |
!!ACCESS CONTROL |
|
|
67 |
|
|
|
68 |
|
|
|
69 |
Optionally, ''tcpd'' supports a simple form of access |
|
|
70 |
control that is based on pattern matching. The |
|
|
71 |
access-control software provides hooks for the execution of |
|
|
72 |
shell commands when a pattern fires. For details, see the |
|
|
73 |
''hosts_access''(5) manual page. |
|
|
74 |
!!HOST NAME VERIFICATION |
|
|
75 |
|
|
|
76 |
|
|
|
77 |
The authentication scheme of some protocols (''rlogin, |
|
|
78 |
rsh'') relies on host names. Some implementations believe |
|
|
79 |
the host name that they get from any random name server; |
|
|
80 |
other implementations are more careful but use a flawed |
|
|
81 |
algorithm. |
|
|
82 |
|
|
|
83 |
|
|
|
84 |
''tcpd'' verifies the client host name that is returned |
|
|
85 |
by the address- |
|
|
86 |
''tcpd'' |
|
|
87 |
concludes that it is dealing with a host that pretends to |
|
|
88 |
have someone elses host name. |
|
|
89 |
|
|
|
90 |
|
|
|
91 |
If the sources are compiled with -DPARANOID, ''tcpd'' |
|
|
92 |
will drop the connection in case of a host name/address |
|
|
93 |
mismatch. Otherwise, the hostname can be matched with the |
|
|
94 |
''PARANOID'' wildcard, after which suitable action can be |
|
|
95 |
taken. |
|
|
96 |
!!HOST ADDRESS SPOOFING |
|
|
97 |
|
|
|
98 |
|
|
|
99 |
Optionally, ''tcpd'' disables source-routing socket |
|
|
100 |
options on every connection that it deals with. This will |
|
|
101 |
take care of most attacks from hosts that pretend to have an |
|
|
102 |
address that belongs to someone elses network. UDP services |
|
|
103 |
do not benefit from this protection. This feature must be |
|
|
104 |
turned on at compile time. |
|
|
105 |
!!RFC 931 |
|
|
106 |
|
|
|
107 |
|
|
|
108 |
When RFC 931 etc. lookups are enabled (compile-time option) |
|
|
109 |
''tcpd'' will attempt to establish the name of the client |
|
|
110 |
user. This will succeed only if the client host runs an RFC |
|
|
111 |
931-compliant daemon. Client user name lookups will not work |
|
|
112 |
for datagram-oriented connections, and may cause noticeable |
|
|
113 |
delays in the case of connections from PCs. |
|
|
114 |
!!EXAMPLES |
|
|
115 |
|
|
|
116 |
|
|
|
117 |
The details of using ''tcpd'' depend on pathname |
|
|
118 |
information that was compiled into the program. |
|
|
119 |
!!EXAMPLE 1 |
|
|
120 |
|
|
|
121 |
|
|
|
122 |
This example applies when ''tcpd'' expects that the |
|
|
123 |
original network daemons will be moved to an |
|
|
124 |
'' |
|
|
125 |
|
|
|
126 |
|
|
|
127 |
In order to monitor access to the ''finger'' service, |
|
|
128 |
move the original finger daemon to the |
|
|
129 |
'' |
|
|
130 |
|
|
|
131 |
|
|
|
132 |
# mkdir /other/place |
|
|
133 |
# mv /usr/etc/in.fingerd /other/place |
|
|
134 |
# cp tcpd /usr/etc/in.fingerd |
|
|
135 |
The example assumes that the network daemons live in /usr/etc. On some systems, network daemons live in /usr/sbin or in /usr/libexec, or have no `in.' prefix to their name. |
|
|
136 |
!!EXAMPLE 2 |
|
|
137 |
|
|
|
138 |
|
|
|
139 |
This example applies when ''tcpd'' expects that the |
|
|
140 |
network daemons are left in their original |
|
|
141 |
place. |
|
|
142 |
|
|
|
143 |
|
|
|
144 |
In order to monitor access to the ''finger'' service, |
|
|
145 |
perform the following edits on the ''inetd'' |
|
|
146 |
configuration file (usually ''/etc/inetd.conf'' or |
|
|
147 |
''/etc/inet/inetd.conf''): |
|
|
148 |
|
|
|
149 |
|
|
|
150 |
finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd |
|
|
151 |
becomes: |
|
|
152 |
finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd |
|
|
153 |
The example assumes that the network daemons live in /usr/etc. On some systems, network daemons live in /usr/sbin or in /usr/libexec, the daemons have no `in.' prefix to their name, or there is no userid field in the inetd configuration file. |
|
|
154 |
|
|
|
155 |
|
|
|
156 |
Similar changes will be needed for the other services that |
|
|
157 |
are to be covered by ''tcpd''. Send a `kill -HUP' to the |
|
|
158 |
inetd(8) process to make the changes effective. AIX |
|
|
159 |
users may also have to execute the `inetimp' |
|
|
160 |
command. |
|
|
161 |
!!EXAMPLE 3 |
|
|
162 |
|
|
|
163 |
|
|
|
164 |
In the case of daemons that do not live in a common |
|
|
165 |
directory ( |
|
|
166 |
inetd'' configuration file so that it specifies an |
|
|
167 |
absolute path name for the process name field. For |
|
|
168 |
example: |
|
|
169 |
|
|
|
170 |
|
|
|
171 |
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd |
|
|
172 |
Only the last component (ntalkd) of the pathname will be used for access control and logging. |
|
|
173 |
!!BUGS |
|
|
174 |
|
|
|
175 |
|
|
|
176 |
Some UDP (and RPC) daemons linger around for a while after |
|
|
177 |
they have finished their work, in case another request comes |
|
|
178 |
in. In the inetd configuration file these services are |
|
|
179 |
registered with the ''wait'' option. Only the request |
|
|
180 |
that started such a daemon will be logged. |
|
|
181 |
|
|
|
182 |
|
|
|
183 |
The program does not work with RPC services over TCP. These |
|
|
184 |
services are registered as ''rpc/tcp'' in the inetd |
|
|
185 |
configuration file. The only non-trivial service that is |
|
|
186 |
affected by this limitation is ''rexd'', which is used by |
|
|
187 |
the ''on(1)'' command. This is no great loss. On most |
|
|
188 |
systems, ''rexd'' is less secure than a wildcard in |
|
|
189 |
/etc/hosts.equiv. |
|
|
190 |
|
|
|
191 |
|
|
|
192 |
RPC broadcast requests (for example: ''rwall, rup, |
|
|
193 |
rusers'') always appear to come from the responding host. |
|
|
194 |
What happens is that the client broadcasts the request to |
|
|
195 |
all ''portmap'' daemons on its network; each |
|
|
196 |
''portmap'' daemon forwards the request to a local |
|
|
197 |
daemon. As far as the ''rwall'' etc. daemons know, the |
|
|
198 |
request comes from the local host. |
|
|
199 |
!!FILES |
|
|
200 |
|
|
|
201 |
|
|
|
202 |
The default locations of the host access control tables |
|
|
203 |
are: |
|
|
204 |
|
|
|
205 |
|
|
|
206 |
/etc/hosts.allow |
|
|
207 |
/etc/hosts.deny |
|
|
208 |
!!SEE ALSO |
|
|
209 |
|
|
|
210 |
|
|
|
211 |
hosts_access(5), format of the tcpd access control tables. |
|
|
212 |
syslog.conf(5), format of the syslogd control file. |
|
|
213 |
inetd.conf(5), format of the inetd control file. |
|
|
214 |
!!AUTHORS |
|
|
215 |
|
|
|
216 |
|
|
|
217 |
Wietse Venema (wietse@wzv.win.tue.nl), |
|
|
218 |
Department of Mathematics and Computing Science, |
|
|
219 |
Eindhoven University of Technology |
|
|
220 |
Den Dolech 2, P.O. Box 513, |
|
|
221 |
5600 MB Eindhoven, The Netherlands |
|
|
222 |
---- |