--- /dev/null
+$OpenBSD: CHANGES,v 1.1 1997/02/26 06:00:31 downsj Exp $
+
+Request: after building the programs, please run the `tcpdchk' wrapper
+configuration checker. See the `tcpdchk.8' manual page (`nroff -man'
+format) for instructions. `tcpdchk' automatically identifies the most
+common configuration problems, and will save you and me a lot of time.
+
+Changes per release 7.5 (Feb 1997)
+==================================
+
+- Optionally refuse source-routed TCP connections requests altogether.
+Credits to Niels Provos of Universitaet Hamburg. File: fix_options.c.
+
+- Support for IRIX 6 (Lael Tucker).
+
+- Support for Amdahl UTS 2.1.5 (Richard E. Richmond).
+
+- Support for SINIX 5.42 (Klaus Nielsen).
+
+- SCO 5 now has vsyslog() (Bill Golden).
+
+- Hints and tips for dealing with IRIX inetd (Niko Makila, Aaron
+M Lee).
+
+- Support for BSD/OS (Paul Borman).
+
+- Support for Tandem (Emad Qawas).
+
+- Support for ISC (Frederick B. Cohen).
+
+- Workaround for UNICOS - it would choke on a setjmp() expression
+(Bruce Kelly). File: hosts_access.c, tcpdchk.c.
+
+- Increased the level of buffer overflow paranoia when printing
+unwanted IP options. File: fix_options.c.
+
+Changes per release 7.4 (Mar 1996)
+==================================
+
+- IRIX 5.3 (and possibly, earlier releases, too) library routines call
+the non-reentrant strtok() routine. The result is that hosts may slip
+through allow/deny filters. Workaround is to not rely on the vendor's
+strtok() routine (#ifdef LIBC_CALLS_STRTOK). Credits to Th. Eifert
+(Aachen University) for spotting this one. This fix supersedes the
+earlier workaround for a similar problem in FreeBSD 2.0.
+
+Changes per release 7.3 (Feb 1996)
+==================================
+
+- More tests added to tcpdchk and tcpdmatch: make sure that the
+REAL_DAEMON_DIR actually is a directory and not a regular file;
+detect if tcpd recursively calls itself.
+
+- Edwin Kremer found an amusing fencepost error in the xgets()
+routine: lines longer than BUFLEN characters would be garbled.
+
+- The access control routines now refuse to execute "dangerous" actions
+such as `twist' when they are called from within a resident process.
+This prevents you from shooting yourself into the foot with critical
+systems programs such as, e.g., portmap or rpcbind.
+
+- Support for Unicos 8.x (Bruce Kelly). The program now closes the
+syslog client socket before running the real daemon: Cray UNICOS
+refuses to checkpoint processes with open network ports.
+
+- Support for MachTen UNIX (Albert M.C Tam).
+
+- Support for Interactive UNIX R3.2 V4.0 (Bobby D. Wright).
+
+- Support for SCO 3.2v5.0.0 OpenServer 5 (bob@odt.handy.com)
+
+- Support for Unixware 1.x and Unixware 2.x. The old Unixware Makefile
+rule was broken. Sorry about that.
+
+- Some FreeBSD 2.0 libc routines call strtok() and severely mess up the
+allow/deny rule processing. This is very bad. Workaround: call our own
+strtok() clone (#ifdef USE_STRSEP).
+
+- The programs now log a warning when they detect that a non-existent
+banner directory is specified.
+
+- The hosts_access.3 manual page used obsolete names for the RQ_*
+constants.
+
+Changes per release 7.2 (Jan 1995)
+==================================
+
+- Added a note to the README and manpages on using the IDENT service to
+detect sequence number spoofing and other host impersonation attacks.
+
+- Portability: ConvexOS puts RPC version numbers before the daemon path
+name (Jukka Ukkonen).
+
+- Portability: the AIX compiler disliked the strchr() declaration
+in socket.c. I should have removed it when I included <string.h>.
+
+- Backwards compatibility: some people relied on the old leading dot or
+trailing dot magic in daemon process names.
+
+- Backwards compatibility: hostname lookup remains enabled when
+-DPARANOID is turned off. In order to disable hostname lookups you
+must turn off -DALWAYS_HOSTNAME.
+
+- Eliminated false complaints from the tcpdmatch/tcpdchk configuration
+checking programs about process names not in inetd.conf or about KNOWN
+username patterns.
+
+Changes per release 7.1 (Jan 1995)
+==================================
+
+- Portability: HP-UX permits you to break inetd.conf entries with
+backslash-newline.
+
+- Portability: EP/IX has no putenv() and some inetd.conf entries are
+spread out over two lines.
+
+- Portability: SCO with NIS support has no *netgrent() routines.
+
+Changes per release 7.0 (Jan 1995)
+==================================
+
+- Added a last-minute workaround for a Solaris 2.4 gethostbyname()
+foulup with multi-homed hosts in DNS through NIS mode.
+
+- Added a last-minute defense against TLI weirdness: address lookups
+apparently succeed but the result netbuf is empty (ticlts transport).
+
+- Dropped several new solutions that were in need of a problem. Beta
+testers may recognize what new features were kicked out during the last
+weeks before release 7.0 came out. Such is life.
+
+- Got rid of out the environment replacement routines, at least for
+most architectures. One should not have to replace working system
+software when all that is needed is a 4.4BSD setenv() emulator.
+
+- By popular request I have added an option to send banner messages to
+clients. There is a Banners.Makefile that gives some aid for sites that
+are going to use this feature. John C. Wingenbach did some pioneering
+work here. I used to think that banners are frivolous. Now that I had
+a personal need for them I know that banners can be useful.
+
+- At last: an extensible functional interface to the pattern matching
+engine. request_init() and request_set() accept a variable-length
+name-value argument list. The result can be passed to hosts_access().
+
+- When PARANOID mode is disabled (compile time), the wrapper does no
+hostname lookup or hostname double checks unless required by %letter
+expansions, or by access control rules that match host names. This is
+useful for sites that don't care about internet hostnames anyway.
+Inspired by the authors of the firewalls and internet security book.
+
+- When PARANOID mode is disabled (compile time), hosts with a name/name
+or name/address conflict can be matched with the PARANOID host wildcard
+pattern, so that you can take some intelligent action instead of just
+dropping clients. Like showing a banner that explains the problem.
+
+- New percent escapes: %A expands to the server address; %H expands to
+the corresponding hostname (or address if no name is available); %n and
+%N expand to the client and server hostname (or "unknown"); %s expands
+to everything we know about the server endpoint (the opposite of the %c
+sequence for client information).
+
+- Symmetry: server and client host information is now treated on equal
+footing, so that we can reuse a lot of code.
+
+- Lazy evaluation of host names, host addresses, usernames, and so on,
+to avoid doing unnecessary work.
+
+- Dropping #ifdefs for some archaic systems made the code simpler.
+
+- Dropping the FAIL pattern made the pattern matcher much simpler. Run
+the "tcpdchk" program to scan your access control files for any uses of
+this obscure language feature.
+
+- Moving host-specific pattern matching from string_match() to the
+host_match() routine made the code more accurate. Run the "tcpdchk"
+program to scan your access control files for any dependencies on
+undocumented or obscure language features that are gone.
+
+- daemon@host patterns trigger on clients that connect to a specific
+internet address. This can be useful for service providers that offer
+multiple ftp or www archives on different internet addresses, all
+belonging to one and the same host (www.foo.com, ftp.bar.com, you get
+the idea). Inspired by a discussion with Rop Gonggrijp, Cor Bosman,
+and Casper Dik, and earlier discussions with Adrian van Bloois.
+
+- The new "tcpdchk" program critcizes all your access control rules and
+inetd.conf entries. Great for spotting obscure bugs in my own hosts.xxx
+files. This program also detects hosts with name/address conflicts and
+with other DNS-related problems. See the "tcpdchk.8" manual page.
+
+- The "tcpdmatch" program replaces the poor old "try" command. The new
+program looks in your inetd.conf file and therefore produces much more
+accurate predictions. In addition, it detects hosts with name/address
+conflicts and with other DNS-related problems. See the "tcpdmatch.8"
+manual page. The inetd.conf lookup was suggested by Everett F Batey.
+
+- In the access control tables, the `=' between option name and value
+is no longer required.
+
+- Added 60-second timeout to the safe_finger command, to cover another
+potential problem. Suggested by Peter Wemm.
+
+- Andrew Maffei provided code that works with WIN-TCP on NCR System V.4
+UNIX. It reportedly works with versions 02.02.01 and 02.03.00. The code
+pops off all streams modules above the device driver, pushes the timod
+module to get at the peer address, and then restores the streams stack
+to the initial state.
+
+Changes per release 6.3 (Mar 1994)
+==================================
+
+- Keepalives option, to get rid of stuck daemons when people turn off
+their PC while still connected. Files: options.c, hosts_options.5.
+
+- Nice option, to calm down network daemons that take away too much CPU
+time. Files: options.c, hosts_options.5.
+
+- Ultrix perversion: the environ global pointer may be null. The
+environment replacement routines now check for this. File: environ.c.
+
+- Fixed a few places that still assumed the socket is on standard
+input. Fixed some error messages that did not provide access control
+file name and line number. File: options.c.
+
+- Just when I was going to release 6.2 I received code for Dynix/PTX.
+That code is specific to PTX 2.x, so I'll keep around my generic
+PTX code just in case. The difference is in the handling of UDP
+services. Files: tli_sequent.[hc].
+
+Changes per release 6.2 (Feb 1994)
+==================================
+
+- Resurrected my year-old code to reduce DNS load by appending a dot to
+the gethostbyname() argument. This feature is still experimental and it
+may go away if it causes more problems than it solves. File: socket.c.
+
+- Auxiliary code for the Pyramid, BSD universe. Karl Vogel figured out
+what was missing: yp_get_default_domain() and vfprintf(). Files:
+workarounds.c, vfprintf.c.
+
+- Improved support for Dynix/PTX. The wrapper should now be able to
+deal with all TLI over IP services. File: ptx.c.
+
+- The try command now uses the hostname that gethostbyaddr() would
+return, instead of the hostname returned by gethostbyname(). This can
+be significant on systems with NIS that have short host names in the
+hosts map. For example, gethostbyname("wzv.win.tue.nl") returns
+"wzv.win.tue.nl"; gethostbyaddr(131.155.210.17) returns "wzv", and
+that is what we should test with. File: try.c.
+
+Changes per release 6.1 (Dec 1993)
+==================================
+
+- Re-implemented all environment access routines. Most systems have
+putenv() but no setenv(), some systems have setenv() but no putenv(),
+and there are even systems that have neither setenv() nor putenv(). The
+benefit of all this is that more systems can now be treated in the same
+way. File: environ.c.
+
+- Workaround for a weird problem with DG/UX when the wrapper is run as
+nobody (i.e. fingerd). For some reason the ioctl(fd, I_FIND, "sockmod")
+call fails even with socket-based applications. The "fix" is to always
+assume sockets when the ioctl(fd, I_FIND, "timod") call fails. File:
+fromhost.c. Thanks to Paul de Vries (vries@dutentb.et.tudelft.nl) for
+helping me to figure out this one.
+
+- Implemented a workaround for Dynix/PTX and other systems with TLI
+that lack some essential support routines. Thanks to Bugs Brouillard
+(brouill@hsuseq.humboldt.edu) for the hospitality to try things out.
+The trick is to temporarily switch to the socket API to identify the
+client, and to switch back to TLI when done. It still does not work
+right for basic network services such as telnet. File: fromhost.c.
+
+- Easy-to-build procedures for SCO UNIX, ConvexOS with UltraNet, EP/IX,
+Dynix 3.2, Dynix/PTX. File: Makefile.
+
+- Variable rfc931 timeout. Files: rfc931.c, options.c, log_tcp.h, try.c.
+
+- Further simplification of the rfc931 code. File: rfc931.c.
+
+- The fromhost() interface stinks: I cannot change that, but at least
+the from_sock() and from_tli() functions now accept a file descriptor
+argument.
+
+- Fixed a buglet: fromhost() would pass a garbage file descriptor to
+the isastream() call.
+
+- On some systems the finger client program lives in /usr/bsd. File:
+safe_finger.c.
+
+Changes per release 6.0 (Sept 1993)
+===================================
+
+- Easy build procedures for common platforms (sun, ultrix, aix, hpux
+and others).
+
+- TLI support, System V.4 style (Solaris, DG/UX).
+
+- Username lookup integrated with the access control language.
+Selective username lookups are now the default (was: no username
+lookups).
+
+- A safer finger command for booby traps. This one solves a host of
+possible problems with automatic reverse fingers. Thanks, Borja Marcos
+(borjam@we.lc.ehu.es) for some inspiring discussions.
+
+- KNOWN pattern that matches hosts whose name and address are known.
+
+- Cleanup of diagnostics. Errors in access-control files are now shown
+with file name and line number.
+
+- With AIX 3.2, hostnames longer than 32 would be truncated. This
+caused hostname verification failures, so that service would be refused
+when paranoid mode was enabled. Found by: Adrian van Bloois
+(A.vanBloois@info.nic.surfnet.nl).
+
+- With some IRIX versions, remote username lookups failed because the
+fgets() library function does not handle partial read()s from sockets.
+Found by: Daniel O'Callaghan (danny@austin.unimelb.edu.au).
+
+- Added a DISCLAIMER document to help you satisfy legal departments.
+
+The extension language module has undergone major revisions and
+extensions. Thanks, John P. Rouillard (rouilj@ra.cs.umb.edu) for
+discussions, experiments, and for being a good guinea pig. The
+extensions are documented in hosts_options.5, and are enabled by
+editing the Makefile STYLE macro definition.
+
+- (Extension language) The ":" separator may now occur within options
+as long as it is protected with a backslash. A warning is issued when
+a rule ends on ":".
+
+- (Extension language) Better verification mode. When the `try' command
+is run, each option function now explains what it would do.
+
+- (Extension language) New "allow" and "deny" keywords so you can now
+have all rules within a single file. See "nroff -man hosts_options.5"
+for examples.
+
+- (Extension language) "linger" keyword to set the socket linger time
+(SO_LINGER). From: Marc Boucher <marc@cam.org>.
+
+- (Extension language) "severity" keyword to turn the logging noise up
+or down. Many sites wanted a means to shut up the program; other sites
+wanted to emphasize specific events. Adapted from code contributed
+by Dave Mitchell <D.Mitchell@dcs.shef.ac.uk>.
+
+Changes per release 5.1 (Mar 1993)
+==================================
+
+- The additional protection against source-routing attacks from hosts
+that pretend to have someone elses network address has become optional
+because it causes kernel panics with SunOS <= 4.1.3.
+
+Changes per release 5.0 (Mar 1993)
+==================================
+
+- Additional protection against source-routing attacks from hosts that
+pretend to have someone elses network address. For example, the address
+of a trusted host within your own network.
+
+- The access control language has been extended with a simple but
+powerful operator that greatly simplifies the design of rule sets (ALL:
+.foo.edu EXCEPT dialup.foo.edu). Blank lines are permitted, and long
+lines can be continued with backslash-newline.
+
+- All configurable stuff, including path names, has been moved into the
+Makefile so that you no longer have to hack source code to just
+configure the programs.
+
+- Ported to Solaris 2. TLI-based applications not yet supported.
+Several workarounds for System V bugs.
+
+- A small loophole in the netgroup lookup code was closed, and the
+remote username lookup code was made more portable.
+
+- Still more documentation. The README file now provides tutorial
+sections with introductions to client, server, inetd and syslogd.
+
+Changes per release 4.3 (Aug 1992)
+==================================
+
+- Some sites reported that connections would be rejected because
+localhost != localhost.domain. The host name checking code now
+special-cases localhost (problem reported by several sites).
+
+- The programs now report an error if an existing access control file
+cannot be opened (e.g. due to lack of privileges). Until now, the
+programs would just pretend that the access control file does not exist
+(reported by Darren Reed, avalon@coombs.anu.edu.au).
+
+- The timeout period for remote userid lookups was upped to 30 seconds,
+in order to cope with slow hosts or networks. If this is too long for
+you, adjust the TIMEOUT definition in file rfc931.c (problem reported
+by several sites).
+
+- On hosts with more than one IP network interface, remote userid
+lookups could use the IP address of the "wrong" local interface. The
+problem and its solution were discussed on the rfc931-users mailing
+list. Scott Schwartz (schwartz@cs.psu.edu) folded the fix into the
+rfc931.c module.
+
+- The result of % expansion (in shell commands) is now checked for
+stuff that may confuse the shell; it is replaced by underscores
+(problem reported by Icarus Sparry, I.Sparry@gdr.bath.ac.uk).
+
+- A portability problem was fixed that caused compile-time problems
+on a CRAY (problem reported by Michael Barnett, mikeb@rmit.edu.au).
+
+Changes per release 4.0 (Jun 1992)
+==================================
+
+1 - network daemons no longer have to live within a common directory
+2 - the access control code now uses both the host address and name
+3 - an access control pattern that supports netmasks
+4 - additional protection against forged host names
+5 - a pattern that matches hosts whose name or address lookup fails
+6 - an operator that prevents hosts or services from being matched
+7 - optional remote username lookup with the RFC 931 protocol
+8 - an optional umask to prevent the creation of world-writable files
+9 - hooks for access control language extensions
+10 - last but not least, thoroughly revised documentation.
+
+Changes per release 3.0 (Oct 1991)
+==================================
+
+Enhancements over the previous release are: support for datagram (UDP
+and RPC) services, and execution of shell commands when a (remote host,
+requested service) pair matches a pattern in the access control tables.
+
+Changes per release 2.0 (May 1991)
+==================================
+
+Enhancements over the previous release are: protection against rlogin
+and rsh attacks through compromised domain name servers, optional
+netgroup support for systems with NIS (formerly YP), and an extension
+of the wild card patterns supported by the access control files.
+
+Release 1.0 (Jan 1991)
--- /dev/null
+$OpenBSD: README,v 1.1 1997/02/26 06:00:35 downsj Exp $
+@(#) README 1.29 97/02/12 02:13:20
+
+This is the 7.5 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
+ 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.
+
+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
+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
+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.
+
+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, 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.
+
+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 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>
+
+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,
+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
+----------------------
+
+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 from sierra.stanford.edu, directory /pub/sources.
+
+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 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.
+
+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
+-----------------------------------------
+
+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 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.
+
+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
+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
+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 `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 (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.
projects / openbsd / commitdiff