RFC 1244
Site Security Handbook
3. Establishing Procedures to Prevent Security Problems The security policy defines what needs to be protected. This section discusses security procedures which specify what steps will be used to carry out the security policy. 3.1 Security Policy Defines What Needs to be Protected The security policy defines the WHAT's: what needs to be protected, what is most important, what the priorities are, and what the general approach to dealing with security problems should be. The security policy by itself doesn't say HOW things are protected. That is the role of security procedures, which this section discusses. The security policy should be a high level document, giving general strategy. The security procedures need to set out, in detail, the precise steps your site will take to protect itself. The security policy should include a general risk assessment of the types of threats a site is mostly likely to face and the consequences of those threats (see section 2.2). Part of doing a risk assessment will include creating a general list of assets that should be protected (section 2.2.2). This information is critical in devising cost-effective procedures. It is often tempting to start creating security procedures by deciding on different mechanisms first: "our site should have logging on all hosts, call-back modems, and smart cards for all users." This approach could lead to some areas that have too much protection for the risk they face, and other areas that aren't protected enough. Starting with the security policy and the risks it outlines should ensure that the procedures provide the right level of protect for all assets. 3.2 Identifing Possible Problems To determine risk, vulnerabilities must be identified. Part of the purpose of the policy is to aid in shoring up the vulnerabilities and thus to decrease the risk in as many areas as possible. Several of the more popular problem areas are presented in sections below. This list is by no means complete. In addition, each site is likely to have a few unique vulnerabilities. 3.2.1 Access Points Access points are typically used for entry by unauthorized users. Having many access points increases the risk of access to an organization's computer and network facilities.
Network links to networks outside the organization allow access
into the organization for all others connected to that external
network. A network link typically provides access to a large
number of network services, and each service has a potential to be
compromised.
Dialup lines, depending on their configuration, may provide access
merely to a login port of a single system. If connected to a
terminal server, the dialup line may give access to the entire
network.
Terminal servers themselves can be a source of problem. Many
terminal servers do not require any kind of authentication.
Intruders often use terminal servers to disguise their actions,
dialing in on a local phone and then using the terminal server to
go out to the local network. Some terminal servers are configured
so that intruders can TELNET [19] in from outside the network, and
then TELNET back out again, again serving to make it difficult to
trace them.
3.2.2 Misconfigured Systems
Misconfigured systems form a large percentage of security holes.
Today's operating systems and their associated software have
become so complex that understanding how the system works has
become a full-time job. Often, systems managers will be non-
specialists chosen from the current organization's staff.
Vendors are also partly responsible for misconfigured systems. To
make the system installation process easier, vendors occasionally
choose initial configurations that are not secure in all
environments.
3.2.3 Software Bugs
Software will never be bug free. Publicly known security bugs are
common methods of unauthorized entry. Part of the solution to
this problem is to be aware of the security problems and to update
the software when problems are detected. When bugs are found,
they should be reported to the vendor so that a solution to the
problem can be implemented and distributed.
3.2.4 "Insider" Threats
An insider to the organization may be a considerable threat to the
security of the computer systems. Insiders often have direct
access to the computer and network hardware components. The
ability to access the components of a system makes most systems
easier to compromise. Most desktop workstations can be easily
manipulated so that they grant privileged access. Access to a
local area network provides the ability to view possibly sensitive
data traversing the network.
3.3 Choose Controls to Protect Assets in a Cost-Effective Way
After establishing what is to be protected, and assessing the risks
these assets face, it is necessary to decide how to implement the
controls which protect these assets. The controls and protection
mechanisms should be selected in a way so as to adequately counter
the threats found during risk assessment, and to implement those
controls in a cost effective manner. It makes little sense to spend
an exorbitant sum of money and overly constrict the user base if the
risk of exposure is very small.
3.3.1 Choose the Right Set of Controls
The controls that are selected represent the physical embodiment
of your security policy. They are the first and primary line of
defense in the protection of your assets. It is therefore most
important to ensure that the controls that you select are the
right set of controls. If the major threat to your system is
outside penetrators, it probably doesn't make much sense to use
biometric devices to authenticate your regular system users. On
the other hand, if the major threat is unauthorized use of
computing resources by regular system users, you'll probably want
to establish very rigorous automated accounting procedures.
3.3.2 Use Common Sense
Common sense is the most appropriate tool that can be used to
establish your security policy. Elaborate security schemes and
mechanisms are impressive, and they do have their place, yet there
is little point in investing money and time on an elaborate
implementation scheme if the simple controls are forgotten. For
example, no matter how elaborate a system you put into place on
top of existing security controls, a single user with a poor
password can still leave your system open to attack.
3.4 Use Multiple Strategies to Protect Assets
Another method of protecting assets is to use multiple strategies.
In this way, if one strategy fails or is circumvented, another
strategy comes into play to continue protecting the asset. By using
several simpler strategies, a system can often be made more secure
than if one very sophisticated method were used in its place. For
example, dial-back modems can be used in conjunction with traditional
logon mechanisms. Many similar approaches could be devised that provide several levels of protection for assets. However, it's very easy to go overboard with extra mechanisms. One must keep in mind exactly what it is that needs to be protected. 3.5 Physical Security It is a given in computer security if the system itself is not physically secure, nothing else about the system can be considered secure. With physical access to a machine, an intruder can halt the machine, bring it back up in privileged mode, replace or alter the disk, plant Trojan horse programs (see section 2.13.9.2), or take any number of other undesirable (and hard to prevent) actions. Critical communications links, important servers, and other key machines should be located in physically secure areas. Some security systems (such as Kerberos) require that the machine be physically secure. If you cannot physically secure machines, care should be taken about trusting those machines. Sites should consider limiting access from non-secure machines to more secure machines. In particular, allowing trusted access (e.g., the BSD Unix remote commands such as rsh) from these kinds of hosts is particularly risky. For machines that seem or are intended to be physically secure, care should be taken about who has access to the machines. Remember that custodial and maintenance staff often have keys to rooms. 3.6 Procedures to Recognize Unauthorized Activity Several simple procedures can be used to detect most unauthorized uses of a computer system. These procedures use tools provided with the operating system by the vendor, or tools publicly available from other sources. 3.6.1 Monitoring System Use System monitoring can be done either by a system administrator, or by software written for the purpose. Monitoring a system involves looking at several parts of the system and searching for anything unusual. Some of the easier ways to do this are described in this section. The most important thing about monitoring system use is that it be done on a regular basis. Picking one day out of the month to monitor the system is pointless, since a security breach can be isolated to a matter of hours. Only by maintaining a constant
vigil can you expect to detect security violations in time to
react to them.
3.6.2 Tools for Monitoring the System
This section describes tools and methods for monitoring a system
against unauthorized access and use.
3.6.2.1 Logging
Most operating systems store numerous bits of information in
log files. Examination of these log files on a regular basis
is often the first line of defense in detecting unauthorized
use of the system.
- Compare lists of currently logged in users and past
login histories. Most users typically log in and out
at roughly the same time each day. An account logged
in outside the "normal" time for the account may be in
use by an intruder.
- Many systems maintain accounting records for billing
purposes. These records can also be used to determine
usage patterns for the system; unusual accounting records
may indicate unauthorized use of the system.
- System logging facilities, such as the UNIX "syslog"
utility, should be checked for unusual error messages
from system software. For example, a large number of
failed login attempts in a short period of time may
indicate someone trying to guess passwords.
- Operating system commands which list currently executing
processes can be used to detect users running programs
they are not authorized to use, as well as to detect
unauthorized programs which have been started by an
intruder.
3.6.2.2 Monitoring Software
Other monitoring tools can easily be constructed using standard
operating system software, by using several, often unrelated,
programs together. For example, checklists of file ownerships
and permission settings can be constructed (for example, with
"ls" and "find" on UNIX) and stored off-line. These lists can
then be reconstructed periodically and compared against the
master checklist (on UNIX, by using the "diff" utility).
Differences may indicate that unauthorized modifications have
been made to the system.
Still other tools are available from third-party vendors and
public software distribution sites. Section 3.9.9 lists
several sources from which you can learn what tools are
available and how to get them.
3.6.2.3 Other Tools
Other tools can also be used to monitor systems for security
violations, although this is not their primary purpose. For
example, network monitors can be used to detect and log
connections from unknown sites.
3.6.3 Vary the Monitoring Schedule
The task of system monitoring is not as daunting as it may seem.
System administrators can execute many of the commands used for
monitoring periodically throughout the day during idle moments
(e.g., while talking on the telephone), rather than spending fixed
periods of each day monitoring the system. By executing the
commands frequently, you will rapidly become used to seeing
"normal" output, and will easily spot things which are out of the
ordinary. In addition, by running various monitoring commands at
different times throughout the day, you make it hard for an
intruder to predict your actions. For example, if an intruder
knows that each day at 5:00 p.m. the system is checked to see that
everyone has logged off, he will simply wait until after the check
has completed before logging in. But the intruder cannot guess
when a system administrator might type a command to display all
logged-in users, and thus he runs a much greater risk of
detection.
Despite the advantages that regular system monitoring provides,
some intruders will be aware of the standard logging mechanisms in
use on systems they are attacking. They will actively pursue and
attempt to disable monitoring mechanisms. Regular monitoring
therefore is useful in detecting intruders, but does not provide
any guarantee that your system is secure, nor should monitoring be
considered an infallible method of detecting unauthorized use.
3.7 Define Actions to Take When Unauthorized Activity is Suspected
Sections 2.4 and 2.5 discussed the course of action a site should
take when it suspects its systems are being abused. The computer
security policy should state the general approach towards dealing
with these problems.
The procedures for dealing with these types of problems should be
written down. Who has authority to decide what actions will be
taken? Should law enforcement be involved? Should your
organization cooperate with other sites in trying to track down an
intruder? Answers to all the questions in section 2.4 should be
part of the incident handling procedures.
Whether you decide to lock out or pursue intruders, you should
have tools and procedures ready to apply. It is best to work up
these tools and procedures before you need them. Don't wait until
an intruder is on your system to figure out how to track the
intruder's actions; you will be busy enough if an intruder
strikes.
3.8 Communicating Security Policy
Security policies, in order to be effective, must be communicated to
both the users of the system and the system maintainers. This
section describes what these people should be told, and how to tell
them.
3.8.1 Educating the Users
Users should be made aware of how the computer systems are
expected to be used, and how to protect themselves from
unauthorized users.
3.8.1.1 Proper Account/Workstation Use
All users should be informed about what is considered the
"proper" use of their account or workstation ("proper" use is
discussed in section 2.3.2). This can most easily be done at
the time a user receives their account, by giving them a policy
statement. Proper use policies typically dictate things such
as whether or not the account or workstation may be used for
personal activities (such as checkbook balancing or letter
writing), whether profit-making activities are allowed, whether
game playing is permitted, and so on. These policy statements
may also be used to summarize how the computer facility is
licensed and what software licenses are held by the
institution; for example, many universities have educational
licenses which explicitly prohibit commercial uses of the
system. A more complete list of items to consider when writing
a policy statement is given in section 2.3.
3.8.1.2 Account/Workstation Management Procedures
Each user should be told how to properly manage their account
and workstation. This includes explaining how to protect files
stored on the system, how to log out or lock the terminal or
workstation, and so on. Much of this information is typically
covered in the "beginning user" documentation provided by the
operating system vendor, although many sites elect to
supplement this material with local information.
If your site offers dial-up modem access to the computer
systems, special care must be taken to inform users of the
security problems inherent in providing this access. Issues
such as making sure to log out before hanging up the modem
should be covered when the user is initially given dial-up
access.
Likewise, access to the systems via local and wide-area
networks presents its own set of security problems which users
should be made aware of. Files which grant "trusted host" or
"trusted user" status to remote systems and users should be
carefully explained.
3.8.1.3 Determining Account Misuse
Users should be told how to detect unauthorized access to their
account. If the system prints the last login time when a user
logs in, he or she should be told to check that time and note
whether or not it agrees with the last time he or she actually
logged in.
Command interpreters on some systems (e.g., the UNIX C shell)
maintain histories of the last several commands executed.
Users should check these histories to be sure someone has not
executed other commands with their account.
3.8.1.4 Problem Reporting Procedures
A procedure should be developed to enable users to report
suspected misuse of their accounts or other misuse they may
have noticed. This can be done either by providing the name
and telephone number of a system administrator who manages
security of the computer system, or by creating an electronic
mail address (e.g., "security") to which users can address
their problems.
3.8.2 Educating the Host Administrators
In many organizations, computer systems are administered by a wide
variety of people. These administrators must know how to protect
their own systems from attack and unauthorized use, as well as how
to communicate successful penetration of their systems to other
administrators as a warning.
3.8.2.1 Account Management Procedures
Care must be taken when installing accounts on the system in
order to make them secure. When installing a system from
distribution media, the password file should be examined for
"standard" accounts provided by the vendor. Many vendors
provide accounts for use by system services or field service
personnel. These accounts typically have either no password or
one which is common knowledge. These accounts should be given
new passwords if they are needed, or disabled or deleted from
the system if they are not.
Accounts without passwords are generally very dangerous since
they allow anyone to access the system. Even accounts which do
not execute a command interpreter (e.g., accounts which exist
only to see who is logged in to the system) can be compromised
if set up incorrectly. A related concept, that of "anonymous"
file transfer (FTP) [20], allows users from all over the
network to access your system to retrieve files from (usually)
a protected disk area. You should carefully weigh the benefits
that an account without a password provides against the
security risks of providing such access to your system.
If the operating system provides a "shadow" password facility
which stores passwords in a separate file accessible only to
privileged users, this facility should be used. System V UNIX,
SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD
Tahoe, as well as others, provide this feature. It protects
passwords by hiding their encrypted values from unprivileged
users. This prevents an attacker from copying your password
file to his or her machine and then attempting to break the
passwords at his or her leisure.
Keep track of who has access to privileged user accounts (e.g.,
"root" on UNIX or "MAINT" on VMS). Whenever a privileged user
leaves the organization or no longer has need of the privileged
account, the passwords on all privileged accounts should be
changed.
3.8.2.2 Configuration Management Procedures
When installing a system from the distribution media or when
installing third-party software, it is important to check the
installation carefully. Many installation procedures assume a
"trusted" site, and hence will install files with world write
permission enabled, or otherwise compromise the security of
files.
Network services should also be examined carefully when first
installed. Many vendors provide default network permission
files which imply that all outside hosts are to be "trusted",
which is rarely the case when connected to wide-area networks
such as the Internet.
Many intruders collect information on the vulnerabilities of
particular system versions. The older a system, the more
likely it is that there are security problems in that version
which have since been fixed by the vendor in a later release.
For this reason, it is important to weigh the risks of not
upgrading to a new operating system release (thus leaving
security holes unplugged) against the cost of upgrading to the
new software (possibly breaking third-party software, etc.).
Bug fixes from the vendor should be weighed in a similar
fashion, with the added note that "security" fixes from a
vendor usually address fairly serious security problems.
Other bug fixes, received via network mailing lists and the
like, should usually be installed, but not without careful
examination. Never install a bug fix unless you're sure you
know what the consequences of the fix are - there's always the
possibility that an intruder has suggested a "fix" which
actually gives him or her access to your system.
3.8.2.3 Recovery Procedures - Backups
It is impossible to overemphasize the need for a good backup
strategy. File system backups not only protect you in the
event of hardware failure or accidental deletions, but they
also protect you against unauthorized changes made by an
intruder. Without a copy of your data the way it's "supposed"
to be, it can be difficult to undo something an attacker has
done.
Backups, especially if run daily, can also be useful in
providing a history of an intruder's activities. Looking
through old backups can establish when your system was first
penetrated. Intruders may leave files around which, although
deleted later, are captured on the backup tapes. Backups can
also be used to document an intruder's activities to law
enforcement agencies if necessary.
A good backup strategy will dump the entire system to tape at
least once a month. Partial (or "incremental") dumps should be
done at least twice a week, and ideally they should be done
daily. Commands specifically designed for performing file
system backups (e.g., UNIX "dump" or VMS "BACKUP") should be
used in preference to other file copying commands, since these
tools are designed with the express intent of restoring a
system to a known state.
3.8.2.4 Problem Reporting Procedures
As with users, system administrators should have a defined
procedure for reporting security problems. In large
installations, this is often done by creating an electronic
mail alias which contains the names of all system
administrators in the organization. Other methods include
setting up some sort of response team similar to the CERT, or
establishing a "hotline" serviced by an existing support group.
3.9 Resources to Prevent Security Breaches
This section discusses software, hardware, and procedural resources
that can be used to support your site security policy.
3.9.1 Network Connections and Firewalls
A "firewall" is put in place in a building to provide a point of
resistance to the entry of flames into another area. Similarly, a
secretary's desk and reception area provides a point of
controlling access to other office spaces. This same technique
can be applied to a computer site, particularly as it pertains to
network connections.
Some sites will be connected only to other sites within the same
organization and will not have the ability to connect to other
networks. Sites such as these are less susceptible to threats
from outside their own organization, although intrusions may still
occur via paths such as dial-up modems. On the other hand, many
other organizations will be connected to other sites via much
larger networks, such as the Internet. These sites are
susceptible to the entire range of threats associated with a
networked environment.
The risks of connecting to outside networks must be weighed
against the benefits. It may be desirable to limit connection to
outside networks to those hosts which do not store sensitive
material, keeping "vital" machines (such as those which maintain
company payroll or inventory systems) isolated. If there is a
need to participate in a Wide Area Network (WAN), consider
restricting all access to your local network through a single
system. That is, all access to or from your own local network
must be made through a single host computer that acts as a
firewall between you and the outside world. This firewall system
should be rigorously controlled and password protected, and
external users accessing it should also be constrained by
restricting the functionality available to remote users. By using
this approach, your site could relax some of the internal security
controls on your local net, but still be afforded the protection
of a rigorously controlled host front end.
Note that even with a firewall system, compromise of the firewall
could result in compromise of the network behind the firewall.
Work has been done in some areas to construct a firewall which
even when compromised, still protects the local network [6,
CHESWICK].
3.9.2 Confidentiality
Confidentiality, the act of keeping things hidden or secret, is
one of the primary goals of computer security practitioners.
Several mechanisms are provided by most modern operating systems
to enable users to control the dissemination of information.
Depending upon where you work, you may have a site where
everything is protected, or a site where all information is
usually regarded as public, or something in-between. Most sites
lean toward the in-between, at least until some penetration has
occurred.
Generally, there are three instances in which information is
vulnerable to disclosure: when the information is stored on a
computer system, when the information is in transit to another
system (on the network), and when the information is stored on
backup tapes.
The first of these cases is controlled by file permissions, access
control lists, and other similar mechanisms. The last can be
controlled by restricting access to the backup tapes (by locking
them in a safe, for example). All three cases can be helped by
using encryption mechanisms.
3.9.2.1 Encryption (hardware and software)
Encryption is the process of taking information that exists in
some readable form and converting it into a non-readable form.
There are several types of commercially available encryption
packages in both hardware and software forms. Hardware
encryption engines have the advantage that they are much faster
than the software equivalent, yet because they are faster, they
are of greater potential benefit to an attacker who wants to
execute a brute-force attack on your encrypted information.
The advantage of using encryption is that, even if other access
control mechanisms (passwords, file permissions, etc.) are
compromised by an intruder, the data is still unusable.
Naturally, encryption keys and the like should be protected at
least as well as account passwords.
Information in transit (over a network) may be vulnerable to
interception as well. Several solutions to this exist, ranging
from simply encrypting files before transferring them (end-to-
end encryption) to special network hardware which encrypts
everything it sends without user intervention (secure links).
The Internet as a whole does not use secure links, thus end-
to-end encryption must be used if encryption is desired across
the Internet.
3.9.2.1.1 Data Encryption Standard (DES)
DES is perhaps the most widely used data encryption
mechanism today. Many hardware and software implementations
exist, and some commercial computers are provided with a
software version. DES transforms plain text information
into encrypted data (or ciphertext) by means of a special
algorithm and "seed" value called a key. So long as the key
is retained (or remembered) by the original user, the
ciphertext can be restored to the original plain text.
One of the pitfalls of all encryption systems is the need to
remember the key under which a thing was encrypted (this is
not unlike the password problem discussed elsewhere in this
document). If the key is written down, it becomes less
secure. If forgotten, there is little (if any) hope of
recovering the original data.
Most UNIX systems provide a DES command that enables a user
to encrypt data using the DES algorithm.
3.9.2.1.2 Crypt
Similar to the DES command, the UNIX "crypt" command allows
a user to encrypt data. Unfortunately, the algorithm used
by "crypt" is very insecure (based on the World War II
"Enigma" device), and files encrypted with this command can
be decrypted easily in a matter of a few hours. Generally,
use of the "crypt" command should be avoided for any but the
most trivial encryption tasks.
3.9.2.2 Privacy Enhanced Mail
Electronic mail normally transits the network in the clear
(i.e., anyone can read it). This is obviously not the optimal
solution. Privacy enhanced mail provides a means to
automatically encrypt electronic mail messages so that a person
eavesdropping at a mail distribution node is not (easily)
capable of reading them. Several privacy enhanced mail
packages are currently being developed and deployed on the
Internet.
The Internet Activities Board Privacy Task Force has defined a
draft standard, elective protocol for use in implementing
privacy enhanced mail. This protocol is defined in RFCs 1113,
1114, and 1115 [7,8,9]. Please refer to the current edition of
the "IAB Official Protocol Standards" (currently, RFC 1200
[21]) for the standardization state and status of these
protocols.
3.9.3 Origin Authentication
We mostly take it on faith that the header of an electronic mail
message truly indicates the originator of a message. However, it
iseasy to "spoof", or forge the source of a mail message. Origin
authentication provides a means to be certain of the originator of
a message or other object in the same way that a Notary Public
assures a signature on a legal document. This is done by means of
a "Public Key" cryptosystem.
A public key cryptosystem differs from a private key cryptosystem
in several ways. First, a public key system uses two keys, a
Public Key that anyone can use (hence the name) and a Private Key
that only the originator of a message uses. The originator uses
the private key to encrypt the message (as in DES). The receiver,
who has obtained the public key for the originator, may then
decrypt the message.
In this scheme, the public key is used to authenticate the
originator's use of his or her private key, and hence the identity
of the originator is more rigorously proven. The most widely
known implementation of a public key cryptosystem is the RSA
system [26]. The Internet standard for privacy enhanced mail
makes use of the RSA system.
3.9.4 Information Integrity
Information integrity refers to the state of information such that
it is complete, correct, and unchanged from the last time in which
it was verified to be in an "integral" state. The value of
information integrity to a site will vary. For example, it is
more important for military and government installations to
prevent the "disclosure" of classified information, whether it is
right or wrong. A bank, on the other hand, is far more concerned
with whether the account information maintained for its customers
is complete and accurate.
Numerous computer system mechanisms, as well as procedural
controls, have an influence on the integrity of system
information. Traditional access control mechanisms maintain
controls over who can access system information. These mechanisms
alone are not sufficient in some cases to provide the degree of
integrity required. Some other mechanisms are briefly discussed
below.
It should be noted that there are other aspects to maintaining
system integrity besides these mechanisms, such as two-person
controls, and integrity validation procedures. These are beyond
the scope of this document.
3.9.4.1 Checksums
Easily the simplest mechanism, a simple checksum routine can
compute a value for a system file and compare it with the last
known value. If the two are equal, the file is probably
unchanged. If not, the file has been changed by some unknown
means.
Though it is the easiest to implement, the checksum scheme
suffers from a serious failing in that it is not very
sophisticated and a determined attacker could easily add enough
characters to the file to eventually obtain the correct value.
A specific type of checksum, called a CRC checksum, is
considerably more robust than a simple checksum. It is only
slightly more difficult to implement and provides a better
degree of catching errors. It too, however, suffers from the
possibility of compromise by an attacker.
Checksums may be used to detect the altering of information.
However, they do not actively guard against changes being made.
For this, other mechanisms such as access controls and
encryption should be used.
3.9.4.2 Cryptographic Checksums
Cryptographic checksums (also called cryptosealing) involve
breaking a file up into smaller chunks, calculating a (CRC)
checksum for each chunk, and adding the CRCs together.
Depending upon the exact algorithm used, this can result in a
nearly unbreakable method of determining whether a file has
been changed. This mechanism suffers from the fact that it is
sometimes computationally intensive and may be prohibitive
except in cases where the utmost integrity protection is
desired.
Another related mechanism, called a one-way hash function (or a
Manipulation Detection Code (MDC)) can also be used to uniquely
identify a file. The idea behind these functions is that no
two inputs can produce the same output, thus a modified file
will not have the same hash value. One-way hash functions can
be implemented efficiently on a wide variety of systems, making
unbreakable integrity checks possible. (Snefru, a one-way hash
function available via USENET as well as the Internet is just
one example of an efficient one-way hash function.) [10]
3.9.5 Limiting Network Access
The dominant network protocols in use on the Internet, IP (RFC
791) [11], TCP (RFC 793) [12], and UDP (RFC 768) [13], carry
certain control information which can be used to restrict access
to certain hosts or networks within an organization.
The IP packet header contains the network addresses of both the
sender and recipient of the packet. Further, the TCP and UDP
protocols provide the notion of a "port", which identifies the
endpoint (usually a network server) of a communications path. In
some instances, it may be desirable to deny access to a specific
TCP or UDP port, or even to certain hosts and networks altogether.
3.9.5.1 Gateway Routing Tables
One of the simplest approaches to preventing unwanted network
connections is to simply remove certain networks from a
gateway's routing tables. This makes it "impossible" for a
host to send packets to these networks. (Most protocols
require bidirectional packet flow even for unidirectional data
flow, thus breaking one side of the route is usually
sufficient.)
This approach is commonly taken in "firewall" systems by
preventing the firewall from advertising local routes to the
outside world. The approach is deficient in that it often
prevents "too much" (e.g., in order to prevent access to one
system on the network, access to all systems on the network is
disabled).
3.9.5.2 Router Packet Filtering
Many commercially available gateway systems (more correctly
called routers) provide the ability to filter packets based not
only on sources or destinations, but also on source-destination
combinations. This mechanism can be used to deny access to a
specific host, network, or subnet from any other host, network,
or subnet.
Gateway systems from some vendors (e.g., cisco Systems) support
an even more complex scheme, allowing finer control over source
and destination addresses. Via the use of address masks, one
can deny access to all but one host on a particular network.
The cisco Systems also allow packet screening based on IP
protocol type and TCP or UDP port numbers [14].
This can also be circumvented by "source routing" packets
destined for the "secret" network. Source routed packets may
be filtered out by gateways, but this may restrict other
legitimate activities, such as diagnosing routing problems.
3.9.6 Authentication Systems
Authentication refers to the process of proving a claimed identity
to the satisfaction of some permission-granting authority.
Authentication systems are hardware, software, or procedural
mechanisms that enable a user to obtain access to computing
resources. At the simplest level, the system administrator who
adds new user accounts to the system is part of the system
authentication mechanism. At the other end of the spectrum,
fingerprint readers or retinal scanners provide a very high-tech
solution to establishing a potential user's identity. Without
establishing and proving a user's identity prior to establishing a
session, your site's computers are vulnerable to any sort of
attack.
Typically, a user authenticates himself or herself to the system
by entering a password in response to a prompt.
Challenge/Response mechanisms improve upon passwords by prompting
the user for some piece of information shared by both the computer
and the user (such as mother's maiden name, etc.).
3.9.6.1 Kerberos
Kerberos, named after the dog who in mythology is said to stand
at the gates of Hades, is a collection of software used in a
large network to establish a user's claimed identity.
Developed at the Massachusetts Institute of Technology (MIT),
it uses a combination of encryption and distributed databases
so that a user at a campus facility can login and start a
session from any computer located on the campus. This has
clear advantages in certain environments where there are a
large number of potential users who may establish a connection
from any one of a large number of workstations. Some vendors
are now incorporating Kerberos into their systems.
It should be noted that while Kerberos makes several advances
in the area of authentication, some security weaknesses in the
protocol still remain [15].
3.9.6.2 Smart Cards
Several systems use "smart cards" (a small calculator-like
device) to help authenticate users. These systems depend on
the user having an object in their possession. One such system
involves a new password procedure that require a user to enter
a value obtained from a "smart card" when asked for a password
by the computer. Typically, the host machine will give the
user some piece of information that is entered into the
keyboard of the smart card. The smart card will display a
response which must then be entered into the computer before
the session will be established. Another such system involves
a smart card which displays a number which changes over time,
but which is synchronized with the authentication software on
the computer.
This is a better way of dealing with authentication than with
the traditional password approach. On the other hand, some say
it's inconvenient to carry the smart card. Start-up costs are
likely to be high as well.
3.9.7 Books, Lists, and Informational Sources
There are many good sources for information regarding computer
security. The annotated bibliography at the end of this document
can provide you with a good start. In addition, information can
be obtained from a variety of other sources, some of which are
described in this section.
3.9.7.1 Security Mailing Lists
The UNIX Security mailing list exists to notify system
administrators of security problems before they become common
knowledge, and to provide security enhancement information. It
is a restricted-access list, open only to people who can be
verified as being principal systems people at a site. Requests
to join the list must be sent by either the site contact listed
in the Defense Data Network's Network Information Center's (DDN
NIC) WHOIS database, or from the "root" account on one of the
major site machines. You must include the destination address
you want on the list, an indication of whether you want to be
on the mail reflector list or receive weekly digests, the
electronic mail address and voice telephone number of the site
contact if it isn't you, and the name, address, and telephone
number of your organization. This information should be sent
to SECURITY-REQUEST@CPD.COM.
The RISKS digest is a component of the ACM Committee on
Computers and Public Policy, moderated by Peter G. Neumann. It
is a discussion forum on risks to the public in computers and
related systems, and along with discussing computer security
and privacy issues, has discussed such subjects as the Stark
incident, the shooting down of the Iranian airliner in the
Persian Gulf (as it relates to the computerized weapons
systems), problems in air and railroad traffic control systems,
software engineering, and so on. To join the mailing list,
send a message to RISKS-REQUEST@CSL.SRI.COM. This list is also
available in the USENET newsgroup "comp.risks".
The VIRUS-L list is a forum for the discussion of computer
virus experiences, protection software, and related topics.
The list is open to the public, and is implemented as a
moderated digest. Most of the information is related to
personal computers, although some of it may be applicable to
larger systems. To subscribe, send the line:
SUB VIRUS-L your full name
to the address LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU. This
list is also available via the USENET newsgroup "comp.virus".
The Computer Underground Digest "is an open forum dedicated to
sharing information among computerists and to the presentation
and debate of diverse views." While not directly a security
list, it does contain discussions about privacy and other
security related topics. The list can be read on USENET as
alt.society.cu-digest, or to join the mailing list, send mail
to Gordon Myer (TK0JUT2%NIU.bitnet@mitvma.mit.edu).
Submissions may be mailed to: cud@chinacat.unicom.com.
3.9.7.2 Networking Mailing Lists
The TCP-IP mailing list is intended to act as a discussion
forum for developers and maintainers of implementations of the
TCP/IP protocol suite. It also discusses network-related
security problems when they involve programs providing network
services, such as "Sendmail". To join the TCP-IP list, send a
message to TCP-IP-REQUEST@NISC.SRI.COM. This list is also
available in the USENET newsgroup "comp.protocols.tcp-ip".
SUN-NETS is a discussion list for items pertaining to
networking on Sun systems. Much of the discussion is related
to NFS, NIS (formally Yellow Pages), and name servers. To
subscribe, send a message to SUN-NETS-REQUEST@UMIACS.UMD.EDU.
The USENET groups misc.security and alt.security also discuss
security issues. misc.security is a moderated group and also
includes discussions of physical security and locks.
alt.security is unmoderated.
3.9.7.3 Response Teams
Several organizations have formed special groups of people to
deal with computer security problems. These teams collect
information about possible security holes and disseminate it to
the proper people, track intruders, and assist in recovery from
security violations. The teams typically have both electronic
mail distribution lists as well as a special telephone number
which can be called for information or to report a problem.
Many of these teams are members of the CERT System, which is
coordinated by the National Institute of Standards and
Technology (NIST), and exists to facilitate the exchange of
information between the various teams.
3.9.7.3.1 DARPA Computer Emergency Response Team
The Computer Emergency Response Team/Coordination Center
(CERT/CC) was established in December 1988 by the Defense
Advanced Research Projects Agency (DARPA) to address
computer security concerns of research users of the
Internet. It is operated by the Software Engineering
Institute (SEI) at Carnegie-Mellon University (CMU). The
CERT can immediately confer with experts to diagnose and
solve security problems, and also establish and maintain
communications with the affected computer users and
government authorities as appropriate.
The CERT/CC serves as a clearing house for the
identification and repair of security vulnerabilities,
informal assessments of existing systems, improvement of
emergency response capability, and both vendor and user
security awareness. In addition, the team works with
vendors of various systems in order to coordinate the fixes
for security problems.
The CERT/CC sends out security advisories to the CERT-
ADVISORY mailing list whenever appropriate. They also
operate a 24-hour hotline that can be called to report
security problems (e.g., someone breaking into your system),
as well as to obtain current (and accurate) information
about rumored security problems.
To join the CERT-ADVISORY mailing list, send a message to
CERT@CERT.SEI.CMU.EDU and ask to be added to the mailing
list. The material sent to this list also appears in the
USENET newsgroup "comp.security.announce". Past advisories
are available for anonymous FTP from the host
CERT.SEI.CMU.EDU. The 24-hour hotline number is (412) 268-
7090.
The CERT/CC also maintains a CERT-TOOLS list to encourage
the exchange of information on tools and techniques that
increase the secure operation of Internet systems. The
CERT/CC does not review or endorse the tools described on
the list. To subscribe, send a message to CERT-TOOLS-
REQUEST@CERT.SEI.CMU.EDU and ask to be added to the mailing
list.
The CERT/CC maintains other generally useful security
information for anonymous FTP from CERT.SEI.CMU.EDU. Get
the README file for a list of what is available.
For more information, contact:
CERT
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
(412) 268-7090
cert@cert.sei.cmu.edu.
3.9.7.3.2 DDN Security Coordination Center
For DDN users, the Security Coordination Center (SCC) serves
a function similar to CERT. The SCC is the DDN's clearing-
house for host/user security problems and fixes, and works
with the DDN Network Security Officer. The SCC also
distributes the DDN Security Bulletin, which communicates
information on network and host security exposures, fixes,
and concerns to security and management personnel at DDN
facilities. It is available online, via kermit or anonymous
FTP, from the host NIC.DDN.MIL, in SCC:DDN-SECURITY-yy-
nn.TXT (where "yy" is the year and "nn" is the bulletin
number). The SCC provides immediate assistance with DDN-
related host security problems; call (800) 235-3155 (6:00
a.m. to 5:00 p.m. Pacific Time) or send email to
SCC@NIC.DDN.MIL. For 24 hour coverage, call the MILNET
Trouble Desk (800) 451-7413 or AUTOVON 231-1713.
3.9.7.3.3 NIST Computer Security Resource and Response Center
The National Institute of Standards and Technology (NIST)
has responsibility within the U.S. Federal Government for
computer science and technology activities. NIST has played
a strong role in organizing the CERT System and is now
serving as the CERT System Secretariat. NIST also operates
a Computer Security Resource and Response Center (CSRC) to
provide help and information regarding computer security
events and incidents, as well as to raise awareness about
computer security vulnerabilities.
The CSRC team operates a 24-hour hotline, at (301) 975-5200.
For individuals with access to the Internet, on-line
publications and computer security information can be
obtained via anonymous FTP from the host CSRC.NCSL.NIST.GOV
(129.6.48.87). NIST also operates a personal computer
bulletin board that contains information regarding computer
viruses as well as other aspects of computer security. To
access this board, set your modem to 300/1200/2400 BPS, 1
stop bit, no parity, and 8-bit characters, and call (301)
948-5717. All users are given full access to the board
immediately upon registering.
NIST has produced several special publications related to
computer security and computer viruses in particular; some
of these publications are downloadable. For further
information, contact NIST at the following address:
Computer Security Resource and Response Center
A-216 Technology
Gaithersburg, MD 20899
Telephone: (301) 975-3359
Electronic Mail: CSRC@nist.gov
3.9.7.3.4 DOE Computer Incident Advisory Capability (CIAC)
CIAC is the Department of Energy's (DOE's) Computer Incident
Advisory Capability. CIAC is a four-person team of computer
scientists from Lawrence Livermore National Laboratory
(LLNL) charged with the primary responsibility of assisting
DOE sites faced with computer security incidents (e.g.,
intruder attacks, virus infections, worm attacks, etc.).
This capability is available to DOE sites on a 24-hour-a-day
basis.
CIAC was formed to provide a centralized response capability
(including technical assistance), to keep sites informed of
current events, to deal proactively with computer security
issues, and to maintain liaisons with other response teams
and agencies. CIAC's charter is to assist sites (through
direct technical assistance, providing information, or
referring inquiries to other technical experts), serve as a
clearinghouse for information about threats/known
incidents/vulnerabilities, develop guidelines for incident
handling, develop software for responding to
events/incidents, analyze events and trends, conduct
training and awareness activities, and alert and advise
sites about vulnerabilities and potential attacks.
CIAC's business hours phone number is (415) 422-8193 or FTS
532-8193. CIAC's e-mail address is CIAC@TIGER.LLNL.GOV.
3.9.7.3.5 NASA Ames Computer Network Security Response Team
The Computer Network Security Response Team (CNSRT) is NASA
Ames Research Center's local version of the DARPA CERT.
Formed in August of 1989, the team has a constituency that
is primarily Ames users, but it is also involved in
assisting other NASA Centers and federal agencies. CNSRT
maintains liaisons with the DOE's CIAC team and the DARPA
CERT. It is also a charter member of the CERT System. The
team may be reached by 24 hour pager at (415) 694-0571, or
by electronic mail to CNSRT@AMES.ARC.NASA.GOV.
3.9.7.4 DDN Management Bulletins
The DDN Management Bulletin is distributed electronically by
the DDN NIC under contract to the Defense Communications Agency
(DCA). It is a means of communicating official policy,
procedures, and other information of concern to management
personnel at DDN facilities.
The DDN Security Bulletin is distributed electronically by the
DDN SCC, also under contract to DCA, as a means of
communicating information on network and host security
exposures, fixes, and concerns to security and management
personnel at DDN facilities.
Anyone may join the mailing lists for these two bulletins by
sending a message to NIC@NIC.DDN.MIL and asking to be placed on
the mailing lists. These messages are also posted to the
USENET newsgroup "ddn.mgt-bulletin". For additional
information, see section 8.7.
3.9.7.5 System Administration List
The SYSADM-LIST is a list pertaining exclusively to UNIX system
administration. Mail requests to be added to the list to
SYSADM-LIST-REQUEST@SYSADMIN.COM.
3.9.7.6 Vendor Specific System Lists
The SUN-SPOTS and SUN-MANAGERS lists are discussion groups for
users and administrators of systems supplied by Sun
Microsystems. SUN-SPOTS is a fairly general list, discussing
everything from hardware configurations to simple UNIX
questions. To subscribe, send a message to SUN-SPOTS-
REQUEST@RICE.EDU. This list is also available in the USENET
newsgroup "comp.sys.sun". SUN-MANAGERS is a discussion list
for Sun system administrators and covers all aspects of Sun
system administration. To subscribe, send a message to SUN-
MANAGERS-REQUEST@EECS.NWU.EDU.
The APOLLO list discusses the HP/Apollo system and its
software. To subscribe, send a message to APOLLO-
REQUEST@UMIX.CC.UMICH.EDU. APOLLO-L is a similar list which
can be subscribed to by sending
SUB APOLLO-L your full name
to LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU.
HPMINI-L pertains to the Hewlett-Packard 9000 series and HP/UX
operating system. To subscribe, send
SUB HPMINI-L your full name
to LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU.
INFO-IBMPC discusses IBM PCs and compatibles, as well as MS-
DOS. To subscribe, send a note to INFO-IBMPC-REQUEST@WSMR-
SIMTEL20.ARMY.MIL.
There are numerous other mailing lists for nearly every popular
computer or workstation in use today. For a complete list,
obtain the file "netinfo/interest-groups" via anonymous FTP
from the host FTP.NISC.SRI.COM.
3.9.7.7 Professional Societies and Journals
The IEEE Technical Committee on Security & Privacy publishes a
quarterly magazine, "CIPHER".
IEEE Computer Society,
1730 Massachusetts Ave. N.W.
Washington, DC 2036-1903
The ACM SigSAC (Special Interest Group on Security, Audit, and
Controls) publishes a quarterly magazine, "SIGSAC Review".
Association for Computing Machinery
11 West 42nd St.
New York, N.Y. 10036
The Information Systems Security Association publishes a
quarterly magazine called "ISSA Access".
Information Systems Security Association
P.O. Box 9457
Newport Beach, CA 92658
"Computers and Security" is an "international journal for the
professional involved with computer security, audit and
control, and data integrity."
$266/year, 8 issues (1990)
Elsevier Advanced Technology
Journal Information Center
655 Avenue of the Americas
New York, NY 10010
The "Data Security Letter" is published "to help data security
professionals by providing inside information and knowledgable
analysis of developments in computer and communications
security."
$690/year, 9 issues (1990)
Data Security Letter
P.O. Box 1593
Palo Alto, CA 94302
3.9.8 Problem Reporting Tools
3.9.8.1 Auditing
Auditing is an important tool that can be used to enhance the
security of your installation. Not only does it give you a
means of identifying who has accessed your system (and may have
done something to it) but it also gives you an indication of
how your system is being used (or abused) by authorized users
and attackers alike. In addition, the audit trail
traditionally kept by computer systems can become an invaluable
piece of evidence should your system be penetrated.
3.9.8.1.1 Verify Security
An audit trail shows how the system is being used from day
to day. Depending upon how your site audit log is
configured, your log files should show a range of access
attempts that can show what normal system usage should look
like. Deviation from that normal usage could be the result
of penetration from an outside source using an old or stale
user account. Observing a deviation in logins, for example,
could be your first indication that something unusual is
happening.
3.9.8.1.2 Verify Software Configurations
One of the ruses used by attackers to gain access to a
system is by the insertion of a so-called Trojan Horse
program. A Trojan Horse program can be a program that does
something useful, or merely something interesting. It
always does something unexpected, like steal passwords or
copy files without your knowledge [25]. Imagine a Trojan
login program that prompts for username and password in the
usual way, but also writes that information to a special
file that the attacker can come back and read at will.
Imagine a Trojan Editor program that, despite the file
permissions you have given your files, makes copies of
everything in your directory space without you knowing about
it.
This points out the need for configuration management of the
software that runs on a system, not as it is being
developed, but as it is in actual operation. Techniques for
doing this range from checking each command every time it is
executed against some criterion (such as a cryptoseal,
described above) or merely checking the date and time stamp
of the executable. Another technique might be to check each
command in batch mode at midnight.
3.9.8.2 Tools
COPS is a security tool for system administrators that checks
for numerous common security problems on UNIX systems [27].
COPS is a collection of shell scripts and C programs that can
easily be run on almost any UNIX variant. Among other things,
it checks the following items and sends the results to the
system administrator:
- Checks "/dev/kmem" and other devices for world
read/writability.
- Checks special or important files and directories for
"bad" modes (world writable, etc.).
- Checks for easily-guessed passwords.
- Checks for duplicate user ids, invalid fields in the
password file, etc..
- Checks for duplicate group ids, invalid fields in the
group file, etc..
- Checks all users' home directories and their ".cshrc",
".login", ".profile", and ".rhosts" files for security
problems.
- Checks all commands in the "/etc/rc" files and "cron"
files for world writability.
- Checks for bad "root" paths, NFS file systems exported
to the world, etc..
- Includes an expert system that checks to see if a given
user (usually "root") can be compromised, given that
certain rules are true.
- Checks for changes in the setuid status of programs on the
system.
The COPS package is available from the "comp.sources.unix"
archive on "ftp.uu.net", and also from the UNIX-SW repository
on the MILNET host "wsmr-simtel20.army.mil".
3.9.9 Communication Among Administrators
3.9.9.1 Secure Operating Systems
The following list of products and vendors is adapted from the
National Computer Security Center's (NCSC) Evaluated Products
List. They represent those companies who have either received
an evaluation from the NCSC or are in the process of a product
evaluation. This list is not complete, but it is
representative of those operating systems and add on components
available in the commercial marketplace.
For a more detailed listing of the current products appearing
in the NCSC EPL, contact the NCSC at:
National Computer Security Center
9800 Savage Road
Fort George G. Meade, MD 20755-6000
(301) 859-4458
Version Evaluation
Evaluated Product Vendor Evaluated Class
-----------------------------------------------------------------------
Secure Communications Honeywell Information 2.1 A1
Processor (SCOMP) Systems, Inc.
Multics Honeywell Information MR11.0 B2
Systems, Inc.
System V/MLS 1.1.2 on UNIX AT&T 1.1.2 B1
System V 3.1.1 on AT&T 3B2/500and 3B2/600
OS 1100 Unisys Corp. Security B1
Release 1
MPE V/E Hewlett-Packard Computer G.03.04 C2
Systems Division
AOS/VS on MV/ECLIPSE series Data General Corp. 7.60 C2
VM/SP or VM/SP HPO with CMS, IBM Corp. 5 C2
RACF, DIRMAINT, VMTAPE-MS,
ISPF
MVS/XA with RACF IBM Corp. 2.2,2.3 C2
AX/VMS Digital Equipment Corp. 4.3 C2
NOS Control Data Corp. NOS
Security C2
Eval Product
TOP SECRET CGA Software Products 3.0/163 C2
Group, Inc.
Access Control Facility 2 SKK, Inc. 3.1.3 C2
UTX/32S Gould, Inc. Computer 1.0 C2
Systems Division
A Series MCP/AS with Unisys Corp. 3.7 C2
InfoGuard Security
Enhancements
Primos Prime Computer, Inc. 21.0.1DODC2A C2
Resource Access Control IBM Corp. 1.5 C1
Facility (RACF)
Version Candidate
Candidate Product Vendor Evaluated Class
-----------------------------------------------------------------------
Boeing MLS LAN Boeing Aerospace A1 M1
Trusted XENIX Trusted Information
Systems, Inc. B2
VSLAN VERDIX Corp. B2
System V/MLS AT&T B1
VM/SP with RACF IBM Corp. 5/1.8.2 C2
Wang SVS/OS with CAP Wang Laboratories, Inc. 1.0 C2
3.9.9.2 Obtaining Fixes for Known Problems
It goes without saying that computer systems have bugs. Even
operating systems, upon which we depend for protection of our
data, have bugs. And since there are bugs, things can be
broken, both maliciously and accidentally. It is important
that whenever bugs are discovered, a should fix be identified
and implemented as soon as possible. This should minimize any
exposure caused by the bug in the first place.
A corollary to the bug problem is: from whom do I obtain the
fixes? Most systems have some support from the manufacturer or
supplier. Fixes coming from that source tend to be implemented
quickly after receipt. Fixes for some problems are often
posted on the network and are left to the system administrators
to incorporate as they can. The problem is that one wants to
have faith that the fix will close the hole and not introduce
any others. We will tend to trust that the manufacturer's
fixes are better than those that are posted on the net.
3.9.9.3 Sun Customer Warning System
Sun Microsystems has established a Customer Warning System
(CWS) for handling security incidents. This is a formal
process which includes:
- Having a well advertised point of contact in Sun
for reporting security problems.
- Pro-actively alerting customers of worms, viruses,
or other security holes that could affect their systems.
- Distributing the patch (or work-around) as quickly
as possible.
They have created an electronic mail address, SECURITY-
ALERT@SUN.COM, which will enable customers to report security
problems. A voice-mail backup is available at (415) 688-9081.
A "Security Contact" can be designated by each customer site;
this person will be contacted by Sun in case of any new
security problems. For more information, contact your Sun
representative.
3.9.9.4 Trusted Archive Servers
Several sites on the Internet maintain large repositories of
public-domain and freely distributable software, and make this
material available for anonymous FTP. This section describes
some of the larger repositories. Note that none of these
servers implements secure checksums or anything else
guaranteeing the integrity of their data. Thus, the notion of
"trust" should be taken as a somewhat limited definition.
3.9.9.4.1 Sun Fixes on UUNET
Sun Microsystems has contracted with UUNET Communications
Services, Inc., to make fixes for bugs in Sun software
available via anonymous FTP. You can access these fixes by
using the "ftp" command to connect to the host FTP.UU.NET.
Then change into the directory "sun-dist/security", and
obtain a directory listing. The file "README" contains a
brief description of what each file in this directory
contains, and what is required to install the fix.
3.9.9.4.2 Berkeley Fixes
The University of California at Berkeley also makes fixes
available via anonymous FTP; these fixes pertain primarily
to the current release of BSD UNIX (currently, release 4.3).
However, even if you are not running their software, these
fixes are still important, since many vendors (Sun, DEC,
Sequent, etc.) base their software on the Berkeley releases.
The Berkeley fixes are available for anonymous FTP from the
host UCBARPA.BERKELEY.EDU in the directory "4.3/ucb-fixes".
The file "INDEX" in this directory describes what each file
contains. They are also available from UUNET (see section
3.9.9.4.3).
Berkeley also distributes new versions of "sendmail" and
"named" from this machine. New versions of these commands
are stored in the "4.3" directory, usually in the files
"sendmail.tar.Z" and "bind.tar.Z", respectively.
3.9.9.4.3 Simtel-20 and UUNET
The two largest general-purpose software repositories on the
Internet are the hosts WSMR-SIMTEL20.ARMY.MIL and
FTP.UU.NET.
WSMR-SIMTEL20.ARMY.MIL is a TOPS-20 machine operated by the
U.S. Army at White Sands Missile Range (WSMR), New Mexico.
The directory "pd2:<unix-c>" contains a large amount of UNIX
software, primarily taken from the "comp.sources"
newsgroups. The directories "pd1:<msdos>" and
"pd2:<msdos2>" contains software for IBM PC systems, and
"pd3:<macintosh>" contains software for the Apple Macintosh.
FTP.UU.NET is operated by UUNET Communications Services,
Inc. in Falls Church, Virginia. This company sells Internet
and USENET access to sites all over the country (and
internationally). The software posted to the following
USENET source newsgroups is stored here, in directories of
the same name:
comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x
Numerous other distributions, such as all the freely
distributable Berkeley UNIX source code, Internet Request
for Comments (RFCs), and so on are also stored on this
system.
3.9.9.4.4 Vendors
Many vendors make fixes for bugs in their software available
electronically, either via mailing lists or via anonymous
FTP. You should contact your vendor to find out if they
offer this service, and if so, how to access it. Some
vendors that offer these services include Sun Microsystems
(see above), Digital Equipment Corporation (DEC), the
University of California at Berkeley (see above), and Apple
Computer [5, CURRY].
(next page on part 3)
