Executive Summary
Operating-system security is a critical component of protecting SAP S/4HANA and SAP HANA environments, particularly where workloads run on SUSE Linux Enterprise Server. Weak permissions, unnecessary services, insecure remote access, missing patches, exposed ports, and inadequate logging can allow attackers to bypass application-level controls and compromise critical SAP resources. These weaknesses can also increase exposure to ransomware, which may exploit operating-system vulnerabilities, gain elevated privileges, modify services, access network shares, and encrypt or delete business-critical files. Organizations should therefore apply a layered security strategy that protects sensitive SAP profiles, secure stores, certificates, HANA configuration files, administrative accounts, system binaries, and audit records at the OS level.
This includes enforcing least privilege, restricting network access through allowlist-based firewall rules, disabling obsolete services, strengthening SSH and password controls, enabling AppArmor and file-integrity monitoring, and maintaining a supported and fully patched operating system. The Linux Audit Framework provides an additional layer of visibility by recording privileged activity, configuration changes, failed access attempts, account administration, kernel events, and modifications to security-sensitive files.
The Cybersecurity Extension for SAP supports these requirements through integrated SLES security capabilities, including sensitive-file permission checks, vulnerable port and service detection, audit-log monitoring, actionable alerts, and SIEM integration. Its monitoring of external connections, malicious program execution, root access, code injection, systemd changes, file-system mounts, and unauthorized file activity can help identify ransomware attack patterns at an early stage. By extending security monitoring across the SAP application, HANA database, and SLES operating-system layers, organizations can reduce the attack surface, strengthen ransomware protection, improve compliance, and enhance the resilience of business-critical SAP systems.
Why Operating-System Security Matters for SAP
Operating-system security is a critical but often overlooked component of SAP cybersecurity. SAP applications depend on the underlying operating system to manage processes, files, user accounts, services, network connections, and access to sensitive business data. Weaknesses at the OS layer can undermine even well-secured SAP applications and databases.
Ransomware, for example, can exploit OS vulnerabilities to compromise SAP solutions and circumvent application-level security controls. Protecting SAP systems therefore requires more than application-level controls. It requires hardening and monitoring of the underlying operating-system layer.
The Role of SLES in Modern SAP Environments
Linux is the leading operating system for modern SAP environments, particularly for SAP HANA and SAP S/4HANA deployments. Among supported Linux distributions, SUSE Linux Enterprise Server is the most widely used, reflecting its longstanding co-engineering partnership with SAP, performance optimization, high-availability capabilities, and enterprise-level support.
For organizations running SAP workloads on SLES, operating-system security should include managing system services, removing unnecessary packages, restricting network exposure, and enforcing strong authentication and least-privilege access for administrative accounts. Timely vulnerability and patch management is equally important, including updates for the kernel, libraries, and third-party components that could expose SAP systems to attack.
Organizations should also protect critical SAP files and directories, monitor changes to configurations and permissions, and collect security-relevant logs for analysis.
Protecting Security-Sensitive SAP and HANA Files
Critical security-sensitive files for SAP S/4HANA and SAP HANA include SAP system profiles, cryptographic key and certificate files, secure storage files, HANA configuration files, SAP and HANA executables, and Linux security configuration files.
These files control authentication, encryption, network communications, service startup, privileged access, and database behaviour, making them attractive targets for attackers seeking to weaken controls or establish persistence.
Organizations should therefore restrict access, enforce appropriate ownership and permissions, monitor unauthorized changes, and maintain reliable backups. Particular attention should be given to SAP profiles, PSE files, ABAP and HANA secure stores, HANA INI files, service-account SSH keys, sudo configurations, and startup definitions. Monitoring should also account for legitimate changes introduced by patching, maintenance, and certificate renewal.
Restricting Network Ports and Services
Apply a Default-Deny Network Model
Network services on SUSE Linux Enterprise Server should follow a default-deny model. Only ports required for documented SAP communications and approved administrative functions should be open, and access should be limited to specific source systems and network zones.
SAP maintains a centralized reference of required TCP/IP ports used by its products and recommends using this information to plan and configure network infrastructure. Because SAP ports frequently incorporate the instance number, firewall rules should be defined for the actual instances deployed rather than opening broad port ranges.
Allow Only Required SAP Communications
For an SAP S/4HANA application server, required ports may include the dispatcher on 32<NN>, the gateway on 33<NN>, the message server on 36<NN>, and HTTP or HTTPS ports configured for the Internet Communication Manager.
SAP HANA uses additional instance-dependent ports for SQL access, internal communication, system replication, administration, and monitoring. These ports should only be reachable by authorized application servers, administrators, monitoring tools, and other approved components.
Internet-facing access should normally be routed through controlled entry points such as reverse proxies, SAP Web Dispatcher, application gateways, or dedicated load balancers rather than exposing SAP application or database services directly.
Disable Unnecessary and Legacy Services
Organizations should review each SLES host for unnecessary or prohibited services. Legacy and insecure services—including Telnet, FTP, TFTP, rlogin, rsh, rexec, finger, echo, chargen, daytime, and unencrypted mail or file-transfer protocols—should generally be disabled.
Ports associated with unrelated databases, remote-access tools, peer-to-peer software, development services, container interfaces, message brokers, and commonly abused backdoors should also remain closed unless there is a documented business requirement.
Validate Legitimate Exceptions
A blacklist should not be applied without considering the services required for the relevant SAP solutions. Several ports are often required for legitimate infrastructure or SAP operations.
Port 22 may be required for restricted SSH administration, 53 for DNS, 123 for time synchronization, 389 for LDAP, and 80 or 443 for approved web communications. Similarly, ports 50013 and 50014 can be associated with SAP HANA services, depending on the HANA instance number and deployment model.
These ports should not be closed solely because they appear on a generic blacklist. Administrators should validate each listening process, confirm that it is required, restrict it to trusted interfaces and source addresses, and use encrypted alternatives wherever possible.
Enforce Firewall Governance
Firewall controls should be enforced both at the network layer and through the SLES host firewall. Administrators should regularly compare listening ports against the approved SAP architecture, investigate unexpected services, and remove or disable software that is not required.
Changes should be documented and monitored so that unauthorized services, accidental exposure, or ports opened temporarily for maintenance do not remain available. This allowlist-based approach reduces the attack surface while preserving the communications required for secure and reliable SAP operations.
General SLES Security Hardening for SAP
Use a Supported and Fully Patched Operating System
Organizations should use a vendor-supported SLES release certified for the deployed SAP products, install security patches promptly, verify package signatures through zypper, and remove obsolete packages, development tools, and services that are not required for SAP operations.
Operating-system changes should be tested before production deployment because SAP HANA supports additional hardening only where the changes do not conflict with SAP requirements or known compatibility restrictions.
Secure Remote Administration
Remote administration is a particularly important area. Unencrypted and legacy services such as Telnet should be removed, while SSH access should be restricted to authorized administrators and trusted management networks.
Recommended controls include:
- Prohibiting empty passwords and direct root login
- Disabling host-based authentication and unnecessary X11 forwarding
- Enforcing strict file-permission checks
- Limiting permitted users and groups
- Configuring session timeouts
- Using approved encryption ciphers and message-authentication algorithms
SSH private keys and configuration files should have restrictive ownership and permissions. Administrative activity should use named accounts with controlled privilege escalation rather than shared root access. OpenSSH encrypts authentication and session traffic, helping protect administrative connections against interception and hijacking.
Strengthen User and Privileged Access Management
User and privilege management should follow least-privilege principles. Every administrator should have a unique account, only the root account should use UID 0, and system or service accounts that do not require interactive access should have login shells disabled.
Password controls should establish appropriate minimum length and complexity, prevent excessive reuse, use secure hashing, enforce minimum and maximum lifetimes where required, and lock or delay accounts following repeated failed logon attempts.
Sudo access should be limited to approved users, require authentication and periodic re-authentication, and avoid unrestricted NOPASSWD rules. Multifactor authentication or smart-card authentication can provide additional protection for high-risk administrative access.
Protect Files and File Systems
File-system protections should prevent unauthorized modification of operating-system and SAP resources. Organizations should verify the ownership and permissions of system binaries, libraries, log files, home directories, SSH keys, password files, SAP profiles, HANA configuration files, and secure stores.
Default umask settings should prevent newly created files from being broadly accessible. Shared directories that must be world-writable should have the sticky bit enabled to prevent users from deleting or renaming files owned by others. Unnecessary world-write permissions should be removed.
Where compatible with SAP requirements, nosuid and noexec options should be considered for removable media and remote file systems. Separate partitions for /var, /var/log/audit, and other high-growth areas can also reduce the risk that logging or temporary-file activity consumes space required by critical SAP services.
Harden Network and Kernel Settings
SLES network settings should be hardened by disabling IP forwarding unless explicitly required, rejecting source-routed packets and unnecessary ICMP redirects, enabling TCP SYN-cookie protection, and disabling unused wireless interfaces.
The host firewall should be enabled and configured using an allowlist of required SAP and infrastructure communications. On SLES 15, firewalld is the default host firewall and replaces the older SuSEfirewall2 framework.
Enable AppArmor, Boot Protection, and Secure Cryptography
AppArmor should be installed, enabled, and configured to restrict the files, capabilities, and system resources available to supported processes.
Boot security should also be considered by protecting GRUB or UEFI configuration against unauthorized modification and restricting access to the system console.
Where regulatory requirements apply, organizations can evaluate SLES FIPS mode and approved cryptographic algorithms. These settings should be tested carefully because enabling FIPS restrictions can affect interoperability with older SAP components, integrations, or administrative tools.
Enable Auditing and File-Integrity Monitoring
Comprehensive auditing and file-integrity monitoring are essential for detecting changes that could affect SAP security.
The Linux Audit Framework should record:
- Modifications to user and group databases
- Execution of privileged commands
- Changes to access permissions
- Kernel-module activity
- Unsuccessful attempts to access protected files
- Alterations to logon records
Audit logs should have restrictive permissions, sufficient dedicated storage, defined actions for low-space and disk-full conditions, and preferably be forwarded to a protected remote logging or SIEM platform.
AIDE or an equivalent file-integrity monitoring capability should periodically verify critical operating-system, SAP, and HANA files, including ownership, permissions, access control lists, extended attributes, and cryptographic checksums.
High-priority targets include audit tools, SSH configuration, system binaries, startup definitions, SAP profiles, HANA INI files, PSE certificates, and secure-store files. Alerts should distinguish unauthorized changes from approved maintenance, patching, kernel upgrades, and certificate renewals.
Support Operational Resilience
Operational resilience controls should complement preventive hardening. Accurate time synchronization is necessary to correlate SAP, HANA, operating-system, and SIEM events, so the approved NTP or chrony service should be configured with trusted time sources and suitable polling intervals.
Root system mail should be forwarded to a monitored administrative account, and kdump should be configured where required to preserve diagnostic information following kernel failures.
Systems should also be rebooted when necessary to activate security-relevant kernel or library updates. Together, these measures establish a hardened, monitored, and supportable SLES platform for business-critical SAP workloads.
Enabling Audit Logging on SLES
The Linux Audit Framework provides detailed records of security-relevant activity on SUSE Linux Enterprise Server, including administrative actions, authentication events, file access, configuration changes, and the execution of privileged commands.
For SAP environments, audit logging can help identify unauthorized activity affecting the operating system, SAP service accounts, application files, HANA configuration, and other sensitive resources. Audit records are normally written to /var/log/audit/audit.log and can be forwarded to a SIEM or centralized logging platform for monitoring and correlation.
Step 1: Check the Audit Packages
Confirm that the audit and audit-libs packages are installed:
sudo rpm -q audit audit-libs
Alternatively, use Zypper to review the installed package status:
sudo zypper search –installed-only audit audit-libs
If either package is missing, install it using:
sudo zypper install audit audit-libs
The audit package provides the audit daemon and administration utilities, while audit-libs provides the libraries required by the Linux Audit Framework.
Step 2: Start the auditd Service
Start the audit daemon so that the system can begin processing and recording audit events:
sudo systemctl start auditd
Verify that the service is running successfully:
sudo systemctl status auditd
The service should report an active (running) state. Any startup errors should be investigated before audit rules are deployed.
Step 3: Enable auditd at Boot
Configure the audit daemon to start automatically whenever the SLES server is restarted:
sudo systemctl enable auditd
Confirm the boot-time configuration with:
sudo systemctl is-enabled auditd
The expected result is:
enabled
Enabling the service at boot helps ensure that security events are recorded consistently following planned maintenance, operating-system patching, or an unexpected system restart.
Step 4: Restart the auditd Service
After modifying /etc/audit/auditd.conf, adding rules under /etc/audit/rules.d/, or making other audit-related configuration changes, restart the service:
sudo systemctl restart auditd
Verify the service status after the restart:
sudo systemctl status auditd
Restarting auditd ensures that the updated configuration and audit rules are loaded.
Configure SAP-Relevant Audit Rules
Once the service is operational, organizations should define audit rules that reflect the risks within their SAP environment.
These can include monitoring changes to:
- SAP profiles
- HANA INI files
- Secure stores
- User and group databases
- SSH configuration
- Sudo policies
- Privileged executables
- Kernel modules
- File permissions
- Audit configuration
Audit storage limits, log rotation, disk-full actions, remote forwarding, and alerting should also be configured to prevent audit records from being lost or altered.
How the Cybersecurity Extension for SAP Supports SLES Security
The Cybersecurity Extension for SAP provides integrated SLES hardening and monitoring capabilities that help organizations identify vulnerabilities, detect suspicious events, and protect critical SAP resources through a unified, cross-stack security platform.
Monitoring Sensitive Files and Directories
The SAP-certified solution reviews permissions and ownership for sensitive SAP and operating-system files and directories, including:
- SAP system profiles
- Secure Storage in the File System
- Gateway and message server resources
- HANA security directories
- /etc/ssh
- /etc/sudoers
- /etc/sudoers.d
- /etc/passwd
- /etc/shadow
This helps identify excessive permissions, incorrect ownership, and unauthorized access paths that could expose credentials, certificates, security configurations, or privileged SAP components.
Detecting Exposed Ports and Services
The Cybersecurity Extension for SAP detects open ports and services that may unnecessarily increase the attack surface of SLES hosts.
Its coverage includes:
- Legacy protocols
- Remote-access services
- Unrelated database ports
- File-sharing services
- Administrative interfaces
- Peer-to-peer services
- Container interfaces
- Message brokers
- Ports commonly associated with malware or backdoors
Findings can include exposed Telnet, FTP, RPC, SMB, VNC, database, container, message-broker, web-management, and other network services.
Because some ports—including SSH, DNS, NTP, LDAP, HTTPS, and certain SAP HANA ports—may be required for legitimate operations, results should be evaluated against the approved SAP architecture. This enables organizations to distinguish necessary connectivity from unauthorized or unnecessary exposure and apply a controlled, allowlist-based firewall policy.
Assessing SLES Hardening Controls
Comprehensive SLES hardening checks help organizations assess security across SSH, authentication, account management, privileged access, file permissions, networking, logging, boot security, cryptography, and endpoint protection.
The Cybersecurity Extension for SAP can identify weaknesses such as:
- Direct SSH root access
- Empty passwords
- Unapproved ciphers and MAC algorithms
- Unrestricted X11 forwarding
- Insecure session settings
- Missing warning banners
- Insufficient password controls
- Excessive sudo privileges
- Inactive AppArmor protection
- Unsupported operating-system versions
- Missing software patches
- Disabled host firewalls
- Insecure remote mount options
- World-writable directories
- Weak kernel security settings
- Inadequate audit storage
- Missing AIDE deployment
- Disabled package-signature validation
- Unnecessary services such as Telnet
Assessing the Linux Audit Framework
Hardening coverage extends to the Linux Audit Framework. The solution can assess whether the required audit packages and plugins are installed, whether auditd is enabled and running, and whether sufficient audit rules are configured.
Relevant areas include:
- Privileged commands
- User and group changes
- Unsuccessful file access
- Kernel modules
- Discretionary access controls
- System administration activity
- Logon records
- Removable media
The solution can also identify weaknesses in audit-log storage, disk-space actions, remote forwarding, file permissions, and failure handling that could result in important evidence being lost during an attack.
Monitoring Security-Relevant SLES Events
Once SLES audit logging is enabled, the Cybersecurity Extension for SAP can monitor the audit trail for security-relevant operating-system events and generate actionable alerts.
These include changes to:
- Audit configuration
- SSH
- PAM
- Sudo
- Login settings
- Systemd
- Crontab
- Kernel configuration
- Network configuration
- SAP profiles
The solution can also detect:
- Failed file access
- Unauthorized permission changes
- File creation or modification attempts
- File-system mounts
- Software installation
- Kernel-module activity
- Privilege abuse
- Root command execution
- User and group administration
- Password changes
- Account locking and unlocking
- Suspicious scripts
- Malicious programs
- Code-injection indicators
- Replay attacks
- Changes to system-level security objects
Integrating SLES Alerts with SIEM Platforms
Alerts can be forwarded to SIEM platforms for correlation and investigation by the security operations centre.
This allows SLES activity to be analysed alongside:
- SAP application events
- SAP HANA database activity
- Authentication events
- Network events
- Endpoint telemetry
- Infrastructure activity
For example, a failed SAP host login can be correlated with SSH configuration changes, sudo activity, access to a secure-store directory, and subsequent execution of a privileged command.
This cross-layer visibility helps analysts identify attack sequences that may not be apparent when operating-system and SAP logs are reviewed separately.
Detecting and Responding to Ransomware
The Cybersecurity Extension for SAP can help detect ransomware activity on SLES by monitoring operating-system events associated with initial access, malware execution, privilege escalation, persistence, and file manipulation.
Relevant alerts include:
- Unexpected external connections
- Failed file access
- Unsuccessful file creation or modification
- Unexpected file-system mounts
- Malicious program execution
- OS code injection
- Root access
- Systemd changes
- Files being modified, renamed, or deleted
These events can reveal suspicious behaviour before SAP services or data are significantly affected.
While individual events may result from legitimate administration, their value increases when correlated chronologically. For example, an external connection followed by root access, malicious program execution, systemd modification, and widespread file changes would present a strong indication of potentially malicious activity.
Forwarding these alerts to a SIEM allows security teams to correlate SLES activity with SAP, HANA, identity, endpoint, and network events, supporting earlier ransomware detection and faster incident response.
Conclusion
By combining configuration assessment, sensitive-file protection, port and service detection, security hardening, audit-log monitoring, ransomware protection, and SIEM integration, the Cybersecurity Extension for SAP helps organizations manage SLES security as an integral part of SAP cybersecurity.
It provides the continuous visibility required to reduce operating-system exposure, detect unauthorized activity, support compliance, and protect the underlying platform on which critical SAP business processes depend.
Frequently Asked Questions
1. Why is operating-system security important for SAP systems?
SAP applications rely on the operating system to manage processes, files, user accounts, network connections, services, and access to sensitive data. Weaknesses at the OS layer can allow attackers to bypass application-level controls, disrupt SAP services, steal credentials, or compromise critical business information.
2. Why is SUSE Linux Enterprise Server widely used for SAP workloads?
SUSE Linux Enterprise Server is widely used for SAP HANA and SAP S/4HANA because of its longstanding alignment with SAP technologies, performance optimization, high-availability capabilities, enterprise support, and availability of an SAP-specific distribution.
3. Which SAP and HANA files require the strongest protection?
Sensitive resources include SAP system profiles, PSE certificate files, ABAP and HANA secure stores, HANA INI configuration files, SAP and HANA executables, service-account SSH keys, sudo configurations, and system startup definitions. Access should be restricted through appropriate ownership, permissions, monitoring, and change control.
4. Which ports should be open on a SLES server supporting SAP?
Only ports required for documented SAP communications, approved infrastructure services, and authorized administration should be open. Examples may include instance-specific SAP dispatcher, gateway, message server, HTTP, HTTPS, and SAP HANA ports. Access should be limited to trusted systems, interfaces, and network zones.
5. Should every port on a security blacklist be closed?
No. Some ports commonly included in security review lists may support legitimate services such as SSH, DNS, NTP, LDAP, HTTPS, or SAP HANA. Administrators should identify the process using each port, validate the business requirement, restrict its exposure, and close it when it is unnecessary.
6. What are the most important SLES hardening controls for SAP?
Key controls include timely patching, removal of unnecessary packages and services, secure SSH configuration, strong authentication, least-privilege administration, restrictive file permissions, host-firewall enforcement, AppArmor protection, secure mount options, boot protection, logging, and file-integrity monitoring.
7. How should privileged access be managed on SAP hosts?
Administrators should use unique named accounts and controlled sudo privileges instead of shared root access. Direct root login, empty passwords, unrestricted NOPASSWD rules, and unnecessary interactive access for system accounts should be prohibited. Multifactor authentication should be considered for high-risk administrative access.
8. What is the role of auditd in SLES security monitoring?
The Linux Audit Framework and auditd record security-relevant activity such as privileged command execution, authentication events, user and group changes, file-access failures, permission changes, kernel-module activity, and modifications to critical configurations. Audit records provide evidence for threat detection, investigation, and compliance.
9. Where are SLES audit records stored?
Audit records are normally stored in /var/log/audit/audit.log. Organizations should protect this directory with restrictive permissions, sufficient storage, log rotation, and defined actions for low-space or disk-full conditions. Logs should also be forwarded to a protected central platform or SIEM.
10. How does file-integrity monitoring support SAP security?
Tools such as AIDE can detect unauthorized changes to SAP profiles, HANA configuration files, certificates, secure stores, operating-system binaries, audit tools, SSH settings, and startup files. Monitoring should account for approved changes introduced by patching, maintenance, and certificate renewal.
11. How does the Cybersecurity Extension for SAP support SLES hardening?
The Cybersecurity Extension for SAP assesses SLES configurations across authentication, SSH, privileged access, file permissions, networking, patching, cryptography, audit logging, AppArmor, file-integrity monitoring, and other security areas. It also reviews permissions on sensitive SAP, HANA, and operating-system resources and identifies potentially vulnerable ports and services.
12. What SLES security events can the Cybersecurity Extension for SAP detect?
The solution can monitor for changes to SAP profiles, SSH, PAM, sudo, systemd, crontab, kernel, network, and audit configurations. It can also identify failed access attempts, privilege abuse, root command execution, suspicious scripts, malicious programs, code-injection indicators, account changes, software installation, file modifications, and kernel-module activity.
13. Can SLES security alerts be forwarded to a SIEM?
Yes. Alerts can be forwarded to SIEM platforms for monitoring and investigation by the security operations centre. This allows SLES events to be correlated with SAP application, SAP HANA, authentication, network, and infrastructure activity to identify cross-layer attack sequences.
14. How often should organizations review SLES security controls?
SLES security should be monitored continuously and reassessed after operating-system upgrades, SAP maintenance, architecture changes, new integrations, firewall modifications, and changes to administrative access. Periodic reviews alone may not identify unauthorized activity or configuration drift quickly enough.
15. What is the main benefit of integrating SLES monitoring with SAP security?
Integrated monitoring provides visibility across the operating system, database, and application layers. This helps organizations reduce their attack surface, identify suspicious activity earlier, improve incident investigation, support compliance, and strengthen the resilience of business-critical SAP systems.
16. How does SLES monitoring help protect SAP systems from ransomware?
SLES monitoring can help detect ransomware by identifying operating-system activity associated with initial access, privilege escalation, malware execution, persistence, and file encryption.
The Cybersecurity Extension for SAP monitors events such as unexpected external connections, malicious program execution, root access, code injection, systemd changes, file-system mounts, failed file access, and files being modified, renamed, or deleted.
Correlating these alerts and forwarding them to a SIEM can help security teams identify ransomware attack patterns earlier, investigate affected SAP hosts, and respond before critical SAP data and services are significantly disrupted.
This structure separates the article into distinct sections for operating-system risk, network security, SLES hardening, audit configuration, Cybersecurity Extension for SAP capabilities, ransomware protection, and frequently asked questions.