home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / admin / policy / 968 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  4.6 KB
  1. Xref: sparky comp.admin.policy:968 alt.comp.acad-freedom.talk:2686
  2. Newsgroups: comp.admin.policy,alt.comp.acad-freedom.talk
  3. Path: sparky!uunet!gatech!darwin.sura.net!ukma!morgan
  4. From: morgan@ms.uky.edu (Wes Morgan)
  5. Subject: Re: Policy regarding Crack
  6. References: <1992Aug26.170825.29391@m.cs.uiuc.edu> 
  7.     <1992Aug26.174017.1077@ms.uky.edu> <CKD.92Aug26221743@loiosh.eff.org>
  8. Message-ID: <1992Aug27.115813.28741@ms.uky.edu>
  9. Date: Thu, 27 Aug 1992 15:58:13 GMT
  10. Organization: The Puzzle Palace, UKentucky
  11. Lines: 85
  12.  
  13. ckd@eff.org (Christopher Davis) writes:
  14. >
  15. > Wes>     - I can set a simple policy that says "this system is not to be used
  16. > Wes>       for the development or use of password cracking software".  My users
  17. > Wes>       are Engineering students; they have no curricular need to develop
  18. > Wes>       such software on our systems.  
  19. >
  20. >
  21. >Or you could run shadow passwords, and run Crack yourself, and have a
  22. >proactive password checker.
  23.  
  24. I run Crack and COPS on a regular basis; a real-time password checker
  25. is in the works.  8)
  26.  
  27. >This also benefits everyone, because it means that people are less
  28. >likely to have their accounts broken into, you don't get into problems
  29. >with people being duped into giving out your /etc/passwd for Joe Cracker
  30. >to run through Crack on his 486/50 (or on the SS2 he broke into last
  31. >week), and even if someone does get your shadow file, your passwords
  32. >will have some degree of strength.
  33. >
  34. >I realize that this isn't always doable, but it's a big improvement.
  35.  
  36. There are external factors to be considered........
  37.  
  38. Here's a "real world" problem:
  39.  
  40. Earlier this year, I received a call from an admin at another university.  
  41. He found a user cracking his (and other) systems, and proceeded to follow 
  42. the normal procedures for disciplinary proceedings.  During the ensuing 
  43. investigation, it was discovered that this individual had copies of password
  44. files from many sites; system accounting records revealed that he had also
  45. been running Crack.  During the auditing of his files, electronic mail 
  46. archives indicated that some of those password files may have come from my 
  47. university; the admin requested my assistance in tracking down the (possibly) 
  48. compromised systems.
  49.  
  50. Thankfully, none of the systems here were compromised (or even attacked).
  51. However, I discovered that this cracker had accumulated password files
  52. from at least 10 different systems in 5 states.  
  53.  
  54. { Enter philosophical mode }
  55.  
  56. Many people have spoken of the "cooperative spirit" of networking.  We've
  57. discussed policies, shared code, and helped each other through problems.
  58.  
  59. I've been a sysadmin for 4 years, and I've used Unix for 11 years.  However,
  60. many sites' admins are inexperienced; indeed, many of them become sysadmins
  61. by default.  (How many times have we seen postings such as "I've just been
  62. told that I'm going to be administering our Sun workstations, so....."?)  Many
  63. of those novice sysadmins depend on the assistance of their more experienced
  64. colleagues. 
  65.  
  66. In some ways, we *are* our 'brother's keeper'.
  67.  
  68. Why, then, should our assistance be restricted to reactive functions?
  69. If I can take steps to prevent potential problems WITHOUT affecting
  70. my core mission (Engineering education, in my case), why *shouldn't*
  71. I do so?  
  72.  
  73. [As I mentioned in an earlier posting, some sites may have a curricular
  74.  (or professional) obligation to provide facilities for cryptographic
  75.  work.  Were I in such a situation, I would find some means of isolating
  76.  them from 'live' systems.  This university recently offered a CompSci class 
  77.  entitled "Computer Security"; in the course of instruction, the students 
  78.  were given a copy of Crack.  At the request of the instuctor, I created a 
  79.  dummy /etc/passwd file which was completely devoid of "real world" informa-
  80.  tion.  The appropriate warnings against extracurricular use of the program 
  81.  were issued, the course proceeded, and everyone was satisfied.]
  82.  
  83. I believe that I, as a sysadmin, have a certain obligation to the other
  84. systems using our common network(s).  Why should I allow my system to be
  85. used as a 'forward base' from which to attack other systems?  Should I
  86. adopt an attitude such as "well, he's not cracking MY password file, so
  87. I don't care"?  If I found someone attempting to crack the password file 
  88. for kragar.eff.org, wouldn't you want me to notify you?  If so, why shouldn't 
  89. I prevent it in the first place, if such a goal is (relatively) attaniable?
  90.  
  91. { Exit philosophical mode }
  92.  
  93. -- 
  94. MORGAN@UKCC         |       Wes Morgan       |        ...!ukma!ukecc!morgan 
  95. morgan@ms.uky.edu   | Engineering  Computing |   morgan@wuarchive.wustl.edu
  96. morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil
  97.   Mailing list for AT&T StarServer S/E  - starserver-request@engr.uky.edu
  98.