TOP 5 Security Measures for SAP NetWeaver ABAP
What if you had only very limited resources and numerous SAP NetWeaver instances in your enterprise, but you still want to ensure at least basic security measures are met. Here we highlight the TOP 5 security measures which you can validate on your systems which will provide rudimentary security. The validation steps are described in a way that no deep technical understanding is required.
In order to validate the measures we will use SAP GUI (SAP Logon), so go on and fire it up and log on to your target system.
Measure #1: Default Passwords
Here we want to identify if there are any standard accounts with default passwords. Typical accounts are SAP*, TMSADM, DDIC, SAPCPIC and EARLYWATCH. See SAP Default Passwords for details on the actual common password.
Open SAP GUI and execute transaction SA38 orSE38.
Execute report RSUSR003 by clicking on "F8" button twice.
The report returns a table with all the available default accounts, the client in which they exist (in this case 000 and 001), their Status (locked or unlocked) and the "Password Status".
In case red warnings appear, execute transaction SU01 and change the password of the respective account with default password.
Consider that you need to do that exercise in each Client in which the default password was identified.
Note: In older AS ABAP versions,the account TMSADM may not appear in the RSUSR003 report and therefore, you may need to validate the password in a different way (e.g. by checking the available password hashes in the table USR02 over the SE16 transaction).
Measure #2: Gateway Security
The NetWeaver Gateway is an application server component which enables RFC communication with the application server. There are different types of RFC communication which enables communication with RFC clients, other RFC-enabled servers and programs. The following diagram describes the different types of RFC communication managed by the Gateway.
While there are authorizations being checked in the first scenario (ABAP RFC), The actual protection layer for Registered and Started RFC programs are the REGINFO and SECINFO Access Control Lists (ACLs). The two ACLs (similar to network ACLs) need to be maintained appropriately in order ensure that only trusted systems and programs can connect to the application server.
To validate the settings go to transaction SE38 and execute report RSPARAM which will display all Profile Parameters configured in the system. Relevant parameters are the following:
gw/acl_mode - must be set to "1". If set to "0" no ACLs are considered and any RFC server can register to the system which poses a huge security risk
gw/sec_info - defines the path to the secinfo ACL file on the system
gw/reg_info - defines the path to the reginfo ACL file on the system
After we have ensured that the ACL paths are there and ACLs are evaluated (gw/acl_mode), we need to verify that the ACLs are set appropriately. In order to do that we execute transaction SMGW. In a well hidden menu we navigate to "More --> Goto --> Expert Functions --> External Security --> Maintain ACL Files"
There you will find the current configurations of the reg_info and sec_info files. The configurations you see below are the default configurations.
There are a few considerations which need to be taken into account:
The first line contains the version format in use - "#VERSION=2"
Rules are applied in the sequential order they appear, meaning the first matching rule will be applied.
Each line represents a rule - a rule cannot be split in multiple different lines.
Multiple parameter values are separated by a comma (,)
Default configurations are considered safe (but not highly restrictive), though these will not allow any integration with other external systems. A wide open insecure configuration will contain wildcard perit statements like "P TP=* HOST=*" - in such cases all alarm bells should be ringing and this needs to be rectified as soon as possible.
In a simplistic scenario you will know the systems with which the you AS ABAP system is communicating and will be able to explicitly add those to the reginfo and secinfo ACLs. In order to do that you will need a basic understanding of the different rule parameters and syntax.
Reginfo
Rule syntax: TP= [HOST=,...] [NO=] [ACCESS=] [CANCEL=]
TP - the registration identifier of the external program.
HOST - the hostname(s) from which the external programs are allowed to logon from. The keyword "local" means programs from the current host of the system (the same server on which the NetWeaver server is running right now) can connect to the Gateway. The keyword "internal" means programs that are running on any host of the current SAP system can connect to the Gateway. You can also enter either DNS names or IPs and use wildcards with those e.g. "*.mycorp.com" or "10.10.10.*"
NO - defines the number of registrations allowed by this particular rule.
ACCESS - defines the hostnames permitted to use the registered program.
CANCEL - defines a list of hostnames that can cancel the registration
Secinfo
Rule syntax: TP=<tp>, USER=<user>, HOST=<host>, [USER-HOST=<user_host>]
TP - the registration identifier of the external program.
USER - user name allowed to start the program
HOST - hostname(s) where the program can be started. The keywords "local" and "internal" have the same meaning as in the reginfo specification.
USER-HOST - a list of hostnames from where the users can start the program.
In a realistic scenario there will be dozens of integrations and the system would be running for quite some time already. Doing direct changes to a production system may yield a lot of trouble and service downtimes. Therefore, it is recommended first switch on the Gateway logging and identify all programs and servers which already connect to the system. On the basis of a continuous logging, a restrictive system list can be created and applied as reginfo and secinfo ACLs.
In order to switch on the Logging go back to SMGW and navigate to Goto --> Expert Functions --> Logging.
Ensure that Security-related events are logged accordingly.
Keep logging the Gateway events for a month in order to ensure that all possible active system interactions have happened at least once and the respective log entries have been generated (consider quarter-end closings and integrations which may be triggered possibly on a quarterly basis only). After the logging phase, execute transaction AL11, navigate to the "work" folder and assess the Gateway logs.
Export all logs, deduplicate entries and create the respective reginfo and secinfo ACL rules.
See also the following SAP Notes for more details: 821875, 1421005 and 1408081.
Measure #3: Critical Authorizations
SAP Authorizations and Roles is a full-time job because of the high complexity of the topic. Nevertheless, here we want to address the low hanging fruits and mitigate any identified issues. We will start with the most common administrative profiles and validate which users are assigned those profiles. The two commonly used overprivileged SAP profiles are SAP_ALL and SAP_NEW.
In order to do this you need to call transaction SA38/SE38 and execute report RSUSR002
Navigate to the "Roles/Profiles" tab and under "Profile Name" enter "SAP_ALL". Execute the report in order to get a list of all users assigned the profile "SAP_ALL".
Navigate to the "Roles/Profiles" tab and under "Profile Name" enter "SAP_ALL". Execute the report in order to get a list of all users assigned the overprivileged profile "SAP_ALL".
Assess the list and remove the profile from those users - in general no user account should have the "SAP_ALL" profile assigned. An exception may be the "SAP_NEW" profile which may temporarily be assigned for a system patch/upgrade activity. Repeat the same exercise also for the "SAP_NEW" profile.
Additionally we can look for privileged authorization objects which we consider critical. Here are some examples of critical authorisation objects:
S_TABU_DIS
S_TABU_NAM
S_TABU_CLI
S_DEVELOP
S_RFC
S_DATASET
S_USER_AGR
S_ADMI_FCD
In the same manner as before, we execute transaction SA38 and then report RSUSR002. We navigate this time to the "Authorizations" tab and enter a critical authorizations object.
Executing the report would output the list of users possessing the particular critical authorizations object.
We can do this same exercise for the rest of the authorizations objects we consider critical and question the assignment of those permissions to the particular users.
Critical authorizations in SAP systems can be additionally assessed through the report RSUSR008_009_NEW.
Measure #4: Network Segregation
SAP NetWeaver systems should be isolated network-wise in trusted and secure network segments. SAP NetWeaver systems expose per default numerous network-enabled services which allow communication and thus provide a large attack surface. In the past, numerous security issues have been identified relating to such services. Here are some examples of network TCP ports used by such SAP system services:
*<NN> stands for the instance number of your system
32<NN> - Dispatcher (e.g. if the instance number <NN> is 01 then the respective dispatcher port on the system would be 3201)
33<NN> - Gateway
36<NN> - Message Server
80<NN> - Internet Communication Manager (ICM) HTTP
443<NN> - Internet Communication Manager (ICM) HTTPS
5<NN>13 - sapctrl (Management Console
5<NN>14 - sapctrls (Management Console - secure communication)
Consider that system related databases and operating systems also expose network services which may require network isolation as well. The following diagram depicts a simplistic example of the the target state. Administration of the SAP systems should be possible over dedicated administrative jump hosts which enforce strong authentication and monitoring. Access to the SAP system from less trusted network segments need to be reduced to a minimum - in the example below - only to the HTTPS port of the system is exposed to the End-user network segment (e.g. the Corporate network).
In a more realistic example the Dispatcher service on port 32<NN> may need to be accessible if End-Users also connect to the system over SAP Logon / SAP GUI, using the DIAG protocol. Additionally, port 33<NN> may need to be open for communication to other systems outside the Administrative Network Segment to integrate over RFC. Nevertheless, here the recommendation is to use "point-to-point" IP restriction rules on the firewall and allow communication only between the two respective systems on the respective RFC port.
Measure #5: Patch Management
Needless to say, implementing a rigorous path management process for any system is of utmost importance to the system's security. SAP systems though are often in the heart of business processes and downtimes and disruptions are highly undesirable. Therefore, SAP NetWeaver patch management becomes often a tedious planning process with irregular cycles, carefully analysing every change which each patch/note introduces.
SAP has come a long way in terms of patching products and fixing reported security issues. SAP has established a monthly Patch Day on every second Tuesday of the month.
You can get more information on released patches under the following link:
You can check the installed versions of the different system components over SAP GUI. Login to the system and navigate to More --> System --> Status. Then click on the small magnifying glass icon marked on the screenshot.
The SAP Solution Manager would be usually the tool of choice for managing and scheduling of the patch processes.
You need support your SAP systems? Contact Us! We help enterprises plan secure IT infrastructures, assess IT services, mitigate risks and run compliant operations.
Related Articles:
You found the content of this post useful? Register for our Newsletter below to receive email notifications about new posts like this one.