RFC Gateway security, part 7 – secure communication
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
2023-03-21: Added Part 9: enhanced security for sapxpg2023-02-28: Added Part 8: OS command execution using sapxpg
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 can then be enabled by the profile parameter
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
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 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 USERACLEXT 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.
Thanks for the wonderful blogs!
I have a question related to SNC encryption. Our basis team has implemented Single Sign-On using the NTLM-based GSS API library. As part of the SOC team, we need to implement a strategy to create SNC-based RFC connections for securing the interfaces. Is it possible to utilize NTLM libraries to encrypt the RFC connections through SNC?
Hello Nipun Mahajan ,
as NTLM can not be considered secure you should switch to Kerberos, if applicable. Please be aware that the CommonCryptoLib 8.5 supports both, Kerberos and X.509 based authentication.
Then you may have a look at SAP note 1696905. With this your domain joined server may use kerberos and other may use X.509 certificates to establish secure connections.
Will have to work with the Basis team to determine the impact of switching to Kerbereos. Thanks!
I am trying to analyze the significance of SNC-based RFC communication. What's the advantage of encrypting the RFC using SNC over utilizing a VPN for secure communication with 3rd party applications. Any thoughts here?
SNC-based RFC communication provides end-to-end encryption between two systems. It helps to protect confidentiality as well as integrity from the client to the server and vice versa. You have full control over the utilized encryption algorithms as described in https://blogs.sap.com/2021/11/05/commoncryptolib-snc-protocol-versions-and-cipher-suites.
For example, in some scenarios you do not have any control over the network of your interface partner. In such cases you should prefer SNC-based RFC communication between client and server rather then trusting the partner that his network architecture behind the VPN endpoint prevents from eavesdropping.
As SNC comes without further license costs, it may also be a reason using SNC in favour of a costly VPN solution. Maintaining a VPN endpoint on both sides would add an additional layer of complexity.
SNC can also be used to create a secure channel between two SAP routers like a VPN. With this you still can decide to additionally use SNC-based RFC communication between the endpoints through the secure tunnel.
In general SNC for RFC is comparable to TLS for HTTP. You may use plain HTTP over a VPN, you may intercept HTTPS on the proxy and forward the responses to the client via unencrypted HTTP or you may use end-to-end HTTPS connections. It depends on your architecture and security posture to decide what is necessary.
Thanks for the detailed reply. End to End encryption will certainly make a difference over choosing a VPN connection.