From 73f17518d5cc915e53cabad35f2b7faf8132df6e Mon Sep 17 00:00:00 2001 From: Jason Downs Date: Wed, 26 Feb 1997 06:00:36 +0000 Subject: Initial integration of userland tcpd. --- libexec/tcpd/BLURB | 39 ++ libexec/tcpd/CHANGES | 440 +++++++++++++++++++ libexec/tcpd/DISCLAIMER | 18 + libexec/tcpd/Makefile | 5 + libexec/tcpd/Makefile.inc | 9 + libexec/tcpd/README | 1036 +++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 1547 insertions(+) create mode 100644 libexec/tcpd/BLURB create mode 100644 libexec/tcpd/CHANGES create mode 100644 libexec/tcpd/DISCLAIMER create mode 100644 libexec/tcpd/Makefile create mode 100644 libexec/tcpd/Makefile.inc create mode 100644 libexec/tcpd/README (limited to 'libexec') diff --git a/libexec/tcpd/BLURB b/libexec/tcpd/BLURB new file mode 100644 index 00000000000..cc95cf74285 --- /dev/null +++ b/libexec/tcpd/BLURB @@ -0,0 +1,39 @@ +$OpenBSD: BLURB,v 1.1 1997/02/26 06:00:30 downsj Exp $ +@(#) BLURB 1.27 97/02/12 02:13:17 + +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. + +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. + +This patch upgrades the tcp wrappers version 7.4 source code to version +7.5. Highlights of this release: + + - Support for more UNIX system types. + + - Improved protection against IP spoofing attacks with source-routed + TCP connections, by refusing them. This protection is not enabled by + default. + +This release does not introduce new features. Do not bother applying +this patch when you built your current tcp wrapper without enabling the +KILL_OPTIONS compiler switch. The patch is not useful for obsolete UNIX +versions that pre-date 4.4BSD, such as SunOS 4. Such systems are unable +to receive source-routed connections and are therefore not vulnerable +to IP spoofing attacks with source-routed TCP connections. + +A complete change log is given in the CHANGES document. As always, +problem reports and suggestions for improvement are welcome. + + Wietse Venema (wietse@wzv.win.tue.nl), + Department of Mathematics and Computing Science, + Eindhoven University of Technology, + The Netherlands. + + Currently visiting IBM T.J. Watson Research, Hawthorne NY, USA. diff --git a/libexec/tcpd/CHANGES b/libexec/tcpd/CHANGES new file mode 100644 index 00000000000..7b4c3c72368 --- /dev/null +++ b/libexec/tcpd/CHANGES @@ -0,0 +1,440 @@ +$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 . + +- 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 . + +- (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 . + +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) diff --git a/libexec/tcpd/DISCLAIMER b/libexec/tcpd/DISCLAIMER new file mode 100644 index 00000000000..9dc90839983 --- /dev/null +++ b/libexec/tcpd/DISCLAIMER @@ -0,0 +1,18 @@ +$OpenBSD: DISCLAIMER,v 1.1 1997/02/26 06:00:32 downsj Exp $ + +/************************************************************************ +* Copyright 1995 by Wietse Venema. All rights reserved. Some individual +* files may be covered by other copyrights. +* +* This material was originally written and compiled by Wietse Venema at +* Eindhoven University of Technology, The Netherlands, in 1990, 1991, +* 1992, 1993, 1994 and 1995. +* +* Redistribution and use in source and binary forms are permitted +* provided that this entire copyright notice is duplicated in all such +* copies. +* +* This software is provided "as is" and without any expressed or implied +* warranties, including, without limitation, the implied warranties of +* merchantibility and fitness for any particular purpose. +************************************************************************/ diff --git a/libexec/tcpd/Makefile b/libexec/tcpd/Makefile new file mode 100644 index 00000000000..f6a3d27ea17 --- /dev/null +++ b/libexec/tcpd/Makefile @@ -0,0 +1,5 @@ +# $OpenBSD: Makefile,v 1.1 1997/02/26 06:00:33 downsj Exp $ + +SUBDIR= safe_finger tcpd tcpdchk tcpdmatch + +.include diff --git a/libexec/tcpd/Makefile.inc b/libexec/tcpd/Makefile.inc new file mode 100644 index 00000000000..f09d54930f5 --- /dev/null +++ b/libexec/tcpd/Makefile.inc @@ -0,0 +1,9 @@ +# $OpenBSD: Makefile.inc,v 1.1 1997/02/26 06:00:34 downsj Exp $ + +# Configuration options for libwrap. Keep in sync with libwrap/Makefile. +CFLAGS+=-DPROCESS_OPTIONS -DFACILITY=LOG_AUTH -DSEVERITY=LOG_INFO \ + -DRFC931_TIMEOUT=10 -DHOSTS_ACCESS -DALWAYS_HOSTNAME \ + -DHOSTS_DENY=\"/etc/hosts.deny\" -DHOSTS_ALLOW=\"/etc/hosts.allow\" \ + -DNETGROUP -DSYS_ERRLIST_DEFINED -DREAL_DAEMON_DIR=\"/usr/libexec\" + +.include "../Makefile.inc" diff --git a/libexec/tcpd/README b/libexec/tcpd/README new file mode 100644 index 00000000000..3d3f1f1c65b --- /dev/null +++ b/libexec/tcpd/README @@ -0,0 +1,1036 @@ +$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 +% 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
netmask up + 4.4 BSD: ifconfig en0 alias
netmask + +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 % 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. -- cgit v1.2.3