README revision 44743
144743Smarkm@(#) README 1.30 97/03/21 19:27:21 244743Smarkm 344743SmarkmThis is the 7.6 version of the TCP/IP daemon wrapper package. 444743Smarkm 544743SmarkmThank you for using this program. If you like it, send me a postcard. 644743SmarkmMy postal address is at the bottom of this file. 744743Smarkm 844743SmarkmRead the BLURB file for a brief summary of what is new. The CHANGES 944743Smarkmfile gives a complete account of differences with respect to previous 1044743Smarkmreleases. 1144743Smarkm 1244743SmarkmAnnouncements of new releases of this software are posted to Usenet 1344743Smarkm(comp.security.unix, comp.unix.admin), to the cert-tools mailing list, 1444743Smarkmand to a dedicated mailing list. You can subscribe to the dedicated 1544743Smarkmmailing list by sending an email message to majordomo@wzv.win.tue.nl 1644743Smarkmwith in the body (not subject): subscribe tcp-wrappers-announce. 1744743Smarkm 1844743SmarkmTable of contents 1944743Smarkm----------------- 2044743Smarkm 2144743Smarkm 1 - Introduction 2244743Smarkm 2 - Disclaimer 2344743Smarkm 3 - Tutorials 2444743Smarkm 3.1 - How it works 2544743Smarkm 3.2 - Where the logging information goes 2644743Smarkm 4 - Features 2744743Smarkm 4.1 - Access control 2844743Smarkm 4.2 - Host name spoofing 2944743Smarkm 4.3 - Host address spoofing 3044743Smarkm 4.4 - Client username lookups 3144743Smarkm 4.5 - Language extensions 3244743Smarkm 4.6 - Multiple ftp/gopher/www archives on one host 3344743Smarkm 4.7 - Banner messages 3444743Smarkm 4.8 - Sequence number guessing 3544743Smarkm 5 - Other works 3644743Smarkm 5.1 - Related documents 3744743Smarkm 5.2 - Related software 3844743Smarkm 6 - Limitations 3944743Smarkm 6.1 - Known wrapper limitations 4044743Smarkm 6.2 - Known system software bugs 4144743Smarkm 7 - Configuration and installation 4244743Smarkm 7.1 - Easy configuration and installation 4344743Smarkm 7.2 - Advanced configuration and installation 4444743Smarkm 7.3 - Daemons with arbitrary path names 4544743Smarkm 7.4 - Building and testing the access control rules 4644743Smarkm 7.5 - Other applications 4744743Smarkm 8 - Acknowledgements 4844743Smarkm 4944743Smarkm1 - Introduction 5044743Smarkm---------------- 5144743Smarkm 5244743SmarkmWith this package you can monitor and filter incoming requests for the 5344743SmarkmSYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other 5444743Smarkmnetwork services. 5544743Smarkm 5644743SmarkmIt supports both 4.3BSD-style sockets and System V.4-style TLI. Praise 5744743Smarkmyourself lucky if you don't know what that means. 5844743Smarkm 5944743SmarkmThe package provides tiny daemon wrapper programs that can be installed 6044743Smarkmwithout any changes to existing software or to existing configuration 6144743Smarkmfiles. The wrappers report the name of the client host and of the 6244743Smarkmrequested service; the wrappers do not exchange information with the 6344743Smarkmclient or server applications, and impose no overhead on the actual 6444743Smarkmconversation between the client and server applications. 6544743Smarkm 6644743SmarkmOptional features are: access control to restrict what systems can 6744743Smarkmconnect to what network daemons; client user name lookups with the RFC 6844743Smarkm931 etc. protocol; additional protection against hosts that pretend to 6944743Smarkmhave someone elses host name; additional protection against hosts that 7044743Smarkmpretend to have someone elses host address. 7144743Smarkm 7244743SmarkmThe programs are very portable. Build procedures are provided for many 7344743Smarkmcommon (and not so common) environments, and guidelines are provided in 7444743Smarkmcase your environment is not among them. 7544743Smarkm 7644743SmarkmRequirements are that network daemons are spawned by a super server 7744743Smarkmsuch as the inetd; a 4.3BSD-style socket programming interface and/or 7844743SmarkmSystem V.4-style TLI programming interface; and the availability of a 7944743Smarkmsyslog(3) library and of a syslogd(8) daemon. The wrappers should run 8044743Smarkmwithout modification on any system that satisfies these requirements. 8144743SmarkmWorkarounds have been implemented for several common bugs in systems 8244743Smarkmsoftware. 8344743Smarkm 8444743SmarkmWhat to do if this is your first encounter with the wrapper programs: 8544743Smarkm1) read the tutorial sections for an introduction to the relevant 8644743Smarkmconcepts and terminology; 2) glance over the security feature sections 8744743Smarkmin this document; 3) follow the installation instructions (easy or 8844743Smarkmadvanced). I recommend that you first use the default security feature 8944743Smarkmsettings. Run the wrappers for a few days to become familiar with 9044743Smarkmtheir logs, before doing anything drastic such as cutting off access or 9144743Smarkminstalling booby traps. 9244743Smarkm 9344743Smarkm2 - Disclaimer 9444743Smarkm-------------- 9544743Smarkm 9644743SmarkmThe wrapper programs rely on source address information obtained from 9744743Smarkmnetwork packets. This information is provided by the client host. It is 9844743Smarkmnot 100 percent reliable, although the wrappers do their best to expose 9944743Smarkmforgeries. 10044743Smarkm 10144743SmarkmIn the absence of cryptographic protection of message contents, and of 10244743Smarkmcryptographic authentication of message originators, all data from the 10344743Smarkmnetwork should be treated with sound scepticism. 10444743Smarkm 10544743SmarkmTHIS RESTRICTION IS BY NO MEANS SPECIFIC TO THE TCP/IP PROTOCOLS. 10644743Smarkm 10744743Smarkm3 - Tutorials 10844743Smarkm------------- 10944743Smarkm 11044743SmarkmThe tutorial sections give a gentle introduction to the operation of 11144743Smarkmthe wrapper programs, and introduce some of the terminology that is 11244743Smarkmused in the remainder of the document: client, server, the inetd and 11344743Smarkmsyslogd daemons, and their configuration files. 11444743Smarkm 11544743Smarkm3.1 - How it works 11644743Smarkm------------------ 11744743Smarkm 11844743SmarkmAlmost every application of the TCP/IP protocols is based on a client- 11944743Smarkmserver model. For example, when a user invokes the telnet command to 12044743Smarkmconnect to one of your systems, a telnet server process is executed on 12144743Smarkmthe target host. The telnet server process connects the user to a login 12244743Smarkmprocess. A few examples of client and server programs are shown in the 12344743Smarkmtable below: 12444743Smarkm 12544743Smarkm client server application 12644743Smarkm -------------------------------- 12744743Smarkm telnet telnetd remote login 12844743Smarkm ftp ftpd file transfer 12944743Smarkm finger fingerd show users 13044743Smarkm 13144743SmarkmThe usual approach is to run one single daemon process that waits for 13244743Smarkmall kinds of incoming network connections. Whenever a connection is 13344743Smarkmestablished, this daemon (usually called inetd) runs the appropriate 13444743Smarkmserver program and goes back to sleep, waiting for other connections. 13544743Smarkm 13644743SmarkmThe wrapper programs rely on a simple, but powerful mechanism. Instead 13744743Smarkmof directly running the desired server program, the inetd is tricked 13844743Smarkminto running a small wrapper program. The wrapper logs the client host 13944743Smarkmname or address and performs some additional checks. When all is well, 14044743Smarkmthe wrapper executes the desired server program and goes away. 14144743Smarkm 14244743SmarkmThe wrapper programs have no interaction with the client user (or with 14344743Smarkmthe client process). Nor do the wrappers interact with the server 14444743Smarkmapplication. This has two major advantages: 1) the wrappers are 14544743Smarkmapplication-independent, so that the same program can protect many 14644743Smarkmkinds of network services; 2) no interaction also means that the 14744743Smarkmwrappers are invisible from outside (at least for authorized users). 14844743Smarkm 14944743SmarkmAnother important property is that the wrapper programs are active only 15044743Smarkmwhen the initial contact between client and server is established. Once 15144743Smarkma wrapper has done its work there is no overhead on the client-server 15244743Smarkmconversation. 15344743Smarkm 15444743SmarkmThe simple mechanism has one major drawback: the wrappers go away after 15544743Smarkmthe initial contact between client and server processes, so the 15644743Smarkmwrappers are of little use with network daemons that service more than 15744743Smarkmone client. The wrappers would only see the first client attempt to 15844743Smarkmcontact such a server. The NFS mount daemon is a typical example of a 15944743Smarkmdaemon that services requests from multiple clients. See the section on 16044743Smarkmrelated software for ways to deal with such server programs. 16144743Smarkm 16244743SmarkmThere are two ways to use the wrapper programs: 16344743Smarkm 16444743Smarkm1) The easy way: move network daemons to some other directory and fill 16544743Smarkm the resulting holes with copies of the wrapper programs. This 16644743Smarkm approach involves no changes to system configuration files, so there 16744743Smarkm is very little risk of breaking things. 16844743Smarkm 16944743Smarkm2) The advanced way: leave the network daemons alone and modify the 17044743Smarkm inetd configuration file. For example, an entry such as: 17144743Smarkm 17244743Smarkm tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot 17344743Smarkm 17444743Smarkm When a tftp request arrives, inetd will run the wrapper program 17544743Smarkm (tcpd) with a process name `in.tftpd'. This is the name that the 17644743Smarkm wrapper will use when logging the request and when scanning the 17744743Smarkm optional access control tables. `in.tftpd' is also the name of the 17844743Smarkm server program that the wrapper will attempt to run when all is 17944743Smarkm well. Any arguments (`-s /tftpboot' in this particular example) are 18044743Smarkm transparently passed on to the server program. 18144743Smarkm 18244743SmarkmFor an account of the history of the wrapper programs, with real-life 18344743Smarkmexamples, see the section below on related documents. 18444743Smarkm 18544743Smarkm3.2 - Where the logging information goes 18644743Smarkm---------------------------------------- 18744743Smarkm 18844743SmarkmThe wrapper programs send their logging information to the syslog 18944743Smarkmdaemon (syslogd). The disposition of the wrapper logs is determined by 19044743Smarkmthe syslog configuration file (usually /etc/syslog.conf). Messages are 19144743Smarkmwritten to files, to the console, or are forwarded to a @loghost. Some 19244743Smarkmsyslogd versions can even forward messages down a |pipeline. 19344743Smarkm 19444743SmarkmOlder syslog implementations (still found on Ultrix systems) only 19544743Smarkmsupport priority levels ranging from 9 (debug-level messages) to 0 19644743Smarkm(alerts). All logging information of the specified priority level or 19744743Smarkmmore urgent is written to the same destination. In the syslog.conf 19844743Smarkmfile, priority levels are specified in numerical form. For example, 19944743Smarkm 20044743Smarkm 8/usr/spool/mqueue/syslog 20144743Smarkm 20244743Smarkmcauses all messages with priority 8 (informational messages), and 20344743Smarkmanything that is more urgent, to be appended to the file 20444743Smarkm/usr/spool/mqueue/syslog. 20544743Smarkm 20644743SmarkmNewer syslog implementations support message classes in addition to 20744743Smarkmpriority levels. Examples of message classes are: mail, daemon, auth 20844743Smarkmand news. In the syslog.conf file, priority levels are specified with 20944743Smarkmsymbolic names: debug, info, notice, ..., emerg. For example, 21044743Smarkm 21144743Smarkm mail.debug /var/log/syslog 21244743Smarkm 21344743Smarkmcauses all messages of class mail with priority debug (or more urgent) 21444743Smarkmto be appended to the /var/log/syslog file. 21544743Smarkm 21644743SmarkmBy default, the wrapper logs go to the same place as the transaction 21744743Smarkmlogs of the sendmail daemon. The disposition can be changed by editing 21844743Smarkmthe Makefile and/or the syslog.conf file. Send a `kill -HUP' to the 21944743Smarkmsyslogd after changing its configuration file. Remember that syslogd, 22044743Smarkmjust like sendmail, insists on one or more TABs between the left-hand 22144743Smarkmside and the right-hand side expressions in its configuration file. 22244743Smarkm 22344743SmarkmSolaris 2.x note: the syslog daemon depends on the m4 macro processor. 22444743SmarkmThe m4 program is installed as part of the software developer packages. 22544743Smarkm 22644743SmarkmTrouble shooting note: when the syslogging does not work as expected, 22744743Smarkmrun the program by hand (`syslogd -d') and see what really happens. 22844743Smarkm 22944743Smarkm4 - Features 23044743Smarkm------------ 23144743Smarkm 23244743Smarkm4.1 - Access control 23344743Smarkm-------------------- 23444743Smarkm 23544743SmarkmWhen compiled with -DHOSTS_ACCESS, the wrapper programs support a 23644743Smarkmsimple form of access control. Access can be controlled per host, per 23744743Smarkmservice, or combinations thereof. The software provides hooks for the 23844743Smarkmexecution of shell commands when an access control rule fires; this 23944743Smarkmfeature may be used to install "booby traps". For details, see the 24044743Smarkmhosts_access.5 manual page, which is in `nroff -man' format. A later 24144743Smarkmsection describes how you can test your access control rules. 24244743Smarkm 24344743SmarkmAccess control can also be used to connect clients to the "right" 24444743Smarkmservice. What is right may depend on the requested service, the origin 24544743Smarkmof the request, and what host address the client connects to. Examples: 24644743Smarkm 24744743Smarkm(1) A gopher or www database speaks native language when contacted from 24844743Smarkm within the country, otherwise it speaks English. 24944743Smarkm 25044743Smarkm(2) A service provider offers different ftp, gopher or www services 25144743Smarkm with different internet hostnames from one host (section 4.6). 25244743Smarkm 25344743SmarkmAccess control is enabled by default. It can be turned off by editing 25444743Smarkmthe Makefile, or by providing no access control tables. The install 25544743Smarkminstructions below describe the Makefile editing process. 25644743Smarkm 25744743SmarkmThe hosts_options.5 manual page (`nroff -man' format) documents an 25844743Smarkmextended version of the access control language. The extensions are 25944743Smarkmdisabled by default. See the section below on language extensions. 26044743Smarkm 26144743SmarkmLater System V implementations provide the Transport Level Interface 26244743Smarkm(TLI), a network programming interface that performs functions similar 26344743Smarkmto the Berkeley socket programming interface. Like Berkeley sockets, 26444743SmarkmTLI was designed to cover multiple protocols, not just Internet. 26544743Smarkm 26644743SmarkmWhen the wrapper discovers that the TLI interface sits on top of a 26744743SmarkmTCP/IP or UDP/IP conversation it uses this knowledge to provide the 26844743Smarkmsame functions as with traditional socket-based applications. When 26944743Smarkmsome other protocol is used underneath TLI, the host address will be 27044743Smarkmsome universal magic cookie that may not even be usable for access 27144743Smarkmcontrol purposes. 27244743Smarkm 27344743Smarkm4.2 - Host name spoofing 27444743Smarkm------------------------ 27544743Smarkm 27644743SmarkmWith some network applications, such as RSH or RLOGIN, the client host 27744743Smarkmname plays an important role in the authentication process. Host name 27844743Smarkminformation can be reliable when lookups are done from a _local_ hosts 27944743Smarkmtable, provided that the client IP address can be trusted. 28044743Smarkm 28144743SmarkmWith _distributed_ name services, authentication schemes that rely on 28244743Smarkmhost names become more problematic. The security of your system now may 28344743Smarkmdepend on some far-away DNS (domain name server) outside your own 28444743Smarkmcontrol. 28544743Smarkm 28644743SmarkmThe wrapper programs verify the client host name that is returned by 28744743Smarkmthe address->name DNS server, by asking for a second opinion. To this 28844743Smarkmend, the programs look at the name and addresses that are returned by 28944743Smarkmthe name->address DNS server, which may be an entirely different host. 29044743Smarkm 29144743SmarkmIf any name or address discrepancies are found, or if the second DNS 29244743Smarkmopinion is not available, the wrappers assume that one of the two name 29344743Smarkmservers is lying, and assume that the client host pretends to have 29444743Smarkmsomeone elses host name. 29544743Smarkm 29644743SmarkmWhen compiled with -DPARANOID, the wrappers will always attempt to look 29744743Smarkmup and double check the client host name, and will always refuse 29844743Smarkmservice in case of a host name/address discrepancy. This is a 29944743Smarkmreasonable policy for most systems. 30044743Smarkm 30144743SmarkmWhen compiled without -DPARANOID, the wrappers by default still perform 30244743Smarkmhostname lookup. You can match hosts with a name/address discrepancy 30344743Smarkmwith the PARANOID wildcard and decide whether or not to grant service. 30444743Smarkm 30544743SmarkmAutomatic hostname verification is enabled by default. Automatic 30644743Smarkmhostname lookups and verification can be turned off by editing the 30744743SmarkmMakefile. The configuration and installation section below describes 30844743Smarkmthe Makefile editing process. 30944743Smarkm 31044743Smarkm4.3 - Host address spoofing 31144743Smarkm--------------------------- 31244743Smarkm 31344743SmarkmWhile host name spoofing can be found out by asking a second opinion, 31444743Smarkmit is much harder to find out that a host claims to have someone elses 31544743Smarkmnetwork address. And since host names are deduced from network 31644743Smarkmaddresses, address spoofing is at least as effective as name spoofing. 31744743Smarkm 31844743SmarkmThe wrapper programs can give additional protection against hosts that 31944743Smarkmclaim to have an address that lies outside their own network. For 32044743Smarkmexample, some far-away host that claims to be a trusted host within 32144743Smarkmyour own network. Such things are possible even while the impersonated 32244743Smarkmsystem is up and running. 32344743Smarkm 32444743SmarkmThis additional protection is not an invention of my own; it has been 32544743Smarkmpresent for at least five years in the BSD rsh and rlogin daemons. 32644743SmarkmUnfortunately, that feature was added *after* 4.3 BSD came out, so that 32744743Smarkmvery few, if any, UNIX vendors have adopted it. Our site, and many 32844743Smarkmother ones, has been running these enhanced daemons for several years, 32944743Smarkmand without any ill effects. 33044743Smarkm 33144743SmarkmWhen the wrapper programs are compiled with -DKILL_IP_OPTIONS, the 33244743Smarkmprograms refuse to service TCP connections with IP source routing 33344743Smarkmoptions. -DKILL_IP_OPTIONS is not needed on modern UNIX systems 33444743Smarkmthat can stop source-routed traffic in the kernel. Examples are 33544743Smarkm4.4BSD derivatives, Solaris 2.x, and Linux. See your system manuals 33644743Smarkmfor details. 33744743Smarkm 33844743SmarkmIf you are going to use this feature on SunOS 4.1.x you should apply 33944743Smarkmpatch 100804-03+ or 101790-something depending on your SunOS version. 34044743SmarkmOtherwise you may experience "BAD TRAP" and "Data fault" panics when 34144743Smarkmthe getsockopt() system call is executed after a TCP RESET has been 34244743Smarkmreceived. This is a kernel bug, it is not the fault of the wrappers. 34344743Smarkm 34444743SmarkmThe feature is disabled by default. It can be turned on by editing the 34544743SmarkmMakefile. The configuration and installation section below describes 34644743Smarkmthe Makefile editing process. 34744743Smarkm 34844743SmarkmUDP services do not benefit from this additional protection. With UDP, 34944743Smarkmall you can be certain of is the network packet's destination address. 35044743Smarkm 35144743Smarkm4.4 - Client username lookups 35244743Smarkm----------------------------- 35344743Smarkm 35444743SmarkmThe protocol proposed in RFC 931 provides a means to obtain the client 35544743Smarkmuser name from the client host. The requirement is that the client 35644743Smarkmhost runs an RFC 931-compliant daemon. The information provided by such 35744743Smarkma daemon is not intended to be used for authentication purposes, but it 35844743Smarkmcan provide additional information about the owner of a TCP connection. 35944743Smarkm 36044743SmarkmThe RFC 931 protocol has diverged into different directions (IDENT, 36144743SmarkmTAP, RFC 1413). To add to the confusion, they all use the same network 36244743Smarkmport. The daemon wrappers implement a common subset of the protocols. 36344743Smarkm 36444743SmarkmThere are some limitations: the number of hosts that run an RFC 931 (or 36544743Smarkmcompatible) daemon is limited (but growing); client user name lookups 36644743Smarkmdo not work for datagram (UDP) services. More seriously, client user 36744743Smarkmname lookups can cause noticeable delays with connections from non-UNIX 36844743SmarkmPCs. Recent PC software seem to have fixed this (for example NCSA 36944743Smarkmtelnet). The wrappers use a 10-second timeout for RFC931 lookups, to 37044743Smarkmaccommodate slow networks and slow hosts. 37144743Smarkm 37244743SmarkmBy default, the wrappers will do username lookup only when the access 37344743Smarkmcontrol rules require them to do so (via user@host client patterns, see 37444743Smarkmthe hosts_access.5 manual page) or when the username is needed for 37544743Smarkm%<letter> expansions. 37644743Smarkm 37744743SmarkmYou can configure the wrappers to always perform client username 37844743Smarkmlookups, by editing the Makefile. The client username lookup timeout 37944743Smarkmperiod (10 seconds default) can be changed by editing the Makefile. The 38044743Smarkminstallation sections below describe the Makefile editing process. 38144743Smarkm 38244743SmarkmOn System V with TLI-based network services, client username lookups 38344743Smarkmwill be possible only when the underlying network protocol is TCP/IP. 38444743Smarkm 38544743Smarkm4.5 - Language extensions 38644743Smarkm------------------------- 38744743Smarkm 38844743SmarkmThe wrappers sport only a limited number of features. This is for a 38944743Smarkmgood reason: programs that run at high privilege levels must be easy to 39044743Smarkmverify. And the smaller a program, the easier to verify. There is, 39144743Smarkmhowever, a provision to add features. 39244743Smarkm 39344743SmarkmThe options.c module provides a framework for language extensions. 39444743SmarkmQuite a few extensions have already been implemented; they are 39544743Smarkmdocumented in the hosts_options.5 document, which is in `nroff -man' 39644743Smarkmformat. Examples: changing the severity level at which a request for 39744743Smarkmservice is logged; "allow" and "deny" keywords; running a customized 39844743Smarkmserver instead of the standard one; many others. 39944743Smarkm 40044743SmarkmThe language extensions are not enabled by default because they 40144743Smarkmintroduce an incompatible change to the access control language 40244743Smarkmsyntax. Instructions to enable the extensions are given in the 40344743SmarkmMakefile. 40444743Smarkm 40544743Smarkm4.6 - Multiple ftp/gopher/www archives on one host 40644743Smarkm-------------------------------------------------- 40744743Smarkm 40844743SmarkmImagine one host with multiple internet addresses. These addresses do 40944743Smarkmnot need to have the same internet hostname. Thus, it is possible to 41044743Smarkmoffer services with different internet hostnames from just one host. 41144743Smarkm 41244743SmarkmService providers can use this to offer organizations a presence on the 41344743Smarkm"net" with their own internet hostname, even when those organizations 41444743Smarkmaren't connected to the Internet at all. To the end user it makes no 41544743Smarkmdifference, because applications use internet hostnames. 41644743Smarkm 41744743SmarkmThere are several ways to assign multiple addresses to one machine. 41844743SmarkmThe nice way is to take an existing network interface and to assign 41944743Smarkmadditional internet addresses with the `ifconfig' command. Examples: 42044743Smarkm 42144743Smarkm Solaris 2: ifconfig le0:1 <address> netmask <mask> up 42244743Smarkm 4.4 BSD: ifconfig en0 alias <address> netmask <mask> 42344743Smarkm 42444743SmarkmOn other systems one has to increase the number of network interfaces: 42544743Smarkmeither with hardware interfaces, or with pseudo interfaces like SLIP or 42644743SmarkmPPP. The interfaces do not need to be attached to anything. They just 42744743Smarkmneed to be up and to be assigned a suitable internet address and mask. 42844743Smarkm 42944743SmarkmWith the wrapper software, `daemon@host' access control patterns can be 43044743Smarkmused to distinguish requests by the network address that they are aimed 43144743Smarkmat. Judicious use of the `twist' option (see the hosts_options.5 file, 43244743Smarkm`nroff -man' format) can guide the requests to the right server. These 43344743Smarkmcan be servers that live in separate chroot areas, or servers modified 43444743Smarkmto take additional context from the command line, or a combination. 43544743Smarkm 43644743SmarkmAnother way is to modify gopher or www listeners so that they bind to 43744743Smarkmonly one specific network address. Multiple gopher or www servers can 43844743Smarkmthen be run side by side, each taking requests sent to its respective 43944743Smarkmnetwork address. 44044743Smarkm 44144743Smarkm4.7 - Banner messages 44244743Smarkm--------------------- 44344743Smarkm 44444743SmarkmSome sites are required to present an informational message to users 44544743Smarkmbefore they attempt to login. Banner messages can also be useful when 44644743Smarkmdenying service: instead of simply dropping the connection a polite 44744743Smarkmexplanation is given first. Finally, banners can be used to give your 44844743Smarkmsystem a more personal touch. 44944743Smarkm 45044743SmarkmThe wrapper software provides easy-to-use tools to generate pre-login 45144743Smarkmbanners for ftp, telnet, rlogin etc. from a single prototype banner 45244743Smarkmtextfile. Details on banners and on-the-fly %<letter> expansions are 45344743Smarkmgiven in the hosts_options.5 manual page (`nroff -man' format). An 45444743Smarkmexample is given in the file Banners.Makefile. 45544743Smarkm 45644743SmarkmIn order to support banner messages the wrappers have to be built with 45744743Smarkmlanguage extensions enabled. See the section on language extensions. 45844743Smarkm 45944743Smarkm4.8 - Sequence number guessing 46044743Smarkm------------------------------ 46144743Smarkm 46244743SmarkmRecently, systems came under attack from intruders that exploited a 46344743Smarkmwell-known weakness in TCP/IP sequence number generators. This 46444743Smarkmweakness allows intruders to impersonate trusted hosts. Break-ins have 46544743Smarkmbeen reported via the rsh service. In fact, any network service can be 46644743Smarkmexploited that trusts the client host name or address. 46744743Smarkm 46844743SmarkmA long-term solution is to stop using network services that trust the 46944743Smarkmclient host name or address, and to use data encryption instead. 47044743Smarkm 47144743SmarkmA short-term solution, as outlined in in CERT advisory CA-95:01, is to 47244743Smarkmconfigure network routers so that they discard datagrams from "outside" 47344743Smarkmwith an "inside" source address. This approach is most fruitful when 47444743Smarkmyou do not trust any hosts outside your local network. 47544743Smarkm 47644743SmarkmThe IDENT (RFC931 etc.) client username lookup protocol can help to 47744743Smarkmdetect host impersonation attacks. Before accepting a client request, 47844743Smarkmthe wrappers can query the client's IDENT server and find out that the 47944743Smarkmclient never sent that request. 48044743Smarkm 48144743SmarkmWhen the client host provides IDENT service, a negative IDENT lookup 48244743Smarkmresult (the client matches `UNKNOWN@host') is strong evidence of a host 48344743Smarkmimpersonation attack. 48444743Smarkm 48544743SmarkmA positive IDENT lookup result (the client matches `KNOWN@host') is 48644743Smarkmless trustworthy. It is possible for an attacker to spoof both the 48744743Smarkmclient request and the IDENT lookup connection, although doing so 48844743Smarkmshould be much harder than spoofing just a client request. Another 48944743Smarkmpossibility is that the client's IDENT server is lying. 49044743Smarkm 49144743SmarkmClient username lookups are described in more detail in a previous 49244743Smarkmsection. Pointers to IDENT daemon software are described in the section 49344743Smarkmon related software. 49444743Smarkm 49544743Smarkm5 - Other works 49644743Smarkm--------------- 49744743Smarkm 49844743Smarkm5.1 - Related documents 49944743Smarkm----------------------- 50044743Smarkm 50144743SmarkmThe war story behind the tcp wrapper tools is described in: 50244743Smarkm 50344743Smarkm W.Z. Venema, "TCP WRAPPER, network monitoring, access control and 50444743Smarkm booby traps", UNIX Security Symposium III Proceedings (Baltimore), 50544743Smarkm September 1992. 50644743Smarkm 50744743Smarkm ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript) 50844743Smarkm ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text) 50944743Smarkm 51044743SmarkmThe same cracker is also described in: 51144743Smarkm 51244743Smarkm W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is 51344743Smarkm Lured, Endured, and Studied", Proceedings of the Winter USENIX 51444743Smarkm Conference (San Francisco), January 1992. 51544743Smarkm 51644743Smarkm research.att.com:/dist/internet_security/berferd.ps 51744743Smarkm 51844743SmarkmAn updated version of the latter paper appeared in: 51944743Smarkm 52044743Smarkm W.R. Cheswick, S.M. Bellovin, "Firewalls and Internet Security", 52144743Smarkm Addison-Wesley, 1994. 52244743Smarkm 52344743SmarkmDiscussions on internet firewalls are archived on ftp.greatcircle.com. 52444743SmarkmSubscribe to the mailing list by sending a message to 52544743Smarkm 52644743Smarkm majordomo@greatcircle.com 52744743Smarkm 52844743SmarkmWith in the body (not subject): subscribe firewalls. 52944743Smarkm 53044743Smarkm5.2 - Related software 53144743Smarkm---------------------- 53244743Smarkm 53344743SmarkmNetwork daemons etc. with enhanced logging capabilities can generate 53444743Smarkmmassive amounts of information: our 150+ workstations generate several 53544743Smarkmhundred kbytes each day. egrep-based filters can help to suppress some 53644743Smarkmof the noise. A more powerful tool is the Swatch monitoring system by 53744743SmarkmStephen E. Hansen and E. Todd Atkins. Swatch can process log files in 53844743Smarkmreal time and can associate arbitrary actions with patterns; its 53944743Smarkmapplications are by no means restricted to security. Swatch is 54044743Smarkmavailable ftp.stanford.edu, directory /general/security-tools/swatch. 54144743Smarkm 54244743SmarkmSocks, described in the UNIX Security III proceedings, can be used to 54344743Smarkmcontrol network traffic from hosts on an internal network, through a 54444743Smarkmfirewall host, to the outer world. Socks consists of a daemon that is 54544743Smarkmrun on the firewall host, and of a library with routines that redirect 54644743Smarkmapplication socket calls through the firewall daemon. Socks is 54744743Smarkmavailable from s1.gov in /pub/firewalls/socks.tar.Z. 54844743Smarkm 54944743SmarkmFor a modified Socks version by Ying-Da Lee (ylee@syl.dl.nec.com) try 55044743Smarkmftp.nec.com, directory /pub/security/socks.cstc. 55144743Smarkm 55244743SmarkmTcpr is a set of perl scripts by Paul Ziemba that enable you to run ftp 55344743Smarkmand telnet commands across a firewall. Unlike socks it can be used with 55444743Smarkmunmodified client software. Available from ftp.alantec.com, /pub/tcpr. 55544743Smarkm 55644743SmarkmThe TIS firewall toolkit provides a multitude of tools to build your 55744743Smarkmown internet firewall system. ftp.tis.com, directory /pub/firewalls. 55844743Smarkm 55944743SmarkmVersions of rshd and rlogind, modified to report the client user name 56044743Smarkmin addition to the client host name, are available for anonymous ftp 56144743Smarkm(ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z). These programs are 56244743Smarkmdrop-in replacements for SunOS 4.x, Ultrix 4.x, SunOS 5.x and HP-UX 56344743Smarkm9.x. This archive also contains ftpd/rexecd/login versions that support 56444743SmarkmS/Key or SecureNet one-time passwords in addition to traditional UNIX 56544743Smarkmreusable passwords. 56644743Smarkm 56744743SmarkmThe securelib shared library by William LeFebvre can be used to control 56844743Smarkmaccess to network daemons that are not run under control of the inetd 56944743Smarkmor that serve more than one client, such as the NFS mount daemon that 57044743Smarkmruns until the machine goes down. Available from eecs.nwu.edu, file 57144743Smarkm/pub/securelib.tar. 57244743Smarkm 57344743Smarkmxinetd (posted to comp.sources.unix) is an inetd replacement that 57444743Smarkmprovides, among others, logging, username lookup and access control. 57544743SmarkmHowever, it does not support the System V TLI services, and involves 57644743Smarkmmuch more source code than the daemon wrapper programs. Available 57744743Smarkmfrom ftp.uu.net, directory /usenet/comp.sources.unix. 57844743Smarkm 57944743Smarkmnetlog from Texas A&M relies on the SunOS 4.x /dev/nit interface to 58044743Smarkmpassively watch all TCP and UDP network traffic on a network. The 58144743Smarkmcurrent version is on net.tamu.edu in /pub/security/TAMU. 58244743Smarkm 58344743SmarkmWhere shared libraries or router-based packet filtering are not an 58444743Smarkmoption, an alternative portmap daemon can help to prevent hackers 58544743Smarkmfrom mounting your NFS file systems using the proxy RPC facility. 58644743Smarkmftp.win.tue.nl:/pub/security/portmap-X.shar.Z was tested with SunOS 58744743Smarkm4.1.X Ultrix 3.0 and Ultrix 4.x, HP-UX 8.x and some version of AIX. The 58844743Smarkmprotection is less effective than that of the securelib library because 58944743Smarkmportmap is mostly a dictionary service. 59044743Smarkm 59144743SmarkmAn rpcbind replacement (the Solaris 2.x moral equivalent of portmap) 59244743Smarkmcan be found on ftp.win.tue.nl in /pub/security. It prevents hackers 59344743Smarkmfrom mounting your NFS file systems by using the proxy RPC facility. 59444743Smarkm 59544743SmarkmSource for a portable RFC 931 (TAP, IDENT, RFC 1413) daemon by Peter 59644743SmarkmEriksson is available from ftp.lysator.liu.se:/pub/ident/servers. 59744743Smarkm 59844743SmarkmSome TCP/IP implementations come without syslog library. Some come with 59944743Smarkmthe library but have no syslog daemon. A replacement can be found in 60044743Smarkmftp.win.tue.nl:/pub/security/surrogate-syslog.tar.Z. The fakesyslog 60144743Smarkmlibrary that comes with the nntp sources reportedly works well, too. 60244743Smarkm 60344743Smarkm6 - Limitations 60444743Smarkm--------------- 60544743Smarkm 60644743Smarkm6.1 - Known wrapper limitations 60744743Smarkm------------------------------- 60844743Smarkm 60944743SmarkmMany UDP (and rpc/udp) daemons linger around for a while after they 61044743Smarkmhave serviced a request, just in case another request comes in. In the 61144743Smarkminetd configuration file these daemons are registered with the `wait' 61244743Smarkmoption. Only the request that started such a daemon will be seen by the 61344743Smarkmwrappers. Such daemons are better protected with the securelib shared 61444743Smarkmlibrary (see: Related software). 61544743Smarkm 61644743SmarkmThe wrappers do not work with RPC services over TCP. These services are 61744743Smarkmregistered as rpc/tcp in the inetd configuration file. The only non- 61844743Smarkmtrivial service that is affected by this limitation is rexd, which is 61944743Smarkmused by the on(1) command. This is no great loss. On most systems, 62044743Smarkmrexd is less secure than a wildcard in /etc/hosts.equiv. 62144743Smarkm 62244743SmarkmSome RPC requests (for example: rwall, rup, rusers) appear to come from 62344743Smarkmthe server host. What happens is that the client broadcasts its request 62444743Smarkmto all portmap daemons on its network; each portmap daemon forwards the 62544743Smarkmrequest to a daemon on its own system. As far as the rwall etc. daemons 62644743Smarkmknow, the request comes from the local host. 62744743Smarkm 62844743SmarkmPortmap and RPC (e.g. NIS and NFS) (in)security is a topic in itself. 62944743SmarkmSee the section in this document on related software. 63044743Smarkm 63144743Smarkm6.2 - Known system software bugs 63244743Smarkm-------------------------------- 63344743Smarkm 63444743SmarkmWorkarounds have been implemented for several bugs in system software. 63544743SmarkmThey are described in the Makefile. Unfortunately, some system software 63644743Smarkmbugs cannot be worked around. The result is loss of functionality. 63744743Smarkm 63844743SmarkmIRIX has so many bugs that it has its own README.IRIX file. 63944743Smarkm 64044743SmarkmOlder ConvexOS versions come with a broken recvfrom(2) implementation. 64144743SmarkmThis makes it impossible for the daemon wrappers to look up the 64244743Smarkmclient host address (and hence, the name) in case of UDP requests. 64344743SmarkmA patch is available for ConvexOS 10.1; later releases should be OK. 64444743Smarkm 64544743SmarkmWith early Solaris (SunOS 5) versions, the syslog daemon will leave 64644743Smarkmbehind zombie processes when writing to logged-in users. Workaround: 64744743Smarkmincrease the syslogd threshold for logging to users, or reduce the 64844743Smarkmwrapper's logging severity. 64944743Smarkm 65044743SmarkmOn some systems, the optional RFC 931 etc. client username lookups may 65144743Smarkmtrigger a kernel bug. When a client host connects to your system, and 65244743Smarkmthe RFC 931 connection from your system to that client is rejected by a 65344743Smarkmrouter, your kernel may drop all connections with that client. This is 65444743Smarkmnot a bug in the wrapper programs: complain to your vendor, and don't 65544743Smarkmenable client user name lookups until the bug has been fixed. 65644743Smarkm 65744743SmarkmReportedly, SunOS 4.1.1, Next 2.0a, ISC 3.0 with TCP 1.3, and AIX 3.2.2 65844743Smarkmand later are OK. 65944743Smarkm 66044743SmarkmSony News/OS 4.51, HP-UX 8-something and Ultrix 4.3 still have the bug. 66144743SmarkmReportedly, a fix for Ultrix is available (CXO-8919). 66244743Smarkm 66344743SmarkmThe following procedure can be used (from outside the tue.nl domain) to 66444743Smarkmfind out if your kernel has the bug. From the system under test, do: 66544743Smarkm 66644743Smarkm % ftp 131.155.70.19 66744743Smarkm 66844743SmarkmThis command attempts to make an ftp connection to our anonymous ftp 66944743Smarkmserver (ftp.win.tue.nl). When the connection has been established, run 67044743Smarkmthe following command from the same system under test, while keeping 67144743Smarkmthe ftp connection open: 67244743Smarkm 67344743Smarkm % telnet 131.155.70.19 111 67444743Smarkm 67544743SmarkmDo not forget the `111' at the end of the command. This telnet command 67644743Smarkmattempts to connect to our portmap process. The telnet command should 67744743Smarkmfail with: "host not reachable", or with a timeout error. If your ftp 67844743Smarkmconnection gets messed up, you have the bug. If the telnet command does 67944743Smarkmnot fail, please let me know a.s.a.p.! 68044743Smarkm 68144743SmarkmFor those who care, the bug is that the BSD kernel code was not careful 68244743Smarkmenough with incoming ICMP UNREACHABLE control messages (it ignored the 68344743Smarkmlocal and remote port numbers, and therefore zapped *all* connections 68444743Smarkmwith the remote system). The bug is still present in the BSD NET/1 68544743Smarkmsource release (1989) but apparently has been fixed in BSD NET/2 (1991). 68644743Smarkm 68744743Smarkm7 - Configuration and installation 68844743Smarkm---------------------------------- 68944743Smarkm 69044743Smarkm7.1 - Easy configuration and installation 69144743Smarkm----------------------------------------- 69244743Smarkm 69344743SmarkmThe "easy" recipe requires no changes to existing software or 69444743Smarkmconfiguration files. Basically, you move the daemons that you want to 69544743Smarkmprotect to a different directory and plug the resulting holes with 69644743Smarkmcopies of the wrapper programs. 69744743Smarkm 69844743SmarkmIf you don't run Ultrix, you won't need the miscd wrapper program. The 69944743Smarkmmiscd daemon implements among others the SYSTAT service, which produces 70044743Smarkmthe same output as the WHO command. 70144743Smarkm 70244743SmarkmType `make' and follow the instructions. The Makefile comes with 70344743Smarkmready-to-use templates for many common UNIX implementations (sun, 70444743Smarkmultrix, hp-ux, aix, irix,...). 70544743Smarkm 70644743SmarkmIRIX has so many bugs that it has its own README.IRIX file. 70744743Smarkm 70844743SmarkmWhen the `make' succeeds the result is five executables (six in case of 70944743SmarkmUltrix). 71044743Smarkm 71144743SmarkmYou can use the `tcpdchk' program to identify the most common problems 71244743Smarkmin your wrapper and inetd configuration files. 71344743Smarkm 71444743SmarkmWith the `tcpdmatch' program you can examine how the wrapper would 71544743Smarkmreact to specific requests for service. 71644743Smarkm 71744743SmarkmThe `safe_finger' command should be used when you implement booby 71844743Smarkmtraps: it gives better protection against nasty stuff that remote 71944743Smarkmhosts may do in response to your finger probes. 72044743Smarkm 72144743SmarkmThe `try-from' program tests the host and username lookup code. Run it 72244743Smarkmfrom a remote shell command (`rsh host /some/where/try-from') and it 72344743Smarkmshould be able to figure out from what system it is being called. 72444743Smarkm 72544743SmarkmThe tcpd program can be used to monitor the telnet, finger, ftp, exec, 72644743Smarkmrsh, rlogin, tftp, talk, comsat and other tcp or udp services that have 72744743Smarkma one-to-one mapping onto executable files. 72844743Smarkm 72944743SmarkmThe tcpd program can also be used for services that are marked as 73044743Smarkmrpc/udp in the inetd configuration file, but not for rpc/tcp services 73144743Smarkmsuch as rexd. You probably do not want to run rexd anyway. On most 73244743Smarkmsystems it is even less secure than a wildcard in /etc/hosts.equiv. 73344743Smarkm 73444743SmarkmWith System V.4-style systems, the tcpd program can also handle TLI 73544743Smarkmservices. When TCP/IP or UDP/IP is used underneath TLI, tcpd provides 73644743Smarkmthe same functions as with socket-based applications. When some other 73744743Smarkmprotocol is used underneath TLI, functionality will be limited (no 73844743Smarkmclient username lookups, weird network address formats). 73944743Smarkm 74044743SmarkmDecide which services you want to monitor. Move the corresponding 74144743Smarkmvendor-provided daemon programs to the location specified by the 74244743SmarkmREAL_DAEMON_DIR constant in the Makefile, and fill the holes with 74344743Smarkmcopies of the tcpd program. That is, one copy of (or link to) the tcpd 74444743Smarkmprogram for each service that you want to monitor. For example, to 74544743Smarkmmonitor the use of your finger service: 74644743Smarkm 74744743Smarkm # mkdir REAL_DAEMON_DIR 74844743Smarkm # mv /usr/etc/in.fingerd REAL_DAEMON_DIR 74944743Smarkm # cp tcpd /usr/etc/in.fingerd 75044743Smarkm 75144743SmarkmThe example applies to SunOS 4. With other UNIX implementations the 75244743Smarkmnetwork daemons live in /usr/libexec, /usr/sbin or in /etc, or have no 75344743Smarkm"in." prefix to their names, but you get the idea. 75444743Smarkm 75544743SmarkmFile protections: the wrapper, all files used by the wrapper, and all 75644743Smarkmdirectories in the path leading to those files, should be accessible 75744743Smarkmbut not writable for unprivileged users (mode 755 or mode 555). Do not 75844743Smarkminstall the wrapper set-uid. 75944743Smarkm 76044743SmarkmUltrix only: If you want to monitor the SYSTAT service, move the 76144743Smarkmvendor-provided miscd daemon to the location specified by the 76244743SmarkmREAL_DAEMON_DIR macro in the Makefile, and install the miscd wrapper 76344743Smarkmat the original miscd location. 76444743Smarkm 76544743SmarkmIn the absence of any access-control tables, the daemon wrappers 76644743Smarkmwill just maintain a record of network connections made to your system. 76744743Smarkm 76844743Smarkm7.2 - Advanced configuration and installation 76944743Smarkm--------------------------------------------- 77044743Smarkm 77144743SmarkmThe advanced recipe leaves your daemon executables alone, but involves 77244743Smarkmsimple modifications to the inetd configuration file. 77344743Smarkm 77444743SmarkmType `make' and follow the instructions. The Makefile comes with 77544743Smarkmready-to-use templates for many common UNIX implementations (sun, 77644743Smarkmultrix, hp-ux, aix, irix, ...). 77744743Smarkm 77844743SmarkmIRIX users should read the warnings in the README.IRIX file first. 77944743Smarkm 78044743SmarkmWhen the `make' succeeds the result is five executables (six in case of 78144743SmarkmUltrix). 78244743Smarkm 78344743SmarkmYou can use the `tcpdchk' program to identify the most common problems 78444743Smarkmin your wrapper and inetd configuration files. 78544743Smarkm 78644743SmarkmWith the `tcpdmatch' program you can examine how the wrapper would 78744743Smarkmreact to specific requests for service. 78844743Smarkm 78944743SmarkmThe `try-from' program tests the host and username lookup code. Run it 79044743Smarkmfrom a remote shell command (`rsh host /some/where/try-from') and it 79144743Smarkmshould be able to figure out from what system it is being called. 79244743Smarkm 79344743SmarkmThe `safe_finger' command should be used when you implement a booby 79444743Smarkmtrap: it gives better protection against nasty stuff that remote hosts 79544743Smarkmmay do in response to your finger probes. 79644743Smarkm 79744743SmarkmThe tcpd program can be used to monitor the telnet, finger, ftp, exec, 79844743Smarkmrsh, rlogin, tftp, talk, comsat and other tcp or udp services that have 79944743Smarkma one-to-one mapping onto executable files. 80044743Smarkm 80144743SmarkmWith System V.4-style systems, the tcpd program can also handle TLI 80244743Smarkmservices. When TCP/IP or UDP/IP is used underneath TLI, tcpd provides 80344743Smarkmthe same functions as with socket-based applications. When some other 80444743Smarkmprotocol is used underneath TLI, functionality will be limited (no 80544743Smarkmclient username lookups, weird network address formats). 80644743Smarkm 80744743SmarkmThe tcpd program can also be used for services that are marked as 80844743Smarkmrpc/udp in the inetd configuration file, but not for rpc/tcp services 80944743Smarkmsuch as rexd. You probably do not want to run rexd anyway. On most 81044743Smarkmsystems it is even less secure than a wildcard in /etc/hosts.equiv. 81144743Smarkm 81244743SmarkmInstall the tcpd command in a suitable place. Apollo UNIX users will 81344743Smarkmwant to install it under a different name because the name "tcpd" is 81444743Smarkmalready taken; a suitable name would be "frontd". 81544743Smarkm 81644743SmarkmFile protections: the wrapper, all files used by the wrapper, and all 81744743Smarkmdirectories in the path leading to those files, should be accessible 81844743Smarkmbut not writable for unprivileged users (mode 755 or mode 555). Do not 81944743Smarkminstall the wrapper set-uid. 82044743Smarkm 82144743SmarkmThen perform the following edits on the inetd configuration file 82244743Smarkm(usually /etc/inetd.conf or /etc/inet/inetd.conf): 82344743Smarkm 82444743Smarkm finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd 82544743Smarkm ^^^^^^^^^^^^^^^^^^^ 82644743Smarkmbecomes: 82744743Smarkm 82844743Smarkm finger stream tcp nowait nobody /usr/etc/tcpd in.fingerd 82944743Smarkm ^^^^^^^^^^^^^ 83044743SmarkmSend a `kill -HUP' to the inetd process to make the change effective. 83144743SmarkmSome IRIX inetd implementations require that you first disable the 83244743Smarkmfinger service (comment out the finger service and `kill -HUP' the 83344743Smarkminetd) before you can turn on the modified version. Sending a HUP 83444743Smarkmtwice seems to work just as well for IRIX 5.3, 6.0, 6.0.1 and 6.1. 83544743Smarkm 83644743SmarkmAIX note: you may have to execute the `inetimp' command after changing 83744743Smarkmthe inetd configuration file. 83844743Smarkm 83944743SmarkmThe example applies to SunOS 4. With other UNIX implementations the 84044743Smarkmnetwork daemons live in /usr/libexec, /usr/sbin, or /etc, the network 84144743Smarkmdaemons have no "in." prefix to their names, or the username field in 84244743Smarkmthe inetd configuration file may be missing. 84344743Smarkm 84444743SmarkmWhen the finger service works as expected you can perform similar 84544743Smarkmchanges for other network services. Do not forget the `kill -HUP'. 84644743Smarkm 84744743SmarkmThe miscd daemon that comes with Ultrix implements several network 84844743Smarkmservices. It decides what to do by looking at its process name. One of 84944743Smarkmthe services is systat, which is a kind of limited finger service. If 85044743Smarkmyou want to monitor the systat service, install the miscd wrapper in a 85144743Smarkmsuitable place and update the inetd configuration file: 85244743Smarkm 85344743Smarkm systat stream tcp nowait /suitable/place/miscd systatd 85444743Smarkm 85544743SmarkmUltrix 4.3 allows you to specify a user id under which the daemon will 85644743Smarkmbe executed. This feature is not documented in the manual pages. Thus, 85744743Smarkmthe example would become: 85844743Smarkm 85944743Smarkm systat stream tcp nowait nobody /suitable/place/miscd systatd 86044743Smarkm 86144743SmarkmOlder Ultrix systems still run all their network daemons as root. 86244743Smarkm 86344743SmarkmIn the absence of any access-control tables, the daemon wrappers 86444743Smarkmwill just maintain a record of network connections made to your system. 86544743Smarkm 86644743Smarkm7.3 - Daemons with arbitrary path names 86744743Smarkm--------------------------------------- 86844743Smarkm 86944743SmarkmThe above tcpd examples work fine with network daemons that live in a 87044743Smarkmcommon directory, but sometimes that is not practical. Having soft 87144743Smarkmlinks all over your file system is not a clean solution, either. 87244743Smarkm 87344743SmarkmInstead you can specify, in the inetd configuration file, an absolute 87444743Smarkmpath name for the daemon process name. For example, 87544743Smarkm 87644743Smarkm ntalk dgram udp wait root /usr/etc/tcpd /usr/local/lib/ntalkd 87744743Smarkm 87844743SmarkmWhen the daemon process name is an absolute path name, tcpd ignores the 87944743Smarkmvalue of the REAL_DAEMON_DIR constant, and uses the last path component 88044743Smarkmof the daemon process name for logging and for access control. 88144743Smarkm 88244743Smarkm7.4 - Building and testing the access control rules 88344743Smarkm--------------------------------------------------- 88444743Smarkm 88544743SmarkmIn order to support access control the wrappers must be compiled with 88644743Smarkmthe -DHOSTS_ACCESS option. The access control policy is given in the 88744743Smarkmform of two tables (default: /etc/hosts.allow and /etc/hosts.deny). 88844743SmarkmAccess control is disabled when there are no access control tables, or 88944743Smarkmwhen the tables are empty. 89044743Smarkm 89144743SmarkmIf you haven't used the wrappers before I recommend that you first run 89244743Smarkmthem a couple of days without any access control restrictions. The 89344743Smarkmlogfile records should give you an idea of the process names and of the 89444743Smarkmhost names that you will have to build into your access control rules. 89544743Smarkm 89644743SmarkmThe syntax of the access control rules is documented in the file 89744743Smarkmhosts_access.5, which is in `nroff -man' format. This is a lengthy 89844743Smarkmdocument, and no-one expects you to read it right away from beginning 89944743Smarkmto end. Instead, after reading the introductory section, skip to the 90044743Smarkmexamples at the end so that you get a general idea of the language. 90144743SmarkmThen you can appreciate the detailed reference sections near the 90244743Smarkmbeginning of the document. 90344743Smarkm 90444743SmarkmThe examples in the hosts_access.5 document (`nroff -man' format) show 90544743Smarkmtwo specific types of access control policy: 1) mostly closed (only 90644743Smarkmpermitting access from a limited number of systems) and 2) mostly open 90744743Smarkm(permitting access from everyone except a limited number of trouble 90844743Smarkmmakers). You will have to choose what model suits your situation best. 90944743SmarkmImplementing a mixed policy should not be overly difficult either. 91044743Smarkm 91144743SmarkmOptional extensions to the access control language are described in the 91244743Smarkmhosts_options.5 document (`nroff -man' format). 91344743Smarkm 91444743SmarkmThe `tcpdchk' program examines all rules in your access control files 91544743Smarkmand reports any problems it can find. `tcpdchk -v' writes to standard 91644743Smarkmoutput a pretty-printed list of all rules. `tcpdchk -d' examines the 91744743Smarkmhosts.access and hosts.allow files in the current directory. This 91844743Smarkmprogram is described in the tcpdchk.8 document (`nroff -man' format). 91944743Smarkm 92044743SmarkmThe `tcpdmatch' command can be used to try out your local access 92144743Smarkmcontrol files. The command syntax is: 92244743Smarkm 92344743Smarkm tcpdmatch process_name hostname (e.g.: tcpdmatch in.tftpd localhost) 92444743Smarkm 92544743Smarkm tcpdmatch process_name address (e.g.: tcpdmatch in.tftpd 127.0.0.1) 92644743Smarkm 92744743SmarkmThis way you can simulate what decisions will be made, and what actions 92844743Smarkmwill be taken, when hosts connect to your own system. The program is 92944743Smarkmdescribed in the tcpdmatch.8 document (`nroff -man' format). 93044743Smarkm 93144743SmarkmNote 1: `tcpdmatch -d' will look for hosts.{allow,deny} tables in the 93244743Smarkmcurrent working directory. This is useful for testing new rules without 93344743Smarkmbothering your users. 93444743Smarkm 93544743SmarkmNote 2: you cannot use the `tcpdmatch' command to simulate what happens 93644743Smarkmwhen the local system connects to other hosts. 93744743Smarkm 93844743SmarkmIn order to find out what process name to use, just use the service and 93944743Smarkmwatch the process name that shows up in the logfile. Alternatively, 94044743Smarkmyou can look up the name from the inetd configuration file. Coming back 94144743Smarkmto the tftp example in the tutorial section above: 94244743Smarkm 94344743Smarkm tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot 94444743Smarkm 94544743SmarkmThis entry causes the inetd to run the wrapper program (tcpd) with a 94644743Smarkmprocess name `in.tftpd'. This is the name that the wrapper will use 94744743Smarkmwhen scanning the access control tables. Therefore, `in.tftpd' is the 94844743Smarkmprocess name that should be given to the `tcpdmatch' command. On your 94944743Smarkmsystem the actual inetd.conf entry may differ (tftpd instead of 95044743Smarkmin.tftpd, and no `root' field), but you get the idea. 95144743Smarkm 95244743SmarkmWhen you specify a host name, the `tcpdmatch' program will use both the 95344743Smarkmhost name and address. This way you can simulate the most common case 95444743Smarkmwhere the wrappers know both the host address and the host name. The 95544743Smarkm`tcpdmatch' program will iterate over all addresses that it can find 95644743Smarkmfor the given host name. 95744743Smarkm 95844743SmarkmWhen you specify a host address instead of a host name, the `tcpdmatch' 95944743Smarkmprogram will pretend that the host name is unknown, so that you can 96044743Smarkmsimulate what happens when the wrapper is unable to look up the client 96144743Smarkmhost name. 96244743Smarkm 96344743Smarkm7.5 - Other applications 96444743Smarkm------------------------ 96544743Smarkm 96644743SmarkmThe access control routines can easily be integrated with other 96744743Smarkmprograms. The hosts_access.3 manual page (`nroff -man' format) 96844743Smarkmdescribes the external interface of the libwrap.a library. 96944743Smarkm 97044743SmarkmThe tcpd program can even be used to control access to the mail 97144743Smarkmservice. This can be useful when you suspect that someone is trying 97244743Smarkmout some obscure sendmail bug, or when a remote site is misconfigured 97344743Smarkmand keeps hammering your mail daemon. 97444743Smarkm 97544743SmarkmIn that case, sendmail should not be run as a stand-alone network 97644743Smarkmlistener, but it should be registered in the inetd configuration file. 97744743SmarkmFor example: 97844743Smarkm 97944743Smarkm smtp stream tcp nowait root /usr/etc/tcpd /usr/lib/sendmail -bs 98044743Smarkm 98144743SmarkmYou will still need to run one sendmail background process to handle 98244743Smarkmqueued-up outgoing mail. A command like: 98344743Smarkm 98444743Smarkm /usr/lib/sendmail -q15m 98544743Smarkm 98644743Smarkm(no `-bd' flag) should take care of that. You cannot really prevent 98744743Smarkmpeople from posting forged mail this way, because there are many 98844743Smarkmunprotected smtp daemons on the network. 98944743Smarkm 99044743Smarkm8 - Acknowledgements 99144743Smarkm-------------------- 99244743Smarkm 99344743SmarkmMany people contributed to the evolution of the programs, by asking 99444743Smarkminspiring questions, by suggesting features or bugfixes, or by 99544743Smarkmsubmitting source code. Nevertheless, all mistakes and bugs in the 99644743Smarkmwrappers are my own. 99744743Smarkm 99844743SmarkmThanks to Brendan Kehoe (cs.widener.edu), Heimir Sverrisson (hafro.is) 99944743Smarkmand Dan Bernstein (kramden.acf.nyu.edu) for feedback on an early 100044743Smarkmrelease of this product. The host name/address check was suggested by 100144743SmarkmJohn Kimball (src.honeywell.com). Apollo's UNIX environment has some 100244743Smarkmpeculiar quirks: Willem-Jan Withagen (eb.ele.tue.nl), Pieter 100344743SmarkmSchoenmakers (es.ele.tue.nl) and Charles S. Fuller (wccs.psc.edu) 100444743Smarkmprovided assistance. Hal R. Brand (addvax.llnl.gov) told me how to 100544743Smarkmget the client IP address in case of datagram-oriented services, and 100644743Smarkmsuggested the optional shell command feature. Shabbir Safdar 100744743Smarkm(mentor.cc.purdue.edu) provided a first version of a much-needed manual 100844743Smarkmpage. Granville Boman Goza, IV (sei.cmu.edu) suggested to use the 100944743Smarkmclient IP address even when the host name is available. Casper H.S. 101044743SmarkmDik (fwi.uva.nl) provided additional insight into DNS spoofing 101144743Smarkmtechniques. The bogus daemon feature was inspired by code from Andrew 101244743SmarkmMacpherson (BNR Europe Ltd). Steve Bellovin (research.att.com) 101344743Smarkmconfirmed some of my suspicions about the darker sides of TCP/IP 101444743Smarkminsecurity. Risks of automated fingers were pointed out by Borja Marcos 101544743Smarkm(we.lc.ehu.es). Brad Plecs (jhuspo.ca.jhu.edu) was kind enough to try 101644743Smarkmmy early TLI code and to work out how DG/UX differs from Solaris. 101744743Smarkm 101844743SmarkmJohn P. Rouillard (cs.umb.edu) deserves special mention for his 101944743Smarkmpersistent, but constructive, nagging about wrong or missing things, 102044743Smarkmand for trying out and discussing embryonic code or ideas. 102144743Smarkm 102244743SmarkmLast but not least, Howard Chu (hanauma.jpl.nasa.gov), Darren Reed 102344743Smarkm(coombs.anu.edu.au), Icarus Sparry (gdr.bath.ac.uk), Scott Schwartz 102444743Smarkm(cs.psu.edu), John A. Kunze (violet.berkeley.edu), Daniel Len Schales 102544743Smarkm(engr.latech.edu), Chris Turbeville (cse.uta.edu), Paul Kranenburg 102644743Smarkm(cs.few.eur.nl), Marc Boucher (cam.org), Dave Mitchell 102744743Smarkm(dcs.shef.ac.uk), Andrew Maffei, Adrian van Bloois, Rop Gonggrijp, John 102844743SmarkmC. Wingenbach, Everett F. Batey and many, many others provided fixes, 102944743Smarkmcode fragments, or ideas for improvements. 103044743Smarkm 103144743Smarkm Wietse Venema (wietse@wzv.win.tue.nl) 103244743Smarkm Department of Mathematics and Computing Science 103344743Smarkm Eindhoven University of Technology 103444743Smarkm P.O. Box 513 103544743Smarkm 5600 MB Eindhoven 103644743Smarkm The Netherlands 103744743Smarkm 103844743Smarkm Currently visiting IBM T.J. Watson Research, Hawthorne NY, USA. 1039