Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Linux Enterprise Server 12 SP4

About This Guide

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 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.

This guide supports administrator in making security related choices and decisions. The individual steps and procedures should be seen as proposals, not as strict rules. You will often need to evaluate the usefulness of measures for your organization yourself.

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 and abstract:

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 focus of this guide lies on doing nothing else. The Linux system is constructed in such way that security policies are enforced. These policies consist of the following concepts (fairly generic and incomplete list):

  • DAC (Discretionary Access Control): File and directory permissions, as set by chmod and chown.

  • Privileged ports: TCP and UDP ports 0-1023 and raw sockets can only be used by root.

  • Other privileged operations: Loading kernel modules, configuring network interfaces, all security relevant settings of the Linux kernel. These are operations that can only be done by the root user, that is the user with the user ID 0, or any other process with the necessary capabilities.

Attacking a system means to attempt to overcome privilege boundaries, for example by circumventing or breaking them. That means the administrator or programmer of the system has not anticipated this scenario.

A hardened system raises the bar by reducing the area that the system exposes to the attacker (often called attack surface). A hardened system can also provide measures to reduce the impact of vulnerabilities in the parts of the systems that must be exposed to a potential attacker.

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. SUSE Linux Enterprise Server can, for example, be configured to comply with security standards, such as SOX, HIPAA and PCIDSS. It can also be set up to fulfill the requirements from the German Federal Office of Information Security (Bundesamt für Sicherheit in der Informationstechnik) as described in BSI TR-02102-1. An effective business requirements analysis should be performed 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. Feel encouraged to dispute list items that you think are counterproductive.

1 Assumptions and Scope

References in this document will usually be made to a single server target or host, however 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 assumptions 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 adapt 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 toward 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. In this way, the trust relationship between the people 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. 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 security problems in your computing environment; in addition, some technical measures can be taken. 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 user IDs that have access to files specific to their purpose. The separation of administrative duties is complicated by this simplicity. Some tools help: Use sudo(8) for administrative tasks, but be aware that after the privilege boundary is crossed, a program running with root privileges does not enforce any file access policies for non-privileged users anymore. vi(1) that runs as root can read and write to any file in the system.

Another tool to mitigate the risk of abuse or accidental misuse of administrative privileges is NetIQ'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 among security professionals is the ten-second Denial of Service: Unplug the wires and reboot the server. Physical security must be ensured and physical access must be controlled. Otherwise, all assumptions about at least the availability of these systems are void.

Note: Cryptography

The use of cryptography to protect the confidentiality of transactions with the services that your system provides is generally encouraged. The need to implement cryptographic enhancements is strongly dependent on the operational environments of all participating systems. 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 by turning on the 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 content of 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, etc.


Protection against alteration of content. Be aware that cryptography does not automatically provide this kind of protection.


Protection against identity fraud. Cryptography that does not know about identities of participating entities cannot deliver this value.

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 does not 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: Trusting Data

Data can only be trusted to the degree that is associated with the domain it comes from. If data leaves the domain in which security policies can be enforced, it should consequently be associated with the trust of the target domain.

For a review of industry best practices on security, the development of sound security processes, controls, development, reviews, audit practices and incident management, you can review a public RFC (request for comments). RFC 2196 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 welcome; 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.

2 Contents of this Book

Chapter 1, Common Criteria contains a reference to Common Criteria and SUSE Linux Enterprise Server. Chapter 2, Linux Security and Service Protection Methods contains more general system security and service protection schemes.

3 Verfügbare Dokumentation

Note: Online-Dokumentation und neueste Aktualisierungen

Die Dokumentation für unsere Produkte steht unter http://www.suse.com/documentation/ bereit. Hier finden Sie außerdem die neuesten Aktualisierungen und Sie können die Dokumentation durchsuchen oder in verschiedenen Formaten herunterladen.

Darüber hinaus befindet sich die Dokumentation in der Regel auf dem installierten System im Verzeichnis /usr/share/doc/manual.

Die folgende Dokumentation ist für dieses Produkt verfügbar:

Schnelleinführung zur Installation

Die Systemanforderungen werden aufgelistet, und Sie werden schrittweise durch die Installation von SUSE Linux Enterprise Server von DVD oder einem ISO-Abbild geführt.


Erfahren Sie, wie Sie einzelne oder mehrere Systeme installieren und die Produktfunktionen für eine Bereitstellungsinfrastruktur nutzen. Wählen Sie aus verschiedenen Ansätzen. Von der lokalen Installation über einen Netzwerkinstallationsserver bis zu einer Masseninstallation über eine entfernt gesteuerte, hochgradig angepasste und automatisierte Installationsmethode ist alles möglich.


Es behandelt Systemverwaltungsaufgaben wie Wartung, Überwachung und Anpassung eines neu installierten Systems.

Virtualization Guide

Hier wird die Virtualisierungstechnologie im Allgemeinen beschrieben, die vereinheitlichte Schnittstelle libvirt für die Virtualisierung wird vorgestellt und Sie finden ausführliche Informationen zu bestimmten Hypervisoren.

Storage Administration Guide

Hier finden Sie Informationen zum Verwalten von Speichergeräten auf einem SUSE Linux Enterprise-Server.


AutoYaST ist ein System für die unbeaufsichtigte Massenbereitstellung von SUSE Linux Enterprise Server-Systemen über ein AutoYaST-Profil, in dem sich Installations- und Konfigurationsdaten befinden. Das Handbuch führt Sie durch die grundlegenden Schritte der automatischen Installation: Vorbereitung, Installation und Konfiguration.

Security Guide

Zudem werden grundlegende Konzepte der Systemsicherheit vorgestellt, die sowohl lokale als auch netzwerkbezogene Aspekte abdecken. Es wird erläutert, wie Sie die in das Produkt eingegliederte Sicherheitssoftware wie AppArmor oder das Prüfsystem nutzen, mit dem zuverlässig Informationen zu allen sicherheitsspezifischen Ereignissen gesammelt werden.

Hardening Guide

Hier finden Sie detaillierte Informationen zum Installieren und Einrichten eines sicheren SUSE Linux Enterprise-Servers sowie zu weiteren Verfahren, die nach dem Installieren anfallen und die Sicherheit und Stabilität der Installation erhöhen. Der Administrator wird bei sicherheitsrelevanten Auswahlmöglichkeiten und Entscheidungen unterstützt.

System Analysis and Tuning Guide

Ein Administratorhandbuch zur Problemsuche, Fehlerbehebung und Optimierung. Erfahren Sie, wie Sie Ihr System mithilfe von Überwachungswerkzeugen prüfen und optimieren können und wie Sie Ihre Ressourcen effizient verwalten. Es enthält zudem einen Überblick über häufige Probleme und Lösungen sowie weitere Hilfequellen und Dokumentationsressourcen.

SMT Guide

Ein Administratorhandbuch zum Subscription Management Tool. Dabei handelt es sich um ein Proxy-System für das SUSE Customer Center mit Repository und Registrierungszielen. Erfahren Sie, wie Sie einen lokalen SMT-Server installieren und konfigurieren, Repositorys spiegeln und verwalten, Client-Computer verwalten und Clients für die Verwendung von SMT konfigurieren.


Einführung in den GNOME-Desktop von SUSE Linux Enterprise Server. Das Handbuch begleitet Sie bei der Verwendung und Konfiguration des Desktops und hilft Ihnen, wichtige Aufgaben zu erledigen. Dies richtet sich in erster Linie an Endbenutzer, die GNOME als ihren Standard-Desktop nutzen möchten.

4 Rückmeldungen

Für Rückmeldungen stehen mehrere Kanäle zur Verfügung:

Fehler und Verbesserungsanforderungen

Informationen zu Diensten und Support-Optionen, die für Ihr Produkt verfügbar sind, finden Sie unter http://www.suse.com/support/.

Die Community bietet Hilfe für openSUSE. Weitere Informationen finden Sie unter https://en.opensuse.org/Portal:Support.

Zum Melden von Fehlern in einer Produktkomponente gehen Sie zu https://scc.suse.com/support/requests, melden Sie sich an und klicken Sie auf Neu erstellen.

Anregungen und Kritik unserer Leser

Wir freuen uns über Ihre Kommentare und Vorschläge zu diesem Handbuch und den anderen Teilen der Dokumentation dieses Produkts. Verwenden Sie die Funktion „Benutzerkommentare“ unten auf den einzelnen Seiten der Online-Dokumentation oder geben Sie Ihre Kommentare auf der Seite http://www.suse.com/documentation/feedback.html ein.


Für Feedback zur Dokumentation dieses Produkts können Sie auch eine Email an doc-team@suse.de senden. Geben Sie auf jeden Fall auch den Titel der Dokumentation, die Produktversion und das Datum der Veröffentlichung der Dokumentation an. Geben Sie eine genaue Beschreibung des Problems an und beziehen Sie sich auf die entsprechende Abschnittsnummer und Seite (oder URL), wenn Sie Fehler melden oder Verbesserungen vorschlagen.

5 Konventionen in der Dokumentation

In der vorliegenden Dokumentation werden die folgenden Hinweise und typografischen Konventionen verwendet:

  • /etc/passwd: Verzeichnis- und Dateinamen

  • PLATZHALTER: Ersetzen Sie PLATZHALTER durch den tatsächlichen Wert.

  • PATH: die Umgebungsvariable PATH

  • ls, --help: Kommandos, Optionen und Parameter

  • Benutzer: Benutzer oder Gruppen

  • Paketname : Name eines Pakets

  • Alt, AltF1: Eine Taste oder Tastenkombination. Tastennamen werden wie auf der Tastatur in Großbuchstaben dargestellt.

  • Datei, Datei › Speichern unter: Menüelemente, Schaltflächen

  • AMD/Intel Dieser Absatz ist nur für die AMD64-/Intel-64-Architektur relevant. Die Pfeile kennzeichnen den Anfang und das Ende des Textblocks.

    IBM Z, POWER Dieser Absatz ist nur für die Architekturen z Systems und POWER relevant. Die Pfeile kennzeichnen den Anfang und das Ende des Textblocks.

  • Tanzende Pinguine (Kapitel Pinguine, ↑Zusätzliches Handbuch): Dies ist ein Verweis auf ein Kapitel in einem anderen Handbuch.

  • Kommandos, die mit root-Privilegien ausgeführt werden müssen. Diesen Befehlen kann zur Ausführung als nicht privilegierter Benutzer auch häufig das Präfix sudo vorangestellt sein.

    root # command
    tux > sudo command
  • Kommandos, die von Benutzern ohne Privilegien ausgeführt werden können.

    tux > command
  • Hinweise

    Warning: Warnhinweis

    Wichtige Informationen, die Sie kennen müssen, bevor Sie fortfahren. Warnt vor Sicherheitsrisiken, potenziellen Datenverlusten, Beschädigung der Hardware oder physischen Gefahren.

    Important: Wichtiger Hinweis

    Wichtige Informationen, die Sie beachten sollten, bevor Sie den Vorgang fortsetzen.

    Note: Anmerkung

    Ergänzende Informationen, beispielsweise zu unterschiedlichen Softwareversionen.

    Tip: Tipp

    Hilfreiche Informationen, etwa als Richtlinie oder praktische Empfehlung.

Print this page