home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 2 / 2601 < prev    next >
Encoding:
Text File  |  1991-01-22  |  7.9 KB  |  162 lines

  1. Newsgroups: alt.sources
  2. From: jaques@setprv.vro.dec.com (Robert Royal Jaques)
  3. Message-ID: <1991Jan22.210439.16791@pa.dec.com>
  4. Subject:cops0 
  5. Date: Tue, 22 Jan 91 21:04:39 GMT
  6.  
  7. In article <9886@as0c.sei.cmu.edu>, df@sei.cmu.edu (Dan Farmer) writes:
  8. From: df@sei.cmu.edu (Dan Farmer)
  9. Subject: cops 0 of 8
  10.  
  11.  
  12.  To all women and men of the net, greetings...
  13.  
  14.   Here are the latest changes, additions, and bug fixes to COPS; this brings
  15. it up to version 1.02, for those who care.  My personal stash (the latest
  16. copy) should always be available via anon-ftp at cert.sei.cmu.edu
  17. (128.237.253.5), in ~pub/cops.  In this header, I'll go through some
  18. thoughts, background notes, then finally get to the changes made, so if
  19. you don't want to listen to me, just unpack the shar files, read the README
  20. file, follow instructions, and you should be ready to roll.
  21.  
  22.   For those who don't know, COPS is a static security checking tool that
  23. checks common procedural (non-bug) problems of a Un*x system.  It basically
  24. takes a snapshot of a system, and then generates a report of it's findings.
  25. On a purely empirical basis, it has successfully discovered problems that
  26. could compromise root on over 3/4 or more of the systems I've run it on; of
  27. course, the idea here is not to break root, but to let someone fix the
  28. problems it shows.  Note, of course, that it gives info indiscriminately, to
  29. whoever runs it.  Decide if you do or don't want to learn about the
  30. information it can give about your system, but remember -- someone else
  31. probably already has it.
  32.  
  33.   After writing COPS, I started working for CERT.  I had always suspected,
  34. but didn't know, that most breakins were caused by pretty trivial problems...
  35. now I *know* it's true (or at least the ones we've found out about :-)).
  36. In the breakins I've seen while working for CERT, using COPS probably could
  37. have prevented 60-75% of them.  The most common problems?  Poor passwords,
  38. guest accounts, accounts with no passwords, and improperly managed systems
  39. (+ in host.equiv, poorly set up remote daemons, etc.)  Interestingly, to
  40. me at least, I wrote the original intro to COPS exactly one year ago today.
  41. How times don't change... I was worried this would be fairly obsolete soon,
  42. but it looks like it'll be good at least for another few years.
  43.  
  44.    The kit is broken into modules, each one driven by a master shell script;
  45. you can usually get it running within 30 minutes or so if you've never used
  46. it before (5 or 10 if you only scan the README); if you've used it in the
  47. past, you can set it up on a new machine in a minute or two.  With no
  48. modifications, it takes perhaps 2 to 30 minutes to generate a report;
  49. however, the password cracking program can add lots of time to this,
  50. depending on the options.  There is also a SUID finder, which can also take
  51. a long time (hours) to run, since it does a "find" on "/".  There's a new
  52. option that tells it not to mail a report if the results are the same as
  53. the last report, so you can just stuff it into cron and wait until a report
  54. comes around.  Of course, if someone breaks in, changes cron, and you just
  55. rely on COPS, then you're f*cked anyway.  Use it as a tool, not as a crutch.
  56.  
  57.    Ok, changes... there are a couple of totally new modules here.  One is
  58. simply labled "misc.chk"; this checks for a potpourri of things -- right
  59. now it checks for unrestricted tftp, uuencode & decode problems (including
  60. the "decode" alias) writability of things in /etc/inetd.conf|/etc/services,
  61. and to see if rexd is enabled.  The second is a CRC generator, called,
  62. amazingly enough, "crc.chk" (Jon Zeef was kind enough to let me use his
  63. version).  It's similar to the SUID trouble finder, in that you run it once,
  64. create a database, then compare future runs against that standard.  It
  65. reports any changes that are found.  There are some problems with this -- 
  66. nothing is functionally wrong with the program, as far as I know, but there
  67. are a few operational hazards -- for more information, read the README file,
  68. and the man page.
  69.  
  70.    Now the rest... I'll try to put the more important things at the top,
  71. but perceptions vary, of course.  Here are the major changes I can remember:
  72.  
  73. -- a newer, faster, better, more powerful version of kuang, in perl, is
  74.    included.
  75.  
  76. -- an anonymous ftp setup checker (ftp.chk -a)
  77.  
  78. -- the SUID finding program now also flags any world writable SUID files and
  79.    SUID shell scripts.
  80.  
  81. -- you can optionally check only passwords that have changed since the last
  82.    time they were checked (pass_diff.chk.)
  83.  
  84. -- optionally, cops will mail you a report only if things have changed since
  85.    last report.
  86.  
  87. -- the password cruncher can chew on arbitrary password files now, plus some
  88.    bugs fixed.  Interesting how this program, the main one I didn't write/port,
  89.    generates more little bugs than all the others... the original program
  90.    worked fine (written by Craig Leres and Jef Poskanzer), but the more
  91.    features that were added by different people over the years, the more
  92.    things broke.  I should have just included my perl version instead.
  93.  
  94. -- checks made for world writable files now looks at the parent directory
  95.    structure of a path, instead of just the file.
  96.  
  97. -- New, optional directory structure (for multiple machine/binary sites) for
  98.    the entire system.  Reports are now saved in a file with the name
  99.    "year_month_day", and by default, are saved in a directory with the
  100.    same name as the host.  Looks something like:
  101.  
  102.    $SECURE/cops
  103.                | -- docs
  104.                | -- src
  105.                |--- archtype1 binaries (sun, or whatever)
  106.                |             |
  107.                |             | - results for sun workstation 1
  108.                |             | - results for sun workstation 2
  109.                |       
  110.                |--- archtype2 binaries(dec)
  111.                |             |
  112.                |             | - results for dec workstation 1
  113.                |             | - results for dec workstation 2
  114.                |            
  115.                |--- archtype3 binaries(vax)
  116.                              |
  117.                              | - results for vax 1
  118.                              | - results for vax 2
  119.  
  120.    You run "cops archtype", and it would cd into the binary directory,
  121.    use those binaries, and put any results in a subdirectory of the
  122.    appropriate host name.  Results would be stored with a date as the title,
  123.    not some stupid number.  Alternately, you can just run "cops", and it will
  124.    take your hostname as a directory to store the results.  More in the
  125.    README file, under "How to Configure/Install COPS".
  126.  
  127. -- user.chk checks .logout and .rhosts files (was .rhost) now, too, as well
  128.    as reporting if any .netrc files are readable.
  129.  
  130. -- file.chk and dir.chk have been replaced by is_able.chk, which performs
  131.    the same function, with hopefully more flexibility and ease of use.
  132.  
  133. -- scripts now start with a ":" on line 1 instead of #!/bin/sh, since it
  134.    didn't work on some stupid machines.
  135.  
  136.  
  137.    The easiest thing to do is unpack everything, scan the README file,
  138. change whatever it tells you, run "reconfig", if you have a sysV based machine,
  139. or are just suspicious of your system, then blast off.  Finally, to steal an
  140. ending from the README file of a year ago...
  141.  
  142.   "So good luck, and I hope you find COPS useful as we plunge into UNIX
  143. of the 1990's.
  144.  
  145.    dan farmer
  146.    January 31, 1989"
  147.  
  148.  
  149.  -- dan
  150.    jan 31, 1990
  151.  
  152. --
  153. ___________________________________________________________________________
  154. |          any relation with reality is purely coincidental               |
  155. |_________________________________________________________________________|
  156. |  Robert R Jaques    !! dr bob !!         |  Mail addresses              |
  157. |  Digital Equipment Corporation           |  jaques@setprv.vro.dec.com   |
  158. |  Cororate Telecommunication Engineering  |  setprv::jaques              |
  159. |  Concord, MA                             |  bob jaques @ vro            |
  160. |  tel 508-371-5162  dnt 273-5162          |                              |
  161. ___________________________________________________________________________
  162.