home *** CD-ROM | disk | FTP | other *** search
/ Cuteskunk BBS / cuteskunk.zip / cuteskunk / Text-Files / Network-Information-Access / nia_24.txt < prev    next >
Text File  |  2003-06-29  |  22KB  |  863 lines

  1.  ZDDDDDDDDDDDDDDDDDD? IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; ZDDDDDDDDDDDDDDDDDD?
  2.  
  3.  3   Founded By:    3 :  Network Information Access   : 3 Mother Earth BBS 3
  4.  
  5.  3 Guardian Of Time 3D:            17APR90            :D3  NUP:> DECnet    3
  6.  
  7.  3   Judge Dredd    3 :          Judge Dredd          : 3Text File Archives3
  8.  
  9.  @DDDDDDDDBDDDDDDDDDY :            File 24            : @DDDDDDDDDBDDDDDDDDY
  10.  
  11.           3           HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<           3
  12.  
  13.           3           IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM;           3
  14.  
  15.           @DDDDDDDDDDD6 Computer Viruses & Threats II GDDDDDDDDDDDY
  16.  
  17.                       HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
  18.  
  19.  
  20.  
  21. $_Virus Prevention in General
  22.  
  23.  
  24.  
  25.  
  26.  
  27.    To provide general  protection from attacks by  computer viruses,
  28.  
  29.    unauthorized users, and related threats,  users and managers need
  30.  
  31.    to eliminate or reduce vulnerabilities.  A general summary of the
  32.  
  33.    vulnerabilities that  computer viruses  and  related threats  are
  34.  
  35.    most likely to exploit is as follows:
  36.  
  37.  
  38.  
  39.       - lack of user  awareness - users  copy and share  infected
  40.  
  41.         software, fail to detect signs of virus activity,  do not
  42.  
  43.         understand proper security techniques
  44.  
  45.  
  46.  
  47.       - absence  of or  inadequate security  controls -  personal
  48.  
  49.         computers generally  lack software and  hardware security
  50.  
  51.         mechanisms that help  to prevent and detect  unauthorized
  52.  
  53.         use,  existing   controls  on   multi-user  systems   can
  54.  
  55.         sometimes be surmounted by knowledgeable users
  56.  
  57.  
  58.  
  59.       - ineffective  use of  existing  security controls  - using
  60.  
  61.         easily guessed passwords, failing to use access controls,
  62.  
  63.         granting users more access to resources than necessary
  64.  
  65.  
  66.  
  67.       - bugs  and  loopholes  in   system  software  -   enabling
  68.  
  69.         knowledgeable users to break into systems or exceed their
  70.  
  71.         authorized privileges
  72.  
  73.  
  74.  
  75.       - unauthorized use  - unauthorized  users can  break in  to
  76.  
  77.         systems,  authorized users can exceed levels of privilege
  78.  
  79.         and misuse systems
  80.  
  81.  
  82.  
  83.       - susceptibility  of  networks  to  misuse  - networks  can
  84.  
  85.         provide anonymous access to systems,  many are in general
  86.  
  87.         only as secure as the systems which use them
  88.  
  89.  
  90.  
  91.    As can be seen from this  summary, virus prevention requires that
  92.  
  93.    many  diverse  vulnerabilities   be  addressed.    Some   of  the
  94.  
  95.    vulnerabilities  can  be  improved  upon significantly,  such  as
  96.  
  97.    security controls that can be added or improved, while others are
  98.  
  99.    somewhat inherent in computing, such as  the risk that users will
  100.  
  101.    not use  security controls  or follow  policies, or  the risk  of
  102.  
  103.    unauthorized use of computers and networks.  Thus,  it may not be
  104.  
  105.    possible  to  completely  protect  systems  from  all  virus-like
  106.  
  107.    attacks.   However, to  attain a realistic  degree of protection,
  108.  
  109.    all areas of vulnerability must be addressed; improving upon some
  110.  
  111.    areas at the expense of others will still leave significant holes
  112.  
  113.    in security.
  114.  
  115.  
  116.  
  117.  
  118.  
  119.    To  adequately  address all  areas  of vulnerability,  the active
  120.  
  121.    involvement  of individual  users, the management  structure, and
  122.  
  123.    the  organization  in a  virus  prevention program  is essential.
  124.  
  125.    Such a program, whether formal or informal, depends on the mutual
  126.  
  127.    cooperation of the  three groups to identify  vulnerabilities, to
  128.  
  129.    take steps to correct them, and to monitor the results.
  130.  
  131.  
  132.  
  133.    A virus prevention program must be initially based upon effective
  134.  
  135.    system   computer  administration   that   restricts  access   to
  136.  
  137.    authorized  users,   ensures  that  hardware  and   software  are
  138.  
  139.    regularly monitored and maintained, makes  backups regularly, and
  140.  
  141.    maintains contingency  procedures for potential  problems.  Sites
  142.  
  143.    that do not maintain a basic computer administration program need
  144.  
  145.    to put  one into place, regardless of their  size or the types of
  146.  
  147.    computers used.  Many system vendors supply system administration
  148.  
  149.    manuals that describe the aspects of a basic program.
  150.  
  151.  
  152.  
  153.    Once a basic  administration program is in  place, management and
  154.  
  155.    users need  to incorporate  virus prevention  measures that  will
  156.  
  157.    help to deter attacks by viruses and related threats, detect when
  158.  
  159.    they occur, contain the attacks to limit damage, and recover in a
  160.  
  161.    reasonable amount of  time without loss  of data.  To  accomplish
  162.  
  163.    these aims, attention needs to be focused on the following areas:
  164.  
  165.  
  166.  
  167.       - educating users  about malicious software in general, the
  168.  
  169.         risks  that  it  poses,  how  to  use  control  measures,
  170.  
  171.         policies, and  procedures to  protect themselves  and the
  172.  
  173.         organization
  174.  
  175.  
  176.  
  177.       - software management policies  and procedures that address
  178.  
  179.         public-domain software, and  the use  and maintenance  of
  180.  
  181.         software in general
  182.  
  183.  
  184.  
  185.       - use of technical controls that  help to prevent and deter
  186.  
  187.         attacks by malicious software and unauthorized users
  188.  
  189.  
  190.  
  191.       - monitoring of user and software  activity to detect signs
  192.  
  193.         of attacks, to  detect policy violations, and  to monitor
  194.  
  195.         the overall  effectiveness of  policies, procedures,  and
  196.  
  197.         controls
  198.  
  199.  
  200.  
  201.       - contingency policies  and procedures  for containing  and
  202.  
  203.         recovering from attacks
  204.  
  205.  
  206.  
  207.    General  guidance  in each  of these  areas  is explained  in the
  208.  
  209.    following sections.
  210.  
  211.  
  212.  
  213.  
  214.  
  215. $_Education
  216.  
  217.  
  218.  
  219.  
  220.  
  221.    Education is  one of  the primary  methods by  which systems  and
  222.  
  223.    organizations can  achieve greater  protection from  incidents of
  224.  
  225.    malicious software  and unauthorized  use.   In situations  where
  226.  
  227.    technical controls do not provide complete protection (i.e., most
  228.  
  229.    computers),  it  is ultimately  people  and their  willingness to
  230.  
  231.    adhere to security  policies that will determine  whether systems
  232.  
  233.    and organizations  are protected.   By educating users  about the
  234.  
  235.    general  nature  of  computer  viruses  and related  threats,  an
  236.  
  237.    organization can improve  its ability  to deter, detect,  contain
  238.  
  239.  
  240.  
  241.    Users should be educated about the following:
  242.  
  243.  
  244.  
  245.       - how malicious software  operates, methods by which  it is
  246.  
  247.         planted  and  spread,  the  vulnerabilities exploited  by
  248.  
  249.         malicious software and unauthorized users
  250.  
  251.  
  252.  
  253.       - general security policies  and procedures and how  to use
  254.  
  255.         them
  256.  
  257.  
  258.  
  259.       - the policies to follow regarding the backup, storage, and
  260.  
  261.         use of  software, especially  public-domain software  and
  262.  
  263.         shareware
  264.  
  265.  
  266.  
  267.       - how  to use  the technical  controls they  have at  their
  268.  
  269.         disposal to protect themselves
  270.  
  271.  
  272.  
  273.       - how to monitor their systems and software to detect signs
  274.  
  275.         of abnormal activity, what  to do or whom to  contact for
  276.  
  277.         more information
  278.  
  279.  
  280.  
  281.       - contingency procedures for containing and recovering from
  282.  
  283.         potential incidents
  284.  
  285.  
  286.  
  287.    User education,  while perhaps  expensive in  terms  of time  and
  288.  
  289.    resources required,  is ultimately a  cost-effective measure  for
  290.  
  291.    protecting  against   incidents   of   malicious   software   and
  292.  
  293.    unauthorized  use.  Users  who  are  better acquainted  with  the
  294.  
  295.    destructive potential of  malicious software  and the methods  by
  296.  
  297.    which it  can attack  systems may  in  turn be  prompted to  take
  298.  
  299.    measures to protect themselves.  The purpose of security policies
  300.  
  301.    and procedures will be more clear, thus users may be more willing
  302.  
  303.    to actively use them.  By  educating users how to detect abnormal
  304.  
  305.    system activity  and the resultant steps to follow for containing
  306.  
  307.    and recovering from potential  incidents, organizations will save
  308.  
  309.    money and time if and when actual incidents occur.
  310.  
  311.  
  312.  
  313. $_Software Management
  314.  
  315.  
  316.  
  317.  
  318.  
  319.    As shown by  examples in File 1,  one of the prime  methods by
  320.  
  321.    which malicious software  is initially copied onto  systems is by
  322.  
  323.    unsuspecting users.   When users  download programs from  sources
  324.  
  325.    such  as  software  bulletin  boards,  or public  directories  on
  326.  
  327.    systems or network servers, or in  general use and share software
  328.  
  329.    that has  not been obtained from a reputable source, users are in
  330.  
  331.    danger of  spreading malicious software.   To prevent  users from
  332.  
  333.    potentially spreading malicious software, managers need to
  334.  
  335.  
  336.  
  337.       - ensure  that  users understand  the  nature of  malicious
  338.  
  339.         software,  how it is generally  spread, and the technical
  340.  
  341.         controls to use to protect themselves
  342.  
  343.  
  344.  
  345.       - develop policies for  the downloading and use  of public-
  346.  
  347.         domain and shareware software
  348.  
  349.  
  350.  
  351.       - create  some mechanism for validating such software prior
  352.  
  353.         to allowing users to copy and use it
  354.  
  355.  
  356.  
  357.       - minimize the exchange  of executable  software within  an
  358.  
  359.         organization as much as possible
  360.  
  361.  
  362.  
  363.       - do not create  software repositories on LAN servers or in
  364.  
  365.         multi-user system directories  unless technical  controls
  366.  
  367.         exist  to   prevent  users   from  freely   uploading  or
  368.  
  369.         downloading the software
  370.  
  371.  
  372.  
  373.    The  role  of  education  is  important,  as  users  who  do  not
  374.  
  375.    understand  the risks  yet who  are  asked to  follow necessarily
  376.  
  377.    restrictive policies may share and  copy software anyway.   Where
  378.  
  379.    technical controls  cannot prevent  placing new  software onto  a
  380.  
  381.    system, users are  then primarily responsible for the  success or
  382.  
  383.    failure of whatever policies are developed.
  384.  
  385.  
  386.  
  387.    A policy  that  prohibits any  copying  or use  of  public-domain
  388.  
  389.    software  may  be  overly  restrictive,  as  some  public  domain
  390.  
  391.    programs have proved  to be  useful.  A  less restrictive  policy
  392.  
  393.    would  allow some  copying, however  a  user might  first require
  394.  
  395.    permission from the appropriate manager.  A special system should
  396.  
  397.    be used  from which  to perform  the copy  and then  to test  the
  398.  
  399.    software.  This type of system, called an isolated system, should
  400.  
  401.    be configured so that there is no risk of spreading a potentially
  402.  
  403.    malicious program to other areas of  an organization.  The system
  404.  
  405.    should  not  be  used  by  other  users, should  not  connect  to
  406.  
  407.    networks, and should not contain any  valuable data.  An isolated
  408.  
  409.    system should also be used  to test internally developed software
  410.  
  411.    and updates to vendor software.
  412.  
  413.  
  414.  
  415.    Other policies for managing vendor  software should be developed.
  416.  
  417.    These  policies  should   control  how  and  where   software  is
  418.  
  419.    purchased, and should govern where the software  is installed and
  420.  
  421.    how it is to be used.  The following policies and  procedures are
  422.  
  423.    suggested:
  424.  
  425.  
  426.  
  427.       - purchase vendor software only from reputable sources
  428.  
  429.  
  430.  
  431.       - maintain the software properly and update it as necessary
  432.  
  433.  
  434.  
  435.       - don't use pirated software, as it may have been modified
  436.  
  437.  
  438.  
  439.       - keep  records  of  where  software is  installed  readily
  440.  
  441.         available for contingency purposes
  442.  
  443.  
  444.  
  445.       - ensure that vendors can be  contacted quickly if problems
  446.  
  447.         occur
  448.  
  449.  
  450.  
  451.       - store the original  disks or tapes  from the vendor in  a
  452.  
  453.         secure location
  454.  
  455.  
  456.  
  457.  
  458.  
  459. $_Technical Controls
  460.  
  461.  
  462.  
  463.    Technical  controls  are  the  mechanisms  used  to  protect  the
  464.  
  465.    security and integrity of  systems and associated data.   The use
  466.  
  467.    of technical controls can help  to prevent occurrences of viruses
  468.  
  469.    and related threats by deterring them or making it more difficult
  470.  
  471.    for them  to  gain access  to  systems  and data.    Examples  of
  472.  
  473.    technical controls include user authentication mechanisms such as
  474.  
  475.    passwords, mechanisms which provide selective levels of access to
  476.  
  477.    files and directories  (read-only, no  access, access to  certain
  478.  
  479.    users,  etc.),  and  write-protection  mechanisms  on  tapes  and
  480.  
  481.    diskettes.
  482.  
  483.  
  484.  
  485.  
  486.  
  487.    The different types of technical controls and the degree to which
  488.  
  489.    they  can provide protection and deterrence varies from system to
  490.  
  491.    system, thus the use  of specific types of controls  is discussed
  492.  
  493.    in the following files.  However,  the following general points are
  494.  
  495.    important to note:
  496.  
  497.  
  498.  
  499.       - technical  controls  should  be  used  as   available  to
  500.  
  501.         restrict system access to authorized users only
  502.  
  503.  
  504.  
  505.       - in the multi-user environment, technical controls  should
  506.  
  507.         be  used  to  limit  users'  privileges  to  the  minimum
  508.  
  509.         practical level; they should work  automatically and need
  510.  
  511.         not be initiated by users
  512.  
  513.  
  514.  
  515.       - users and system managers must be  educated as to how and
  516.  
  517.         when to use technical controls
  518.  
  519.  
  520.  
  521.       - where  technical controls are weak or non-existent (i.e.,
  522.  
  523.         personal  computers), they  should  be supplemented  with
  524.  
  525.         alternative   physical   controls   or   add-on   control
  526.  
  527.         mechanisms
  528.  
  529.  
  530.  
  531.    Managers need to determine which technical controls are available
  532.  
  533.    on their systems,  and then the  degree to which  they should  be
  534.  
  535.    used and whether  additional add-on controls are  necessary.  One
  536.  
  537.    way  to  answer  these  questions  is  to  first  categorize  the
  538.  
  539.    different classes of data being processed by a system or systems,
  540.  
  541.    and then to  rank the  categories according to  criteria such  as
  542.  
  543.    sensitivity to the  organization and vulnerability of  the system
  544.  
  545.    to attack.  The rankings should then help determine the degree to
  546.  
  547.    which  the  controls  should be  applied  and  whether additional
  548.  
  549.    controls are  necessary.   Ideally, those systems  with the  most
  550.  
  551.    effective controls should be used  to process the most  sensitive
  552.  
  553.    data, and vice-versa.   As an example, a personal  computer which
  554.  
  555.    processes  sensitive employee  information should  require add-on
  556.  
  557.    user authentication mechanisms, whereas  a personal computer used
  558.  
  559.    for general word processing may not need additional controls.
  560.  
  561.  
  562.  
  563.  
  564.  
  565.    It is important to note that  technical controls do not generally
  566.  
  567.    provide complete protection against viruses  and related threats.
  568.  
  569.    They may be cracked by determined  users who are knowledgeable of
  570.  
  571.    hidden  bugs and weaknesses,  and they may  be surmounted through
  572.  
  573.    the use of Trojan horse programs, as shown by examples in File
  574.  
  575.    1.  An  inherent weakness  in technical controls  is that,  while
  576.  
  577.    deterring users and  software from objects  to which they do  not
  578.  
  579.    have  access,  they may  be  totally ineffective  against attacks
  580.  
  581.    which target objects that are accessible.  For example, technical
  582.  
  583.    controls may not prevent an authorized user from destroying files
  584.  
  585.    to which the user has authorized  access.  Most importantly, when
  586.  
  587.    technical controls  are not  used properly, they  may increase  a
  588.  
  589.    system's  degree of vulnerability.   It is  generally agreed that
  590.  
  591.    fully effective technical  controls will not be  widely available
  592.  
  593.    for some time.   Because of the immediate nature of  the computer
  594.  
  595.    virus threat,  technical controls  must be  supplemented by  less
  596.  
  597.    technically-oriented control  measures such as  described in this
  598.  
  599.    chapter.
  600.  
  601.  
  602.  
  603. $_General Monitoring
  604.  
  605.  
  606.  
  607.    An  important aspect of  computer viruses and  related threats is
  608.  
  609.    that they  potentially can cause  extensive damage within  a very
  610.  
  611.    small amount of time, such as minutes or seconds.  Through proper
  612.  
  613.    monitoring of software, system activity,  and in some cases  user
  614.  
  615.    activity,  managers  can increase  their  chances that  they will
  616.  
  617.    detect   early  signs  of  malicious  software  and  unauthorized
  618.  
  619.    activity.  Once the presence is  noted or suspected, managers can
  620.  
  621.    then  use  contingency  procedures to  contain  the  activity and
  622.  
  623.    recover  from whatever  damage has  been  caused.   An additional
  624.  
  625.    benefit of  general monitoring is that  over time, it can  aid in
  626.  
  627.    determining  the  necessary  level  or   degree  of  security  by
  628.  
  629.    indicating  whether security  policies, procedures,  and controls
  630.  
  631.    are working as planned.
  632.  
  633.  
  634.  
  635.    Monitoring  is  a  combination  of  continual system  and  system
  636.  
  637.    management activity.   Its effectiveness  depends on  cooperation
  638.  
  639.    between management and users.   The following items are necessary
  640.  
  641.    for effective monitoring:
  642.  
  643.  
  644.  
  645.       - user  education  -  users must  know,  specific  to their
  646.  
  647.         computing  environment,  what   constitutes  normal   and
  648.  
  649.         abnormal system activity and whom  to contact for further
  650.  
  651.         information - this  is especially important for  users of
  652.  
  653.         personal  computers,  which   generally  lack   automated
  654.  
  655.         methods for monitoring
  656.  
  657.  
  658.  
  659.       - automated system  monitoring tools - generally  on multi-
  660.  
  661.         user systems, to  automate logging or accounting  of user
  662.  
  663.         and  software  accesses  to accounts,  files,  and  other
  664.  
  665.         system objects  - can sometimes  be tuned to  record only
  666.  
  667.         certain types of accesses such as "illegal" accesses
  668.  
  669.  
  670.  
  671.       - anti-viral software  - generally  on personal  computers,
  672.  
  673.         these tools alert users of certain types of system access
  674.  
  675.         that are indicative of "typical" malicious software
  676.  
  677.  
  678.  
  679.       - system-sweep programs  - programs to  automatically check
  680.  
  681.         files for changes in size, date, or content
  682.  
  683.  
  684.  
  685.       - network  monitoring  tools -  as  with system  monitoring
  686.  
  687.         tools, to record network accesses or attempts to access
  688.  
  689.  
  690.  
  691.    The statistics gained  from monitoring activities should  be used
  692.  
  693.    as input for periodic reviews of  security programs.  The reviews
  694.  
  695.    should  evaluate the effectiveness  of general system management,
  696.  
  697.    and associated security policies, procedures,  and controls.  The
  698.  
  699.    statistics will indicate  the need for  changes and will help  to
  700.  
  701.    fine tune the program so that security is distributed to where it
  702.  
  703.    is most necessary.   The reviews  should also incorporate  users'
  704.  
  705.    suggestions,  and  to  ensure  that  the program  is  not  overly
  706.  
  707.    restrictive, their criticisms.
  708.  
  709.  
  710.  
  711. $_Contingency Planning
  712.  
  713.  
  714.  
  715.  
  716.  
  717.    The  purpose  of  contingency planning  with  regard  to computer
  718.  
  719.    viruses and related threats is to be able to  contain and recover
  720.  
  721.    completely from  actual attacks.  In many  ways, effective system
  722.  
  723.    management  that  includes  user  education,  use   of  technical
  724.  
  725.    controls,  software management,  and monitoring activities,  is a
  726.  
  727.    form  of  contingency  planning, generally  because  a  well-run,
  728.  
  729.    organized  system  or facility  is better  able to  withstand the
  730.  
  731.    disruption that could  result from a  computer virus attack.   In
  732.  
  733.    addition to effective system management activities, managers need
  734.  
  735.    to consider  other contingency procedures that  specifically take
  736.  
  737.    into account the nature of computer viruses and related threats.
  738.  
  739.  
  740.  
  741.    Possibly  the  most   important  contingency  planning   activity
  742.  
  743.    involves the use of backups.  The ability to recover from a virus
  744.  
  745.    attack depends upon maintaining regular,  frequent backups of all
  746.  
  747.    system data.   Each backup should be  checked to ensure  that the
  748.  
  749.    backup media has not  been corrupted.  Backup media  could easily
  750.  
  751.    be corrupted because of defects, because the backup procedure was
  752.  
  753.    incorrect, or perhaps because the backup software itself has been
  754.  
  755.    attacked and modified to corrupt backups as they are made.
  756.  
  757.  
  758.  
  759.    Contingency procedures for  restoring from backups after  a virus
  760.  
  761.    attack  are equally  important.   Backups may  contain  copies of
  762.  
  763.    malicious  software  that   have  been  hiding  in   the  system.
  764.  
  765.    Restoring  the  malicious software  to  a  system  that has  been
  766.  
  767.    attacked could  cause a recurrence of the problem.  To avoid this
  768.  
  769.    possibility, software should  be restored only from  its original
  770.  
  771.    media:   the tapes or diskettes from the  vendor.  In some cases,
  772.  
  773.    this may  involve reconfiguring the software,  therefore managers
  774.  
  775.    must maintain copies of configuration  information for system and
  776.  
  777.    application software.   Because data is not  directly executable,
  778.  
  779.    it  can be restored from routine backups.  However, data that has
  780.  
  781.    been  damaged  may need  to be  restored  manually or  from older
  782.  
  783.    backups.    Command files  such  as  batch  procedures and  files
  784.  
  785.    executed  when  systems  boot  or  when  user log  on  should  be
  786.  
  787.    inspected to ensure that they have  not been damaged or modified.
  788.  
  789.    Thus,  managers  will  need  to  retain  successive  versions  of
  790.  
  791.    backups, and search through them when restoring  damaged data and
  792.  
  793.    command files.
  794.  
  795.  
  796.  
  797.    Other contingency procedures for containing virus attacks need to
  798.  
  799.    be developed.  The following are suggested; they are discussed in
  800.  
  801.    more detail in following files:
  802.  
  803.  
  804.  
  805.  
  806.  
  807.       - ensure that accurate  records are  kept of each  system's
  808.  
  809.         configuration,  including  the  system's   location,  the
  810.  
  811.         software  it   runs,  the  system's  network   and  modem
  812.  
  813.         connections,  and  the name  of  the system's  manager or
  814.  
  815.         responsible individual
  816.  
  817.  
  818.  
  819.       - create a  group  of  skilled users  to  deal  with  virus
  820.  
  821.         incidents and ensure that users  can quickly contact this
  822.  
  823.         group if they suspect signs of viral activity
  824.  
  825.  
  826.  
  827.       - maintain a security  distribution list at each  site with
  828.  
  829.         appropriate telephone numbers of managers to contact when
  830.  
  831.         problems occur
  832.  
  833.  
  834.  
  835.       - isolate critical systems from  networks and other sources
  836.  
  837.         of infection
  838.  
  839.  
  840.  
  841.       - place outside  network connections  on  systems with  the
  842.  
  843.         best  protections,  use  central  gateways to  facilitate
  844.  
  845.         rapid disconnects
  846.  
  847.  
  848.  
  849. -JUDGE DREDD/NIA
  850.  
  851.  
  852.  
  853. [OTHER WORLD BBS]
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861. .
  862.  
  863.