RFC Gateway security, part 4 - prxyinfo ACL

[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.

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 a section about the location of the prxyinfo ACL file and for the new profile parameter gw/acl_mode_proxy.
2021-11-10: Added Part 7: Secure communication
2021-10-12: Updated the whole blogpost.

---

prxyinfo 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 reginfo ACL stored?

The location of the prxyinfo ACL file is specified by the profile parameter gw/prxy_info.

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

The prxyinfo ACL contains rules related to 'Proxy to other RFC Gateways'.

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 source is allowed to proxy. This is defined in SOURCE=.
   
   
   • which target is allowed to be reached. This is defined in DEST=.
   
   
   
   

What is proxying about?

The RFC Gateway allows to proxy requests from any RFC clients to ABAP RFC-enabled function modules as well as to registered external RFC Server programs.

As soon as any RFC Gateway is maintained as a proxy in a remote destination, the request will be proxied. In this case, "any" could be an RFC Gateway of the same system, an RFC Gateway of another application server of the same system, an RFC Gateway of a foreign system, or a stand-alone RFC Gateway.

Please note: For SAP NW AS ABAP, if no RFC Gateway is maintained as a proxy (see screenshot below) the request is directly processed by the application server's local RFC Gateway and no proxying is involved at all.

What is the strong gw/proxy_check about?

In the older days, the prxyinfo ACL was only checked if the endpoint was an ABAP RFC enabled function module. In 2014 SAP introduced the so-called strong gw/proxy_check, which can be controlled in the profile parameter gw/reg_no_conn_info. With this, the prxyinfo ACL is also evaluated if the end point is a registered external RFC Server program.

Nowadays this feature is enabled by default.

Are there any default/internal rules?

As pointed out in part 2 and part 3 of this series, for the reginfo and secinfo, SAP delivers a feature to provide a basic set of rules which can be enabled by the profile parameter gw/acl_mode.

A similar feature is also available for the prxyinfo. It is controlled by the profile parameter gw/acl_mode_proxy.

The following rules are generated when gw/acl_mode_proxy = 1 is set but no custom prxyinfo was defined.:

P SOURCE=internal DEST=*

P SOURCE=local    DEST=*

 

Depending on the SAP Kernel Version this feature is enabled by default.

What are common use-cases?

Proxying calls to an external RFC Server program which is registered on any RFC Gateway of the same system

In some scenarios, an external RFC Server program like SAP TREX is registered only at one RFC Gateway of a multi-application server system.

In this case, the remote destination is created in SM59 and the RFC Gateway used to communicate with the external RFC Server program is specified in the remote destination:

With this, each request will be sent to the defined RFC Gateway and this RFC Gateway will establish the communication with the external RFC Server program. In other words this RFC Gateway will be used as proxy towards the external RFC Server program.

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

P SOURCE=internal,local DEST=local

To identify if a RFC Gateway is used to proxy requests, we have to look at the log files of the RFC Gateway and search for ‘prxyinfo accepted:’ or ‘prxyinfo denied:’, e.g.,:

Please note: In the logs shown above the request goes to an external RFC Server program registered to the proxying RFC Gateway itself. Therefore, the target is displayed as %%RFCSERVER%%(0.0.0.0).

If the relevant rule is missing, the following error will be displayed for the connection attempt:

 

Proxying calls to an external RFC Server program registered on a stand-alone RFC Gateway

In some scenarios, an external RFC Server program like a TAX software is registered at a stand-alone RFC Gateway and is consumed by different RFC clients.

In this case, the remote destination is created in SM59 and the stand-alone RFC Gateway is specified to establish the communication with the external RFC Server program:

With this, each request will be sent to the defined RFC Gateway and this RFC Gateway will establish the communication with the end point. In other words, this RFC Gateway will be used as proxy towards the external RFC Server program.

For this scenario, a custom rule in the prxyinfo ACL of the stand-alone RFC Gateway would be necessary, e.g.,

P SOURCE=<RFC-client-1>,<RFC-client-n> DEST=local

 

Proxying calls to ABAP RFC-enabled function modules

In contrast to the previous cases, the RFC Gateway may also be used to circumvent network level restrictions. For example, the SAP system 'SRC' cannot directly connect to the SAP system 'TGT'. The system 'SRC' can connect to the RFC Gateway 'PXY'. The RFC Gateway 'PXY'  is allowed to connect to system 'TGT'. In this scenario system 'SRC' may proxy requests via 'PXY' to the target system 'TGT'.

Please note: The RFC Gateway 'PXY' may be either a stand-alone RFC Gateway or the RFC gateway of another SAP NW AS ABAP.

To identify this use case on system 'SRC', we can look for any connection in transaction SM59 with ‘Gateway Host’ different to the IP address or hostname of any application server of the same system where the 'Target Host' is not directly accessible from at least one of the application servers of the same system, e.g.,:

NPL:192.168.75.135, PXY: 192.168.75.131, TGT: 192.168.75.139

 

To identify if a RFC Gateway is used to proxy requests, we have to look at the gateway logs and search for ‘prxyinfo accepted:’ or ‘prxyinfo denied:’, for example in the gateway logs of PXY we can find the following:

For this scenario, a custom rule in the prxyinfo ACL of the stand-alone RFC Gateway would be necessary, e.g.,

P SOURCE=<hosts-SRC> DEST=<hosts-TGT>

 

 

SAP introduced an internal rule for the prxyinfo ACL to allow all proxying by default:

P SOURCE=* DEST=*

Please note: This rule is applied when no custom prxyinfo ACL was defined!

 

EDIT: A new feature for improving the system security was introduced which enables that the following rules are generated when gw/acl_mode_proxy = 1 is set but no custom prxyinfo was defined:

P SOURCE=internal DEST=*

P SOURCE=local    DEST=*

 

 

---

<--Previous

Next -->