Time and again, we’ve seen subpar handling of risk resolution in practice for RFC interfaces, with no guarantee for maintaining proper and secure operating conditions.
In today’s practical tip, we give you a step-by-step explanation of how you can secure your SAP gateways against unauthorized calls.
SAP systems use several different mechanisms to execute OS commands.
1. Dialog call with an authenticated user
a) CALL ‘SYSTEM’ C-call from ABAP programs (RSBDCOS0) or Z-programs
b) Call logical OS commands using the SM49/SM69 mechanism in ABAP programs
2. Batch processing (SM36) with an SAP user
a) Call logical OS commands via the SM49/SM69 mechanism in jobs
b) Call direct OS commands in jobs
3. Initiate commands via the SAP Gateway
a) Via RFC server program SAPXPG
b) Via RFC server program RFCEXEC
Crucially, you must ensure that all options that use SM49/SM69 commands and the SAP Gateway have security mechanisms that guard against unauthorized calls.
Lock it down: gateway security and SAPXPG.SEC
Calls of external OS commands are not performed directly. Instead, auxiliary programs such as RFCEXEC and SAPXPG are involved. To do this, the Gateway Security file SECINFO must be configured in such a way that calling RFCEXEC is prevented for security reasons and that SAPXPG can only called via LOCAL or INTERNAL.
The first step in securing SAP systems at the level of the Gateway and NI layer is to isolate the SAP server segment from the PC segment. Second, all calls must be routed to the SAP server segment via an SAP router over 32xx and 33xx ports as an application-level proxy in combination with a firewall.
Take advantage of SAP XPG logging
The only thing that the SECINFO security file controls is whether SAPXPG can be started. However, no further filtering can be done at gateway level as to which subsequent OS commands can be called (see transaction SM49). The program SAPXPG offers comprehensive logging functions that permit you to analyze the OS commands that are called.
Here’s how you can turn on SAPXPG logging:
1. On your SAP server, set the “SAPXPG_PROTOCOL = 1” environment variable
Do this for every SAP instance in the user environment <sid>adm (Unix) or SAPService<SID> (Windows)
2. Setting the environment variable: SAPXPG_PROTOCOL_PATH = <path for log file>
This variable describes the existing directory to which the log file is written.
Recommendation: SAPXPG_PROTOCOL_PATH = /usr/sap/<SID>/<INSTANCE_DIRECTORY>/work/
It is important that this ends with the system-specific separator, either slash or backslash.
As long as logging is turned on, a log file named “xpg_prot_mm-dd” is generated in the defined directory every day (“mm” is for month, “dd” for day).
Generating SAPXPG SEC files and activating security
Protection against unauthorized calls from the OS level must be implemented at level 2 via a SAPXPG.SEC file (see OSS Note 686765). The main switch for the environment variable is “SAPXPG_SEC_CHECK”. Next, you must configure the environment variable “SAPXPG_SEC_CHECK = POS” in the Unix or Windows environment for the user of the instance.
However, to prevent all external commands from being blocked after you install the new SAPXPG, you must also turn on this “main switch” (specify any single-digit value for the environment variable). The security check is not performed until you have done this. In this case, you must also disallow ALL commands in the SAPXPG.SEC that are not permitted. This is practically impossible. SAP has recognized this and adapted.
The file SAPXPG.SEC (see Note 686765) can also be interpreted as a positive list, which is easy to maintain and provides optimum protection. You can achieve this by assigning any 3-character value to the environment variable “SAPXPG_SEC_CHECK” on the target computer, for example POS.
A word of caution, however – avoid using “/” as a separator character as this is a component in UNIX command names when the full path is specified. Try using “#” instead. The new positive list function is delivered with an SAPXPG Patch for the kernel Releases 640 and 700.
Examples for an SAPXPG.SEC file:
1. #U#*#C#*#T#3#F#*#O#cp, pwd, ls #S#*#
Here, only those commands specified may be executed by all users who have SAP authorization in the calling system to call external commands or external programs.
2. If you want to differentiate between users, you must create exactly one line for each user, for example:
#U#SMITH#C#*#T#3#F#*#O#cp, pwd, ls #S#*#
#U#CARTER#C#*#T#3#F#*#O#cp, pwd, ls, rm #S#*#
#U#SUPERUSER#C#*#T#3#F#*#O#*#S#*#
But be careful because well-meaning admins may decide to create a separate line for each user and each command in SAPXPC.EXE. A good idea, but one that does not work.
The kernel only evaluates one line per user. This means that you must be sure to enter all Unix commands into a comma-separated list.
Don’t forget about authorizations
In SAP, the object “S_LOG_COM” controls which logical commands, and by extension which OS commands, that a user is authorized to execute. Thus, admins should assign “S_LOG_COM” only to users to whom interface tasks will be assigned.
Result
Once hardening is complete, your users can execute only those OS commands for which they are authorized. Be sure to check both positive and negative tests and don’t be surprised when you see the following: When calls are denied, you’ll see the notification “Communication Error” in SM49, rather than “Not authorized according to SAPXPG.SEC”.
Ralf Kempf
Technical Managing Director “SAST SOLUTIONS”
Do you wish you had some support for protecting your SAP systems?
SAST Interface Management covers comprehensive functions for analyzing gateway and SAPXPG security, and can additionally assess your authorizations, detecting misuse in real time. Generating SAPXPG.SEC ACL files based on the log files is also convenient with SAST SUITE. If you still would rather place the security of your SAP gateways into professional hands, our experienced SAP security experts would be glad help at any time.