Applies to SUSE Linux Enterprise Server for SAP applications 15 SP4

10 Configuring a firewall #

This chapter provides information about restricting access to the system using a firewall and encryption and gives information about connecting to the system remotely.

10.1 Configuring `firewalld` #

By default, the installation workflow of SUSE Linux Enterprise Server for SAP applications enables firewalld.

Note: firewalld replaces SuSEfirewall2

SUSE Linux Enterprise Server for SAP applications 15 introduces firewalld as the new default software firewall, replacing SuSEfirewall2. SuSEfirewall2 has not been removed from SUSE Linux Enterprise Server for SAP applications 15 and is still part of the main repository, but it is not installed by default. If you are upgrading from a release older than SUSE Linux Enterprise Server for SAP applications 15, SuSEfirewall2 will be unchanged and you must manually upgrade to firewalld (see Security and Hardening Guide).

The firewall must be manually configured to allow network access for the following components:

SAP application
Database (see the documentation of your database vendor; for SAP HANA, see Section 10.2, “Configuring HANA-Firewall”)

Additionally, open the ports 1128 (TCP) and 1129 (UDP).

SAP applications require multiple open ports and port ranges in the firewall. The exact numbers depend on the selected instance. For more information, see the documentation provided to you by SAP.

10.2 Configuring HANA-Firewall #

To simplify setting up a firewall for SAP HANA, install the package HANA-Firewall. HANA-Firewall adds rule sets to your existing SuSEfirewall2 configuration.

HANA-Firewall consists of the following parts:

YaST module SAP HANA firewall. Allows configuring, applying, and reverting firewall rules for SAP HANA from a graphical user interface.
Command-line utility hana-firewall. Creates XML files containing firewall rules for SAP HANA.
Instead of using YaST, you can configure firewall rules using the configuration file at /etc/sysconfig/hana-firewall.

Important: SAP HANA MDC databases

For multi-tenant SAP HANA (MDC) databases, determining automatically the port numbers that need to be opened is not yet possible. If you are working with a multi-tenant SAP HANA database system, run a script to create a new service definition before using YaST:

# cd /etc/hana-firewall.d
# hana-firewall define-new-hana-service

The script prompts you to answer a series of questions, including TCP and UDP port ranges that need to be opened.

Note: Install HANA-Firewall packages

Before continuing, make sure that the packages HANA-Firewall and yast2-hana-firewall are installed.

Procedure 10.1: Using HANA-Firewall #

Make sure the SAP HANA databases for which you want to configure the firewall are correctly installed.
To open the appropriate YaST module, select Applications › YaST, Security and Users › Configure system firewall for SAP HANA.
Under Global Options, activate Enable and reload firewalld.
Select the desired zone from the Zone drop-down list, and add the required services using the right arrow button.
To add services other than the preconfigured ones, use the following notation:
```
SERVICE_NAME:CIDR_NOTATION
```
For more information about the CIDR notation, see https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing. To find out which services are available on your system, use getent services.
When you are done, click OK.
The firewall rules from HANA-Firewall will now be compiled and applied. Then, the service hana-firewall will be restarted.

Finally, check whether HANA-Firewall was enabled correctly:

# hana-firewall status
HANA firewall is active. Everything is OK.

For more information, see the man page of hana-firewall.

10.3 SAProuter integration #

The SAProuter software from SAP allows proxying network traffic between different SAP systems or between an SAP system and outside networks. SUSE Linux Enterprise Server for SAP applications now provides integration for SAProuter into systemd. This means that SAProuter will be started and stopped properly with the operating system and can be controlled using systemctl.

Before you can use this functionality, make sure the following has been installed, in this order:

An SAP application that includes SAProuter
The SAProuter systemd integration, packaged as saprouter-systemd

If you got the order of applications to install wrong initially, reinstall saprouter-systemd.

To control SAProuter with systemctl, use:

Enabling the SAProuter service: systemctl enable saprouter
Starting the SAProuter service: systemctl start saprouter
Showing the Status of SAProuter service: systemctl status saprouter
Stopping the SAProuter service: systemctl stop saprouter
Disabling the SAProuter service: systemctl disable saprouter

10.4 Securing DNS #

On Linux systems, most applications rely on the glibc POSIX style APIs to perform host name resolution. Internally, glibc uses a "Name Service Switch" (NSS) framework to delegate these resolution requests to different configured tools. The configuration for NSS is located in the /etc/nsswitch.conf file. Several built-in types for host name resolution are available:

files: This method uses the /etc/hosts file that contains static mappings of host names to IP addresses.
dns: This option utilizes the glibc's built-in DNS resolver, which is configured via the /etc/resolv.conf file.

To address the security vulnerabilities inherent in the traditional DNS protocol, several protocol-level solutions have been developed.

The DNS over TLS and DNS over HTTPS methods aim to enhance security by transmitting DNS queries over encrypted TLS connections, either directly (DoT) or embedded within HTTPS (DoH).

The DNSSEC involves cryptographically signing DNS queries and verifying these signatures upon receiving responses. For DNSSEC to function correctly, all DNS servers involved in the resolution process must be configured to support it.

Several implementations are available on Linux to facilitate secure DNS resolution.

The systemd resolved component provides secure DNS resolution services. The systemd resolved nameservice plug-in supports integration with the glibc Name Service Switch (NSS) framework. resolved is part of the systemd-network package available on PackageHub.

To configure resolved add resolve to the hosts line in the /etc/nsswitch.conf file as follows:

hosts:          mymachines resolve [!UNAVAIL=return] files myhostname dns

It is possible to use resolved as a local resolver by directing DNS queries to localhost:dns.

Use the following command to enable and start the resolved service:

# systemctl enable systemd-resolved.service
  # systemctl start systemd-resolved.service

Configuring resolved for secure DNS is done via the resolved.conf configuration file in the /etc/systemd/resolved.conf.d/ directory.

For DNSSEC, the configuration is as follows:

[Resolve]
# Add your local resolvers below:
DNS=192.168.178.1
DNSSEC=on

Another approach is to secure DNS through the Unbound name server that can act as a DNS forwarder, capable of translating regular DNS queries into secure DNS protocols. To use Unbound, it is typically set up locally, and then the /etc/resolv.conf file is configured to point to the local Unbound instance.

In SUSE's default configuration, Unbound performs DNSSEC verification by default. The unbound-anchor service is responsible for obtaining the standard ISC root key.