Red Hat High Availability Clustering for SAP Solutions

OS security refers to specified steps or measures to protect the OS from threats, viruses, worms, or malware remote hackers. The hacker's target in most cases is operating systems. If the hacker gains any access to the system with sufficient permissions and privileges, then they can easily attack any installed application on the OS and even databases. Red Hat Enterprise Linux contains many security-driven configurations to protect the system from attacks, which can improve the overall durability of the operating system and its applications. These settings can be summarized in the following categories:

For more information, see the Red Hat Enterprise Linux 8 Security Guide at https://red.ht/3qp6TNV Operating system security is the process of ensuring OS integrity, confidentiality, and availability of the system on which the SAP HANA database is running.

Security hardening for SAP HANA is the entry point for all information that relates to the secure operation and configuration of SAP HANA. The following hardening settings are recommended to improve security for Red Hat Enterprise Linux Server on a SAP HANA database. Security hardening on the one hand brings the system to a more secure level, but on the other hand reduces administrative and system functionality. The goal is a more restrictive configured system, which provides a better level of protection and a lower risk of attacks. Based on the impact of a particular setting, a system administrator or security engineer can decide if the loss of administrative comfort is worth the gain in security. This consideration depends on how the users are using a system, and on how certain system administrative tasks are performed.

For each hardening setting, the following details are provided:

Figure 6.3: SAP HANA + OS Security

Description:

This part explains which packages are necessary for running a standard SAP HANA system on RHEL. By default, the Red Hat Enterprise Linux installation process loads a suitable software selection for a system that is deployed as a basic server. It is best practice to install only the packages that you will use, because each software item might contain a vulnerability. If you are installing from DVD, you also have the option of selecting the exact packages that you require. You can further customize the RHEL installation, depending on your specific security requirements during this step.

The Package Installation Defaults screen appears and details the default package set for the Red Hat Enterprise Linux installation. This screen varies depending on the Red Hat Enterprise Linux version that you are installing.

Figure 6.4: Software selection - Installation of RHEL

This option provides only the essential packages to run Red Hat Enterprise Linux. A minimal installation provides the basis for a single-purpose server or desktop appliance, and maximizes performance and security on such an installation. For more information about installing the minimal install environment, see Software Selection chapter, https://red.ht/3RvineX of the Red Hat Enterprise Linux 8 Installation Guide at https://red.ht/3qp6TNV, and the Installing SAP HANA DB with RHEL 8.4 Using a Minimal Installation Environment Knowledge base article.

Reducing the number of installed RPM packages to a minimum number of potential files on the system improves the security of a system. A minimized number of packages also reduces the number of updates and patches to apply to a system.

SAP HANA is an in-memory, column-oriented, relational database management system. It is delivered in different versions, and has many additional available components that are not part of the standard installation. Therefore, it is not straightforward to follow the OS minimum required packages in a Linux system. Generally for an SAP HANA system, use of only the OS minimum required packages is impossible, when considering all eventualities of certain SAP HANA installations, including different configurations, versions, and add-ons. Therefore, the current approach to a minimal package selection is an option of Red Hat Linux Enterprise Server installation. The strategy is to use the RHEL "Minimal" installation option, and then to install the required packages for running a SAP HANA instance on RHEL.

Red Hat tested a minimal installation environment for SAP HANA on RHEL. The testing environment was a RHEL 8.4 system with minimal install selected. From there, Ansible scripts installed the required packages to set up a HANA DB. Other Ansible scripts installed the required SAP system roles to set up a HANA DB. For a more streamlined installation of SAP HANA, the following roles can be used: sap-preconfigure and sap-hana-preconfigure.

Lastly, for testing the minimal install environment, Red Hat tested whether the RHEL 8.4 system could run the SAP HANA validation test suite, which is SAP's method to verify whether a system can run and process a HANA DB.

The results of running the SAP HANA validation test suite showed that a RHEL 8.4 system is stable when set up with the minimal packages.

compat-sap-c++ (C ++ compatibility runtime library for SAP applications)

The compat-sap-c++ packages carry the needed runtime compatibility libraries for the SAP HANA system. These libraries are installed independently of the standard runtime libraries from RHEL. It contains the libstdc++ shared library, named sap-compat-c++.so.

libtool-ltdl

The libtool-ltdl package contains the GNU Libtool Dynamic Module Loader, a library that provides a consistent, portable interface that simplifies using dynamic modules. These runtime libraries, which are needed by programs that link directly to the system-installed ltdl libraries, are not needed by software that is built by using the rest of the GNU Autotools (including GNU Autoconf and GNU Automake).

Impact:

Depending on your installation environment for different versions of HANA, it is likely required to install additional RHEL packages.

Priority:

Medium

Many services under Red Hat Enterprise Linux 8 are network services. If a network service is running on a machine, then a server application (called a daemon) is listening for connections on one or more network ports. Treat each of these services as a potential avenue of attack. Network services can pose many risks for Linux systems. Some of the primary issues are as follows: DoS (Denial of Service), DDos (Distributed Denial of Service), script vulnerability attacks, and buffer overflow attacks. These types of attacks, if not prevented can cause the servers to stop functioning with unexpected down times. Potentially, any network service is insecure. For this reason, turning off unused network services is very important. Exploits for services are routinely revealed and patched, and so it is critical to regularly update packages that are associated with any service. Some network protocols are inherently more insecure than others, especially any of the following services:

To secure a RHEL system from attacks via insecure network services, it is recommended to turn off the unused network services. Examples of inherently insecure services include vsftpd, Telnet, rlogin, and rsh. Use ssh in favor. For more information about securing network services, see the following KBA, Security Hardening, at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/security_hardening/index

Disable Telnet

Telnet is an unsecured network protocol service that facilitates remote login to a server via a network connection. It is a legacy remote access protocol that does not support encryption. Thus, it allows hackers or crackers to sniff and obtain this information easily, for example the login username and password for Telnet. It is a good practice to disable Telnet, especially on web servers that are reachable from the Internet, and to replace it with a secure remote access protocol such as SSH. By default, telnet listens for incoming messages on port 23, and sends outgoing messages to port 23.

Procedure for Disabling the Telnet Service

[root@localhost ~]# systemctl stop telnet.socket
[root@localhost ~]# systemctl disable telnet.socket
[root@localhost ~]# systemctl status telnet.socket
● telnet.socket - Telnet Server Activation Socket
  Loaded: loaded (/usr/lib/systemd/system/telnet.socket; disabled; vendor preset: disabled)
  Active: inactive (dead)
        Docs: man:telnetd(8)
  Listen: [::]:23 (Stream)
 Accepted: 0; Connected: 0
Apr 04 15:12:15 localhost systemd[1]: Listening on Telnet Server Activation Socket.
Apr 04 15:12:15 localhost systemd[1]: Starting Telnet Server Activation Socket.
Apr 04 15:30:14 localhost systemd[1]: Closed Telnet Server Activation Socket.
Apr 04 15:30:14 localhost systemd[1]: Stopping Telnet Server Activation Socket.

To enable Telnet again, see How to Enable the Telnet Service at https://access.redhat.com/solutions/1269.

The sudo command offers a mechanism for providing trusted users with administrative access to a system without sharing the password of the root user. When users with access via this mechanism precede an administrative command with sudo, they are prompted to enter their own password. When authenticated, and assuming that the command is permitted, the administrative command is executed as if the root user ran it. As with the su command, sudo asks for the root password by default. However, unlike su, sudo remembers the password and allows further commands to be executed as root without asking again for the password. Therefore, sudo should be enabled for selected users only, specifically administrative admin users.

Procedure to Restrict sudo for Normal Users:

[root@localhost ~]# chgrp wheel /usr/bin/sudo /usr/bin/su

[root@localhost ~]# chmod 4550 /usr/bin/sudo /usr/bin/su

[root@localhost ~]# visudo

%wheel ALL=(ALL) ALL

wheel:x:10:<user names of sysadmin users>

The user that is added to the wheel group should be logged out and log in to the system again, so that the new group membership is applied.

Impact:

This procedure prohibits the sudo command for all users, other than for members of the wheel group. The su command is still available for other users.

Priority:

High

By default, the root access is enabled for the outside world. It is not secure for ssh root access to be enabled for unauthorized users. So, it is better to have another account that you regularly use, and then to switch to root user by using the su - command when necessary. Before disabling root logins, add an administrative user that can use ssh to the server and become root with su. To prevent root logins via the SSH protocol, edit the SSH daemon's configuration file, /etc/ssh/sshd_config. Add a line in the Authentication section of the file: PermitRootLogin no. This line might exist and be commented out. In this case, uncomment it by removing the # sign before PermitRootLogin no.

Procedure:

Make the following changes in the /etc/ssh/sshd_config file:

#Authentication
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

Restart the SSH server:

Use the following command:

[root@localhost ~]# service sshd restart

Impact:

Root cannot log in to the system remotely any more. Users must first log in to the system, and then use su or sudo to get the root access when they are using ssh to log in to the system.

Priority:

High

Locking out a user to log in again after a certain number of failed login attempts prevents users from logging in, and is one of the security configurations on RHEL. Red Hat Enterprise Linux provides this mechanism via the Pluggable Authentication Module (PAM) system. PAM comes with the pam_tally login counter module. The pam_tally module has the capability to maintain an attempted access count, to reset counters on successful logins, and also to lock out users with multiple failed login attempts. In the authentication phase of the /etc/pam.d/system-auth and /etc/pam.d/password-auth files, the pam_tally deny parameter can be used to restrict the number of failed login attempts. The user account is locked out after the login attempts exceed the deny tally value. For Red Hat Enterprise Linux 8, pam_tally2 is replaced by pam_faillock. In Red Hat Enterprise Linux 8, the pam_faillock PAM module allows system administrators to lock out user accounts after a specified number of failed attempts. Limiting user login attempts is mainly a security measure that aims to prevent possible brute force attacks that are targeted to obtain a user's account password. With the pam_faillock module, failed login attempts are stored in a separate file for each user in the /var/run/faillock directory. Follow these steps to configure account locking:

Enabling or Disabling faillock

[root@localhost ~]# authselect enable-feature with-faillock

[root@localhost ~]# authselect disable-feature with-faillock

Configuring failock

The faillock options should be stored in /etc/security/faillock.conf:

deny=4
unlock_time=1200
silent

Using the faillock Command to Reset or View Authentication Failure Records:

Use commands such as the following ones:

[root@localhost ~]# faillock --user username

[root@localhost ~]# faillock --user username --reset

SSHD configuration adjustment

If pam_faillock.so is not working as expected, the following changes might be needed to the SSHD configuration:

[root@localhost ~]# vi /etc/ssh/sshd_config

ChallengeResponseAuthentication yes

PasswordAuthentication no

Then, restart the sshd service to apply these configuration changes:

[root@localhost ~]# systemctl restart sshd

Impact:

The password for RHEL system users must be set according to the Defining Password Policies. After the user makes a certain number of failed attempts to log in to the system, the user is locked, and cannot log in to the RHEL system.

Priority:

Medium

The network communication channels that SAP HANA uses can be categorized into channels for database clients to connect to SAP HANA, and channels for internal database communication. SAP recommends to use encrypted communication channels where possible.

To support the various SAP HANA scenarios and setup, SAP HANA has different types of network communication channels:

The connections between SAP HANA and external components and applications come under these categories:

To integrate SAP HANA securely into the network environment, several general recommendations apply. The components of an SAP HANA landscape communicate through different network communication channels. It is a recommended security practice to have a well-defined network topology to control and limit network access to SAP HANA to only those communication channels for the scenario, and to apply appropriate security measures, such as encryption, where necessary.

This setup can be achieved through different means, such as with separate network zones, network firewalls, and through the configuration options from SAP HANA, such as encryption. The exact setup depends on your environment, implementation scenario, requirements, and policies. In the SAP HANA Security Guide at https://help.sap.com/doc/eec734dbb0fd1014a61590fcb5411390/1.0.12/en-US/SAP_HANA_Security_Guide_en.pdf, it is recommended to protect internal communication further by applying additional mechanisms. They might include filtering access to the relevant ports and channels by applying additional protection at the network level, for example with VPN or IPsec.

In Red Hat Enterprise Linux 8, a Virtual Private Network (VPN) can be configured by using the IPsec tunneling protocol, which the Libreswan application supports.

Libreswan is a fork of the Openswan application, and examples in documentation should be interchangeable. The NetworkManager IPsec plug-in is called NetworkManager-libreswan. Users of GNOME shell should install the NetworkManager-libreswan-gnome package, which is available only from the Optional channel. See Enabling Supplement and Optional Repositories at https://red.ht/3eAtPHp

Libreswan is an open-source, user-space IPsec implementation that is available in Red Hat Enterprise Linux 8. Libreswan interfaces with the Linux kernel by using netlink to transfer the encryption keys. Packet encryption and decryption happen in the Linux kernel.

IMPORTANT:

IKE/IPsec, implemented by Libreswan, is the only recommended VPN technology for use in Red Hat Enterprise Linux 8. Do not use any other VPN technology without understanding the risks of doing so.

Procedure:

To install and verify that Libreswan is installed, run the following commands as root:

[root@localhost ~]# yum install libreswan
[root@localhost ~]# yum info libreswan

After installing Libreswan, the NSS database must be initialized as part of the installation process. However, if you need to start a new database, first remove the old database and then, to initialize a new NSS database, run as follows:

[root@localhost ~]# rm /etc/ipsec.d/*db
#ipsec initnss
Initializing NSS database
See man pluto if you want to protect the NSS database with a password

If you do not want to use a password for NSS, press Enter twice when prompted for the password. If you do enter a password, then you must re-enter it every time that Libreswan is started, such as every time that the system is booted. To start the ipsec daemon from Libreswan and to confirm that the daemon is now running, issue the following command as root:

[root@localhost ~]# systemctl start ipsec
[root@localhost ~]# systemctl status ipsec
ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled)
Active: active (running) since Wed 2018-02-21 12:14:12 CET; 2 days ago

To ensure that Libreswan starts when the system starts, run the systemctl enable ipsec command as root. For more information about Libreswan and Security VPN, see Chapter 4, Configuring a VPN with IPsec, from the RHEL 8 Security Guide.

To use the Transport Layer Secure (TLS)/Secure Socket Layer (SSL) protocol to secure communication between the SAP HANA database and clients that access the SQL interface of the database, TLS/SSL must be configured on both the server and client. Before configuring TLS/SSL on the SAP HANA server, verify whether the SAP Cryptographic Library CommonCryptoLib (SAPCRYPTOLIB) is available on the server.

CommonCryptoLib (libsapcrypto.so) is installed by default as part of SAP HANA installation at $DIR_EXECUTABLE. If you are using trust and key stores in the file system instead of in the database, then OpenSSL is also supported. The OpenSSL library is installed by default as part of the RHEL installation. However, it is recommended that you migrate to CommonCryptoLib after an upgrade to Support Package Stack. For more information, see SAP Note 2093286, https://launchpad.support.sap.com/#/notes/2093286

OpenSSL is a cryptography toolkit that implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols and related cryptography standards that they require. The OpenSSL program is a command-line tool for using the various cryptography functions of OpenSSL's crypto library from the shell. It can be used for the following purposes:

OpenSSL is one of the packages that the user must install on RHEL 8 for SAP HANA as a dependency for SAP HANA. To install the OpenSSL, execute the required commands as follows:

[root@lv8020 ~]# yum install openssl
Loaded plugins: product-id, rhnplugin, search-disabled-repos
This system is receiving updates from RHN Classic or Red Hat Satellite.
Resolving Dependencies
--> Running transaction check
---> Package openssl.x86_64 1:1.0.2k-8.el8 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================
Package          Arch       Version       Repository                Size
===========================================================================
Installing:openssl x86_64   1:1.0.2k-8.el8  rhel-x86_64-server-8.0.eus 492k

Transaction Summary
===========================================================================
Install 1 Package

Total download size: 492 k
Installed size: 826 k
Is this ok [y/d/N]:

The <sid>adm user, where <sid> is the ID of the SAP HANA system, is not a database user, but a user at the operating system user level, and is also referred to as the operating system administrator. For example, the <sid>adm user is created during the installation process with super user privileges. All platform services of the SAP HANA system, including the application server, run with this OS user. Therefore, <sid>adm is not limited in any way, and must be handled with special care. This operating system user has unlimited access to all local resources that relate to SAP systems.

Being the owner of all OS processes, this administrative user is powerful from a security perspective. For this reason, it is strongly recommended that the user limits the number of people with <sid>adm credentials as much as possible.

The initial password is specified during installation by your hardware partner or certified administrator. After handover, it is important that you change this password. A system administrator can change it at the operating system level. It is also possible as part of a system rename with SAP HANA lifecycle manager.

Priority:

High

SELinux is enabled by default on RHEL 8 systems. The goal of this section is to re-enable SELinux on RHEL 8 systems that run SAP HANA where SELinux was previously disabled.

SELinux can run in one of three modes: disabled, permissive, or enforcing. Red Hat suggests to set SELinux to enforcing, to provide a more secure system.

When enabled, SELinux has two modes: enforcing and permissive. Use the getenforce or sestatus commands to verify the status of SELinux. The getenforce command returns enforcing, permissive, or disabled. The sestatus command returns the SELinux status and the SELinux policy in use:

[localhost@linux ~]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      30

SELinux provides the following benefits:

When SELinux is running in enforcing mode, it enforces the SELinux policy and denies access based on SELinux policy rules. In Red Hat Enterprise Linux, enforcing mode is enabled by default when the system was initially installed with SELinux. One way of changing the SELinux mode permanently to either enforcing or permissive is to edit the /etc/sysconfig/selinux file and set SELINUX parameters value to either enforcing or permissive.

[localhost@linux ~]$ ls -l /etc/sysconfig/selinux
lrwxrwxrwx. 1 root root 17 Nov 15 2016 /etc/sysconfig/selinux -> ../selinux/config


[localhost@linux ~]$ cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are
protected.
#     mls - Multi Level Sec

To verify the SELinux mode, use the getenforce command, as in the following example:

[root@localhost ~]# getenforce
Enforcing

When you enable SELinux on systems where it was previously disabled, to avoid problems, such as systems that cannot boot, or process failures, follow this procedure:

Enable SELinux in Permissive Mode

Edit the /etc/sysconfig/selinux file and set SELINUX parameters value to permissive.

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Relabel the whole file system to fix SELinux labels on the file system:

[root@localhost ~]# fixfiles onboot

Restart your system:

[root@localhost ~]# reboot

After the system restarts, confirm that the getenforce command returns Permissive:

[root@localhost ~]# getenforce
Permissive

If the system boots in permissive mode and without SELinux denials, then continue with the next section, Enable SELinux in enforcing mode.

Enable SELinux in Enforcing Mode

Edit the /etc/sysconfig/selinux file and set SELINUX parameters value to permissive:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#    enforcing - SELinux security policy is enforced.
#    permissive - SELinux prints warnings instead of enforcing.
#    disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#    targeted - Targeted processes are protected,
#    mls - Multi Level Security protection.
SELINUXTYPE=targeted

Restart your system:

[root@localhost ~]# reboot

After the system restarts, confirm that the getenforce command returns Enforcing:

[root@localhost ~]# getenforce
Enforcing

How to Read and Understand Log Files and Check for SELinux Denial Messages

When your software is blocked by SELinux, the /var/log/audit/audit.log file is the first place to check for more information about a denial. To query Audit logs, use the ausearch tool. Because the SELinux decisions, such as allowing or disallowing access, are cached and this cache is known as the Access Vector Cache (AVC), use the AVC and USER_AVC values for the message type parameter, for example:

[root@localhost ~]# ausearch -m \
> AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

Or:

[root@localhost ~]# ausearch -m AVC -ts boot

If no matches, check if the Audit daemon is running. If not, repeat the denied scenario after you start auditd and check the Audit log again.

If no denials, switch to enforcing mode.

[root@localhost ~]# setenforce 1

Another way of changing the SELinux mode permanently to either Enforcing or Permissive is to edit the /etc/sysconfig/selinux file and set SELINUX parameters value to either enforcing or permissive:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#    enforcing - SELinux security policy is enforced.
#    permissive - SELinux prints warnings instead of enforcing.
#    disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#    targeted - Targeted processes are protected,
#    mls - Multi Level Security protection.
SELINUXTYPE=targeted

Then, restart the machine:

[root@localhost ~]# reboot

Verification Steps:

After the system restarts, confirm that the getenforce command returns Enforcing:

[root@localhost ~]# getenforce
Enforcing

SAP Hana processes should run in the unconfined_t SELinux policy. You can verify it by running this command:

[root@localhost ~]# ps -efZ | grep unconfined_t

Refer to this link for instructions on how to create exceptions in SELinux, at https://red.ht/3DdIEKu

If you need to disable SELinux:

Changing the SELinux mode from Enforcing to Disabled immediately on a running system is not possible.

To set the SELinux mode to Disabled permanently, use the following command and reboot the server:

[root@localhost ~]# sed -i \
> 's/\(SELINUX=enforcing\|SELINUX=permissive\)/SELINUX=disabled/g' \
> /etc/selinux/config

This command configures the /etc/selinux/config file so that any SELINUX parameter setting other than disabled is changed to disabled. The SELinux configuration change takes effect only after a system reboot. Note the different spelling in the /etc/selinux/config file versus in the getenforce/setenforce usage and outputs: All characters of the SELINUX value in file /etc/selinux/config are in lowercase, whereas the SELINUX value in the mentioned commands is capitalized.

Unless noted otherwise, all mentioned changes require root access at the operating system level. It is recommended to reboot the system after the changes are applied. Future implementations might lead to changes of these recommendations.

Conclusion

To properly enforce rules on your machine, it is recommended to enable SELinux on your machine after installing RHEL. For enabling SELinux, Red Hat recommends to enable enforcing on RHEL 8.2 and later systems, because it was not tested on earlier versions. If a system has issues with SELinux denials, the recommendation is to set SELinux to permissive mode and then view the SELinux logs to see what processes are being denied. If these processes should be allowed, then create an exception.

Priority

High

As security vulnerabilities are discovered, the affected software must be updated to limit any potential security risk. If the software is part of the package within a Red Hat Enterprise Linux distribution that is currently supported, then Red Hat is committed to releasing updated packages that fix the vulnerability as soon as possible. Often, announcements about a given security exploit are accompanied with a patch (or source code) that fixes the problem. This patch is then applied to the Red Hat Enterprise Linux package, and tested and released as an erratum update. However, if an announcement does not include a patch, then Red Hat developers first work with the maintainer of the software to fix the problem. When the problem is fixed, the package is tested and released as an erratum update. If an erratum update is released for software on your system such as SAP HANA, then it is highly recommended to update the affected packages as soon as possible, to minimize the time that the system is potentially vulnerable. If a security patch impacts SAP HANA operation, then SAP will publish an SAP note where it is stated. To install and configure SAP HANA on RHEL, see the SAP Note 2009879, https://launchpad.support.sap.com/#/notes/2009879.

All software contains bugs. Often, these bugs can result in a vulnerability that can expose your system to malicious users. Packages that are not updated are a common cause of computer intrusions. Implement a plan for timely installing security patches to quickly eliminate discovered vulnerabilities, so that they cannot be exploited. Test security updates when they become available, and schedule to install them. Additional controls are needed to protect the system during the time between the release of the update and its installation on the system. These controls depend on the exact vulnerability, but might include additional firewall rules, the use of external firewalls, or changes in software settings.

Bugs in supported packages are fixed with the errata mechanism. An erratum consists of one or more RPM packages accompanied by a brief explanation of the problem that the particular erratum deals with. All errata are distributed to customers with active subscriptions through the Red Hat Subscription Management service. Errata that address security issues are called Red Hat Security Advisories.

When updating software on a system, it is important to download from a trusted source. An attacker can easily rebuild a package with the same version number as the one that is supposed to fix the problem, but with a different security exploit, and release it on the internet. If so, then use of security measures such as verifying files against the original RPM does not detect the exploit. Thus, it is important to download RPMs only from trusted sources, such as from Red Hat, Inc, and to check the signature of the packages to verify their integrity.

Red Hat offers ways to find information about errata updates:

Red Hat Enterprise Linux consistently provides security updates and patches, so that SAP HANA can run in a secure environment, with the highest security standards.

The yum package manager includes several security-related features to search, list, display, and install security errata. These features also make it possible to use yum to install only security updates.

To check for available security-related updates for the system, enter the following command as a root user:

Procedure

[root@localhost ~]# yum check-update --security
Loaded plugins: product-id, rhnplugin, search-disabled-repos
This system is receiving updates from RHN Classic or Red Hat Satellite.
--> pcp-pmda-postfix-3.11.3-4.el7.x86_64 from rhel-x86_64-server-8.0.eus excluded
(updateinfo)
--> fence-agents-bladecenter-4.0.11-27.el7.x86_64 from rhel-x86_64-server-8.0.eus
excluded (updateinfo)
--> 10:libcacard-1.5.3-105.el7.x86_64 from rhel-x86_64-server-8.0.eus excluded
(updateinfo)
...
No packages needed for security; 0 packages available
Security: kernel-3.10.0-693.17.1.el7.x86_64 is an installed security update
Security: kernel-3.10.0-693.el7.x86_64 is the currently running version

Use the following command to install only security-related updates:

[root@localhost ~]# yum update --security
Loaded plugins: product-id, rhnplugin, search-disabled-repos
This system is receiving updates from RHN Classic or Red{nbsp}Hat Satellite.
No packages needed for security; 0 packages available
No packages marked for update