The SUSE Linux Enterprise Server Security and Hardening Guide deals with the particulars of installation and set up of a secure SUSE Linux Enterprise Server server and additional post-install processes required to further secure and harden that installation. Security and hardening elements and procedures are best applied to a server both during installation and post-installation and aim to improve the fitness of the system for the purposes demanded by its administrator. The understanding of this guide is to support the administrator with the security related choices and decisions that the administrator will have to make. The individual steps and procedures are to be seen as a proposal, not as something that ultimately needs to be done. In many cases, this guide will even force the reader to discuss the usefulness towards the objectives that the measures may provide - or not.
Obviously, the objective is to improve the security value of the system. Definitions about the meaning of the term security vary, but we want to settle on one that is both simple, abstract and therefore possibly true for most IT solutions:
A good system does what it is expected to do, and it does it well.
A secure system is a good system that does nothing else.
The part with
nothing else is certainly within the focus of
this guide. The Linux system is architected in such way that security
policies are enforced. These policies are (fairly generic and incomplete list):
DAC - Discretionary Access Control: File and directory permissions as we know them: chmod, chown
privileged ports: TCP and UDP ports 0-1023 as well as raw sockets are only to the super user
other privileged operations: The loading of kernel modules, configuration of network interfaces, exclusively all security relevant settings of the Linux kernel, are operations that can only be done by the root user, eg. the user with the numeric userID 0.
Attacking a system means to attempt to overcome (eg. circumvent or break) these privilege boundaries in a way that the administrator of the system or the programmer of the corresponding subsystem has not taken into account.
hardened system raises the bar for the attacker
to make the system do what
he wants by reducing the area
that the system exposes to the attacker (often called attack surface),
and by mitigating the risk that exists for the system if a part of it
fails to handle untrusted input safely, thereby allowing actions within the
context of this part of the system that were not intended by the programmer.
Security is about decisions, and whenever security is in (apparent) opposition to function, these decisions become trade-offs. While it can be argued that all systems should be set up to be as securely as possible, some levels of security and hardening may very well be overkill in some cases. Each system's operational environment has its own security requirements derived from business drivers or regulatory compliance mandates (e.g. SOX, HIPAA, PCIDSS, etc.) and an effective business requirements analysis should be performed in order to determine the right level of security and hardening to be applied to a server or defined as part of a baseline server build.
As a final note before we begin: You may encounter individual requirements in regulatory compliance frameworks that may not make sense from a technical perspective, or they do not serve the purpose of improving security. It may be a productive attitude to simply implement what is required, but whenever there is a contradiction to security, an informed discussion in the documentation serves the overall purpose of your regulative compliance framework much more than blindly obeying the specifications. Please feel encouraged to dispute list items that you think are counterproductive.
While in most cases in this document reference will be made to a single server target or host, the scope can generally be applied to more than one machine. We generally assume that the security target can cover one or more systems running SUSE Linux Enterprise Server.
We explicitly do not make any assumtions about the hostility of the network that the systems are connected to, or the cooperative nature of the users that leverage the services provided by the systems.
In turn, this means that you partially define your context on your own when reading through this document. You will need to broaden the meaning of individual portions to adopt it to your environment. In some cases, such as the use case of a server that is exposed to the Internet, this document may even be insufficient or incomplete; however, it may still serve as a good starting point on your journey towards an increased level of confidence that your system will behave like you want it to.
About trust: Trust relationships exist among all systems that participate in networked transactions. Basically, the trust relationship between the persons that use the systems is transported across these systems. The chain that is formed by your trust relationships is only as strong as the weakest link. If we further assume that not all your problems are between keyboards and chairs, then it is up to the designer of the network of systems to watchguard the trust relationships. It is good practice to graphically visualize the trust relationships with the services in a schematic overview or map of your network. Generally, it is up to the owner of a resource to enforce the policies imposed on that resource; this would usually be the server that provides the resource. The client that opens a connection to request the resource can only be made responsible for the actions that it performs. This refers to the action of opening the connection to start with, but to nothing else as such.
The case of hostile users is special and unique: The Human Resources department may be able to solve some of your security problems in your computing environment at least as well as some technical measures can. Please make sure that the necessary regulations in your environment fit your needs, and that they back your intentions instead of obstructing them if you need to work around a missing support from your HR department (and your management).
Persons that have administrative privileges on a system are automatically considered trusted.
A Linux system - without any additional security frameworks such as SELinux - is a single level security system: From a security policy perspective there is only the superuser (root) and non-privileged users. System users are non-root userIDs that have access to files specific to their purpose. All system user identities are inaccessible for local or networked users!) The separation of (systems-) administrative duties is complicated by this simplicity. Some tools however help: Make use of sudo(8) for administrative tasks, but be aware that once the privilege boundary is crossed, a program running with root privileges does not enforce any file access policies for non-privileged users any more. vi(1) that runs as root can read and write to any file in the system.
Another tool to mitigate the risk of the abuse or accidential misuse of administrative privileges is Novell's Privileged User Manager product. More information is available here:
Physical security of the server is another assumption made here, where
the server is protected from theft and manipulation by unauthorized
persons. A common sobering thought amongst security professionals is the
ten-second Denial of Service simply unplug the wires and
reboot the server. Physical security must be insured and physical access
must be controlled. Otherwise, all assumtions about at least the avaliability
of these systems are void.
The use of cryptography to protect the confidentiality of transactions
with the services that your system provides is generally encouraged. The
need to implement crypto-enhancements is strongly dependent on the
operational environments of all participating systems. Please keep in
mind that you need to verify all of the possible security benefits that
cryptography can provide, for
all of your services, and
that these benefits are not delivered automatically just by turning on
encrypt option of your service (if you can enjoy the
idyllic situation where encryption is available as a button to check):
Protection against reading the
contentof a transaction
Protection against knowing that a transaction exists, and some properties that it may have, such as size, identities of involved parties, their presence, ...
Protection against alteration of content. Be aware that cryptography does not automatically provide this kind of protection.
Protection against identity fraud. Cryptogrphy that does not know
about identities of participating entities cannot deliver this value.
If an ecrypted data connection to your server can articulate
integrity, then the server
may provide authenticity of
the content, but the cryptographical part cannot.
Keep in mind that encryption of data for confidentiality purposes can merely reduce the size of the data to protect from the actual size to the size of the key that is used to encrypt the data. This results in a key exchange problem for encrypted transactions, and in a key management problem for encrypted data storage. Since data is (typically, there are exceptions!) processed in clear, you need your vault unlocked while data within is being worked with. The encryption of such data on the file system or block device layer helps against the theft of the system, but it doesn't help the confidentiality of the data while the system is running.
If you want to implement a consistent security policy covering multiple hosts on a network then organizational procedures must ensure that all those hosts can be trusted and are configured with compatible security configurations enforcing an organization wide security policy. Isolation of groups of systems that maintain data of the same trust domain can provide an adequate means of control; ultimately, the access controls to these systems, both for end users and for other systems, need to be carefully designed, configured, inspected and monitored.
IMPORTANT: Data can only be trusted to the degree that is assiciated with the domain where it comes from. If data leaves the domain in which security policies can be enforced, then this data should consequently be associated with the trust of the target domain. (This is the first facepalm paragraph of this guide. Do not stop fixing occurrences of failure and misconfiguration in your network - it pays off.)
For a review of industry best practices on security, the development of sound security processes, controls, development, reviews and audit practices and incident management, you can review a public RFC (request for comments). RFC2196 is the ongoing work of the world-wide community and individual security and process experts. You can review it online here: http://www.faqs.org/rfcs/rfc2196.html. An RFC is an open and living document that invites "comments" and review". Enhancements and improvements are welcomed; you will find instructions on where to send those suggestions within the document itself.
This guide provides initial guidance on how to set up and secure a SUSE Linux Enterprise Server installation but it is not intended to be the only information required for a system administrator to learn how to operate Linux securely. Assumptions are made within this guide that the reader has knowledge and understanding of operating security principles in general, and of Linux administrative commands and configuration options in particular. Upon reaching this section of the document, we believe that the willingness of the reader to learn can be safely assumed.
The guide contains
Sections and many examples. The
a complete set of guidance and recommendations that can be used as a
stand-alone reference within a specific context. For example, Part 1
contains a reference to Common Criteria and SUSE Linux Enterprise Server.
Part 2 contains more general system security and service protection schemes.
Chapters will divide the books into logical parent
topics within the
parts and likewise the
sections sub-divide even further.
Examples will exist throughout the whole guide, and many more can be found in referenced man pages or documentation.
We provide HTML and PDF versions of our books in different languages. The following manuals for users and administrators are available for this product:
Deployment Guide,(↑ Deployment Guide )
Shows how to install single or multiple systems and how to exploit the product inherent capabilities for a deployment infrastructure. Choose from various approaches, ranging from a local installation or a network installation server to a mass deployment using a remote-controlled, highly-customized, and automated installation technique.
Administration Guide,(↑ Administration Guide )
Covers system administration tasks like maintaining, monitoring, and customizing an initially installed system.
Security Guide,(↑ Security Guide )
Introduces basic concepts of system security, covering both local and network security aspects. Shows how to make use of the product inherent security software like AppArmor (which lets you specify per program which files the program may read, write, and execute), and the auditing system that reliably collects information about any security-relevant events.
Deals with the particulars of installing and setting up a secure SUSE Linux Enterprise Server, and additional post-installation processes required to further secure and harden that installation. Supports the administrator with security-related choices and decisions.
System Analysis and Tuning Guide,(↑ System Analysis and Tuning Guide )
An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to efficiently manage resources. Also contains an overview of common problems and solutions, and of additional help and documentation resources.
Virtualization with Xen,(↑ Virtualization with Xen )
Offers an introduction to virtualization technology of your product. It features an overview of the various fields of application and installation types of each of the platforms supported by SUSE Linux Enterprise Server as well as a short description of the installation procedure.
Virtualization with KVM for IBM System z,(↑ Virtualization with KVM for IBM System z )
Offers an introduction to setting up and managing virtualization with KVM (Kernel-based Virtual Machine) on SUSE Linux Enterprise Server. Learn how to manage KVM with libvirt or QEMU. The guide also contains detailed information about requirements, limitations, and support status.
AutoYaST,(↑ AutoYaST )
AutoYaST is a system for installing one or more SUSE Linux Enterprise systems automatically and without user intervention, using an AutoYaST profile that contains installation and configuration data. The manual guides you through the basic steps of auto-installation: preparation, installation, and configuration.
Storage Administration Guide,(↑Storage Administration Guide)
Provides information about how to manage storage devices on a SUSE Linux Enterprise Server.
In addition to the comprehensive manuals, several quick start guides are available:
Installation Quick Start,(↑Quick Start Manuals)
Lists the system requirements and guides you step-by-step through the installation of SUSE Linux Enterprise Server from DVD, or from an ISO image.
Gives a short overview how to enable and configure the auditing system and how to execute key tasks such as setting up audit rules, generating reports, and analyzing the log files.
Helps you understand the main concepts behind AppArmor®.
Virtualization with Linux Containers (LXC),(↑Quick Start Manuals)
Gives a short introduction to LXC (a lightweight
virtualization method) and shows how to set up an LXC
host and LXC containers.
Find HTML versions of most product manuals in your installed system under /usr/share/doc/manual or in the help centers of your desktop. Find the latest documentation updates at http://www.suse.com/doc where you can download PDF or HTML versions of the manuals for your product.
Several feedback channels are available:
For services and support options available for your product, refer to http://www.suse.com/support/.
To report bugs for a product component, log in to the Novell Customer Center from http://www.suse.com/support/ and select .
We want to hear your comments about and suggestions for this manual and the other documentation included with this product. Use the User Comments feature at the bottom of each page in the online documentation or go to http://www.suse.com/doc/feedback.html and enter your comments there.
For feedback on the documentation of this product, you can also send a mail to email@example.com. Make sure to include the document title, the product version, and the publication date of the documentation. To report errors or suggest enhancements, provide a concise description of the problem and refer to the respective section number and page (or URL).
The following typographical conventions are used in this manual:
/etc/passwd: directory names and filenames
placeholder: replace placeholder with the actual value
PATH: the environment variable PATH
ls, --help: commands, options, and parameters
user: users or groups
Alt, Alt+F1: a key to press or a key combination; keys are shown in uppercase as on a keyboard
, : menu items, buttons
This paragraph is only relevant for the architectures amd64, em64t, and ipf. The arrows mark the beginning and the end of the text block.
Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.