TCP_WRAPPERS(8)TCP_WRAPPERS(8)NAME
tcp_wrappers, try-from - access control facility for internet services
DESCRIPTION
NOTES: This is the README file from the TCP/IP daemon wrapper package.
o If you wish to use tcp_wrappers with inetd, please look at
inetd(1m).
o try-from usage is explained in this manual page.
@(#) README 1.30 97/03/21 19:27:21
This is the 7.6 version of the TCP/IP daemon wrapper package.
Thank you for using this program. If you like it, send me a postcard. My
postal address is at the bottom of this file.
Read the BLURB file for a brief summary of what is new. The CHANGES file
gives a complete account of differences with respect to previous
releases.
Announcements of new releases of this software are posted to Usenet
(comp.security.unix, comp.unix.admin), to the cert-tools mailing list,
and to a dedicated mailing list. You can subscribe to the dedicated
mailing list by sending an email message to majordomo@wzv.win.tue.nl with
in the body (not subject): subscribe tcp-wrappers-announce.
Table of contents -----------------
1 - Introduction
2 - Disclaimer
3 - Tutorials
3.1 - How it works
3.2 - Where the logging information goes
4 - Features
4.1 - Access control
4.2 - Host name spoofing
4.3 - Host address spoofing
4.4 - Client username lookups
4.5 - Language extensions 4.6 - Multiple
ftp/gopher/www archives on one host 4.7 - Banner messages
4.8 - Sequence number guessing
5 - Other works
5.1 - Related documents
5.2 - Related software
6 - Limitations
6.1 - Known wrapper limitations
6.2 - Known system software bugs
7 - Configuration and installation
7.1 - Easy configuration and installation
7.2 - Advanced configuration and installation
7.3 - Daemons with arbitrary path names
7.4 - Building and testing the access control rules
Page 1
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
7.5 - Other applications
8 - Acknowledgements
1 - Introduction ----------------
With this package you can monitor and filter incoming requests for the
SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other
network services.
It supports both 4.3BSD-style sockets and System V.4-style TLI. Praise
yourself lucky if you don't know what that means.
The package provides tiny daemon wrapper programs that can be installed
without any changes to existing software or to existing configuration
files. The wrappers report the name of the client host and of the
requested service; the wrappers do not exchange information with the
client or server applications, and impose no overhead on the actual
conversation between the client and server applications.
Optional features are: access control to restrict what systems can
connect to what network daemons; client user name lookups with the RFC
931 etc. protocol; additional protection against hosts that pretend to
have someone elses host name; additional protection against hosts that
pretend to have someone elses host address.
The programs are very portable. Build procedures are provided for many
common (and not so common) environments, and guidelines are provided in
case your environment is not among them.
Requirements are that network daemons are spawned by a super server such
as the inetd; a 4.3BSD-style socket programming interface and/or System
V.4-style TLI programming interface; and the availability of a syslog(3)
library and of a syslogd(8) daemon. The wrappers should run without
modification on any system that satisfies these requirements.
Workarounds have been implemented for several common bugs in systems
software.
What to do if this is your first encounter with the wrapper programs: 1)
read the tutorial sections for an introduction to the relevant concepts
and terminology; 2) glance over the security feature sections in this
document; 3) follow the installation instructions (easy or advanced). I
recommend that you first use the default security feature settings. Run
the wrappers for a few days to become familiar with their logs, before
doing anything drastic such as cutting off access or installing booby
traps.
2 - Disclaimer --------------
The wrapper programs rely on source address information obtained from
network packets. This information is provided by the client host. It is
not 100 percent reliable, although the wrappers do their best to expose
forgeries.
Page 2
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
In the absence of cryptographic protection of message contents, and of
cryptographic authentication of message originators, all data from the
network should be treated with sound scepticism.
THIS RESTRICTION IS BY NO MEANS SPECIFIC TO THE TCP/IP PROTOCOLS.
3 - Tutorials -------------
The tutorial sections give a gentle introduction to the operation of the
wrapper programs, and introduce some of the terminology that is used in
the remainder of the document: client, server, the inetd and syslogd
daemons, and their configuration files.
3.1 - How it works ------------------
Almost every application of the TCP/IP protocols is based on a client-
server model. For example, when a user invokes the telnet command to
connect to one of your systems, a telnet server process is executed on
the target host. The telnet server process connects the user to a login
process. A few examples of client and server programs are shown in the
table below:
client server application
--------------------------------
telnet telnetd remote login
ftp ftpd file transfer
finger fingerd show users
The usual approach is to run one single daemon process that waits for all
kinds of incoming network connections. Whenever a connection is
established, this daemon (usually called inetd) runs the appropriate
server program and goes back to sleep, waiting for other connections.
The wrapper programs rely on a simple, but powerful mechanism. Instead
of directly running the desired server program, the inetd is tricked into
running a small wrapper program. The wrapper logs the client host name or
address and performs some additional checks. When all is well, the
wrapper executes the desired server program and goes away.
The wrapper programs have no interaction with the client user (or with
the client process). Nor do the wrappers interact with the server
application. This has two major advantages: 1) the wrappers are
application-independent, so that the same program can protect many kinds
of network services; 2) no interaction also means that the wrappers are
invisible from outside (at least for authorized users).
Another important property is that the wrapper programs are active only
when the initial contact between client and server is established. Once a
wrapper has done its work there is no overhead on the client-server
conversation.
The simple mechanism has one major drawback: the wrappers go away after
Page 3
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
the initial contact between client and server processes, so the wrappers
are of little use with network daemons that service more than one client.
The wrappers would only see the first client attempt to contact such a
server. The NFS mount daemon is a typical example of a daemon that
services requests from multiple clients. See the section on related
software for ways to deal with such server programs.
There are two ways to use the wrapper programs:
1) The easy way: move network daemons to some other directory and fill
the resulting holes with copies of the wrapper programs. This
approach involves no changes to system configuration files, so there
is very little risk of breaking things.
2) The advanced way: leave the network daemons alone and modify the
inetd configuration file. For example, an entry such as:
tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot
When a tftp request arrives, inetd will run the wrapper program
(tcpd) with a process name `in.tftpd'. This is the name that the
wrapper will use when logging the request and when scanning the
optional access control tables. `in.tftpd' is also the name of the
server program that the wrapper will attempt to run when all is
well. Any arguments (`-s /tftpboot' in this particular example) are
transparently passed on to the server program.
For an account of the history of the wrapper programs, with real-life
examples, see the section below on related documents.
3.2 - Where the logging information goes
----------------------------------------
The wrapper programs send their logging information to the syslog daemon
(syslogd). The disposition of the wrapper logs is determined by the
syslog configuration file (usually /etc/syslog.conf). Messages are
written to files, to the console, or are forwarded to a @loghost. Some
syslogd versions can even forward messages down a |pipeline.
Older syslog implementations (still found on Ultrix systems) only support
priority levels ranging from 9 (debug-level messages) to 0 (alerts). All
logging information of the specified priority level or more urgent is
written to the same destination. In the syslog.conf file, priority
levels are specified in numerical form. For example,
8/usr/spool/mqueue/syslog
causes all messages with priority 8 (informational messages), and
anything that is more urgent, to be appended to the file
/usr/spool/mqueue/syslog.
Newer syslog implementations support message classes in addition to
Page 4
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
priority levels. Examples of message classes are: mail, daemon, auth and
news. In the syslog.conf file, priority levels are specified with
symbolic names: debug, info, notice, ..., emerg. For example,
mail.debug /var/log/syslog
causes all messages of class mail with priority debug (or more urgent) to
be appended to the /var/log/syslog file.
By default, the wrapper logs go to the same place as the transaction logs
of the sendmail daemon. The disposition can be changed by editing the
Makefile and/or the syslog.conf file. Send a `kill -HUP' to the syslogd
after changing its configuration file. Remember that syslogd, just like
sendmail, insists on one or more TABs between the left-hand side and the
right-hand side expressions in its configuration file.
Solaris 2.x note: the syslog daemon depends on the m4 macro processor.
The m4 program is installed as part of the software developer packages.
Trouble shooting note: when the syslogging does not work as expected, run
the program by hand (`syslogd -d') and see what really happens.
4 - Features ------------
4.1 - Access control --------------------
When compiled with -DHOSTS_ACCESS, the wrapper programs support a simple
form of access control. Access can be controlled per host, per service,
or combinations thereof. The software provides hooks for the execution of
shell commands when an access control rule fires; this feature may be
used to install "booby traps". For details, see the hosts_access.5
manual page, which is in `nroff -man' format. A later section describes
how you can test your access control rules.
Access control can also be used to connect clients to the "right"
service. What is right may depend on the requested service, the origin of
the request, and what host address the client connects to. Examples:
(1) A gopher or www database speaks native language when contacted from
within the country, otherwise it speaks English.
(2) A service provider offers different ftp, gopher or www services
with different internet hostnames from one host (section 4.6).
Access control is enabled by default. It can be turned off by editing the
Makefile, or by providing no access control tables. The install
instructions below describe the Makefile editing process.
The hosts_options.5 manual page (`nroff -man' format) documents an
extended version of the access control language. The extensions are
disabled by default. See the section below on language extensions.
Page 5
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
Later System V implementations provide the Transport Level Interface
(TLI), a network programming interface that performs functions similar to
the Berkeley socket programming interface. Like Berkeley sockets, TLI
was designed to cover multiple protocols, not just Internet.
When the wrapper discovers that the TLI interface sits on top of a TCP/IP
or UDP/IP conversation it uses this knowledge to provide the same
functions as with traditional socket-based applications. When some other
protocol is used underneath TLI, the host address will be some universal
magic cookie that may not even be usable for access control purposes.
4.2 - Host name spoofing ------------------------
With some network applications, such as RSH or RLOGIN, the client host
name plays an important role in the authentication process. Host name
information can be reliable when lookups are done from a _local_ hosts
table, provided that the client IP address can be trusted.
With _distributed_ name services, authentication schemes that rely on
host names become more problematic. The security of your system now may
depend on some far-away DNS (domain name server) outside your own
control.
The wrapper programs verify the client host name that is returned by the
address->name DNS server, by asking for a second opinion. To this end,
the programs look at the name and addresses that are returned by the
name->address DNS server, which may be an entirely different host.
If any name or address discrepancies are found, or if the second DNS
opinion is not available, the wrappers assume that one of the two name
servers is lying, and assume that the client host pretends to have
someone elses host name.
When compiled with -DPARANOID, the wrappers will always attempt to look
up and double check the client host name, and will always refuse service
in case of a host name/address discrepancy. This is a reasonable policy
for most systems.
When compiled without -DPARANOID, the wrappers by default still perform
hostname lookup. You can match hosts with a name/address discrepancy with
the PARANOID wildcard and decide whether or not to grant service.
Automatic hostname verification is enabled by default. Automatic hostname
lookups and verification can be turned off by editing the Makefile. The
configuration and installation section below describes the Makefile
editing process.
4.3 - Host address spoofing ---------------------------
While host name spoofing can be found out by asking a second opinion, it
is much harder to find out that a host claims to have someone elses
network address. And since host names are deduced from network addresses,
Page 6
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
address spoofing is at least as effective as name spoofing.
The wrapper programs can give additional protection against hosts that
claim to have an address that lies outside their own network. For
example, some far-away host that claims to be a trusted host within your
own network. Such things are possible even while the impersonated system
is up and running.
This additional protection is not an invention of my own; it has been
present for at least five years in the BSD rsh and rlogin daemons.
Unfortunately, that feature was added *after* 4.3 BSD came out, so that
very few, if any, UNIX vendors have adopted it. Our site, and many other
ones, has been running these enhanced daemons for several years, and
without any ill effects.
When the wrapper programs are compiled with -DKILL_IP_OPTIONS, the
programs refuse to service TCP connections with IP source routing
options. -DKILL_IP_OPTIONS is not needed on modern UNIX systems that can
stop source-routed traffic in the kernel. Examples are 4.4BSD
derivatives, Solaris 2.x, and Linux. See your system manuals for details.
If you are going to use this feature on SunOS 4.1.x you should apply
patch 100804-03+ or 101790-something depending on your SunOS version.
Otherwise you may experience "BAD TRAP" and "Data fault" panics when the
getsockopt() system call is executed after a TCP RESET has been received.
This is a kernel bug, it is not the fault of the wrappers.
The feature is disabled by default. It can be turned on by editing the
Makefile. The configuration and installation section below describes the
Makefile editing process.
UDP services do not benefit from this additional protection. With UDP,
all you can be certain of is the network packet's destination address.
4.4 - Client username lookups -----------------------------
The protocol proposed in RFC 931 provides a means to obtain the client
user name from the client host. The requirement is that the client host
runs an RFC 931-compliant daemon. The information provided by such a
daemon is not intended to be used for authentication purposes, but it can
provide additional information about the owner of a TCP connection.
The RFC 931 protocol has diverged into different directions (IDENT, TAP,
RFC 1413). To add to the confusion, they all use the same network port.
The daemon wrappers implement a common subset of the protocols.
There are some limitations: the number of hosts that run an RFC 931 (or
compatible) daemon is limited (but growing); client user name lookups do
not work for datagram (UDP) services. More seriously, client user name
lookups can cause noticeable delays with connections from non-UNIX PCs.
Recent PC software seem to have fixed this (for example NCSA telnet). The
wrappers use a 10-second timeout for RFC931 lookups, to accommodate slow
Page 7
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
networks and slow hosts.
By default, the wrappers will do username lookup only when the access
control rules require them to do so (via user@host client patterns, see
the hosts_access.5 manual page) or when the username is needed for
%<letter> expansions.
You can configure the wrappers to always perform client username lookups,
by editing the Makefile. The client username lookup timeout period (10
seconds default) can be changed by editing the Makefile. The installation
sections below describe the Makefile editing process.
On System V with TLI-based network services, client username lookups will
be possible only when the underlying network protocol is TCP/IP.
4.5 - Language extensions -------------------------
The wrappers sport only a limited number of features. This is for a good
reason: programs that run at high privilege levels must be easy to
verify. And the smaller a program, the easier to verify. There is,
however, a provision to add features.
The options.c module provides a framework for language extensions. Quite
a few extensions have already been implemented; they are documented in
the hosts_options.5 document, which is in `nroff -man' format. Examples:
changing the severity level at which a request for service is logged;
"allow" and "deny" keywords; running a customized server instead of the
standard one; many others.
The language extensions are not enabled by default because they introduce
an incompatible change to the access control language syntax.
Instructions to enable the extensions are given in the Makefile.
4.6 - Multiple ftp/gopher/www archives on one host
--------------------------------------------------
Imagine one host with multiple internet addresses. These addresses do not
need to have the same internet hostname. Thus, it is possible to offer
services with different internet hostnames from just one host.
Service providers can use this to offer organizations a presence on the
"net" with their own internet hostname, even when those organizations
aren't connected to the Internet at all. To the end user it makes no
difference, because applications use internet hostnames.
There are several ways to assign multiple addresses to one machine. The
nice way is to take an existing network interface and to assign
additional internet addresses with the `ifconfig' command. Examples:
Solaris 2: ifconfig le0:1 <address> netmask <mask> up
4.4 BSD: ifconfig en0 alias <address> netmask <mask>
Page 8
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
On other systems one has to increase the number of network interfaces:
either with hardware interfaces, or with pseudo interfaces like SLIP or
PPP. The interfaces do not need to be attached to anything. They just
need to be up and to be assigned a suitable internet address and mask.
With the wrapper software, `daemon@host' access control patterns can be
used to distinguish requests by the network address that they are aimed
at. Judicious use of the `twist' option (see the hosts_options.5 file,
`nroff -man' format) can guide the requests to the right server. These
can be servers that live in separate chroot areas, or servers modified to
take additional context from the command line, or a combination.
Another way is to modify gopher or www listeners so that they bind to
only one specific network address. Multiple gopher or www servers can
then be run side by side, each taking requests sent to its respective
network address.
4.7 - Banner messages ---------------------
Some sites are required to present an informational message to users
before they attempt to login. Banner messages can also be useful when
denying service: instead of simply dropping the connection a polite
explanation is given first. Finally, banners can be used to give your
system a more personal touch.
The wrapper software provides easy-to-use tools to generate pre-login
banners for ftp, telnet, rlogin etc. from a single prototype banner
textfile. Details on banners and on-the-fly %<letter> expansions are
given in the hosts_options.5 manual page (`nroff -man' format). An
example is given in the file Banners.Makefile.
In order to support banner messages the wrappers have to be built with
language extensions enabled. See the section on language extensions.
4.8 - Sequence number guessing ------------------------------
Recently, systems came under attack from intruders that exploited a
well-known weakness in TCP/IP sequence number generators. This weakness
allows intruders to impersonate trusted hosts. Break-ins have been
reported via the rsh service. In fact, any network service can be
exploited that trusts the client host name or address.
A long-term solution is to stop using network services that trust the
client host name or address, and to use data encryption instead.
A short-term solution, as outlined in in CERT advisory CA-95:01, is to
configure network routers so that they discard datagrams from "outside"
with an "inside" source address. This approach is most fruitful when you
do not trust any hosts outside your local network.
The IDENT (RFC931 etc.) client username lookup protocol can help to
detect host impersonation attacks. Before accepting a client request,
Page 9
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
the wrappers can query the client's IDENT server and find out that the
client never sent that request.
When the client host provides IDENT service, a negative IDENT lookup
result (the client matches `UNKNOWN@host') is strong evidence of a host
impersonation attack.
A positive IDENT lookup result (the client matches `KNOWN@host') is less
trustworthy. It is possible for an attacker to spoof both the client
request and the IDENT lookup connection, although doing so should be much
harder than spoofing just a client request. Another possibility is that
the client's IDENT server is lying.
Client username lookups are described in more detail in a previous
section. Pointers to IDENT daemon software are described in the section
on related software.
5 - Other works ---------------
5.1 - Related documents -----------------------
The war story behind the tcp wrapper tools is described in:
W.Z. Venema, "TCP WRAPPER, network monitoring, access control and
booby traps", UNIX Security Symposium III Proceedings (Baltimore),
September 1992.
ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript)
ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text)
The same cracker is also described in:
W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is
Lured, Endured, and Studied", Proceedings of the Winter USENIX
Conference (San Francisco), January 1992.
research.att.com:/dist/internet_security/berferd.ps
An updated version of the latter paper appeared in:
W.R. Cheswick, S.M. Bellovin, "Firewalls and Internet Security",
Addison-Wesley, 1994.
Discussions on internet firewalls are archived on ftp.greatcircle.com.
Subscribe to the mailing list by sending a message to
majordomo@greatcircle.com
With in the body (not subject): subscribe firewalls.
5.2 - Related software ----------------------
Page 10
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
Network daemons etc. with enhanced logging capabilities can generate
massive amounts of information: our 150+ workstations generate several
hundred kbytes each day. egrep-based filters can help to suppress some of
the noise. A more powerful tool is the Swatch monitoring system by
Stephen E. Hansen and E. Todd Atkins. Swatch can process log files in
real time and can associate arbitrary actions with patterns; its
applications are by no means restricted to security. Swatch is available
ftp.stanford.edu, directory /general/security-tools/swatch.
Socks, described in the UNIX Security III proceedings, can be used to
control network traffic from hosts on an internal network, through a
firewall host, to the outer world. Socks consists of a daemon that is run
on the firewall host, and of a library with routines that redirect
application socket calls through the firewall daemon. Socks is available
from s1.gov in /pub/firewalls/socks.tar.Z.
For a modified Socks version by Ying-Da Lee (ylee@syl.dl.nec.com) try
ftp.nec.com, directory /pub/security/socks.cstc.
Tcpr is a set of perl scripts by Paul Ziemba that enable you to run ftp
and telnet commands across a firewall. Unlike socks it can be used with
unmodified client software. Available from ftp.alantec.com, /pub/tcpr.
The TIS firewall toolkit provides a multitude of tools to build your own
internet firewall system. ftp.tis.com, directory /pub/firewalls.
Versions of rshd and rlogind, modified to report the client user name in
addition to the client host name, are available for anonymous ftp
(ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z). These programs are
drop-in replacements for SunOS 4.x, Ultrix 4.x, SunOS 5.x and HP-UX 9.x.
This archive also contains ftpd/rexecd/login versions that support S/Key
or SecureNet one-time passwords in addition to traditional UNIX reusable
passwords.
The securelib shared library by William LeFebvre can be used to control
access to network daemons that are not run under control of the inetd or
that serve more than one client, such as the NFS mount daemon that runs
until the machine goes down. Available from eecs.nwu.edu, file
/pub/securelib.tar.
xinetd (posted to comp.sources.unix) is an inetd replacement that
provides, among others, logging, username lookup and access control.
However, it does not support the System V TLI services, and involves much
more source code than the daemon wrapper programs. Available from
ftp.uu.net, directory /usenet/comp.sources.unix.
netlog from Texas A&M relies on the SunOS 4.x /dev/nit interface to
passively watch all TCP and UDP network traffic on a network. The
current version is on net.tamu.edu in /pub/security/TAMU.
Where shared libraries or router-based packet filtering are not an
option, an alternative portmap daemon can help to prevent hackers from
Page 11
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
mounting your NFS file systems using the proxy RPC facility.
ftp.win.tue.nl:/pub/security/portmap-X.shar.Z was tested with SunOS 4.1.X
Ultrix 3.0 and Ultrix 4.x, HP-UX 8.x and some version of AIX. The
protection is less effective than that of the securelib library because
portmap is mostly a dictionary service.
An rpcbind replacement (the Solaris 2.x moral equivalent of portmap) can
be found on ftp.win.tue.nl in /pub/security. It prevents hackers from
mounting your NFS file systems by using the proxy RPC facility.
Source for a portable RFC 931 (TAP, IDENT, RFC 1413) daemon by Peter
Eriksson is available from ftp.lysator.liu.se:/pub/ident/servers.
Some TCP/IP implementations come without syslog library. Some come with
the library but have no syslog daemon. A replacement can be found in
ftp.win.tue.nl:/pub/security/surrogate-syslog.tar.Z. The fakesyslog
library that comes with the nntp sources reportedly works well, too.
6 - Limitations ---------------
6.1 - Known wrapper limitations -------------------------------
Many UDP (and rpc/udp) daemons linger around for a while after they have
serviced a request, just in case another request comes in. In the inetd
configuration file these daemons are registered with the `wait' option.
Only the request that started such a daemon will be seen by the wrappers.
Such daemons are better protected with the securelib shared library (see:
Related software).
The wrappers do 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(1) command. This is no great loss. On most systems, rexd
is less secure than a wildcard in /etc/hosts.equiv.
Some RPC requests (for example: rwall, rup, rusers) appear to come from
the server host. What happens is that the client broadcasts its request
to all portmap daemons on its network; each portmap daemon forwards the
request to a daemon on its own system. As far as the rwall etc. daemons
know, the request comes from the local host.
Portmap and RPC (e.g. NIS and NFS) (in)security is a topic in itself.
See the section in this document on related software.
6.2 - Known system software bugs --------------------------------
Workarounds have been implemented for several bugs in system software.
They are described in the Makefile. Unfortunately, some system software
bugs cannot be worked around. The result is loss of functionality.
IRIX has so many bugs that it has its own README.IRIX file.
Page 12
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
Older ConvexOS versions come with a broken recvfrom(2) implementation.
This makes it impossible for the daemon wrappers to look up the client
host address (and hence, the name) in case of UDP requests. A patch is
available for ConvexOS 10.1; later releases should be OK.
With early Solaris (SunOS 5) versions, the syslog daemon will leave
behind zombie processes when writing to logged-in users. Workaround:
increase the syslogd threshold for logging to users, or reduce the
wrapper's logging severity.
On some systems, the optional RFC 931 etc. client username lookups may
trigger a kernel bug. When a client host connects to your system, and
the RFC 931 connection from your system to that client is rejected by a
router, your kernel may drop all connections with that client. This is
not a bug in the wrapper programs: complain to your vendor, and don't
enable client user name lookups until the bug has been fixed.
Reportedly, SunOS 4.1.1, Next 2.0a, ISC 3.0 with TCP 1.3, and AIX 3.2.2
and later are OK.
Sony News/OS 4.51, HP-UX 8-something and Ultrix 4.3 still have the bug.
Reportedly, a fix for Ultrix is available (CXO-8919).
The following procedure can be used (from outside the tue.nl domain) to
find out if your kernel has the bug. From the system under test, do:
% ftp 131.155.70.19
This command attempts to make an ftp connection to our anonymous ftp
server (ftp.win.tue.nl). When the connection has been established, run
the following command from the same system under test, while keeping the
ftp connection open:
% telnet 131.155.70.19 111
Do not forget the `111' at the end of the command. This telnet command
attempts to connect to our portmap process. The telnet command should
fail with: "host not reachable", or with a timeout error. If your ftp
connection gets messed up, you have the bug. If the telnet command does
not fail, please let me know a.s.a.p.!
For those who care, the bug is that the BSD kernel code was not careful
enough with incoming ICMP UNREACHABLE control messages (it ignored the
local and remote port numbers, and therefore zapped *all* connections
with the remote system). The bug is still present in the BSD NET/1 source
release (1989) but apparently has been fixed in BSD NET/2 (1991).
7 - Configuration and installation ----------------------------------
7.1 - Easy configuration and installation
-----------------------------------------
Page 13
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
The "easy" recipe requires no changes to existing software or
configuration files. Basically, you move the daemons that you want to
protect to a different directory and plug the resulting holes with copies
of the wrapper programs.
If you don't run Ultrix, you won't need the miscd wrapper program. The
miscd daemon implements among others the SYSTAT service, which produces
the same output as the WHO command.
Type `make' and follow the instructions. The Makefile comes with ready-
to-use templates for many common UNIX implementations (sun, ultrix, hp-
ux, aix, irix,...).
IRIX has so many bugs that it has its own README.IRIX file.
When the `make' succeeds the result is five executables (six in case of
Ultrix).
You can use the `tcpdchk' program to identify the most common problems in
your wrapper and inetd configuration files.
With the `tcpdmatch' program you can examine how the wrapper would react
to specific requests for service.
The `safe_finger' command should be used when you implement booby traps:
it gives better protection against nasty stuff that remote hosts may do
in response to your finger probes.
The `try-from' program tests the host and username lookup code. Run it
from a remote shell command (`rsh host /some/where/try-from') and it
should be able to figure out from what system it is being called.
The tcpd program can be used to monitor the telnet, finger, ftp, exec,
rsh, rlogin, tftp, talk, comsat and other tcp or udp services that have a
one-to-one mapping onto executable files.
The tcpd program can also be used for services that are marked as rpc/udp
in the inetd configuration file, but not for rpc/tcp services such as
rexd. You probably do not want to run rexd anyway. On most systems it is
even less secure than a wildcard in /etc/hosts.equiv.
With System V.4-style systems, the tcpd program can also handle TLI
services. When TCP/IP or UDP/IP is used underneath TLI, tcpd provides the
same functions as with socket-based applications. When some other
protocol is used underneath TLI, functionality will be limited (no client
username lookups, weird network address formats).
Decide which services you want to monitor. Move the corresponding
vendor-provided daemon programs to the location specified by the
REAL_DAEMON_DIR constant in the Makefile, and fill the holes with copies
of the tcpd program. That is, one copy of (or link to) the tcpd program
for each service that you want to monitor. For example, to monitor the
Page 14
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
use of your finger service:
# mkdir REAL_DAEMON_DIR
# mv /usr/etc/in.fingerd REAL_DAEMON_DIR
# cp tcpd /usr/etc/in.fingerd
The example applies to SunOS 4. With other UNIX implementations the
network daemons live in /usr/libexec, /usr/sbin or in /etc, or have no
"in." prefix to their names, but you get the idea.
File protections: the wrapper, all files used by the wrapper, and all
directories in the path leading to those files, should be accessible but
not writable for unprivileged users (mode 755 or mode 555). Do not
install the wrapper set-uid.
Ultrix only: If you want to monitor the SYSTAT service, move the
vendor-provided miscd daemon to the location specified by the
REAL_DAEMON_DIR macro in the Makefile, and install the miscd wrapper at
the original miscd location.
In the absence of any access-control tables, the daemon wrappers will
just maintain a record of network connections made to your system.
7.2 - Advanced configuration and installation
---------------------------------------------
The advanced recipe leaves your daemon executables alone, but involves
simple modifications to the inetd configuration file.
Type `make' and follow the instructions. The Makefile comes with ready-
to-use templates for many common UNIX implementations (sun, ultrix, hp-
ux, aix, irix, ...).
IRIX users should read the warnings in the README.IRIX file first.
When the `make' succeeds the result is five executables (six in case of
Ultrix).
You can use the `tcpdchk' program to identify the most common problems in
your wrapper and inetd configuration files.
With the `tcpdmatch' program you can examine how the wrapper would react
to specific requests for service.
The `try-from' program tests the host and username lookup code. Run it
from a remote shell command (`rsh host /some/where/try-from') and it
should be able to figure out from what system it is being called.
The `safe_finger' command should be used when you implement a booby trap:
it gives better protection against nasty stuff that remote hosts may do
in response to your finger probes.
Page 15
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
The tcpd program can be used to monitor the telnet, finger, ftp, exec,
rsh, rlogin, tftp, talk, comsat and other tcp or udp services that have a
one-to-one mapping onto executable files.
With System V.4-style systems, the tcpd program can also handle TLI
services. When TCP/IP or UDP/IP is used underneath TLI, tcpd provides the
same functions as with socket-based applications. When some other
protocol is used underneath TLI, functionality will be limited (no client
username lookups, weird network address formats).
The tcpd program can also be used for services that are marked as rpc/udp
in the inetd configuration file, but not for rpc/tcp services such as
rexd. You probably do not want to run rexd anyway. On most systems it is
even less secure than a wildcard in /etc/hosts.equiv.
Install the tcpd command in a suitable place. Apollo UNIX users will want
to install it under a different name because the name "tcpd" is already
taken; a suitable name would be "frontd".
File protections: the wrapper, all files used by the wrapper, and all
directories in the path leading to those files, should be accessible but
not writable for unprivileged users (mode 755 or mode 555). Do not
install the wrapper set-uid.
Then perform the following edits on the inetd configuration file (usually
/etc/inetd.conf or /etc/inet/inetd.conf):
finger stream tcp nowait nobody /usr/etc/in.fingerd
in.fingerd
^^^^^^^^^^^^^^^^^^^ becomes:
finger stream tcp nowait nobody /usr/etc/tcpd
in.fingerd
^^^^^^^^^^^^^ Send a `kill
-HUP' to the inetd process to make the change effective. Some IRIX inetd
implementations require that you first disable the finger service
(comment out the finger service and `kill -HUP' the inetd) before you can
turn on the modified version. Sending a HUP twice seems to work just as
well for IRIX 5.3, 6.0, 6.0.1 and 6.1.
AIX note: you may have to execute the `inetimp' command after changing
the inetd configuration file.
The example applies to SunOS 4. With other UNIX implementations the
network daemons live in /usr/libexec, /usr/sbin, or /etc, the network
daemons have no "in." prefix to their names, or the username field in the
inetd configuration file may be missing.
When the finger service works as expected you can perform similar changes
for other network services. Do not forget the `kill -HUP'.
The miscd daemon that comes with Ultrix implements several network
Page 16
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
services. It decides what to do by looking at its process name. One of
the services is systat, which is a kind of limited finger service. If
you want to monitor the systat service, install the miscd wrapper in a
suitable place and update the inetd configuration file:
systat stream tcp nowait /suitable/place/miscd systatd
Ultrix 4.3 allows you to specify a user id under which the daemon will be
executed. This feature is not documented in the manual pages. Thus, the
example would become:
systat stream tcp nowait nobody /suitable/place/miscd
systatd
Older Ultrix systems still run all their network daemons as root.
In the absence of any access-control tables, the daemon wrappers will
just maintain a record of network connections made to your system.
7.3 - Daemons with arbitrary path names
---------------------------------------
The above tcpd examples work fine with network daemons that live in a
common directory, but sometimes that is not practical. Having soft links
all over your file system is not a clean solution, either.
Instead you can specify, in the inetd configuration file, an absolute
path name for the daemon process name. For example,
ntalk dgram udp wait root /usr/etc/tcpd
/usr/local/lib/ntalkd
When the daemon process name is an absolute path name, tcpd ignores the
value of the REAL_DAEMON_DIR constant, and uses the last path component
of the daemon process name for logging and for access control.
7.4 - Building and testing the access control rules
---------------------------------------------------
In order to support access control the wrappers must be compiled with the
-DHOSTS_ACCESS option. The access control policy is given in the form of
two tables (default: /etc/hosts.allow and /etc/hosts.deny). Access
control is disabled when there are no access control tables, or when the
tables are empty.
If you haven't used the wrappers before I recommend that you first run
them a couple of days without any access control restrictions. The
logfile records should give you an idea of the process names and of the
host names that you will have to build into your access control rules.
The syntax of the access control rules is documented in the file
hosts_access.5, which is in `nroff -man' format. This is a lengthy
Page 17
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
document, and no-one expects you to read it right away from beginning to
end. Instead, after reading the introductory section, skip to the
examples at the end so that you get a general idea of the language. Then
you can appreciate the detailed reference sections near the beginning of
the document.
The examples in the hosts_access.5 document (`nroff -man' format) show
two specific types of access control policy: 1) mostly closed (only
permitting access from a limited number of systems) and 2) mostly open
(permitting access from everyone except a limited number of trouble
makers). You will have to choose what model suits your situation best.
Implementing a mixed policy should not be overly difficult either.
Optional extensions to the access control language are described in the
hosts_options.5 document (`nroff -man' format).
The `tcpdchk' program examines all rules in your access control files and
reports any problems it can find. `tcpdchk -v' writes to standard output
a pretty-printed list of all rules. `tcpdchk -d' examines the
hosts.access and hosts.allow files in the current directory. This program
is described in the tcpdchk.8 document (`nroff -man' format).
The `tcpdmatch' command can be used to try out your local access control
files. The command syntax is:
tcpdmatch process_name hostname (e.g.: tcpdmatch in.tftpd localhost)
tcpdmatch process_name address (e.g.: tcpdmatch in.tftpd 127.0.0.1)
This way you can simulate what decisions will be made, and what actions
will be taken, when hosts connect to your own system. The program is
described in the tcpdmatch.8 document (`nroff -man' format).
Note 1: `tcpdmatch -d' will look for hosts.{allow,deny} tables in the
current working directory. This is useful for testing new rules without
bothering your users.
Note 2: you cannot use the `tcpdmatch' command to simulate what happens
when the local system connects to other hosts.
In order to find out what process name to use, just use the service and
watch the process name that shows up in the logfile. Alternatively, you
can look up the name from the inetd configuration file. Coming back to
the tftp example in the tutorial section above:
tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot
This entry causes the inetd to run the wrapper program (tcpd) with a
process name `in.tftpd'. This is the name that the wrapper will use when
scanning the access control tables. Therefore, `in.tftpd' is the process
name that should be given to the `tcpdmatch' command. On your system the
actual inetd.conf entry may differ (tftpd instead of in.tftpd, and no
Page 18
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
`root' field), but you get the idea.
When you specify a host name, the `tcpdmatch' program will use both the
host name and address. This way you can simulate the most common case
where the wrappers know both the host address and the host name. The
`tcpdmatch' program will iterate over all addresses that it can find for
the given host name.
When you specify a host address instead of a host name, the `tcpdmatch'
program will pretend that the host name is unknown, so that you can
simulate what happens when the wrapper is unable to look up the client
host name.
7.5 - Other applications ------------------------
The access control routines can easily be integrated with other programs.
The hosts_access.3 manual page (`nroff -man' format) describes the
external interface of the libwrap.a library.
The tcpd program can even be used to control access to the mail service.
This can be useful when you suspect that someone is trying out some
obscure sendmail bug, or when a remote site is misconfigured and keeps
hammering your mail daemon.
In that case, sendmail should not be run as a stand-alone network
listener, but it should be registered in the inetd configuration file.
For example:
smtp stream tcp nowait root /usr/etc/tcpd
/usr/lib/sendmail -bs
You will still need to run one sendmail background process to handle
queued-up outgoing mail. A command like:
/usr/lib/sendmail -q15m
(no `-bd' flag) should take care of that. You cannot really prevent
people from posting forged mail this way, because there are many
unprotected smtp daemons on the network.
8 - Acknowledgements --------------------
Many people contributed to the evolution of the programs, by asking
inspiring questions, by suggesting features or bugfixes, or by submitting
source code. Nevertheless, all mistakes and bugs in the wrappers are my
own.
Thanks to Brendan Kehoe (cs.widener.edu), Heimir Sverrisson (hafro.is)
and Dan Bernstein (kramden.acf.nyu.edu) for feedback on an early release
of this product. The host name/address check was suggested by John
Kimball (src.honeywell.com). Apollo's UNIX environment has some peculiar
quirks: Willem-Jan Withagen (eb.ele.tue.nl), Pieter Schoenmakers
Page 19
TCP_WRAPPERS(8)TCP_WRAPPERS(8)
(es.ele.tue.nl) and Charles S. Fuller (wccs.psc.edu) provided assistance.
Hal R. Brand (addvax.llnl.gov) told me how to get the client IP address
in case of datagram-oriented services, and suggested the optional shell
command feature. Shabbir Safdar (mentor.cc.purdue.edu) provided a first
version of a much-needed manual page. Granville Boman Goza, IV
(sei.cmu.edu) suggested to use the client IP address even when the host
name is available. Casper H.S. Dik (fwi.uva.nl) provided additional
insight into DNS spoofing techniques. The bogus daemon feature was
inspired by code from Andrew Macpherson (BNR Europe Ltd). Steve Bellovin
(research.att.com) confirmed some of my suspicions about the darker sides
of TCP/IP insecurity. Risks of automated fingers were pointed out by
Borja Marcos (we.lc.ehu.es). Brad Plecs (jhuspo.ca.jhu.edu) was kind
enough to try my early TLI code and to work out how DG/UX differs from
Solaris.
John P. Rouillard (cs.umb.edu) deserves special mention for his
persistent, but constructive, nagging about wrong or missing things, and
for trying out and discussing embryonic code or ideas.
Last but not least, Howard Chu (hanauma.jpl.nasa.gov), Darren Reed
(coombs.anu.edu.au), Icarus Sparry (gdr.bath.ac.uk), Scott Schwartz
(cs.psu.edu), John A. Kunze (violet.berkeley.edu), Daniel Len Schales
(engr.latech.edu), Chris Turbeville (cse.uta.edu), Paul Kranenburg
(cs.few.eur.nl), Marc Boucher (cam.org), Dave Mitchell (dcs.shef.ac.uk),
Andrew Maffei, Adrian van Bloois, Rop Gonggrijp, John C. Wingenbach,
Everett F. Batey and many, many others provided fixes, code fragments,
or ideas for improvements.
Wietse Venema (wietse@wzv.win.tue.nl)
Department of Mathematics and Computing Science
Eindhoven University of Technology
P.O. Box 513
5600 MB Eindhoven
The Netherlands
Currently visiting IBM T.J. Watson Research, Hawthorne NY, USA.
SEE ALSOhosts_access(5), format of the tcpd access control tables.
tcpdchk(8), tcpdmatch(8), test programs.
inetd(1m).
Page 20
