diff options
Diffstat (limited to 'contrib/tcp_wrappers/README')
| -rw-r--r-- | contrib/tcp_wrappers/README | 1038 |
1 files changed, 0 insertions, 1038 deletions
diff --git a/contrib/tcp_wrappers/README b/contrib/tcp_wrappers/README deleted file mode 100644 index 98b6b472a4d51..0000000000000 --- a/contrib/tcp_wrappers/README +++ /dev/null @@ -1,1038 +0,0 @@ -@(#) 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. |