home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.70 < prev    next >
Text File  |  1995-01-03  |  7KB  |  146 lines
  1. VIRUS-L Digest             Thursday, 23 Mar 1989        Volume 2 : Issue 70
  2.  
  3. Today's Topics:
  4. Virus protection [and user removal] (Mac)
  5. Report Query...
  6. anti-virus recommendations from Computer World
  7.  
  8. ---------------------------------------------------------------------------
  9.  
  10. Date: Wed, 22 Mar 89 10:41 MST
  11. From: "Richard Johnson" <Johnson_RJ@CUBLDR.Colorado.EDU>
  12. Subject: Virus protection [and user removal] (Mac)
  13.  
  14. MOSES@URVAX (quite a name, but aren't you mixing history?) writes:
  15.  
  16. > It has been brought to my attention that the users either Turn Off the
  17. > protection or remove the vaccine so they may be able to use their
  18. > infected applications.
  19.  
  20. At least one research center and three departments in the engineering
  21. school here at the Univ. of Colorado have had their Macs infected
  22. multiple times by nVIR.  At some sites, the people in charge don't
  23. want to install _Vaccine because they do software development work.
  24. There are alternatives, however.
  25.  
  26. The best general anti-viral utility I know of is an INIT/cdev called
  27. GateKeeper.  Chris Johnson, its author, bills it as the "configure and
  28. forget" approach to software protection.  It can block the
  29. creation/modification of executable code and executable files by all
  30. applications/INITs/etc. except those given special permission.
  31. (Latest version is 1.1 - as of 3/20/89)
  32.  
  33. On the more specific anti-nVIR front, the RWatcher INIT is fantastic.
  34. If it detects an application trying to add nVIR resources to another
  35. file, it beeps 10 times and exits to the Finder.
  36.  
  37. Both of those ounces of prevention are in use at the center I work
  38. for.  (Both are also free.)  It may just be coincidence, but we've
  39. never had a machine infected.
  40.  
  41. There has been some user "resistance".  One of our more hot-headed
  42. co-workers here was ranting yesterday about how GateKeeper was getting
  43. in the way, throwing up stupid dialogs, and not letting him do his
  44. work.  He'd ended up throwing it away and re-booting.  Turns out he
  45. was just unwilling to take 15 seconds and give Tops and FORTRAN the
  46. code modification and creation privileges they needed to work
  47. correctly.  When I explained to him that once GateKeeper was
  48. configured you didn't even need to think about it, he calmed down
  49. somewhat.  But even with that illustration of how users will remove
  50. anti-viral protection, we were still protected partially by RWatcher.
  51.  
  52. The main lesson I draw from this is that if a protection scheme is
  53. *perceived* as getting in the way, some folks will remove it.
  54. However, if it's unobtrusive, most users won't even know it's there
  55. until they try an infected application.  We use a simple sign
  56. directing users to see an advisor about their infected program if
  57. their machine beeps 10 times or if GateKeeper vetoes a modification.
  58. That way they're more likely to see someone who can help them rather
  59. than removing the protection themselves.
  60.  
  61. Richard Johnson  <Johnson_RJ@CUBLDR.Colorado.EDU>
  62.  
  63. ------------------------------
  64.  
  65. Date:     Wed, 22 Mar 89 13:54 EST
  66. From:     John McMahon - NASA GSFC ADFTO - <FASTEDDY@DFTBIT.BITNET>
  67. Subject:  Report Query...
  68.  
  69. Was  a report  generated  on  the  "IBM Christmas  Card"  trojan horse
  70. program that got loose in BITNET some time back ?  If  so, can someone
  71. direct me to the server (or human being) that has it.
  72.  
  73. Thanks,
  74. +------------------------------------+---------------------------------------+
  75. |John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)  |
  76. |Advanced Data Flow Technology Office|    Arpa: FASTEDDY@DFTNIC.GSFC.NASA.GOV|
  77. |Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT              |
  78. |NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                     |
  79. |Greenbelt, Maryland 20771           |   Phone: x6-2045                      |
  80. +------------------------------------+---------------------------------------+
  81.  
  82. ------------------------------
  83.  
  84. Date: Wed, 22 Mar 89 14:46 EST
  85. From: Roman Olynyk - Information Services <CC011054@WVNVAXA.WVNET.EDU>
  86. Subject: anti-virus recommendations from Computer World
  87.  
  88. Several months ago, I asked if anyone had heard about a set of
  89. recommendations for combating viruses that had appeared in Computer
  90. World.  I had hoped that the article would provide me with a better
  91. lead on the entire guidelines.  I've still not had any luck with the
  92. later, but I did manage to find a shortened list (there were supposed
  93. to have been twenty items in all) in the September 19 issue of
  94. Computer World.  Here they are:
  95.  
  96. *   All software should be purchased from known, reputable sources.
  97.  
  98. *   All purchased software should be in its original shrink-wrap or
  99.     sealed-disk containers when received.
  100.  
  101. *   Backup copies of all original software should be made as soon as the
  102.     package is opened and stored off-site.
  103.  
  104. *   Before installation, all software should be reviews carefully by a
  105.     systems manager.
  106.  
  107. *   New software should be quarantined on an isolated computer to
  108.     greatly reduce contamination risk.
  109.  
  110. *   A backup copy of all system software and data should be made a least
  111.     once a month and stored for at least one year before reuse.  This
  112.     will allow restoration of a system that has been contaminated by a
  113.     time-release virus.  A plan that includes "grandfathered" rotation
  114.     of backup copies will reduce risk even further.
  115.  
  116. *   System administrators should restrict access to programs and data on
  117.     a need-to-use basis.  This isolates problems, protects critical
  118.     applications and facilitates problem diagnostics.
  119.  
  120. *   All programs on a system should be checked regularly for size
  121.     changes.  Any size deviations could be evidence of tampering or
  122.     virus infiltration.
  123.  
  124. *   Many shareware and freeware programs provide a prime entry point for
  125.     viruses.  Skeptical review and extended quarantine of such programs
  126.     are prudent.
  127.  
  128. *   Plans should be made to quickly remove any software that exhibits
  129.     symptoms of contamination and to immediately back up all related
  130.     data.  Users should be informed of these plans, which should be
  131.     tested and reviews periodically.
  132.  
  133. These recommendation were made by a small working group of network
  134. manufacturers.  I've seen some flames (justified, I believe) about the
  135. second-to-the-last point dealing with shareware and freeware.
  136. Shareware developers saw this as an industry ploy to discredit
  137. non-commercial software developers.  Naturally, I'm still looking for
  138. the entire set of guidelines, so I'd appreciate hearing from anyone
  139. who can help me find them.
  140.  
  141. ------------------------------
  142.  
  143. End of VIRUS-L Digest
  144. *********************
  145. Downloaded From P-80 International Information Systems 304-744-2253
  146.