1TCPD(8) System Manager's Manual TCPD(8)
2
6 tcpd - access control facility for internet services
7
9 The tcpd program can be set up to monitor incoming requests for telnet,
10 finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and other services
11 that have a one-to-one mapping onto executable files.
12 The program supports both 4.3BSD-style sockets and System V.4-style
14 TLI. Functionality may be limited when the protocol underneath TLI is
15 not an internet protocol.
16 Operation is as follows: whenever a request for service arrives, the
18 inetd daemon is tricked into running the tcpd program instead of the
19 desired server. tcpd logs the request and does some additional checks.
20 When all is well, tcpd runs the appropriate server program and goes
21 away.
22 Optional features are: pattern-based access control, client username
24 lookups with the RFC 931 etc. protocol, protection against hosts that
25 pretend to have someone elses host name, and protection against hosts
26 that pretend to have someone elses network address.
27
29 Connections that are monitored by tcpd are reported through the sys‐
30 log(3) facility. Each record contains a time stamp, the client host
31 name and the name of the requested service. The information can be
32 useful to detect unwanted activities, especially when logfile informa‐
33 tion from several hosts is merged.
34 In order to find out where your logs are going, examine the syslog con‐
36 figuration file, usually /etc/syslog.conf.
37
39 Optionally, tcpd supports a simple form of access control that is based
40 on pattern matching. The access-control software provides hooks for
41 the execution of shell commands when a pattern fires. For details, see
42 the hosts_access(5) manual page.
43
45 The authentication scheme of some protocols (rlogin, rsh) relies on
46 host names. Some implementations believe the host name that they get
47 from any random name server; other implementations are more careful but
48 use a flawed algorithm.
49 tcpd verifies the client host name that is returned by the
51 address->name DNS server by looking at the host name and address that
52 are returned by the name->address DNS server. If any discrepancy is
53 detected, tcpd concludes that it is dealing with a host that pretends
54 to have someone elses host name.
55 If the sources are compiled with -DPARANOID, tcpd will drop the connec‐
57 tion in case of a host name/address mismatch. Otherwise, the hostname
58 can be matched with the PARANOID wildcard, after which suitable action
59 can be taken.
60
62 Optionally, tcpd disables source-routing socket options on every con‐
63 nection that it deals with. This will take care of most attacks from
64 hosts that pretend to have an address that belongs to someone elses
65 network. UDP services do not benefit from this protection. This feature
66 must be turned on at compile time.
67
69 When RFC 931 etc. lookups are enabled (compile-time option) tcpd will
70 attempt to establish the name of the client user. This will succeed
71 only if the client host runs an RFC 931-compliant daemon. Client user
72 name lookups will not work for datagram-oriented connections, and may
73 cause noticeable delays in the case of connections from PCs.
74
76 The details of using tcpd depend on pathname information that was com‐
77 piled into the program.
78
80 This example applies when tcpd expects that the original network dae‐
81 mons will be moved to an "other" place.
82 In order to monitor access to the finger service, move the original
84 finger daemon to the "other" place and install tcpd in the place of the
85 original finger daemon. No changes are required to configuration files.
86 # mkdir /other/place
88 # mv /usr/etc/in.fingerd /other/place
89 # cp tcpd /usr/etc/in.fingerd
90 The example assumes that the network daemons live in /usr/etc. On some
92 systems, network daemons live in /usr/sbin or in /usr/libexec, or have
93 no `in.´ prefix to their name.
94
96 This example applies when tcpd expects that the network daemons are
97 left in their original place.
98 In order to monitor access to the finger service, perform the following
100 edits on the inetd configuration file (usually /etc/inetd.conf or
101 /etc/inet/inetd.conf):
102 finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd
104 becomes:
106 finger stream tcp nowait nobody /some/where/tcpd in.fingerd
108 The example assumes that the network daemons live in /usr/etc. On some
111 systems, network daemons live in /usr/sbin or in /usr/libexec, the dae‐
112 mons have no `in.´ prefix to their name, or there is no userid field in
113 the inetd configuration file.
114 Similar changes will be needed for the other services that are to be
116 covered by tcpd. Send a `kill -HUP´ to the inetd(8) process to make
117 the changes effective. AIX users may also have to execute the `inetimp´
118 command.
119
121 In the case of daemons that do not live in a common directory ("secret"
122 or otherwise), edit the inetd configuration file so that it specifies
123 an absolute path name for the process name field. For example:
124 ntalk dgram udp wait root /some/where/tcpd /usr/local/lib/ntalkd
126 Only the last component (ntalkd) of the pathname will be used for
129 access control and logging.
130
132 Some UDP (and RPC) daemons linger around for a while after they have
133 finished their work, in case another request comes in. In the inetd
134 configuration file these services are registered with the wait option.
135 Only the request that started such a daemon will be logged.
136 The program does not work with RPC services over TCP. These services
138 are registered as rpc/tcp in the inetd configuration file. The only
139 non-trivial service that is affected by this limitation is rexd, which
140 is used by the on(1) command. This is no great loss. On most systems,
141 rexd is less secure than a wildcard in /etc/hosts.equiv.
142 RPC broadcast requests (for example: rwall, rup, rusers) always appear
144 to come from the responding host. What happens is that the client
145 broadcasts the request to all portmap daemons on its network; each
146 portmap daemon forwards the request to a local daemon. As far as the
147 rwall etc. daemons know, the request comes from the local host.
148
150 The default locations of the host access control tables are:
151 /etc/hosts.allow
153 /etc/hosts.deny
154
156 hosts_access(5), format of the tcpd access control tables.
157 syslog.conf(5), format of the syslogd control file.
158 inetd.conf(5), format of the inetd control file.
159
161 Wietse Venema (wietse@wzv.win.tue.nl),
162 Department of Mathematics and Computing Science,
163 Eindhoven University of Technology
164 Den Dolech 2, P.O. Box 513,
165 5600 MB Eindhoven, The Netherlands
166 TCPD(8)