@(#) README 1.4 91/05/20 13:30:17

General description:
--------------------

With this package you can monitor connections to the SYSTAT, FINGER,
FTP, TELNET, RLOGIN, RSH and EXEC network services.  Connections are
logged through the syslog(3) facility. A requirement is that daemons
are started by the inetd program or something similar.

The programs are tiny front ends that just report the remote host name
and then invoke the real network daemon.  In the most common case, no
changes should be required to existing software or to configuration
files.  Just move the vendor-provided daemons to another place and
install the front ends into their original places. Installation details
are given below.

Early versions of the programs were tested with Ultrix >= 2.2, with
SunOS >= 3.4 and ISC 2.2. The first official release has been installed
on a wide variety of systems (BSD, SYSV, Apollo) without modification.
The present release should still run on top of most BSD-style TCP/IP
implementations.

Optional feature:
-----------------

When compiled with -DHOSTS_ACCESS, the front-end programs support a
simple form of access control that is based on host (or domain) names,
internet addresses or network numbers, network daemon process names and
(optionally) netgroups (a NIS, formerly YP, feature).  Wild cards are
supported.  If a host requests connection to a network daemon, and if
the (daemon, host) pair is matched by an entry in the /etc/hosts.allow
file, access is granted.  Otherwise, if the (daemon, host) pair is
matched by an entry in the /etc/hosts.deny file, access is denied.
Otherwise, access is granted.  More details are provided in the
hosts_access(5) manual page.  This form of access control may be useful
if it can not be implemented at a more suitable level (such as an
internet router).

Major enhancement:
------------------

It has been brought to my attention that authentication based on host
address to host name mapping can easily be spoofed by playing games
with some domain name server.  A little research led me to the conclusion
that many existing rshd and rlogind implementations do not account for
this potential problem.

The present versions of the front-end programs provide a way to take
care of the problem.  After mapping a client host address to a host
name, the front-end programs now verify that the host name maps to the
same host address.  The idea is that it is much easier to compromise
the address->name map of some random name server than to compromise the
name->address map that is specific to your domain.  If the source is
compiled with -DPARANOID, the front ends justs drop the connection in
case of a host name/address mismatch. Otherwise, the front ends just
ignore the bad host name and use the host address when consulting the
access control files.

Minor enhancements: 
-------------------

The host access control files now support more types of wild cards and
(optionally) allow the use of netgroup names.  Netgroup support is
usually available on systems with NIS (formerly YP) software.

Related software:
-----------------

Versions of rshd and rlogind, hacked to report the remote user name as
well, are available for anon ftp (ftp.win.tue.nl:/pub/logdaemon.tar.Z).  
That archive also contains a tftpd source that logs the remote host
name (nice if you want to know who is interested in your /etc/passwd
file).  All those programs have been tested only with SunOS >= 4.0.

Another way to manage access to tcp/ip services is illustrated by the
servers provided with the authutil package (comp.sources.unix volume
22). This has the advantage that one will get the remote username from
any host supporting RFC 931 security.  By installing the auth package
(same volume) one supports RFC 931 security too (but you will have to
believe what the remote host tells you).  Eventually one can start
cutting off unauthenticated connections. This is obviously a much more
advanced approach than what my front-end programs provide. The present
package is more suitable for those who lack the resources to install
anything that requires more than just renaming a couple of executables.

Configuration and installation (the easy way):
----------------------------------------------

An advanced installation recipe is given lateron. The "easy way" recipe
requires no changes to existing software or configuration files.

If you don't run Ultrix, you don't need the miscd front-end program.
The Ultrix miscd daemon implements among others the SYSTAT service,
which pipes the output from the WHO command to standard output.

By default, the front-end programs assume that the vendor-provided
daemons will be moved to the "/usr/etc/..." directory.  If you want
something else, adjust the REAL_DAEMON and the REAL_DAEMON_DIR macros
in the files miscd.c and tcpd.c.

By default, connections are logged to the same place where the sendmail
log entries go.  If connections should be logged elsewhere, adjust the
LOG_MAIL macro in the miscd.c and tcpd.c files, and update your syslog
configuration file (usually, /etc/syslog.conf).  Most Ultrix versions 
do not provide this flexibility, though.

By default, the front-end programs support host access control.  Access
control is turned off when the /etc/hosts.{allow,deny} files do not
exist. If you do not need support for host access control, adjust the
makefile so that the programs are compiled without -DHOSTS_ACCESS.
Note:  the host access control facility requires the strchr(), strspn()
and strtok() routines.

If your C library does not provide the strcasecmp() routine, adjust the
AUX_OBJ macro in the Makefile so that it uses the strcasecmp() version
provided with this package.

In the Makefile, add -Dmemcmp=bcmp to the CFLAGS macro if your system
does not have memcmp(), and add -DNETGROUP to the CFLAGS macro if your
system supports netgroups.

Compile with -DPARANOID if you want to drop connections when a remote
host name does not agree with the remote host address. This helps 
against attacks through compromised domain name servers, but may
occasionally cause a perfectly legal connection to be refused due to
transient name server lookup problems.

The tcpd program is intended for monitoring connections to the telnet,
finger, ftp, exec, rsh and rlogin services. Decide which services you
want to be monitored. Move the vendor-provided daemon programs to the
location specified by the REAL_DAEMON_DIR macro in the file tcpd.c, and
copy the tcpd front end to the locations where the vendor-provided
daemons used to be. That is, one copy of the tcpd front end for each
service that you want to monitor.

Ultrix only: if you want to monitor connections to the SYSTAT service,
move the vendor-provided miscd daemon to the location specified by the
REAL_DAEMON macro in the miscd.c file, and install the miscd front end
into the original miscd location.

Configuration and installation (the advanced way):
--------------------------------------------------

Instead of moving the vendor-provided daemons to another directory,
define the REAL_DAEMON_DIR to reflect the present location of those
daemons, and install the tcpd command in the same directory. Then do
the following edits to the inetd configuration file (usually in
/etc/inetd.conf):

    telnet  stream  tcp     nowait  root    /usr/etc/in.telnetd     in.telnetd

becomes:

    telnet  stream  tcp     nowait  root    /usr/etc/tcpd           in.telnetd

(the example applies to SunOS 4.x; other UNIX implementations should
not differ much). Similar changes will be needed for the other services
that are to be covered by the tcpd front-end program.

Apollo UNIX users will want to install the front end under a different
name because tcpd is the name of an already existing command. A suitable 
name for the front-end program would be "frontd".

The same trick can be played with the Ultrix miscd daemon but then the
daemon front end will have to be installed under a different name.

Acknowledgements:
-----------------

Thanks to Brendan Kehoe (brendan@cs.widener.edu), Heimir Sverrisson
(heimir@hafro.is) and Dan Bernstein (brnstnd@kramden.acf.nyu.edu) for
feedback on an earlier release of this product.  Thanks to John Kimball
(jkimball@src.honeywell.com) for suggesting the host name to host
address mapping check. Willem-Jan Withagen (wjw@eb.ele.tue.nl) provided
useful information on how to deal with the Apollo UNIX environment.

	Wietse Venema (wietse@wzv.win.tue.nl),
	Mathematics and Computing Science,
	Eindhoven University of Technology,
	The Netherlands.
