1TCPD(8)                     System Manager's Manual                    TCPD(8)
2
3
4

NAME

6       tcpd - access control facility for internet services
7

DESCRIPTION

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
13       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
17       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
23       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

LOGGING

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
35       In order to find out where your logs are going, examine the syslog con‐
36       figuration file, usually /etc/syslog.conf.
37

ACCESS CONTROL

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

HOST NAME VERIFICATION

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
50       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
56       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

HOST ADDRESS SPOOFING

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

RFC 931

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

EXAMPLES

76       The details of using tcpd depend on pathname information that was  com‐
77       piled into the program.
78

EXAMPLE 1

80       This  example  applies when tcpd expects that the original network dae‐
81       mons will be moved to an "other" place.
82
83       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
87            # mkdir /other/place
88            # mv /usr/etc/in.fingerd /other/place
89            # cp tcpd /usr/etc/in.fingerd
90
91       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

EXAMPLE 2

96       This example applies when tcpd expects that  the  network  daemons  are
97       left in their original place.
98
99       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
103            finger  stream  tcp  nowait  nobody  /usr/etc/in.fingerd  in.fingerd
104
105       becomes:
106
107            finger  stream  tcp  nowait  nobody  /some/where/tcpd     in.fingerd
108
109
110       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
115       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

EXAMPLE 3

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
125           ntalk  dgram  udp  wait  root  /some/where/tcpd  /usr/local/lib/ntalkd
126
127
128       Only  the  last  component  (ntalkd)  of  the pathname will be used for
129       access control and logging.
130

BUGS

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
137       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
143       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

FILES

150       The default locations of the host access control tables are:
151
152       /etc/hosts.allow
153       /etc/hosts.deny
154

SEE ALSO

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

AUTHORS

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
167
168
169
170                                                                       TCPD(8)
Impressum