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 / cover_letter < prev    next >
Text File  |  1992-03-10  |  8KB  |  137 lines

  1.  
  2.  Women and men of the net, greetings...
  3.  
  4.   Gone are the days when COPS was sleek, trim, and new.  It has joined
  5. the ranks of modern software -- bloated, overladen with potentially
  6. useless features, overhyped and underloved.  Here are the latest changes,
  7. additions, and bug fixes to COPS -- this brings it up to version 1.04, for
  8. those who care.  I skipped version 1.03 because the beta copy that I put
  9. out is so hopelessly out of date that it didn't make a lot of sense to
  10. continue with 1.03.  Anyway, my personal stash (the latest copy) should
  11. be available via anon-ftp at archive.cis.ohio-state.edu (128.146.8.52),
  12. in ~pub/cops/1.04.  In this header, I'll go through some thoughts,
  13. background notes, then finally get to the changes made, so if you don't
  14. want to listen to me, just unpack the shar files, read the README file,
  15. follow instructions, and you should be ready to roll.
  16.  
  17.   For those who don't know, COPS is a static security checking tool that
  18. checks common (mostly) procedural problems of a Un*x system.  It basically
  19. takes a snapshot of a system, and then generates a report of it's findings.
  20. On a purely empirical basis, over the years it has successfully discovered
  21. problems that could compromise root on more than 3/4 or more of the systems
  22. I've run it on; of course, the idea here is not to break root, but to let
  23. someone fix the problems it shows.  Note, of course, that it gives info
  24. indiscriminately, to whoever runs it.  Decide if you do or don't want to
  25. learn about the information it can give about your system, but remember --
  26. someone else probably already has it.
  27.  
  28.   After writing COPS, I started working for CERT.  I had always suspected,
  29. but didn't know, that most breakins were caused by pretty trivial problems...
  30. now I *know* it's true (or at least the ones we've found out about :-)).
  31. In the breakins I've seen while working for CERT, using COPS probably could
  32. have prevented 60-75% of them.  The most common problems?  Poor passwords,
  33. guest accounts, accounts with no passwords, and improperly managed systems
  34. (+ in host.equiv, poorly set up remote daemons, etc.)  Interestingly, to
  35. me at least, I wrote the original intro to COPS over two years ago.
  36. How times don't change... I was worried this would be fairly obsolete soon,
  37. but it looks like it'll be good at least for another few years.
  38.  
  39.    The kit is broken into modules, each one driven by a master shell script;
  40. you can usually get it running within 30 minutes or less if you've never used
  41. it before (5 or 10 if you only scan the README); if you've used it in the
  42. past, you can set it up on a new machine in a minute or two.  With no
  43. modifications, it usually takes somewhere 2 to 30 minutes to generate a
  44. report; however, the password cracking program can add lots of time to this,
  45. depending on the options.  There is also a SUID finder, which can also take
  46. a long time (hours) to run, since it does a "find" on "/".  There's a new
  47. option that tells it not to mail a report if the results are the same as
  48. the last report, so you can just stuff it into cron and wait until a report
  49. comes around.  Of course, if someone breaks in, changes cron, and you just
  50. rely on COPS, then you're f*cked anyway.  Use it as a tool, not as a crutch.
  51.  
  52.    Ok, changes... The main thing is that the whole thing (more or less)
  53. has been ported to perl; both shell and perl versions are included and
  54. will probably be supported in the future.  They have various differences,
  55. some intentional, some not, but I have attempted to keep them as similar
  56. as possible.  Tom Christiansen did a large part of the work on this part
  57. (thanks again, tom!), but there were several people involved in the perl
  58. work... see "README.perl" and the perl subdirectory for more info.  Warning;
  59. the perl version, for a variety of reasons (mostly detailed in "README.2.pl"
  60. is not as robust as the shell version.
  61.  
  62.   There is one new major module here -- "bug.chk" (all of this is
  63. in the subdirectory "bugs").  This takes most of the CERT security
  64. announcements (those relating to bugs and vulnerabilities, at least) and
  65. attempts to see if your host might have the problem.  Some problems come
  66. up with a good way to check for these problems, not the least of which is
  67. that I am taking a very conservative route (i.e.  probably not a very good
  68. way of handling it) to see if a host has bugs.  See the man page for
  69. "bug.chk" for more details.
  70.  
  71.   In addition, there is a new program, a kind of "personal-cops",
  72. called "checkacct" (found in the directory of the same name.)  This 
  73. interactive program does a variety of checks, some done in cops, some not
  74. (searching for individual S[UG]ID files, writable user directories,
  75. .rhosts parsing/checking) that can be run by an individual to check
  76. their account security.  This was done by some friends at purdue,
  77. most notably shabbir safdar.
  78.  
  79.   Here are the rest of the major changes I can think of:
  80.  
  81. -- a new program, "carp" (look in the "carp" subdirectory), looks at
  82. COPS output from several machines (presumably from your network) and
  83. attempts to give a kind of scoresheet of what it found wrong with your
  84. system, with weighted values.  It outputs either standard text, postscript,
  85. and has an X (as in windows, not that you'll have to be 18 to look at)
  86. previewer.  Like all new features, I'm not sure if this is particularily
  87. useful (perhaps more for impressing management with pretty pictures, but
  88. it might be good for seeing trends or interesting tidbits not otherwise
  89. discernable), but time (or, rather, you, the users) will tell.  Let me
  90. know what you think.  This is *ONLY* useable with "cops -v" output!
  91.  
  92. -- a filter for COPS (originally named by default "cops_filter") makes
  93. it possible to get rid of those pesky "Warning!  /dev/printer is _World_
  94. writable!" messages.  Use "cops -f cops_filter" to use.
  95.  
  96. -- Code has been cleaned up, tons of flags/options have been added to make
  97. things easier to use, documentation has been updated.
  98.  
  99. -- a fast crypt is included, stolen right from that wonderful password
  100. cracker everyone knows and loves, Crack.  I'm not about to say you
  101. should use my password cracker instead of crack -- if you can use crack,
  102. use it!  However, it might prove to be a easy/painless alternative if
  103. you decide that crack doesn't fit your time constraints or something.
  104. You can try uncommenting lines 91 and 92 in the makefile for this.
  105.  
  106. -- a more powerful version of perl kuang is included.
  107.  
  108. -- a new directory, "extra_src" has been created, and contains a few
  109. miscellaneous programs that couldn't quite fit in with the rest of this
  110. release, but are fairly important or useful in their own right.  Some
  111. of these programs will go into future versions of COPS.  There is a
  112. README file that briefly describes the programs there.  BTW, if you use
  113. uucp, make sure you look here!
  114.  
  115. -- two mini-papers have been put in the "extensions" directory.  One
  116. is a very useful article on how to harden your uucp site, the other
  117. is a good paper on how to write a SUID program correctly.
  118.  
  119.    The easiest thing to do is unpack everything, scan the README file,
  120. read either the README.shell or README.perl file (depending on which one
  121. you'd like to use), and finally look at the README.final file.  Alternately,
  122. you can read the "quick_start" file if you're impatient.  If you're not totally
  123. sure that the pathnames to the executables are correct, then you should
  124. run "reconfig" (if you have a sysV based machine, or are just suspicious
  125. of your system, you should do this anyway.)  After all that, just
  126. type "./cops", and blast off.  Finally, to steal an ending from the README
  127. file of a few years ago...
  128.  
  129.   "So good luck, and I hope you find COPS useful as we plunge into UNIX
  130. of the 1990's.
  131.  
  132.    dan farmer
  133.    January 31, 1989"
  134.  
  135.  -- dan
  136.    March 6, 1992
  137.