home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / misc / volume20 / log_tcp / part01 / README < prev    next >
Encoding:
Text File  |  1991-05-22  |  8.4 KB  |  182 lines
  1. @(#) README 1.4 91/05/20 13:30:17
  2.  
  3. General description:
  4. --------------------
  5.  
  6. With this package you can monitor connections to the SYSTAT, FINGER,
  7. FTP, TELNET, RLOGIN, RSH and EXEC network services.  Connections are
  8. logged through the syslog(3) facility. A requirement is that daemons
  9. are started by the inetd program or something similar.
  10.  
  11. The programs are tiny front ends that just report the remote host name
  12. and then invoke the real network daemon.  In the most common case, no
  13. changes should be required to existing software or to configuration
  14. files.  Just move the vendor-provided daemons to another place and
  15. install the front ends into their original places. Installation details
  16. are given below.
  17.  
  18. Early versions of the programs were tested with Ultrix >= 2.2, with
  19. SunOS >= 3.4 and ISC 2.2. The first official release has been installed
  20. on a wide variety of systems (BSD, SYSV, Apollo) without modification.
  21. The present release should still run on top of most BSD-style TCP/IP
  22. implementations.
  23.  
  24. Optional feature:
  25. -----------------
  26.  
  27. When compiled with -DHOSTS_ACCESS, the front-end programs support a
  28. simple form of access control that is based on host (or domain) names,
  29. internet addresses or network numbers, network daemon process names and
  30. (optionally) netgroups (a NIS, formerly YP, feature).  Wild cards are
  31. supported.  If a host requests connection to a network daemon, and if
  32. the (daemon, host) pair is matched by an entry in the /etc/hosts.allow
  33. file, access is granted.  Otherwise, if the (daemon, host) pair is
  34. matched by an entry in the /etc/hosts.deny file, access is denied.
  35. Otherwise, access is granted.  More details are provided in the
  36. hosts_access(5) manual page.  This form of access control may be useful
  37. if it can not be implemented at a more suitable level (such as an
  38. internet router).
  39.  
  40. Major enhancement:
  41. ------------------
  42.  
  43. It has been brought to my attention that authentication based on host
  44. address to host name mapping can easily be spoofed by playing games
  45. with some domain name server.  A little research led me to the conclusion
  46. that many existing rshd and rlogind implementations do not account for
  47. this potential problem.
  48.  
  49. The present versions of the front-end programs provide a way to take
  50. care of the problem.  After mapping a client host address to a host
  51. name, the front-end programs now verify that the host name maps to the
  52. same host address.  The idea is that it is much easier to compromise
  53. the address->name map of some random name server than to compromise the
  54. name->address map that is specific to your domain.  If the source is
  55. compiled with -DPARANOID, the front ends justs drop the connection in
  56. case of a host name/address mismatch. Otherwise, the front ends just
  57. ignore the bad host name and use the host address when consulting the
  58. access control files.
  59.  
  60. Minor enhancements: 
  61. -------------------
  62.  
  63. The host access control files now support more types of wild cards and
  64. (optionally) allow the use of netgroup names.  Netgroup support is
  65. usually available on systems with NIS (formerly YP) software.
  66.  
  67. Related software:
  68. -----------------
  69.  
  70. Versions of rshd and rlogind, hacked to report the remote user name as
  71. well, are available for anon ftp (ftp.win.tue.nl:/pub/logdaemon.tar.Z).  
  72. That archive also contains a tftpd source that logs the remote host
  73. name (nice if you want to know who is interested in your /etc/passwd
  74. file).  All those programs have been tested only with SunOS >= 4.0.
  75.  
  76. Another way to manage access to tcp/ip services is illustrated by the
  77. servers provided with the authutil package (comp.sources.unix volume
  78. 22). This has the advantage that one will get the remote username from
  79. any host supporting RFC 931 security.  By installing the auth package
  80. (same volume) one supports RFC 931 security too (but you will have to
  81. believe what the remote host tells you).  Eventually one can start
  82. cutting off unauthenticated connections. This is obviously a much more
  83. advanced approach than what my front-end programs provide. The present
  84. package is more suitable for those who lack the resources to install
  85. anything that requires more than just renaming a couple of executables.
  86.  
  87. Configuration and installation (the easy way):
  88. ----------------------------------------------
  89.  
  90. An advanced installation recipe is given lateron. The "easy way" recipe
  91. requires no changes to existing software or configuration files.
  92.  
  93. If you don't run Ultrix, you don't need the miscd front-end program.
  94. The Ultrix miscd daemon implements among others the SYSTAT service,
  95. which pipes the output from the WHO command to standard output.
  96.  
  97. By default, the front-end programs assume that the vendor-provided
  98. daemons will be moved to the "/usr/etc/..." directory.  If you want
  99. something else, adjust the REAL_DAEMON and the REAL_DAEMON_DIR macros
  100. in the files miscd.c and tcpd.c.
  101.  
  102. By default, connections are logged to the same place where the sendmail
  103. log entries go.  If connections should be logged elsewhere, adjust the
  104. LOG_MAIL macro in the miscd.c and tcpd.c files, and update your syslog
  105. configuration file (usually, /etc/syslog.conf).  Most Ultrix versions 
  106. do not provide this flexibility, though.
  107.  
  108. By default, the front-end programs support host access control.  Access
  109. control is turned off when the /etc/hosts.{allow,deny} files do not
  110. exist. If you do not need support for host access control, adjust the
  111. makefile so that the programs are compiled without -DHOSTS_ACCESS.
  112. Note:  the host access control facility requires the strchr(), strspn()
  113. and strtok() routines.
  114.  
  115. If your C library does not provide the strcasecmp() routine, adjust the
  116. AUX_OBJ macro in the Makefile so that it uses the strcasecmp() version
  117. provided with this package.
  118.  
  119. In the Makefile, add -Dmemcmp=bcmp to the CFLAGS macro if your system
  120. does not have memcmp(), and add -DNETGROUP to the CFLAGS macro if your
  121. system supports netgroups.
  122.  
  123. Compile with -DPARANOID if you want to drop connections when a remote
  124. host name does not agree with the remote host address. This helps 
  125. against attacks through compromised domain name servers, but may
  126. occasionally cause a perfectly legal connection to be refused due to
  127. transient name server lookup problems.
  128.  
  129. The tcpd program is intended for monitoring connections to the telnet,
  130. finger, ftp, exec, rsh and rlogin services. Decide which services you
  131. want to be monitored. Move the vendor-provided daemon programs to the
  132. location specified by the REAL_DAEMON_DIR macro in the file tcpd.c, and
  133. copy the tcpd front end to the locations where the vendor-provided
  134. daemons used to be. That is, one copy of the tcpd front end for each
  135. service that you want to monitor.
  136.  
  137. Ultrix only: if you want to monitor connections to the SYSTAT service,
  138. move the vendor-provided miscd daemon to the location specified by the
  139. REAL_DAEMON macro in the miscd.c file, and install the miscd front end
  140. into the original miscd location.
  141.  
  142. Configuration and installation (the advanced way):
  143. --------------------------------------------------
  144.  
  145. Instead of moving the vendor-provided daemons to another directory,
  146. define the REAL_DAEMON_DIR to reflect the present location of those
  147. daemons, and install the tcpd command in the same directory. Then do
  148. the following edits to the inetd configuration file (usually in
  149. /etc/inetd.conf):
  150.  
  151.     telnet  stream  tcp     nowait  root    /usr/etc/in.telnetd     in.telnetd
  152.  
  153. becomes:
  154.  
  155.     telnet  stream  tcp     nowait  root    /usr/etc/tcpd           in.telnetd
  156.  
  157. (the example applies to SunOS 4.x; other UNIX implementations should
  158. not differ much). Similar changes will be needed for the other services
  159. that are to be covered by the tcpd front-end program.
  160.  
  161. Apollo UNIX users will want to install the front end under a different
  162. name because tcpd is the name of an already existing command. A suitable 
  163. name for the front-end program would be "frontd".
  164.  
  165. The same trick can be played with the Ultrix miscd daemon but then the
  166. daemon front end will have to be installed under a different name.
  167.  
  168. Acknowledgements:
  169. -----------------
  170.  
  171. Thanks to Brendan Kehoe (brendan@cs.widener.edu), Heimir Sverrisson
  172. (heimir@hafro.is) and Dan Bernstein (brnstnd@kramden.acf.nyu.edu) for
  173. feedback on an earlier release of this product.  Thanks to John Kimball
  174. (jkimball@src.honeywell.com) for suggesting the host name to host
  175. address mapping check. Willem-Jan Withagen (wjw@eb.ele.tue.nl) provided
  176. useful information on how to deal with the Apollo UNIX environment.
  177.  
  178.     Wietse Venema (wietse@wzv.win.tue.nl),
  179.     Mathematics and Computing Science,
  180.     Eindhoven University of Technology,
  181.     The Netherlands.
  182.