One of the mandatory technical and architectural components of any SAP system is the SAP instance. Every SAP instance has a gateway process. The SAP gateway provides the frontier for communication between not only different SAP systems but also external programs. In a typical SAP environment, there is always a need to run external programs (such as sapftp and saphttp) to achieve specific business and technical requirements. As a matter of fact, the aforementioned external programs (sapftp and saphttp) are available by default in every ABAP installation.

The need to take appropriate security and protective steps to prevent malicious execution of external programs is therefore crucial. External programs are started at the operating system level via the sapxpg middleware program based on the authorization of the standard SAP system operating system user. Although there are different ways to address security issues in the SAP system, a commonplace approach is using authorization concepts. However, authorization concepts are not effective as it relates to starting external programs. This is because SAP authorization concepts do not perform explicit authorization checks when starting external programs unlike how they do for ABAP programs.

As a result, you need to have security measures and strategies in place to protect the SAP gateway. In this article, I discuss these five tips:

• Restrict unauthorized access to external programs by configuring the secinfo file
• Control the registration of external programs in the SAP gateway by properly configuring the reginfo file
• Configure Secure Network Communication (SNC) support via appropriate parameterization
• Configure and protect side information tables

• Activate gateway logging

Restrict Unauthorized Access to External Programs by Configuring the secinfo File

You can avoid unauthorized access to external programs by configuring the secinfo file, which is resident in the data directory of the gateway instance. If the secinfo file does not exist in the standard SAP system, any user who can access the SAP gateway can execute all operating system commands on the SAP system, which is a serious security threat. Furthermore, the secinfo file needs to be appropriately configured to guarantee optimal protection and availability of external programs. This is because if the secinfo file exists, but it is empty or contains invalid entries, it is impossible to start any external program.

You need to set the profile parameter gw/secinfo to point to the specific location (/usr/sap/<SID>/data/secinfo [where SID is the SAP system name]) of the secinfo file in the SAP system. The profile parameter gw/tcp_security also plays an important role in protecting external programs from being started. The valid values for this parameter are 0 (deactivated) and 1 (activated). If this parameter is activated, the information in the gw/sec_info is read. The entries defined in the secinfo file are case sensitive, so you need to be careful when making your entries. The syntax for the entries in the secinfo file is as follows:

USER=<user>, HOST=<host>,TP=<tp> [USER-HOST=<user_host>,]

• USER is mandatory and defines the name of the user who wants to start the external program
• HOST is mandatory and defines the host name on which the external program is to be started. Valid entries include host names, IP addresses, subnet mask addresses, or domains.

• TP is mandatory and defines the name of the external program that you want to start
• USER-HOST is optional and defines the host name of the user who wants to start the external program

An example of a simple entry in the secinfo file is as follows:

USER=KENNY, HOST=SCD, TP=sapken (This means: Permit user KENNY to access external program sapken only on host SCD.)

You can also define additional restrictions by specifying the optional USER-HOST attributes as follows:

USER=KENNY, USER-HOST=SMG, HOST=SCD, TP=sapken (This means: Permit user KENNY to access the external program sapken only on host SCD provided that user KENNY is connected to the gateway from host SMG.)

Note that you can use a wildcard (*) character as an entry for any of the attributes. Also, all characters specified after * are ignored. For example, if TP=sap*xy, the system ignores xy and validates sap*.

Aside from the conventional (old) file format for secinfo just discussed, the SAP system supports a new format that allows you to define an additional permit (P) or deny (D) parameters in the file. The structure of the new file format is a bit different from the old format. In the new file format, the first line must start with #VERSION=2 and be followed with the lines in the old format, but with a P or D prefix. Note that the P or D must be in upper case and should be followed by a space or blank character. The syntax is as follows:

#VERSION=2

P|D USER=<user>, HOST=<host>,TP=<tp> [USER-HOST=<user_host>,]

An example of a typical entry for the new secinfo file is as follows:

#VERSION=2

D USER= * HOST=* TP=sapken (This means that starting the program sapken is not allowed (denied). If the D in the syntax above is replaced by P, it means that the starting of the program sapken is allowed (permitted).)

The secinfo file is read whenever the gateway is started. However, you can perform activation of the changes to the secinfo file (at the operating system level) dynamically (no need to restart) by using transaction SMGW and following menu path Goto > Expert Functions > External Security > Reread (Figure 1).

Figure 1

Dynamic activation of changes to the secinfo/reginfo file

Furthermore, you can control access to external programs by correctly setting the profile parameter gw/rem_start. This parameter defines how remote programs are started. The valid entries for this parameter include:

• REMOTE_SHELL: Remote programs are started through a remote shell. This is the default setting.
• SSH_SHELL: Remote programs are started through a secure shell
• REXEC: Remote programs are started through rexec
• DISABLED: Remote program cannot be started

Control the Registration of External Programs in the Gateway  

You can protect external programs from registration in the gateway by appropriately configuring the reginfo file. The reginfo file is an access control list that not only prevents authorized registration of external programs, but also cancels registered programs. You need to correctly set the profile parameter gw/reg_info to point to the specific location (/usr/sap/<SID>/data/reginfo [where SID is the SAP system name]) of the reginfo file in the SAP system. The syntax for the entries in this file is as follows:

TP=<tp> [HOST=<host name>,...] [NO=<n>] [ACCESS=<host name,...>] [CANCEL=<host name,...>]

• TP is the registration identifier of the external program. Examples of permitted TP names includes: sap* (start of name), sap (TP name), and * (unrestricted name).
• HOST defines the host name from which registered external programs are permitted to log on. Examples of permitted host names include: 10.116.219.* (Subnet mask address), *.kite.com.ng (domain), 10.116.219.3 (IP address), SCD (host name), and * (unrestricted).
• NO defines the number of registrations allowed
• ACCESS allows you to define an access list, which is the host name permitted to use the registered program. The exception here is that it cannot take a wildcard (*) as a value. If you do not specify any access list, the implication therefore is that the program can be used from any client.
• CANCEL allows you to define a cancel list, which determines whether or not other clients can stop or log off the registered program

Examples of valid entries in the reginfo file are as follows:

• TP=* (All registrations are allowed)
• HOST=* .kite.com.ng TP=* (This means that all registrations from *.kite.com.ng domain are permitted)
• HOST=* TP=sapken NO=1 (This means that only a program with the name sapken is allowed to register)
• HOST=* TP=sapken ACCESS=*kite.com.ng (This means that the program sapken can be accessed by hosts that belong to only the *kite.com.ng domain)
• HOST=* TP=sapken CANCEL=*pro.com.ng (This means that program sapken can be ended by clients that are logged on from only the *pro.com.ng domain)

Aside from the conventional (old) file format for reginfo just discussed above, the SAP system supports a new format that allows you to define an additional permit (P) or deny (D) parameters in the file. The structure of the new file format is a bit different from the old format. In the new file format, the first line must start with #VERSION=2 and followed by the lines in the old format, but with a P or D prefix. Note that the P or D must be in upper case and it should be followed by a space or blank character. The syntax is as follows:

#VERSION=2

P|D TP=<tp> [HOST=<host name>,...] [NO=<n>] [ACCESS=<host name,...>] [CANCEL=<host name,...>]

An example of a typical entry for the new reginfo file is as follows:

#VERSION=2

P HOST=SMG TP=sapken

This means that the registration of the program sapken is allowed (permitted) if it came from host SMG. If the P in the syntax above is replaced by D, it means that the registration of the program sapken is not allowed (denied).

The reginfo file is read whenever the gateway is started. However, you can activate the changes to the reginfo file (at the operating system level) dynamically (no need to restart) by using transaction SMGW (gateway monitor) and following menu path Goto > Expert Functions External Security > Reread (Figure 1).

Configure SNC Support via Appropriate Parameterization

Activation of SNC support allows you to use an external security product to secure the communication between SAP systems and external programs. SNC offers encryption capabilities that facilitate secure user authentication, data integrity, and privacy for data transfer. Note that security products that have implemented the standardized interface GSS-API v2 and whose services are available to the SAP system as a shared library can use SNC functionalities. Certification of external security products is based on the standardized interface GSS-API v2. Appropriately configuring a number of SNC-based parameters is one laudable way to secure the gateway and control the execution of external programs. You can configure these parameters by using transaction RZ11 (maintain profile parameter attributes).

Some of the SNC relevant parameters include:

• snc/enable (Enable SNC module) defines whether or not the gateway supports SNC. The valid entries for this parameter are 0 (deactivated) and 1 (activated).
• snc/permit_insecure_start defines whether or not insecure programs can be started when support for SNC is activated.
• snc/permit_insecure_comm defines whether or not the gateway can permit connections without SNC. Valid entries for this parameter are 0 (deactivated) and 1 (activated).
• snc/identity/as defines the identity of the gateway application server for an external security product when using SNC.
• snc/permit_common_name defines whether or not the gateway can use a default name specified as the application server in profile parameter snc/identity/as in a scenario where the SNC name cannot be read from the secinfo file. Valid entries for this parameter are 0 (deactivated) and 1 (activated).

• snc/gessapi_lib (file name for external GSS-API shared library) defines the name of the GSS-API v2 shared library, which is provided by the vendor of an independent network security product. The file extension for the valid entries for this parameter is dependent on the operating system in use. For example, Sun Solaris is sncgss.so, IBM (AIX) is sncgss.o, and Microsoft is sncgss.dll.

Configure and Protect Side Information Tables

Side information tables act as a security repository for the information used to establish a connection and communication between programs or systems. Usually, when a program communicates with partner programs, the program should not contain communication-related attributes for security reasons. Communication-centric attributes are stored in configuration files external to the program. Side information tables contain a number of general and unique parameters. These parameters include:

• DEST: Defines the symbolic name of the target system
• LU: Defines the name of the logical unit of the partner
• TP: Defines the name of the transaction program to be called remotely
• PROTOCOL: Defines the communication type. Possible values as seen in an excerpt of transaction SM54 (table maintenance TXCOM) (Figure 2) include:
  • I: An SAP NetWeaver ABAP program that can be accessed via TCP/IP
  • E: A C-based program that can be accessed via TCP/IP and started via fork/exec, remote shell, or rexec
  • F: A C-based program that you can access via TCP/IP and started externally
  • R: A C-based program that you can access via TCP/IP and has registered at the SAP gateway
• GWHOST: Defines the name of the host on which the SAP gateway is running
• GWSERV: Defines the name of the gateway service

Figure 2

Creation screen for entries in table TXCOM showing possible communication types

The database of every SAP system usually consists of a side information table called TXCOM. You can create and maintain entries for table TXCOM by using transaction SM54 (Figure 3).

Figure 3

Sample entries in table TXCOM

Activate Gateway Logging

Activating gateway logging allows you to monitor the activities of the gateway. The gateway log file provides details about successful and unsuccessful program calls. Also, successful and unsuccessful registrations and calls from registered programs are recorded in the log file. You can activate the logging functionality of the gateway by correctly setting the profile parameter gw/logging. The syntax for the parameter is as follows:

LOGFILE=<name> ACTION=[TERSMPXVOC] [MAXSIZEKB=n] [SWITCHTF=t] [FILEWRAP=on]

LOGFILE defines the name of the logfile and is driven by a number of special characters, including %y, %m, %d, %h, %t, and %s, which represent year, month, day, hour, minute, and second, respectively.

ACTION defines the possible actions that can be logged. Valid entries for this attribute are represented by means of identifiers, including:

• T: Opening and closing of network connections and network activities
• E: Running of external programs
• R: Registration and deregistration of servers
• S: Security settings for the SAP gateway and changes to security files
• M: Administrative commands (SMGW or external gwmon) received from the gateway monitor
• P: Maintenance of profile parameters in the production environment
• X: Receipt of start and stop commands or other operating system-based signals
• V: Creation and deletion of new conversion IDs
• O: Opening of new RFC connections
• C: RFC actions such as connection opening and closing and data sending and receipt

MAXSIZEKB allows you to define a threshold file size in kilobyte. When the log file exceeds the defined ceiling, the file is closed and a new one is opened. The new file is assigned a new name if special characters (with timestamp) are used for file name generation.

SWITCHTF facilitates the opening of a new file after a defined time period unless the condition specified for the MAXSIZEKB attribute is met before then. Possible entries include year, month, week, day, and hour.

FILEWRAP defines the reusability of log files.

An example of a valid entry for this the parameter gw/logging is as follows:

ACTION=ERSX LOGFILE=gw_log-%y%m%d SWITCHTF=day

This means that external programs, registered programs, security settings, and receipt of start and stop commands are logged in the log file with a name such as gw_log-2010-02-18.

You can also activate the logging functionality graphically via the gateway monitor, accessible via transaction SMGW and by following the menu path Goto > Expert functions > Logging (Figure 4).

Figure 4

Logging attributes and settings in the gateway monitor

The LOGFILE and ACTION attributes in the gw/logging parameter relate to the File Name and Log Events tabs in Figure 4, respectively. Also, the MAXSIZEKB, SWITCHF, and FILEWRAP options in the parameter relate to the toggle criteria in Figure 4, respectively.

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.