From my experience the RFC Gateway security is for many SAP Administrators still a not well understood topic. As a result many SAP systems lack for example of proper defined ACLs to prevent malicious use.

After an attack vector was published in the talk “SAP Gateway to Heaven” from Mathieu Geli and Dmitry Chastuhin at OPDCA 2019 Dubai (https://github.com/gelim/sap_ms) the RFC Gateway security is even more important than ever. This publication got considerable public attention as 10KBLAZE.

With this blogpost series i try to give a comprehensive explanation of the RFC Gateway Security:

Part 1: General questions about the RFC Gateway and RFC Gateway security.
Part 2: reginfo ACL in detail.
Part 3: secinfo ACL in detail.
Part 4: prxyinfo ACL in detail.
Part 5: ACLs and the RFC Gateway security.
Part 6: RFC Gateway Logging.
Part 7: Secure communication
Part 8: OS command execution using sapxpg
Part 9: enhanced security for sapxpg

Updates:

2023-03-21: Added Part 9: enhanced security for sapxpg2023-02-28: Added Part 8: OS command execution using sapxpg
2023-02-06: Added section about the location of the secinfo ACL file.
2021-11-10: Added Part 7: Secure communication
2021-03-17: Rephrased some sections to be more precise.

secinfo ACL

Please make sure you have read at least part 1 of this series to be familiar with the basics of the RFC Gateway and the terms i use to describe things.

Where is the secinfo ACL stored?

The location of the secinfo ACL file is specified by the profile parameter gw/sec_info.

What exactly is defined in the rules in the secinfo ACL?

The secinfo ACL contains rules related to ‘Started external RFC Servers’.

Every line corresponds one rule. A rule defines

1. • if it specifies a permit or a deny. This is defined by the letter P or Dat the beginning of a rule.
   • which user is allowed to start a program. This is defined in USER=.
     

     Please note: If a rule should be restricted to certain users please be aware that for ‘USER’ it is not possible to maintain a comma separated list. Instead separate rules must be created.

   • from which RFC client can this be initiated. This is specified in USER-HOST=.
   • the remote host on which the executable is to be started. This is defined in HOST=.
   • the executable which will be executed on the OS level with the permissions of either the OS user running the RFC Gateway process or the credentials of an SAP user. This is defined in TP= based on the executable name or its fullpath (e.g., if it is not in $PATH).

What are the common use cases?

Starting external programs on the local RFC Gateway

On SAP NetWeaver AS ABAP starting external programs by the local RFC Gateways is commonly used. For example the STMS calls the executable ‘tp’ during transport management, transaction SM49/SM69 calls ‘sapxpg’ to execute OS commands, or ‘saphttp’ is called to connect to content servers (if not switched to the ICM plugin as described in SAP note 2570180).

To identify this use case we can look for TCP/IP connections with “Technical Setting” – “Activation Type = Start on Application Server”:

We can verify this during runtime by going to transaction SMGW and look for the active connections:

or by going to “Logged on Clients” and looking for lines with “System Type = External Client” and “Gateway Host = 127.0.0.1” (in some cases this may be any other IP address or hostname of a server of the same system). The related program name can be found in column ‘TP Name’:

Please note: ‘SAPXPG’ has a special behavior: Whenever a command is executed in SM49/SM69 a temporary TCP/TP connection named ‘%_TCPIP_%<n>’ will be created with the program name ‘/usr/sap/$SAPSYSTEMNAME/<Instance-Name>/exe/sapxpg’ and the actual command as parameters. After execution this temporary TCP/IP connection will be deleted.

Since these programs are shown only during their execution it would be a better approach to look into the log files of the RFC Gateway and search for ‘secinfo accepted:’ or ‘secinfo denied:’ to identify which programs have been called in the past, e.g.,:

SAP introduced an internal rule in the secinfo ACL to allow the starting of any programs on the same server :

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

This rule is generated when gw/acl_mode = 1 is set but no custom secinfo ACL was defined.

It is common to define this rule also in a custom reginfo file as the last rule.

Starting external programs on a remote host

The RFC Gateway allows to connect to remote hosts using SSH or remote shell (depending on the configuration in the corresponding TCP/IP connection and the value of parameter ‘gw/rem_start’) to execute programs on it.

Please note: Additional setup is necessary to allow SSH or remote shell connections to be made from the sidadm to the remote server.

To identify this use case we can look for TCP/IP connections with “Technical Setting” – “Activation Type = Start on Explicit Host” and a “Target Host” different from hosts of the application servers of the same system.

For this scenario a custom rule in the secinfo ACL would be necessary, e.g.,

P USER=<username> USER-HOST=internal,local,<rfc-client-host> HOST=<target-host> TP=<TP-Name>

Please note: This use case is very uncommon. So, SAP recommends to set the value of the parameter ‘gw/rem_start’ to ‘DISABLED’.

 

Starting external programs on a remote RFC Gateway

RFC clients can also connect to a remote RFC Gateway using RFC or SNC to start programs on its host.

To identify use cases for starting external programs via remote RFC Gateways from our AS ABAP we can look for TCP/IP connections with “Technical Setting” –  “Activation Type = Start on Explicit Host” and a “Target Host” as well as “Gateway Host” different from the IP address or hostname of any application server of the same system.

For this scenario acustom rule in the secinfo ACL of the remote RFC Gateway would be necessary, e.g.,

P USER=<username> USER-HOST=<AS-host>,<rfc-client-host> HOST=local TP=<TP-Name>

Please note: sapxpg implements a special feature for starting programs/scripts or executing commands on OS level. This is described in part 8 of this series.

<–Previous

Next –>