Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/misc/volume39/tcp_wrappers/part01

Text File | 1993-09-29 | 58.4 KB | 1,480 lines

Newsgroups: comp.sources.misc
From: [e-mail] (Wietse Venema)
Subject: v39i110:  tcp_wrappers - TCP/IP daemon wrappers, v6.0, Part01/04
Message-ID: <csm-v39i110=[e-mail]>
X-Md4-Signature: f7f0bba0608f3341f993d4d163f6a3fc
Sender: [e-mail] (Kent Landfield)
Organization: Eindhoven University of Technology, The Netherlands
Date: Wed, 29 Sep 1993 21:56:53 GMT
Approved: [e-mail]

Submitted-by: [e-mail] (Wietse Venema)
Posting-number: Volume 39, Issue 110
Archive-name: tcp_wrappers/part01
Environment: UNIX, INET
Supersedes: log_tcp: Volume 36, Issue 4-6

This is the 6.0 version of the TCP/IP daemon wrapper package.

With these programs you can monitor and control who connects to your
TFTP, EXEC, FTP, RSH, TELNET, RLOGIN, FINGER, and many other network
services.  The programs can be installed without changes to existing
software or configuration files.

Significant differences with respect to the previous release:

    - Easier to install: ready-to-use build procedures for many common
    UNIX implementations (sun, ultrix, hp-ux, irix, aix, ...).

    - Support for the System V.4 TLI network programming interface
    (Solaris, DG/UX etc.).  In case of TLI applications on top of
    TCP/IP, the wrappers provide the same functionality as with
    socket-based applications.

    - A more secure finger tool for automatic reverse finger probes.

    - New extension language keywords:  "severity", to adjust the log
    noise level; "allow" and "deny", to keep all access-control rules
    within a single file.

    - More support for selective remote username lookups.

    - More workarounds for System V bugs: IRIX username lookups, and
    SCO problems with UDP.

The default mode of operation (no TLI support) should be backwards
compatible with earlier versions. The library interface has changed,
though, and programs that depend on the libwrap.a library will have to
be recompiled before they can be relinked.

    Wietse Venema ([e-mail]),
    Department of Mathematics and Computing Science,
    Eindhoven University of Technology,
    The Netherlands.
----
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#        "End of archive 1 (of 4)."
# Contents:  README BLURB CHANGES DISCLAIMER clean_exit.c fakelog.c
#   fix_options.c fromhost.c hosts_ctl.c hosts_info.c
# Wrapped by wietse@wzv on Wed Sep 29 18:45:46 1993
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f README -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"README\"
else
echo shar: Extracting \"README\" \(37825 characters\)
sed "s/^X//" >README <<'END_OF_README'
X@(#) README 1.17 93/09/28 23:03:22
X
XThis is the 6.0 version of the TCP/IP daemon wrapper package.
X
XTable of contents
X-----------------
X
X    1 - Introduction
X    2 - Disclaimer
X    3 - Tutorials
X        3.1 - How it works
X        3.2 - Where the logging information goes
X    4 - Features
X        4.1 - Access control
X        4.2 - Host name spoofing
X        4.3 - Host address spoofing
X        4.4 - Remote username lookups
X        4.5 - Language extensions
X    5 - Other works
X        5.1 - Related documents
X        5.2 - Related software
X    6 - Limitations
X        6.1 - Known wrapper limitations
X        6.2 - Known system software bugs
X    7 - Configuration and installation
X        7.1 - Easy configuration and installation
X        7.2 - Advanced configuration and installation
X        7.3 - Daemons with arbitrary path names
X        7.4 - Building and testing the access control rules
X        7.5 - Other applications
X    8 - Acknowledgements
X
X1 - Introduction
X----------------
X
XWith this package you can monitor and filter incoming requests for the
XSYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other
Xnetwork services.
X
XIt supports both 4.3BSD-style sockets and System V.4-style TLI. Praise
Xyourself lucky if you don't know what that means.
X
XThe package provides tiny daemon wrapper programs that can be installed
Xwithout any changes to existing software or to existing configuration
Xfiles.  The wrappers report the name of the remote host and of the
Xrequested service; the wrappers do not exchange information with the
Xremote client process, and impose no overhead on the actual
Xcommunication between the client and server applications.
X
XOptional features are: access control to restrict what systems can
Xconnect to your network daemons; remote user name lookups with the RFC
X931 protocol; additional protection against hosts that pretend to have
Xsomeone elses host name; additional protection against hosts that
Xpretend to have someone elses host address.
X
XEarly versions of the programs were tested with Ultrix >= 2.2, with
XSunOS >= 3.4 and ISC 2.2. Later versions have been installed on a wide
Xvariety of platforms such as SunOS 4.x and 5.x, Ultrix 3.x and 4.x, DEC
XOSF/1 T1.2-2, HP-UX 8.x, AIX 3.1.5 up to 3.2.4, Apollo SR10.3.5, Sony,
XNeXT, SCO UNIX, DG/UX, Cray, and an unknown number of other ones.
X
XRequirements are that the network daemons are spawned by a super server
Xsuch as the inetd; a 4.3BSD-style socket programming interface and/or
XSystem V.4-style TLI programming interface; and the availability of a
Xsyslog(3) library and of a syslogd(8) daemon.  The wrappers should run
Xwithout modification on any system that satisfies these requirements.
XWorkarounds have been implemented for several common bugs in systems
Xsoftware.
X
XWhat to do if this is your first encounter with the wrapper programs:
X1) read the tutorial sections for an introduction to the relevant
Xconcepts and terminology; 2) glance over the security feature sections
Xin this document; 3) follow the installation instructions (easy or
Xadvanced). I recommend that you first use the default security feature
Xsettings.  Run the wrappers for a few days to become familiar with
Xtheir logs, before doing anything drastic such as cutting off access or
Xinstalling booby traps.
X
X2 - Disclaimer
X--------------
X
XThe wrapper programs rely on source address information obtained from
Xnetwork packets. Such information is not 100 percent reliable, although
Xthe wrappers do their best to expose forgeries.
X
XIn the absence of cryptographic protection of message contents, and of
Xcryptographic authentication of message originators, all data from the
Xnetwork should be treated with sound scepticism.
X
XTHIS RESTRICTION IS BY NO MEANS SPECIFIC TO THE TCP/IP PROTOCOLS.
X
X3 - Tutorials
X-------------
X
XThe tutorial sections give a gentle introduction to the operation of
Xthe wrapper programs, and introduce some of the terminology that is
Xused in the remainder of the document: client, server, the inetd and
Xsyslogd daemons, and their configuration files.
X
X3.1 - How it works
X------------------
X
XAlmost every application of the TCP/IP protocols is based on a client-
Xserver model. For example, when a user invokes the telnet command to
Xconnect to one of your systems, a telnet server process is executed on
Xthe target host. The telnet server process connects the user to a login
Xprocess. A few examples of client and server programs are shown in the
Xtable below:
X
X              client   server    application
X              --------------------------------
X              telnet   telnetd   remote login
X              ftp      ftpd      file transfer
X              finger   fingerd   show users
X
XThe usual approach is to run one single daemon process that waits for
Xall kinds of incoming network connections. Whenever a connection is
Xestablished, this daemon (usually called inetd) runs the appropriate
Xserver program and goes back to sleep, waiting for other connections.
X
XThe wrapper programs rely on a simple, but powerful mechanism.  Instead
Xof directly running the desired server program, the inetd is tricked
Xinto running a small wrapper program. The wrapper logs the remote host
Xname or address and performs some additional checks.  When all is well,
Xthe wrapper executes the desired server program and goes away.
X
XThe wrapper programs have no interaction with the remote user (or
Xclient process).  This has two major advantages: 1) the wrappers are
Xapplication-independent, so that the same program can protect many
Xkinds of network services; 2) no interaction also means that the
Xwrappers are invisible from outside (at least for authorized users).
X
XAnother important property is that the wrapper programs are active only
Xwhen the initial contact between client and server is established. Once
Xa wrapper has done its work there is no overhead on the client-server
Xcommunication.
X
XThe simple mechanism has one major drawback: since the wrappers go away
Xafter the initial contact between client and server processes, the
Xwrappers are of little use with network daemons that service more than
Xone client.  The wrappers would only see the first client attempt to
Xcontact such a server. The NFS mount daemon is a typical example of a
Xdaemon that services requests from multiple clients. See the section on
Xrelated software for ways to deal with such programs.
X
XThere are two ways to use the wrapper programs:
X
X1) The easy way: move network daemons to some other directory and fill
X   the resulting holes with copies of the wrapper programs.  This
X   approach involves no changes to system configuration files, so there
X   is very little risk of breaking things.
X
X2) The advanced way: leave the network daemons alone and modify the
X   inetd configuration file.  For example, an entry such as:
X
X     tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd -s /tftpboot
X
X   When a tftp request arrives, inetd will run the wrapper program
X   (tcpd) with a process name `in.tftpd'.  This is the name that the
X   wrapper will use when logging the request and when scanning the
X   optional access control tables.  `in.tftpd' is also the name of the
X   server program that the wrapper will attempt to run when all is
X   well.  Any arguments (`-s /tftpboot' in this particular example) are
X   transparently passed on to the server program.
X
XFor an account of the history of the wrapper programs, with real-life
Xexamples, see the section below on related documents.
X
X3.2 - Where the logging information goes
X----------------------------------------
X
XThe wrapper programs send their logging information to the syslog
Xdaemon (syslogd). The disposition of the wrapper logs is determined by
Xthe syslog configuration file (usually /etc/syslog.conf). Messages are
Xwritten to files, to the console, or are forwarded to a @loghost.
X
XOlder syslog implementations (still found on Ultrix systems) only
Xsupport priority levels ranging from 9 (debug-level messages) to 0
X(alerts). All logging information of the same priority level (or more
Xurgent) is written to the same destination.  In the syslog.conf file,
Xpriority levels are specified in numerical form.  For example,
X
X    8/usr/spool/mqueue/syslog
X
Xcauses all messages with priority 8 (informational messages), and
Xanything that is more urgent, to be appended to the file
X/usr/spool/mqueue/syslog.
X
XNewer syslog implementations support message classes in addition to
Xpriority levels.  Examples of message classes are: mail, daemon, auth
Xand news. In the syslog.conf file, priority levels are specified with
Xsymbolic names: debug, info, notice, ..., emerg. For example,
X
X    mail.debug            /var/log/syslog
X
Xcauses all messages of class mail with priority debug (or more urgent)
Xto be appended to the /var/log/syslog file.
X
XBy default, the wrapper logs go to the same place as the transaction
Xlogs of the sendmail daemon. The disposition can be changed by editing
Xthe Makefile and/or the syslog.conf file. Send a `kill -HUP' to the
Xsyslogd after changing its configuration file. Remember that syslogd,
Xjust like sendmail, insists on one or more TABs between the left-hand
Xside and the right-hand side expressions in its configuration file.
X
X4 - Features
X------------
X
X4.1 - Access control
X--------------------
X
XWhen compiled with -DHOSTS_ACCESS, the wrapper programs support a
Xsimple form of access control.  Access can be controlled per host, per
Xservice, or combinations thereof. The software provides hooks for the
Xexecution of shell commands when an access control rule fires; this
Xfeature may be used to install "booby traps".  For details, see the
Xhosts_access.5 manual page, which is in `nroff -man' format. A later
Xsection describes how you can test your access control rules. The
Xhosts_options.5 manual page describes additional features that
Xare turned off by default.
X
XAccess control is enabled by default. It can be turned off by editing
Xthe Makefile, or by providing no access control tables. The install
Xinstructions below describe the Makefile editing process.
X
XWhen TCP/IP or UDP/IP is used underneath TLI, the wrapper programs
Xprovide the same functions as with socket-based applications. When some
Xother protocol is used underneath TLI, the host address will be some
Xuniversal magic cookie that may not be usable for access control
Xpurposes.
X
X4.2 - Host name spoofing
X------------------------
X
XWith some network applications, such as RSH or RLOGIN, the remote host
Xname plays an important role in the authentication process. Host name
Xinformation can be reliable when lookups are done from a _local_ hosts
Xtable, provided that the client IP address can be trusted.
X
XWith _distributed_ name services, authentication schemes that rely on
Xhost names become more problematic. The security of your system now may
Xdepend on some far-away DNS (domain name server) outside your own
Xcontrol.
X
XThe wrapper programs verify the remote host name that is returned by
Xthe address->name DNS server, by asking for a second opinion.  To this
Xend, the programs look at the name and addresses that are returned by
Xthe name->address DNS server.
X
XIf any name or address discrepancies are found, or if the second DNS
Xopinion is not available, the wrappers assume that one of the two name
Xservers is lying, and assume that the client host pretends to have
Xsomeone elses host name.
X
XWhen the sources are compiled with -DPARANOID, the wrappers will drop
Xthe connection in case of a host name/address discrepancy.
X
XWhen the sources are not compiled with -DPARANOID, the wrappers just
Xpretend that an offending host name is unknown.
X
XParanoid mode is enabled by default. It can be turned off by editing
Xthe Makefile. The configuration and installation below describes the
XMakefile editing process.
X
X4.3 - Host address spoofing
X---------------------------
X
XWhile host name spoofing can be found out by asking a second opinion,
Xit is much harder to find out that a host claims to have someone elses
Xnetwork address. And since host names are deduced from network
Xaddresses, address spoofing is at least as effective as name spoofing.
X
XThe wrapper programs can give additional protection against hosts that
Xclaim to have an address that lies outside their own network.  For
Xexample, some far-away host that claims to be a trusted host within
Xyour own network. Such things are possible even while the impersonated
Xsystem is up and running.
X
XThis additional protection is not an invention of my own; it has been
Xpresent for at least five years in the BSD rsh and rlogin daemons.
XUnfortunately, that feature was added *after* 4.3 BSD came out, so that
Xvery few, if any, UNIX vendors have adopted it.  Our site, and many
Xother ones, has been running these enhanced daemons for several years,
Xand without any ill effects.
X
XWhen the programs are compiled with -DKILL_IP_OPTIONS, source routing
Xwill be disabled for all TCP connections that are handled by the
Xwrapper programs.
X
XAll this cannot be used with SunOS 4.x because of a kernel bug in the
Ximplementation of the getsockopt() system call. Kernel panics have been
Xobserved for SunOS 4.1.1 up to SunOS 4.1.3. The symptoms are "BAD TRAP"
Xand "Data fault" while executing the tcp_ctloutput() kernel function.
X
XThe feature is disabled by default. It can be turned on by editing the
XMakefile.  The configuration and installation section below describes
Xthe Makefile editing process.
X
XUDP services do not benefit from this additional protection. With UDP,
Xall you can be certain of is the network packet's destination address.
X
X4.4 - Remote username lookups
X-----------------------------
X
XThe protocol proposed in RFC 931 provides a means to get the remote
Xuser name from the client host.  The requirement is that the client
Xhost runs an RFC 931-compliant daemon. The information provided by such
Xa daemon is not intended to be used for authentication purposes, but it
Xcan provide additional information about the owner of a TCP connection.
X
XThere are some limitations: the number of hosts that run an RFC 931 (or
Xcompatible) daemon is small (but growing); remote user name lookups do
Xnot work for datagram (UDP) connections. More seriously, remote user
Xname lookups can cause noticeable delays with connections from non-UNIX
XPCs. The wrappers use a 10-second timeout for RFC931 lookups, to
Xaccommodate slow networks and slow hosts.
X
XBy default, the wrappers will do username lookup only when the access
Xcontrol rules require them to do so.  The wrappers can be configured to
Xalways perform remote username lookups by editing the Makefile.  The
Xremote username lookup timeout period (10 seconds default) can also be
Xchanged by editing the Makefile. The installation sections below
Xdescribe the Makefile editing process.
X
XThe RFC 931 protocol has diverged into different directions (IDENT and
XTAP). To add to the confusion, both protocols use the same network
Xport.  The daemon wrappers implement a common subset of the protocols.
X
XWith TLI-based network services, remote username lookups will be
Xpossible only when TCP/IP is the underlying network protocol.
X
X4.5 - Language extensions
X-------------------------
X
XThe wrappers sport only a limited number of features. This is for a
Xgood reason: programs that run at high privilege levels must be easy to
Xverify. And the smaller a program, the easier to verify. There is,
Xhowever, a provision to add features.
X
XThe options.c module provides a framework for language extensions.
XQuite a few extensions have already been implemented; they are
Xdocumented in the hosts_options.5 document, which is in `nroff -man'
Xformat. Examples: changing the severity level at which a request for
Xservice is logged; "allow" and "deny" keywords; running a customized
Xserver instead of the standard one; many others.
X
XThe language extensions are not enabled by default because they
Xintroduce an incompatible change to the access control language
Xsyntax.  Instructions to enable the extensions are given in the
XMakefile.
X
X5 - Other works
X---------------
X
X5.1 - Related documents
X-----------------------
X
XThe war story behind the wrapper tools is described in:
X
X    W.Z. Venema, "TCP WRAPPER, network monitoring, access control and
X    booby traps", UNIX Security Symposium III Proceedings (Baltimore),
X    September 1992.
X
X    ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript)
X    ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text)
X
XThe same cracker is also described in:
X
X    W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is
X    Lured, Endured, and Studied", Proceedings of the Winter USENIX
X    Conference (San Francisco), January 1992.
X
X    research.att.com:/dist/internet_security/berferd.ps
X
X5.2 - Related software
X----------------------
X
XNetwork daemons etc. with enhanced logging capabilities can generate
Xmassive amounts of information: our 100+ workstations generate several
Xhundred kbytes each day. egrep-based filters can help to suppress some
Xof the noise.  A more powerful tool is the Swatch monitoring system by
XStephen E. Hansen and E. Todd Atkins. Swatch can process log files in
Xreal time and can associate arbitrary actions with patterns; its
Xapplications are by no means restricted to security.  Swatch is
Xavailable from sierra.stanford.edu, directory /pub/sources.
X
XSocks, described in the UNIX Security III proceedings, can be used to
Xcontrol network traffic from hosts on an internal network, through a
Xfirewall host, to the outer world. Socks consists of a daemon that is
Xrun on the firewall host, and of a library with routines that redirect
Xapplication socket calls through the firewall daemon.  Socks is
Xavailable from s1.gov in /pub/socks.tar.Z.
X
XTcpr is a set of perl scripts by Paul Ziemba that enable you to run ftp
Xand telnet commands across a firewall. Unlike socks it can be used with
Xunmodified client software. Available from ftp.alantec.com, pub/tcpr.
X
XVersions of rshd and rlogind, modified to report the remote user name
Xin addition to the remote host name, are available for anonymous ftp
X(ftp.win.tue.nl:/pub/security/logdaemon-3.tar.Z).  These programs are
Xdrop-in replacements for SunOS 4.x, Ultrix 4.x, and SunOS 5.x.
X
XThe securelib shared library by William LeFebvre can be used to control
Xaccess to network daemons that are not run under control of the inetd
Xor that serve more than one client, such as the NFS mount daemon that
Xruns until the machine goes down.  Available from eecs.nwu.edu, file
X/pub/securelib.tar.
X
Xxinetd (posted to comp.sources.unix) is an inetd replacement program
Xthat provides, among others, logging, username lookup and access
Xcontrol. However, it does not support TLI services, and it is only six
Xtimes as much source code as the daemon wrapper programs.
X
XWhere shared libraries or router-based packet filtering are not an
Xoption, an alternative portmap daemon can help to improve RPC security,
Xin particular that of NFS and of the NIS (YP) information service.
Xftp.win.tue.nl:/pub/security/portmap.shar.Z was tested with SunOS 4.1.1
X... 4.1.3, Ultrix 3.0 and Ultrix 4.x, HP-UX 8.x and AIX. The protection
Xis less effective than that of the securelib library because portmap is
Xmostly a dictionary service.  SunOS 4.x users should install the latest
Xrevision of the portmap and NIS daemons instead, or adopt NIS+ which
Xhas access control built in.
X
XSource for a portable RFC 931 (TAP, IDENT)-compatible daemon by Peter
XEriksson is available from ftp.lysator.liu.se:/pub/ident/servers.
X
XSome TCP/IP implementations come without syslog library. Some come with
Xthe library but have no syslog daemon. A replacement can be found in
Xftp.win.tue.nl:/pub/security/surrogate-syslog.tar.Z.  The fakesyslog
Xlibrary that comes with the nntp sources reportedly works well, too.
X
X6 - Limitations
X---------------
X
X6.1 - Known wrapper limitations
X-------------------------------
X
XSome UDP (and rpc/udp) daemons linger around for a while after they
Xhave serviced a request, just in case another request comes in.  In the
Xinetd configuration file these daemons are registered with the `wait'
Xoption. Only the request that started such a daemon will be seen by the
Xwrappers.  Such daemons are better protected with the securelib shared
Xlibrary (see: Related software).
X
XThe wrappers do not work with RPC services over TCP. These services are
Xregistered as rpc/tcp in the inetd configuration file. The only non-
Xtrivial service that is affected by this limitation is rexd, which is
Xused by the on(1) command. This is no great loss.  On most systems,
Xrexd is less secure than a wildcard in /etc/hosts.equiv.
X
XSome RPC requests (for example: rwall, rup, rusers) appear to come from
Xthe responding host. What happens is that the client sends its request
Xto all portmap daemons on its network; each portmap daemon forwards the
Xrequest to its own system. As far as the rwall etc.  daemons know, the
Xrequest comes from the local host.
X
XPortmap and RPC (e.g. NIS and NFS) (in)security is a topic in itself.
XSee the section in this document on related software.
X
X6.2 - Known system software bugs
X--------------------------------
X
XWorkarounds have been implemented for several bugs in system software.
XThey are described in the Makefile. Unfortunately, some system software
Xbugs cannot be worked around. The result is loss of functionality.
X
XOlder ConvexOS versions come with a broken recvfrom(2) implementation.
XThis makes it impossible for the daemon wrappers to look up the
Xremote host address (and hence, the name) in case of UDP requests.
XA patch is available for ConvexOS 10.1; later releases should be OK.
X
XOn some systems, the optional RFC 931 remote username lookups may
Xtrigger a kernel bug.  When a client host connects to your system, and
Xthe RFC 931 connection from your system to that client is rejected by a
Xrouter, your kernel may drop all connections with that client.  This is
Xnot a bug in the wrapper programs: complain to your vendor, and don't
Xenable remote user name lookups until the bug has been fixed.
X
XReportedly, SunOS 4.1.1, Next 2.0a, ISC 3.0 with TCP 1.3, and AIX 3.2.2
Xand later are OK.
X
XSony News/OS 4.51, HP-UX 8-something and Ultrix 4.3 still have the bug.
XReportedly, a fix for Ultrix is available ((CXO-8919).
X
XThe following procedure can be used (from outside the tue.nl domain) to
Xfind out if your kernel has the bug. From the system under test, do:
X
X    % ftp 131.155.70.100
X
XThis command attempts to make an ftp connection to our anonymous ftp
Xserver (ftp.win.tue.nl).  When the connection has been established, run
Xthe following command from the same system under test, while keeping
Xthe ftp connection open:
X
X    % telnet 131.155.70.100 111
X
XDo not forget the `111' at the end of the command. This telnet command
Xattempts to connect to our portmap process.  The telnet command should
Xfail with:  "host not reachable", or something like that. If your ftp
Xconnection gets messed up, you have the bug. If the telnet command does
Xnot fail, please let me know a.s.a.p.!
X
XFor those who care, the bug is that the BSD kernel code was not careful
Xenough with incoming ICMP UNREACHABLE control messages (it ignored the
Xlocal and remote port numbers, and therefore zapped *all* connections
Xwith the remote system). The bug is still present in the BSD NET/1
Xsource release (1989) but apparently has been fixed in BSD NET/2 (1991).
X
X7 - Configuration and installation
X----------------------------------
X
X7.1 - Easy configuration and installation
X-----------------------------------------
X
XThe "easy" recipe requires no changes to existing software or
Xconfiguration files.  Basically, you move the daemons that you want to
Xprotect to a different directory and plug the resulting holes with
Xcopies of the wrapper programs.
X
XIf you don't run Ultrix, you won't need the miscd wrapper program.  The
Xmiscd daemon implements among others the SYSTAT service, which produces
Xthe same output as the the WHO command.
X
XType `make' and follow the instructions.  The Makefile comes with
Xready-to-use templates for many common UNIX implementations (sun,
Xultrix, hp-ux, irix, ...).
X
XWhen the `make' succeeds the result is four executables (five in
Xcase of Ultrix).
X
XThe `try' program can be used to play with host access control tables
Xand is described in a later section.
X
XThe `safe_finger' command should be used when you implement booby
Xtraps:  it gives better protection against nasty stuff that hosts may
Xsend in response to finger probes.
X
XThe `try-from' program tests the host and username lookup code.  Run it
Xfrom a remote shell command (`rsh host /some/where/try-from') and it
Xshould be able to figure out from what system it is being called.
X
XThe tcpd program can be used to monitor the telnet, finger, ftp, exec,
Xrsh, rlogin, tftp, talk, comsat and other tcp or udp services that have
Xa one-to-one mapping onto executable files.
X
XThe tcpd program can also be used for services that are marked as
Xrpc/udp in the inetd configuration file, but not for rpc/tcp services
Xsuch as rexd.  You probably do not want to run rexd anyway. On most
Xsystems it is even less secure than a wildcard in /etc/hosts.equiv.
X
XWith System V.4-style systems, the tcpd program can also handle TLI
Xservices. When TCP/IP or UDP/IP is used underneath TLI, the wrappers
Xprovide the same functions as with socket-based applications. When some
Xother protocol is used underneath TLI, functionality will be limited
X(no remote username lookups, weird network address formats).
X
XDecide which services you want to monitor. Move the corresponding
Xvendor-provided daemon programs to the location specified by the
XREAL_DAEMON_DIR constant in the Makefile, and fill the holes with
Xcopies of the tcpd wrapper. That is, one copy of (or link to) the tcpd
Xprogram for each service that you want to monitor. For example, to
Xmonitor the use of your finger service:
X
X    # mkdir REAL_DAEMON_DIR
X    # mv /usr/etc/in.fingerd REAL_DAEMON_DIR
X    # cp tcpd /usr/etc/in.fingerd
X
XThe example applies to SunOS 4. With other UNIX implementations the
Xnetwork daemons live in /usr/libexec, /usr/sbin or in /etc, or have no
X"in." prefix to their names, but you get the idea.
X
XUltrix only:  If you want to monitor the SYSTAT service, move the
Xvendor-provided miscd daemon to the location specified by the
XREAL_DAEMON_DIR macro in the Makefile, and install the miscd wrapper
Xat the original miscd location.
X
XIn the absence of any access-control tables, the daemon wrappers
Xwill just maintain a record of network connections made to your system.
X
X7.2 - Advanced configuration and installation
X---------------------------------------------
X
XThe advanced recipe leaves your daemon executables alone, but involves
Xsimple modifications to the inetd configuration file.
X
XType `make' and follow the instructions.  The Makefile comes with
Xready-to-use templates for many common UNIX implementations (sun,
Xultrix, hp-ux, irix, ...).
X
XWhen the `make' succeeds the result is four executables (five in
Xcase of Ultrix).
X
XThe `try' program can be used to play with host access control tables
Xand is described in a later section.
X
XThe `try-from' program tests the host and username lookup code.  Run it
Xfrom a remote shell command (`rsh host /some/where/try-from') and it
Xshould be able to figure out from what system it is being called.
X
XThe `safe_finger' command should be used when you implement a booby
Xtrap:  it gives better protection against nasty stuff that hosts may
Xsend in response to finger probes.
X
XThe tcpd program can be used to monitor the telnet, finger, ftp, exec,
Xrsh, rlogin, tftp, talk, comsat and other tcp or udp services that have
Xa one-to-one mapping onto executable files.
X
XWith System V.4-style systems, the tcpd program can also handle TLI
Xservices. When TCP/IP or UDP/IP is used underneath TLI, the wrappers
Xprovide the same functions as with socket-based applications. When some
Xother protocol is used underneath TLI, functionality will be limited
X(no remote username lookups, weird network address formats).
X
XThe tcpd program can also be used for services that are marked as
Xrpc/udp in the inetd configuration file, but not for rpc/tcp services
Xsuch as rexd.  You probably do not want to run rexd anyway. On most
Xsystems it is even less secure than a wildcard in /etc/hosts.equiv.
X
XInstall the tcpd command in a suitable place. Apollo UNIX users will
Xwant to install it under a different name because the name "tcpd" is
Xalready taken; a suitable name for the wrapper program would be
X"frontd".  Then perform the following edits on the inetd configuration
Xfile (usually /etc/inetd.conf or /etc/inet/inetd.conf):
X
X    finger  stream  tcp     nowait  nobody  /usr/etc/in.fingerd     in.fingerd
X                                            ^^^^^^^^^^^^^^^^^^^
Xbecomes:
X
X    finger  stream  tcp     nowait  nobody  /usr/etc/tcpd in.fingerd
X                        ^^^^^^^^^^^^^
XSend a `kill -HUP' to the inetd process to make the change effective.
XSome inetd implementations require that you first disable the finger
Xservice (comment out the finger service and `kill -HUP' the inetd)
Xbefore you can turn on the modified version.
X
XThe example applies to SunOS 4. With other UNIX implementations the
Xnetwork daemons live in /usr/libexec, /usr/sbin, or /etc, the network
Xdaemons have no "in." prefix to their names, or the username field in
Xthe inetd configuration file may be missing.
X
XWhen the finger service works as expected you can perform similar
Xchanges for other network services. Do not forget the `kill -HUP'.
X
XThe miscd daemon that comes with Ultrix implements several network
Xservices. It decides what to do by looking at its process name. One of
Xthe services is systat, which is a kind of limited finger service.  If
Xyou want to monitor the systat service, install the miscd wrapper in a
Xsuitable place and update the inetd configuration file:
X
X    systat  stream  tcp     nowait  /suitable/place/miscd      systatd
X
XUltrix 4.3 allows you to specify a user id under which the daemon will
Xbe executed. This feature is not documented in the manual pages.  Thus,
Xthe example would become:
X
X    systat  stream  tcp     nowait  nobody /suitable/place/miscd    systatd
X
XOlder Ultrix systems still run all their network daemons as root.
X
XIn the absence of any access-control tables, the daemon wrappers
Xwill just maintain a record of network connections made to your system.
X
X7.3 - Daemons with arbitrary path names
X---------------------------------------
X
XThe above tcpd examples work fine with network daemons that live in a
Xcommon directory, but sometimes that is not practical. Having soft
Xlinks all over your file system is not a clean solution, either.
X
XInstead you can specify, in the inetd configuration file, an absolute
Xpath name for the daemon process name.  For example,
X
X    ntalk   dgram   udp     wait    root    /usr/etc/tcpd /usr/local/lib/ntalkd
X
XWhen the daemon process name is an absolute path name, tcpd ignores the
Xvalue of the REAL_DAEMON_DIR constant, and uses the last path component
Xof the daemon process name for logging and for access control.
X
X7.4 - Building and testing the access control rules
X---------------------------------------------------
X
XIn order to support access control the wrappers must be compiled with
Xthe -DHOSTS_ACCESS option. The access control policy is given in the
Xform of two tables (default: /etc/hosts.allow and /etc/hosts.deny).
XAccess control is disabled when there are no access control tables, or
Xwhen the tables are empty.
X
XIf you haven't used the wrappers before I recommend that you first run
Xthem a couple of days without any access control restrictions. The
Xlogfile records should give you an idea of the process names and of the
Xhost names that you will have to build into your access control rules.
X
XThe syntax of the access control rules is documented in the file
Xhosts_access.5, which is in `nroff -man' format. This is a lengthy
Xdocument, and no-one expects you to read it right away from beginning
Xto end.  Instead, after reading the introductory section, skip to the
Xexamples at the end so that you get a general idea of the language.
XThen you can appreciate the detailed reference sections near the
Xbeginning of the document.
X
XThe examples in the hosts_access.5 document (`nroff -man' format) show
Xtwo specific types of access control policy:  1) mostly closed (only
Xpermitting access from a limited number of systems) and 2) mostly open
X(permitting access from everyone except a limited number of trouble
Xmakers). You will have to choose what model suits your situation best.
XImplementing a mixed policy should not be overly difficult either.
X
XOptional extensions to the access control language are described in the
Xhosts_options.5 document (`nroff -man' format).
X
XThe `try' command can be used to try out your local access control
Xfiles.  The command syntax is:
X
X    ./try process_name hostname    (e.g.: ./try in.tftpd localhost)
X
X    ./try process_name address    (e.g.: ./try in.tftpd 127.0.0.1)
X
XThis way you can simulate what decisions will be made, and what actions
Xwill be taken, when hosts connect to your own system.
X
XNote 1: `try -d' will look for hosts.{allow,deny} tables in the
Xcurrent working directory. This is useful for testing new rules
Xwithout bothering your users.
X
XNote 2: you cannot use the `try' command to simulate what happens when
Xthe local system connects to other hosts.
X
XIn order to find out what process name to use, just use the service and
Xwatch the process name that shows up in the logfile.  Alternatively,
Xyou can look up the name from the inetd configuration file. Coming back
Xto the tftp example in the tutorial section above:
X
X    tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd -s /tftpboot
X
XThis entry causes the inetd to run the wrapper program (tcpd) with a
Xprocess name `in.tftpd'.  This is the name that the wrapper will use
Xwhen scanning the access control tables. Therefore, `in.tftpd' is the
Xprocess name that should be given to the `try' command. On your system
Xthe actual inetd.conf entry may differ (tftpd instead of in.tftpd, and
Xno `root' field), but you get the idea.
X
XWhen you specify a host name, the `try' program will use both the host
Xname and address. This way you can simulate the most common case where
Xthe wrappers know both the host address and the host name.  The `try'
Xprogram will iterate over all addresses that it can find for the given
Xhost name.
X
XWhen you specify a host address instead of a host name, the `try'
Xprogram will pretend that the host name is unknown, so that you can
Xsimulate what happens when the wrapper is unable to look up the remote
Xhost name.
X
XThe `try' command will report serious errors to the standard error
Xstream (no need to tail the syslog file anymore).
X
X7.5 - Other applications
X------------------------
X
XThe access control routines can easily be integrated with other
Xprograms.  The hosts_access.3 manual page (`nroff -man' format)
Xdescribes the external interface of the libwrap.a library.
X
XThe tcpd wrapper can even be used to control access to the smtp port.
XIn that case, sendmail should not be run as a stand-alone daemon, but
Xit should be registered in the inetd configuration file. For example:
X
X    smtp    stream  tcp     nowait  root    /usr/etc/tcpd /usr/lib/sendmail -bs
X
XYou will periodically want to run sendmail to process queued-up
Xmessages. A crontab entry like:
X
X    0,15,30,45 * * * * /usr/lib/sendmail -q
X
Xshould take care of that. When you are going to "protect" your sendmail
Xdaemon this way, you should realize that there are many "unprotected"
Xsendmail daemons all over the network that can still be abused.
X
X8 - Acknowledgements
X--------------------
X
XMany people contributed to the evolution of the programs, by asking
Xinspiring questions, by suggesting features or bugfixes, or by
Xsubmitting source code.  Nevertheless, all mistakes and bugs in the
Xwrappers are my own.
X
XThanks to Brendan Kehoe ([e-mail]), Heimir Sverrisson
X([e-mail]) and Dan Bernstein ([e-mail]) for
Xfeedback on an early release of this product.  The host name/address
Xcheck was suggested by John Kimball ([e-mail]).
XApollo's UNIX environment has some peculiar quirks: Willem-Jan Withagen
X([e-mail]), Pieter Schoenmakers ([e-mail]) and
XCharles S. Fuller ([e-mail]) provided assistance.  Hal R.
XBrand ([e-mail]) told me how to get the remote IP address
Xin case of datagram-oriented services, and suggested the optional shell
Xcommand feature.  Shabbir Safdar ([e-mail]) provided
Xa first version of a much-needed manual page.  Granville Boman Goza, IV
X([e-mail]) suggested to use the remote IP address even when the
Xhost name is available.  Casper H.S. Dik ([e-mail]) provided
Xadditional insight into DNS spoofing techniques.  The bogus daemon
Xfeature was inspired by code from Andrew Macpherson (BNR Europe Ltd).
XSteve Bellovin ([e-mail]) confirmed some of my suspicions
Xabout the darker sides of TCP/IP insecurity. Risks of automated fingers
Xwere pointed out by Borja Marcos ([e-mail]). Brad Plecs
X([e-mail]) was kind enough to try my early TLI code and
Xto work out how DG/UX differs from Solaris.
X
XJohn P.  Rouillard ([e-mail]) deserves special mention for his
Xpersistent, but constructive, nagging about wrong or missing things,
Xand for trying out and discussing embryonic code or ideas.
X
XLat but not least, Howard Chu ([e-mail]), Darren Reed
X([e-mail]), Icarus Sparry ([e-mail]),
XScott Schwartz (schwartz@ cs.psu.edu), John A. Kunze
X([e-mail]), Daniel Len Schales ([e-mail]),
XChris Turbeville <[e-mail]>, Paul Kranenburg
X<[e-mail]>, Marc Boucher <[e-mail]>, Dave Mitchell
X<[e-mail]>, and many, many others provided fixes, code
Xfragments, or other improvements to the wrappers.
X
X    Wietse Venema ([e-mail])
X    Department of Mathematics and Computing Science
X    Eindhoven University of Technology
X    P.O. Box 513
X    5600 MB Eindhoven
X    The Netherlands
END_OF_README
if test 37825 -ne `wc -c <README`; then
    echo shar: \"README\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f BLURB -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"BLURB\"
else
echo shar: Extracting \"BLURB\" \(1735 characters\)
sed "s/^X//" >BLURB <<'END_OF_BLURB'
X@(#) BLURB 1.14 93/09/28 23:03:27
X
XThis is the 6.0 version of the TCP/IP daemon wrapper package.
X
XWith these programs you can monitor and control who connects to your
XTFTP, EXEC, FTP, RSH, TELNET, RLOGIN, FINGER, and SYSTAT network
Xservices, and many others.
X
XThe programs can be installed without any changes to existing software
Xor configuration files. By default, they just log the remote host name
Xand do some sanity checks on the origin of the request. No information
Xis exchanged with the remote client process.
X
XSignificant differences with respect to the previous release:
X
X    - Easier to install: ready-to-use build procedures for many common
X    UNIX implementations (sun, ultrix, hp-ux, irix, aix, ...).
X
X    - Support for the System V.4 TLI network programming interface
X    (Solaris, DG/UX etc.).  In case of TLI applications on top of
X    TCP/IP, the wrappers provide the same functionality as with
X    socket-based applications.
X
X    - A more secure finger tool for automatic reverse finger probes.
X
X    - New extension language keywords:  "severity", to adjust the log
X    noise level; "allow" and "deny", to keep all access-control rules
X    within a single file.
X
X    - More support for selective remote username lookups.
X
X    - More workarounds for System V bugs: IRIX username lookups, and
X    SCO problems with UDP.
X
XThe default mode of operation (no TLI support) should be backwards
Xcompatible with earlier versions. The library interface has changed,
Xthough, and programs that depend on the libwrap.a library will have to
Xbe recompiled before they can be relinked.
X
X    Wietse Venema ([e-mail]),
X    Department of Mathematics and Computing Science,
X    Eindhoven University of Technology,
X    The Netherlands.
END_OF_BLURB
if test 1735 -ne `wc -c <BLURB`; then
    echo shar: \"BLURB\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f CHANGES -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"CHANGES\"
else
echo shar: Extracting \"CHANGES\" \(2334 characters\)
sed "s/^X//" >CHANGES <<'END_OF_CHANGES'
XChanges per release 6.0.
X========================
X
X- Easy build procedures for common platforms (sun, ultrix, aix, hpux
Xand others).
X
X- TLI support, System V.4 style (Solaris, DG/UX).
X
X- Username lookup integrated with the access control language.
XSelective username lookups are now the default (was: no username
Xlookups).
X
X- A safer finger command for booby traps. This one solves a host of
Xpossible problems with automatic reverse fingers. Thanks, Borja Marcos
X([e-mail]) for some inspiring discussions.
X
X- KNOWN pattern that matches hosts whose name and address are known.
X
X- Cleanup of diagnostics. Errors in access-control files are now shown
Xwith file name and line number.
X
X- With AIX 3.2, hostnames longer than 32 would be truncated.  This
Xcaused hostname verification failures, so that service would be refused
Xwhen paranoid mode was enabled.  Found by:  Adrian van Bloois
X([e-mail]).
X
X- With some IRIX versions, remote username lookups failed because the
Xfgets() library function does not handle partial read()s from sockets.
XFound by:  Daniel O'Callaghan ([e-mail]).
X
X- Added a DISCLAIMER document to help you satisfy legal departments.
X
XThe extension language module has undergone major revisions and
Xextensions.  Thanks, John P. Rouillard ([e-mail]) for
Xdiscussions, experiments, and for being a good guinea pig. The
Xextensions are documented in hosts_options.5, and are enabled by
Xediting the Makefile STYLE macro definition.
X
X- (Extension language) The ":" separator may now occur within options
Xas long as it is protected with a backslash. A warning is issued when
Xa rule ends on ":".
X
X- (Extension language) Better verification mode. When the `try' command
Xis run, each option function now explains what it would do.
X
X- (Extension language) New "allow" and "deny" keywords so you can now
Xhave all rules within a single file. See "nroff -man hosts_options.5"
Xfor examples.
X
X- (Extension language) "linger" keyword to set the socket linger time
X(SO_LINGER). From:  Marc Boucher <[e-mail]>.
X
X- (Extension language) "severity" keyword to turn the logging noise up
Xor down. Many sites wanted a means to shut up the program; other sites
Xwanted to to emphasize specific events.  Adapted from code contributed
Xby Dave Mitchell <[e-mail]>.
END_OF_CHANGES
if test 2334 -ne `wc -c <CHANGES`; then
    echo shar: \"CHANGES\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f DISCLAIMER -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"DISCLAIMER\"
else
echo shar: Extracting \"DISCLAIMER\" \(973 characters\)
sed "s/^X//" >DISCLAIMER <<'END_OF_DISCLAIMER'
X/************************************************************************
X* Copyright 1993 by Wietse Venema.  All rights reserved.  Some individual
X* files may be covered by other copyrights.
X*
X* This material was originally written and compiled by Wietse Venema at
X* Eindhoven University of Technology, The Netherlands, in 1990, 1991,
X* 1992 and 1993.
X*
X* Redistribution and use in source and binary forms are permitted
X* provided that this entire copyright notice is duplicated in all such
X* copies.  No charge, other than an "at-cost" distribution fee, may be
X* charged for copies, derivations, or distributions of this material
X* without the express written consent of the copyright holder.
X*
X* This software is provided "as is" and without any expressed or implied
X* warranties, including, without limitation, the implied warranties of
X* merchantibility and fitness for any particular purpose.
X************************************************************************/
END_OF_DISCLAIMER
if test 973 -ne `wc -c <DISCLAIMER`; then
    echo shar: \"DISCLAIMER\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f clean_exit.c -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"clean_exit.c\"
else
echo shar: Extracting \"clean_exit.c\" \(1075 characters\)
sed "s/^X//" >clean_exit.c <<'END_OF_clean_exit.c'
X /*
X  * clean_exit() cleans up and terminates the program. It should be called
X  * instead of exit when for some reason the real network daemon will not or
X  * cannot be run. Reason: in the case of a datagram-oriented service we must
X  * discard the not-yet received data from the client. Otherwise, inetd will
X  * see the same datagram again and again, and go into a loop.
X  *
X  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
X  */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#) clean_exit.c 1.3 93/09/11 20:45:43";
X#endif
X
X#include <stdio.h>
X
Xextern void exit();
X
X#include "log_tcp.h"
X
X/* clean_exit - clean up and exit */
X
Xvoid    clean_exit(client)
Xstruct client_info *client;
X{
X
X    /*
X     * In case of unconnected protocols we must eat up the not-yet received
X     * data or inetd will loop.
X     */
X
X    if (client->sink)
X    client->sink(client->fd);
X
X    /*
X     * Be kind to the inetd. We already reported the problem via the syslogd,
X     * and there is no need for additional garbage in the logfile.
X     */
X
X    sleep(1);
X    exit(0);
X}
END_OF_clean_exit.c
if test 1075 -ne `wc -c <clean_exit.c`; then
    echo shar: \"clean_exit.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f fakelog.c -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"fakelog.c\"
else
echo shar: Extracting \"fakelog.c\" \(2288 characters\)
sed "s/^X//" >fakelog.c <<'END_OF_fakelog.c'
X /*
X  * This module intercepts syslog() library calls and redirects their output
X  * to the standard error stream. For interactive testing. Not for critical
X  * applications, because it will happily write beyond the end of buffers.
X  *
X  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
X  */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#) fakelog.c 1.2 93/09/25 12:56:20";
X#endif
X
X#include <stdio.h>
X
X /*
X  * What follows is an attempt to unify varargs.h and stdarg.h. I'd rather
X  * have this than #ifdefs all over the code.
X  */
X
X#ifdef __STDC__
X#include <stdarg.h>
X#define VARARGS(func,type,arg) func(type arg, ...)
X#define VASTART(ap,type,name)  va_start(ap,name)
X#define VAEND(ap)              va_end(ap)
X#else
X#include <varargs.h>
X#define VARARGS(func,type,arg) func(va_alist) va_dcl
X#define VASTART(ap,type,name)  {type name; va_start(ap); name = va_arg(ap, type)
X#define VAEND(ap)              va_end(ap);}
X#endif
X
Xextern int errno;
Xextern char *sys_errlist[];
Xextern int sys_nerr;
Xextern char *strcpy();
X
X/* percentm - replace %m by error message associated with value in err */
X
Xchar   *percentm(buf, str, err)
Xchar   *buf;
Xchar   *str;
Xint     err;
X{
X    char   *ip = str;
X    char   *op = buf;
X
X    while (*ip) {
X    switch (*ip) {
X    case '%':
X        switch (ip[1]) {
X        case '\0':                /* don't fall off end */
X        *op++ = *ip++;
X        break;
X        case 'm':                /* replace %m */
X        if (err < sys_nerr && err > 0)
X            strcpy(op, sys_errlist[err]);
X        else
X            sprintf(op, "Unknown error %d", err);
X        op += strlen(op);
X        ip += 2;
X        break;
X        default:                /* leave %<any> alone */
X        *op++ = *ip++, *op++ = *ip++;
X        break;
X        }
X    default:
X        *op++ = *ip++;
X    }
X    }
X    *op = 0;
X    return (buf);
X}
X
X/* openlog - dummy */
X
X/* ARGSUSED */
X
Xopenlog(name, logopt, facility)
Xchar   *name;
Xint     logopt;
Xint     facility;
X{
X    /* void */
X}
X
X/* syslog - append record to system log -- not */
X
X/* VARARGS */
X
XVARARGS(syslog, int, severity)
X{
X    va_list ap;
X    char   *fmt;
X    int     err = errno;
X    char    buf[BUFSIZ];
X
X    VASTART(ap, int, severity);
X    fmt = va_arg(ap, char *);
X    fprintf(stderr, " ");
X    vfprintf(stderr, percentm(buf, fmt, err), ap);
X    fprintf(stderr, "\n");
X    VAEND(ap);
X}
X
X/* closelog - dummy */
X
Xcloselog()
X{
X    /* void */
X}
END_OF_fakelog.c
if test 2288 -ne `wc -c <fakelog.c`; then
    echo shar: \"fakelog.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f fix_options.c -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"fix_options.c\"
else
echo shar: Extracting \"fix_options.c\" \(1348 characters\)
sed "s/^X//" >fix_options.c <<'END_OF_fix_options.c'
X /*
X  * Routine to disable IP-level socket options. This code was taken from 4.4BSD
X  * rlogind source, but all mistakes in it are my fault.
X  *
X  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
X  */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#) fix_options.c 1.2 93/09/11 20:45:45";
X#endif
X
X#include <sys/types.h>
X#include <sys/param.h>
X#include <netinet/in.h>
X#include <netdb.h>
X#include <stdio.h>
X#include <syslog.h>
X
X#include "log_tcp.h"
X
X/* fix_options - get rid of IP-level socket options */
X
Xfix_options(client)
Xstruct client_info *client;
X{
X#ifdef IP_OPTIONS
X    unsigned char optbuf[BUFSIZ / 3], *cp;
X    char    lbuf[BUFSIZ], *lp;
X    int     optsize = sizeof(optbuf), ipproto;
X    struct protoent *ip;
X    int     fd = client->fd;
X
X    if ((ip = getprotobyname("ip")) != 0)
X    ipproto = ip->p_proto;
X    else
X    ipproto = IPPROTO_IP;
X
X    if (getsockopt(fd, ipproto, IP_OPTIONS, (char *) optbuf, &optsize) == 0
X    && optsize != 0) {
X    lp = lbuf;
X    for (cp = optbuf; optsize > 0; cp++, optsize--, lp += 3)
X        sprintf(lp, " %2.2x", *cp);
X    syslog(LOG_NOTICE,
X           "connect from %s with IP options (ignored):%s",
X           hosts_info(client), lbuf);
X    if (setsockopt(fd, ipproto, IP_OPTIONS, (char *) 0, optsize) != 0) {
X        syslog(LOG_ERR, "setsockopt IP_OPTIONS NULL: %m");
X        clean_exit(client);
X    }
X    }
X#endif
X}
END_OF_fix_options.c
if test 1348 -ne `wc -c <fix_options.c`; then
    echo shar: \"fix_options.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f fromhost.c -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"fromhost.c\"
else
echo shar: Extracting \"fromhost.c\" \(2196 characters\)
sed "s/^X//" >fromhost.c <<'END_OF_fromhost.c'
X /*
X  * On socket-only systems, fromhost() is nothing but an alias for the
X  * socket-specific sock_host() function.
X  *
X  * On systems with sockets and TLI, fromhost() determines the type of API
X  * (sockets, TLI), then invokes the appropriate API-specific routines.
X  *
X  * The API-specific routines determine the nature of the service (datagram,
X  * stream), and the name and address of the host at the other end. In case
X  * of an IP service, these routines also determine the local address and
X  * port, and the remote username if username lookups are done irrespective
X  * of client. All results are in static memory.
X  *
X  * The return value is (-1) if the remote host pretends to have someone elses
X  * name, or if the remote host name is available but could not be verified;
X  * in either case the hostname will be ignored. The return status is zero in
X  * all other cases (the hostname is unavailable, or the host name double
X  * check succeeds).
X  *
X  * Diagnostics are reported through syslog(3).
X  *
X  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
X  */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#) fromhost.c 1.13 93/09/24 19:16:08";
X#endif
X
X/* System libraries. */
X
X#include <sys/types.h>
X#include <stdio.h>
X#include <syslog.h>
X
X#ifdef TLI
X#include <sys/tiuser.h>
X#include <stropts.h>
X#endif
X
X/* Local stuff. */
X
X#include "log_tcp.h"
X
X#ifdef TLI
X
X/* fromhost - find out what network API we should use */
X
Xint     fromhost(client)
Xstruct client_info *client;
X{
X
X    /*
X     * On systems with streams support the IP network protocol family may
X     * have more than one programming interface (sockets and TLI).
X     *
X     * Thus, we must first find out what programming interface to use: sockets
X     * or TLI. On some systems, sockets are not part of the streams system,
X     * so if stdin is not a stream we assume sockets.
X     */
X
X    if (!isastream(client->fd))
X    return (sock_host(client));
X    if (ioctl(0, I_FIND, "timod") > 0)
X    return (tli_host(client));
X    if (ioctl(0, I_FIND, "sockmod") > 0)
X    return (sock_host(client));
X    syslog(LOG_ERR, "wrapper: cannot establish type of transport interface");
X    return (0);
X}
X
X#endif /* TLI */
END_OF_fromhost.c
if test 2196 -ne `wc -c <fromhost.c`; then
    echo shar: \"fromhost.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f hosts_ctl.c -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"hosts_ctl.c\"
else
echo shar: Extracting \"hosts_ctl.c\" \(1065 characters\)
sed "s/^X//" >hosts_ctl.c <<'END_OF_hosts_ctl.c'
X /*
X  * hosts_ctl() combines the most common applications of the host access
X  * control library. routine. It bundles its arguments into a client_info
X  * structure, then calls the hosts_access() access control checker. The host
X  * name and user name arguments should be empty strings, "unknown" or real
X  * data. If a match is found, the optional shell command is executed.
X  *
X  * Restriction: this interface does not pass enough information to support
X  * selective remote username lookups.
X  *
X  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
X  */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#) hosts_ctl.c 1.3 93/09/24 19:48:26";
X#endif
X
X#include <stdio.h>
X
X#include "log_tcp.h"
X
X/* hosts_ctl - general interface for the hosts_access() routine */
X
Xint     hosts_ctl(daemon, name, addr, user)
Xchar   *daemon;
Xchar   *name;
Xchar   *addr;
Xchar   *user;
X{
X    struct client_info client;
X
X    init_client (&client);
X    client.name = name;
X    client.addr = addr;
X    client.user = user;
X
X    return (hosts_access(daemon, &client));
X}
END_OF_hosts_ctl.c
if test 1065 -ne `wc -c <hosts_ctl.c`; then
    echo shar: \"hosts_ctl.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
if test -f hosts_info.c -a "${1}" != "-c" ; then
  echo shar: Will not over-write existing file \"hosts_info.c\"
else
echo shar: Extracting \"hosts_info.c\" \(790 characters\)
sed "s/^X//" >hosts_info.c <<'END_OF_hosts_info.c'
X /*
X  * hosts_info() returns a string with as much information about the origin
X  * of a connection as we have: the user name, if known, and the host name,
X  * or the host address if the name is not available.
X  *
X  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
X  */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#) hosts_info.c 1.2 93/09/11 20:45:32";
X#endif
X
X#include <stdio.h>
X
X#include "log_tcp.h"
X
X/* hosts_info - return string with as much about the client as we know */
X
Xchar   *hosts_info(client)
Xstruct client_info *client;
X{
X    static char buf[BUFSIZ];        /* XXX */
X
X    if (client->user[0] && strcmp(client->user, FROM_UNKNOWN)) {
X    sprintf(buf, "%s@%s", client->user, FROM_HOST(client));
X    return (buf);
X    } else {
X    return (FROM_HOST(client));
X    }
X}
END_OF_hosts_info.c
if test 790 -ne `wc -c <hosts_info.c`; then
    echo shar: \"hosts_info.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of archive 1 \(of 4\).
cp /dev/null ark1isdone
MISSING=""
for I in 1 2 3 4 ; do
    if test ! -f ark${I}isdone ; then
    MISSING="${MISSING} ${I}"
    fi
done
if test "${MISSING}" = "" ; then
    echo You have unpacked all 4 archives.
    rm -f ark[1-9]isdone
else
    echo You still need to unpack the following archives:
    echo "        " ${MISSING}
fi
##  End of shell archive.
exit 0

exit 0 # Just in case...