Skip to content
This repository was archived by the owner on Aug 24, 2020. It is now read-only.

Latest commit

 

History

History
1396 lines (1060 loc) · 46.5 KB

linux.(02)basic-hardening.adoc

File metadata and controls

1396 lines (1060 loc) · 46.5 KB

Telekom Security Compliance Framework

Table of Contents

Linux OS for Servers - 2. Basic Hardening

Req 1: Unused services and protocols must be deactivated.

After installation of systems and software products local or remote reachable services and protocols may be active, which are not necessarily needed for operation and functionality of the system. These include also services and protocols which may not be used in Deutsche Telekom Group networks due to known security vulnerabilities. Such services and protocols must be completely disabled on the system. Additionally, it is important that protocols and service are still deactivated after system re-boot.

This kind of system hardening must be done before the system is reachable from the network. Otherwise an attacker has the possibility to attack and maybe compromise the unsecured system.

Motivation: Services and protocols that are not Required for system operation increase the potential attack sur-face and thus the risk of the system being compromised. This risk is further increased by the fact that a security inspection and appropriate optimization of the configuration for unused services and protocols is not being done in most cases.

Compliance Check (all)

The output of the following commands must be checked for unwanted services:

TCP (IPv4 & v6):

   # ss -nlt 2>/dev/null | awk '(#1 == "LISTEN" && #4 !~ /127.0.0.*.:./ && #4 !~ /::*.:./) {print #4}' | sed 's/.*://' | sort -nu

UDP (IPv4 & v6):

   # ss -nlu 2>/dev/null | awk '(#1 == "UNCONN" && #4 !~ /127.0.0.*.:./ && #4 !~ /::*.:./) {print #4}' | sed 's/.*://' | sort -nu

Compare the results with your communication matrix to identify open and not needed TCP and UDP ports.

Implementation (Ubuntu 14.04)

Use the following command to disable services permanently:

   # update-rc.d -f <service-name> remove

   Example: update-rc.d -f rsync remove

This takes only effect after a reboot. To stop services immediately use:

   # service <service-name> stop

Implementation (Ubuntu > 14.04, RedHat, Suse)

Use the following command to disable services permanently:

   # systemctl disable <service-name>

   Example: systemctl disable rsync    (or 'rsyncd' for RedHad based Linux)

This takes only effect after a reboot. To stop services immediately use:

   # service <service-name> stop
ℹ️
 Services should be uninstalled (see Req 3) if permanently not needed on a system.

Req 2: The reachability of services must be restricted.

The available services of a server are enabled without any restrictions for network reachability by default on all available network interfaces. In most cases it is not needed that such services are remotely reachable for anyone. To limit the attack surface services must be bound only to the network interfaces where they are needed.

Some services of a system, like management services, have only a limited and clearly defined set of needed communication partners. The reachability of such services must be restricted to IP addresses of legitimated communication partners. To limit the reachability a local firewall solution must be used in case no external solution to control the reachability (e.g. dedicated firewall, OpenStack secu-rity groups) in front of the system is available. Examples for local firewall solutions are:

  • iptables (see IPTables for more details)

  • nftables

Motivation: Disabling services on network interfaces and the implementation of filters to limit the reachability can reduce the potential attack possibilities.

Compliance Check (all)

Use the following commands to check if reachability of services are restricted with IPTables were needed:

   # sudo iptables -L

Expected output: command shows a table of all IPTables rules.

Implementation (all)

See req-50 (IPTables) how to configure IPTables rules for listening services.

Req 3: Unused software must not be installed or must be uninstalled.

Software could be installed during setup of Linux operating system which is not needed for the functionality of the server. Such software should not be installed or must be uninstalled after installation. Examples for software that is typically not needed on a server system are:

  • inetd

  • xinetd

  • X Window System

  • Avahi Server

  • CUPS

  • rsync service

  • NIS server/client

  • talk server/client

  • telnet server/client

  • tftp server/client

  • ftp server/client

  • rsh server/client

ℹ️
 It is not allowed to install software on a server that is not needed for operation, maintenance or general functionality!

Motivation: Vulnerabilities in software offer an attack window for attackers to infiltrate the system. By uninstalling not needed software the attack surface and the risk of a successful compromise can be reduced.

Compliance Check (Ubuntu)

Use the following commands to search for an installed software:

   # dpkg -l | grep <package-name>
   Alternative use: # apt list --installed | grep <package-name>

Expected output: 'none'

Compliance Check (RedHat, Suse)

Use the following commands to search for an installed software:

   # rpm -qa | grep <package-name>

Expected output: 'none'

Implementation (Ubuntu)

Use the following command to uninstall a software package:

   # apt purge <package-name>

Implementation (RedHat)

Use the following command to uninstall a software package:

  # yum remove <package-name>

Implementation (Suse)

Use the following command to uninstall a software package:

   # zypper remove <package-name>

Req 4: Unused filesystems must be disabled.

Linux supports a lot of filesystem types. Most of them are not needed on a server and must be disabled. Examples for filesystem types that are should not used on servers are:

  • cramfs

  • freevxfs

  • jffs2

  • hfs

  • hfsplus

  • squashfs

  • udf

  • vfat

Motivation: The availability of unneeded filesystem types increases the local attack surface of a server.

Compliance Check (all)

Use the following commands to search for running kernel modules:

  # modprobe -n -v <filesystem>

Eexpected output: 'install /bin/true'

  # lsmod | grep <filesystem>

Expected output: 'none'

Implementation (all)

Generate the file '/etc/modprobe.d/disable.conf' and add the following line for any module that should not be loadable:

   install <filesystem> /bin/true

Use the following command to unload running kernel modules:

   # rmmod <filesystem>

Req 5: Dedicated partitions must be used for growing content that can influence the availability of the system.

An own partition must be created for directories that are used to store dynamic content. It is recommended to use a dedicated partition for the directories:

  • /tmp

  • /var

In specific cases it could be necessary to use the following partitions:

  • /var/log and /var/tmp (instead of /var)

  • /home (for file servers with high number of users)

Motivation: A filled filesystem can stop operation of a server. This can be triggered by an attacker to effect avail-ability of a server.

Compliance Check (all)

Use the following command to search for partitions:

   # mount | grep <partition>

Implementation (all)

ℹ️
 Partitions should be generated during the installation of Linux operating system!

Req 6: Parameters nodev, nosuid and noexec must be set for partitions where this is applicable.

The named mount options must be set for the following partitions if they exist:

  • /tmp (nodev, nosuid)

  • /var/tmp (nodev, nosuid, noexec)

  • /home (nodev)

ℹ️
 For installation reasons it could be necessary to remove 'noexec' from partition '/tmp' as this is used sometimes for script execution during software installation.

If separate partition exists also for:

  • /dev/shm (RHEL, SLES) (nodev, nosuid, noexec)

  • /run/shm (Ubuntu) (nodev, nosuid, noexec)

Motivation: It must be avoided for such partitions that an attacker can execute files with suid, to store device files and to save and execute files from this partition.

Compliance Check (all)

Use the following command to search for partition in file '/etc/fstab':

   # grep -i <partition> /etc/fstab

Expected output (example): /dev/sda3 /tmp ext4 (default,nosuid,nodev)

Implementation (all)

Add the correct values to the entry of the partition in the file '/etc/fstab':

  Example:
  # <device>        <dir>        <type>        <options>
  /dev/sda3         /tmp         ext4          (default,nosuid,nodev)

Req 7: Automounting must be disabled.

Automounting of file systems must be disabled to avoid the automated mounting and use of external file systems like USB sticks and CD-ROMs.

Motivation: With automounting enabled any external file system will be mounted to the server and can possibly misused.

Compliance Check (Ubuntu 14.04)

Use the following command to check if autofs is enabled:

   # initctl show-config autofs

Expected output: only 'autofs' and no start conditions must be shown

Compliance Check (Ubuntu > 14.04, RedHat, Suse)

Use the following command to check if autofs is enabled:

   # systemctl is-enabled autofs

Expected output: 'disabled'

Implementation (Ubuntu 14.04)

Comment out or remove all start lines in file '/etc/init/autofs.conf':

   #start on runlevel [2345]

Implementation (Ubuntu > 14.04, RedHat, Suse)

Use the following command to disable autofs:

   # systemctl disable autofs

Req 8: The use of at/cron must be restricted to authorized users.

The use of the tools 'cron' and 'at', that can be used to schedule automated execution of jobs on a Linux system, must be restricted to authorized users.

Motivation: Users can misuse these tools to execute jobs on a system.

Compliance Check (all)

Check if the following files exists:

   # stat /etc/cron.deny
   # stat /etc/at.deny

Expected output:
stat: cannot stat `/etc/<file>.deny': No such file or directory

   # stat /etc/cron.allow
   # stat /etc/at.allow

Expected output:
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)

Implementation (all)

If exist delete the following files:

   # rm /etc/cron.deny
   # rm /etc/at.deny

Generate the following files, change permissions and add them to root user and group:

   # touch /etc/cron.allow
   # chmod og-rwx /etc/cron.allow
   # chown root:root /etc/cron.allow

   # touch /etc/at.allow
   # chmod og-rwx /etc/at.allow
   # chown root:root /etc/at.allow

Req 9: Sticky bit must be set on all world-writable directories.

This feature prevents the ability to delete or rename files in world writable directories (such as /tmp) that are owned by another user.

Motivation: Setting the sticky bit on world writable directories prevents users from deleting or renaming files in that directory that are not owned by them.

Compliance Check (all)

Use the following command to find world-writable directories:

   # df --local -P | awk {'if (NR!=1) print $6'} | xargs -I '{}' find '{}' -xdev -type d -perm -0002 \! -perm -1000

Implementation (all)

Use the following command to set the sticky bit on world-writable directories:

   # chmod o+t <world-writable-directory>

Req 10: No regular files that are world writable must exist.

World writable files are files that have write permission set for other. These files are writable by any user of the server. Such files must be detected and if existing the rights of these files must be changed to an adequate level.

Motivation: Data in world-writable files can be read, modified, and potentially compromised by any user on the system.

Compliance Check (all)

Use the following command to find world-writable files:

   # df --local -P | awk {'if (NR!=1) print $6'} | xargs -I '{}' find '{}' -xdev -type f -perm -0002

Implementation (all)

Use the following command to set correct permission to files:

   # chmod o-w <world-writable-file>

Req 11: Passwords must be protected with an appropriate hashing function.

Passwords must always be stored as hashes. Sha512-crypt with 640.000 rounds and Salt (96 Bit) must be used as a hashing algorithm to protect passwords.

Motivation: It an unauthorized person gets access to a password file, the password can be misused if not stored in a secure way.

Compliance Check (all)

Check the file '/etc/login.defs' for the correct entries for password encryption (sha-512) and max/min rounds (640.000):

   # grep -i "^ENCRYPT_METHOD" /etc/login.defs

Expected output: 'ENCRYPT_METHOD SHA512'

   # grep -i "^SHA_CRYPT_MIN_ROUNDS" /etc/login.defs
   # grep -i "^SHA_CRYPT_MAX_ROUNDS" /etc/login.defs

Expected output: 'SHA_CRYPT_MAX_ROUNDS 640000' and 'SHA_CRYPT_MIN_ROUNDS 640000'

Implementation (all)

Add or change the following entries in the file '/etc/login.defs':

   ENCRYPT_METHOD SHA512
   SHA_CRYPT_MIN_ROUNDS 640000
   SHA_CRYPT_MAX_ROUNDS 640000

Req 12: The default user umask must be 027 or more restrictive.

The setting of the umask defines which mode files or directories get when they are created by a user. The default umask on most Linux systems is less strict. This is the reason why a stricter umask must be configured.

A umask of 027 is recommended. This defines the permissions 'read, write, execute' (0) for the user, 'read, execute' (2) for group and no permissions (7) for others.

Motivation: With a strict umask the manipulation of files by unauthorized users can be prevented.

Compliance Check (all)

Check the file '/etc/login.defs' for correct umask:

   # grep -i "^UMASK" /etc/login.defs

Expected output: 'UMASK 027'

Implementation (Ubuntu LTS 14.04/16.04/18.04, RHEL 7.x/CentOS 7.x, SLES 15)

Add or change the following entry in the file '/etc/login.defs':

   UMASK 027

Req 13: Not needed SUID and SGID bits must be removed from executables.

Executables with SUID or SGID bits set run with extensive rights. Such executables pose a security risk. Therefore, executables with SUID and SGID bit set must be limited to the absolutly needed ones. From all others, the SUID and SGID bits must be removed. An alternative is to grant more granular permission for such commands with Posix capabilities. This solution allows to enable only needed system functions for a binary file and not full root privileges as with SUID/SGID. It is highly recommended where even possible to use Posix capabilities instead of SUID/SGID!

The following executables are allowed to run with SUID and SGID if not Posix capabilities can be used:

  • /bin/ping

  • /sbin/pam_timestamp_check

  • /sbin/unix_chkpwd

  • /usr/bin/at

  • /usr/bin/gpasswd

  • /usr/bin/locate

  • /usr/bin/newgrp

  • /usr/bin/passwd

  • /usr/bin/ssh-agent

  • /usr/libexec/utempter/utempter

  • /usr/sbin/lockdev

  • /usr/sbin/sendmail.sendmail

  • /usr/bin/expiry

  • /bin/ping6

  • /usr/bin/traceroute6.iputils

  • /sbin/mount.nfs

  • /sbin/umount.nfs

  • /sbin/mount.nfs4

  • /sbin/umount.nfs4

  • /usr/bin/crontab

  • /usr/bin/wall

  • /usr/bin/write

  • /usr/bin/screen

  • /usr/bin/mlocate

  • /usr/bin/chage

  • /usr/bin/chfn

  • /usr/bin/chsh

  • /bin/fusermount

  • /usr/bin/pkexec

  • /usr/bin/sudo

  • /usr/bin/sudoedit

  • /usr/sbin/postdrop

  • /usr/sbin/postqueue

  • /usr/sbin/suexec

  • /usr/sbin/ccreds_validate

  • /usr/lib/dbus-1.0/dbus-daemon-launch-helper

  • /usr/lib/policykit-1/polkit-agent-helper-1

Motivation: Executables with SUID and SGID are a high risk for a system. If such an executable has a vulnerability it could possibly lead to compromise of the system.

Compliance Check (all)

Use the following command to find files with SUID or SGID:

   # df --local -P | awk {'if (NR!=1) print $6'} | xargs -I '{}' find '{}' -xdev -type f \( -perm -4000 -o -perm -2000 \) -print 2

Implementation (all)

Use the following command to set correct permission to files:

   chmod a-s <file>
ℹ️
 See requirement for whitelist of files were SUID/SGID is allowed!

Req 14: Core dumps must be disabled.

A core dump includes complete memory content of an executable program. It is used to debug pro-gram crashes. Core dumps should be disabled during normal operation and only be enabled in case of debugging. On systems where core dumps are needed it is recommended to disable core dumps for setuid processes.

Motivation: Core dumps can include some sensitive data. To avoid information leakage core dumps must be restricted.

Compliance Check (all)

Check all files in directory '/etc/security/limits.d/':

   # grep -i "soft core 0" /etc/security/limits.d/*
   # grep -i "hard core 0" /etc/security/limits.d/*

Expected output: '* soft core 0' and '* hard core 0'

Use the following commands to check the kernel parameter:

   # sysctl fs.suid_dumpable
   # grep "fs.suid_dumpable" /etc/sysctl.conf /etc/sysctl.d/*

Expected output for both commands: 'fs.suid_dumpable = 0'

Implementation (all)

If not exist create a file (e.g. '10.hardcore.conf') in the directory '/etc/security/limits.d/'. Add the following entries to this file:

   * soft core 0
   * hard core 0

Set the following parameter in the file '/etc/sysctl.conf':

   fs.suid_dumpable = 0

Use the following command to set the kernel parameter:

   # sysctl -w fs.suid_dumpable=0

Req 15: Protection against buffer overflows must be enabled.

A protection function against buffer overflow attacks must be used on Linux servers. The following solutions are available:

  • ASLR (Debian based Linux like Ubuntu)

  • Exec Shield (RedHat based Linux. Per default activated in RHEL 7) * NoExecute (NX)/ eXecute Disable (XD) must be activated in system bios for the functionality of buffer overflow protection solutions.

ℹ️
 ASLR has some weaknesses. For servers with a high security demand it is recommended to use Exec Shield as buffer overflow protection solution.

Motivation: Buffer overflow attacks can be used to unauthorizedly execute code on a system to influence availability or to get full access to a system.

Compliance Check (all)

First must be checked if NoExecute (NX)/ eXecute Disable (XD) is activated in system bios with the following command:

   # dmesg | awk -F' ' '{if ($3 == "NX") print $7}'

Expected output: 'active'

Use the following command to check if buffer overflow protection is configured and activated in running kernel:

   # sysctl kernel.randomize_va_space
   # grep "kernel.randomize_va_space" /etc/sysctl.conf /etc/sysctl.d/*

Expected output for both commands: kernel.randomize_va_space = 2

Implementation (all)

Set the following parameter in the file '/etc/sysctl.conf':

   kernel.randomize_va_space = 2

Use the following command to set the kernel parameter:

   # sysctl -w kernel.randomize_va_space=2

Req 16: Prelink must not be used.

Prelink is a tool to modify ELF shared libraries and ELF dynamically linked binaries. This tool must be disabled on Linux based servers.

Motivation: Prelink must be disabled to use the ASLR feature PIE (Position- independent executable). Additionally, prelink increases the risk of a compromise to a common library such as libc.

Compliance Check (RedHat, Suse)

ℹ️
 From RedHat 7 (and Linux distribution based on RedHat 7) and Suse 15 prelink is deprecated and no longer part of the distributions.

Compliance Check (Ubuntu)

Check if prelink is installed with the following command:

   # dpkg -l | grep -io "prelink"

Expected output: 'prelink'

Implementation (Ubuntu)

If prelink is installed uninstall it with the following command:

   # apt purge prelink

2.1 Network Hardening

Req 17: IPv4 protocol stack must be securely configured.

If IPv4 is not used it must be completely disabled. Otherwise, the IPv4 stack on Linux servers must be hardened. For this the following configuration must be implemented:

  • IPv4 forwarding must be disabled.

  • IPv4 redirects must not be accepted.

  • Secure IPv4 redirects must not be accepted.

  • IPv4 packet redirect sending must be disabled.

  • IPv4 source routed packets must not be accepted.

  • Suspicious packets must be logged.

  • Broadcast ICMP Requests must be ignored.

  • Bogus ICMP responses must be ignored.

  • Reverse Path Filtering must be enabled.

  • TCP SYN Cookies must be enabled.

  • An ICMP ratelimit must be configured.

  • Timestamp must be disabled.

  • ARP must be restricted.

Motivation: An unhardened IPv4 protocol stack is vulnerable against several attacks like denial of service, traffic high jacking.

Compliance Check (all)

Use the following commands to verify the running configuration:

   # sysctl <ipv4-setting>
   # grep "<ipv4-setting>" /etc/sysctl.conf /etc/sysctl.d/*

Expected output for both commands: <ipv4-setting> = <value>

Use the following IPv4 settings and corresponding values:

IPv4 forwarding must be disabled:

  • net.ipv4.ip_forward = 0

IPv4 redirects must not be accepted:

  • net.ipv4.conf.all.accept_redirects = 0

  • net.ipv4.conf.default.accept_redirects = 0

Secure IPv4 redirects must not be accepted:

  • net.ipv4.conf.all.secure_redirects = 1

  • net.ipv4.conf.default.secure_redirects = 1

IPv4 packet redirect sending must be disabled:

  • net.ipv4.conf.all.send_redirects = 0

  • net.ipv4.conf.default.send_redirects = 0

IPv4 source routed packets must not be accepted:

  • net.ipv4.conf.all.accept_source_route = 0

  • net.ipv4.conf.default.accept_source_route = 0

Suspicious packets must be logged:

  • net.ipv4.conf.all.log_martians = 1

  • net.ipv4.conf.default.log_martians = 1

Broadcast ICMP Requests must be ignored:

  • net.ipv4.icmp_echo_ignore_broadcasts = 1

Bogus ICMP responses must be ignored:

  • net.ipv4.icmp_ignore_bogus_error_responses = 1

Reverse Path Filtering must be enabled:

  • net.ipv4.conf.all.rp_filter = 1

  • net.ipv4.conf.default.rp_filter = 1

TCP SYN Cookies must be enabled:

  • net.ipv4.tcp_syncookies = 1

An ICMP ratelimit must be configured:

  • nett.ipv4.icmp_ratelimit = 100

  • net.ipv4.icmp_ratemask = 88089

Timestamp must be disabled:

  • net.ipv4.tcp_timestamps = 0

ARP must be restricted:

  • net.ipv4.conf.all.arp_ignore = 2

  • net.ipv4.conf.all.arp_announce = 2

  • net.ipv4.conf.all.arp_notify = 0

  • net.ipv4.conf.all.arp_accept = 0

Implementation (all)

First add the above listed IPv4 settings and values with in the file '/etc/sysctl.conf'. Than use the following command to set these for IPv4 settings for the running system:

   # sysctl -w <ipv4-setting>=<value>

Req 18: IPv6 protocol stack must be securely configured.

If IPv6 is not used it must be completely disabled. Otherwise, the IPv6 stack on Linux servers must be hardened. For this the following configuration must be implemented:

  • IPv6 forwarding must be disabled.

  • IPv6 redirects must not be accepted.

  • IPv6 source routed packets must not be accepted.

  • IPv6 router advertisements must not be accepted.

  • IPv6 router solicitations messages must not be accepted.

  • IPv6 autoconfiguration must be disabled.

Motivation: An un-hardened IPv6 protocol stack is vulnerable against several attacks like denial of service, traffic high jacking.

Compliance Check (all)

Use the following commands to verify the running configuration:

   # sysctl <ipv6-setting>
   # grep "<ipv6-setting>" /etc/sysctl.conf /etc/sysctl.d/*

Expected output for both commands: <ipv6-setting> = <value>

Use the following IPv6 settings and corresponding values:

If IPv6 is not used it must be completely disabled with:

  • net.ipv6.conf.all.disable_ipv6: 1

  • net.ipv6.conf.default.disable_ipv6: 1

If IPv6 is used enable it and set the following parameters:

  • net.ipv6.conf.all.disable_ipv6: 0

  • net.ipv6.conf.default.disable_ipv6: 0

IPv6 forwarding must be disabled:

  • net.ipv6.conf.all.forwarding: 0

  • net.ipv6.conf.default.forwarding: 0

IPv6 redirects must not be accepted:

  • net.ipv6.conf.all.accept_redirects: 0

  • net.ipv6.conf.default.accept_redirects: 0

IPv6 source routed packets must not be accepted:

  • net.ipv6.conf.all.accept_source_route: 0

  • net.ipv6.conf.default.accept_source_route: 0

IPv6 router advertisements must not be accepted:

  • net.ipv6.conf.all.accept_ra: 0

  • net.ipv6.conf.default.accept_ra: 0

  • net.ipv6.conf.all.accept_ra_rtr_pref: 0

  • net.ipv6.conf.default.accept_ra_rtr_pref: 0

  • net.ipv6.conf.all.accept_ra_pinfo: 0

  • net.ipv6.conf.default.accept_ra_pinfo: 0

  • net.ipv6.conf.all.accept_ra_defrtr: 0

  • net.ipv6.conf.default.accept_ra_defrtr: 0

IPv6 router solicitations messages must not be accepted:

  • net.ipv6.conf.all.router_solicitations: 0

  • net.ipv6.conf.default.router_solicitations: 0

  • net.ipv6.conf.all.dad_transmits: 0

  • net.ipv6.conf.default.dad_transmits: 0

IPv6 autoconfiguration must be disabled:

  • net.ipv6.conf.all.autoconf: 0

  • net.ipv6.conf.default.autoconf: 0

Implementation (all)

First add the above listed IPv6 settings and values with in the file '/etc/sysctl.conf'. Than use the following command to set these for IPv4 settings for the running system:

   # sysctl -w <ipv6-setting>=<value>

2.2 System Update

Req 19: Emerged vulnerabilities in software and hardware of a system must be fixed or protected against misuse.

The administrator must check before the installation of software on a server if vulnerabilities are known for the selected version. Software with known vulnerabilities must not be used. Excepted from this rule are components for which the vendor has already provided a measure to remedy the vulner-ability, e.g. a patch, update or workaround. In this case, the additional measure must be implement-ed on the server.

ℹ️
 It is mandatory to implement a patch management process covering the complete life cycle of the server to guarantee that upcoming vulnerabilities will be fixed as soon as possible.

Motivation: Vulnerabilities increases the risk of successful exploitation by an attacker. The likelihood raises if de-tailed information and tools are available that help to exploit the vulnerability.

Compliance Check (Ubuntu)

Use the following commands to first update the repository and second show all available upgrades:

   # apt update
   # apt list --upgradable

Compliance Check (RedHat)

Use the following command to search for available updates:

   # yum check-update

Compliance Check (Suse)

Use the following commands to first update the repository and second show all available upgrades:

   # zypper refresh -s
   # zypper list-updates

Implementation (Ubuntu)

Use the following command to update the operating system:

   # apt upgrade

Implementation (RedHat)

Use the following command to update the operating system:

   # yum update

Implementation (Suse)

Use the following command to update the operating system:

   # zypper update

Req 20: GPG check for repository server must be activated and corresponding keys for trustable repositories must be configured.

GPG check must be enabled and keys must be configured properly to verify integrity during installation of software from a repository server. On RedHat Linux it is necessary to activate the gpgcheck globally.

Motivation: The GPG check is necessary to guarantee the authenticity of used source an integrity of software. Without this check an attacker could possibly manipulate software packets before installation.

Compliance Check (Ubuntu)

Use the following command to check if the correct repositories are configured. This is especially important if internal own operated repository servers are used.

   # apt-cache policy

Check that the file 'sources.list' not include the parameter '[trusted=yes] '. This will disable the GPG check for repositories and must not be used:

grep "trusted=yes" /etc/apt/sources.list

If compliant the command gives nothing back.

Use the following commands to check the GPG key configuration:

   # apt-key list

Expected output (example):
/etc/apt/trusted.gpg
--------------------
pub 1024D/437D05B5 2004-09-12
uid Ubuntu Archive Automatic Signing Key

Compliance Check (RedHat)

Use the following command to check if the correct repositories are configured. This is especially important if internal own operated satellite servers are used.

   # yum repolist

Use the following command to check if GPG check is enabled:

   # awk -F\= '/^gpgcheck=/ {print $2}' /etc/yum.conf

Expected output: '1'

Use the following commands to check the GPG key configuration:

   # yum repolist enabled
   # rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'

Expected output (example):
gpg-pubkey-fd431d51-4ae0493b -→ gpg(Red Hat, Inc. (release key 2)
gpg-pubkey-2fa658e0-45700c69 -→ gpg(Red Hat, Inc. (auxiliary key)

Compliance Check (Suse)

Use the following command to check if the correct repositories are configured. This is especially important if internal own operated repository servers are used.

   # zypper repos

Use the following command to check if GPG check is enabled:

   # awk -F\= '/^gpgcheck=/ {print $2}' /etc/zypp/zypp.conf

Expected output: '1' or none

Use the following commands to check the GPG key configuration:

   # zypper repos -E
   # rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'

Expected output (example):
gpg-pubkey-307e3d54-5aaa90a5 -→ gpg(SuSE Package Signing Key)
gpg-pubkey-39db7c82-5847eb1f -→ gpg(SuSE Package Signing Key)

Implementation (Ubuntu)

Use the following command to add or update GPG keys:

   # apt-key add <key-file>
   # apt-key update

Implementation (RedHat, Suse)

Use the following command to add GPG keys:

   # rpm --import /path/<key-file>

2.3 User Authentication

Req 21: User accounts must be used that allow unambiguous identification of the user.

Users must be identified unambiguously by the system. This can typically be achieved by using a unique user account per user. So, called group accounts, i.e. the use of one user account for several persons, must not be created and used for this purpose. This also means that the use of specific Linux accounts like 'root' by humans is not allowed.

One exception of this Requirement is machine (or M2M) accounts. These will be used for authentication and authorization of systems to each other or for applications on a system. They can’t be as-signed to a single person. Such user accounts must be assigned on a per system or per application basis. In this connection, it must be guaranteed that this user account can’t be misused.

Motivation: Unambiguous user identification is mandatory to assign user rights that are necessary to perform the Required tasks on the system. This is the only way to adequately control access to system data and services and to prevent misuse. Furthermore, it makes it possible to log activities and actions on a system and to assign them to individual users.

Compliance Check (Ubuntu)

Use the following command to search for not needed and prohibited user accounts on the system:

   # awk -F':' '{ if ( $3 >= 1000 && $7 != "/usr/sbin/nologin" ) print $1 }' /etc/passwd

Compliance Check (RedHat, Suse)

Use the following command to search for not needed and prohibited user accounts on the system:

   # awk -F':' '{ if ( $3 >= 1000 && $7 != "/sbin/nologin" ) print $1 }' /etc/passwd

Implementation (all)

ℹ️
 Make sure that you have an approved authentication concept that describes and guarantees how to administrate individual user accounts. Delete all group account that violate this requirement (# userdel <user>)!

Req 22: System accounts must be non-login.

On Linux servers, several users are available that are needed for functionality of applications. These users are not intended to provide a shell. To avoid that such accounts are used to login the shell pa-rameter in file '/etc/passwd' must be set to '/usr/sbin/nologin' or '/bin/false'.

ℹ️
 The system accounts root, sync, shutdown and halt are excluded from this requirement!

Motivation: Accounts that are needed only for local functionality can be used to get unauthorized access to the system if not protected in a proper way.

Compliance Check (all)

Use the following command to search for system accounts with login option:

   # awk -F':' '($1!="root" && $1!="sync" && $1!="shutdown" && $1!="halt" && $3<1000 && $7=="/bin/bash") {print $1}' /etc/passwd

Expected output: none (if system accounts are configured correct)

Implementation (Ubuntu)

Use the following command to set system accounts to no-login:

   # usermod -s /usr/sbin/nologin <system-account>

Implementation (RedHat, Suse)

Use the following command to set system accounts to no-login:

   # usermod -s /sbin/nologin <system-account>

Req 23: User accounts must be protected against unauthorized usage by at least one authentication attribute.

The various user and machine accounts on a system must be protected from misuse. To this end, an authentication attribute is typically used, which, when combined with the user name, enables unam-biguous authentication and identification of the authorized user.

Authentication attributes include:

  • Cryptographic keys

  • Token

  • Passwords

  • PINs

This means that authentication based on a parameter that can be spoofed (e.g. phone numbers, public IP addresses or VPN membership) is not permitted. Exceptions are attributes that cannot be faked or spoofed by an attacker. Two of the above options can be combined (2-factor authentication) to achieve a higher level of security. Whether or not this is suitable and necessary depends on the protection needs of the individual system and its data and must be evaluated for individual cases.

In companies of Deutsche Telekom group where the MyCard or a comparable smartcard is available this solution should be preferred.

Motivation: User accounts that are not protected with a secret authentication attribute can be used by an attacker to gain unauthorized access to a system and the data and applications stored on it.

Compliance Check (all)

   # awk -F":" '($2 == "" && $2 != "!" && $2 !="*") {print $1}' /etc/shadow

Expected output: none (or only users that use alternatively 2-factor authentication like public-key authentication + passphrase (see req 24)).

Implementation (all)

If you have identified user accounts with adequate protection you can lock the account using the following command:

   # passwd -l <user-account>

Req 24: User accounts with extensive rights must be protected with two authentication attributes.

Some user accounts, for example those used for administration, maintenance and troubleshooting, have extensive rights. Extensive rights mean that with an appropriate user account changes like writ-ing, reading etc. to system parameters and configurations are possible. Therefore, a simple protec-tion (e.g. using a password), as for normal user accounts with less rights, is not suitable. To get a higher protection level it is necessary to use two independent authentication attributes. For this a combination of an attribute that the user knows and an attribute that the user owns will often be used often. This kind of authentication is called as 2-factor authentication. Examples for 2-factor authentication are:

  • Smartcard (e.g. MyCard) protected by a PIN

  • Private key protected by a passphrase

  • Password plus additional one-time token

In companies of Deutsche Telekom group where the MyCard or a comparable smartcard is available this solution should be preferred.

Motivation: User accounts with extensive rights as used for system administration have a higher risk for system’s security. An attacker could get extensive rights by compromising such a user account and get access to wide parts of the system and stored data.

Compliance Check & Implementation (all)

ℹ️
 The implementation of this requirement depends on the used 2-factor authentication and service that should be protected. This is very often SSH with public key authentication. For more details how to configure 2-factor authentication for SSH see Security Requirement Document 3.04 "SSH").

Req 25: The system must be connected to a central system for user administration.

Systems must be connected to a central system for user administration. A solution for identity management should be preferred. Accounts and their rights must be administrated on central identity management systems (e.g. cIAM, WiW, ZAM) in Deutsche Telekom Group. The system must provide a central interface (e.g. LDAPs or authorization, Kerberos for authentication, revocation information for certificates) or decentralized mechanisms (e.g. public-key authentication) for the provisioning of authorization data. In areas where a central identity management system is not available a central system such as LDAP, TACACS+ or Radius server must be used for the administration of accounts and their authentication and authorization.

Exceptions to this Requirement are accounts that are used only internally by the system involved and that are Required for one or more applications on the system to function. Also, for those accounts remote access and local login must be forbidden to prevent abusive usage.

Motivation: Central administration of identity of accounts and their rights means that they only have to be maintained once instead of separately on each system. Regarding the aspect of security, the advantage is that a user account and its rights are only known on a single central site. This information can be transmitted from the central site to other systems (provisioning), central administrated (reconciliation) and central deleted (deprovisioning). This reduces the risk of accounts being forgotten during changing or deletion since they are not configured on multiple systems. Faulty account management could give user inappropriate system rights or continued access to a system e.g. after leaving the company or changing the responsibility.

Compliance Check & Implementation (all)

ℹ️
 Implementation depends on the used solution (e.g. LDAP, Kerberos). Examples are planed for further versions of this document.

Req 26: Authentication must be used for single user mode.

For system recovery, the so called single user mode is used. This mode can also be manually selected from the bootloader during system boot. Authentication must be enabled for single user mode to protect this access. This is especially relevant, if the console of the machine can be reached remotely (e.g. via lights-out-management or via virtual console in case of virtual machines).

Motivation: Without authentication, an unauthorized user can gain root privileges by forcing a reboot.

Compliance Check (Ubuntu)

On Ubuntu Linux the user 'root' is not used and has no password set. As a result login without any authentication after a reboot is possible. Use the following command to check if a password is configured for user 'root':

   # grep "^root:[*\!]:" /etc/shadow

If this command gives no output the user 'root' has no password set.

Compliance Check (RedHat, Suse)

Use the following commands to search for relevant entry in files:

   # grep "^ExecStart=" /usr/lib/systemd/system/rescue.service
   # grep "^ExecStart=" /usr/lib/systemd/system/emergency.service

Expected output: ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default"

Implementation (Ubuntu)

To activate single user mode on Ubuntu Linux a password must be set for this user.

ℹ️
 The password must be hold confidential as the user 'root' is not allowed to be used by employees to login. The user 'root' must only be used for emergency reasons!

Set a password for user 'root'

   # passwd root

Implementation (RedHat, Suse)

Add the following line to the files '/usr/lib/systemd/system/rescue.service' and '/usr/lib/systemd/system/emergency.service' to enable single user mode:

   ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default"'

2.4 System Management

Req 27: The management of the operating system must be done via a dedicated management network which is independent from the production network.

Management access to a server must be done via a separate management network. The access must be limited to legitimate systems. The reachability of the management services must be limited to single IP addresses or small IP address ranges of subnets.

Motivation: By restricting the accessibility to legitimate systems, the group of potential attackers can be reduced, and thus also the likeliness of a successful attack. Furthermore, systems must be manageable even in the case the customer or production network is down.

Compliance Check (Ubuntu)

Use the following command to check the interfaces and IP addresses:

   # ifconfig -a

Compliance Check (RedHat, Suse)

Use the following command to check the interfaces and IP addresses:

   # ip addr

Implementation (all)

Two physical or virtual (VLAN, VxLAN etc.) interfaces must be configured. One for the connection to management network and another one to production network.

Req 28: Management services must be bound to the management network.

The services used for server administration must be bound to an interface connected to a management network or an IP address of the management network.

Motivation: This Requirement ensures that management services are not reachable from untrusted networks and limits so the possibility of attacks.

Compliance Check (all)

This must be checked for all management services. Check open ports to find all services (tcp: ss -nlt; udp: ss -nlu). The following section gives only some examples for most common management services:

Example for OpenSSH:

   # grep "^ListenAddress" /etc/ssh/sshd_config

Expected output: ListenAddress <ip-address-of-mgmt-network>

Example for NTP:

   # grep "^interface listen" /etc/ntp.conf

Expected output: interface listen <ip-address-of-mgmt-network>

Example for Chrony:

   # grep "^bindaddress" /etc/chrony.conf

Expected output: bindaddress <ip-address-of-mgmt-network>

Example for rsyslog:

   # grep "^$UDPServerAddress" /etc/rsyslog.conf/

Expected output: $UDPServerAddress <ip-address-of-mgmt-network>

Implementation (all)

The services itself must be configured to use the correct interface intended for management reasons.

OpenSSH: add the following line to file '/etc/ssh/ssd_conf':

   ListenAddress <ip-address-of-mgmt-network>

NTP: add the following line to file '/etc/ntp.conf':

   interface listen <ip-address-of-mgmt-network>

Chrony: add the following line to file /etc/chrony.conf

   bindaddress <ip-address-of-mgmt-network

rsyslog: add the following line to file /etc/rsyslog.conf/

   $UDPServerAddress <ip-address-of-mgmt-network>

Req 29: Encrypted protocols must be used for management access to administrate the operating system.

The used services and protocols for system management and administration must be encrypted. Only services like SSHv2 and HTTPS (TLS) are allowed.

Motivation: Management connections and access must be protected against eavesdropping of sensitive data and unauthorized access.

Compliance Check & Implementation (all)

Use only encrypted protocols like the following for system Management:

  • SSH

  • SFTP

  • HTTPS

  • SYSLOG-NG

ℹ️
 As syslog-ng is not available on all operating systems as an exception standard syslog can be used.