home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / logenh11.zip / manual.doc < prev    next >
Text File  |  1994-02-02  |  14KB  |  283 lines
  1. ==============================================================================
  2.  
  3.    **** LOGIN, PASSWD, and CNVTUNIX: A Suite of programs to secure and enhance
  4.                                               OS/2 2.x TCP/IP TelnetD
  5.  
  6.    **** By Aaron B. Brown
  7.  
  8. ==============================================================================
  9.  
  10. CONTENTS
  11. --------
  12.  
  13.         Summary
  14.         Installation
  15.         Configuration
  16.         Security and Logging
  17.         Support Information
  18.         Warranty and License
  19.  
  20.  
  21.  
  22. SUMMARY
  23. -------
  24.  
  25.         In its default implementation supplied by IBM, OS/2 TCP/IP TelnetD is
  26. full of security holes.  Its standard setup depends on a plaintext password
  27. stored in the environment; only by using the included loginunx.exe can it be
  28. modified to rely on UNIX-style DES-secure password file.  Even in this
  29. configuration, it is difficult to configure and maintains no log of telnet
  30. activity.
  31.         The combination of utilities in this package is designed to address 
  32. these problems.  Like loginunx, it relies on a UNIX-style DES-encrypted 
  33. password file.  However, it adds greatly to that functionality.  It supplies 
  34. the additional utilities needed to maintain and create the "passwd" file; it
  35. also provides much more flexibility in controlling and maintaining your OS/2
  36. telnet system.  You can configure the telnetd subsystem for each user through
  37. the passwd file, selecting shells and default directories for every entry in
  38. the passwd file. Guest access (with no password) is also available by 
  39. leaving the password field blank. The welcome banner displayed by the login
  40. program is also configurable.  Finally, the login program can also keep a full
  41. log of successful and failed login attempts, and will place the login name of
  42. the currently-logged-in user in the environment and in a file.
  43.         Also supplied is a program to convert UNIX password files to OS/2 
  44. compatible format.
  45.  
  46.  
  47. INSTALLATION
  48. ------------
  49.  
  50. 1) Create a directory to contain the password file, log file, and banner 
  51.         (welcome) files.
  52. 2) Rename the \tcpip\bin\login.exe program to loginold.exe
  53. 3) Copy the supplied login.exe and login2.exe programs to the \tcpip\bin
  54.         directory
  55. 4) Place the passwd.exe and cnvtunix.exe program in a directory in your path
  56. 5) Copy the supplied telnetd2.cmd file to \tcpip\bin.
  57. 6) Edit the telnetd2.cmd file that was just copied so that the line that says 
  58.         "SET COMSPEC=c:\tcpip\bin\login2.exe" points to the actual path where 
  59.         you just copied login2.exe.  For example, if your \tcpip\bin directory
  60.         is on drive D, change the line to:
  61.         "SET COMPSEC=d:\tcpip\bin\login2.exe".
  62. 7) If you use INETD, edit the \tcpip\etc\inetd.lst file so that the line that 
  63.         says "telnet tcp telnetd" to "telnet tcp telnetd2"
  64. 8) If you don't use INETD, always start telnetd by typing "telnetd2".  If it is
  65.         called in TCPSTART.CMD, fix it there too.
  66. 9) Setup the necessary environment variables in CONFIG.SYS as described in
  67.         "Configuration," below.
  68. 10) Reboot to allow environment variable changes to take effect
  69. 11) Configure a password file as described in "Configuration," below.
  70.  
  71. That's it!
  72.  
  73. CONFIGURATION
  74. -------------
  75.  
  76.         **** Environment Variables ****
  77.  
  78. The login and passwd programs depend on the proper settings of several 
  79. environment variables.  These variables are described below:
  80.  
  81. Variable     Set to:
  82. --------     -------
  83.  
  84. PASSWD       Drive and path of password file, i.e. c:\login\passwd.fil
  85. LOGINLOG     Drive and path of log file, i.e. c:\login\login.log. If 
  86.                 logging is not desired, do not set this variable.
  87. LOGINBAN     Drive and path of welcome banner, i.e. c:\login\welcome.txt. This
  88.                 file will be displayed before the login prompt.
  89. LOGINOK      Drive and path of file to be displayed when someone successfully
  90.                 logs in.
  91. TELPROMPT    The prompt to be used by shells spawned by the login program, 
  92.                 i.e. "[%hostname%] $p$g"
  93. LOGINNF      Drive and path for the file in which the login name of the 
  94.                 currently logged-in user is placed.
  95.  
  96.         **** The Password File ****
  97.  
  98. The password file used by this set of programs is similar to that of a UNIX 
  99. "passwd" file.  Each line represents the data for one user, and is in the 
  100. following format:
  101.  
  102. username:encrypted_password:0:shellflag:Real Name:default_dir:;default_shell
  103.  
  104. This format differs from the UNIX format in the extra semicolon before the 
  105. default shell and the different usage of the two fields following the 
  106. encrypted password.
  107.  
  108. USERNAME: the name that the user will type when logging in
  109. ENCRYPTED_PASSWORD: the DES-encrypted password for the user
  110. 0: this is a reserved field and should be set to 0
  111. SHELLFLAG: This field can be set to 1 or 0 to determine the method that will 
  112.         be used to present the user with a shell.  If it is set to 1, the 
  113.         shell listed in the default_shell field will be spawned directly by 
  114.         the login program upon a successful login.  In this case, the initial
  115.         directory will be that specified in the default_dir field, and the
  116.         user's username will be placed in the environment variable "TELUSER."
  117.         Note that TELNETD.CMD will NOT be called if this option is used, but a
  118.         prompt can still be set with the TELPROMPT environment variable. If
  119.         this flag is set to 0, the standard sequence will be followed:
  120.         TELNETD.CMD will be processed and the default system shell (usually
  121.         \os2\cmd.exe) will be called by TelnetD.
  122. REALNAME: This field is used to hold the real name of the user
  123. DEFAULT_DIR: This field contains the default directory of the user.  If 
  124.         shellflag is set to 1, this will be the first directory presented to 
  125.         the user when the shell is spawned.  This field has no effect when
  126.         shellflag is set to 0. This field should be in a fully-qualified drive
  127.         and path form, but using FORWARD SLASHES! For example, c:/tcpip/public
  128.         or d:/
  129. DEFAULT_SHELL: This field holds the drive and path of the shell that will be 
  130.         spawned by the login program.  This field has no effect when 
  131.         shellflag is set to 0.  The shell should be specified in 
  132.         fully-qualified drive and path format, but using FORWARD SLASHES, i.e.
  133.         c:/os2/cmd.exe or d:/4os2/4os2.exe.  To disable user login, set the
  134.         default_shell field to a nonexistent path.  Note also that this field 
  135.         is delimited by a colon followed by a semicolon.
  136.  
  137.         **** Setting up the Password File ****
  138.  
  139. NOTE:If you already have a UNIX password file, see below on the usage of the
  140.         CNVTUNIX utility.
  141.         
  142. To create and configure the password file, the PASSWD.EXE program should be 
  143. used. Note that the environment variables MUST be set as specified above 
  144. before you configure the password file.  
  145.  
  146. To create a new password file, run the PASSWD program with no arguments. You
  147. will be prompted to create a root entry in the new password file; the password
  148. you supply will be required to add users to the password file, and must be 
  149. used to change the shell/directory information for other users.
  150.  
  151. The PASSWD program takes up to 2 arguments.  The first is a switch which 
  152. specifies the action you wish to take (see below).  If no switch is specified, 
  153. it is assumed that you wish to change a password.  The other argument that is 
  154. accepted by PASSWD is the username. For example, to change the password for 
  155. user "sample," type: "passwd sample." To change the default directory for user 
  156. "sample," type: "passwd -d sample."  If you do not specify the username on the
  157. command line, PASSWD will prompt for it.
  158.  
  159. A summary of (mutually exclusive) command-line switches follows:
  160.  
  161.         <none>:   change password
  162.         -a:       add new password file entry
  163.         -r:       remove password file entry
  164.         -n:       change real name field
  165.         -s:       change default shell field
  166.         -d:       change default directory
  167.         -p:       change shell launching preference
  168.         -h of -?: show help screen
  169.  
  170. Note: Guest Access
  171.         To set up guest access (i.e. access which does not require a password) 
  172.         for a specific user, just hit return each time when prompted for the 
  173.         username. The password field will be then set to nothing.
  174.  
  175.         **** Using the CNVTUNIX utility ****
  176.  
  177. The CNVTUNIX utility can be used to convert UNIX-style password files to OS/2 
  178. password files. It will retain the username, password, and realname fields, 
  179. and replace the other fields with OS/2 specific equivalents. The syntax of the
  180. CNVTUNIX command line is:
  181.  
  182.         cnvtunix <sourcefile> <destfile> <defdir> <defshell> <shellpref>
  183.  
  184. <sourcefile>:   UNIX password file to be converted
  185. <destfile>:     OS/2 password file to be created
  186. <defdir>:       default directory to be used for all users
  187. <defshell>:     default shell to be used for all users
  188. <shellpref>:    1 if default shell is to be used, 0 if telnetd.cmd is preferred
  189.  
  190. Note that if <destfile> exists, it WILL BE OVERWRITTEN.
  191. The <defdir>, <defshell>, and <shellpref> fields will be inserted into every 
  192. entry in the new OS/2 password file.  Individual entries can then be 
  193. configured with the PASSWD utility.
  194.  
  195. IMPORTANT: If there is not already an entry for "root" in the password file, 
  196.         run PASSWD with no command-line options to create this essential entry
  197.         before using LOGIN or PASSWD!
  198.  
  199.  
  200. SECURITY AND LOGGING
  201. --------------------
  202.  
  203.         The OS/2 operating system was not designed to be a multiuser operating
  204. system, and thus does not have a protected, multiuser file system. However,
  205. IBM's TCP/IP kit essentially converts OS/2 into a multiuser OS without greatly
  206. increasing its security. The package of programs included here greatly 
  207. increases the _access_ security of your machine; it is much more difficult for 
  208. a user to obtain Telnet access when the supplied login system is in place.
  209. However, it is not foolproof, and it cannot insure security once the login
  210. process has been completed.
  211.         The password file used by these programs contains DES-encrypted
  212. passwords that are extremely difficult to crack. Unlike UNIX systems which 
  213. use the same encryption scheme, though, the OS/2 password file is by nature
  214. world readable and writable. Thus anyone with access to the physical machine,
  215. or with FTP or Telnet Shell access can modify the password file, potentially
  216. removing or blocking other user logins.
  217.         If you are planning to give access to people in whom you do not have 
  218. complete confidence, I recommend that you use the capability of this login 
  219. program to spawn a shell, and set that shell to a menu-driven, uninterruptable
  220. program that insulates the user from the filesystem; that's what I've done on 
  221. my machine and haven't yet had security problems. To disable a user's access,
  222. set their shell to a nonexistent file, such as c:/nul.nul.
  223.         To help insure the security of the system further, and to help 
  224. identify break-ins, the login program supports full logging of access attempts,
  225. both correct and incorrect.  If the environment variable "LOGINLOG" is set to a
  226. correct path and filename, the login program will record the time, date, and 
  227. username for each login attempt. The login program will also store the name of 
  228. the current correctly-logged-in user in the file specified by the LOGINNF 
  229. environment variable; the same username will be placed in the environment
  230. variable TELUSER. These are reset with each correct login, but can be used by a
  231. shell or other program to track security and logins.
  232.      Finally, note that these programs have no effect on FTP, RSH, LPR, or
  233. any other daemon's security. They affect ONLY TelnetD.
  234.  
  235.  
  236. SUPPORT INFORMATION
  237. -------------------
  238.  
  239. Please send bug reports and suggestions for future versions to 
  240. abrown@husc.harvard.edu.
  241.  
  242. Technical support is available to registered users; see the REGISTER.DOC file 
  243. included with this archive for more information on registering.
  244.  
  245.  
  246. WARRANTY AND LICENSE
  247. --------------------
  248.  
  249. This software is shareware.  You may evaluate it free-of-charge for 15 days.
  250. If you intend to use this software after the 15 day trial period, please 
  251. register it. See the included REGISTER.DOC for more information.
  252.  
  253. This software is provided "as-is." Aaron B. Brown disclaims all warranties,
  254. whether expressed or implied, including without limitation warranties of 
  255. fitness and merchantability with respect to this software and the accompanying
  256. documentation.  Neither Aaron Brown nor anyone associated with him are
  257. responsible for any damages incurred through the use of or the inability to 
  258. use this software.  By using this software, you agree to these terms.
  259.  
  260. This software is shareware.  If you continue to use this software after the
  261. 15-day trial period has elpased, a registration fee is required.  If you
  262. register this software, you will receive notification of new releases as they
  263. are made available, and will be entitled to receive free upgrades when they
  264. are released.
  265.  
  266. This software may be distributed freely, provided that there is no fee
  267. charged for the program, and that all of the original files are included
  268. in the distribution without modifications.  A distribution fee may be
  269. charged, provided that no special fee is charged for this software.
  270.  
  271. This software is Copyright (c) 1994 by Aaron B. Brown.
  272. Portions Copyright (c) 1989 The Regents of the University of California.
  273. All rights reserved.
  274.  
  275. +-------------------------------+---------------------------------------+
  276. | *  Aaron B. Brown           * |   "The way out is through the door.   |
  277. | *  Harvard University '97   * |        How can it be that so few      |
  278. | *  abrown@husc.harvard.edu  * |            people use it?"            |
  279. |-------------------------------+---------------------------------------|
  280. |   ****** Finger abrown@husc7.harvard.edu for PGP public key ******    |
  281. +-------------------------------+---------------------------------------+
  282.  
  283.