RFC Gateway security, part 2 - reginfo 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 sapxpg
2023-02-28: Added Part 8: OS command execution using sapxpg
2023-02-06: Added section about the location of the reginfo ACL file.
2021-11-10: Added Part 7: Secure communication
2021-03-17: Rephrased some sections to be more precise. Updated images.

---

reginfo 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 reginfo ACL file is specified by the profile parameter gw/reg_info.

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

The reginfo ACL contains rules related to 'Registered external RFC Servers'.

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 servers are allowed to register which program aliases as a 'Registered external RFC Server'. This is defined in HOST=.
    

    Please note: In most cases the registered program name differs from the actual name of the executable program on OS level. The related program alias also known as 'TP Name' is used to register a program at the RFC Gateway.

    
    
  
  
  • which RFC clients are allowed to talk to the 'Registered Server Program'. This is defined in ACCESS=.
  
  
  • which servers are allowed to cancel or de-register the 'Registered Server Program'. This is defined in CANCEL=.
  
  
  • how many 'Registered Server Programs' with the same name can be registered. This could be defined in NO=.
  
  
  
  

What are the common use cases?

Registering external programs by and accessing them from the local application server

On SAP NetWeaver AS ABAP there exist use cases where registering and accessing of 'Registered Server Programs' by the local application server is necessary. In other words the same host running the ABAP system is also running the SAP IGS, for example the integrated IGS (as part of SAP NW AS ABAP) may be started on the application server's host during the start procedure of the ABAP system. It registers itself with the program alias 'IGS.<SID>' at the RFC Gateway of the same application server. Its functions are then used by the ABAP system on the same host.

We can identify these use cases by going to transaction SMGW -> "Goto" -> "Logged on Clients" and looking for lines with 'System Type = Registered Server' and 'Gateway Host = 127.0.0.1' (in some cases this may be any other IP address or hostname of any application server of the same system). The related program alias can be found in column 'TP Name':

We can verify if the functionality of these Registered RFC Server Programs is accessible from the AS ABAP by looking for a TCP/IP connection in transaction SM59 with "Technical Settings" - "Activation Type = Registered Server Program" the corresponding 'Program ID' and either no 'Gateway Options' or connection details to any of the RFC Gateways belonging to the same system set:

 

SAP introduced an internal rule in the reginfo ACL to cover these cases:

P TP=* HOST=internal,local ACCESS=internal,local CANCEL=internal,local

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

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

 

Registering external programs by remote servers and accessing them from the local application server

On SAP NetWeaver AS ABAP registering ‘Registered Server Programs’ by remote servers may be used to integrate 3rd party technologies. In other words the host running the ABAP system differs from the host running the Registered Server Program, for example the SAP TREX server will register the program alias ‘Trex_<SID>_<timestamp>’ at the RFC Gateway of an application server.

We can identify these use cases by going to transaction SMGW -> "Goto" -> "Logged on Clients" and looking for programs listed with 'System Type = Registered Server' and 'Gateway Host' set to any IP address or hostname not belonging to any application server of the same system. The related program alias can be found in column 'TP Name':

We can verify if the functionality of these Registered RFC Server programs is accessible from the AS ABAP by looking for a TCP/IP connection in transaction SM59 with "Technical Settings" - "Activation Type = Registered Server Program" the corresponding 'Program ID' and either no 'Gateway Options' or connection details to any of the RFC Gateways belonging to the same system set:

Please note: If the AS ABAP system has more than one application servers and therefore also more than one RFC Gateways there may be scenarios in which the 'Registered Server Program' is registered at one specific RFC Gateway only. In this case the 'Gateway Options' must point to exactly this RFC Gateway host. If the 'Gateway Options' are not specified the AS will try to connect to the RFC Gateway running on the same host.

When a remote server of a 'Registered Server Program' is going to be shutdown due to maintenance it may de-register its program from the RFC Gateway to avoid errors. In some cases any application server of the same system may also need to de-register a 'Registered Server Program', for example if the reginfo ACL was adjusted for the same 'Registered Server Program' or if the remote server crashed.

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

P TP=<TP-Name> HOST=<rfc-server> ACCESS=internal,local CANCEL=internal,local,<rfc-server>

 

Registering external programs at a standalone RFC Gateway by remote servers and accessing them from various RFC clients

'Registered Server Programs' at a standalone RFC Gateway may be used to integrate 3rd party technologies. An example could be the integration of a TAX software.

For a RFC Gateway of AS Java or a stand-alone RFC Gateway this can be determined with the command-line tool gwmon by running the command gwmon nr=<InstNo> pf=<profile> then going to the menu by typing m and displaying the client table by typing 3.

We can look for programs listed with 'Type = REGISTER_TP' and field 'ADDR' set to any IP address or hostname not belonging to any application server of the same system. The related program alias can be found in column 'TP':

We can identify RFC clients which consume these 'Registered Server Programs' by corresponding entries in the gateway log.

Again when a remote server of a 'Registered Server Program' is going to be shutdown due to maintenance it may de-register its program from the RFC Gateway to avoid errors. But also in some cases the RFC Gateway itself may need to de-register a 'Registered Server Program', for example if the reginfo ACL was adjusted for the same 'Registered Server Program' or if the remote server crashed.

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

P TP=<TP-Name> HOST=<rfc-server> ACCESS=<rfc-client-1>,<rfc-client-2>,<rfc-client-3> CANCEL=<rfc-server>,local

 

---

<--Previous

Next -->