Reverse Invoke for Added Security: SAProuter as an example
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:
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
Result: failed connection because there is no open port (as also shown by telnet test).
Test 3: niping test via SAProuter1 host
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!
