Skip to Content
Technical Articles
Author's profile photo Johannes Goerlich

RFC Gateway security, part 4 – prxyinfo ACL

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.

 

Updates:
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.

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

    • 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?

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.

What are common use-cases?

Proxying calls to an external RFC Server program which is registered on a RFC Gateway of another application server 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 end point 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 end point. In other words this RFC Gateway will be used as proxy towards the end point.

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 this case the request goes to an external RFC Server program registered to the proxying RFC Gateway. Therefore, the target is displayed as %%RFCSERVER%%(0.0.0.0).

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

 

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 end point:

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 end point.

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=internal,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%3A192.168.75.135%2C%20PXY%3A%20192.168.75.131%2C%20TGT%3A%20192.168.75.139

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!

 

 


<–Previous

Next –>

Assigned tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Isaias Freitas
      Isaias Freitas

      Hello Johannes, all,

      When the parameter "gw/reg_no_conn_info" includes the bitmask value 128, the proxy info ACL is also checked when the communication with registered programs is taking place.

      Read the SAP KBA 2464128 for more details. It also includes links to resources that explain how the parameter "gw/reg_no_conn_info" works.

      Cheers!

      Isaías

      Author's profile photo Johannes Goerlich
      Johannes Goerlich
      Blog Post Author

      Hello Isaías,

      thanks for your comment. It took a while but now I've updated the blogpost.

      Greets

      Joe

      Author's profile photo Isaias Freitas
      Isaias Freitas

      You are welcome! And thanks for updating the blog 🙂