From the author of

From the author of

In our previous article, Stick to the Essentials,we made the point
that more than 99 percent of intrusions result from the exploitation of known
vulnerabilities or configuration errors, even though countermeasures and solutions
are available. This excerpt from The
CERT® Guide to System and Network Security Practices(Addison-Wesley,
2001, ISBN: 020173723X), and the CERT security improvement modules Securing
Network Servers and Securing
Public Web Servers advises administrators to configure network servers securely
by applying two essential practices: Use the right access controls on general
purpose servers, and use the right access controls on public Web servers. The
second practice assumes that the guidelines described in the first have been
followed.

Vendors sell systems configured so their customers will be eager to buy.
Often, systems are general-purpose, that is, fully featured with most of the
software enabled for ease of use. They are meant to satisfy everyone's
needs and, perhaps, some they didn't realize they had. Such systems
frequently contain

services that are unneeded and often insecurely configured

little to no protection against intruders accessing data objects such as
files and directories

ease-of-use features often provided at the expense of security

vulnerabilities that intruders can use to break into systems

Given a user's or user group's role and access authority,
administrators are responsible for implementing user privileges to access any
data object on any network server. Access controls need to be configured to
allow users to do their jobs while, at the same time, protecting the
organization's critical data from breaches in confidentiality, integrity,
and availability.

Use the Right Access Controls On Network Servers

Many operating systems provide the capability to specify access privileges
individually for files, directories, devices, and other data or code objects. We
recommend configuring the settings on files and other objects to take advantage
of this capability and protect information in accordance with the
organization's security policy.

The biggest challenge for administrators setting up access controls on data
items in an operating system's file system is knowing what level of access
is appropriate and correct. They must determine which identities need what type
of access to properly use the data items in question.

Why This Is Important

Carefully setting access controls reduces the risk of both intentional and
unintentional security breaches. For example, denying read access helps to
protect confidentiality of information, while denying unnecessary write (modify)
access can help maintain its integrity. Limiting the execution privilege of most
system-related tools to authorized system administrators can prevent general
users from making configuration changes that could reduce security. This
restriction can also make it harder for intruders to use those tools to attack
the system or other systems on the network.

How to Do It

Some operating systems provide a number of file systems, each with different
access control capabilities. It is important to choose the file system that best
meets requirements for file access control. This decision may affect the
low-level formatting of storage devices, so it should be made early in the
process of configuring the operating system.

Implement access controls during initial installation and configuration of
the operating system. Carefully monitor and maintain them thereafter.

Identify the Level of Protection Needed

Restrict access to data based on groups, not individuals. For example,
instead of giving read-only access to the Master Auto Parts File to the
identities Manny, Moe, and Jack, the administrator first creates a group named
Master_Auto_Parts_File_Read_Only, and places the identities Manny, Moe, and Jack
into this group. The access control lists associated with the Master Auto Parts
File are changed to grant read-only access to the group
Master_Auto_Parts_File_Read_Only. If that triumvirate ever changes, only the
group definition needs to change; the file need never change, even if no one is
a member of the Master_Auto_Parts_File_Read_Only group. Plus, the group's
name helps to document the access granted to those who are members. Use groups
even if they contain only one member.

One method that can be used to identify needed protection is to construct a
matrix with categories of files and objects on one axis and groups of users
(defined by roles and access authority) on the other. Then, record in the matrix
the kinds of access privileges allowed for that class of objects and that class
of users. The privileges are based on the security requirements (such as
confidentiality, integrity, and availability) of the various classes of
resources.

For example, file categories may include administrative information (user
names, passwords, privileges, and so on), applications, development tools,
operating system files, and user data files. The latter may be further
subdivided into categories such as customer accounts, inventory records,
research data, and management reports. User groups may include system
administrators, network service daemons, and users from various departments.

Privilege identification may result in the need to split some rows and
columns. This happens, for example, upon discovering that a single group of
users is really two groups because their needs to access a particular resource
is not uniform.

Consider distinguishing local access privileges from network access
privileges for a class of files.

Application programs may request and be granted increased access privileges
for some of their operationsa change that is not obvious to the users of
that application, and may not be desired. Therefore, it is important to take
great care in assigning privileges to users and groups.

Configure the operating system to recognize the needed user groups and then
assign individual users (including network service daemons) to the appropriate
groups.

Configure Access Controls

Configure access controls for all protected files, directories, devices, and
other objects using the matrix created in the first step as a guide. Every
change or decision not to change each object's permission should be
documented, along with the rationale.

The least privilege principle should be used when deciding how to implement
access control lists. In other words, grant permissions to those user groups
that need to have access and then allow those groups only the access levels they
absolutely require. For example, if a group needs Read access to a folder,
resist the temptation to give the group Full control, and grant only Read
access.

Consider the following:

Disable write/modify access permissions for all executable and binary
files.

Restrict access of operating system source files, configuration files,
and their directories to authorized administrators.

For UNIX systems, there should be no world-writable files unless
application programs specifically require them. For Windows systems, there
should be no permissions set so that "the Everyone group has Modify
permissions to files."

For UNIX systems, if possible, mount file systems as read only and
nosuid to preclude unauthorized changes to files and programs.

Assign an access permission of immutable to all kernel files if assigning
such a permission is supported by the operating system (such as Linux and
FreeBSD).

Establish all log files as "append only" if that option is
available.

Aim to preclude users from installing, removing, or editing scripts
without administrative review. We realize that this restriction is difficult to
enforce. Refer to the practices Consider Security Implications for Programs,
Scripts, and Plug-ins and Configure the Web Server to Minimize the Functionality
of Programs, Scripts, and Plug-ins in the references noted at the beginning of
this article.

Pay attention to access control inheritance when defining categories of files
and user groups. Ensure that the operating system is configured so that newly
created files and directories inherit appropriate access controls, and so that
access controls propagate down the directory hierarchies as intended when
assigned.

Many of an administrator's security directives can be overridden on a
per-directory basis. The convenience of being able to make local exceptions to
global policy is offset by the threat of a security hole being introduced in a
distant subdirectory, which could be taken over by a hostile user.
Administrators should disable a subdirectory's capability to override
top-level security directives unless that override is required.

Install and Configure File Encryption Capabilities for Sensitive Data

Some operating systems provide optional file encryption; there are also
third-party file encryption packages available, which may be useful if the
operating system's access controls are insufficient to maintain the
confidentiality of file contents. This situation can occur if the operating
system provides few or no access control features, or when the relationships
among categories of files and categories of users are so complex that it would
be difficult to administer the security policy using only access controls.

The security provided by strong access controls is further enhanced by the
use of encryption. However, when using encryption, an administrator must still
dispose of unencrypted versions of the data that existed prior to encryption
being performed, remain after decrypting, and are used in the encryption
process. Encryption adds complexity, so weigh the need for it against the cost
of using it.

NOTE

Note that this recommendation pertains only to the encryption of files stored
on the server itself. Encryption of information for transmission over a network
is a separate issue that is not within the scope of this practice.

Policy Considerations

An organization's security policy for networked systems should specify
the following:

Access privileges and controls for the information that will be stored on
servers

Ways to access the files that have been encrypted with a user key. This
information is very important when that user no longer works for the
organization.

Access privileges and controls for administrators, such as

the authority and conditions for reading other users'
e-mail

access to protected programs or files

disruption of service under specific conditions

a ban on sharing accounts

a ban on the unauthorized creation of user accounts

the authority and conditions for using vulnerability testing
tools

the authority and conditions for using password cracking tools

The
AusCERT Unix Checklist recommends permission settings as well as tasks for administrators to
complete when adjusting access control lists (ACLs) on a Unix- or Linux-based
system.