SYS.1.3

SYS.1.3 Servers Running Linux and Unix

Server systems frequently run the Linux or Unix operating systems. Examples of classic Unix systems include the BSD family (FreeBSD, OpenBSD, and NetBSD), Solaris, and AIX...

Description

Introduction

Server systems frequently run the Linux or Unix operating systems. Examples of classic Unix systems include the BSD family (FreeBSD, OpenBSD, and NetBSD), Solaris, and AIX. Linux, in contrast, is not a classic Unix but a functional Unix system, meaning the Linux kernel is not based on the original source code from which the various Unix derivatives developed. This building block covers all operating systems in the Unix family, including Linux as a functional Unix system. Since the configuration and operation of Linux and Unix servers are similar, this building block collectively refers to Linux and Unix as “Unix servers” or “Unix-like”.

Linux is free software developed by the open-source community. This means it may be used, copied, distributed, and modified by anyone. In addition, there are companies that bundle and maintain the various software components into a distribution and offer additional services. Common distributions for Linux servers include Debian, Red Hat Enterprise Linux / CentOS, SUSE Linux Enterprise / openSUSE, and Ubuntu Server. In addition, there are Linux distributions tailored for specific use cases and devices, such as OpenWRT for routers.

The services offered on a Unix server are often central and therefore particularly exposed. For this reason, Unix servers are not only critical for business processes and professional tasks but also frequently become the target of attacks. This makes the availability and hardening of Unix servers especially important.

Objective

The objective of this building block is to protect information provided and processed by Unix servers. The requirements of the building block primarily apply to Linux servers but can generally be adapted for Unix servers. Requirements are formulated for how the operating system should be configured and operated, regardless of the server’s intended purpose.

Scope and Modeling

The building block SYS.1.3 Servers Running Linux and Unix is to be applied to all servers running Linux or Unix-based operating systems.

The building block contains fundamental requirements for the setup and operation of Unix servers. It specifies and supplements the aspects addressed in building block SYS.1.1 General Server with the specific characteristics of Unix systems. Accordingly, both building blocks must always be applied together.

Security requirements for possible server functions such as web servers (see APP.3.2 Web Server) or email servers (see APP.5.3 General Email Client and Server) are not addressed in the present building block but are the subject of separate building blocks. An exception is the Unix-specific server service SSH, which is also covered in this building block. The topic of virtualization is likewise not addressed in the present building block but in building block SYS.1.5 Virtualization.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to describe the threat landscape. The following specific threats and vulnerabilities are of particular significance for building block SYS.1.3 Servers Running Linux and Unix.

Spying on Information About the System and Users

With the help of various Unix programs, it is possible to query data that the IT system stores about users. This also includes data that can provide information about the performance profile of users. This information includes information about other logged-in users as well as technical information about the operating system installation and configuration.

For example, with a simple program that evaluates at defined time intervals the information provided by the “who” command, any user can create a detailed usage profile for an account. In this way, the absence times of system administrators can be determined in order to use these times for unauthorized actions. Furthermore, it can be determined which terminals are permitted for privileged access. Other programs with similar capabilities for data misuse are “finger” or “ruser”.

Exploitability of the Scripting Environment

Script languages are often used in Unix operating systems. Scripts are a listing of individual commands stored in a text file and called, for example, from the command line. Due to the extensive range of functions in the scripting environment, attackers can extensively exploit scripts for their own purposes. Furthermore, activated script languages can be very difficult to contain.

Dynamic Loading of Shared Libraries

The command line option LD_PRELOAD causes a dynamic library to be loaded before all other standard libraries required in an application. This allows individual functions of the standard libraries to be selectively overridden by custom ones. Attackers could, for example, manipulate the operating system such that malicious functions are also executed when certain applications are used.

Software from Third-Party Sources

On Unix-like IT systems, it sometimes happens that users download and compile software source code themselves rather than installing ready-made software packages. When ready-made software packages are used, they are also in some cases installed from third-party sources without further review, rather than exclusively from the package sources of the producing company. Each of these alternative approaches to software installation carries additional risks, as they can result in the installation of faulty or incompatible software, or malware.

Requirements

The following are the specific requirements of building block SYS.1.3 Servers Running Linux and Unix. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is sensible and appropriate.

ResponsibilitiesRoles
Primarily responsibleIT Operations
Additional responsibilitiesNone

Exactly one role should be Primarily responsible. In addition, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

SYS.1.3.A1 DISCONTINUED (B)

This requirement has been discontinued.

SYS.1.3.A2 Careful Assignment of IDs (B)

Each login name, each user ID (UID), and each group ID (GID) MUST appear only once. Each user account MUST be a member of at least one group. Every GID that appears in the file /etc/passwd MUST be defined in the file /etc/group. Each group SHOULD contain only the accounts that are absolutely necessary. In networked systems, it MUST also be ensured that the assignment of user and group names, UIDs, and GIDs is consistent across the system network, if cross-system access creates the possibility that the same UIDs or GIDs could be assigned to different user or group names on different systems.

SYS.1.3.A3 No Automatic Mounting of Removable Drives (B)

Removable media such as USB sticks or CDs/DVDs MUST NOT be mounted automatically.

SYS.1.3.A4 Protection Against Exploitation of Vulnerabilities in Applications (B)

To make exploitation of vulnerabilities in applications more difficult, ASLR and DEP/NX MUST be activated in the kernel and used by applications. Security functions of the kernel and standard libraries, such as heap and stack protection, MUST NOT be deactivated.

SYS.1.3.A5 Secure Installation of Software Packages (B)

If software to be installed is to be compiled from source code, it MUST ONLY be unpacked, configured, and translated under an unprivileged account. Subsequently, the software to be installed MUST NOT be installed without control into the root file system of the operating system.

If the software is compiled from source, the selected parameters SHOULD be appropriately documented. Based on this documentation, the software SHOULD be compilable traceably and reproducibly at any time. All further installation steps SHOULD also be documented.

Standard Requirements

Together with the basic requirements, the following requirements reflect the state of the art for this building block. They SHOULD generally be fulfilled.

SYS.1.3.A6 Management of Users and Groups (S)

Appropriate management tools SHOULD be used to manage users and groups. Direct editing of the configuration files /etc/passwd, /etc/shadow, /etc/group, and /etc/sudoers SHOULD be avoided.

SYS.1.3.A7 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.3.A8 Encrypted Access via Secure Shell (S)

To establish an encrypted and authenticated, interactive connection between two IT systems, ONLY Secure Shell (SSH) SHOULD be used. All other protocols whose functionality is covered by Secure Shell SHOULD be completely disabled. For authentication, certificates SHOULD be preferred over passwords.

SYS.1.3.A9 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.3.A10 Prevention of Propagation When Exploiting Vulnerabilities (S)

Services and applications SHOULD be protected with an individual security architecture (e.g., with AppArmor or SELinux). Chroot environments as well as LXC or Docker containers SHOULD also be taken into account. It SHOULD be ensured that included standard profiles or rules are activated.

SYS.1.3.A11 DISCONTINUED (S)

This requirement has been discontinued.

SYS.1.3.A12 DISCONTINUED (S)

This requirement has been discontinued.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the protection level corresponding to the state of the art. The proposals SHOULD be considered in the case of high protection needs. The specific determination is made within the framework of an individual risk analysis.

SYS.1.3.A13 DISCONTINUED (H)

This requirement has been discontinued.

SYS.1.3.A14 Prevention of Spying on Information About the System and Users (H)

The output of information about the operating system and access to log and configuration files SHOULD be restricted for users to the necessary extent. Furthermore, no confidential information SHOULD be passed as parameters in command calls.

SYS.1.3.A15 DISCONTINUED (H)

This requirement has been discontinued.

SYS.1.3.A16 Additional Prevention of Propagation When Exploiting Vulnerabilities (H)

The use of system calls SHOULD be restricted — especially for exposed services and applications — to the absolutely necessary number. The standard profiles or rules of e.g., SELinux, AppArmor SHOULD be manually reviewed and, if necessary, adapted to the institution’s own security policies. If required, new rules or profiles SHOULD be created.

SYS.1.3.A17 Additional Kernel Protection (H)

Specially hardened kernels (e.g., grsecurity, PaX) and appropriate protective measures such as memory protection or file system hardening SHOULD be implemented to prevent exploitation of vulnerabilities and propagation within the operating system.

Additional Information

Good to Know

The National Institute of Standards and Technology (NIST) provides the document “Guide to General Server Security: NIST Special Publication 800-123”, July 2008.