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
.
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 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
.
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.
Before continuing, make sure that the packages HANA-Firewall and yast2-hana-firewall are installed.
Make sure the SAP HANA databases for which you want to configure the firewall are correctly installed.
To open the appropriate YaST module, select
› , › .Under
, activate .Select the desired zone from the
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
.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.