Download Good practice guide: General advice on securing operating

GOOD PRACTICE GUIDE
GENERAL ADVICE ON SECURING OPERATING
SYSTEMS
JULY 2007
Abstract
This paper provides a technical overview of general operating system security. It also provides
guidance on what practical steps can be taken to improve the security of an organisation’s operating
systems, regardless of which particular product and version they have chosen to run.
Disclaimer
Reference to any specific commercial product, process or service by trade name, trademark, manufacturer, or otherwise,
does not constitute or imply its endorsement, recommendation, or favouring by CPNI. The views and opinions of authors
expressed within this document shall not be used for advertising or product endorsement purposes.
To the fullest extent permitted by law, CPNI accepts no liability for any loss or damage (whether direct, indirect or
consequential and including, but not limited to, loss of profits or anticipated profits, loss of data, business or goodwill)
incurred by any person and howsoever caused arising from or connected with any error or omission in this document
or from any person acting, omitting to act or refraining from acting upon, or otherwise using, the information contained
in this document or its references. You should make your own judgement as regards use of this document and seek
independent professional advice on your particular circumstances.
General Advice on Securing Operating Systems
CONTENTS
1
Key points ............................................................................................................................. 3
2
Operating system components .......................................................................................... 4
3
4
5
2
2.1
Kernel ....................................................................................................................... 4
2.2
Interface to firmware .................................................................................................. 4
2.3
Input/output .............................................................................................................. 5
2.4
Memory and disk protection ...................................................................................... 5
2.5
User interface ............................................................................................................ 5
Common attack vectors and countermeasures ............................................................... 5
3.1
Network attack .......................................................................................................... 6
3.2
Local attack .............................................................................................................. 8
3.3
Authentication ......................................................................................................... 11
3.4
Viruses .................................................................................................................... 12
3.5
Access control ........................................................................................................ 13
3.6
Auditing ................................................................................................................... 17
Sources of further guidance ............................................................................................. 20
4.1
Security lockdown guides ........................................................................................ 20
4.2
Security tools .......................................................................................................... 20
References .......................................................................................................................... 21
General Advice on Securing Operating Systems
1
Key points
•
This document is a guide which provides advice on improving operating system security.
The advice in this document is generic and can be applied to both open and closed
source operating systems.
•
The guide is aimed at technical and non-technical members of IT Security teams.
•
This guide is not a substitute for a detailed lockdown guide for a particular operating
system. Instead it looks at generic security trends across operating systems and provides
general advice on improving the security standards.
•
The document contains:
o
o
o
•
Operating system security is a very important part of an organisation’s overall IT security
approach. Regardless of which operating system is used, certain steps should be
followed to ensure a minimum level of protection, as described in this paper:
o
o
o
o
o
o
3
An introductory section which defines the term “operating system” (OS) and
describes the principal components of an OS.
A section covering the key attack vectors relevant to operating systems, and
suggested countermeasures to mitigate attacks carried out via these vectors.
A section listing of sources of further advice.
All operating systems should have their network services reviewed and any services
that are not required should be disabled.
Any services that are required should have the latest security patches applied in
accordance with an organisational patching policy. Access to the services should be
limited to the minimum number of remote users wherever possible.
The same steps should be applied to all programs and processes that run locally on
a machine. Any applications that are not required to be running on the operating
system should be disabled. Then the latest security patches should be applied to
the remaining applications and the underlying operating system.
A lockdown guide, specific to the operating system being used should be obtained
and followed. While it may not be necessary to implement all of the lockdown
guides recommendations, for usability reasons, they should be followed as closely
as possible.
Consider further strengthening operating system security through the use of third
party products such as anti-virus solutions and personal firewalls.
A strong authentication policy should be put in place on the machine. This should
be effective at preventing unauthorised users attempting to log onto the system.
This should be supported by an audit program that will detect any such
unauthorised access or attempted access.
General Advice on Securing Operating Systems
2
Operating system components
Wikipedia [1] defines an operating system as:
“a computer program that manages the hardware and software resources of a computer.
At the foundation of all system software, an operating system performs basic tasks such
as controlling and allocating memory, prioritising system requests, controlling input and
output devices, facilitating networking, and managing files. It also may provide a graphical
user interface for higher level functions. It forms a platform for other software”.
Historically, operating systems, like many other aspects of computer science, were not
designed with security in mind. However, as the industry has moved on and attacks against
operating systems have become more widespread, vendors have become increasingly aware of
the importance of operating system security.
To understand the various attacks and countermeasures presented in the next section, it is first
necessary to provide a high level overview of the components that make up an operating
system.
2.1 Kernel
The kernel is the central and most important component in an operating system. It provides the
interface via which the computer’s hardware (e.g. memory, processors and input/output
devices) are controlled and accessed.
“The most important program in the [OS] is called the kernel. It is loaded into [memory]
when the system boots and contains many critical procedures that are needed for the
system to operate. The other programs are less crucial utilities; they can provide a wide
variety of interactive experiences for the user — as well as doing all the jobs the user
bought the computer for — but the essential shape and capabilities of the system are
determined by the kernel”. [2]
The kernel is also responsible for scheduling and multi-tasking. It determines which processes
should be run and with which priority.
From a security perspective, this is the most crucial component of an operating system as it is
the interface to all system resources. If an attacker can convince the kernel to run their code
with the highest level of privilege then they will have full control over the entire computer system.
2.2 Interface to firmware
The term “firmware” refers to computer programs embedded in hardware, usually read-only
memory (ROM) or other forms of non-volatile memory. It provides the means by which hardware
devices such as disk drives, memory, sound cards and video cards can be controlled.
The OS function known as “interface to firmware”, or “device management”, is the means by
which data is fed to (and from) the firmware on the computer’s various hardware devices. The
4
General Advice on Securing Operating Systems
operating system must be able to ensure that all of these device can interact with one another. It
is important that from a security perspective that hardware and firmware do not perform
functions which could compromise system resources.
2.3 Input/output
Closely linked to the interface to firmware function is the requirement for the operating system to
interpret input and output from user I/O devices such as the keyboard and mouse. These take
input from the user and convert it into data which the operating system interprets. The operating
system then takes this data and outputs the results to another device such as the computer
monitor or a printer.
From a security perspective, allowing users to interact with the operating system increases the
likelihood that the operating system will receive unexpected input or process it in an incorrect
manner. Similarly, allowing users to attach their own I/O devices to the computer system (e.g.
USB keys) provides a further channel for attackers to communicate with the operating system.
The risks of an uncontrolled user I/O policy are examined in detail later in this guide.
2.4 Memory and disk protection
Every operating system has functions that determine how memory is allocated to the various
applications and operating system functions that run on the system. From a security perspective
it vitally necessary for operating systems to have some form of built-in memory protection:
“Memory protection is a system that prevents one process from corrupting the memory of
another process running on the same computer at the same time”. [1]
Many attacks, such as buffer overflow attacks, are designed to bypass this protection. The
attacker may attempt to get a vulnerable piece of software to execute their exploit code with its
own level of privilege.
2.5 User interface
It is through the user interface that the operating system actually interacts with the user.
Almost all operating systems now use graphical user interfaces (GUIs). These typically run
different applications in different windows, where each windowed application is a separate
process and may have different privileges with regard to the underlying operating system
(although this may not be immediately apparent to the user).
3
Common attack vectors and countermeasures
The threats to an OS are varied and depend on both the environment that the operating system
is running in and the role that the operating system is used for. For example, if the operating
system is installed on a stand-alone workstation that is never connected to a network, then it is
not at risk from network attack. By contrast, the OS might be hosting an Internet facing web
server, which would greatly increase the risk of the server coming under remote attack.
5
General Advice on Securing Operating Systems
This paper will now look at some of the common attacks that operating systems have to face
and will then present countermeasures that can mitigate against these attacks. It is for the
reader to determine (via a risk assessment) whether the attack vectors discussed are applicable
and the extent to which countermeasures need to be implemented. Risk managers also need to
consider the balance between security and usability, since security measures such as locking
down system services may also have an impact on functionality.
3.1 Network attack
3.1.1
Network attack vectors
Network attacks can be sub-divided into two distinct categories, namely attacks
exploiting TCP/IP stack vulnerabilities and those that exploit operating system and
application network services.
Figure 1 - Network attack categories
The first category of attack, exploiting the TCP/IP stack, concerns the implementation of
the operating system’s networking components. As a typical example, the so-called ‘ping
of death’ attack involves a malicious user sending a malformed ping packet to the target
computer, causing the computer to crash. Many operating systems, including Solaris,
Windows and Linux, were vulnerable to this attack before subsequent versions of the
software corrected the vulnerability. More modern denial of service (DoS) attacks include
SYN attacks (so called because they involve one or more attackers sending repeated SYN
packets to the target machine, but never completing a full TCP connection). However,
these attacks have a relatively low impact on the operating system unless the operating
system is running a high visibility service, such as a big corporate website.
Attacks in the second category, relating to vulnerabilities in operating system or
application network services, tend to be more serious and have a higher impact. Most
operating systems offer, by default, a large number of services over the network to other
users. Even servers that have undergone some basic hardening usually need to have
several services running, often for maintenance purposes.
The first step a remote attacker needs to take is to establish exactly what services are
running on the target operating system. This is accomplished through the use of a tool
called a port scanner. The attacker can then attempt to run exploit code against any
service that they believe to be vulnerable.
6
General Advice on Securing Operating Systems
The exploit code may perform any number of tasks. However, the attacker is initially likely
to mount an attack that will grant him administrator level privileges (‘root’ under UNIX or
‘system’ under Windows), and hence allow the attacker to execute arbitrary code.
Attack class
Typical vulnerability classes Attack or outcome
TCP/IP stack
vulnerabilities
• faulty implementation/design
of TCP/IP stack
• “ping of death”
• SYN flooding
• other denial of service
attacks
OS and application
network services
• buffer overflow
• faulty logic
• no authentication service
• faulty access control
• specific application
vulnerability classes (e.g. SQL
injection for www service)
• privilege escalation
• custom code execution
• access to additional systems
Figure 2 - Summary of network attacks
3.1.2
Network attack countermeasures
The first and most basic countermeasure against OS and application network attacks is
to minimise the services that are running. The more services are available, and hence
ports that are open, the more likely it is that the attacker will find a port that is vulnerable
to a remote attack. The solution therefore is to disable all services running on the
operating system that there is not a business requirement for keeping open. More modern
operating system tend to have fewer services available by default than older versions.
Some come with a built-in software firewall, which provides further defences (as will be
discussed later).
Security administrators can run port scanners themselves to identify which ports are open
and then make informed decisions as to whether the services are necessary for the day to
day running of the business.
When all unnecessary services have been disabled, the second step is to ensure that the
remaining services are as well protected as possible from attack. This is achieved by
applying security patches, in accordance with an organisational patch management
strategy. It is important to remember that while some of the services will be patched when
the operating system itself is patched, other applications may need patches that are only
available direct from the manufacturer. These third party applications should be patched
to the same level as the operating system, because if these applications are exploited
then the whole operating system may be exploited. For more detailed guidance on patch
management, see the Good Practice Guide on this subject [3].
7
General Advice on Securing Operating Systems
The third and final step that can be taken to reduce the risk to the operating system from
remote attack is to use a firewall. Traditionally, a firewall is a separate network device that
segments off the network connections between network devices. The installation,
configuration and positioning of firewalls is outside the scope of this guide, and requires a
high level of computer security experience.
In recent years, however, so called “personal firewalls” have become available. A personal
firewall is a software program that runs on the operating system and filters the network
ports so that ports which are not required by the business are not accessible to remote
users. Personal firewalls have their limitations, and indeed some have been found to
contain vulnerabilities themselves. Even so they add another layer of defence that can be
introduced to the operating system to mitigate the risk of remote attack.
3.2 Local attack
Operating systems need to not only be secured from remote attack, but also from local attack.
According to the CSI/FBI Computer Crime and Security Survey [4], 75% of companies cited
employees as a likely source of hacking attacks. It is also important to note that there is far
more operating system exploit code for local attacks than for remote, as local attacks are not
reliant on services being exposed to the network.
The best way of limiting the risks posed by local users is to follow a lockdown guide for the
operating system that is being used. These guides will be tailored to the specific operating
system and will detail exactly how to lock down the system to limit local attacks and prevent
such attacks occurring.
These guides are the best resource for securing an operating system, and this document is not
intended to be used as a substitute. Instead, it provides an overview of the types of attacks that
are applicable to all operating systems, and the countermeasures to deal with them.
3.2.1
Local attack vectors
There are three distinct attack vectors available to users with local access to the machine,
as illustrated in Figure 3.
Figure 3 - Local attack categories
8
General Advice on Securing Operating Systems
These attack classes are explored in more detail in the following table:
Attack class
Typical vulnerability classes
Attack or Outcome
OS attacks
• buffer overflow
• faulty logic
• unnecessary privileges
• poor configuration
• security by obscurity
• authentication service exposed
• privilege escalation
• custom code execution
• installation of spyware
• interception of confidential
information
• brute force attacks on
credentials
Application attacks • buffer overflow
• faulty logic
• poor configuration
• privilege escalation
• “phishing” attacks
Physical attacks
• running custom code and
vulnerability exploit code
• capturing keystrokes
• installation of spyware
• access to confidential HDD
information
• access to password files.
• access to internal HDD
• ability to attach external devices
(e.g. USB keys, physical key
sniffer).
• ability to alter system
configuration (e.g. BIOS
access).
Figure 4 - Summary of local attacks
Firstly, we will examine the risks of attacks against the operating system itself. Local users
who wish to attack or misuse an operating system usually have a considerable advantage
over remote attackers, in that they already have a legitimate user account on the target
machine.
The number of attacks that these users can perform is also greatly influenced by the
privileges that they have on the underlying operating system. Users with administrative
privileges can perform serious damage to an operating system, intentionally or otherwise.
Users with low-level privileges present a lower a level of risk, although it should be noted
that many legacy operating systems provide all users with high levels of privilege by
default. Finally, even users with low levels of privilege may be able to install ‘spyware’
software on the machine, allowing them to intercept the credentials of other users and
hence escalate their privileges.
Because there are considerably more local exploits than remote exploits known in the
public domain, if a local user is able to load exploit code onto the operating system it is
highly likely that they will be able to run this code in order to exploit operating system
vulnerabilities and hence raise their privileges.
This risk extends to local applications that run on the operating system. An OS may grant
an application a high level of privilege for business reasons. If a malicious user can use
9
General Advice on Securing Operating Systems
one application (“application A”) to call another application (“application B”, for example a
command shell), then it is possible that application B might be given the privileges of
application A rather than the user (whose privileges may not be as high).
Finally, there is the threat posed by physical attacks. Having physical access to a machine
can aid an attacker considerably. With access to local I/O devices such as the CDROM
and USB ports, an attacker can upload their own software or even boot their own
operating system (from within which they have access to the machine’s underlying file
system).
3.2.2
Local attack countermeasures
If the operating system is to be deployed and used by a large number of users then a
lockdown guide should be obtained and system specific countermeasures should be put
in place. The lockdown should limit the amount of access that users have over the
operating system, by ensuring that features which could be powerful if misused are
curtailed for all users bar administrators.
The specifics of actually performing a system lockdown cannot be reproduced in this
guide, as the steps that need to be taken vary considerably between operating systems.
However, there are a number of specific guides that are available which should be
investigated further if it is determined that a lockdown is required.
The primary defence against local exploits is again to ensure that the latest security
patches and hot-fixes are applied to both the operating system and the applications that
run on top of it, in accordance with the organisational patch management policy.
Additionally, a review should be performed on user accounts on the operating system, to
ensure that users only have the minimum rights that they need to be able to perform their
duties. The number of accounts with administrative privileges should be kept at the
absolute minimum. Newer operating systems allow for considerable granularity in the
assignment of permissions and these features should be taken advantage of wherever
possible.
The most effective way to stop users introducing unknown media onto an operating
system is to limit which users have permission to access I/O devices. For example, if the
purpose of the machine on which the OS is installed is to act as a web server in a
machine room, then there may be no requirement for the USB ports on the server to be
enabled.
Likewise, unless there are valid business reasons to allow users to install their own
software from CD ROM or to access data in this manner then the CD/DVD drive should
be disabled, or at least restricted to certain users.
10
General Advice on Securing Operating Systems
3.3 Authentication
The means by which users authenticate to the operating system is another area where security
is paramount. Authentication is the means by which users tell the operating system who they
are and what rights they have over the system. Therefore, successful attacks on an
authentication mechanism can give the attacker a high level of privilege to cause further
compromises.
3.3.1
Authentication attack vectors
A user can attempt to upgrade their OS privileges by obtaining the access credentials
(such as the logon password) for another user who has greater privileges. This can be
achieved by a range of methods, including guessing, taking advantage of user negligence,
or (if the operating system has a weak password policy) by conducting a brute force
attack on the password file to decrypt the password.
The risk of brute force attacks is increased if users are able to login remotely, because an
attacker is able to conduct the attack with less risk of being observed. Additionally, there
may be vulnerabilities associated with the protocol that users authenticate to the system
with. For example, if users connect to a remote server using a protocol such as telnet,
they may be unaware that all the traffic that they transmit to the machine is passed over
the network in clear-text. If an attacker is monitoring the traffic then these credentials can
be intercepted and used by the attacker to gain local user, or potentially even
administrative, access to the machine.
3.3.2
Authentication countermeasures
In order to protect against brute-force attacks, ensure that a good password policy is in
place for all accounts on the machine. The password policy should lock out accounts
when an incorrect password has been entered on a number of successive occasions. The
only account that it is not possible to have this lockout applied to is the administrative
account. If possible the username of this account should be renamed – so that attackers
need to know both the administrative username and the correct password. Likewise
regular monitoring of the system logs should be conducted to ensure that excessive log-in
attempts are not being made (auditing and accounting is discussed in more depth in a
subsequent section of this document).
For extra security, organisations may wish to consider introducing a second factor of
authentication. The use of system which requires a token (such as a smartcard) or a
biometric device (such as a fingerprint scanner) as well as a password can add to the
overall level of security.
11
General Advice on Securing Operating Systems
3.4 Viruses
Computer viruses and computer worms pose a serious threat to operating system security, and
due to the fact that they can be introduced to the system either locally or remotely, they are
discussed separately.
A computer virus is a program which distributes copies of itself, often without the permission or
knowledge of a user. A worm is a virus that can reproduce and run independently.
The most common way that viruses and worms get onto an operating system is through user
action, usually unintentionally.
3.4.1
Virus/worm attack vectors
Viruses can get onto the system in a number of ways. The first is by being imported from
CD, USB or floppy disk. The risk is considerably increased if users are allowed to import
their own files.
Likewise, if the operating system hosts an email program that receives messages from the
internet, then a virus could be imported by a user receiving and opening an executable
from an unverified source.
Computer worms travel across network connections and so they exploit the same type of
program or service that a remote attacker would, as discussed in the network attack
vectors section above. For example, the MS BLASTER worm exploited a vulnerability in
the Windows NetBIOS service to propagate and spread across the Internet.
3.4.2
Countermeasures
The installation of anti-virus software is widely perceived as the solution to the virus and
worm threat. Certainly this software plays its part. However, it is not a complete solution:
the CSI/FBI Computer Crime and Security Survey [4] showed that although 99% of
companies use antivirus software, 82% of them were hit by viruses and worms.
Additional countermeasures can and should be taken to protect against viruses and
worms. Because a worm exploits the same vulnerabilities as a remote attacker, the same
defences discussed in the network countermeasures section will prevent the attack and
spread of the worm. Likewise, worms and viruses take advantage of vulnerabilities in
application or operating system code in order to execute or propagate. By ensuring that
the operating system and all of the applications running on it all have the latest security
patches applied, the threat from viruses and worms is reduced even further.
Similarly, some viruses do not rely on system vulnerabilities at all, but on the fact that the
user running the virus may have a high level of control over the underlying operating
system. By ensuring that users do not have unnecessarily high privileges, as discussed in
the local attack countermeasures section, this risk can be reduced. It is also important to
educate users in the risks posed to the operating system by viruses and worms. This
12
General Advice on Securing Operating Systems
should both reduce the risks (for example by educating users not to run executable code
they receive from an unverified source) and improve the effectiveness of any recovery
process (by ensuring that all users know who to contact, what to do and what not to do
in the event of a virus or worm infecting their system).
As with many of aspects of computer security, the best defence is defence in depth. User
training and awareness should be enough to prevent viruses entering the operating
system. Having a frequently updated anti-virus package will catch any lapses in the user
training. Should this fail as well, well patched applications and operating systems should
still be resilient to the actions of the virus.
3.5 Access control
Prior to the widespread adoption of computers, it was common for confidential information to
be locked away. Authorised staff were granted access for the purpose of reading, writing or
altering the confidential material. The key holder would usually have been a trusted individual
(such as the bank manager in a bank). Sometimes two or more individuals would have separate
keys that worked together in an effort to mitigate internal threat through collaboration.
Based on the needs of businesses, and particularly the access control mechanisms required by
the military, a number of corresponding access control security principles have been formed for
the computing environment. These include:
•
The principle of least privilege: provide only those permissions to a user as are necessary
for them to undertake a particular business function and no more.
•
Need to know: only those individuals that need to know information in order to perform a
particular business function should be permitted access to that information.
•
Fallback to no access: in the event of any problem (such as the appearance of an
unauthenticated user or a user who does not appear in the access control list), the
system will default to denying all access to the object. This “fail closed” approach can be
contrasted with the “fail open” approach which is the norm in safety critical systems.
•
Accountability: all access attempts are monitored and subsequently audited.
The task of ensuring that certain data is appropriately available to the authentic owners (or
authorised parties), and not to those who do not have permission, now generally falls to the
operating system. Even applications written on top of the operating system will generally rely
upon the access control mechanisms provided by the OS. Access control refers to this problem
and is usually modelled to consist of access control policies and access control mechanisms.
Access control presumes that appropriate identification and authentication of a user has been
achieved.
It is not simply files that may require access control on a computer system – access to devices,
processes and so on may also need to be protected. The notion is therefore that objects need
to be subject to access control, where an object could be a file or a hardware device. The
13
General Advice on Securing Operating Systems
object needs to have a unique name (for referencing) and a set of valid operations. Example
operations for a file may be read, write and execute.
3.5.1
Access control models
The access control policy (ACP) specifies exactly who does, or does not, have access to
a particular object, whilst the access control mechanism is responsible for implementing
this. A number of different criteria may be set within an access control policy: some
common examples are shown in the figure below.
Roles
Based on a job assignment or business function. A particular
role necessitates a particular level of access.
Groups
An administrative convenience for managing groups of users
that require the same level of access to an object.
Physical/logical location
E.g. where a service is only available from console.
Time of day
Some services should only be authorised during a particular
time slot.
Transaction type
Some services types should not be permitted to particular
users – e.g. financial transactions above a particular amount.
Figure 5 - Access control criteria
There are a number of ways of modelling access from a subject to an object.
Discretionary access control (DAC) enables the owner of the resource to specify which
objects can access specific resources, i.e. the user can grant access at their discretion.
The user is the owner of any file that they create. The most common implementation of a
DAC is through access control lists (ACLs), which are dictated by the owners. The DAC
model is that typically found within Unix systems.
Mandatory access control (MAC) removes some of the freedom associated with DAC.
Although users have some control over specifying who may access their files, the
operating system makes the final decision. MAC is usually implemented in conjunction
with security labels: users are assigned a security clearance and objects are assigned a
security marking. The operating system must mediate access to objects that have a
marking higher than the accessing user’s clearance.
Role based access control (RAC or RBAC) uses a centrally administered set of controls to
determine how users interact with objects. Administrators of a system will put the user
into a role and then specify what that role is permitted to do.
Within each model there has to be a way of specifying the access policy. An access
control matrix is a table of users and objects, indicating what actions individual users can
take upon individual objects. Access control matrices are often used with DAC models
where the access rights can be assigned to the users (the capability model) or to the
14
General Advice on Securing Operating Systems
objects (the ACL model). A capability table specifies the access rights that a subject
possesses pertaining to specific objects. A capability table differs from an ACL because
the user is bound to a capability table whereas the object itself is bound to an ACL.
3.5.2
Models in practice
Unix introduced a simple model of file permissions in the 70’s which has proven to be
quite effective and easy to understand. In recent times, Unix has added a modern
approach to file permissions using ACLs, but very few organisations have adopted this
because of its complexity.
In the original Unix model, each file has three categories of user: User (u), Group (g) and
Other (o). Any user can be a member of any number of groups.
Each file has an owner and group attribute, and a set of flags (shown below) for each of
the categories:
•
•
•
read
write
execute
Note that a limitation of this model is that a file can only be a member of one group at a
time.
The main limitation of the Unix model is that ordinary users do not have the right to make
their own groups. There are ways around this, but Unix has not introduced a standard
solution to the problem.
“Secure” or “trusted” versions of Unix are available that implement broader policies and
models which can include MAC, RAC and the removal of the superuser (root). These
include the National Security Agency’s Security Enhanced Linux [11], Sun’s Trusted Solaris
[12] and Hewlett Packard’s Trusted HP-UX [13].
In the Microsoft Windows NT line of operating systems (including Windows XP), the OS
grants or denies privileges based on an ACL. Windows attaches access-control lists
(prioritised allow and deny by groups) comprising up to 30 different privileges for
operations on about 15 different kinds of objects. For example, on a service object one
can have the privilege to choose what application is run to effect the service (e.g. what
graphics program is used to open a graphics file). Although Windows access control is
fine-grained and expressive, software developers can have difficulty in evaluating the
consequences of the access-control configurations that they choose for their software
and services.
15
General Advice on Securing Operating Systems
3.5.3
Vulnerability classes
Unix
The most significant access control vulnerability class within Unix systems arises from the
setuid concept. setuid and setgid (short for “Set User ID” and “Set Group ID”,
respectively) are Unix access right flags that can be assigned to files and directories. They
are mostly used to allow users on a computer system to execute binary executables with
temporarily elevated privileges to perform a specific task. For example, a normal user
does not have access to the system password file, but still needs to be able to change
their password. This is done by granting the passwd executable the setuid privilege.
When the program runs it will run with the privileges of root and therefore be able to
access the password files.
Any mechanism by which a user can subvert a setuid executable can be used to execute
code as root. The buffer overflow is the classic path through which this is achieved, with
the buffer overflow payload containing code to spawn a shell with root privileges.
Windows
A recent research paper from Princeton University [5] provides some interesting insights
into the access control model provided by MS Windows, and illustrates possible
escalation paths that are known to have been successfully exploited by hackers:
Figure 6 - Privilege escalations in Windows from different vendors.
Dashed lines indicate that the problem had been fixed by patches at the
date of publication
16
General Advice on Securing Operating Systems
The following table explains these vulnerability classes and escalation paths in more detail.
Services
Several vendors poorly apply the Windows access control model to
their services; a common mistake is to assign the SERVICE CHANGE
CONFIG permission indiscriminately to services. The Windows XP
documentation states “…because this grants the caller the right to
change the executable file that the system runs, it should be granted
only to administrators.” But that warning fails to explain clearly that
permission to configure a service allows both setting the executable
and selecting the account under which the service runs, e.g., change
the run-as account to Local System. From Local System, all things are
possible.
Registry
Some registry keys store sensitive information like the path to the
executable acting as a user’s shell, the library to be loaded by a
program, the identity of an operating system object etc. If an
adversary can overwrite the contents of a sensitive key with the path
of their library or executable, they could cause their code to be
executed. The standard configuration of AOL includes a registry entry
binding the name of a DLL file (which, in some circumstances, is
loaded and executed by the AOL software). The access permissions
permit any user to write this entry; the attacker can substitute the
name of their own DLL and wait for some other AOL user to execute
it.
Power users
There are many privilege-escalation paths from Power Users to Local
System.
3.6 Auditing
The auditing capabilities within an operating system are usually at least partly designed as a
security control. From a security perspective auditing is a control that is primarily detective, but
its very existence is likely to have a deterring effect on potential attackers. Auditing can ensure
that users are accountable for their actions, verify that security policies are enforced and,
importantly, provide a trail of actions that can be used to investigate security incidents.
During the transition from large scale single-vendor software systems to COTS solutions, many
would say that audit event reporting was diminished in importance, with COTS providers
disclaiming liability for security performance. A general focus on security over the past few
years, driven by increased network exposure, has increased the awareness for auditing as a
direct or indirect security control. It looks likely that government regulations (notably US
legislation mandating corporate and enterprise auditing requirements) and business compliance
requirements such as Sarbanes-Oxley [6] will prompt a degree of standardisation and
development of the auditing infrastructure.
17
General Advice on Securing Operating Systems
3.6.1 What is the operating system auditing function?
Accountability is tracked through recording user, system and application activities. The
recording is done through auditing functions and mechanisms within an operating system
or application. Audit trails typically contain information about operating system activities,
application events and user actions.
A good system security policy should describe what actions and events are to be audited
and logged. This will probably be based upon the outcome of a system risk assessment,
legislative requirements and requirements of the disaster recovery policy. Archiving and
storage of non-live logs will also need to be considered. One of the problems faced by
some system auditing solutions is their centralised and multipurpose nature. Security
events are often lumped in with system events making for a huge amount of material.
Additionally this is often rotated or cleared by default periodically. This can make mining
for relevant information difficult and so needs to be considered before an incident occurs.
How, exactly, will information be extracted and pieced together? Are there logging options
that can be configured in advance to simplify this task?
OS level auditing will probably need to be supplemented with auditing from applications
that have security relevance. Individual security logs from applications, stack traces for
errors and so on can provide a level of detail regarding applications security events that is
simply unavailable at the OS level.
Regardless of how OS level auditing is performed, the function itself must be protected: it
needs to be kept confidential, its integrity must be preserved and the logging service must
be available when required. Exactly how this is achieved depends upon the individual
solution. Inevitably, a network-wide auditing solution takes more consideration than a
solution focussed on individual servers, however the latter is less likely to scale efficiently.
3.6.2 Logging in Windows and Unix systems
In Windows and Unix systems, applications and components submit free-form text
messages to system logging facilities. Under Unix this is typically the syslog process and
in Windows the System, Security and Application event logs. Additionally applications that
terminate unexpectedly may produce a core dump under Unix or trigger the default
debugger under Windows. Java applications often fall back to the standard Java logging
facility log4j. All of these facilities can work on a per system basis or can provide
centralised logging on a network basis.
The fundamental problem with such free-form event records is that each application
developer individually determines what information should be included in an audit event
record, and the overall format in which that record should be presented to the audit log.
This variance in formatting among thousands of instrumented applications makes the job
of parsing audit event records by analysis tools difficult and error prone. Such domain and
application specific parsing code included in analysis tools is also difficult to maintain, as
changes to event formats inevitably work their way into newer versions of the applications
over time.
18
General Advice on Securing Operating Systems
3.6.3 The future of OS-level auditing
Auditing software such as the open source OpenXDAS project [7] has begun appear in
response to new legislation and business compliance requirements to provide a more
structured alternative to free-form text audit logging. According to the OpenXDAS site,
both US companies and those centred in the EU are rapidly adopting standards including
ISO9001 that require computer audit trails necessary to minimise the danger of civil
litigation and legal prosecution. The XDAS specification defines a well-considered event
format for security related events, an event taxonomy with event types that cover most
security-related event scenarios, and a standardized API for event submission and
management.
Development work continues on the syslog software [8] (which is also available for MS
Windows), although the rate of development does not seem to mirror that of the XDAS
specification.
Windows Vista has introduced a new eventing model [9][10] in which event descriptions
contain more data and also include event information in XML format, making it easy to
expose events data to management tools. Other features include the ability to launch
tasks triggered by specific events and to customize the event viewer display.
19
General Advice on Securing Operating Systems
4
Sources of further guidance
4.1 Security lockdown guides
The National Security Agency (NSA) have released detailed lockdown guides for:
Apple Mac OS X
Apple Server Operating Systems
Microsoft Windows XP
Microsoft Windows 2000
Microsoft Windows Server 2003
Sun Solaris 8
Sun Solaris 9
These can be downloaded at
http://www.nsa.gov/snac/downloads_os.cfm?MenuID=scg10.3.1.1
The Center for Internet Security (CIS) has issued a range of publicity about lockdown
configurations:
http://www.cisecurity.com
If you prefer to use a free operating system, NSA have also released Security-Enhanced Linux.
This builds a number of security enhancements into the Linux kernel. Details on this project can
be found at:
http://www.nsa.gov/selinux/
Microsoft have also released their own lockdown guides for their operating systems:
Windows XP
http://www.microsoft.com/technet/security/prodtech/windowsxp/secwinxp/default.mspx
Windows 2000
http://www.microsoft.com/technet/security/prodtech/windows2000/win2khg/default.mspx
Windows 2003
http://www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.
mspx
4.2 Security tools
There are a number of security tools that system administrators may wish to consider to check
the security of their operating system. Tools include port scanners, such as nmap, which will
determine what services the operating system offers to the network, through to tools such as
Cain and John which can be used to test the password strength of accounts on the operating
system.
A comprehensive list of the top 100 most popular security tools (as voted for by nmap users)
can be found at: http://sectools.org. This list was last updated in 2006.
20
General Advice on Securing Operating Systems
5
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
21
Wikipedia, http://en.wikipedia.org/wiki/Main_Page
Understanding the Linux Kernel (3rd edition), D. Bovet & M. Cesati, O’Reilly, 2005.
Good Practice Guide – Patch Management, http://www.cpni.gov.uk/docs/re-2006102400719.pdf, October 2006.
CSI/FBI Computer Crime and Security Survey 2003. http://www.reddshell.com/docs/csi_
fbi_2003.pdf
“Windows Access Control Demystified”, S. Govindavajhala and A. W. Appel, January
2006. www.cs.princeton.edu/~sudhakar/papers/winval.pdf
“Sarbanes Oxley for IT security?”, http://www.theregister.co.uk/2005/05/03/sarbanes_
oxley_for_it_security/
OpenXDAS http://openxdas.sourceforge.net/
“Security Issues in Network Event Logging (syslog)”, http://www.ietf.org/html.charters/
syslog-charter.html
“Windows events”, http://msdn2.microsoft.com/en-us/library/aa964766.aspx
“Windows Vista Product Features for IT professionals”, http://technet.microsoft.com/enus/windowsvista/aa906027.aspx
SE Linux home page, http://www.nsa.gov/selinux/
Trusted Solaris home page, http://www.sun.com/software/solaris/trustedsolaris/
Description of the HP-UX Trusted System, http://docs.hp.com/en/B2355-90121/ch01.
html