Skip to Content
Technical Articles

10KBLAZE and SAP ( From an administrative point )

I am sure everyone by now would have read tons of articles on ‘ how to make your SAP systems secure ‘ specially after the recent published article by Onapsis on 10KBLAZE.This article focusses on specifics of what steps we need/can take to safeguard our SAP systems.

If you want to read detailed study of Onapsis report please see this link here .

An important thing to know is the affected systems can also S/4 HANA on premise versions.

I will divide the blog into 2 parts.

Part A will be about security of the gateway.

Part B  will deal with the security of Message server

 

Part A : The SAP gateway ( and its security )

 

Here I will point out what exactly you need to take care for securing your SAP gateway.

1>. Check the Early Watch Alert (EWA).There will be section in EWA which mentions about settings of reg_info and sec_info.Take the results of EWA seriously and follow the suggestions by EWA.
See SAP note : 863362 – Security checks in SAP EarlyWatch Alert, EarlyWatch and GoingLive sessions .

2>. Check profile parameter gw/acl_mode.  It needs to be set to 1 ( link for parameter description : gw/acl_mode ).

3 >. The file secinfo and reginfo must exists. You should carefully check each sub parameter in secinfo file example : USER-HOST=<value>. There should not be entries which are unwanted and take care that wild-card ( ‘ * ‘) are not present.

Setup a secinfo file as in the link : secinfo

It should contain entries :

  P TP=* USER=* USER-HOST=local HOST=local
  P TP=* USER=* USER-HOST=internal HOST=internal

but no other entries with wildcards for USER-HOST

4>. Set parameter gw/reg_no_conn_info=255 in DEFAULT.PFL

5>. To make the settings of reginfo and secinfo please see the latest revised and updated SAP note ( it also includes CVSS score ) : 1408081 – Basic settings for reg_info and sec_info

While making the changes in reginfo and secinfo there will always be a threat that whilst making any changes the existing registrations of programs might get disrupted and cause connections to fail and RFC’s generating errors.

To find out which connections to let enter the gateway and which to deny you can use the gateway logging. Please set gw/sim_mode to 1. ( Everything will be permitted ). But extra information will be written to trace file on denied attempts which are only allowed due to gw/sim_mode.
Start gw/logging to log all sec_info and reg_info actions with gw/logging = ACTION=SsMPXZ LOGFILE=gw_log-%y-%m-%d SWITCHTF=day MAXSIZEKB=1000 MAXFILES=50

 

There is an excellent SAP security document , please check it here : Securing Remote Function Calls (RFC).

Apart from this SAP releases official security notes which help in making the SAP system more secure , see link here.

Helpful / Reference notes :

1408081 – Basic settings for reg_info and sec_info

614971 – GW: Changes to the ACL list of the gateway (secinfo)

1592493 – GW: Problems in “reginfo” configuration

1425765 – Generating sec_info reg_info

Wiki links / Help portal links :

Configuring Connections between Gateway and External Programs Securely

Security Parameters of the Gateway

Part B : The SAP Message server

Reading the report published by Onapsis I came to know the threat was not a coding related but rather administrative misconfigurations of SAP NetWeaver installations ( based on Netweaver releases and older releases as well ).
When I say administrative it straight points towards parameters. So , which parameters exactly ?

The important parameters that are related to the security of message server and which must be setup correctly to avoid this attack ( 10KBLAZE ) are :

– rdisp/msserv_internal

– rdisp/msserv

– ms/acl_info

 

There are some other parameters as well : ms/acl_file_admin, ms/acl_file_ext, ms/acl_file_extbnd, and ms/acl_file_int .

More details about the parameters are given in the link  here : Security Settings for the SAP Message Server

What precautions to take ?

 

1>. Ensure that parameters rdisp/msserv and rdisp/msserv_internal point to different ports. They must * NOT * point to same port.

What will happen if rdisp/msserv and rdisp/msserv_internal = same port ?

External clients must have read-only access and must not have right to modify/write the data. In this case if ports are same then external clients can pose as internal clients and access the application server an make unwanted changes in the system.

2>. Ensure the port number indicated by rdisp/msserv_internal is not exposed to untrusted networks and you give ports checked thoroughly by your network team.

3>. The end-users do not need access to this port , this is defined with 39XX ( XX = instance number of SAP system ). This port must be blocked by firewall so that no unwanted or external applications can access this port.
External clients and servers should not be able to bypass the firewall to access the message server host.

4>. Configure the packet filter in such a way that it permits accesses to the internal port of the message server from exactly those hosts on which an application server of the relevant system runs or can run. If no packet filter is available on the host of the message server, set up an external firewall with the relevant rules.

“The famous ACL list “

The “ms/acl_info” parameter specifies a file (default: /usr/sap/<SID>/SYS/global/ms_acl_info) with access rights to the message server. If the file exists, it must contain all machine names, domains, IP addresses and/or subnet masks for the application servers that are allowed to log on to the message server.

An example content of the file would look like:

The entries must have the following syntax:

HOST=[*| ip_adr | host_name | Subnet_mask | Domain ] [, …]

Examples for valid entries are:
HOST = * (all hosts are allowed)
HOST=host1,host2 (Logons allowed from host1 and host2)
HOST=*.sap.com (all hosts in the sap.com domain can log on)
HOST=10.10.10.0 (hosts with this IP address can log on)
HOST=20.20.20.* (hosts with this subnet can log on)

 

This link provides a nice overview of syntax of acl file .

 

What about parameters ms/monitor and ms/admin_port ?

ms/monitor  – With parameter ms/monitor you can specify that only application servers can modify the internal status of the message server. The external msmon monitoring program then has restricted access.
Set it to 0.

ms/admin_port – This port is used to open and close TCP ports of the message server for administration. An external client can connect to the message server through this port to carry out administration tasks on the message server. By default, administration from external programs is deactivated (ms/monitor = 0).

Helpful SAP notes :

1421005 – Secure configuration of the message server

821875 – Security settings in the message server

1504652 – Consulting: Secure Configuration of Application Server ABAP

Portal links :

Security Settings for the SAP Message Server

Syntax of the ACL File

 

Hope this helps.

 

Kind regards,

Manjunath Hanmantgad

3 Comments
You must be Logged on to comment or reply to a post.