In today's world of cyber-attacks and data leaks, security and encryption should be an absolute priority for any IT organisation. However, experience shows that this is not always the case. Mechanisms that bring security are still often seen as making work difficult and challenging to implement. The fact that a program was configured years before and there was never a problem is used as an excuse not to make changes. This is a very incorrect approach that can have serious consequences.
In this post, I will cover a topic perhaps quite niche for the SAP Basis administrator - securing connections from external non-SAP programs. An aspect that is often overlooked due to a gap in accountability. On the one hand, this is sometimes seen as outside the Basis scope. On the other hand, programs are sometimes configured by third party vendors not necessarily interested in the security of our system. I will try to show what we, as Basis administrators, can do to make the connection more secure.
In this post I will try to consider what mechanisms we can use to make an external connection secure. Of course, SNC/SSL-based encryption will be the focus as usual, but I will not limit myself to this technical aspect alone. As usual, I will also touch on topics that are on the borderline of responsibilities or even outside the typical scope of Basis, but important for understanding how the various mechanisms work.
I will discuss the topics of encryption, authentication using an SSL certificate, level of trust in a foreign CA, permissions, limiting network traffic. I will base my analysis on example programs from the SAP NetWeaver RFC SDK. I originally wanted to write my own simple program, but as Basis administrators we usually secure existing software and connections, so this is a more representative example.
My test environment is ABAP Platform Trial 1909, based on S/4HANA 1909. The system is not the youngest, nor is it the oldest, but in the field of RFC connection security, not that much has changed over the years. So most of the insights will be valid for both older and younger systems.
The system has already been prepped for SNC and certificate-based authentication. I described this in my previous post "SAP-GUI Single Sign-On based on SSL certificates and SNC", so I won't repeat that part.
For the purpose of presenting the client program, I prepared a completely fresh Debian Linux system version 12. The rfcuser user was also created, in the context of which we will run the program that connects to the SAP server. Of course, you can use another Linux distribution as well, or even Windows, and the results will be similar.
SAP Note 2573790 describes where to get the library and briefly describes the installation process. I assume you can download it yourself from the Software Download Center, and I will describe the simplest installation method in a moment. I get two files, which I decompress in the rfcuser home directory.
[...]
All files are located in nwrfcsdk folder. Next step is adding the folder to LD_LIBRARY_PATH environment variable. I can do this for current session, but to make this permanent, I add this to .profile file located in the user's home directory.
I plan to establish a connection from an external program to my SAP system to perform some operations. It is easy to guess that I will need a user on the SAP system side to do this. So I'm creating an RFC user that the external program will use for operations on the system. I give it the top-secret password secure123, just for the purpose of this presentation, to keep things simple.
In addition to filling in basic user data, I set up the type to system or communication. In this case, it doesn't matter much. I leave the rest of the data default, including the lack of authorizations, because I'll come back to that in the next step.
Together with the SDK library, we get two sample programs - rfcexec and startrfc. Rfcexec connects to the SAP gateway and waits for incoming commands from the SAP system. I leave it for another occasion for now and will focus on startrfc.
The program connects to SAP and execute one of two function modules, related to EDI or display system information. In fact, I will focus on the last function today. The -i switch is responsible for calling it.
Let's call the program:
Sandbox is my SAP server hostname 00 is SAP instance number. 001 is a productive client.
Error is expected. In general connection is successful, because program reached checking authorization phase.
Indisputably, the principle of least privilege is one of the most important elements of security and an absolute must when it comes to external connections. Keep in mind that a system is only as secure as its weakest component. Even if you secure your SAP system perfectly, an intrusion into a server independent of you that has rights to connect to SAP with a high level of privilege could result in data leakage or even damage to the system. So you should keep the level of RFC user privileges at the minimum level needed to operate. In fact, this should obviously apply to all users. However, for technical users, this rule is more often ignored for some reason. Do we trust programs more than people?
That's why I didn't give the RFCUSER any authorization at the beginning, and now I will build it from scratch. I check what the SU53 transaction reports for this user by selecting Authorization Values / Other User from the menu.
Apparently, the system first checked whether the user had access to the RFCPING function module. Since access was not explicitly granted, so the permissions for the entire SYST function group were also checked. Since I am very strict about permissions, I will build a role with minimal privileges in the PFCG tranaction.
I added this role to RFCUSER and repeated the connection test.
This time the connection is fully successful and I get system information. Authorization is sufficient.
At this point it is worth saying a few words about how my system is configured. This is, in fact, already described in my previous post, but it doesn't do any harm to remind you of the basic information. The main certificate authority (OU=Security) signed the certificates of intermediate authorities - for servers (OU=Servers) and for users (OU=Users). The SAP server certificate was issued by the first one.
It's clear that the simplest solution would be to issue a certificate by an existing certification authority, but that would simplify our considerations a bit too much. Instead, I will assume that the certificate was issued by a completely independent group of certification authorities. So I will add three new to the existing ones, marked in blue in the diagram.
I won't focus on details, because you can go through this proces in my previous post, but let's go to the process of CAs creation and issuing RFCUSER's certificate. In practice, SAP administrators are usually not responsible for this part, so if you are not interested in issuing certificates, you can skip without hesitation to the next chapter.
Root CA key creation:
Certificate generation:
Intermediate CA key:
Certificate signing request:
Certificate signature by the new root CA:
RFCUSER key creation:
Certificate signing request:
Client.cnf for client certificates:
Certificate signing:
Export certificate to PKCS12 format:
As a result I got several keys and certificates, including the most important rfcuser.p12 file, which contains user's private key and certificate with the trust chain. The file is protected with exportpassword123 password. In real life scenarion this file you'll receive from your certification team.
Ok, I know that forcing encrypted connections is not necessary for my connection to be encrypted. However, I will do it to show if the encryption works or not. Nevertheless, if you are ready to disable unsafe connections, I highly recommend making it permanent. In my case, the snc/only_encrypted_rfc parameter is sufficient, but you might consider setting a few others as well, such as snc/accept_insecure_cpic, snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/only_encrypted_gui.
I can set the parameter to 1, which enforces encryprion for non-ABAP RFC connections. Higher levels enforces encryption for ABAP and intenal connections.
Now the call should be rejected by the system.
It is no longer possible to establish an unencrypted connection.
To enable RFC connection encryption, it is necessary to install a cryptographic library. On SAP systems it is included along with the kernel, while here it must be installed separately. I go to the SAP Marketplace to see what the latest version is and download it. In addition, I need to get the SAPCAR program to decompress the archive. So in the end I choose 2 files and save them in a new cryptolib folder.
It's time to unpack the library:
SAPCAR and the archive can be removed after extraction. Let's also start sapgenpse component to check if everything is fine.
It would be good to set SECUDIR variable explicitly and add cryptolib folder to LD_LIBRARY_PATH variable. Let's edit .profile of the user.
In the previous sections, I generated an SSL certificate for the RFCUSER. It was saved in the file rfcuser.p12. Even if you don't generate the certificates yourself, you will probably get a ready one from the certification authority in this format. In the SAP world we rather operate on PSE repositories, so with the help of sapgenpse I will convert PKCS#12 to PSE. I will perform all operations in the rfcuser user sec folder.
I prepared files, including certification authorities' certificates:
Let's import the p12 file into new repository and protect it with MyVerySecretPIN_1 secret PIN.
The PIN we can encrypt in cred_v2 file, which is kind of passwords repository. Later this can be used by tools to access the PSE file. I also update file permissions to more strict.
Finally I have below files with PSE and cred_v2.
Let's check what was saved in the PSE. I can see main certificate, signing CA and validity dates.
I can also confirm, that the trust list of the PSE is empty.
The next step is to prepare the RFCUSER user for SSO authentication. To do this, I update the SNC name field in the SNC tab in the SU01 transaction. At the same time, I can disable the option of logging in with a password.
The sapnwrfc.ini file allows to configure connection parameters for RFC calls made with the SDK library. You can define parameters there, such as the details of the system you are connecting to, the method of authentication, or encryption. Of course, you can specify a username and password there, but I will be configuring a certificate-based SSO. So I create the sapnwrfc.ini file in the same directory as the startrfc program:
For readability, the file contains a minimum set of parameters. DEST defines the name of the connection, which must be referred to by the program making the connection. SNC_LIB defines which cryptographic library to use. SNC_MYNAME specifies the SNC name of the client. SNC_PARTNERNAME gives the SNC name of the SAP server to which we are connecting. SNC_QOP defines the scope of the SNC, where 9 defines the maximum available security level.
I can return to startrfc program and update required parameters. The most important one is -D, which defines connection name, consistent with sapnwrfc.ini definition.
You might notice that the parameters responsible for the username, password and client number have been removed. They are not required if the SNC string is unique, that is, only one user on one client in a given system has this specific SNC name assigned to it.
The connection name is essential when you are securing a application that you are not the author of. The most important thing is to find in the documentation or configuration options how to determine this parameter or how to define it. Once you know this you will most likely be able to enable secure connection and encryption, even if the documentation from the vendor does not mention anything about such feature.
Ok, let's start the program to see what else is missing:
The error message is clear - SAP server does not trust my certificate chain. What does it mean?
The situation is as follows - the client approaches the server with a certificate, which perhaps even matches the SNC name of some user in the system. But after all, such certificate can be issued by anyone and any subject can be defined. Therefore, it is very important that the certificate is known and accepted by the server. This can be a trust relationship defined directly - by adding this particular certificate to the list. However, it can also be defined at a higher level - by trusting the certification authority.
It is the administrator's decision, or more often security policies, at which level we establish the trust relationship. It is very convenient to add a specific CA to the trusted list and this is often the right way to go. However, be aware that this also has consequences. The organisation that issues the certificates receives the authority to authenticate users on our system.
When we are unable to trust the certificate authority, we are required to add the leaf certificate to the list. This usually brings with it quite an inconvenience - the need to renew each certificate as it approaches its expiration date. This requires coordination with the client and, with a larger number of certificates, can be very inconvenient, especially as end certificates usually have an expiry date of one year.
As I have full control over my certificate authorities, so I add Another Root CA to my trusted list in transaction STRUST.
Let's retry the connection.
There is still an error, but different one. This is also related to trust, but in opposite direction. Now client doesn't trust server. I need to add SAP system certificate or better it's CA to the client's trusted list. Let's go to SECUDIR and add it to PSE.
I have to know PSE password to modify it.
You can always your trusted list with below command:
Now I can test the connection once more.
Success. Connection is possible with SSL based authentication. Encryption is obviously enabled.
When we consider how to secure RFC connections, it is impossible to ignore the question of the firewall. It is obvious that also at the network level, we should only allow traffic from addresses that are allowed to communicate with our server. One question to ask is which ports are needed. There are two ports that are used by the Gateway, which is responsible for RFC communication - 33<NN>/tcp and 48<NN>/tcp. NN is instance number, in my case 00. 3300/tcp is used for unencrypted communication, while 4800/tcp is the secure gateway, where communication is encrypted. In my case, after configuring a secure connection, only 4800/tcp is needed.
However, there is one more port to be considered. It is opened by the message server, which is part of the ASCS instance, that in my case is number 01. So I would also consider opening port 3601/tcp on the firewall to allow load balancing using login groups.
The final option I wanted to recommend to make RFC connections more secure is Unified Connectivity (UCON). This is a mechanism that provides the ability to define a list of allowed remote function modules. This is related to the idea of reducing the attack surface. It is clear that systems only use a very small proportion of functional modules. As the software may contain security vulnerabilities and somewhere in the system someone may have set too broad permissions, it is worth implementing protection at a higher level. UCON introduces an extra layer of protection - even before the user's permissions are checked, it is verified whether the call is on the allowed list. However, UCON is a rather broad topic for a separate article.
RFC connections from external non-ABAP programmes can be secured on very many levels. Security should be a priority these days and unencrypted connections forbidden by any security policy. Although we often have less control over external programs, as you can see, quite a lot can be done in this area too.
In this post, I will cover a topic perhaps quite niche for the SAP Basis administrator - securing connections from external non-SAP programs. An aspect that is often overlooked due to a gap in accountability. On the one hand, this is sometimes seen as outside the Basis scope. On the other hand, programs are sometimes configured by third party vendors not necessarily interested in the security of our system. I will try to show what we, as Basis administrators, can do to make the connection more secure.
Scope of consideration
In this post I will try to consider what mechanisms we can use to make an external connection secure. Of course, SNC/SSL-based encryption will be the focus as usual, but I will not limit myself to this technical aspect alone. As usual, I will also touch on topics that are on the borderline of responsibilities or even outside the typical scope of Basis, but important for understanding how the various mechanisms work.
I will discuss the topics of encryption, authentication using an SSL certificate, level of trust in a foreign CA, permissions, limiting network traffic. I will base my analysis on example programs from the SAP NetWeaver RFC SDK. I originally wanted to write my own simple program, but as Basis administrators we usually secure existing software and connections, so this is a more representative example.
Environment preparation
SAP server side
My test environment is ABAP Platform Trial 1909, based on S/4HANA 1909. The system is not the youngest, nor is it the oldest, but in the field of RFC connection security, not that much has changed over the years. So most of the insights will be valid for both older and younger systems.
The system has already been prepped for SNC and certificate-based authentication. I described this in my previous post "SAP-GUI Single Sign-On based on SSL certificates and SNC", so I won't repeat that part.
Client side
For the purpose of presenting the client program, I prepared a completely fresh Debian Linux system version 12. The rfcuser user was also created, in the context of which we will run the program that connects to the SAP server. Of course, you can use another Linux distribution as well, or even Windows, and the results will be similar.
SAP NetWeaver RFC SDK
SAP Note 2573790 describes where to get the library and briefly describes the installation process. I assume you can download it yourself from the Software Download Center, and I will describe the simplest installation method in a moment. I get two files, which I decompress in the rfcuser home directory.
rfcuser@sandboxn100:~$ unzip nwrfc750P_12-70002752.zip
Archive: nwrfc750P_12-70002752.zip
creating: nwrfcsdk/
creating: nwrfcsdk/bin/
inflating: nwrfcsdk/bin/rfcexec
inflating: nwrfcsdk/bin/startrfc[...]
inflating: nwrfcsdk/lib/libsapnwrfc.so
inflating: nwrfcsdk/lib/libsapucum.so
inflating: SIGNATURE.SMF
rfcuser@sandboxn100:~$ unzip nwrfc750P12HF_2-70002752.zip
Archive: nwrfc750P12HF_2-70002752.zip
inflating: libsapnwrfc.so
rfcuser@sandboxn100:~$ mv libsapnwrfc.so nwrfcsdk/lib/All files are located in nwrfcsdk folder. Next step is adding the folder to LD_LIBRARY_PATH environment variable. I can do this for current session, but to make this permanent, I add this to .profile file located in the user's home directory.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/libSAP user
I plan to establish a connection from an external program to my SAP system to perform some operations. It is easy to guess that I will need a user on the SAP system side to do this. So I'm creating an RFC user that the external program will use for operations on the system. I give it the top-secret password secure123, just for the purpose of this presentation, to keep things simple.
In addition to filling in basic user data, I set up the type to system or communication. In this case, it doesn't matter much. I leave the rest of the data default, including the lack of authorizations, because I'll come back to that in the next step.
The first, unsecured connection
Together with the SDK library, we get two sample programs - rfcexec and startrfc. Rfcexec connects to the SAP gateway and waits for incoming commands from the SAP system. I leave it for another occasion for now and will focus on startrfc.
The program connects to SAP and execute one of two function modules, related to EDI or display system information. In fact, I will focus on the last function today. The -i switch is responsible for calling it.
Let's call the program:
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i
Error: No RFC authorization for function module RFCPING.Sandbox is my SAP server hostname 00 is SAP instance number. 001 is a productive client.
Error is expected. In general connection is successful, because program reached checking authorization phase.
The principle of least privilege
Indisputably, the principle of least privilege is one of the most important elements of security and an absolute must when it comes to external connections. Keep in mind that a system is only as secure as its weakest component. Even if you secure your SAP system perfectly, an intrusion into a server independent of you that has rights to connect to SAP with a high level of privilege could result in data leakage or even damage to the system. So you should keep the level of RFC user privileges at the minimum level needed to operate. In fact, this should obviously apply to all users. However, for technical users, this rule is more often ignored for some reason. Do we trust programs more than people?
That's why I didn't give the RFCUSER any authorization at the beginning, and now I will build it from scratch. I check what the SU53 transaction reports for this user by selecting Authorization Values / Other User from the menu.
Apparently, the system first checked whether the user had access to the RFCPING function module. Since access was not explicitly granted, so the permissions for the entire SYST function group were also checked. Since I am very strict about permissions, I will build a role with minimal privileges in the PFCG tranaction.
I added this role to RFCUSER and repeated the connection test.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i
SAP System ID: A4H
SAP System Number: 00
Partner Host: vhcala4hci
Own Host: sandboxn100
Partner System Release: 754
Partner Kernel Release: 777
Own Release: 753
Partner Codepage: 4103
Own Codepage: 4103
User: RFCUSER
Client: 001
Language: E
This time the connection is fully successful and I get system information. Authorization is sufficient.
Certification authority
At this point it is worth saying a few words about how my system is configured. This is, in fact, already described in my previous post, but it doesn't do any harm to remind you of the basic information. The main certificate authority (OU=Security) signed the certificates of intermediate authorities - for servers (OU=Servers) and for users (OU=Users). The SAP server certificate was issued by the first one.
It's clear that the simplest solution would be to issue a certificate by an existing certification authority, but that would simplify our considerations a bit too much. Instead, I will assume that the certificate was issued by a completely independent group of certification authorities. So I will add three new to the existing ones, marked in blue in the diagram.
I won't focus on details, because you can go through this proces in my previous post, but let's go to the process of CAs creation and issuing RFCUSER's certificate. In practice, SAP administrators are usually not responsible for this part, so if you are not interested in issuing certificates, you can skip without hesitation to the next chapter.
Root CA key creation:
openssl genrsa -out AnotherRootCA/anotherca.key.pem 4096Certificate generation:
openssl req -x509 -sha256 -new -nodes -key AnotherRootCA/anotherca.key.pem -days 3650 -out AnotherRootCA/anotherca.cert.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany
Organizational Unit Name (eg, section) []:Trustworthy
Common Name (e.g. server FQDN or YOUR name) []:Another Root CA
Email Address []:Intermediate CA key:
openssl genrsa -out intermediateAppsCA/interApps.key.pem 4096Certificate signing request:
openssl req -key intermediateAppsCA/interApps.key.pem -new -sha256 -out intermediateAppsCA/interApps.csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany
Organizational Unit Name (eg, section) []:Apps
Common Name (e.g. server FQDN or YOUR name) []:Intermediate Apps CA
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:*******
An optional company name []:Certificate signature by the new root CA:
openssl x509 -req -in intermediateAppsCA/interApps.csr.pem -days 3650 -CA AnotherRootCA/anotherca.cert.pem -CAkey AnotherRootCA/anotherca.key.pem -CAcreateserial -out intermediateAppsCA/interApps.cert.pem
Certificate request self-signature ok
subject=C = PL, ST = kuj-pom, O = AnotherCompany, OU = Apps, CN = Intermediate Apps CARFCUSER key creation:
openssl genrsa -out intermediateAppsCA/rfcuser.key.pem 4096Certificate signing request:
openssl req -key intermediateAppsCA/rfcuser.key.pem -new -sha256 -out intermediateAppsCA/rfcuser.csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:kuj-pom
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:RFCUSER
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:********
An optional company name []:Client.cnf for client certificates:
nsCertType = client
extendedKeyUsage = clientAuthCertificate signing:
openssl x509 -req -days 365 -in intermediateAppsCA/rfcuser.csr.pem -sha256 -CA intermediateAppsCA/interApps.cert.pem -CAkey intermediateAppsCA/interApps.key.pem -CAcreateserial -out intermediateAppsCA/rfcuser.crt.pem -extfile intermediateAppsCA/client.cnf
Certificate request self-signature ok
subject=C = PL, ST = kuj-pom, O = AnotherCompany, CN = RFCUSERExport certificate to PKCS12 format:
openssl pkcs12 -export -inkey intermediateAppsCA/rfcuser.key.pem -in intermediateAppsCA/rfcuser.crt.pem -certfile AnotherRootCA/anotherca.cert.pem -certfile intermediateAppsCA/interApps.cert.pem -out rfcuser.p12
Enter Export Password:
Verifying - Enter Export Password:
exportpassword123As a result I got several keys and certificates, including the most important rfcuser.p12 file, which contains user's private key and certificate with the trust chain. The file is protected with exportpassword123 password. In real life scenarion this file you'll receive from your certification team.
Enforcing RFC encryption on system level
Ok, I know that forcing encrypted connections is not necessary for my connection to be encrypted. However, I will do it to show if the encryption works or not. Nevertheless, if you are ready to disable unsafe connections, I highly recommend making it permanent. In my case, the snc/only_encrypted_rfc parameter is sufficient, but you might consider setting a few others as well, such as snc/accept_insecure_cpic, snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/only_encrypted_gui.
I can set the parameter to 1, which enforces encryprion for non-ABAP RFC connections. Higher levels enforces encryption for ABAP and intenal connections.
snc/only_encrypted_rfc = 1Now the call should be rejected by the system.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -t 3 -i
Error: Unencrypted communication is rejected by this systemIt is no longer possible to establish an unencrypted connection.
SAP Cryptographic Library installation
To enable RFC connection encryption, it is necessary to install a cryptographic library. On SAP systems it is included along with the kernel, while here it must be installed separately. I go to the SAP Marketplace to see what the latest version is and download it. In addition, I need to get the SAPCAR program to decompress the archive. So in the end I choose 2 files and save them in a new cryptolib folder.
SAPCRYPTOLIBP_8553-20011697.SAR
SAPCAR_1200-70007716.EXEIt's time to unpack the library:
rfcuser@sandboxn100:~/cryptolib$ ./SAPCAR_1200-70007716.EXE -xf SAPCRYPTOLIBP_8553-20011697.SAR
SAPCAR: processing archive SAPCRYPTOLIBP_8553-20011697.SAR (version 2.01)
SAPCAR: 6 file(s) extractedSAPCAR and the archive can be removed after extraction. Let's also start sapgenpse component to check if everything is fine.
rfcuser@sandboxn100:~/cryptolib$ ./sapgenpse | tail -10
Versions: SAPGENPSE 8.5.53 (Sep 22 2023)
CommonCryptoLib 8.5.53 (Sep 22 2023) [AES-NI,CLMUL,SSE3,SSSE3]
Build change list: 248172
USER="rfcuser"
Environment variable $SECUDIR is not defined!
Fallback selection of SECUDIR through HOME:
"/home/rfcuser/sec"It would be good to set SECUDIR variable explicitly and add cryptolib folder to LD_LIBRARY_PATH variable. Let's edit .profile of the user.
rfcuser@sandboxn100:~$ cat .profile
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/lib:~/secudir
export SECUDIR=/home/rfcuser/secClient PSE preparation
In the previous sections, I generated an SSL certificate for the RFCUSER. It was saved in the file rfcuser.p12. Even if you don't generate the certificates yourself, you will probably get a ready one from the certification authority in this format. In the SAP world we rather operate on PSE repositories, so with the help of sapgenpse I will convert PKCS#12 to PSE. I will perform all operations in the rfcuser user sec folder.
I prepared files, including certification authorities' certificates:
rfcuser@sandboxn100:~/sec$ ls -l
total 24
-rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem
-rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem
-rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12Let's import the p12 file into new repository and protect it with MyVerySecretPIN_1 secret PIN.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse import_p12 -x MyVerySecretPIN_1 -p SAPSNCS.pse -r anotherca.cert.pem -r interApps.cert.pem rfcuser.p12
Please enter PKCS#12 encryption password: *****************
Found key 'INDEX=0,SIG=YES,ENC=YES,MD5-FINGERPRINT=60A1 B7F2 4F30 C198 9457 D2C3 5FA4 7F8E,KEYID=57F11B35BBC963B83B3B65F2666726003D11A46F'
PSE "/home/rfcuser/sec/SAPSNCS.pse" was writtenThe PIN we can encrypt in cred_v2 file, which is kind of passwords repository. Later this can be used by tools to access the PSE file. I also update file permissions to more strict.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse seclogin -x MyVerySecretPIN_1 -p SAPSNCS.pse
running seclogin with USER="rfcuser"
Added SSO-credentials for PSE "/home/rfcuser/sec/SAPSNCS.pse"
rfcuser@sandboxn100:~/sec$ chmod go-rwx cred_v2Finally I have below files with PSE and cred_v2.
rfcuser@sandboxn100:~/sec$ ls -l
total 28
-rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem
-rw------- 1 rfcuser rfcuser 114 Nov 30 18:37 cred_v2
-rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem
-rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12
-rw------- 1 rfcuser rfcuser 5111 Nov 30 18:36 SAPSNCS.pseLet's check what was saved in the PSE. I can see main certificate, signing CA and validity dates.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse get_my_name -p SAPSNCS.pse
SSO for USER "rfcuser"
with PSE file "/home/rfcuser/sec/SAPSNCS.pse"
Subject : CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL
Issuer : CN=Intermediate Apps CA, OU=Apps, O=AnotherCompany, SP=kuj-pom, C=PL
Serialno : 72:7B:01:77:64:B6:60:0B:31:D7:6C:60:66:0A:B2:7E:AB:FD:77:B1
KeyInfo : RSA, 4096-bit
Validity - NotBefore: Thu Nov 30 17:54:25 2023 (231130165425Z)
NotAfter : Fri Nov 29 17:54:25 2024 (241129165425Z)
KeyUsage : none
ExtKeyUsage : ClientAuthentication
SubjectAltName : noneI can also confirm, that the trust list of the PSE is empty.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -p SAPSNCS.pse -l
maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"
PKList is empty.
Empty trusted list.SAP user update
The next step is to prepare the RFCUSER user for SSO authentication. To do this, I update the SNC name field in the SNC tab in the SU01 transaction. At the same time, I can disable the option of logging in with a password.
sapnwrfc.ini
The sapnwrfc.ini file allows to configure connection parameters for RFC calls made with the SDK library. You can define parameters there, such as the details of the system you are connecting to, the method of authentication, or encryption. Of course, you can specify a username and password there, but I will be configuring a certificate-based SSO. So I create the sapnwrfc.ini file in the same directory as the startrfc program:
rfcuser@sandboxn100:~/nwrfcsdk/bin$ cat sapnwrfc.ini
DEST=a4htest
SNC_LIB=/home/rfcuser/cryptolib/libsapcrypto.so
SNC_MYNAME=p:CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL
SNC_PARTNERNAME=p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL
SNC_QOP=9For readability, the file contains a minimum set of parameters. DEST defines the name of the connection, which must be referred to by the program making the connection. SNC_LIB defines which cryptographic library to use. SNC_MYNAME specifies the SNC name of the client. SNC_PARTNERNAME gives the SNC name of the SAP server to which we are connecting. SNC_QOP defines the scope of the SNC, where 9 defines the maximum available security level.
I can return to startrfc program and update required parameters. The most important one is -D, which defines connection name, consistent with sapnwrfc.ini definition.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -iYou might notice that the parameters responsible for the username, password and client number have been removed. They are not required if the SNC string is unique, that is, only one user on one client in a given system has this specific SNC name assigned to it.
The connection name is essential when you are securing a application that you are not the author of. The most important thing is to find in the documentation or configuration options how to determine this parameter or how to define it. Once you know this you will most likely be able to enable secure connection and encryption, even if the documentation from the vendor does not mention anything about such feature.
Trust relationship
Ok, let's start the program to see what else is missing:
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i
[Thr 139683030722496] Thu Nov 30 18:50:59:304 2023
[Thr 139683030722496] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638]
Error:
LOCATION CPIC (TCP/IP) with Unicode
ERROR GSS-API(maj): Miscellaneous failure
GSS-API(min): A2210223:Server does not trust my certificate
path
target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany,
C=PL"
TIME Thu Nov 30 18:50:59 2023
RELEASE 753
COMPONENT SNC (Secure Network Communication)
VERSION 6
RC -4
MODULE /bas/753_REL/src/krn/snc/sncxxall.c
LINE 3604
DETAIL SncPEstablishContext
SYSTEM CALL gss_iThe error message is clear - SAP server does not trust my certificate chain. What does it mean?
The situation is as follows - the client approaches the server with a certificate, which perhaps even matches the SNC name of some user in the system. But after all, such certificate can be issued by anyone and any subject can be defined. Therefore, it is very important that the certificate is known and accepted by the server. This can be a trust relationship defined directly - by adding this particular certificate to the list. However, it can also be defined at a higher level - by trusting the certification authority.
It is the administrator's decision, or more often security policies, at which level we establish the trust relationship. It is very convenient to add a specific CA to the trusted list and this is often the right way to go. However, be aware that this also has consequences. The organisation that issues the certificates receives the authority to authenticate users on our system.
When we are unable to trust the certificate authority, we are required to add the leaf certificate to the list. This usually brings with it quite an inconvenience - the need to renew each certificate as it approaches its expiration date. This requires coordination with the client and, with a larger number of certificates, can be very inconvenient, especially as end certificates usually have an expiry date of one year.
As I have full control over my certificate authorities, so I add Another Root CA to my trusted list in transaction STRUST.
Let's retry the connection.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i
[Thr 139834091542464] Thu Nov 30 18:58:31:277 2023
[Thr 139834091542464] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638]
Error:
LOCATION CPIC (TCP/IP) with Unicode
ERROR GSS-API(maj): Miscellaneous failure
GSS-API(min): A2200223:Peer certificate path not trusted
target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany,
C=PL"
TIME Thu Nov 30 18:58:31 2023
RELEASE 753
COMPONENT SNC (Secure Network Communication)
VERSION 6
RC -4
MODULE /bas/753_REL/src/krn/snc/sncxxall.c
LINE 3604
DETAIL SncPEstablishContext
SYSTEM CALL gss_init_sec_contextThere is still an error, but different one. This is also related to trust, but in opposite direction. Now client doesn't trust server. I need to add SAP system certificate or better it's CA to the client's trusted list. Let's go to SECUDIR and add it to PSE.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a ca.cert.pem
Please enter PSE PIN/Passphrase: *****************
maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"
----------------------------------------------------------------------------
Subject : OU=Security, O=MyCompany, SP=kuj-pom, C=PL
PKList updated (1 entries total, 1 newly added)
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a interServers.cert.pem
Please enter PSE PIN/Passphrase: *****************
maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"
----------------------------------------------------------------------------
Subject : OU=Servers, O=MyCompany, SP=kuj-pom, C=PL
PKList updated (2 entries total, 1 newly added)I have to know PSE password to modify it.
You can always your trusted list with below command:
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -lNow I can test the connection once more.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i
SAP System ID: A4H
SAP System Number: 00
Partner Host: vhcala4hci
Own Host: sandboxn100
Partner System Release: 754
Partner Kernel Release: 777
Own Release: 753
Partner Codepage: 4103
Own Codepage: 4103
User: RFCUSER
Client: 001
Language: ESuccess. Connection is possible with SSL based authentication. Encryption is obviously enabled.
Firewall
When we consider how to secure RFC connections, it is impossible to ignore the question of the firewall. It is obvious that also at the network level, we should only allow traffic from addresses that are allowed to communicate with our server. One question to ask is which ports are needed. There are two ports that are used by the Gateway, which is responsible for RFC communication - 33<NN>/tcp and 48<NN>/tcp. NN is instance number, in my case 00. 3300/tcp is used for unencrypted communication, while 4800/tcp is the secure gateway, where communication is encrypted. In my case, after configuring a secure connection, only 4800/tcp is needed.
However, there is one more port to be considered. It is opened by the message server, which is part of the ASCS instance, that in my case is number 01. So I would also consider opening port 3601/tcp on the firewall to allow load balancing using login groups.
UCON
The final option I wanted to recommend to make RFC connections more secure is Unified Connectivity (UCON). This is a mechanism that provides the ability to define a list of allowed remote function modules. This is related to the idea of reducing the attack surface. It is clear that systems only use a very small proportion of functional modules. As the software may contain security vulnerabilities and somewhere in the system someone may have set too broad permissions, it is worth implementing protection at a higher level. UCON introduces an extra layer of protection - even before the user's permissions are checked, it is verified whether the call is on the allowed list. However, UCON is a rather broad topic for a separate article.
Conclusion
RFC connections from external non-ABAP programmes can be secured on very many levels. Security should be a priority these days and unencrypted connections forbidden by any security policy. Although we often have less control over external programs, as you can see, quite a lot can be done in this area too.
- SAP Managed Tags:
3 Comments
