|HP-UX Reference > T
HP-UX 11i Version 3: February 2007
tcpd — access control facility for internet services
The tcpd program can be set up to monitor the incoming requests for telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, 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 inetd daemon runs the tcpd program instead of the desired server. tcpd logs the request and checks its access control files for matching (daemon, client) pair entries to either grant or deny access to the requested service. If access to the requested service is granted, then tcpd runs the appropriate server program and exits. Configuration parameters, such as logging behaviour, username lookup and reverse lookup failure behaviour can be defined in the configuration file /etc/tcpd.conf. See tcpd.conf(4) for more details.
Features of tcpd 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 pretend to have someone else's network address.
Connections monitored by tcpd 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 syslog configuration file, /etc/syslog.conf.
tcpd 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 (rlogin, rsh) 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 algorithm.
tcpd 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, tcpd concludes that it is dealing with a host, which pretends to have someone else's host name.
If the configuration parameter on_reverselookup_fail in /etc/tcpd.conf is set to deny, then tcpd will drop the connection in case of a host name/address mismatch. Otherwise, the hostname can be matched with the PARANOID wildcard, after which suitable action can be taken.
Host Address Spooking
tcpd disables source-routing socket options on every connection that it deals with. This will take care of most attacks from hosts that pretend to have an address belonging to someone else's network. UDP services benefit from this protection.
NOTE: This functionality is not applicable to IPv6 connections.
When RFC 931 lookup is enabled (in /etc/tcpd.conf) tcpd 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, /etc/tcpd.conf provides an option to set the time-out value, within which tcpd should get the remote user name. See the tcpd.conf(4) for more information.
There are two ways to configure the system to monitor access to selected services via tcpd. The examples below use the ftp and telnet daemon to demonstrate the two possible configurations.
Move the original daemon to the /usr/lbin/wrapper directory and install tcpd in place of the original daemon. No changes are required to the inetd configuration file, /etc/inetd.conf.
Edit the inetd configuration file as follows:
Only the last component (telnetd) of the pathname will be used for access control and logging.
Send a kill -HUP to the inetd process to make the changes effective.
If the above entry is specified without the absolute path of telnetd then tcpd looks for the telnetd binary in /usr/lbin/wrapper directory.
NOTE: To apply the access control mechanism to IPv6 connections of a service, enable IPv6 connections for that service in the /etc/inetd.conf file. Refer to the manpage inetd.conf(4) for more details.
Some UDP (and RPC) daemons linger around for a while after they have finished their work, in case another request comes in. In the inetd configuration file these services are registered with the wait 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 rpc/tcp in the inetd configuration file. The only non-trivial service that is affected by this limitation is rexd, which is used by the on command. On most systems, rexd is less secure than a wildcard in /etc/hosts.equiv.
RPC broadcast requests (for example: rwall, rup, rusers) always appear to come from the responding host. What really happens is that the client broadcasts the request to all portmap daemons on its network; each portmap daemon forwards the request to a local daemon. From daemon's (like rwall) point of view, the request is coming from the local host.
Wietse Venema (email@example.com) Department of Mathematics and Computing Science, Eindhoven University of Technology Den Dolech 2, P.O. Box 513, 5600 MB Eindhoven, The Netherlands
The default locations of the host access control tables are: