Guide to the Secure Configuration of Oracle Linux 7

with profile Security Profile of Oracle Linux 7 for SAP
This profile contains rules for Oracle Linux 7 Operating System in compliance with SAP note 2069760 and SAP Security Baseline v1.9 Item I-8 and section 4.1.2.2. Regardless of your system's workload all of these checks should pass.
This guide presents a catalog of security-relevant configuration settings for Oracle Linux 7. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the config_item="scap-security-guide" package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a italics="catalog, not a checklist," and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF italics="Profiles", which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Oracle Linux 7, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile TitleSecurity Profile of Oracle Linux 7 for SAP
Profile IDxccdf_org.ssgproject.content_profile_sap

CPE Platforms

  • cpe:/o:oracle:linux:7

Revision History

Current version: 0.1.39

  • draft (as of 2018-07-15)

Table of Contents

  1. Services
    1. Obsolete Services
  2. System Settings
    1. File Permissions and Masks
    2. Installing and Maintaining Software

Checklist

Group   Guide to the Secure Configuration of Oracle Linux 7   Group contains 9 groups and 6 rules
Group   Services   Group contains 2 groups and 3 rules

[ref]   The best protection against vulnerable software is running less software. This section describes how to review the software which Oracle Linux 7 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Oracle Linux 7 system and provides guidance about which ones can be safely disabled.

Oracle Linux 7 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Oracle Linux 7 systems, it is highly recommended to select the minimal packages and then build up the system from there.

Group   Obsolete Services   Group contains 1 group and 3 rules

[ref]   This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of Red Hat Enterprise Linux 7 by default.

Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as firewalld to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.

Group   Rlogin, Rsh, and Rexec   Group contains 3 rules

[ref]   The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model.

Rule   Disable rlogin Service   [ref]

The rlogin service, which is available with the rsh-server package and runs as a service through xinetd or separately as a systemd socket, should be disabled. If using xinetd, set disable to yes in /etc/xinetd.d/rlogin. If using systemd, The rlogin socket can be disabled with the following command:

$ sudo systemctl disable rlogin.socket

Rationale:

The rlogin service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Severity: 
high
Identifiers and References

References:  2.2.17, 3.1.13, 3.4.7, CCI-001436, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-17(8), CM-7, IA-5(1)(c)

Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
- name: Disable service rlogin
  service:
    name="{{item}}"
    enabled="no"
    state="stopped"
  register: service_result
  failed_when: "service_result|failed and ('Could not find the requested service' not in service_result.msg)"
  with_items:
    - rlogin
  tags:
    - service_rlogin_disabled
    - high_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - NIST-800-53-AC-17(8)
    - NIST-800-53-CM-7
    - NIST-800-53-IA-5(1)(c)
    - NIST-800-171-3.1.13
    - NIST-800-171-3.4.7

Rule   Disable rsh Service   [ref]

The rsh service, which is available with the rsh-server package and runs as a service through xinetd or separately as a systemd socket, should be disabled. If using xinetd, set disable to yes in /etc/xinetd.d/rsh. If using systemd, The rsh socket can be disabled with the following command:

$ sudo systemctl disable rsh.socket

Rationale:

The rsh service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Severity: 
high
Identifiers and References

References:  2.2.17, 3.1.13, 3.4.7, CCI-000068, CCI-001436, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-17(8), CM-7, IA-5(1)(c)

Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
- name: Disable service rsh
  service:
    name="{{item}}"
    enabled="no"
    state="stopped"
  register: service_result
  failed_when: "service_result|failed and ('Could not find the requested service' not in service_result.msg)"
  with_items:
    - rsh
  tags:
    - service_rsh_disabled
    - high_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - NIST-800-53-AC-17(8)
    - NIST-800-53-CM-7
    - NIST-800-53-IA-5(1)(c)
    - NIST-800-171-3.1.13
    - NIST-800-171-3.4.7

Rule   Remove Rsh Trust Files   [ref]

The files /etc/hosts.equiv and ~/.rhosts (in each user's home directory) list remote hosts and users that are trusted by the local system when using the rshd daemon. To remove these files, run the following command to delete them from any location:

$ sudo rm /etc/hosts.equiv
$ rm ~/.rhosts

Rationale:

Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system.

Severity: 
high
Identifiers and References

References:  6.2.14, CCI-001436, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-17(8), CM-7

Group   System Settings   Group contains 5 groups and 3 rules

[ref]   Contains rules that check correct system settings.

Group   File Permissions and Masks   Group contains 2 groups and 1 rule

[ref]   Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access.

Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn.

The following command prints a list of all xfs partitions on the local system, which is the default filesystem for Red Hat Enterprise Linux 7 installations:

$ mount -t xfs | awk '{print $3}'
For any systems that use a different local filesystem type, modify this command as appropriate.

Group   Verify Permissions on Important Files and Directories   Group contains 1 group and 1 rule

[ref]   Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen.

Group   Verify Permissions on Files with Local Account Information and Credentials   Group contains 1 rule

Rule   Verify Permissions on shadow File   [ref]

To properly set the permissions of /etc/shadow, run the command:

$ sudo chmod 0000 /etc/shadow

Rationale:

The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity: 
medium
Identifiers and References

References:  6.1.3, 5.5.2.2, AC-6, Req-8.7.c

Group   Installing and Maintaining Software   Group contains 1 group and 2 rules

[ref]   The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

Group   SAP Specific Requirement   Group contains 2 rules

[ref]   SAP (Systems, Applications and Products in Data Processing) is enterprise software to manage business operations and customer relations. The following section contains SAP specific requirement that is not part of standard or common OS setting.

Rule   Package glibc Installed   [ref]

The package glibc is installed on Linux by default, but the glibc version might not be sufficient for SAP. Please refer to SAP note of your Linux version for the minimum requirement on glibc. Use the following command to install and/or update the package:

$ sudo yum install glibc

Rationale:

The glibc package contains standard C and math libraries used by multiple programs on Linux. The glibc shipped with first release of each major Linux version is often not sufficient for SAP. An update is required after the first OS installation.

Severity: 
medium
Identifiers and References
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
- name: Ensure glibc is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - glibc
  tags:
    - package_glibc_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
Remediation Puppet snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
include install_glibc

class install_glibc {
  package { 'glibc':
    ensure => 'installed',
  }
}

Rule   Package uuidd Installed   [ref]

The package uuidd is not installed on normal Linux distribution by default. Applications require this package to avoid database inconsistences caused by duplicated UUIDs. Especially in banking services with SAP where massive UUIDs are created in a short time period, it is important to install the package uuidd. More information can be found in SAP note 1391070. Using the following command to install and/or update the package:

$ sudo yum install uuidd

Rationale:

The uuidd package contains a userspace daemon (uuidd) which is used to generate unique identifiers even at very high rates on SMP systems.

Severity: 
medium
Identifiers and References
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
- name: Ensure uuidd is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - uuidd
  tags:
    - package_uuidd_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
Remediation Puppet snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
include install_uuidd

class install_uuidd {
  package { 'uuidd':
    ensure => 'installed',
  }
}
Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.