1*0Sstevel@tonic-gate@(#) README 1.30 97/03/21 19:27:21 2*0Sstevel@tonic-gate 3*0Sstevel@tonic-gateThis is the 7.6 version of the TCP/IP daemon wrapper package. 4*0Sstevel@tonic-gate 5*0Sstevel@tonic-gateThank you for using this program. If you like it, send me a postcard. 6*0Sstevel@tonic-gateMy postal address is at the bottom of this file. 7*0Sstevel@tonic-gate 8*0Sstevel@tonic-gateRead the BLURB file for a brief summary of what is new. The CHANGES 9*0Sstevel@tonic-gatefile gives a complete account of differences with respect to previous 10*0Sstevel@tonic-gatereleases. 11*0Sstevel@tonic-gate 12*0Sstevel@tonic-gateAnnouncements of new releases of this software are posted to Usenet 13*0Sstevel@tonic-gate(comp.security.unix, comp.unix.admin), to the cert-tools mailing list, 14*0Sstevel@tonic-gateand to a dedicated mailing list. You can subscribe to the dedicated 15*0Sstevel@tonic-gatemailing list by sending an email message to majordomo@wzv.win.tue.nl 16*0Sstevel@tonic-gatewith in the body (not subject): subscribe tcp-wrappers-announce. 17*0Sstevel@tonic-gate 18*0Sstevel@tonic-gateTable of contents 19*0Sstevel@tonic-gate----------------- 20*0Sstevel@tonic-gate 21*0Sstevel@tonic-gate 1 - Introduction 22*0Sstevel@tonic-gate 2 - Disclaimer 23*0Sstevel@tonic-gate 3 - Tutorials 24*0Sstevel@tonic-gate 3.1 - How it works 25*0Sstevel@tonic-gate 3.2 - Where the logging information goes 26*0Sstevel@tonic-gate 4 - Features 27*0Sstevel@tonic-gate 4.1 - Access control 28*0Sstevel@tonic-gate 4.2 - Host name spoofing 29*0Sstevel@tonic-gate 4.3 - Host address spoofing 30*0Sstevel@tonic-gate 4.4 - Client username lookups 31*0Sstevel@tonic-gate 4.5 - Language extensions 32*0Sstevel@tonic-gate 4.6 - Multiple ftp/gopher/www archives on one host 33*0Sstevel@tonic-gate 4.7 - Banner messages 34*0Sstevel@tonic-gate 4.8 - Sequence number guessing 35*0Sstevel@tonic-gate 5 - Other works 36*0Sstevel@tonic-gate 5.1 - Related documents 37*0Sstevel@tonic-gate 5.2 - Related software 38*0Sstevel@tonic-gate 6 - Limitations 39*0Sstevel@tonic-gate 6.1 - Known wrapper limitations 40*0Sstevel@tonic-gate 6.2 - Known system software bugs 41*0Sstevel@tonic-gate 7 - Configuration and installation 42*0Sstevel@tonic-gate 7.1 - Easy configuration and installation 43*0Sstevel@tonic-gate 7.2 - Advanced configuration and installation 44*0Sstevel@tonic-gate 7.3 - Daemons with arbitrary path names 45*0Sstevel@tonic-gate 7.4 - Building and testing the access control rules 46*0Sstevel@tonic-gate 7.5 - Other applications 47*0Sstevel@tonic-gate 8 - Acknowledgements 48*0Sstevel@tonic-gate 49*0Sstevel@tonic-gate1 - Introduction 50*0Sstevel@tonic-gate---------------- 51*0Sstevel@tonic-gate 52*0Sstevel@tonic-gateWith this package you can monitor and filter incoming requests for the 53*0Sstevel@tonic-gateSYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other 54*0Sstevel@tonic-gatenetwork services. 55*0Sstevel@tonic-gate 56*0Sstevel@tonic-gateIt supports both 4.3BSD-style sockets and System V.4-style TLI. Praise 57*0Sstevel@tonic-gateyourself lucky if you don't know what that means. 58*0Sstevel@tonic-gate 59*0Sstevel@tonic-gateThe package provides tiny daemon wrapper programs that can be installed 60*0Sstevel@tonic-gatewithout any changes to existing software or to existing configuration 61*0Sstevel@tonic-gatefiles. The wrappers report the name of the client host and of the 62*0Sstevel@tonic-gaterequested service; the wrappers do not exchange information with the 63*0Sstevel@tonic-gateclient or server applications, and impose no overhead on the actual 64*0Sstevel@tonic-gateconversation between the client and server applications. 65*0Sstevel@tonic-gate 66*0Sstevel@tonic-gateOptional features are: access control to restrict what systems can 67*0Sstevel@tonic-gateconnect to what network daemons; client user name lookups with the RFC 68*0Sstevel@tonic-gate931 etc. protocol; additional protection against hosts that pretend to 69*0Sstevel@tonic-gatehave someone elses host name; additional protection against hosts that 70*0Sstevel@tonic-gatepretend to have someone elses host address. 71*0Sstevel@tonic-gate 72*0Sstevel@tonic-gateThe programs are very portable. Build procedures are provided for many 73*0Sstevel@tonic-gatecommon (and not so common) environments, and guidelines are provided in 74*0Sstevel@tonic-gatecase your environment is not among them. 75*0Sstevel@tonic-gate 76*0Sstevel@tonic-gateRequirements are that network daemons are spawned by a super server 77*0Sstevel@tonic-gatesuch as the inetd; a 4.3BSD-style socket programming interface and/or 78*0Sstevel@tonic-gateSystem V.4-style TLI programming interface; and the availability of a 79*0Sstevel@tonic-gatesyslog(3) library and of a syslogd(8) daemon. The wrappers should run 80*0Sstevel@tonic-gatewithout modification on any system that satisfies these requirements. 81*0Sstevel@tonic-gateWorkarounds have been implemented for several common bugs in systems 82*0Sstevel@tonic-gatesoftware. 83*0Sstevel@tonic-gate 84*0Sstevel@tonic-gateWhat to do if this is your first encounter with the wrapper programs: 85*0Sstevel@tonic-gate1) read the tutorial sections for an introduction to the relevant 86*0Sstevel@tonic-gateconcepts and terminology; 2) glance over the security feature sections 87*0Sstevel@tonic-gatein this document; 3) follow the installation instructions (easy or 88*0Sstevel@tonic-gateadvanced). I recommend that you first use the default security feature 89*0Sstevel@tonic-gatesettings. Run the wrappers for a few days to become familiar with 90*0Sstevel@tonic-gatetheir logs, before doing anything drastic such as cutting off access or 91*0Sstevel@tonic-gateinstalling booby traps. 92*0Sstevel@tonic-gate 93*0Sstevel@tonic-gate2 - Disclaimer 94*0Sstevel@tonic-gate-------------- 95*0Sstevel@tonic-gate 96*0Sstevel@tonic-gateThe wrapper programs rely on source address information obtained from 97*0Sstevel@tonic-gatenetwork packets. This information is provided by the client host. It is 98*0Sstevel@tonic-gatenot 100 percent reliable, although the wrappers do their best to expose 99*0Sstevel@tonic-gateforgeries. 100*0Sstevel@tonic-gate 101*0Sstevel@tonic-gateIn the absence of cryptographic protection of message contents, and of 102*0Sstevel@tonic-gatecryptographic authentication of message originators, all data from the 103*0Sstevel@tonic-gatenetwork should be treated with sound scepticism. 104*0Sstevel@tonic-gate 105*0Sstevel@tonic-gateTHIS RESTRICTION IS BY NO MEANS SPECIFIC TO THE TCP/IP PROTOCOLS. 106*0Sstevel@tonic-gate 107*0Sstevel@tonic-gate3 - Tutorials 108*0Sstevel@tonic-gate------------- 109*0Sstevel@tonic-gate 110*0Sstevel@tonic-gateThe tutorial sections give a gentle introduction to the operation of 111*0Sstevel@tonic-gatethe wrapper programs, and introduce some of the terminology that is 112*0Sstevel@tonic-gateused in the remainder of the document: client, server, the inetd and 113*0Sstevel@tonic-gatesyslogd daemons, and their configuration files. 114*0Sstevel@tonic-gate 115*0Sstevel@tonic-gate3.1 - How it works 116*0Sstevel@tonic-gate------------------ 117*0Sstevel@tonic-gate 118*0Sstevel@tonic-gateAlmost every application of the TCP/IP protocols is based on a client- 119*0Sstevel@tonic-gateserver model. For example, when a user invokes the telnet command to 120*0Sstevel@tonic-gateconnect to one of your systems, a telnet server process is executed on 121*0Sstevel@tonic-gatethe target host. The telnet server process connects the user to a login 122*0Sstevel@tonic-gateprocess. A few examples of client and server programs are shown in the 123*0Sstevel@tonic-gatetable below: 124*0Sstevel@tonic-gate 125*0Sstevel@tonic-gate client server application 126*0Sstevel@tonic-gate -------------------------------- 127*0Sstevel@tonic-gate telnet telnetd remote login 128*0Sstevel@tonic-gate ftp ftpd file transfer 129*0Sstevel@tonic-gate finger fingerd show users 130*0Sstevel@tonic-gate 131*0Sstevel@tonic-gateThe usual approach is to run one single daemon process that waits for 132*0Sstevel@tonic-gateall kinds of incoming network connections. Whenever a connection is 133*0Sstevel@tonic-gateestablished, this daemon (usually called inetd) runs the appropriate 134*0Sstevel@tonic-gateserver program and goes back to sleep, waiting for other connections. 135*0Sstevel@tonic-gate 136*0Sstevel@tonic-gateThe wrapper programs rely on a simple, but powerful mechanism. Instead 137*0Sstevel@tonic-gateof directly running the desired server program, the inetd is tricked 138*0Sstevel@tonic-gateinto running a small wrapper program. The wrapper logs the client host 139*0Sstevel@tonic-gatename or address and performs some additional checks. When all is well, 140*0Sstevel@tonic-gatethe wrapper executes the desired server program and goes away. 141*0Sstevel@tonic-gate 142*0Sstevel@tonic-gateThe wrapper programs have no interaction with the client user (or with 143*0Sstevel@tonic-gatethe client process). Nor do the wrappers interact with the server 144*0Sstevel@tonic-gateapplication. This has two major advantages: 1) the wrappers are 145*0Sstevel@tonic-gateapplication-independent, so that the same program can protect many 146*0Sstevel@tonic-gatekinds of network services; 2) no interaction also means that the 147*0Sstevel@tonic-gatewrappers are invisible from outside (at least for authorized users). 148*0Sstevel@tonic-gate 149*0Sstevel@tonic-gateAnother important property is that the wrapper programs are active only 150*0Sstevel@tonic-gatewhen the initial contact between client and server is established. Once 151*0Sstevel@tonic-gatea wrapper has done its work there is no overhead on the client-server 152*0Sstevel@tonic-gateconversation. 153*0Sstevel@tonic-gate 154*0Sstevel@tonic-gateThe simple mechanism has one major drawback: the wrappers go away after 155*0Sstevel@tonic-gatethe initial contact between client and server processes, so the 156*0Sstevel@tonic-gatewrappers are of little use with network daemons that service more than 157*0Sstevel@tonic-gateone client. The wrappers would only see the first client attempt to 158*0Sstevel@tonic-gatecontact such a server. The NFS mount daemon is a typical example of a 159*0Sstevel@tonic-gatedaemon that services requests from multiple clients. See the section on 160*0Sstevel@tonic-gaterelated software for ways to deal with such server programs. 161*0Sstevel@tonic-gate 162*0Sstevel@tonic-gateThere are two ways to use the wrapper programs: 163*0Sstevel@tonic-gate 164*0Sstevel@tonic-gate1) The easy way: move network daemons to some other directory and fill 165*0Sstevel@tonic-gate the resulting holes with copies of the wrapper programs. This 166*0Sstevel@tonic-gate approach involves no changes to system configuration files, so there 167*0Sstevel@tonic-gate is very little risk of breaking things. 168*0Sstevel@tonic-gate 169*0Sstevel@tonic-gate2) The advanced way: leave the network daemons alone and modify the 170*0Sstevel@tonic-gate inetd configuration file. For example, an entry such as: 171*0Sstevel@tonic-gate 172*0Sstevel@tonic-gate tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot 173*0Sstevel@tonic-gate 174*0Sstevel@tonic-gate When a tftp request arrives, inetd will run the wrapper program 175*0Sstevel@tonic-gate (tcpd) with a process name `in.tftpd'. This is the name that the 176*0Sstevel@tonic-gate wrapper will use when logging the request and when scanning the 177*0Sstevel@tonic-gate optional access control tables. `in.tftpd' is also the name of the 178*0Sstevel@tonic-gate server program that the wrapper will attempt to run when all is 179*0Sstevel@tonic-gate well. Any arguments (`-s /tftpboot' in this particular example) are 180*0Sstevel@tonic-gate transparently passed on to the server program. 181*0Sstevel@tonic-gate 182*0Sstevel@tonic-gateFor an account of the history of the wrapper programs, with real-life 183*0Sstevel@tonic-gateexamples, see the section below on related documents. 184*0Sstevel@tonic-gate 185*0Sstevel@tonic-gate3.2 - Where the logging information goes 186*0Sstevel@tonic-gate---------------------------------------- 187*0Sstevel@tonic-gate 188*0Sstevel@tonic-gateThe wrapper programs send their logging information to the syslog 189*0Sstevel@tonic-gatedaemon (syslogd). The disposition of the wrapper logs is determined by 190*0Sstevel@tonic-gatethe syslog configuration file (usually /etc/syslog.conf). Messages are 191*0Sstevel@tonic-gatewritten to files, to the console, or are forwarded to a @loghost. Some 192*0Sstevel@tonic-gatesyslogd versions can even forward messages down a |pipeline. 193*0Sstevel@tonic-gate 194*0Sstevel@tonic-gateOlder syslog implementations (still found on Ultrix systems) only 195*0Sstevel@tonic-gatesupport priority levels ranging from 9 (debug-level messages) to 0 196*0Sstevel@tonic-gate(alerts). All logging information of the specified priority level or 197*0Sstevel@tonic-gatemore urgent is written to the same destination. In the syslog.conf 198*0Sstevel@tonic-gatefile, priority levels are specified in numerical form. For example, 199*0Sstevel@tonic-gate 200*0Sstevel@tonic-gate 8/usr/spool/mqueue/syslog 201*0Sstevel@tonic-gate 202*0Sstevel@tonic-gatecauses all messages with priority 8 (informational messages), and 203*0Sstevel@tonic-gateanything that is more urgent, to be appended to the file 204*0Sstevel@tonic-gate/usr/spool/mqueue/syslog. 205*0Sstevel@tonic-gate 206*0Sstevel@tonic-gateNewer syslog implementations support message classes in addition to 207*0Sstevel@tonic-gatepriority levels. Examples of message classes are: mail, daemon, auth 208*0Sstevel@tonic-gateand news. In the syslog.conf file, priority levels are specified with 209*0Sstevel@tonic-gatesymbolic names: debug, info, notice, ..., emerg. For example, 210*0Sstevel@tonic-gate 211*0Sstevel@tonic-gate mail.debug /var/log/syslog 212*0Sstevel@tonic-gate 213*0Sstevel@tonic-gatecauses all messages of class mail with priority debug (or more urgent) 214*0Sstevel@tonic-gateto be appended to the /var/log/syslog file. 215*0Sstevel@tonic-gate 216*0Sstevel@tonic-gateBy default, the wrapper logs go to the same place as the transaction 217*0Sstevel@tonic-gatelogs of the sendmail daemon. The disposition can be changed by editing 218*0Sstevel@tonic-gatethe Makefile and/or the syslog.conf file. Send a `kill -HUP' to the 219*0Sstevel@tonic-gatesyslogd after changing its configuration file. Remember that syslogd, 220*0Sstevel@tonic-gatejust like sendmail, insists on one or more TABs between the left-hand 221*0Sstevel@tonic-gateside and the right-hand side expressions in its configuration file. 222*0Sstevel@tonic-gate 223*0Sstevel@tonic-gateSolaris 2.x note: the syslog daemon depends on the m4 macro processor. 224*0Sstevel@tonic-gateThe m4 program is installed as part of the software developer packages. 225*0Sstevel@tonic-gate 226*0Sstevel@tonic-gateTrouble shooting note: when the syslogging does not work as expected, 227*0Sstevel@tonic-gaterun the program by hand (`syslogd -d') and see what really happens. 228*0Sstevel@tonic-gate 229*0Sstevel@tonic-gate4 - Features 230*0Sstevel@tonic-gate------------ 231*0Sstevel@tonic-gate 232*0Sstevel@tonic-gate4.1 - Access control 233*0Sstevel@tonic-gate-------------------- 234*0Sstevel@tonic-gate 235*0Sstevel@tonic-gateWhen compiled with -DHOSTS_ACCESS, the wrapper programs support a 236*0Sstevel@tonic-gatesimple form of access control. Access can be controlled per host, per 237*0Sstevel@tonic-gateservice, or combinations thereof. The software provides hooks for the 238*0Sstevel@tonic-gateexecution of shell commands when an access control rule fires; this 239*0Sstevel@tonic-gatefeature may be used to install "booby traps". For details, see the 240*0Sstevel@tonic-gatehosts_access.5 manual page, which is in `nroff -man' format. A later 241*0Sstevel@tonic-gatesection describes how you can test your access control rules. 242*0Sstevel@tonic-gate 243*0Sstevel@tonic-gateAccess control can also be used to connect clients to the "right" 244*0Sstevel@tonic-gateservice. What is right may depend on the requested service, the origin 245*0Sstevel@tonic-gateof the request, and what host address the client connects to. Examples: 246*0Sstevel@tonic-gate 247*0Sstevel@tonic-gate(1) A gopher or www database speaks native language when contacted from 248*0Sstevel@tonic-gate within the country, otherwise it speaks English. 249*0Sstevel@tonic-gate 250*0Sstevel@tonic-gate(2) A service provider offers different ftp, gopher or www services 251*0Sstevel@tonic-gate with different internet hostnames from one host (section 4.6). 252*0Sstevel@tonic-gate 253*0Sstevel@tonic-gateAccess control is enabled by default. It can be turned off by editing 254*0Sstevel@tonic-gatethe Makefile, or by providing no access control tables. The install 255*0Sstevel@tonic-gateinstructions below describe the Makefile editing process. 256*0Sstevel@tonic-gate 257*0Sstevel@tonic-gateThe hosts_options.5 manual page (`nroff -man' format) documents an 258*0Sstevel@tonic-gateextended version of the access control language. The extensions are 259*0Sstevel@tonic-gatedisabled by default. See the section below on language extensions. 260*0Sstevel@tonic-gate 261*0Sstevel@tonic-gateLater System V implementations provide the Transport Level Interface 262*0Sstevel@tonic-gate(TLI), a network programming interface that performs functions similar 263*0Sstevel@tonic-gateto the Berkeley socket programming interface. Like Berkeley sockets, 264*0Sstevel@tonic-gateTLI was designed to cover multiple protocols, not just Internet. 265*0Sstevel@tonic-gate 266*0Sstevel@tonic-gateWhen the wrapper discovers that the TLI interface sits on top of a 267*0Sstevel@tonic-gateTCP/IP or UDP/IP conversation it uses this knowledge to provide the 268*0Sstevel@tonic-gatesame functions as with traditional socket-based applications. When 269*0Sstevel@tonic-gatesome other protocol is used underneath TLI, the host address will be 270*0Sstevel@tonic-gatesome universal magic cookie that may not even be usable for access 271*0Sstevel@tonic-gatecontrol purposes. 272*0Sstevel@tonic-gate 273*0Sstevel@tonic-gate4.2 - Host name spoofing 274*0Sstevel@tonic-gate------------------------ 275*0Sstevel@tonic-gate 276*0Sstevel@tonic-gateWith some network applications, such as RSH or RLOGIN, the client host 277*0Sstevel@tonic-gatename plays an important role in the authentication process. Host name 278*0Sstevel@tonic-gateinformation can be reliable when lookups are done from a _local_ hosts 279*0Sstevel@tonic-gatetable, provided that the client IP address can be trusted. 280*0Sstevel@tonic-gate 281*0Sstevel@tonic-gateWith _distributed_ name services, authentication schemes that rely on 282*0Sstevel@tonic-gatehost names become more problematic. The security of your system now may 283*0Sstevel@tonic-gatedepend on some far-away DNS (domain name server) outside your own 284*0Sstevel@tonic-gatecontrol. 285*0Sstevel@tonic-gate 286*0Sstevel@tonic-gateThe wrapper programs verify the client host name that is returned by 287*0Sstevel@tonic-gatethe address->name DNS server, by asking for a second opinion. To this 288*0Sstevel@tonic-gateend, the programs look at the name and addresses that are returned by 289*0Sstevel@tonic-gatethe name->address DNS server, which may be an entirely different host. 290*0Sstevel@tonic-gate 291*0Sstevel@tonic-gateIf any name or address discrepancies are found, or if the second DNS 292*0Sstevel@tonic-gateopinion is not available, the wrappers assume that one of the two name 293*0Sstevel@tonic-gateservers is lying, and assume that the client host pretends to have 294*0Sstevel@tonic-gatesomeone elses host name. 295*0Sstevel@tonic-gate 296*0Sstevel@tonic-gateWhen compiled with -DPARANOID, the wrappers will always attempt to look 297*0Sstevel@tonic-gateup and double check the client host name, and will always refuse 298*0Sstevel@tonic-gateservice in case of a host name/address discrepancy. This is a 299*0Sstevel@tonic-gatereasonable policy for most systems. 300*0Sstevel@tonic-gate 301*0Sstevel@tonic-gateWhen compiled without -DPARANOID, the wrappers by default still perform 302*0Sstevel@tonic-gatehostname lookup. You can match hosts with a name/address discrepancy 303*0Sstevel@tonic-gatewith the PARANOID wildcard and decide whether or not to grant service. 304*0Sstevel@tonic-gate 305*0Sstevel@tonic-gateAutomatic hostname verification is enabled by default. Automatic 306*0Sstevel@tonic-gatehostname lookups and verification can be turned off by editing the 307*0Sstevel@tonic-gateMakefile. The configuration and installation section below describes 308*0Sstevel@tonic-gatethe Makefile editing process. 309*0Sstevel@tonic-gate 310*0Sstevel@tonic-gate4.3 - Host address spoofing 311*0Sstevel@tonic-gate--------------------------- 312*0Sstevel@tonic-gate 313*0Sstevel@tonic-gateWhile host name spoofing can be found out by asking a second opinion, 314*0Sstevel@tonic-gateit is much harder to find out that a host claims to have someone elses 315*0Sstevel@tonic-gatenetwork address. And since host names are deduced from network 316*0Sstevel@tonic-gateaddresses, address spoofing is at least as effective as name spoofing. 317*0Sstevel@tonic-gate 318*0Sstevel@tonic-gateThe wrapper programs can give additional protection against hosts that 319*0Sstevel@tonic-gateclaim to have an address that lies outside their own network. For 320*0Sstevel@tonic-gateexample, some far-away host that claims to be a trusted host within 321*0Sstevel@tonic-gateyour own network. Such things are possible even while the impersonated 322*0Sstevel@tonic-gatesystem is up and running. 323*0Sstevel@tonic-gate 324*0Sstevel@tonic-gateThis additional protection is not an invention of my own; it has been 325*0Sstevel@tonic-gatepresent for at least five years in the BSD rsh and rlogin daemons. 326*0Sstevel@tonic-gateUnfortunately, that feature was added *after* 4.3 BSD came out, so that 327*0Sstevel@tonic-gatevery few, if any, UNIX vendors have adopted it. Our site, and many 328*0Sstevel@tonic-gateother ones, has been running these enhanced daemons for several years, 329*0Sstevel@tonic-gateand without any ill effects. 330*0Sstevel@tonic-gate 331*0Sstevel@tonic-gateWhen the wrapper programs are compiled with -DKILL_IP_OPTIONS, the 332*0Sstevel@tonic-gateprograms refuse to service TCP connections with IP source routing 333*0Sstevel@tonic-gateoptions. -DKILL_IP_OPTIONS is not needed on modern UNIX systems 334*0Sstevel@tonic-gatethat can stop source-routed traffic in the kernel. Examples are 335*0Sstevel@tonic-gate4.4BSD derivatives, Solaris 2.x, and Linux. See your system manuals 336*0Sstevel@tonic-gatefor details. 337*0Sstevel@tonic-gate 338*0Sstevel@tonic-gateIf you are going to use this feature on SunOS 4.1.x you should apply 339*0Sstevel@tonic-gatepatch 100804-03+ or 101790-something depending on your SunOS version. 340*0Sstevel@tonic-gateOtherwise you may experience "BAD TRAP" and "Data fault" panics when 341*0Sstevel@tonic-gatethe getsockopt() system call is executed after a TCP RESET has been 342*0Sstevel@tonic-gatereceived. This is a kernel bug, it is not the fault of the wrappers. 343*0Sstevel@tonic-gate 344*0Sstevel@tonic-gateThe feature is disabled by default. It can be turned on by editing the 345*0Sstevel@tonic-gateMakefile. The configuration and installation section below describes 346*0Sstevel@tonic-gatethe Makefile editing process. 347*0Sstevel@tonic-gate 348*0Sstevel@tonic-gateUDP services do not benefit from this additional protection. With UDP, 349*0Sstevel@tonic-gateall you can be certain of is the network packet's destination address. 350*0Sstevel@tonic-gate 351*0Sstevel@tonic-gate4.4 - Client username lookups 352*0Sstevel@tonic-gate----------------------------- 353*0Sstevel@tonic-gate 354*0Sstevel@tonic-gateThe protocol proposed in RFC 931 provides a means to obtain the client 355*0Sstevel@tonic-gateuser name from the client host. The requirement is that the client 356*0Sstevel@tonic-gatehost runs an RFC 931-compliant daemon. The information provided by such 357*0Sstevel@tonic-gatea daemon is not intended to be used for authentication purposes, but it 358*0Sstevel@tonic-gatecan provide additional information about the owner of a TCP connection. 359*0Sstevel@tonic-gate 360*0Sstevel@tonic-gateThe RFC 931 protocol has diverged into different directions (IDENT, 361*0Sstevel@tonic-gateTAP, RFC 1413). To add to the confusion, they all use the same network 362*0Sstevel@tonic-gateport. The daemon wrappers implement a common subset of the protocols. 363*0Sstevel@tonic-gate 364*0Sstevel@tonic-gateThere are some limitations: the number of hosts that run an RFC 931 (or 365*0Sstevel@tonic-gatecompatible) daemon is limited (but growing); client user name lookups 366*0Sstevel@tonic-gatedo not work for datagram (UDP) services. More seriously, client user 367*0Sstevel@tonic-gatename lookups can cause noticeable delays with connections from non-UNIX 368*0Sstevel@tonic-gatePCs. Recent PC software seem to have fixed this (for example NCSA 369*0Sstevel@tonic-gatetelnet). The wrappers use a 10-second timeout for RFC931 lookups, to 370*0Sstevel@tonic-gateaccommodate slow networks and slow hosts. 371*0Sstevel@tonic-gate 372*0Sstevel@tonic-gateBy default, the wrappers will do username lookup only when the access 373*0Sstevel@tonic-gatecontrol rules require them to do so (via user@host client patterns, see 374*0Sstevel@tonic-gatethe hosts_access.5 manual page) or when the username is needed for 375*0Sstevel@tonic-gate%<letter> expansions. 376*0Sstevel@tonic-gate 377*0Sstevel@tonic-gateYou can configure the wrappers to always perform client username 378*0Sstevel@tonic-gatelookups, by editing the Makefile. The client username lookup timeout 379*0Sstevel@tonic-gateperiod (10 seconds default) can be changed by editing the Makefile. The 380*0Sstevel@tonic-gateinstallation sections below describe the Makefile editing process. 381*0Sstevel@tonic-gate 382*0Sstevel@tonic-gateOn System V with TLI-based network services, client username lookups 383*0Sstevel@tonic-gatewill be possible only when the underlying network protocol is TCP/IP. 384*0Sstevel@tonic-gate 385*0Sstevel@tonic-gate4.5 - Language extensions 386*0Sstevel@tonic-gate------------------------- 387*0Sstevel@tonic-gate 388*0Sstevel@tonic-gateThe wrappers sport only a limited number of features. This is for a 389*0Sstevel@tonic-gategood reason: programs that run at high privilege levels must be easy to 390*0Sstevel@tonic-gateverify. And the smaller a program, the easier to verify. There is, 391*0Sstevel@tonic-gatehowever, a provision to add features. 392*0Sstevel@tonic-gate 393*0Sstevel@tonic-gateThe options.c module provides a framework for language extensions. 394*0Sstevel@tonic-gateQuite a few extensions have already been implemented; they are 395*0Sstevel@tonic-gatedocumented in the hosts_options.5 document, which is in `nroff -man' 396*0Sstevel@tonic-gateformat. Examples: changing the severity level at which a request for 397*0Sstevel@tonic-gateservice is logged; "allow" and "deny" keywords; running a customized 398*0Sstevel@tonic-gateserver instead of the standard one; many others. 399*0Sstevel@tonic-gate 400*0Sstevel@tonic-gateThe language extensions are not enabled by default because they 401*0Sstevel@tonic-gateintroduce an incompatible change to the access control language 402*0Sstevel@tonic-gatesyntax. Instructions to enable the extensions are given in the 403*0Sstevel@tonic-gateMakefile. 404*0Sstevel@tonic-gate 405*0Sstevel@tonic-gate4.6 - Multiple ftp/gopher/www archives on one host 406*0Sstevel@tonic-gate-------------------------------------------------- 407*0Sstevel@tonic-gate 408*0Sstevel@tonic-gateImagine one host with multiple internet addresses. These addresses do 409*0Sstevel@tonic-gatenot need to have the same internet hostname. Thus, it is possible to 410*0Sstevel@tonic-gateoffer services with different internet hostnames from just one host. 411*0Sstevel@tonic-gate 412*0Sstevel@tonic-gateService providers can use this to offer organizations a presence on the 413*0Sstevel@tonic-gate"net" with their own internet hostname, even when those organizations 414*0Sstevel@tonic-gatearen't connected to the Internet at all. To the end user it makes no 415*0Sstevel@tonic-gatedifference, because applications use internet hostnames. 416*0Sstevel@tonic-gate 417*0Sstevel@tonic-gateThere are several ways to assign multiple addresses to one machine. 418*0Sstevel@tonic-gateThe nice way is to take an existing network interface and to assign 419*0Sstevel@tonic-gateadditional internet addresses with the `ifconfig' command. Examples: 420*0Sstevel@tonic-gate 421*0Sstevel@tonic-gate Solaris 2: ifconfig le0:1 <address> netmask <mask> up 422*0Sstevel@tonic-gate 4.4 BSD: ifconfig en0 alias <address> netmask <mask> 423*0Sstevel@tonic-gate 424*0Sstevel@tonic-gateOn other systems one has to increase the number of network interfaces: 425*0Sstevel@tonic-gateeither with hardware interfaces, or with pseudo interfaces like SLIP or 426*0Sstevel@tonic-gatePPP. The interfaces do not need to be attached to anything. They just 427*0Sstevel@tonic-gateneed to be up and to be assigned a suitable internet address and mask. 428*0Sstevel@tonic-gate 429*0Sstevel@tonic-gateWith the wrapper software, `daemon@host' access control patterns can be 430*0Sstevel@tonic-gateused to distinguish requests by the network address that they are aimed 431*0Sstevel@tonic-gateat. Judicious use of the `twist' option (see the hosts_options.5 file, 432*0Sstevel@tonic-gate`nroff -man' format) can guide the requests to the right server. These 433*0Sstevel@tonic-gatecan be servers that live in separate chroot areas, or servers modified 434*0Sstevel@tonic-gateto take additional context from the command line, or a combination. 435*0Sstevel@tonic-gate 436*0Sstevel@tonic-gateAnother way is to modify gopher or www listeners so that they bind to 437*0Sstevel@tonic-gateonly one specific network address. Multiple gopher or www servers can 438*0Sstevel@tonic-gatethen be run side by side, each taking requests sent to its respective 439*0Sstevel@tonic-gatenetwork address. 440*0Sstevel@tonic-gate 441*0Sstevel@tonic-gate4.7 - Banner messages 442*0Sstevel@tonic-gate--------------------- 443*0Sstevel@tonic-gate 444*0Sstevel@tonic-gateSome sites are required to present an informational message to users 445*0Sstevel@tonic-gatebefore they attempt to login. Banner messages can also be useful when 446*0Sstevel@tonic-gatedenying service: instead of simply dropping the connection a polite 447*0Sstevel@tonic-gateexplanation is given first. Finally, banners can be used to give your 448*0Sstevel@tonic-gatesystem a more personal touch. 449*0Sstevel@tonic-gate 450*0Sstevel@tonic-gateThe wrapper software provides easy-to-use tools to generate pre-login 451*0Sstevel@tonic-gatebanners for ftp, telnet, rlogin etc. from a single prototype banner 452*0Sstevel@tonic-gatetextfile. Details on banners and on-the-fly %<letter> expansions are 453*0Sstevel@tonic-gategiven in the hosts_options.5 manual page (`nroff -man' format). An 454*0Sstevel@tonic-gateexample is given in the file Banners.Makefile. 455*0Sstevel@tonic-gate 456*0Sstevel@tonic-gateIn order to support banner messages the wrappers have to be built with 457*0Sstevel@tonic-gatelanguage extensions enabled. See the section on language extensions. 458*0Sstevel@tonic-gate 459*0Sstevel@tonic-gate4.8 - Sequence number guessing 460*0Sstevel@tonic-gate------------------------------ 461*0Sstevel@tonic-gate 462*0Sstevel@tonic-gateRecently, systems came under attack from intruders that exploited a 463*0Sstevel@tonic-gatewell-known weakness in TCP/IP sequence number generators. This 464*0Sstevel@tonic-gateweakness allows intruders to impersonate trusted hosts. Break-ins have 465*0Sstevel@tonic-gatebeen reported via the rsh service. In fact, any network service can be 466*0Sstevel@tonic-gateexploited that trusts the client host name or address. 467*0Sstevel@tonic-gate 468*0Sstevel@tonic-gateA long-term solution is to stop using network services that trust the 469*0Sstevel@tonic-gateclient host name or address, and to use data encryption instead. 470*0Sstevel@tonic-gate 471*0Sstevel@tonic-gateA short-term solution, as outlined in in CERT advisory CA-95:01, is to 472*0Sstevel@tonic-gateconfigure network routers so that they discard datagrams from "outside" 473*0Sstevel@tonic-gatewith an "inside" source address. This approach is most fruitful when 474*0Sstevel@tonic-gateyou do not trust any hosts outside your local network. 475*0Sstevel@tonic-gate 476*0Sstevel@tonic-gateThe IDENT (RFC931 etc.) client username lookup protocol can help to 477*0Sstevel@tonic-gatedetect host impersonation attacks. Before accepting a client request, 478*0Sstevel@tonic-gatethe wrappers can query the client's IDENT server and find out that the 479*0Sstevel@tonic-gateclient never sent that request. 480*0Sstevel@tonic-gate 481*0Sstevel@tonic-gateWhen the client host provides IDENT service, a negative IDENT lookup 482*0Sstevel@tonic-gateresult (the client matches `UNKNOWN@host') is strong evidence of a host 483*0Sstevel@tonic-gateimpersonation attack. 484*0Sstevel@tonic-gate 485*0Sstevel@tonic-gateA positive IDENT lookup result (the client matches `KNOWN@host') is 486*0Sstevel@tonic-gateless trustworthy. It is possible for an attacker to spoof both the 487*0Sstevel@tonic-gateclient request and the IDENT lookup connection, although doing so 488*0Sstevel@tonic-gateshould be much harder than spoofing just a client request. Another 489*0Sstevel@tonic-gatepossibility is that the client's IDENT server is lying. 490*0Sstevel@tonic-gate 491*0Sstevel@tonic-gateClient username lookups are described in more detail in a previous 492*0Sstevel@tonic-gatesection. Pointers to IDENT daemon software are described in the section 493*0Sstevel@tonic-gateon related software. 494*0Sstevel@tonic-gate 495*0Sstevel@tonic-gate5 - Other works 496*0Sstevel@tonic-gate--------------- 497*0Sstevel@tonic-gate 498*0Sstevel@tonic-gate5.1 - Related documents 499*0Sstevel@tonic-gate----------------------- 500*0Sstevel@tonic-gate 501*0Sstevel@tonic-gateThe war story behind the tcp wrapper tools is described in: 502*0Sstevel@tonic-gate 503*0Sstevel@tonic-gate W.Z. Venema, "TCP WRAPPER, network monitoring, access control and 504*0Sstevel@tonic-gate booby traps", UNIX Security Symposium III Proceedings (Baltimore), 505*0Sstevel@tonic-gate September 1992. 506*0Sstevel@tonic-gate 507*0Sstevel@tonic-gate ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (postscript) 508*0Sstevel@tonic-gate ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.Z (flat text) 509*0Sstevel@tonic-gate 510*0Sstevel@tonic-gateThe same cracker is also described in: 511*0Sstevel@tonic-gate 512*0Sstevel@tonic-gate W.R. Cheswick, "An Evening with Berferd, In Which a Cracker is 513*0Sstevel@tonic-gate Lured, Endured, and Studied", Proceedings of the Winter USENIX 514*0Sstevel@tonic-gate Conference (San Francisco), January 1992. 515*0Sstevel@tonic-gate 516*0Sstevel@tonic-gate research.att.com:/dist/internet_security/berferd.ps 517*0Sstevel@tonic-gate 518*0Sstevel@tonic-gateAn updated version of the latter paper appeared in: 519*0Sstevel@tonic-gate 520*0Sstevel@tonic-gate W.R. Cheswick, S.M. Bellovin, "Firewalls and Internet Security", 521*0Sstevel@tonic-gate Addison-Wesley, 1994. 522*0Sstevel@tonic-gate 523*0Sstevel@tonic-gateDiscussions on internet firewalls are archived on ftp.greatcircle.com. 524*0Sstevel@tonic-gateSubscribe to the mailing list by sending a message to 525*0Sstevel@tonic-gate 526*0Sstevel@tonic-gate majordomo@greatcircle.com 527*0Sstevel@tonic-gate 528*0Sstevel@tonic-gateWith in the body (not subject): subscribe firewalls. 529*0Sstevel@tonic-gate 530*0Sstevel@tonic-gate5.2 - Related software 531*0Sstevel@tonic-gate---------------------- 532*0Sstevel@tonic-gate 533*0Sstevel@tonic-gateNetwork daemons etc. with enhanced logging capabilities can generate 534*0Sstevel@tonic-gatemassive amounts of information: our 150+ workstations generate several 535*0Sstevel@tonic-gatehundred kbytes each day. egrep-based filters can help to suppress some 536*0Sstevel@tonic-gateof the noise. A more powerful tool is the Swatch monitoring system by 537*0Sstevel@tonic-gateStephen E. Hansen and E. Todd Atkins. Swatch can process log files in 538*0Sstevel@tonic-gatereal time and can associate arbitrary actions with patterns; its 539*0Sstevel@tonic-gateapplications are by no means restricted to security. Swatch is 540*0Sstevel@tonic-gateavailable ftp.stanford.edu, directory /general/security-tools/swatch. 541*0Sstevel@tonic-gate 542*0Sstevel@tonic-gateSocks, described in the UNIX Security III proceedings, can be used to 543*0Sstevel@tonic-gatecontrol network traffic from hosts on an internal network, through a 544*0Sstevel@tonic-gatefirewall host, to the outer world. Socks consists of a daemon that is 545*0Sstevel@tonic-gaterun on the firewall host, and of a library with routines that redirect 546*0Sstevel@tonic-gateapplication socket calls through the firewall daemon. Socks is 547*0Sstevel@tonic-gateavailable from s1.gov in /pub/firewalls/socks.tar.Z. 548*0Sstevel@tonic-gate 549*0Sstevel@tonic-gateFor a modified Socks version by Ying-Da Lee (ylee@syl.dl.nec.com) try 550*0Sstevel@tonic-gateftp.nec.com, directory /pub/security/socks.cstc. 551*0Sstevel@tonic-gate 552*0Sstevel@tonic-gateTcpr is a set of perl scripts by Paul Ziemba that enable you to run ftp 553*0Sstevel@tonic-gateand telnet commands across a firewall. Unlike socks it can be used with 554*0Sstevel@tonic-gateunmodified client software. Available from ftp.alantec.com, /pub/tcpr. 555*0Sstevel@tonic-gate 556*0Sstevel@tonic-gateThe TIS firewall toolkit provides a multitude of tools to build your 557*0Sstevel@tonic-gateown internet firewall system. ftp.tis.com, directory /pub/firewalls. 558*0Sstevel@tonic-gate 559*0Sstevel@tonic-gateVersions of rshd and rlogind, modified to report the client user name 560*0Sstevel@tonic-gatein addition to the client host name, are available for anonymous ftp 561*0Sstevel@tonic-gate(ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z). These programs are 562*0Sstevel@tonic-gatedrop-in replacements for SunOS 4.x, Ultrix 4.x, SunOS 5.x and HP-UX 563*0Sstevel@tonic-gate9.x. This archive also contains ftpd/rexecd/login versions that support 564*0Sstevel@tonic-gateS/Key or SecureNet one-time passwords in addition to traditional UNIX 565*0Sstevel@tonic-gatereusable passwords. 566*0Sstevel@tonic-gate 567*0Sstevel@tonic-gateThe securelib shared library by William LeFebvre can be used to control 568*0Sstevel@tonic-gateaccess to network daemons that are not run under control of the inetd 569*0Sstevel@tonic-gateor that serve more than one client, such as the NFS mount daemon that 570*0Sstevel@tonic-gateruns until the machine goes down. Available from eecs.nwu.edu, file 571*0Sstevel@tonic-gate/pub/securelib.tar. 572*0Sstevel@tonic-gate 573*0Sstevel@tonic-gatexinetd (posted to comp.sources.unix) is an inetd replacement that 574*0Sstevel@tonic-gateprovides, among others, logging, username lookup and access control. 575*0Sstevel@tonic-gateHowever, it does not support the System V TLI services, and involves 576*0Sstevel@tonic-gatemuch more source code than the daemon wrapper programs. Available 577*0Sstevel@tonic-gatefrom ftp.uu.net, directory /usenet/comp.sources.unix. 578*0Sstevel@tonic-gate 579*0Sstevel@tonic-gatenetlog from Texas A&M relies on the SunOS 4.x /dev/nit interface to 580*0Sstevel@tonic-gatepassively watch all TCP and UDP network traffic on a network. The 581*0Sstevel@tonic-gatecurrent version is on net.tamu.edu in /pub/security/TAMU. 582*0Sstevel@tonic-gate 583*0Sstevel@tonic-gateWhere shared libraries or router-based packet filtering are not an 584*0Sstevel@tonic-gateoption, an alternative portmap daemon can help to prevent hackers 585*0Sstevel@tonic-gatefrom mounting your NFS file systems using the proxy RPC facility. 586*0Sstevel@tonic-gateftp.win.tue.nl:/pub/security/portmap-X.shar.Z was tested with SunOS 587*0Sstevel@tonic-gate4.1.X Ultrix 3.0 and Ultrix 4.x, HP-UX 8.x and some version of AIX. The 588*0Sstevel@tonic-gateprotection is less effective than that of the securelib library because 589*0Sstevel@tonic-gateportmap is mostly a dictionary service. 590*0Sstevel@tonic-gate 591*0Sstevel@tonic-gateAn rpcbind replacement (the Solaris 2.x moral equivalent of portmap) 592*0Sstevel@tonic-gatecan be found on ftp.win.tue.nl in /pub/security. It prevents hackers 593*0Sstevel@tonic-gatefrom mounting your NFS file systems by using the proxy RPC facility. 594*0Sstevel@tonic-gate 595*0Sstevel@tonic-gateSource for a portable RFC 931 (TAP, IDENT, RFC 1413) daemon by Peter 596*0Sstevel@tonic-gateEriksson is available from ftp.lysator.liu.se:/pub/ident/servers. 597*0Sstevel@tonic-gate 598*0Sstevel@tonic-gateSome TCP/IP implementations come without syslog library. Some come with 599*0Sstevel@tonic-gatethe library but have no syslog daemon. A replacement can be found in 600*0Sstevel@tonic-gateftp.win.tue.nl:/pub/security/surrogate-syslog.tar.Z. The fakesyslog 601*0Sstevel@tonic-gatelibrary that comes with the nntp sources reportedly works well, too. 602*0Sstevel@tonic-gate 603*0Sstevel@tonic-gate6 - Limitations 604*0Sstevel@tonic-gate--------------- 605*0Sstevel@tonic-gate 606*0Sstevel@tonic-gate6.1 - Known wrapper limitations 607*0Sstevel@tonic-gate------------------------------- 608*0Sstevel@tonic-gate 609*0Sstevel@tonic-gateMany UDP (and rpc/udp) daemons linger around for a while after they 610*0Sstevel@tonic-gatehave serviced a request, just in case another request comes in. In the 611*0Sstevel@tonic-gateinetd configuration file these daemons are registered with the `wait' 612*0Sstevel@tonic-gateoption. Only the request that started such a daemon will be seen by the 613*0Sstevel@tonic-gatewrappers. Such daemons are better protected with the securelib shared 614*0Sstevel@tonic-gatelibrary (see: Related software). 615*0Sstevel@tonic-gate 616*0Sstevel@tonic-gateThe wrappers do not work with RPC services over TCP. These services are 617*0Sstevel@tonic-gateregistered as rpc/tcp in the inetd configuration file. The only non- 618*0Sstevel@tonic-gatetrivial service that is affected by this limitation is rexd, which is 619*0Sstevel@tonic-gateused by the on(1) command. This is no great loss. On most systems, 620*0Sstevel@tonic-gaterexd is less secure than a wildcard in /etc/hosts.equiv. 621*0Sstevel@tonic-gate 622*0Sstevel@tonic-gateSome RPC requests (for example: rwall, rup, rusers) appear to come from 623*0Sstevel@tonic-gatethe server host. What happens is that the client broadcasts its request 624*0Sstevel@tonic-gateto all portmap daemons on its network; each portmap daemon forwards the 625*0Sstevel@tonic-gaterequest to a daemon on its own system. As far as the rwall etc. daemons 626*0Sstevel@tonic-gateknow, the request comes from the local host. 627*0Sstevel@tonic-gate 628*0Sstevel@tonic-gatePortmap and RPC (e.g. NIS and NFS) (in)security is a topic in itself. 629*0Sstevel@tonic-gateSee the section in this document on related software. 630*0Sstevel@tonic-gate 631*0Sstevel@tonic-gate6.2 - Known system software bugs 632*0Sstevel@tonic-gate-------------------------------- 633*0Sstevel@tonic-gate 634*0Sstevel@tonic-gateWorkarounds have been implemented for several bugs in system software. 635*0Sstevel@tonic-gateThey are described in the Makefile. Unfortunately, some system software 636*0Sstevel@tonic-gatebugs cannot be worked around. The result is loss of functionality. 637*0Sstevel@tonic-gate 638*0Sstevel@tonic-gateIRIX has so many bugs that it has its own README.IRIX file. 639*0Sstevel@tonic-gate 640*0Sstevel@tonic-gateOlder ConvexOS versions come with a broken recvfrom(2) implementation. 641*0Sstevel@tonic-gateThis makes it impossible for the daemon wrappers to look up the 642*0Sstevel@tonic-gateclient host address (and hence, the name) in case of UDP requests. 643*0Sstevel@tonic-gateA patch is available for ConvexOS 10.1; later releases should be OK. 644*0Sstevel@tonic-gate 645*0Sstevel@tonic-gateWith early Solaris (SunOS 5) versions, the syslog daemon will leave 646*0Sstevel@tonic-gatebehind zombie processes when writing to logged-in users. Workaround: 647*0Sstevel@tonic-gateincrease the syslogd threshold for logging to users, or reduce the 648*0Sstevel@tonic-gatewrapper's logging severity. 649*0Sstevel@tonic-gate 650*0Sstevel@tonic-gateOn some systems, the optional RFC 931 etc. client username lookups may 651*0Sstevel@tonic-gatetrigger a kernel bug. When a client host connects to your system, and 652*0Sstevel@tonic-gatethe RFC 931 connection from your system to that client is rejected by a 653*0Sstevel@tonic-gaterouter, your kernel may drop all connections with that client. This is 654*0Sstevel@tonic-gatenot a bug in the wrapper programs: complain to your vendor, and don't 655*0Sstevel@tonic-gateenable client user name lookups until the bug has been fixed. 656*0Sstevel@tonic-gate 657*0Sstevel@tonic-gateReportedly, SunOS 4.1.1, Next 2.0a, ISC 3.0 with TCP 1.3, and AIX 3.2.2 658*0Sstevel@tonic-gateand later are OK. 659*0Sstevel@tonic-gate 660*0Sstevel@tonic-gateSony News/OS 4.51, HP-UX 8-something and Ultrix 4.3 still have the bug. 661*0Sstevel@tonic-gateReportedly, a fix for Ultrix is available (CXO-8919). 662*0Sstevel@tonic-gate 663*0Sstevel@tonic-gateThe following procedure can be used (from outside the tue.nl domain) to 664*0Sstevel@tonic-gatefind out if your kernel has the bug. From the system under test, do: 665*0Sstevel@tonic-gate 666*0Sstevel@tonic-gate % ftp 131.155.70.19 667*0Sstevel@tonic-gate 668*0Sstevel@tonic-gateThis command attempts to make an ftp connection to our anonymous ftp 669*0Sstevel@tonic-gateserver (ftp.win.tue.nl). When the connection has been established, run 670*0Sstevel@tonic-gatethe following command from the same system under test, while keeping 671*0Sstevel@tonic-gatethe ftp connection open: 672*0Sstevel@tonic-gate 673*0Sstevel@tonic-gate % telnet 131.155.70.19 111 674*0Sstevel@tonic-gate 675*0Sstevel@tonic-gateDo not forget the `111' at the end of the command. This telnet command 676*0Sstevel@tonic-gateattempts to connect to our portmap process. The telnet command should 677*0Sstevel@tonic-gatefail with: "host not reachable", or with a timeout error. If your ftp 678*0Sstevel@tonic-gateconnection gets messed up, you have the bug. If the telnet command does 679*0Sstevel@tonic-gatenot fail, please let me know a.s.a.p.! 680*0Sstevel@tonic-gate 681*0Sstevel@tonic-gateFor those who care, the bug is that the BSD kernel code was not careful 682*0Sstevel@tonic-gateenough with incoming ICMP UNREACHABLE control messages (it ignored the 683*0Sstevel@tonic-gatelocal and remote port numbers, and therefore zapped *all* connections 684*0Sstevel@tonic-gatewith the remote system). The bug is still present in the BSD NET/1 685*0Sstevel@tonic-gatesource release (1989) but apparently has been fixed in BSD NET/2 (1991). 686*0Sstevel@tonic-gate 687*0Sstevel@tonic-gate7 - Configuration and installation 688*0Sstevel@tonic-gate---------------------------------- 689*0Sstevel@tonic-gate 690*0Sstevel@tonic-gate7.1 - Easy configuration and installation 691*0Sstevel@tonic-gate----------------------------------------- 692*0Sstevel@tonic-gate 693*0Sstevel@tonic-gateThe "easy" recipe requires no changes to existing software or 694*0Sstevel@tonic-gateconfiguration files. Basically, you move the daemons that you want to 695*0Sstevel@tonic-gateprotect to a different directory and plug the resulting holes with 696*0Sstevel@tonic-gatecopies of the wrapper programs. 697*0Sstevel@tonic-gate 698*0Sstevel@tonic-gateIf you don't run Ultrix, you won't need the miscd wrapper program. The 699*0Sstevel@tonic-gatemiscd daemon implements among others the SYSTAT service, which produces 700*0Sstevel@tonic-gatethe same output as the WHO command. 701*0Sstevel@tonic-gate 702*0Sstevel@tonic-gateType `make' and follow the instructions. The Makefile comes with 703*0Sstevel@tonic-gateready-to-use templates for many common UNIX implementations (sun, 704*0Sstevel@tonic-gateultrix, hp-ux, aix, irix,...). 705*0Sstevel@tonic-gate 706*0Sstevel@tonic-gateIRIX has so many bugs that it has its own README.IRIX file. 707*0Sstevel@tonic-gate 708*0Sstevel@tonic-gateWhen the `make' succeeds the result is five executables (six in case of 709*0Sstevel@tonic-gateUltrix). 710*0Sstevel@tonic-gate 711*0Sstevel@tonic-gateYou can use the `tcpdchk' program to identify the most common problems 712*0Sstevel@tonic-gatein your wrapper and inetd configuration files. 713*0Sstevel@tonic-gate 714*0Sstevel@tonic-gateWith the `tcpdmatch' program you can examine how the wrapper would 715*0Sstevel@tonic-gatereact to specific requests for service. 716*0Sstevel@tonic-gate 717*0Sstevel@tonic-gateThe `safe_finger' command should be used when you implement booby 718*0Sstevel@tonic-gatetraps: it gives better protection against nasty stuff that remote 719*0Sstevel@tonic-gatehosts may do in response to your finger probes. 720*0Sstevel@tonic-gate 721*0Sstevel@tonic-gateThe `try-from' program tests the host and username lookup code. Run it 722*0Sstevel@tonic-gatefrom a remote shell command (`rsh host /some/where/try-from') and it 723*0Sstevel@tonic-gateshould be able to figure out from what system it is being called. 724*0Sstevel@tonic-gate 725*0Sstevel@tonic-gateThe tcpd program can be used to monitor the telnet, finger, ftp, exec, 726*0Sstevel@tonic-gatersh, rlogin, tftp, talk, comsat and other tcp or udp services that have 727*0Sstevel@tonic-gatea one-to-one mapping onto executable files. 728*0Sstevel@tonic-gate 729*0Sstevel@tonic-gateThe tcpd program can also be used for services that are marked as 730*0Sstevel@tonic-gaterpc/udp in the inetd configuration file, but not for rpc/tcp services 731*0Sstevel@tonic-gatesuch as rexd. You probably do not want to run rexd anyway. On most 732*0Sstevel@tonic-gatesystems it is even less secure than a wildcard in /etc/hosts.equiv. 733*0Sstevel@tonic-gate 734*0Sstevel@tonic-gateWith System V.4-style systems, the tcpd program can also handle TLI 735*0Sstevel@tonic-gateservices. When TCP/IP or UDP/IP is used underneath TLI, tcpd provides 736*0Sstevel@tonic-gatethe same functions as with socket-based applications. When some other 737*0Sstevel@tonic-gateprotocol is used underneath TLI, functionality will be limited (no 738*0Sstevel@tonic-gateclient username lookups, weird network address formats). 739*0Sstevel@tonic-gate 740*0Sstevel@tonic-gateDecide which services you want to monitor. Move the corresponding 741*0Sstevel@tonic-gatevendor-provided daemon programs to the location specified by the 742*0Sstevel@tonic-gateREAL_DAEMON_DIR constant in the Makefile, and fill the holes with 743*0Sstevel@tonic-gatecopies of the tcpd program. That is, one copy of (or link to) the tcpd 744*0Sstevel@tonic-gateprogram for each service that you want to monitor. For example, to 745*0Sstevel@tonic-gatemonitor the use of your finger service: 746*0Sstevel@tonic-gate 747*0Sstevel@tonic-gate # mkdir REAL_DAEMON_DIR 748*0Sstevel@tonic-gate # mv /usr/etc/in.fingerd REAL_DAEMON_DIR 749*0Sstevel@tonic-gate # cp tcpd /usr/etc/in.fingerd 750*0Sstevel@tonic-gate 751*0Sstevel@tonic-gateThe example applies to SunOS 4. With other UNIX implementations the 752*0Sstevel@tonic-gatenetwork daemons live in /usr/libexec, /usr/sbin or in /etc, or have no 753*0Sstevel@tonic-gate"in." prefix to their names, but you get the idea. 754*0Sstevel@tonic-gate 755*0Sstevel@tonic-gateFile protections: the wrapper, all files used by the wrapper, and all 756*0Sstevel@tonic-gatedirectories in the path leading to those files, should be accessible 757*0Sstevel@tonic-gatebut not writable for unprivileged users (mode 755 or mode 555). Do not 758*0Sstevel@tonic-gateinstall the wrapper set-uid. 759*0Sstevel@tonic-gate 760*0Sstevel@tonic-gateUltrix only: If you want to monitor the SYSTAT service, move the 761*0Sstevel@tonic-gatevendor-provided miscd daemon to the location specified by the 762*0Sstevel@tonic-gateREAL_DAEMON_DIR macro in the Makefile, and install the miscd wrapper 763*0Sstevel@tonic-gateat the original miscd location. 764*0Sstevel@tonic-gate 765*0Sstevel@tonic-gateIn the absence of any access-control tables, the daemon wrappers 766*0Sstevel@tonic-gatewill just maintain a record of network connections made to your system. 767*0Sstevel@tonic-gate 768*0Sstevel@tonic-gate7.2 - Advanced configuration and installation 769*0Sstevel@tonic-gate--------------------------------------------- 770*0Sstevel@tonic-gate 771*0Sstevel@tonic-gateThe advanced recipe leaves your daemon executables alone, but involves 772*0Sstevel@tonic-gatesimple modifications to the inetd configuration file. 773*0Sstevel@tonic-gate 774*0Sstevel@tonic-gateType `make' and follow the instructions. The Makefile comes with 775*0Sstevel@tonic-gateready-to-use templates for many common UNIX implementations (sun, 776*0Sstevel@tonic-gateultrix, hp-ux, aix, irix, ...). 777*0Sstevel@tonic-gate 778*0Sstevel@tonic-gateIRIX users should read the warnings in the README.IRIX file first. 779*0Sstevel@tonic-gate 780*0Sstevel@tonic-gateWhen the `make' succeeds the result is five executables (six in case of 781*0Sstevel@tonic-gateUltrix). 782*0Sstevel@tonic-gate 783*0Sstevel@tonic-gateYou can use the `tcpdchk' program to identify the most common problems 784*0Sstevel@tonic-gatein your wrapper and inetd configuration files. 785*0Sstevel@tonic-gate 786*0Sstevel@tonic-gateWith the `tcpdmatch' program you can examine how the wrapper would 787*0Sstevel@tonic-gatereact to specific requests for service. 788*0Sstevel@tonic-gate 789*0Sstevel@tonic-gateThe `try-from' program tests the host and username lookup code. Run it 790*0Sstevel@tonic-gatefrom a remote shell command (`rsh host /some/where/try-from') and it 791*0Sstevel@tonic-gateshould be able to figure out from what system it is being called. 792*0Sstevel@tonic-gate 793*0Sstevel@tonic-gateThe `safe_finger' command should be used when you implement a booby 794*0Sstevel@tonic-gatetrap: it gives better protection against nasty stuff that remote hosts 795*0Sstevel@tonic-gatemay do in response to your finger probes. 796*0Sstevel@tonic-gate 797*0Sstevel@tonic-gateThe tcpd program can be used to monitor the telnet, finger, ftp, exec, 798*0Sstevel@tonic-gatersh, rlogin, tftp, talk, comsat and other tcp or udp services that have 799*0Sstevel@tonic-gatea one-to-one mapping onto executable files. 800*0Sstevel@tonic-gate 801*0Sstevel@tonic-gateWith System V.4-style systems, the tcpd program can also handle TLI 802*0Sstevel@tonic-gateservices. When TCP/IP or UDP/IP is used underneath TLI, tcpd provides 803*0Sstevel@tonic-gatethe same functions as with socket-based applications. When some other 804*0Sstevel@tonic-gateprotocol is used underneath TLI, functionality will be limited (no 805*0Sstevel@tonic-gateclient username lookups, weird network address formats). 806*0Sstevel@tonic-gate 807*0Sstevel@tonic-gateThe tcpd program can also be used for services that are marked as 808*0Sstevel@tonic-gaterpc/udp in the inetd configuration file, but not for rpc/tcp services 809*0Sstevel@tonic-gatesuch as rexd. You probably do not want to run rexd anyway. On most 810*0Sstevel@tonic-gatesystems it is even less secure than a wildcard in /etc/hosts.equiv. 811*0Sstevel@tonic-gate 812*0Sstevel@tonic-gateInstall the tcpd command in a suitable place. Apollo UNIX users will 813*0Sstevel@tonic-gatewant to install it under a different name because the name "tcpd" is 814*0Sstevel@tonic-gatealready taken; a suitable name would be "frontd". 815*0Sstevel@tonic-gate 816*0Sstevel@tonic-gateFile protections: the wrapper, all files used by the wrapper, and all 817*0Sstevel@tonic-gatedirectories in the path leading to those files, should be accessible 818*0Sstevel@tonic-gatebut not writable for unprivileged users (mode 755 or mode 555). Do not 819*0Sstevel@tonic-gateinstall the wrapper set-uid. 820*0Sstevel@tonic-gate 821*0Sstevel@tonic-gateThen perform the following edits on the inetd configuration file 822*0Sstevel@tonic-gate(usually /etc/inetd.conf or /etc/inet/inetd.conf): 823*0Sstevel@tonic-gate 824*0Sstevel@tonic-gate finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd 825*0Sstevel@tonic-gate ^^^^^^^^^^^^^^^^^^^ 826*0Sstevel@tonic-gatebecomes: 827*0Sstevel@tonic-gate 828*0Sstevel@tonic-gate finger stream tcp nowait nobody /usr/etc/tcpd in.fingerd 829*0Sstevel@tonic-gate ^^^^^^^^^^^^^ 830*0Sstevel@tonic-gateSend a `kill -HUP' to the inetd process to make the change effective. 831*0Sstevel@tonic-gateSome IRIX inetd implementations require that you first disable the 832*0Sstevel@tonic-gatefinger service (comment out the finger service and `kill -HUP' the 833*0Sstevel@tonic-gateinetd) before you can turn on the modified version. Sending a HUP 834*0Sstevel@tonic-gatetwice seems to work just as well for IRIX 5.3, 6.0, 6.0.1 and 6.1. 835*0Sstevel@tonic-gate 836*0Sstevel@tonic-gateAIX note: you may have to execute the `inetimp' command after changing 837*0Sstevel@tonic-gatethe inetd configuration file. 838*0Sstevel@tonic-gate 839*0Sstevel@tonic-gateThe example applies to SunOS 4. With other UNIX implementations the 840*0Sstevel@tonic-gatenetwork daemons live in /usr/libexec, /usr/sbin, or /etc, the network 841*0Sstevel@tonic-gatedaemons have no "in." prefix to their names, or the username field in 842*0Sstevel@tonic-gatethe inetd configuration file may be missing. 843*0Sstevel@tonic-gate 844*0Sstevel@tonic-gateWhen the finger service works as expected you can perform similar 845*0Sstevel@tonic-gatechanges for other network services. Do not forget the `kill -HUP'. 846*0Sstevel@tonic-gate 847*0Sstevel@tonic-gateThe miscd daemon that comes with Ultrix implements several network 848*0Sstevel@tonic-gateservices. It decides what to do by looking at its process name. One of 849*0Sstevel@tonic-gatethe services is systat, which is a kind of limited finger service. If 850*0Sstevel@tonic-gateyou want to monitor the systat service, install the miscd wrapper in a 851*0Sstevel@tonic-gatesuitable place and update the inetd configuration file: 852*0Sstevel@tonic-gate 853*0Sstevel@tonic-gate systat stream tcp nowait /suitable/place/miscd systatd 854*0Sstevel@tonic-gate 855*0Sstevel@tonic-gateUltrix 4.3 allows you to specify a user id under which the daemon will 856*0Sstevel@tonic-gatebe executed. This feature is not documented in the manual pages. Thus, 857*0Sstevel@tonic-gatethe example would become: 858*0Sstevel@tonic-gate 859*0Sstevel@tonic-gate systat stream tcp nowait nobody /suitable/place/miscd systatd 860*0Sstevel@tonic-gate 861*0Sstevel@tonic-gateOlder Ultrix systems still run all their network daemons as root. 862*0Sstevel@tonic-gate 863*0Sstevel@tonic-gateIn the absence of any access-control tables, the daemon wrappers 864*0Sstevel@tonic-gatewill just maintain a record of network connections made to your system. 865*0Sstevel@tonic-gate 866*0Sstevel@tonic-gate7.3 - Daemons with arbitrary path names 867*0Sstevel@tonic-gate--------------------------------------- 868*0Sstevel@tonic-gate 869*0Sstevel@tonic-gateThe above tcpd examples work fine with network daemons that live in a 870*0Sstevel@tonic-gatecommon directory, but sometimes that is not practical. Having soft 871*0Sstevel@tonic-gatelinks all over your file system is not a clean solution, either. 872*0Sstevel@tonic-gate 873*0Sstevel@tonic-gateInstead you can specify, in the inetd configuration file, an absolute 874*0Sstevel@tonic-gatepath name for the daemon process name. For example, 875*0Sstevel@tonic-gate 876*0Sstevel@tonic-gate ntalk dgram udp wait root /usr/etc/tcpd /usr/local/lib/ntalkd 877*0Sstevel@tonic-gate 878*0Sstevel@tonic-gateWhen the daemon process name is an absolute path name, tcpd ignores the 879*0Sstevel@tonic-gatevalue of the REAL_DAEMON_DIR constant, and uses the last path component 880*0Sstevel@tonic-gateof the daemon process name for logging and for access control. 881*0Sstevel@tonic-gate 882*0Sstevel@tonic-gate7.4 - Building and testing the access control rules 883*0Sstevel@tonic-gate--------------------------------------------------- 884*0Sstevel@tonic-gate 885*0Sstevel@tonic-gateIn order to support access control the wrappers must be compiled with 886*0Sstevel@tonic-gatethe -DHOSTS_ACCESS option. The access control policy is given in the 887*0Sstevel@tonic-gateform of two tables (default: /etc/hosts.allow and /etc/hosts.deny). 888*0Sstevel@tonic-gateAccess control is disabled when there are no access control tables, or 889*0Sstevel@tonic-gatewhen the tables are empty. 890*0Sstevel@tonic-gate 891*0Sstevel@tonic-gateIf you haven't used the wrappers before I recommend that you first run 892*0Sstevel@tonic-gatethem a couple of days without any access control restrictions. The 893*0Sstevel@tonic-gatelogfile records should give you an idea of the process names and of the 894*0Sstevel@tonic-gatehost names that you will have to build into your access control rules. 895*0Sstevel@tonic-gate 896*0Sstevel@tonic-gateThe syntax of the access control rules is documented in the file 897*0Sstevel@tonic-gatehosts_access.5, which is in `nroff -man' format. This is a lengthy 898*0Sstevel@tonic-gatedocument, and no-one expects you to read it right away from beginning 899*0Sstevel@tonic-gateto end. Instead, after reading the introductory section, skip to the 900*0Sstevel@tonic-gateexamples at the end so that you get a general idea of the language. 901*0Sstevel@tonic-gateThen you can appreciate the detailed reference sections near the 902*0Sstevel@tonic-gatebeginning of the document. 903*0Sstevel@tonic-gate 904*0Sstevel@tonic-gateThe examples in the hosts_access.5 document (`nroff -man' format) show 905*0Sstevel@tonic-gatetwo specific types of access control policy: 1) mostly closed (only 906*0Sstevel@tonic-gatepermitting access from a limited number of systems) and 2) mostly open 907*0Sstevel@tonic-gate(permitting access from everyone except a limited number of trouble 908*0Sstevel@tonic-gatemakers). You will have to choose what model suits your situation best. 909*0Sstevel@tonic-gateImplementing a mixed policy should not be overly difficult either. 910*0Sstevel@tonic-gate 911*0Sstevel@tonic-gateOptional extensions to the access control language are described in the 912*0Sstevel@tonic-gatehosts_options.5 document (`nroff -man' format). 913*0Sstevel@tonic-gate 914*0Sstevel@tonic-gateThe `tcpdchk' program examines all rules in your access control files 915*0Sstevel@tonic-gateand reports any problems it can find. `tcpdchk -v' writes to standard 916*0Sstevel@tonic-gateoutput a pretty-printed list of all rules. `tcpdchk -d' examines the 917*0Sstevel@tonic-gatehosts.access and hosts.allow files in the current directory. This 918*0Sstevel@tonic-gateprogram is described in the tcpdchk.8 document (`nroff -man' format). 919*0Sstevel@tonic-gate 920*0Sstevel@tonic-gateThe `tcpdmatch' command can be used to try out your local access 921*0Sstevel@tonic-gatecontrol files. The command syntax is: 922*0Sstevel@tonic-gate 923*0Sstevel@tonic-gate tcpdmatch process_name hostname (e.g.: tcpdmatch in.tftpd localhost) 924*0Sstevel@tonic-gate 925*0Sstevel@tonic-gate tcpdmatch process_name address (e.g.: tcpdmatch in.tftpd 127.0.0.1) 926*0Sstevel@tonic-gate 927*0Sstevel@tonic-gateThis way you can simulate what decisions will be made, and what actions 928*0Sstevel@tonic-gatewill be taken, when hosts connect to your own system. The program is 929*0Sstevel@tonic-gatedescribed in the tcpdmatch.8 document (`nroff -man' format). 930*0Sstevel@tonic-gate 931*0Sstevel@tonic-gateNote 1: `tcpdmatch -d' will look for hosts.{allow,deny} tables in the 932*0Sstevel@tonic-gatecurrent working directory. This is useful for testing new rules without 933*0Sstevel@tonic-gatebothering your users. 934*0Sstevel@tonic-gate 935*0Sstevel@tonic-gateNote 2: you cannot use the `tcpdmatch' command to simulate what happens 936*0Sstevel@tonic-gatewhen the local system connects to other hosts. 937*0Sstevel@tonic-gate 938*0Sstevel@tonic-gateIn order to find out what process name to use, just use the service and 939*0Sstevel@tonic-gatewatch the process name that shows up in the logfile. Alternatively, 940*0Sstevel@tonic-gateyou can look up the name from the inetd configuration file. Coming back 941*0Sstevel@tonic-gateto the tftp example in the tutorial section above: 942*0Sstevel@tonic-gate 943*0Sstevel@tonic-gate tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot 944*0Sstevel@tonic-gate 945*0Sstevel@tonic-gateThis entry causes the inetd to run the wrapper program (tcpd) with a 946*0Sstevel@tonic-gateprocess name `in.tftpd'. This is the name that the wrapper will use 947*0Sstevel@tonic-gatewhen scanning the access control tables. Therefore, `in.tftpd' is the 948*0Sstevel@tonic-gateprocess name that should be given to the `tcpdmatch' command. On your 949*0Sstevel@tonic-gatesystem the actual inetd.conf entry may differ (tftpd instead of 950*0Sstevel@tonic-gatein.tftpd, and no `root' field), but you get the idea. 951*0Sstevel@tonic-gate 952*0Sstevel@tonic-gateWhen you specify a host name, the `tcpdmatch' program will use both the 953*0Sstevel@tonic-gatehost name and address. This way you can simulate the most common case 954*0Sstevel@tonic-gatewhere the wrappers know both the host address and the host name. The 955*0Sstevel@tonic-gate`tcpdmatch' program will iterate over all addresses that it can find 956*0Sstevel@tonic-gatefor the given host name. 957*0Sstevel@tonic-gate 958*0Sstevel@tonic-gateWhen you specify a host address instead of a host name, the `tcpdmatch' 959*0Sstevel@tonic-gateprogram will pretend that the host name is unknown, so that you can 960*0Sstevel@tonic-gatesimulate what happens when the wrapper is unable to look up the client 961*0Sstevel@tonic-gatehost name. 962*0Sstevel@tonic-gate 963*0Sstevel@tonic-gate7.5 - Other applications 964*0Sstevel@tonic-gate------------------------ 965*0Sstevel@tonic-gate 966*0Sstevel@tonic-gateThe access control routines can easily be integrated with other 967*0Sstevel@tonic-gateprograms. The hosts_access.3 manual page (`nroff -man' format) 968*0Sstevel@tonic-gatedescribes the external interface of the libwrap.a library. 969*0Sstevel@tonic-gate 970*0Sstevel@tonic-gateThe tcpd program can even be used to control access to the mail 971*0Sstevel@tonic-gateservice. This can be useful when you suspect that someone is trying 972*0Sstevel@tonic-gateout some obscure sendmail bug, or when a remote site is misconfigured 973*0Sstevel@tonic-gateand keeps hammering your mail daemon. 974*0Sstevel@tonic-gate 975*0Sstevel@tonic-gateIn that case, sendmail should not be run as a stand-alone network 976*0Sstevel@tonic-gatelistener, but it should be registered in the inetd configuration file. 977*0Sstevel@tonic-gateFor example: 978*0Sstevel@tonic-gate 979*0Sstevel@tonic-gate smtp stream tcp nowait root /usr/etc/tcpd /usr/lib/sendmail -bs 980*0Sstevel@tonic-gate 981*0Sstevel@tonic-gateYou will still need to run one sendmail background process to handle 982*0Sstevel@tonic-gatequeued-up outgoing mail. A command like: 983*0Sstevel@tonic-gate 984*0Sstevel@tonic-gate /usr/lib/sendmail -q15m 985*0Sstevel@tonic-gate 986*0Sstevel@tonic-gate(no `-bd' flag) should take care of that. You cannot really prevent 987*0Sstevel@tonic-gatepeople from posting forged mail this way, because there are many 988*0Sstevel@tonic-gateunprotected smtp daemons on the network. 989*0Sstevel@tonic-gate 990*0Sstevel@tonic-gate8 - Acknowledgements 991*0Sstevel@tonic-gate-------------------- 992*0Sstevel@tonic-gate 993*0Sstevel@tonic-gateMany people contributed to the evolution of the programs, by asking 994*0Sstevel@tonic-gateinspiring questions, by suggesting features or bugfixes, or by 995*0Sstevel@tonic-gatesubmitting source code. Nevertheless, all mistakes and bugs in the 996*0Sstevel@tonic-gatewrappers are my own. 997*0Sstevel@tonic-gate 998*0Sstevel@tonic-gateThanks to Brendan Kehoe (cs.widener.edu), Heimir Sverrisson (hafro.is) 999*0Sstevel@tonic-gateand Dan Bernstein (kramden.acf.nyu.edu) for feedback on an early 1000*0Sstevel@tonic-gaterelease of this product. The host name/address check was suggested by 1001*0Sstevel@tonic-gateJohn Kimball (src.honeywell.com). Apollo's UNIX environment has some 1002*0Sstevel@tonic-gatepeculiar quirks: Willem-Jan Withagen (eb.ele.tue.nl), Pieter 1003*0Sstevel@tonic-gateSchoenmakers (es.ele.tue.nl) and Charles S. Fuller (wccs.psc.edu) 1004*0Sstevel@tonic-gateprovided assistance. Hal R. Brand (addvax.llnl.gov) told me how to 1005*0Sstevel@tonic-gateget the client IP address in case of datagram-oriented services, and 1006*0Sstevel@tonic-gatesuggested the optional shell command feature. Shabbir Safdar 1007*0Sstevel@tonic-gate(mentor.cc.purdue.edu) provided a first version of a much-needed manual 1008*0Sstevel@tonic-gatepage. Granville Boman Goza, IV (sei.cmu.edu) suggested to use the 1009*0Sstevel@tonic-gateclient IP address even when the host name is available. Casper H.S. 1010*0Sstevel@tonic-gateDik (fwi.uva.nl) provided additional insight into DNS spoofing 1011*0Sstevel@tonic-gatetechniques. The bogus daemon feature was inspired by code from Andrew 1012*0Sstevel@tonic-gateMacpherson (BNR Europe Ltd). Steve Bellovin (research.att.com) 1013*0Sstevel@tonic-gateconfirmed some of my suspicions about the darker sides of TCP/IP 1014*0Sstevel@tonic-gateinsecurity. Risks of automated fingers were pointed out by Borja Marcos 1015*0Sstevel@tonic-gate(we.lc.ehu.es). Brad Plecs (jhuspo.ca.jhu.edu) was kind enough to try 1016*0Sstevel@tonic-gatemy early TLI code and to work out how DG/UX differs from Solaris. 1017*0Sstevel@tonic-gate 1018*0Sstevel@tonic-gateJohn P. Rouillard (cs.umb.edu) deserves special mention for his 1019*0Sstevel@tonic-gatepersistent, but constructive, nagging about wrong or missing things, 1020*0Sstevel@tonic-gateand for trying out and discussing embryonic code or ideas. 1021*0Sstevel@tonic-gate 1022*0Sstevel@tonic-gateLast but not least, Howard Chu (hanauma.jpl.nasa.gov), Darren Reed 1023*0Sstevel@tonic-gate(coombs.anu.edu.au), Icarus Sparry (gdr.bath.ac.uk), Scott Schwartz 1024*0Sstevel@tonic-gate(cs.psu.edu), John A. Kunze (violet.berkeley.edu), Daniel Len Schales 1025*0Sstevel@tonic-gate(engr.latech.edu), Chris Turbeville (cse.uta.edu), Paul Kranenburg 1026*0Sstevel@tonic-gate(cs.few.eur.nl), Marc Boucher (cam.org), Dave Mitchell 1027*0Sstevel@tonic-gate(dcs.shef.ac.uk), Andrew Maffei, Adrian van Bloois, Rop Gonggrijp, John 1028*0Sstevel@tonic-gateC. Wingenbach, Everett F. Batey and many, many others provided fixes, 1029*0Sstevel@tonic-gatecode fragments, or ideas for improvements. 1030*0Sstevel@tonic-gate 1031*0Sstevel@tonic-gate Wietse Venema (wietse@wzv.win.tue.nl) 1032*0Sstevel@tonic-gate Department of Mathematics and Computing Science 1033*0Sstevel@tonic-gate Eindhoven University of Technology 1034*0Sstevel@tonic-gate P.O. Box 513 1035*0Sstevel@tonic-gate 5600 MB Eindhoven 1036*0Sstevel@tonic-gate The Netherlands 1037*0Sstevel@tonic-gate 1038*0Sstevel@tonic-gate Currently visiting IBM T.J. Watson Research, Hawthorne NY, USA. 1039