493 lines
25 KiB
Plaintext
493 lines
25 KiB
Plaintext
|
ZDDDDDDDDDDDDDDDDDD? IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; ZDDDDDDDDDDDDDDDDDD?
|
||
|
3 Founded By: 3 : Network Information Access : 3 Mother Earth BBS 3
|
||
|
3 Guardian Of Time 3D: 17APR90 :D3 NUP:> DECnet 3
|
||
|
3 Judge Dredd 3 : Judge Dredd : 3Text File Archives3
|
||
|
@DDDDDDDDBDDDDDDDDDY : File 25 : @DDDDDDDDDBDDDDDDDDY
|
||
|
3 HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM< 3
|
||
|
3 IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; 3
|
||
|
@DDDDDDDDD6 Overview On Viruses & Threats III GDDDDDDDDDY
|
||
|
HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
|
||
|
|
||
|
$_Virus Prevention for Multi-User Computers and Associated Networks
|
||
|
|
||
|
Virus prevention in the multi-user computer environment is aided
|
||
|
by the centralized system and user management, and the relative
|
||
|
richness of technical controls. Unlike personal computers, many
|
||
|
multi-user systems possess basic controls for user
|
||
|
authentication, for levels of access to files and directories,
|
||
|
and for protected regions of memory. By themselves, these
|
||
|
controls are not adequate, but combined with other policies and
|
||
|
procedures that specifically target viruses and related threats,
|
||
|
multi-user systems can greatly reduce their vulnerabilities to
|
||
|
exploitation and attack.
|
||
|
|
||
|
However, some relatively powerful multi-user machines are now so
|
||
|
compact as to be able to be located in an office or on a desk-
|
||
|
top. These machines are still fully able to support a small user
|
||
|
population, to connect to major networks, and to perform complex
|
||
|
real-time operations. But due to their size and increased ease
|
||
|
of operation, they are more vulnerable to unauthorized access.
|
||
|
Also, multi-user machines are sometimes managed by untrained
|
||
|
personnel who do not have adequate time to devote to proper
|
||
|
system management and who may not possess a technical background
|
||
|
or understanding of the system's operation. Thus, it is
|
||
|
especially important for organizations who use or are considering
|
||
|
machines of this nature to pay particular attention to the risks
|
||
|
of attack by unauthorized users, viruses, and related software.
|
||
|
|
||
|
The following sections offer guidance and recommendations for
|
||
|
improving the management and reducing the risk of attack for
|
||
|
multi-user computers and associated networks.
|
||
|
|
||
|
$_General Policies
|
||
|
|
||
|
Two general policies are suggested here. They are intended for
|
||
|
uniform adoption throughout an organization, i.e., they will not
|
||
|
be entirely effective if they are not uniformly followed. These
|
||
|
policies are as follows:
|
||
|
|
||
|
- An organization must assign a dedicated system manager to
|
||
|
operate each multi-user computer. The manager should be
|
||
|
trained, if necessary, to operate the system in a
|
||
|
practical and secure manner. This individual should be
|
||
|
assigned the management duties as part of his job
|
||
|
description; the management duties should not be assigned
|
||
|
"on top" of the individual's other duties, but rather
|
||
|
adequate time should be taken from other duties. System
|
||
|
management is a demanding and time-consuming operation
|
||
|
that can unexpectedly require complete dedication. As
|
||
|
systems are increasingly inter-connected via networks, a
|
||
|
poorly managed system that can be used as a pathway for
|
||
|
unauthorized access to other systems will present a
|
||
|
significant vulnerability to an organization. Thus, the
|
||
|
job of system manager should be assigned carefully, and
|
||
|
adequate time be given so that the job can be performed
|
||
|
completely.
|
||
|
|
||
|
- Management needs to impress upon users the need for their
|
||
|
involvement and cooperation in computer security. A
|
||
|
method for doing this is to create an organizational
|
||
|
security policy. This policy should be a superset of all
|
||
|
other computer-related policy, and should serve to
|
||
|
clearly define what is expected of the user. It should
|
||
|
detail how systems are to be used and what sorts of
|
||
|
computing are permitted and not permitted. Users should
|
||
|
read this policy and agree to it as a prerequisite to
|
||
|
computer use. It would also be helpful to use this
|
||
|
policy to create other policies specific to each multi-
|
||
|
user system.
|
||
|
|
||
|
|
||
|
$_Software Management
|
||
|
|
||
|
|
||
|
Effective software management can help to make a system less
|
||
|
vulnerable to attack and can make containment and recovery more
|
||
|
successful. Carefully controlled access to software will prevent
|
||
|
or discourage unauthorized access. If accurate records and
|
||
|
backups are maintained, software restoral can be accomplished
|
||
|
with a minimum of lost time and data. A policy of testing all
|
||
|
new software, especially public-domain software, will help
|
||
|
prevent accidental infection of a system by viruses and related
|
||
|
software. Thus, the following policies and procedures are
|
||
|
recommended:
|
||
|
|
||
|
- Use only licensed copies of vendor software, or software
|
||
|
that can be verified to be free of harmful code or other
|
||
|
destructive aspects. Maintain complete information about
|
||
|
the software, such as the vendor address and telephone
|
||
|
number, the license number and version, and update
|
||
|
information. Store the software in a secure, tamper-
|
||
|
proof location.
|
||
|
|
||
|
- Maintain configuration reports of all installed software,
|
||
|
including the operating system. This information will be
|
||
|
necessary if the software must be re-installed later.
|
||
|
|
||
|
- Prevent user access to system software and data. Ensure
|
||
|
that such software is fully protected, and that
|
||
|
appropriate monitoring is done to detect attempts at
|
||
|
unauthorized access.
|
||
|
|
||
|
- Prohibit users from installing software. Users should
|
||
|
first contact the system manager regarding new software.
|
||
|
The software should then be tested on an isolated system
|
||
|
to determine whether the software may contain destructive
|
||
|
elements. The isolated system should be set up so that,
|
||
|
to a practical degree, it replicates the target system,
|
||
|
but does not connect to networks or process sensitive
|
||
|
data. A highly-skilled user knowledgeable about viruses
|
||
|
and related threats should perform the testing and ensure
|
||
|
that the software does not change or delete other
|
||
|
software or data. Do not allow users to directly add any
|
||
|
software to the system, whether from public software
|
||
|
repositories, or other systems, or their home systems.
|
||
|
|
||
|
- Teach users to protect their data from unauthorized
|
||
|
access. Ensure that they know how to use access controls
|
||
|
or file protection mechanisms to prevent others from
|
||
|
reading or modifying their files. As possible, set
|
||
|
default file protections such that when a user creates a
|
||
|
file, the file can be accessed only by that user, and no
|
||
|
others. Each user should not permit others to use his or
|
||
|
her account.
|
||
|
|
||
|
- Do not set-up directories to serve as software
|
||
|
repositories unless technical controls are used to
|
||
|
prevent users from writing to the directory. Make sure
|
||
|
that users contact the system manager regarding software
|
||
|
they wish to place in a software repository. It would be
|
||
|
helpful to track where the software is installed by
|
||
|
setting up a process whereby users must first register
|
||
|
their names before they can copy software from the
|
||
|
directory.
|
||
|
|
||
|
- If developing software, control the update process so
|
||
|
that the software is not modified without authorization.
|
||
|
Use a software management and control application to
|
||
|
control access to the software and to automate the
|
||
|
logging of modifications.
|
||
|
|
||
|
- Accept system and application bug fixes or patches only
|
||
|
from highly reliable sources, such as the software
|
||
|
vendor. Do not accept patches from anonymous sources,
|
||
|
such as received via a network. Test the new software on
|
||
|
an isolated system to ensure that the software does not
|
||
|
make an existing problem worse.
|
||
|
|
||
|
$_Technical Controls
|
||
|
|
||
|
Many multi-user computers contain basic built-in technical
|
||
|
controls. These include user authentication via passwords,
|
||
|
levels of user privilege, and file access controls. By using
|
||
|
these basic controls effectively, managers can significantly
|
||
|
reduce the risk of attack by preventing or deterring viruses and
|
||
|
related threats from accessing a system.
|
||
|
|
||
|
Perhaps the most important technical control is user
|
||
|
authentication, with the most widely form of user authentication
|
||
|
being a username associated with a password. Every user account
|
||
|
should use a password that is deliberately chosen so that simple
|
||
|
attempts at password cracking cannot occur. An effective
|
||
|
password should not consist of a person's name or a recognizable
|
||
|
word, but rather should consist of alphanumeric characters and/or
|
||
|
strings of words that cannot easily be guessed. The passwords
|
||
|
should be changed at regular intervals, such as every three to
|
||
|
six months. Some systems include or can be modified to include a
|
||
|
password history, to prevent users from reusing old passwords.
|
||
|
|
||
|
The username/password mechanism can sometimes be modified to
|
||
|
reduce opportunities for password cracking. One method is to
|
||
|
increase the running time of the password encryption to several
|
||
|
seconds. Another method is to cause the user login program to
|
||
|
accept from three to five incorrect password attempts in a row
|
||
|
before disabling the user account for several minutes. Both
|
||
|
methods significantly increase the amount of time a password
|
||
|
cracker would spend when making repeated attempts at guessing a
|
||
|
password. A method for ensuring that passwords are difficult to
|
||
|
crack involves the use of a program that could systematically
|
||
|
guess passwords, and then send warning messages to the system
|
||
|
manager and corresponding users if successful. The program could
|
||
|
attempt passwords that are permutations of each user's name, as
|
||
|
well as using words from an on-line dictionary.
|
||
|
|
||
|
Besides user authentication, access control mechanisms are
|
||
|
perhaps the next most important technical control. Access
|
||
|
control mechanisms permit a system manager to selectively permit
|
||
|
or bar user access to system resources regardless of the user's
|
||
|
level of privilege. For example, a user at a low-level of system
|
||
|
privilege can be granted access to a resource at a higher level
|
||
|
of privilege without raising the user's privilege through the use
|
||
|
of an access control that specifically grants that user access.
|
||
|
Usually, the access control can determine the type of access,
|
||
|
e.g., read or write. Some access controls can send alarm
|
||
|
messages to audit logs or the system manager when unsuccessful
|
||
|
attempts are made to access resources protected by an access
|
||
|
control.
|
||
|
|
||
|
Systems which do not use access controls usually contain another
|
||
|
more basic form that grants access based on user categories.
|
||
|
Usually, there are four: owner, where only the user who "owns" or
|
||
|
creates the resource can access it; group, where anyone in the
|
||
|
same group as the owner can access the resource; world, where all
|
||
|
users can access the resource, and system, which supersedes all
|
||
|
other user privileges. Usually, a file or directory can be set
|
||
|
up to allow any combination of the four. Unlike access controls,
|
||
|
this scheme doesn't permit access to resources on a specific user
|
||
|
basis, thus if a user at a low level of privilege requires access
|
||
|
to a system level resource, the user must be granted system
|
||
|
privilege. However, if used carefully, this scheme can
|
||
|
adequately protect users' files from being accessed without
|
||
|
authorization. The most effective mode is to create a unique
|
||
|
group for each user. Some systems may permit a default file
|
||
|
permission mask to be set so that every file created would be
|
||
|
accessible only by the file's owner.
|
||
|
|
||
|
Other technical control guidelines are as follows:
|
||
|
|
||
|
- Do not use the same password on several systems.
|
||
|
Additionally, sets of computers that are mutually
|
||
|
trusting in the sense that login to one constitutes login
|
||
|
to all should be carefully controlled.
|
||
|
|
||
|
- Disable or remove old or unnecessary user accounts.
|
||
|
Whenever users leave an organization or no longer use a
|
||
|
system, change all passwords that the users had knowledge
|
||
|
of.
|
||
|
|
||
|
- Practice a "least privilege" policy, whereby users are
|
||
|
restricted to accessing resources on a need-to-know basis
|
||
|
only. User privileges should be as restricting as
|
||
|
possible without adversely affecting the performance of
|
||
|
their work. To determine what level of access is
|
||
|
required, err first by setting privileges to their most
|
||
|
restrictive, and upgrade them as necessary. If the
|
||
|
system uses access controls, attempt to maintain a user's
|
||
|
system privileges at a low level while using the access
|
||
|
controls to specifically grant access to the required
|
||
|
resources.
|
||
|
|
||
|
- Users are generally able to determine other users' access
|
||
|
to their files and directories, thus instruct users to
|
||
|
carefully maintain their files and directories such that
|
||
|
they are not accessible, or at a minimum, not writable,
|
||
|
by other users. As possible, set default file
|
||
|
protections such that files and directories created by
|
||
|
each user are accessible by only that user.
|
||
|
|
||
|
- When using modems, do not provide more access to the
|
||
|
system than is necessary. For example, if only dial-out
|
||
|
service is required, set up the modem or telephone line
|
||
|
so that dial-in service is not possible. If dial-in
|
||
|
service is necessary, use modems that require an
|
||
|
additional passwords or modems that use a call-back
|
||
|
mechanism. These modems may work such that a caller must
|
||
|
first identify himself to the system. If the
|
||
|
identification has been pre-recorded with the system and
|
||
|
therefore valid, the system then calls back at a pre-
|
||
|
recorded telephone number.
|
||
|
|
||
|
- If file encryption mechanisms are available, make them
|
||
|
accessible to users. Users may wish to use encryption as
|
||
|
a further means of protecting the confidentiality of
|
||
|
their files, especially if the system is accessible via
|
||
|
networks or modems.
|
||
|
|
||
|
- Include software so that users can temporarily "lock"
|
||
|
their terminals from accepting keystrokes while they are
|
||
|
away. Use software that automatically disables a user's
|
||
|
account if no activity occurs after a certain interval,
|
||
|
such as 10 - 15 minutes.
|
||
|
|
||
|
|
||
|
$_Monitoring
|
||
|
|
||
|
Many multi-user systems provide a mechanism for automatically
|
||
|
recording some aspects of user and system activity. This
|
||
|
monitoring mechanism, if used regularly, can help to detect
|
||
|
evidence of viruses and related threats. Early detection is of
|
||
|
great value, because malicious software potentially can cause
|
||
|
significant damage within a matter of minutes. Once evidence of
|
||
|
an attack has been verified, managers can use contingency
|
||
|
procedures to contain and recover from any resultant damage.
|
||
|
|
||
|
Effective monitoring also requires user involvement, and
|
||
|
therefore, user education. Users must have some guidelines for
|
||
|
what constitutes normal and abnormal system activity. They need
|
||
|
to be aware of such items as whether files have been changed in
|
||
|
content, date, or by access permissions, whether disk space has
|
||
|
become suddenly full, and whether abnormal error messages occur.
|
||
|
They need to know whom to contact to report signs of trouble and
|
||
|
then the steps to take to contain any damage.
|
||
|
|
||
|
The following policies and procedures for effective monitoring
|
||
|
are recommended:
|
||
|
|
||
|
- Use the system monitoring/auditing tools that are
|
||
|
available. Follow the procedures recommended by the
|
||
|
system vendor, or start out by enabling the full level or
|
||
|
most detailed level of monitoring. Use tools as
|
||
|
available to help read the logs, and determine what level
|
||
|
of monitoring is adequate, and cut back on the level of
|
||
|
detail as necessary. Be on the guard for excessive
|
||
|
attempts to access accounts or other resources that are
|
||
|
protected. Examine the log regularly, at least weekly if
|
||
|
not more often.
|
||
|
|
||
|
- As a further aid to monitoring, use alarm mechanisms
|
||
|
found in some access controls. These mechanisms send a
|
||
|
message to the audit log whenever an attempt is made to
|
||
|
access a resource protected by an access control.
|
||
|
|
||
|
- If no system monitoring is available, or if the present
|
||
|
mechanism is unwieldy or not sufficient, investigate and
|
||
|
purchase other monitoring tools as available. Some
|
||
|
third-party software companies sell monitoring tools for
|
||
|
major operating systems with capabilities that supersede
|
||
|
those of the vendor's.
|
||
|
|
||
|
- Educate users so that they understand the normal
|
||
|
operating aspects of the system. Ensure that they have
|
||
|
quick access to an individual or group who can answer
|
||
|
their questions and investigate potential virus
|
||
|
incidents.
|
||
|
|
||
|
- Purchase or build system sweep programs to checksum files
|
||
|
at night, and report differences from previous runs. Use
|
||
|
a password checker to monitor whether passwords are being
|
||
|
used effectively.
|
||
|
|
||
|
- Always report, log, and investigate security problems,
|
||
|
even when the problems appear insignificant. Use the log
|
||
|
as input into regular security reviews. Use the reviews
|
||
|
as a means for evaluating the effectiveness of security
|
||
|
policies and procedures.
|
||
|
|
||
|
- Enforce some form of sanctions against users who
|
||
|
consistently violate or attempt to violate security
|
||
|
policies and procedures. Use the audit logs as evidence,
|
||
|
and bar the users from system use.
|
||
|
|
||
|
$_Contingency Planning
|
||
|
|
||
|
As stressed in part II, backups are the most important
|
||
|
contingency planning activity. A system manager must plan for
|
||
|
the eventuality of having to restore all software and data from
|
||
|
backup tapes for any number of reasons, such as disk drive
|
||
|
failure or upgrades. It has been shown that viruses and related
|
||
|
threats could potentially and unexpectedly destroy all system
|
||
|
information or render it useless, thus managers should pay
|
||
|
particular attention to the effectiveness of their backup
|
||
|
policies. Backup policies will vary from system to system,
|
||
|
however they should be performed daily, with a minimum of several
|
||
|
months backup history. Backup tapes should be verified to be
|
||
|
accurate, and should be stored off-site in a secured location.
|
||
|
|
||
|
Viruses and related software threats could go undetected in a
|
||
|
system for months to years, and thus could be backed up along
|
||
|
with normal system data. If such a program would suddenly
|
||
|
trigger and cause damage, it may require much searching through
|
||
|
old backups to determine when the program first appeared or was
|
||
|
infected. Therefore the safest policy is to restore programs,
|
||
|
i.e., executable and command files, from their original vendor
|
||
|
media only. Only system data that is non-executable should be
|
||
|
restored from regular backups. Of course, in the case of command
|
||
|
files or batch procedures that are developed or modified in the
|
||
|
course of daily system activity, these may need to be inspected
|
||
|
manually to ensure that they have not been modified or damaged.
|
||
|
|
||
|
Other recommended contingency planning activities are as follows:
|
||
|
|
||
|
- Create a security distribution list for hand-out to each
|
||
|
user. The list should include the system manager's name
|
||
|
and number, and other similar information for individuals
|
||
|
who can answer users' questions about suspicious or
|
||
|
unusual system activity. The list should indicate when
|
||
|
to contact these individuals, and where to reach them in
|
||
|
emergencies.
|
||
|
|
||
|
- Coordinate with other system managers, especially if
|
||
|
their computers are connected to the same network.
|
||
|
Ensure that all can be contacted quickly in the event of
|
||
|
a network emergency by using some mechanism other than
|
||
|
the network.
|
||
|
|
||
|
- Besides observing physical security for the system as
|
||
|
well as its software and backup media, locate terminals
|
||
|
in offices that can be locked or in other secure areas.
|
||
|
|
||
|
- If users are accessing the system via personal computers
|
||
|
and terminal emulation software, keep a record of where
|
||
|
the personal computers are located and their network or
|
||
|
port address for monitoring purposes. Control carefully
|
||
|
whether such users are uploading software to the system.
|
||
|
|
||
|
- Exercise caution when accepting system patches. Do not
|
||
|
accept patches that arrive over a network unless there is
|
||
|
a high degree of certainty as to their validity. It is
|
||
|
best to accept patches only from the appropriate software
|
||
|
vendor.
|
||
|
|
||
|
|
||
|
$_Associated Network Concerns
|
||
|
|
||
|
Multi-user computers are more often associated with relatively
|
||
|
large networks than very localized local area networks or
|
||
|
personal computer networks that may use dedicated network
|
||
|
servers. The viewpoint taken here is that wide area network and
|
||
|
large local area network security is essentially a collective
|
||
|
function of the systems connected to the network, i.e., it is not
|
||
|
practical for a controlling system to monitor all network traffic
|
||
|
and differentiate between authorized and unauthorized use. A
|
||
|
system manager should generally assume that network connections
|
||
|
pose inherent risks of unauthorized access to the system in the
|
||
|
forms of unauthorized users and malicious software. Thus, a
|
||
|
system manager needs to protect the system from network-borne
|
||
|
threats and likewise exercise responsibility by ensuring that his
|
||
|
system is not a source of such threats, while at the same time
|
||
|
making network connections available to users as necessary. The
|
||
|
accomplishment of these aims will require the use of technical
|
||
|
controls to restrict certain types of access, monitoring to
|
||
|
detect violations, and a certain amount of trust that users will
|
||
|
use the controls and follow the policies.
|
||
|
|
||
|
Some guidelines for using networks in a more secure manner are as
|
||
|
follows:
|
||
|
|
||
|
- Assume that network connections elevate the risk of
|
||
|
unauthorized access. Place network connections on system
|
||
|
which provide adequate controls, such as strong user
|
||
|
authentication and access control mechanisms. Avoid
|
||
|
placing network connections on system which process
|
||
|
sensitive data.
|
||
|
|
||
|
- If the system permits, require an additional password or
|
||
|
form of authentication for accounts accessed from network
|
||
|
ports. If possible, do not permit access to system
|
||
|
manager accounts from network ports.
|
||
|
|
||
|
- If anonymous or guest accounts are used, place
|
||
|
restrictions on the types of commands that can be
|
||
|
executed from the account. Don't permit access to
|
||
|
software tools, commands that can increase privileges,
|
||
|
and so forth.
|
||
|
|
||
|
- As possible, monitor usage of the network. Check if
|
||
|
network connections are made at odd hours, such as during
|
||
|
the night, or if repeated attempts are made to log in to
|
||
|
the system from a network port.
|
||
|
|
||
|
- When more than one computer is connected to the same
|
||
|
network, arrange the connections so that one machine
|
||
|
serves as a central gateway for the other machines. This
|
||
|
will allow a rapid disconnect from the network in case of
|
||
|
an attack.
|
||
|
|
||
|
- Ensure that users are fully educated in network usage.
|
||
|
Make them aware of the additional risks involved in
|
||
|
network access. Instruct them to be on the alert for any
|
||
|
signs of tampering, and to contact an appropriate person
|
||
|
if they detect any suspicious activity. Create a policy
|
||
|
for responsible network usage that details what sort of
|
||
|
computing activity will and will not be tolerated. Have
|
||
|
users read the policy as a prerequisite to network use.
|
||
|
|
||
|
- Warn users to be suspicious of any messages that are
|
||
|
received from unidentified or unknown sources.
|
||
|
|
||
|
- Don't advertise a system to network users by printing
|
||
|
more information than necessary on a welcome banner. For
|
||
|
example, don't include messages such as "Welcome to the
|
||
|
Payroll Accounting System" that may cause the system to
|
||
|
be more attractive to unauthorized users.
|
||
|
|
||
|
- Don't network to outside organizations without a mutual
|
||
|
review of security practices
|
||
|
|
||
|
-JUDGE DREDD/NIA
|
||
|
|
||
|
[OTHER WORLD BBS]
|
||
|
|
||
|
|
||
|
|