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 Template version 1.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 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 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 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, 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 TitleSecurity Profile of Oracle Linux 7 for SAP
Profile IDxccdf_org.ssgproject.content_profile_sap

Revision History

Current version: 0.1.41

  • draft (as of 2018-10-09)

Platforms

  • cpe:/o:oracle:linux:7

Table of Contents

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

Checklist

contains 9 rules

Services   [ref]group

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.

contains 5 rules

Obsolete Services   [ref]group

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 Oracle 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 iptables to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.

contains 5 rules

Rlogin, Rsh, and Rexec   [ref]group

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

contains 3 rules

Disable rlogin Service   [ref]rule

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

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:enable

SYSTEMCTL_EXEC='/usr/bin/systemctl'
"$SYSTEMCTL_EXEC" stop 'rlogin.service'
"$SYSTEMCTL_EXEC" disable 'rlogin.service'
# Disable socket activation if we have a unit file for it
"$SYSTEMCTL_EXEC" list-unit-files | grep -q '^rlogin.socket\>' && "$SYSTEMCTL_EXEC" disable 'rlogin.socket'
# The service may not be running because it has been started and failed,
# so let's reset the state so OVAL checks pass.
# Service should be 'inactive', not 'failed' after reboot though.
"$SYSTEMCTL_EXEC" reset-failed 'rlogin.service'
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
- name: Disable service rlogin
  service:
    name: rlogin
    enabled: "no"
    state: "stopped"
  register: service_result
  failed_when: "service_result is failed and ('Could not find the requested service' not in service_result.msg)"
  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


- name: Disable socket of service rlogin if applicable
  service:
    name: rlogin.socket
    enabled: "no"
    state: "stopped"
  register: socket_result
  failed_when: "socket_result is failed and ('Could not find the requested service' not in socket_result.msg)"
  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

Disable rsh Service   [ref]rule

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

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:enable

SYSTEMCTL_EXEC='/usr/bin/systemctl'
"$SYSTEMCTL_EXEC" stop 'rsh.service'
"$SYSTEMCTL_EXEC" disable 'rsh.service'
# Disable socket activation if we have a unit file for it
"$SYSTEMCTL_EXEC" list-unit-files | grep -q '^rsh.socket\>' && "$SYSTEMCTL_EXEC" disable 'rsh.socket'
# The service may not be running because it has been started and failed,
# so let's reset the state so OVAL checks pass.
# Service should be 'inactive', not 'failed' after reboot though.
"$SYSTEMCTL_EXEC" reset-failed 'rsh.service'
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
- name: Disable service rsh
  service:
    name: rsh
    enabled: "no"
    state: "stopped"
  register: service_result
  failed_when: "service_result is failed and ('Could not find the requested service' not in service_result.msg)"
  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


- name: Disable socket of service rsh if applicable
  service:
    name: rsh.socket
    enabled: "no"
    state: "stopped"
  register: socket_result
  failed_when: "socket_result is failed and ('Could not find the requested service' not in socket_result.msg)"
  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

Remove Rsh Trust Files   [ref]rule

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

NIS   [ref]group

The Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information.

contains 2 rules

Remove NIS Client   [ref]rule

The Network Information Service (NIS), formerly known as Yellow Pages, is a client-server directory service protocol used to distribute system configuration files. The NIS client (ypbind) was used to bind a system to an NIS server and receive the distributed configuration files.

Rationale:

The NIS service is inherently an insecure system that has been vulnerable to DOS attacks, buffer overflows and has poor authentication for querying NIS maps. NIS generally has been replaced by such protocols as Lightweight Directory Access Protocol (LDAP). It is recommended that the service be removed.

Severity:  unknown

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove ypbind
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
- name: Ensure ypbind is removed
  package:
    name: ypbind
    state: absent
  tags:
    - package_ypbind_removed
    - unknown_severity
    - disable_strategy
    - low_complexity
    - low_disruption
Remediation Puppet snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
include remove_ypbind

class remove_ypbind {
  package { 'ypbind':
    ensure => 'purged',
  }
}
Remediation Anaconda snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable

package --remove=ypbind

Uninstall ypserv Package   [ref]rule

The ypserv package can be removed with the following command:

$ sudo yum erase ypserv

Rationale:

The NIS service provides an unencrypted authentication service which does not provide for the confidentiality and integrity of user passwords or the remote session. Removing the ypserv package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.

Severity:  high

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:disable
# Function to remove packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_remove telnet-server
#
function package_remove {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_remove 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if rpm -q --quiet "$package"; then
    dnf remove -y "$package"
  fi
elif which yum ; then
  if rpm -q --quiet "$package"; then
    yum remove -y "$package"
  fi
elif which apt-get ; then
  apt-get remove -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_remove ypserv
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
- name: Ensure ypserv is removed
  package:
    name: ypserv
    state: absent
  tags:
    - package_ypserv_removed
    - high_severity
    - disable_strategy
    - low_complexity
    - low_disruption
    - NIST-800-53-AC-17(8)
    - NIST-800-53-CM-7(a)
Remediation Puppet snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable
include remove_ypserv

class remove_ypserv {
  package { 'ypserv':
    ensure => 'purged',
  }
}
Remediation Anaconda snippet:   (show)

Complexity:low
Disruption:low
Strategy:disable

package --remove=ypserv

System Settings   [ref]group

Contains rules that check correct system settings.

contains 4 rules

Installing and Maintaining Software   [ref]group

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

contains 3 rules

SAP Specific Requirement   [ref]group

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.

contains 3 rules

Package uuidd Installed   [ref]rule

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. The uuidd package can be installed with the following command:

$ 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

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:enable
# Function to install packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_install aide
#
function package_install {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_install 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if ! rpm -q --quiet "$package"; then
    dnf install -y "$package"
  fi
elif which yum ; then
  if ! rpm -q --quiet "$package"; then
    yum install -y "$package"
  fi
elif which apt-get ; then
  apt-get install -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_install uuidd
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
- name: Ensure uuidd is installed
  package:
    name: uuidd
    state: present
  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',
  }
}
Remediation Anaconda snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable

package --add=uuidd

Package glibc Installed   [ref]rule

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. The glibc package can be installed with the following command:

$ 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

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:enable
# Function to install packages on RHEL, Fedora, Debian, and possibly other systems.
#
# Example Call(s):
#
#     package_install aide
#
function package_install {

# Load function arguments into local variables
local package="$1"

# Check sanity of the input
if [ $# -ne "1" ]
then
  echo "Usage: package_install 'package_name'"
  echo "Aborting."
  exit 1
fi

if which dnf ; then
  if ! rpm -q --quiet "$package"; then
    dnf install -y "$package"
  fi
elif which yum ; then
  if ! rpm -q --quiet "$package"; then
    yum install -y "$package"
  fi
elif which apt-get ; then
  apt-get install -y "$package"
else
  echo "Failed to detect available packaging system, tried dnf, yum and apt-get!"
  echo "Aborting."
  exit 1
fi

}

package_install glibc
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
- name: Ensure glibc is installed
  package:
    name: glibc
    state: present
  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',
  }
}
Remediation Anaconda snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable

package --add=glibc

Only sidadm and orasid/oracle User Accounts Exist on Operating System   [ref]rule

SAP tends to use the server or virtual machine exclusively. There should be only SAP system users sidadm and orasid that exist on the operating system (or virtual machine). If SAP Host Agent is installed, the user sapadm must exist too. With Oracle Database using oracle user, the user oracle should exist as well. While SID is the SAP System ID, which is always three alphanumeric characters in upper case, beginning with an alphabetic character, the user names sidadm and orasid are in lower case.

Besides the above SAP users that are automatically detected, other operating system users can be customized in the refine value variable var_accounts_authorized_local_users_regex. OVAL regular expression is used for the user list.

Test result of both fail or error means mismatch of user names and SAP system. The bash remediation commands can be used to delete unexpected users on the operating system.

Warning:  Currently this rule only works with following limitations:
1. SAP system mount directory is /sapmnt (mounted or local file system or a symbolic link to the target directory);
2. there is maximum one SAP System on each operating system or virtual machine (maximum one SID in /sapmnt and /usr/sap).
With the above limitations, the SAP system users sidadm, orasid, sapadm and oracle can be automatically detected.

For other cases, please use the general purpose rule accounts_authorized_local_users and customize the refine value variable var_accounts_authorized_local_users_regex by adding all the authorized user names to the list.

The bash remediation is not limited by the above two conditions, it works in all the cases regardless there is zero, one or multiple SAP systems on the OS/VM.
Rationale:

Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.

Severity:  medium

Remediation Shell script:   (show)


var_accounts_authorized_local_users_regex="^(root|bin|daemon|adm|lp|sync|shutdown|halt|mail|operator|games|ftp|nobody|pegasus|systemd-bus-proxy|systemd-network|dbus|polkitd|abrt|unbound|tss|libstoragemgmt|rpc|colord|usbmuxd$|pcp|saslauth|geoclue|setroubleshoot|rtkit|chrony|qemu|radvd|rpcuser|nfsnobody|pulse|gdm|gnome-initial-setup|postfix|avahi|ntp|sshd|tcpdump|oprofile|uuidd)$"

# never delete the root user
default_os_user="root"

# add users sidamd, orasid, sapadm and oracle if needed
userlist="root"
sapmnt_SID_stem="/sapmnt/[A-Z][A-Z0-9][A-Z0-9]"
oracle_SID_stem="/oracle/[A-Z][A-Z0-9][A-Z0-9]"

# if owner of any directory or file in the given list is the user oracle,
# add the user oracle to the variable userlist. 
# Usage: verify_oracle_user_to_userlist "$path_list"
# Note: this function might modify the value of the global variable userlist
function verify_oracle_user_to_userlist {
	local path_list="$1"
	local is_oracle=no
	for path in $path_list ; do
		if [ $(ls -ld "$path" | awk '{print $3}') = "oracle" ]; then
			is_oracle=yes
		fi
	done
	if test "$is_oracle" = yes ; then
		userlist="$userlist|oracle" ;
	fi
} 

# if /sapmnt is a directory or a symbolic link to a directory,
# then try to add SAP system users to the userlist
if [ -d "/sapmnt" ] ; then 
	# if /sapmnt/SID exists, add sidadm to the userlist
	path_sapmnt_SID_list=$(find /sapmnt/ -regex "^$sapmnt_SID_stem$")
	for path_sapmnt_SID in $path_sapmnt_SID_list ; do
		SID=${path_sapmnt_SID:8:3}
		userlist="$userlist|$(echo "$SID" | sed -e 's/\(.*\)/\L\1/')adm"
	done

	# try to get brspace from directories /sapmnt/SID/exe (SAP binaries of old structure)
	# and /sapmnt/SID/exe/<codepage>/<platform> (SAP binaries of new structure)
	path_to_brspace_list=$(find /sapmnt/ -regex "^$sapmnt_SID_stem/exe/\(\|\(\|n\)uc/[a-z0-9_]+/\)brspace$")

	# if brspace exist in any of the above directory of a SID, add orasid to the userlist 
	for path_to_brspace in $path_to_brspace_list ; do
		SID=${path_to_brspace:8:3}
		userlist="$userlist|ora$(echo "$SID" | sed -e 's/\(.*\)/\L\1/')"
	done

	# if owner of any brspace file is oracle, add oracle to the userlist
	verify_oracle_user_to_userlist "$path_to_brspace_list"
fi

# if owner of any /oracle/SID directory is oracle, add oracle to the userlist
# the user oracle could be added twice in the userlist, but it is harmlos to the final result
if [ -d "/oracle" ] ; then
	path_oracle_SID_list=$(find /oracle/ -regex "^$oracle_SID_stem$")
	verify_oracle_user_to_userlist "$path_oracle_SID_list"
fi

# if /usr/sap/hostctrl is a directory or a symbolic link to a directory, add sapadm to the list
if [ -d /usr/sap/hostctrl ] ; then
	userlist="$userlist|sapadm"
fi

# delete users that is in /etc/passwd but neither in the userlist
# nor in default_os_user nor in the var_accounts_authorized_local_users_regex
default_os_user=^$default_os_user$
userlist=^$userlist$
for username in $( sed 's/:.*//' /etc/passwd ) ; do
	if [[ ! "$username" =~ ($default_os_user|$userlist|$var_accounts_authorized_local_users_regex) ]]; then
		userdel $username ; 
	fi
done

File Permissions and Masks   [ref]group

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.

contains 1 rule

Verify Permissions on Important Files and Directories   [ref]group

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.

contains 1 rule
contains 1 rule

Verify Permissions on shadow File   [ref]rule

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

$ sudo chmod 0640 /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

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

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:configure

chmod 0000 /etc/shadow
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:configure
- name: Ensure permission 0000 on /etc/shadow
  file:
    path: /etc/shadow
    mode: 0000
  tags:
    - file_permissions_etc_shadow
    - medium_severity
    - configure_strategy
    - low_complexity
    - low_disruption
    - NIST-800-53-AC-6
    - PCI-DSS-Req-8.7.c
    - CJIS-5.5.2.2
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.