home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 1 / HACKER1.ISO / network / nia25 < prev    next >
Text File  |  1992-09-26  |  26KB  |  495 lines

  1.  ZDDDDDDDDDDDDDDDDDD? IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; ZDDDDDDDDDDDDDDDDDD?
  2.  3   Founded By:    3 :  Network Information Access   : 3 Mother Earth BBS 3
  3.  3 Guardian Of Time 3D:            17APR90            :D3  NUP:> DECnet    3
  4.  3   Judge Dredd    3 :          Judge Dredd          : 3Text File Archives3
  5.  @DDDDDDDDBDDDDDDDDDY :            File 25            : @DDDDDDDDDBDDDDDDDDY
  6.           3           HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<           3
  7.           3         IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM;         3
  8.           @DDDDDDDDD6 Overview On Viruses & Threats III GDDDDDDDDDY
  9.                     HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
  10.  
  11. $_Virus Prevention for Multi-User Computers and Associated Networks
  12.  
  13.   Virus prevention in the multi-user  computer environment is aided
  14.   by the centralized system and  user management, and the  relative
  15.   richness of technical controls.   Unlike personal computers, many
  16.   multi-user    systems   possess    basic   controls    for   user
  17.   authentication, for levels  of access  to files and  directories,
  18.   and  for  protected regions  of  memory.   By  themselves,  these
  19.   controls are not  adequate, but combined with other  policies and
  20.   procedures that  specifically target viruses and related threats,
  21.   multi-user systems  can greatly  reduce their  vulnerabilities to
  22.   exploitation and attack.
  23.  
  24.   However, some relatively powerful multi-user  machines are now so
  25.   compact as to be  able to be located  in an office or on  a desk-
  26.   top.  These machines are still fully able to support a small user
  27.   population, to connect to major  networks, and to perform complex
  28.   real-time operations.  But  due to their size and  increased ease
  29.   of operation, they  are more  vulnerable to unauthorized  access.
  30.   Also,  multi-user  machines are  sometimes  managed by  untrained
  31.   personnel  who  do not  have adequate  time  to devote  to proper
  32.   system management and who may not possess  a technical background
  33.   or  understanding  of  the  system's  operation.    Thus,  it  is
  34.   especially important for organizations who use or are considering
  35.   machines of this nature to pay  particular attention to the risks
  36.   of attack by unauthorized users, viruses, and related software.
  37.  
  38.   The  following sections  offer guidance  and recommendations  for
  39.   improving  the management  and reducing  the risk  of attack  for
  40.   multi-user computers and associated networks.
  41.  
  42. $_General Policies
  43.  
  44.   Two general policies are  suggested here.  They are  intended for
  45.   uniform adoption throughout an organization,  i.e., they will not
  46.   be entirely effective if they are  not uniformly followed.  These
  47.   policies are as follows:
  48.  
  49.      - An organization must assign a dedicated system manager to
  50.        operate each multi-user computer.   The manager should be
  51.        trained,  if  necessary,  to  operate  the  system  in  a
  52.        practical and secure  manner.  This individual  should be
  53.        assigned  the  management  duties  as  part  of  his  job
  54.        description; the management duties should not be assigned
  55.        "on top"  of the  individual's other  duties, but  rather
  56.        adequate time should be taken  from other duties.  System
  57.        management  is a  demanding and  time-consuming operation
  58.        that can  unexpectedly require  complete dedication.   As
  59.        systems are increasingly inter-connected via networks,  a
  60.        poorly managed system that  can be used as a  pathway for
  61.        unauthorized access  to  other  systems  will  present  a
  62.        significant vulnerability to an organization.   Thus, the
  63.        job of system  manager should be assigned  carefully, and
  64.        adequate time be given  so that the job can  be performed
  65.        completely.
  66.  
  67.      - Management needs to impress upon users the need for their
  68.        involvement  and  cooperation in  computer  security.   A
  69.        method  for  doing this  is  to create  an organizational
  70.        security policy.  This policy should be a superset of all
  71.        other  computer-related  policy,  and  should  serve   to
  72.        clearly define what is  expected of the user.   It should
  73.        detail  how  systems are  to be  used  and what  sorts of
  74.        computing are permitted and not  permitted.  Users should
  75.        read this policy  and agree  to it as  a prerequisite  to
  76.        computer  use.   It  would also  be  helpful to  use this
  77.        policy to create  other policies specific to  each multi-
  78.        user system.
  79.  
  80.  
  81. $_Software Management
  82.  
  83.  
  84.   Effective  software management  can help  to make  a  system less
  85.   vulnerable to  attack and can make containment  and recovery more
  86.   successful.  Carefully controlled access to software will prevent
  87.   or  discourage  unauthorized  access.   If  accurate  records and
  88.   backups  are  maintained, software  restoral can  be accomplished
  89.   with  a minimum of lost  time and data.  A  policy of testing all
  90.   new  software,  especially  public-domain   software,  will  help
  91.   prevent accidental infection  of a system by  viruses and related
  92.   software.    Thus,  the  following  policies and  procedures  are
  93.   recommended:
  94.  
  95.      - Use only licensed copies of  vendor software, or software
  96.        that can be verified to be free of harmful code or  other
  97.        destructive aspects.  Maintain complete information about
  98.        the software, such  as the  vendor address and  telephone
  99.        number,  the  license  number  and  version,  and  update
  100.        information.   Store the  software in  a secure,  tamper-
  101.        proof location.
  102.  
  103.      - Maintain configuration reports of all installed software,
  104.        including the operating system.  This information will be
  105.        necessary if the software must be re-installed later.
  106.  
  107.      - Prevent user access to system software and  data.  Ensure
  108.        that  such  software   is  fully   protected,  and   that
  109.        appropriate  monitoring  is  done to  detect  attempts at
  110.        unauthorized access.
  111.  
  112.      - Prohibit users  from installing software.   Users  should
  113.        first contact the system  manager regarding new software.
  114.        The software should  then be tested on an isolated system
  115.        to determine whether the software may contain destructive
  116.        elements.  The isolated system should  be set up so that,
  117.        to a practical  degree, it replicates the  target system,
  118.        but does  not connect  to networks  or process  sensitive
  119.        data.  A highly-skilled user knowledgeable about  viruses
  120.        and related threats should perform the testing and ensure
  121.        that  the  software  does  not  change  or  delete  other
  122.        software or data.  Do not allow users to directly add any
  123.        software  to  the  system, whether  from  public software
  124.        repositories, or other systems, or their home systems.
  125.  
  126.      - Teach  users  to  protect  their  data  from unauthorized
  127.        access.  Ensure that they know how to use access controls
  128.        or  file  protection mechanisms  to  prevent others  from
  129.        reading  or  modifying  their files.    As  possible, set
  130.        default file protections such that when a user  creates a
  131.        file, the file can  be accessed only by that user, and no
  132.        others.  Each user should not permit others to use his or
  133.        her account.
  134.  
  135.      - Do  not   set-up  directories   to   serve  as   software
  136.        repositories  unless  technical  controls  are  used   to
  137.        prevent users from  writing to the directory.   Make sure
  138.        that users contact the system  manager regarding software
  139.        they wish to place in a software repository.  It would be
  140.        helpful  to  track  where the  software  is  installed by
  141.        setting up a  process whereby  users must first  register
  142.        their  names  before  they  can  copy software  from  the
  143.        directory.
  144.  
  145.      - If  developing  software, control  the update  process so
  146.        that the  software is not modified without authorization.
  147.        Use a  software  management and  control  application  to
  148.        control  access  to  the  software  and to  automate  the
  149.        logging of modifications.
  150.  
  151.      - Accept system and  application bug fixes or  patches only
  152.        from  highly  reliable  sources,  such  as  the  software
  153.        vendor.  Do  not accept  patches from anonymous  sources,
  154.        such as received via a network.  Test the new software on
  155.        an isolated system  to ensure that the  software does not
  156.        make an existing problem worse.
  157.  
  158. $_Technical Controls
  159.  
  160.   Many  multi-user  computers   contain  basic  built-in  technical
  161.   controls.   These  include  user  authentication  via  passwords,
  162.   levels of user  privilege, and  file access controls.   By  using
  163.   these  basic  controls  effectively, managers  can  significantly
  164.   reduce the risk of attack by  preventing or deterring viruses and
  165.   related threats from accessing a system.
  166.  
  167.   Perhaps   the   most   important   technical   control   is  user
  168.   authentication, with the most widely  form of user authentication
  169.   being a username associated with a  password.  Every user account
  170.   should use a password that is  deliberately chosen so that simple
  171.   attempts  at  password  cracking  cannot  occur.    An  effective
  172.   password should not consist of a  person's name or a recognizable
  173.   word, but rather should consist of alphanumeric characters and/or
  174.   strings of words  that cannot easily  be guessed.  The  passwords
  175.   should be changed  at regular intervals,  such as every three  to
  176.   six months.  Some systems include or can be modified to include a
  177.   password history, to  prevent users  from reusing old  passwords.
  178.  
  179.   The  username/password mechanism  can  sometimes be  modified  to
  180.   reduce opportunities  for password  cracking.  One  method is  to
  181.   increase the running time of  the password encryption to  several
  182.   seconds.   Another method is to  cause the user login  program to
  183.   accept from three  to five incorrect  password attempts in a  row
  184.   before disabling  the  user account  for several  minutes.   Both
  185.   methods  significantly  increase the  amount  of time  a password
  186.   cracker would spend  when making repeated attempts at  guessing a
  187.   password.  A method for ensuring  that passwords are difficult to
  188.   crack involves  the use  of a  program that  could systematically
  189.   guess passwords,  and then  send warning messages  to the  system
  190.   manager and corresponding users if successful.  The program could
  191.   attempt passwords that  are permutations of each  user's name, as
  192.   well as using words from an on-line dictionary.
  193.  
  194.   Besides  user  authentication,   access  control  mechanisms  are
  195.   perhaps  the  next  most  important  technical control.    Access
  196.    control mechanisms permit a system  manager to selectively permit
  197.   or bar user access  to system resources regardless of  the user's
  198.   level of privilege.  For example, a user at a low-level of system
  199.   privilege  can be granted access to a  resource at a higher level
  200.   of privilege without raising the user's privilege through the use
  201.   of an access  control that specifically grants that  user access.
  202.   Usually,  the access control  can determine  the type  of access,
  203.   e.g.,  read  or  write.   Some  access  controls  can send  alarm
  204.   messages  to audit logs  or the system  manager when unsuccessful
  205.   attempts are  made  to access  resources protected  by an  access
  206.   control.
  207.  
  208.   Systems which do not use access controls  usually contain another
  209.   more  basic form  that grants  access based  on user  categories.
  210.   Usually, there are four: owner, where only the user who "owns" or
  211.   creates the resource  can access it;  group, where anyone in  the
  212.   same group as the owner can access the resource; world, where all
  213.   users can access  the resource, and system, which  supersedes all
  214.   other user privileges.   Usually, a file or directory can  be set
  215.   up to allow any combination of the four.  Unlike access controls,
  216.   this scheme doesn't permit access to resources on a specific user
  217.   basis, thus if a user at a low level of privilege requires access
  218.   to  a  system level  resource, the  user  must be  granted system
  219.   privilege.    However,   if  used  carefully,  this   scheme  can
  220.   adequately  protect  users'  files from  being  accessed  without
  221.   authorization.  The  most effective  mode is to  create a  unique
  222.   group  for each  user.   Some systems  may permit a  default file
  223.   permission mask  to be set  so that every  file created would  be
  224.   accessible only by the file's owner.
  225.  
  226.   Other technical control guidelines are as follows:
  227.  
  228.      - Do  not  use  the  same   password  on  several  systems.
  229.        Additionally,  sets  of   computers  that  are   mutually
  230.        trusting in the sense that login to one constitutes login
  231.        to all should be carefully controlled.
  232.  
  233.      - Disable  or  remove  old  or unnecessary  user  accounts.
  234.        Whenever users leave  an organization or no  longer use a
  235.        system, change all passwords that the users had knowledge
  236.        of.
  237.  
  238.      - Practice a  "least privilege"  policy, whereby  users are
  239.        restricted to accessing resources on a need-to-know basis
  240.        only.    User  privileges  should  be as  restricting  as
  241.        possible without adversely  affecting the performance  of
  242.        their  work.   To  determine  what  level  of  access  is
  243.        required, err first  by setting privileges to  their most
  244.        restrictive,  and  upgrade  them as  necessary.    If the
  245.        system uses access controls, attempt to maintain a user's
  246.        system privileges at  a low level while using  the access
  247.        controls  to  specifically grant  access to  the required
  248.        resources.
  249.  
  250.      - Users are generally able to determine other users' access
  251.        to their files  and directories,  thus instruct users  to
  252.        carefully maintain their files  and directories such that
  253.        they are not accessible,  or at a minimum,  not writable,
  254.        by  other  users.     As   possible,  set  default   file
  255.        protections such  that files  and directories created  by
  256.        each user are accessible by only that user.
  257.  
  258.      - When  using modems,  do not  provide more  access to  the
  259.        system than is necessary.  For  example, if only dial-out
  260.        service  is required, set up the  modem or telephone line
  261.        so  that dial-in  service is  not  possible.   If dial-in
  262.        service  is   necessary,  use  modems  that   require  an
  263.        additional  passwords  or  modems  that  use  a call-back
  264.        mechanism.  These modems may work such that a caller must
  265.        first  identify   himself  to   the  system.     If   the
  266.        identification has been pre-recorded with  the system and
  267.        therefore valid,  the system  then calls  back at  a pre-
  268.        recorded telephone number.
  269.  
  270.      - If file  encryption mechanisms are  available, make  them
  271.        accessible to users.  Users may wish to use encryption as
  272.        a  further  means of  protecting  the confidentiality  of
  273.        their files, especially  if the system is  accessible via
  274.        networks or modems.
  275.  
  276.      - Include  software so  that users  can temporarily  "lock"
  277.        their terminals from accepting keystrokes while they  are
  278.        away.  Use software that  automatically disables a user's
  279.        account if no  activity occurs after a  certain interval,
  280.        such as 10 - 15 minutes.
  281.  
  282.  
  283. $_Monitoring
  284.  
  285.   Many  multi-user systems  provide a  mechanism for  automatically
  286.   recording  some  aspects  of  user  and  system  activity.   This
  287.   monitoring  mechanism,  if  used regularly,  can  help  to detect
  288.   evidence of viruses and  related threats.  Early detection  is of
  289.   great  value, because  malicious software  potentially can  cause
  290.   significant damage within a matter of  minutes.  Once evidence of
  291.   an  attack  has  been  verified,  managers  can  use  contingency
  292.   procedures to contain and recover from any resultant damage.
  293.  
  294.   Effective  monitoring   also  requires   user  involvement,   and
  295.   therefore,  user education.  Users must  have some guidelines for
  296.   what constitutes normal and abnormal  system activity.  They need
  297.   to be aware of such items  as whether files have been changed  in
  298.   content,  date, or by access permissions,  whether disk space has
  299.   become suddenly full, and whether  abnormal error messages occur.
  300.   They need to know whom to contact to report signs of  trouble and
  301.   then the steps to take to contain any damage.
  302.  
  303.   The following  policies and procedures  for effective  monitoring
  304.   are recommended:
  305.  
  306.      - Use  the  system   monitoring/auditing  tools  that   are
  307.        available.    Follow the  procedures  recommended  by the
  308.        system vendor, or start out by enabling the full level or
  309.        most  detailed  level  of  monitoring.     Use  tools  as
  310.        available to help read the logs, and determine what level
  311.        of monitoring is adequate,  and cut back on the  level of
  312.        detail  as  necessary.   Be  on the  guard  for excessive
  313.        attempts to access  accounts or other resources  that are
  314.        protected.  Examine the log regularly, at least weekly if
  315.        not more often.
  316.  
  317.      - As  a  further aid  to  monitoring, use  alarm mechanisms
  318.        found in some access  controls.  These mechanisms  send a
  319.        message to the audit  log whenever an attempt is  made to
  320.        access a resource protected by an access control.
  321.  
  322.      - If no system  monitoring is available, or  if the present
  323.        mechanism is unwieldy or not sufficient,  investigate and
  324.        purchase  other  monitoring  tools as  available.    Some
  325.        third-party software companies sell monitoring tools  for
  326.        major operating systems  with capabilities that supersede
  327.        those of the vendor's.
  328.  
  329.      - Educate  users  so  that   they  understand  the   normal
  330.        operating  aspects of the system.   Ensure that they have
  331.        quick access  to an  individual or  group who  can answer
  332.        their   questions   and   investigate   potential   virus
  333.        incidents.
  334.  
  335.      - Purchase or build system sweep programs to checksum files
  336.        at night, and report differences from previous runs.  Use
  337.        a password checker to monitor whether passwords are being
  338.        used effectively.
  339.  
  340.      - Always report,  log, and  investigate security  problems,
  341.        even when the problems appear insignificant.  Use the log
  342.        as input into regular security reviews.  Use the  reviews
  343.        as a means  for evaluating the effectiveness  of security
  344.        policies and procedures.
  345.  
  346.      - Enforce  some  form   of  sanctions  against   users  who
  347.        consistently  violate  or  attempt  to  violate  security
  348.        policies and procedures.  Use the audit logs as evidence,
  349.        and bar the users from system use.
  350.  
  351. $_Contingency Planning
  352.  
  353.   As  stressed  in  part II,  backups  are  the  most  important
  354.   contingency planning  activity.  A  system manager must  plan for
  355.   the eventuality of having  to restore all software and  data from
  356.   backup  tapes  for any  number  of  reasons, such  as  disk drive
  357.   failure or upgrades.  It has been shown that viruses and  related
  358.   threats  could potentially  and unexpectedly  destroy all  system
  359.   information  or  render  it  useless,  thus managers  should  pay
  360.   particular   attention  to  the  effectiveness  of  their  backup
  361.   policies.   Backup  policies  will vary  from  system to  system,
  362.   however they should be performed daily, with a minimum of several
  363.   months backup history.   Backup  tapes should be  verified to  be
  364.   accurate, and should be stored off-site in a secured location.
  365.  
  366.   Viruses and  related software threats  could go  undetected in  a
  367.   system  for months  to years, and  thus could be  backed up along
  368.   with  normal  system data.    If  such a  program  would suddenly
  369.   trigger  and cause damage, it may  require much searching through
  370.   old backups to determine  when the program first appeared  or was
  371.   infected.   Therefore the safest  policy is to  restore programs,
  372.   i.e., executable and  command files,  from their original  vendor
  373.   media only.   Only system data  that is non-executable should  be
  374.   restored from regular backups.  Of course, in the case of command
  375.   files or batch procedures  that are developed or modified  in the
  376.   course of daily system  activity, these may need to  be inspected
  377.   manually to ensure that they have not been modified or damaged.
  378.  
  379.   Other recommended contingency planning activities are as follows:
  380.  
  381.      - Create a security distribution list  for hand-out to each
  382.        user.  The list should include  the system manager's name
  383.        and number, and other similar information for individuals
  384.        who can  answer  users'  questions  about  suspicious  or
  385.        unusual system activity.   The list should  indicate when
  386.        to contact these individuals, and where to reach  them in
  387.        emergencies.
  388.  
  389.      - Coordinate with  other  system  managers,  especially  if
  390.        their  computers  are  connected  to  the  same  network.
  391.        Ensure that all can be contacted  quickly in the event of
  392.        a network emergency  by using  some mechanism other  than
  393.        the network.
  394.  
  395.      - Besides  observing physical  security for  the system  as
  396.        well as its  software and backup media,  locate terminals
  397.        in offices that can be locked or in other secure areas.
  398.  
  399.      - If users are accessing the  system via personal computers
  400.        and terminal emulation  software, keep a record  of where
  401.        the personal computers  are located and their  network or
  402.        port address for monitoring  purposes.  Control carefully
  403.        whether such users are uploading software to the system.
  404.  
  405.      - Exercise caution when  accepting system patches.   Do not
  406.        accept patches that arrive over a network unless there is
  407.        a high degree of certainty  as to their validity.  It  is
  408.        best to accept patches only from the appropriate software
  409.        vendor.
  410.  
  411.  
  412. $_Associated Network Concerns
  413.  
  414.   Multi-user  computers are  more often associated  with relatively
  415.   large  networks  than  very  localized  local  area  networks  or
  416.   personal  computer  networks  that  may   use  dedicated  network
  417.   servers.  The viewpoint taken here is that wide area network  and
  418.   large local  area network  security is  essentially a  collective
  419.   function of the systems connected to the network, i.e., it is not
  420.   practical for a controlling system to monitor all network traffic
  421.   and differentiate  between authorized  and unauthorized  use.   A
  422.   system manager  should generally assume that  network connections
  423.   pose inherent risks of  unauthorized access to the system  in the
  424.   forms  of unauthorized  users and  malicious software.   Thus,  a
  425.   system manager  needs to  protect the  system from  network-borne
  426.   threats and likewise exercise responsibility by ensuring that his
  427.   system is not  a source of such  threats, while at the  same time
  428.   making  network connections available to users as necessary.  The
  429.   accomplishment  of these aims  will require the  use of technical
  430.   controls  to  restrict  certain types  of  access,  monitoring to
  431.   detect violations, and a certain amount  of trust that users will
  432.   use the controls and follow the policies.
  433.  
  434.   Some guidelines for using networks in a more secure manner are as
  435.   follows:
  436.  
  437.      - Assume  that network  connections  elevate  the  risk  of
  438.        unauthorized access.  Place network connections on system
  439.        which  provide adequate  controls,  such  as strong  user
  440.        authentication  and  access  control  mechanisms.   Avoid
  441.        placing  network  connections  on  system  which  process
  442.        sensitive data.
  443.  
  444.      - If the system permits, require  an additional password or
  445.        form of authentication for accounts accessed from network
  446.        ports.    If possible,  do  not permit  access  to system
  447.        manager accounts from network ports.
  448.  
  449.      - If  anonymous   or  guest   accounts   are  used,   place
  450.        restrictions  on  the  types  of  commands  that  can  be
  451.        executed  from  the  account.    Don't permit  access  to
  452.        software tools,  commands that  can increase  privileges,
  453.        and so forth.
  454.  
  455.      - As  possible,  monitor usage  of the  network.   Check if
  456.        network connections are made at odd hours, such as during
  457.        the night, or if repeated attempts are made  to log in to
  458.        the system from a network port.
  459.  
  460.      - When more  than  one computer  is connected  to the  same
  461.        network,  arrange the  connections  so that  one  machine
  462.        serves as a central gateway for the other machines.  This
  463.        will allow a rapid disconnect from the network in case of
  464.        an attack.
  465.  
  466.      - Ensure that users  are fully  educated in network  usage.
  467.        Make  them  aware  of the  additional  risks  involved in
  468.        network access.  Instruct them to be on the alert for any
  469.        signs of tampering, and to  contact an appropriate person
  470.        if they detect any suspicious activity.  Create a  policy
  471.        for responsible network  usage that details what  sort of
  472.        computing activity will and will  not be tolerated.  Have
  473.        users read the policy as a prerequisite to network use.
  474.  
  475.      - Warn  users to  be suspicious  of  any messages  that are
  476.        received from unidentified or unknown sources.
  477.  
  478.      - Don't advertise  a system  to network  users by  printing
  479.        more information than necessary on a welcome banner.  For
  480.        example, don't include  messages such as "Welcome  to the
  481.        Payroll Accounting System"  that may cause the  system to
  482.        be more attractive to unauthorized users.
  483.  
  484.      - Don't network  to outside organizations  without a mutual
  485.        review of security practices
  486.  
  487. -JUDGE DREDD/NIA
  488.  
  489. [OTHER WORLD BBS]
  490.  
  491.  
  492.  
  493.  
  494. Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
  495.