home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / c / cops_104.zip / cops_104 / README.3 < prev    next >
Text File  |  1992-03-10  |  9KB  |  172 lines

  1.  
  2. Continued Use and Installing COPS
  3. ----------------------------------
  4.  
  5.    Once you are satisfied that COPS indeed does something useful
  6. (hopefully this will occur :-)), a good way to use it is to run it on at
  7. least a semi-regular basis.  Even if it doesn't find any problems
  8. immediately, the problems and holes it detects are of the sort that can
  9. pop up at any given time.  One way of running COPS might be to run it as
  10. an "at" job or by cron (if you run suid.chk via cron, use the "-s" flag
  11. to tell cron where the rest of the COPS programs are, or it will chmod
  12. "/" to mode 700, among other things).
  13.  
  14.    I strongly advise that whatever directory COPS is placed in be
  15. readable, writable, and executable only by the owner (typing "chmod 700
  16. /usr/foo/bar" or whatever the name is will do this) of the directory.
  17. This is to prevent prying eyes from seeing any security problems your
  18. site may have.  Even if you don't think of them as important, someone
  19. else might come around and change your mind.  Since COPS is fairly
  20. configurable, an intruder could easily change the paths and files that
  21. COPS checks for, hence making it fairly worthless.  Again, this comes
  22. back to the point that COPS is only a tool -- don't put down your
  23. defensive shields merely because COPS says "all clear".  If this sounds
  24. paranoid, it is!  Security people are traditionally paranoid, for a
  25. reason...  In any case, it is probably not a good idea to advertise any
  26. (even) potential weaknesses.
  27.  
  28.    If you use the shell/C version, typing "make install" will create (if
  29. necessary) a subdirectory with the name you put in $INSTALL_DIR (found
  30. on line 7 of "makefile"); if you run a network with multiple
  31. architectures, you can have several executable versions of COPS in the
  32. same NFS-mounted directory structure.
  33.  
  34.   You can run COPS with "cops -a archtype", and it will cd into the
  35. archtype directory, use the binaries or config files in that directory
  36. (placed there by a "make install"), and put any results in a
  37. subdirectory of the archtype directory with the appropriate host name.
  38. You can set the secure directory (the directory that COPS finds all of
  39. the programs in and places the results in) by either invoking COPS with
  40. the -s flag (both shell and perl versions), or by setting the $SECURE
  41. variable in the "cops" shell script (line 93.)
  42.  
  43.    For example, assume you have the following setup, and run COPS with:
  44.  
  45. machine architecture    hostname    If run COPS with:
  46. =====================   ========    ==================
  47. cray                    ribcage     cops         -s /usr/secure
  48. vax                     bar         cops -a vax  -s /usr/secure
  49. vax                     foo         cops -a vax  -s /usr/secure
  50. sun                     earth       cops -a sun3 -s /usr/secure
  51. sun                     mars        cops -a sun3 -s /usr/secure
  52. sun                     venus       cops -a sun4 -s /usr/secure
  53. mips                    hades       cops         -s /usr/secure
  54.  
  55.   The resulting directory/reporting structure would be (all reports
  56. would be placed in a file named "year_month_day"):
  57.  
  58. /usr/secure/cops/ribcage
  59. /usr/secure/cops/vax/bar
  60. /usr/secure/cops/vax/foo
  61. /usr/secure/cops/sun3/earth
  62. /usr/secure/cops/sun3/mars
  63. /usr/secure/cops/sun4/venus
  64. /usr/secure/cops/hades
  65.  
  66.   Sometimes you will get the same report over and over again, everytime
  67. you run COPS; for instance, with Ultrix 3.x, /dev/kmem is world
  68. readable.  This is a security hole, but many utilities in Ultrix need
  69. this to function.  If you wish to only see reports that are _different_
  70. than the old reports, you first need to have an older report saved in a
  71. file (in $SECURE/hostname, or wherever you usually save the reports).
  72. In the shell version, you can either do:
  73.  
  74.    cops -m user
  75.  
  76. or:
  77.  
  78.    set "MMAIL=YES" (line 55)
  79.    set "ONLY_DIFF=YES" (line 66)
  80.  
  81. in "cops".  In the perl version, do:
  82.  
  83.    set "$ONLY_DIFF=1" (line 11 of the config file)
  84.  
  85.   Every time COPS is run after that, it will compare the report it
  86. generated for the current check with the old report; if it detects any
  87. differences, it will mail you a report.  If not, it will simply discard
  88. it.  This can be a real boon for a site with a lot of machines running
  89. COPS every night.
  90.  
  91.   Alternately, you can use a "filter_file" to filter out repetative
  92. messages.  There is an example filter file, "cops_filter", that is
  93. included in the package.  It is used by simply typing "cops -f cops_filter",
  94. and can be both very useful and very dangerous.  Useful for obvious
  95. reasons, dangerous because it can cause valid warning messages to be
  96. thrown away before you get to see them.
  97.  
  98.    There are a couple of further options you may wish to explore.  First
  99. of all, since so many breakins are because of poor password selection by
  100. users, it would be a wise idea to add options to your password checking
  101. program (line 200 in "cops", or line 72 in "cops.cf" for perl users).
  102. You may wish to try some words from a dictionary; you may use either
  103. your system dictionary (usually found in /usr/dict/words), or you may
  104. use the same dictionary that the internet worm found so lucrative when
  105. hitting all those thousands of hosts; that dictionary is in the file
  106. "pass.words".  For example, the way to include the worm dictionary (e.g.
  107. the dictionary r.t.m. used in his Internet Worm) is:
  108.  
  109.   pass.chk -w pass.words
  110.  
  111.   Also, try some of the options in the password program, such as "-b",
  112. "-g", "-s", and "-c", which add checks for backward, gecos, single
  113. letter & number, and upper and lower case guesses, respectively.  Of
  114. course, each option will increase the time needed to crack the
  115. passwords, so experiment!  See what is reasonable for your hardware
  116. capabilities and resources.
  117.  
  118.   I've included the fast crypt functions that are used in Crack; if you
  119. want to try those (highly recommended!), uncomment lines 96-97 in the
  120. makefile, and comment out the normal compile line (95).  Better yet,
  121. get the full Crack package from uunet.uu.net or somewhere else.  It
  122. does a great job at cracking passwords.  I might try to integrate the
  123. whole package at some later time, but it might just be wasted work;
  124. they work well separately.
  125.  
  126.    By using the "pass_diff.chk" program, you can check only accounts
  127. that have _changed_ their password since the last time you've checked --
  128. this can save enormous amounts of time with large systems.  This way,
  129. you can check your users thoroughly once, then only check them when
  130. their passwords change (possibly to something less secure).  Be careful,
  131. though, if you use this and then later expand your checks and/or the
  132. dictionary you use to search for passwords, since the earlier accounts
  133. that were already checked with an inferior method will not be checked
  134. again until they change their password.  See the file "passwords" in the
  135. "extensions" directory for a replacement "passwd" program that can
  136. disallow poor passwords to begin with.
  137.  
  138.    The file "is_able.lst" contains a list of files that are to be
  139. checked for world readability and/or writability.  You should look at
  140. this file and add or delete any files you feel are important to your
  141. system.
  142.  
  143.    After running COPS, if any warnings are given that compromise any
  144. individual user's account (such as a world writable .profile or home
  145. directory, a guessed password, etc.), and the problem is not corrected
  146. immediately (or you are not sure whether or not it is worth hassling the
  147. user to change it), try this:
  148.  
  149.    If you are using the shell version, edit the file "init_kuang", and
  150. add the compromised user(s) uids and groups in their respective target
  151. lines (below lines 20 and 26, respectively).  If you are running the
  152. perl version, create a file with the compromised users listed in it (see
  153. kuang.1 in the perl distribution).  Now run kuang again to see if the
  154. users can compromise the entire system.  You may change your mind about
  155. not thinking they are a problem!  In addition, kuang does not have to
  156. have "root" as a target (the last line).  Try putting in system
  157. administrators or other powerful figures to see if they are in danger as
  158. well.  If you have "perl" installed on your system, try the perl version
  159. of kuang -- "kuang.pl" (you'll have to unpack the shar file this is
  160. inside -- "kuang.pl.shar", and you may have to edit the first line of the
  161. file "kuang.pl", to reflect where the location that perl is on your system),
  162. because it is a more powerful, faster, and more versitile version.
  163.  
  164.   That's it!  Congratulations for reading this far :-)  Browse around
  165. the COPS directories for more goodies; the "extra_src", "docs", and
  166. "extensions" directories all have interesting things in them.  Don't
  167. forget to try CARP to analyze your network's data (*ONLY USABLE WITH
  168. "cops -v" RESULT FILES*) , and let me know how it goes.  Finally, good
  169. luck.  Send me ideas, flames, kudos, whatever.
  170.  
  171.  -- dan
  172.