top of page

SAP Security Advisory – Securely Configuring SAP Gateway and SAP Message Server - Easy Explanation

Updated: Oct 15, 2021

Purpose

SAP has issued a recent security advisory mail to the customers in May 2019 with subject line " SAP Security Advisory – Patch Your SAP Landscape and Ensure Secure Configuration" to remind the customers of implementing the gateway and message server security recommendations already provided by SAP long time ago. You can check the advisory at below URL

SAP security advisory notice


The purpose of writing this blog is to provide the list of tasks that need to be performed in order to ensure the successful implementation of SAP recommendations and provide a better understanding of gateway related ACL files reginfo and secinfo implementation with minimum risk


SAP Notes and related parameters

Please go through the SAP notes 1408081 ,821875 and 1421005 for any updates, I have listed down the below parameters according to the above mentioned notes for the system SAP_BASIS release 701 and above with kernel 720 and above. Few parameters/file syntax may vary if your system is old e.g 46D, 640 etc.


You can find the gateway related parameters in SMGW

You can find the message server related parameters in RZ11 and the related files in SMMS

You can also get the idea about missing gateway configuration from the EWA reports.


gw/reg_no_conn_info: It is only relevant for kernel releases 72x and can influence the parameter gw/acl_mode in them. If we have systems on kernel releases above 720 or have the patches for kernel 720 as mentioned in the SAP note 1480644 , there is no need to set the parameter gw/reg_no_conn_info if it doesn’t exist in the system. However, if it exists then we should change it’s value to 1 or the values mentioned in SAP note 1444282.


gw/acl_mode : System reads it’s value only if the files gw/reg_info and gw/sec_info do not exist. It should always be set to 1 in production so that it considers only the internal access if the files don’t exist



SAP Gateway related changes

The challenging part of this change is to create the gateway ACL files reginfo and secinfo with the restricted entries, without impacting the customer SAP landscape communication with the external interfaces.

Below is the summary of changes that need to be done in most of your systems:

1. Change the value of parameter gw/acl_mode to 1 from 0.

2. Maintain the ACL files (reginfo and secinfo ) in the systems with the trusted server list.


Reginfo file

This file should contain the information of all the external programs registering on your SAP instance. Think of this file as a firewall in your SAP system which will allow this external program to be registered only from a specific server/servers and you can mention which servers can access and cancel this registered program.


Syntax:

P TP=<program name>

HOST=<comma separated list of hosts that can register the program>

ACCESS=<comma separated list of hosts that can communicate with the program>

CANCEL=<comma separated list of hosts that can cancel this registration>


1. The simplest way to start with is put the below entry if you are not able to create specific entries and avoid any loss of communication.

P TP=* HOST=*.<FQDN of your SAP system>


This will allow all the programs to be registered from your customer domain on to your SAP application, which means any server in your customer domain can register/access all th,e external programs.


2. Once you generate the new reginfo for the first time, you will find that it picks up all the programs entries from the TCP/IP destinations with HOST,CANCEL and ACCESS as local and internal.

These entries represent that only your SAP application servers of current system can register,access and cancel the specified programs in TP entries.


You will need to modify this by checking the servers which register on your SAP application by checking SMGW-> Goto -> Logged on clients.


For example, if you have webmethods or Business connectors registering from another server (not SAP application server). This may be in the customer domain (as mentioned in point 1), however you should still put the hardcoded server name and it's IP address in one of the entries as sometimes SAP doesnt pick up the full hostname of external server.


e.g


P TP=<program name of webmethods program>

HOST=<IP address of webmethods server>,<Hostname of webmethods server>

ACCESS=*

CANCEL=internal,local,<IP address of webmethods server>,<Hostname of webmethods server>


The above entries represent that only the IP address/Host name mentioned in HOST entry can register the program mentioned in TP entry, it can be cancelled only by the SAP application server of current system and the hostname/Ip address server of webmethods, and it can be accessed by all servers though. You can also restrict the ACCESS entry as well with same entries as CANCEL if you are sure that this program should not be accessed by another server.


3. End this file with below default entries which are generated automatically when you create this file


# system entry for host: <hostname>

P TP=* HOST=<IP address> CANCEL=<IP address>ACCESS=<IP address>

# system entry for host: <DB Host>

P TP=* HOST=<IP address> CANCEL=<IP address> ACCESS=<IP address>

#

# system entries for 720 compatibility

P TP=* HOST=local CANCEL=local ACCESS=local

P TP=* HOST=internal CANCEL=internal ACCESS=internal



Secinfo file

This file should contain the information of the usernames (USER) that are allowed to start the specified programs (TP) on specified hosts (HOST) when logged in through specific servers (USER-HOST)


Syntax

P USER=<username that is allowed to start the program>

USER-HOST=<comma separated list of hosts from where the users can start the program>

HOST=<comma separated list of hosts where the program can be started>

TP=<program name>


1. The simplest way to start is with the below entry:

P TP=* USER=* USER-HOST=local,internal HOST=*


This will allow all users of current SAP system , logged on to current SAP application servers to start any program on any host in the customer domain.


2. End the file with below auto generated entries when you create the secinfo file

# system entries for 720 compatibility

P TP=* USER=* USER-HOST=local HOST=local

P TP=* USER=* USER-HOST=internal HOST=internal

#

# secinfo should the crosswise execution of external program

# from servers within the system. Therefore USER-HOST for

# one machine must allow HOST of all other servers.

#

# system entry for host:<SAP application server>

P TP=* USER=* USER-HOST=<IP Address> HOST=<IP Address>

P TP=* USER=* USER-HOST=<IP Address> HOST=<IP Address>

# system entry for host:<DB hostname>

P TP=* USER=* USER-HOST=<IP Address> HOST=<IP Address>

P TP=* USER=* USER-HOST=<IP Address> HOST=<IP Address>



Minimum risk approach

Follow the below approach for the minimum risk in implementing these recommendations:


1. Always consult the customer and find out regarding the external interfaces which connect to the SAP applications and if there are any interfaces which connect on ad-hoc basis. You should get the server names and IP addresses of those servers.


2. Always test the changes in development (if possible) and test environment before implementing them in production environment.


3. Enable the simulation mode in production system before the actual change by implementing below parameters.

gw/sim_mode : 1 (Enables the simulation)

gw/logging : ACTION=Z LOGFILE=gw_log-%y%m%d SWITCHTF=day (It will create logs for any missing configuration in your ACL files)


The setting of above parameters will not enable the ACL files restrictions, it will instead simulate and find out what entries have you missed in your ACL files which will impact the registration of certain programs in the live scenario.


Monitor the logs for at least 2-3 weeks in production system.


4. Update your ACL files entries if you find any missing server entries in the logs created during simulation mode.


5. Disable the gateway simulation mode and enable the restrictions through gateway ACL files.



#SAP #SAPAdvisory