RFC Gateway security, part 1 - basic understanding

[JoeGoerlich]

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 of the RFC Gateway.

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: Security considerations related to these ACLs.
Part 6: RFC Gateway Logging.
Part 7: Secure communication
Part 8: OS command execution using sapxpg
Part 9: enhanced security for sapxpg

Updates:

2023-11-15: Added usage type 'extern-to-extern RFC communication with JCo 3.x'
2023-03-21: Added Part 9: enhanced security for sapxpg
2023-02-28: Added Part 8: OS command execution using sapxpg
2021-11-10: Added Part 7: Secure communication

---

Basic understanding

 

In the following i will do the question and answer game to develop a basic understanding of the RFC Gateway, the RFC Gateway security and its related terms.

What is the RFC Gateway?

The RFC Gateway can be seen as a communication middleware. The RFC Gateway act as an RFC Server which enables RFC function modules to be used by RFC clients. It also enables communication between work or server processes of SAP NetWeaver AS and external programs.

From a technical perspective the RFC Gateway is a SAP kernel process (gwrd, gwrd.exe) running on OS level as user <sapsid>adm.

Where can we find the RFC Gateway?

There are three places where we can find an RFC Gateway:

1. 
   
   
   
   • In SAP NetWeaver Application Server ABAP: Every Application Server has a built-in RFC Gateway.
   
   
   • In SAP NetWeaver Application Server Java: The SCS instance has a built-in RFC Gateway.
   
   
   • The Stand-alone RFC Gateway: As a dedicated RFC Gateway serving for various RFC clients or as an additional component which may be used to extend a SAP NW AS ABAP or AS Java system.
   
   
   
   

Who can access the RFC Gateway in general

The RFC Gateway is by default reachable via the services 'sapgw<InstNo>' and 'sapgw<InstNo>s' which can be mapped to the ports '33<InstNo>' and '48<InstNo>'. Access to this ports is typically restricted on network level.

There may also be an ACL in place which controls access on application level. The location of this ACL can be defined by parameter 'gw/acl_file'.

Which usage types are there?

 

This diagram shows all use-cases except `Proxy to other RFC Gateways´. The subsequent blogs of will describe each individually.

 

'Registered external RFC Servers'

The RFC Gateway allows 'external RFC Server programs' (also known as 'Registered Server' or 'Registered Server Program') to register to itself and allows RFC clients to consume the functions offered by these programs.

An example would be 'Trex_<SID>_<timestamp>' registered at the RFC Gateway of the SAP NW AS ABAP from the server running SAP TREX and consumed by the same AS ABAP as an RFC client.

Another example would be 'IGS.<SID>' of SAP IGS registered at the RFC Gateway of the SAP NW AS ABAP from the same server as AS ABAP (since it is also part of it) and consumed by the same AS ABAP as an RFC client.

'Started external RFC Servers'

The RFC Gateway is capable to start programs on the OS level.

Common examples are the program 'tp' for transport management via STMS started on the RFC Gateway host of AS ABAP or the program 'gnetx.exe' for the graphical screen painter started on the SAP GUI client host.

While typically remote servers start the to-be-registered program on the OS level by themselves, there may be cases where starting a program is used to register a 'Registered Server Program' at the RFC Gateway. In these cases the program started by the RFC Gateway may also be the program which tries to register to the same RFC Gateway.

Please note: One should be aware that starting a program using the RFC Gateway is an interactive task. This means the call of a program is always waiting for an answer before it times out. If the called program is not an RFC enabled program (compiled with the SAP RFC library) the call will time out, but the program is still left running on the OS level!
To overcome this issue the RFC enabled program 'SAPXPG' can be used as a wrapper to call any OS command. This is for example used by AS ABAP when starting external commands using transaction SM49/SM69.

'RFC destinations'

Most common use-case is the SAP-to-SAP communication, in other words communication via RFC connections between SAP NetWeaver AS systems, but also communication from RFC clients using the SAP Java Connector (JCo) or the SAP .NET Connector (NCo) to SAP NetWeaver systems.

The RFC Gateway hands over the request from the RFC client to the dispatcher which assigns it to a work process (AS ABAP) or to a server process (AS Java).

'Proxy to other RFC Gateways'

The RFC Gateway can be used to proxy requests to other RFC Gateways.

'extern-to-extern RFC communication with JCo 3.x'

As of JCo 3.0.10, there is also a use-case where a JCo based RFC Client communicates via the RFC Gateway with a JCo based registered external RFC server.

Please note: For security reasons, this usage type is not recommended. For more details, see SAP Note 1877907.

What about the reginfo ACL?

The reginfo file is holding rules controlling which remote servers (based on their hostname/ip-address) are allowed to either register, access or cancel which 'Registered Server Programs' (based on their program alias (also known as 'TP name')).

Its location is defined by parameter 'gw/reg_info'.
In case of AS ABAP for example it may be defined as '$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_REG_INFO)' to make sure all RFC Gateways of the application servers of the same system relay on the same configuration.

What about the secinfo ACL?

The secinfo file is holding rules controlling which programs (based on their executable name or fullpath, if not in $PATH) can be started by which user calling from which host(s) (based on its hostname/ip-address) on which RFC Gateway server(s) (based on their hostname/ip-address).

Its location is defined by parameter 'gw/sec_info'.
In case of AS ABAP for example it may be defined as '$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_SEC_INFO)' to make sure all RFC Gateways of the application servers of the same system relay on the same configuration.

How are reginfo and secinfo related?

As we learnt before the reginfo and secinfo are defining rules for very different use-cases, so they are not related.

What about the prxyinfo ACL?

The prxyinfo file is holding rules controlling which source systems (based on their hostname/ip-address) are allowed to talk to which destination systems (based on their hostname/ip-address) over the current RFC Gateway.

Its location is defined by parameter 'gw/prxy_info'.
In case of AS ABAP for example it may be defined as '$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_PRXY_INFO)' to make sure all RFC Gateways of the application servers of the same system relay on the same configuration.

What about the SNC System ACL?

RFCs between two SAP NetWeaver AS ABAP systems are typically controlled on network level only. The RFC Gateway does not perform any additional security checks.

When using SNC to secure RFC destinations on AS ABAP the so called 'SNC System ACL', also known as 'System Authentication', is introduced and must be maintained accordingly.

This ACL is applied on the ABAP layer and is maintained in transaction SNC0.

Please note: 'SNC System ACL' is not a feature of the RFC Gateway itself.

 

What about the SNC User ACL?

RFCs between RFC clients using JCo/NCo or Registered Server Programs and the AS ABAP are typically controlled on network level only. The RFC Gateway does not perform any additional security checks.

When using SNC to secure logon for RFC Clients or Registered Server Programs the so called 'Extended SNC Access Control List (ACL) for Users', also known as 'User Authentication', is introduced. With this, the AS ABAP verifies whether the RFC client is allowed to logon with the combination of username and SNC name sent in the connection attempt. The SNC name taken from the X.509 client certificate is used for the authentication in favor of password based logon.

This Extended SNC ACL for Users is applied on the ABAP layer and is maintained in table USRACLEXT, for example using transaction SM30.

The mapping of an SNC name to a user can also be done in transaction SU01. Keep in mind that in SU01 only a 1:1 mapping can be performed while in the table USRACLEXT more than one certificates can be mapped to one user.

Please note: 'SNC User ACL' is not a feature of the RFC Gateway itself.

---

 

Next -->