Skip to content
Reverse invoke SAProuter

Reverse Invoke for Added Security: SAProuter as an example

ebde76d0d55c1a42c8ff2d0159c52217?s=96&d=mm&r=g
Gert-Jan Koster
SAP Security specialist
February 28, 2024
3 min read
Chapters

Share Article

In this article, we want to demostrate the underutilized security benefits of SAProuter’s reverse invoke configuration through a test setup. 

We have pointed out the advantage of a reverse invoke configuration and explored this for the SAP Web Dispatcher component, see the following link here. In this blog, we will now zoom in on the SAProuter component and show this in a concise test setup.   

As mentioned earlier, in our experience, the reverse invoke option is not often used and is quite unknown to SAP consultants. This goes for the SAP Web Dispatcher and perhaps even more so for the SAProuter component. This is a pity because it is an interesting option to explore for enhanced security of a setup where more than one component is involved.   

Test setup

Note that we will focus on the reverse invoke setup of the SAProuter component and will not go into other security details, although the below setup has also been tested in combination with SNC. For this SNC configuration, see the following page for reference.  

Our test setup resembles the setup example from SAP Help, see the link further below and the following picture:  

Reverse invoke SAProuter-1

The setup is a DMZ-like scenario but can be any setup with 2 SAProuter components and in-between network separation. The SAProuter 1 and 2 components are technically installed within docker containers which have the following inbound characteristics:  

  • SAProuter1: only accepting incoming TCP connections from ports 4001 and 5001 
  • SAProuter2: accepting NO incoming TCP connections.  

Both SAProuters run with a basic SNC configuration and the following parameters for reverse invoke:

SAPROUTER1 SAPROUTER2

Start command:  

saprouter -K p:CN=SAPROUTER1 -S 4001 -V 2 -i cf1 &

Start command:  

saprouter -K p:CN=SAPROUTER2 -V 2 -i cf2 &

saprouttab:  

# Allow outbound connections to SAProuter host2 with use of SNC 

KT “p:CN=SAPROUTER2” 172.17.0.3 5002 

P * 172.17.0.3 5002 

saprouttab:

# Accept incoming connections from SAProuter1

# with destination sapdp00 and 4001 on any host

KP “p:CN=SAPROUTER1” *     sapdp01

KP “p:CN=SAPROUTER1” *     4001

Reverse invoke configuration parameters:  

client = true 

client_service= 5001

Reverse invoke configuration parameters:  

server = true 

client_hostname = 172.17.0.2 

client_service = 5001 

reg_service = 5002

Furthermore, there is an SAP ABAP backend system running in the local network, with an active dispatcher on service sapdp01 (port 3201). This is the connection that is used for an SAP GUI connection for example.    

Now comes the testing of connectivity! This is done from the SAProuter1 container.  

Test 1: direct connections  

Result: only connection to SAProuter1 is open on port 4001. Performed with basic telnet <IP> <port> commands.  

Test 2: niping test to SAProuter2 host directly  

Reverse invoke SAProuter-2

Result: failed connection because there is no open port (as also shown by telnet test).  

 Test 3: niping test via SAProuter1 host 

Reverse invoke SAProuter-3

Result: successful connection.

Conclusion

The above tests demonstrate the effect and advantage of a reverse invoke configuration. There are no ports opened to any of the components in the local network. Still, using reverse invoke, the local components are reachable but only via the configured SAProuter component in the DMZ.   

The setup of reverse invoke can be more complex and should, naturally, always be tested thoroughly for a given scenario. But a successful implementation can certainly contribute to a more secure setup!  

 See the following SAP Help page as a starting point for configuration:  

Try SecurityBridge and immediately strengthen the security of your SAP systems! For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!