RFC Gateway security, part 7 - secure communication

[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

---

Secure communication

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

Does the RFC Gateway support encrypted communication?

The RFC Gateway supports encrypted communication for RFC using SNC (Secure Network Communication).

 

Does SNC require any additional license?

As of SAP note 1848999 there is no additional license required. SNC Client Encryption 2.0 is included in SAP NetWeaver.

An additional license is only required when SNC with SSO for SAP GUI or Web GUI for end-users shall be provided. This requires the SAP Secure Login Client which is part of the product SAP Single Sign-On 3.0.

 

What is needed for encrypting the traffic?

To establish SNC-protected RFC communication a cryptographic library must be installed on both communication partners, for example, the SAP CommonCryptoLib 8.

The server and client must possess a public and private key pair and a public key certificate, which is stored in a Personal Security Environment (PSE). Typically, the SNC PSE stored at  $SECUDIR/SAPSNCS.pse is used.

Furthermore, both parties must be able to validate the counterparts certificates, which includes the validation of its trust-chain. Therefore, the trusted Issuing CAs have to be stored in the PSE.

More details on the CCL integration for SNC can be found at CommonCryptoLib: SNC protocol versions and cipher suites.

 

How to enable SNC

If the above prerequisites are fulfilled, the subject name of the certificate has to be configured as SNC Name in the profile parameter snc/identity/as.

SNC can then be enabled by the profile parameter snc/enable.

Secure RFC communication typically, but not necessarily, is established over port '48<InstNo>'. Therefore, there may be also some adjustments to the firewall necessary.

Please note: Some legacy interfaces do not allow to adjust the port and use '32<InstNo>' which is widely known as the port for unencrypted RFC communication.

 

How to manage trusted Issuing CAs?

This can be done via the command line tool sapgenpse maintain_pk. For ABAP systems the trust manager STRUST, for Java systems the Certificates and Keys (/nwa/key-storage) should be used instead.

Please note: Trusting a Root CA leads to trusting all sub-CAs. This should be strongly avoided.

 

Does the usage type 'Registered external RFC Servers' support encrypted communication?

Encrypted communication can be enabled or enforced for the different scenarios by the profile  parameter snc/only_encrypted_rfc.

Please note: The value of this profile parameter may also affect RFC connections from ABAP to ABAP or internal RFC connections between application servers of the same system.

Does the usage type 'Started external RFC Servers' support encrypted communication?

Encrypted communication can be enforced by the profile parameter snc/permit_insecure_start.

 

SNC System ACL (SNCSYSACL)

For SNC-protected RFC connections between AS ABAP systems, the SNC system access control list in table SNCSYSACL has to be maintained, for example, using transaction SNC0.

 

SNC User ACL (USRACLEXT)

For SNC-protected RFC connections from RFC Client or Registered Server Programs to the RFC Gateway, the SNC user access control list in table USRACLEXT has to be maintained if the SNC name from the RFC program does not correspond to the SNC name in the specified user's master record in the designated client. For example, using transaction SM30.

To allow password less authentication either the SNC Name has to match the SNC Name in the corresponding user's master record or an entry in the table USRACLEXT for the corresponding client with a matching user and SNC name combination exists.

If a matching entry in USRACLEXT has a wildcard for user or SNC Name or both, the system verifies the user's password.

 

What if a legacy component does not support SNC?

If SNC can not be used for some reasons in a scenario (which is rarely the case), a mitigation could be to establish the connection over a secure tunnel initiated between two SAP Routers. Be aware that this is not an end-to-end encryption, especially if you are not in control over the architecture on one of both sides .

 

How to setup the CommonCryptoLib for secure communication?

Details on the CCL configuration options for SNC in terms of protocols, cipher suites and more can be found at CommonCryptoLib: SNC protocol versions and cipher suites.

 

---

<--Previous

Next -->