tcpd(1M)tcpd(1M)NAMEtcpd - access control facility for internet services
DESCRIPTION
The program can be set up to monitor the incoming requests for and
other services that have a one-to-one mapping onto executable files.
The program supports both 4.3BSD-style sockets and System V.4-style
TLI. The functionality may be limited when the protocol underneath TLI
is not an internet protocol.
The operation is as follows: Whenever a request for service is
received, the daemon runs the program instead of the desired server.
logs the request and checks its access control files for matching (dae‐
mon, client) pair entries to either grant or deny access to the
requested service. If access to the requested service is granted, then
runs the appropriate server program and exits. Configuration parame‐
ters, such as logging behaviour, username lookup and reverse lookup
failure behaviour can be defined in the configuration file See
tcpd.conf(4) for more details.
Features of are: pattern-based access control, client username lookups
with the RFC 931 protocol, protection against hosts that pretend to
have someone else's host name, and protection against hosts that pre‐
tend to have someone else's network address.
Logging
Connections monitored by are reported through the syslog(3C) facility.
Each record contains a time stamp, the client host name and the name of
the requested service. The information can be used to detect unwanted
activities, especially when logfile information from several hosts is
merged.
In order to find out where your information is logged, examine the con‐
figuration file,
Access Control
supports a simple form of access control that is based on pattern
matching. The access-control software provides hooks for the execution
of shell commands when a pattern fires. For details, see
hosts_access(5)).
Host Name Verification
The authentication scheme of some protocols relies on host names. Some
implementations trust the host name that they get from any random name
server; other implementations are more careful but use a flawed algo‐
rithm.
verifies the client host name returned by the "address to name" lookup
on the client's address. It compares the client's address with the
address returned by the "resultant name to address" lookup. If any
discrepancy is detected, concludes that it is dealing with a host,
which pretends to have someone else's host name.
If the configuration parameter in is set to then will drop the connec‐
tion in case of a host name/address mismatch. Otherwise, the hostname
can be matched with the wildcard, after which suitable action can be
taken.
Host Address Spooking
disables source-routing socket options on every connection that it
deals with. This will take care of most attacks from hosts that pre‐
tend to have an address belonging to someone else's network. UDP ser‐
vices benefit from this protection.
NOTE: This functionality is not applicable to IPv6 connections.
RFC 931
When RFC 931 lookup is enabled (in will attempt to establish the name
of the client user. This will succeed only if the client host runs an
RFC 931-compliant daemon. Client user name lookups will not work for
datagram-oriented connections, and may cause noticeable delays in the
case of connections from PCs. The configuration file, provides an
option to set the time-out value, within which should get the remote
user name. See the tcpd.conf(4) for more information.
EXAMPLES
There are two ways to configure the system to monitor access to
selected services via The examples below use the and daemon to demon‐
strate the two possible configurations.
Example 1
Move the original daemon to the directory and install in place of the
original daemon. No changes are required to the configuration file,
Example 2
Edit the configuration file as follows:
becomes:
Only the last component of the pathname will be used for access control
and logging.
Send a to the process to make the changes effective.
If the above entry is specified without the absolute path of then looks
for the binary in directory.
NOTE: To apply the access control mechanism to IPv6 connections of a
service, enable IPv6 connections for that service in the file. Refer
to the manpage inetd.conf(4) for more details.
WARNINGS
Some UDP (and RPC) daemons linger around for a while after they have
finished their work, in case another request comes in. In the configu‐
ration file these services are registered with the option. Only the
request that started such a daemon will be logged.
The program does not work with RPC services over TCP. These services
are registered as in the configuration file. The only non-trivial ser‐
vice that is affected by this limitation is which is used by the com‐
mand. On most systems, is less secure than a wildcard in
RPC broadcast requests (for example: always appear to come from the
responding host. What really happens is that the client broadcasts the
request to all daemons on its network; each daemon forwards the request
to a local daemon. From daemon's (like point of view, the request is
coming from the local host.
AUTHOR
Wietse Venema (wietse@wzv.win.tue.nl)
Department of Mathematics and Computing Science,
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513,
5600 MB Eindhoven, The Netherlands
FILES
The default locations of the host access control tables are:
(daemon,client) pairs that are granted access.
(daemon,client) pairs that are denied access.
SEE ALSOinetd(1M), internet services daemon.
syslogd(1M), format of the control file.
inetd.conf(4), format of the control file.
hosts_access(5), format of the access control tables.
tcpd(1M)
