diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 1038 |
1 files changed, 1038 insertions, 0 deletions
@@ -0,0 +1,1038 @@ +@(#) README 1.30 97/03/21 19:27:21 + +This is the 7.6 version of the TCP/IP daemon wrapper package. + +Thank you for using this program. If you like it, send me a postcard. +My postal address is at the bottom of this file. + +Read the BLURB file for a brief summary of what is new. The CHANGES +file gives a complete account of differences with respect to previous +releases. + +Announcements of new releases of this software are posted to Usenet +(comp.security.unix, comp.unix.admin), to the cert-tools mailing list, +and to a dedicated mailing list. You can subscribe to the dedicated +mailing list by sending an email message to majordomo@wzv.win.tue.nl +with in the body (not subject): subscribe tcp-wrappers-announce. + +Table of contents +----------------- + + 1 - Introduction + 2 - Disclaimer + 3 - Tutorials + 3.1 - How it works + 3.2 - Where the logging information goes + 4 - Features + 4.1 - Access control + 4.2 - Host name spoofing + 4.3 - Host address spoofing + 4.4 - Client username lookups + 4.5 - Language extensions + 4.6 - Multiple ftp/gopher/www archives on one host + 4.7 - Banner messages + 4.8 - Sequence number guessing + 5 - Other works + 5.1 - Related documents + 5.2 - Related software + 6 - Limitations + 6.1 - Known wrapper limitations + 6.2 - Known system software bugs + 7 - Configuration and installation + 7.1 - Easy configuration and installation + 7.2 - Advanced configuration and installation + 7.3 - Daemons with arbitrary path names + 7.4 - Building and testing the access control rules + 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. -DKILL_IP_OPTIONS is not needed on modern UNIX systems +that can stop source-routed traffic in the kernel. Examples are +4.4BSD derivatives, Solaris 2.x, and Linux. See your system manuals +for details. + +If you are going to use this feature on SunOS 4.1.x you should apply +patch 100804-03+ or 101790-something depending on your SunOS version. +Otherwise you may experience "BAD TRAP" and "Data fault" panics when +the getsockopt() system call is executed after a TCP RESET has been +received. This is a kernel bug, it is not the fault of the wrappers. + +The feature is disabled by default. It can be turned on by editing the +Makefile. The configuration and installation section below describes +the Makefile editing process. + +UDP services do not benefit from this additional protection. With UDP, +all you can be certain of is the network packet's destination address. + +4.4 - Client username lookups +----------------------------- + +The protocol proposed in RFC 931 provides a means to obtain the client +user name from the client host. The requirement is that the client +host runs an RFC 931-compliant daemon. The information provided by such +a daemon is not intended to be used for authentication purposes, but it +can provide additional information about the owner of a TCP connection. + +The RFC 931 protocol has diverged into different directions (IDENT, +TAP, RFC 1413). To add to the confusion, they all use the same network +port. The daemon wrappers implement a common subset of the protocols. + +There are some limitations: the number of hosts that run an RFC 931 (or +compatible) daemon is limited (but growing); client user name lookups +do not work for datagram (UDP) services. More seriously, client user +name lookups can cause noticeable delays with connections from non-UNIX +PCs. Recent PC software seem to have fixed this (for example NCSA +telnet). The wrappers use a 10-second timeout for RFC931 lookups, to +accommodate slow networks and slow hosts. + +By default, the wrappers will do username lookup only when the access +control rules require them to do so (via user@host client patterns, see +the hosts_access.5 manual page) or when the username is needed for +%<letter> expansions. + +You can configure the wrappers to always perform client username +lookups, by editing the Makefile. The client username lookup timeout +period (10 seconds default) can be changed by editing the Makefile. The +installation sections below describe the Makefile editing process. + +On System V with TLI-based network services, client username lookups +will be possible only when the underlying network protocol is TCP/IP. + +4.5 - Language extensions +------------------------- + +The wrappers sport only a limited number of features. This is for a +good reason: programs that run at high privilege levels must be easy to +verify. And the smaller a program, the easier to verify. There is, +however, a provision to add features. + +The options.c module provides a framework for language extensions. +Quite a few extensions have already been implemented; they are +documented in the hosts_options.5 document, which is in `nroff -man' +format. Examples: changing the severity level at which a request for +service is logged; "allow" and "deny" keywords; running a customized +server instead of the standard one; many others. + +The language extensions are not enabled by default because they +introduce an incompatible change to the access control language +syntax. Instructions to enable the extensions are given in the +Makefile. + +4.6 - Multiple ftp/gopher/www archives on one host +-------------------------------------------------- + +Imagine one host with multiple internet addresses. These addresses do +not need to have the same internet hostname. Thus, it is possible to +offer services with different internet hostnames from just one host. + +Service providers can use this to offer organizations a presence on the +"net" with their own internet hostname, even when those organizations +aren't connected to the Internet at all. To the end user it makes no +difference, because applications use internet hostnames. + +There are several ways to assign multiple addresses to one machine. +The nice way is to take an existing network interface and to assign +additional internet addresses with the `ifconfig' command. Examples: + + Solaris 2: ifconfig le0:1 <address> netmask <mask> up + 4.4 BSD: ifconfig en0 alias <address> netmask <mask> + +On other systems one has to increase the number of network interfaces: +either with hardware interfaces, or with pseudo interfaces like SLIP or +PPP. The interfaces do not need to be attached to anything. They just +need to be up and to be assigned a suitable internet address and mask. + +With the wrapper software, `daemon@host' access control patterns can be +used to distinguish requests by the network address that they are aimed +at. Judicious use of the `twist' option (see the hosts_options.5 file, +`nroff -man' format) can guide the requests to the right server. These +can be servers that live in separate chroot areas, or servers modified +to take additional context from the command line, or a combination. + +Another way is to modify gopher or www listeners so that they bind to +only one specific network address. Multiple gopher or www servers can +then be run side by side, each taking requests sent to its respective +network address. + +4.7 - Banner messages +--------------------- + +Some sites are required to present an informational message to users +before they attempt to login. Banner messages can also be useful when +denying service: instead of simply dropping the connection a polite +explanation is given first. Finally, banners can be used to give your +system a more personal touch. + +The wrapper software provides easy-to-use tools to generate pre-login +banners for ftp, telnet, rlogin etc. from a single prototype banner +textfile. Details on banners and on-the-fly %<letter> expansions are +given in the hosts_options.5 manual page (`nroff -man' format). An +example is given in the file Banners.Makefile. + +In order to support banner messages the wrappers have to be built with +language extensions enabled. See the section on language extensions. + +4.8 - Sequence number guessing +------------------------------ + +Recently, systems came under attack from intruders that exploited a +well-known weakness in TCP/IP sequence number generators. This +weakness allows intruders to impersonate trusted hosts. Break-ins have +been reported via the rsh service. In fact, any network service can be +exploited that trusts the client host name or address. + +A long-term solution is to stop using network services that trust the +client host name or address, and to use data encryption instead. + +A short-term solution, as outlined in in CERT advisory CA-95:01, is to +configure network routers so that they discard datagrams from "outside" +with an "inside" source address. This approach is most fruitful when +you do not trust any hosts outside your local network. + +The IDENT (RFC931 etc.) client username lookup protocol can help to +detect host impersonation attacks. Before accepting a client request, +the wrappers can query the client's IDENT server and find out that the +client never sent that request. + +When the client host provides IDENT service, a negative IDENT lookup +result (the client matches `UNKNOWN@host') is strong evidence of a host +impersonation attack. + +A positive IDENT lookup result (the client matches `KNOWN@host') is +less trustworthy. It is possible for an attacker to spoof both the +client request and the IDENT lookup connection, although doing so +should be much harder than spoofing just a client request. Another +possibility is that the client's IDENT server is lying. + +Client username lookups are described in more detail in a previous +section. Pointers to IDENT daemon software are described in the section +on related software. + +5 - Other works +--------------- + +5.1 - Related documents +----------------------- + +The war story behind the tcp wrapper tools is described in: + + W.Z. Venema, "TCP WRAPPER, network monitoring, access control and + booby traps", UNIX Security Symposium III Proceedings (Baltimore), + September 1992. + + ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript) + ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text) + +The same cracker is also described in: + + W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is + Lured, Endured, and Studied", Proceedings of the Winter USENIX + Conference (San Francisco), January 1992. + + research.att.com:/dist/internet_security/berferd.ps + +An updated version of the latter paper appeared in: + + W.R. Cheswick, S.M. Bellovin, "Firewalls and Internet Security", + Addison-Wesley, 1994. + +Discussions on internet firewalls are archived on ftp.greatcircle.com. +Subscribe to the mailing list by sending a message to + + majordomo@greatcircle.com + +With in the body (not subject): subscribe firewalls. + +5.2 - Related software +---------------------- + +Network daemons etc. with enhanced logging capabilities can generate +massive amounts of information: our 150+ workstations generate several +hundred kbytes each day. egrep-based filters can help to suppress some +of the noise. A more powerful tool is the Swatch monitoring system by +Stephen E. Hansen and E. Todd Atkins. Swatch can process log files in +real time and can associate arbitrary actions with patterns; its +applications are by no means restricted to security. Swatch is +available ftp.stanford.edu, directory /general/security-tools/swatch. + +Socks, described in the UNIX Security III proceedings, can be used to +control network traffic from hosts on an internal network, through a +firewall host, to the outer world. Socks consists of a daemon that is +run on the firewall host, and of a library with routines that redirect +application socket calls through the firewall daemon. Socks is +available from s1.gov in /pub/firewalls/socks.tar.Z. + +For a modified Socks version by Ying-Da Lee (ylee@syl.dl.nec.com) try +ftp.nec.com, directory /pub/security/socks.cstc. + +Tcpr is a set of perl scripts by Paul Ziemba that enable you to run ftp +and telnet commands across a firewall. Unlike socks it can be used with +unmodified client software. Available from ftp.alantec.com, /pub/tcpr. + +The TIS firewall toolkit provides a multitude of tools to build your +own internet firewall system. ftp.tis.com, directory /pub/firewalls. + +Versions of rshd and rlogind, modified to report the client user name +in addition to the client host name, are available for anonymous ftp +(ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z). These programs are +drop-in replacements for SunOS 4.x, Ultrix 4.x, SunOS 5.x and HP-UX +9.x. This archive also contains ftpd/rexecd/login versions that support +S/Key or SecureNet one-time passwords in addition to traditional UNIX +reusable passwords. + +The securelib shared library by William LeFebvre can be used to control +access to network daemons that are not run under control of the inetd +or that serve more than one client, such as the NFS mount daemon that +runs until the machine goes down. Available from eecs.nwu.edu, file +/pub/securelib.tar. + +xinetd (posted to comp.sources.unix) is an inetd replacement that +provides, among others, logging, username lookup and access control. +However, it does not support the System V TLI services, and involves +much more source code than the daemon wrapper programs. Available +from ftp.uu.net, directory /usenet/comp.sources.unix. + +netlog from Texas A&M relies on the SunOS 4.x /dev/nit interface to +passively watch all TCP and UDP network traffic on a network. The +current version is on net.tamu.edu in /pub/security/TAMU. + +Where shared libraries or router-based packet filtering are not an +option, an alternative portmap daemon can help to prevent hackers +from 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. |