Seventh critical issue in SAP Security landscape: Unencrypted connections. To protect connections between the SAP NetWeaver system components, especially against the man- in-the-middle (MITM) attacks, it is necessary to ensure SAP security at the transport level. While using the Transport Layer Security (TLS), the data transmission may be protected from eavesdropping not only with encryption, but also with the partner authentication.
TLS provides the following types of protection:
- Authentication: Communication partners may go through authentication. The server is always authenticated, while the client is authenticated depending on the algorithm.
- Data integrity: Message exchange is protected so that any modification is revealed.
- Data confidentiality: The data transmitted between the client and the server is encrypted, thus confidentiality is ensured. Eavesdropper is not able to get access to the data. Protection is available for inbound and outbound connections.
There are two forms of protection, depending on the used connection type. For connections using the Internet protocols such as HTTP, Secure Sockets Layer (SSL) protocol is used. For the SAP protocols such as RFC, Secure Communications Network (SNC) is used.
This section contains the detailed encryption settings for various services. However, you should understand that, even if the encryption is enabled, it does not necessarily mean that it is always securely configured. For each type of encryption, in each particular case there are various settings to be fine-tuned. For example, recent BEAST and CRIME attacks on the SSL showed that more SSL fine-tuned settings are necessary . That is why you should be very careful careful while configuring encryption, considering new attack types and peculiarities of the service.
[EASAI-NA-25] The SSL encryption to protect HTTP connections
SSL supports the following protocols:
- HTTPS from HTTP,
- IIOPSEC from the IIOP,
- P4SEC from the P4.
Note that we take into consideration only the HTTP, as IIOP and P4 belong to the JAVA stack. In the ICM service parameter icm/server_port_<xx>, the protocol and the port are specified, where <xx> is the ordinal number of parameter. This parameter is used to specify the service name or port number to be applied to by the protocol. Also, additional service properties can be defined. But one port cannot have more than one service assigned to it. Besides, the service can not start when another program is already using this service or port. Parameter line has the following syntax: PROT = <protocol name>, PORT = <port name> [, TIMEOUT = <timeout>, PROCTIMEOUT = <proctimeout>, EXTBIND = 1, HOST = <host name>, VCLIENT = <client SSL Verification>, SSLCONFIG = ]. Mandatory to be defined are the following parameters: protocol name (PROT) and service name or port number (PORT), other parameters are optional. Default system values for this parameter depend on the system type which is specified by the system/type parameter. The following types are available:
- Double stack: system/type = DS (currently out-of-date). The instance contains AS ABAP and Java AS application servers:
- icm/server_port_1 = PROT=P4,PORT=5$(SAPSYSTEM)04
- icm/server_port_2 = PROT=IIOP, PORT=5$(SAPSYSTEM)07
- icm/server_port_3 = PROT=TELNET,PORT=5$(SAPSYSTEM)08,HOST=localhost
- icm/server_port_4 = PROT=SMTP,PORT=0,TIMEOUT=120,PROCTIMEOUT=120
- Java only: system/type = J2EE (not covered by this document). The instance contains the Java AS application server only.
- ABAP only: system/type = ABAP. The instance contains the ABAP (AS ABAP) application server only.
- icm/server_port_0 = PROT=HTTP,PORT=0,TIMEOUT=30,PROCTIMEOUT=60
- icm/server_port_1 = PROT=SMTP,PORT=0,TIMEOUT=120,PROCTIMEOUT=120
If there is no encryption of network connections, this can lead to unauthorized access to the data being transmitted by means of interception. HTTP protocol transmits all authentication data as a plain text, that allows to intercept it easily using the spoofing type of attack.
For HTTP connections, you should configure SSL. Detailed step-by-step instructions for this process may be found in the paper SSL Configuration in SAP ABAP AS and JAVA AS – Step-by-step procedure Available: .
[EASAI-NA-26] The SNC encryption use to protect the SAP GUI client connections
SNC (Secure Network Communications) is a software layer in the SAP solution architecture. It supplies secure interface for external products. In particular, it is responsible for encryption and authentication. SAP solutions contain basic security controls including password-based user authorization and authentication concepts. With SNC in place, the SAP security can be improved by implementing additional security functions. Those functions are not provided openly by SAP solutions. It is, for example, the use of smart cards for user authentication, additional digital and encryption certificates. There are three security levels that can be applied. snc/data_protection/use parameter is responsible for this (by default it is set to 3 and shows standard connections protection level). Respectively, snc/data_protection/max and snc/data_protection/min show maximum/minimum protection level. So, those values show:
- Authentication only (snc/data_protection/use=1). The system authenticates communication partners. It is the minimum security level provided by the SNC. Data protection is not ensured!
- Integrity protection (snc/data_protection/use=2). The system detects any data modifications (manipulations) that may occur between the two communication endpoints.
- Data confidentiality protection (snc/data_protection/use=3). The message encryption system makes the eavesdropping useless. This level also includes the data integrity protection. It is the maximum security level provided by the SNC.This level also includes data integrity protection.
The snc/enable parameter defines whether the SNC protection is used for connections.
- The default value is: 0 (inactive SNC).
- The secure value: 1 (active SNC)
As soon as the SNC is active (snc/enable = 1), the system starts accepting the SNC-protected connections only. If there is a need to accept a normal connection which is not protected by the SNC, it is necessary to set the appropriate parameters (snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/accept_insecure_cpic) depending on the types of connections to be accepted insecurely.
If there is no encryption of network connections, this can lead to unauthorized access to the data being transmitted by means of interception. HTTP protocol transmits all authentication data as a plain text, that allows to intercept it easily using the spoofing type of attack. If SNC encryption is not set, this can lead to unauthorized access to data transmitted between the systems using DIAG and RFC protocols. those protocols do not use data and passwords encryption, they use insecure compression algorythms. It is quite easy to decode those algorythms using free tools available on the Internet. This, in turn, allows to intercept passwords and get unauthorized access to system.
Set the snc/enable parameter to 1 to enable encryption, thus mitigating the risk of unauthorized access. Besides, the SNC User’s Guide  recommendations may be useful here.
[EASAI-NA-27] The SNC encryption to protect RFC connections between systems
SAP systems can connect to the other SAP systems, or non-SAP systems using two basic methods:
- by the Internet Communication Framework (ICF) that allows to use the HTTP, HTTPS or SMTP, or
- by the Remote Function Call (RFC) which may be called directly in the system.
RFC is the SAP own interface necesary for integration of SAP system and non-SAP system software. RFC calls a function to be executed in a remote system. Other integration technologies, such as web-services, are optional in RFC. Currently, there is a whole range of various RFCs, each of them with various properties and used for specific purposes. To ensure security of RFC connections, a wide range of measures can be implemented, but in this article we describe encryption only.
RFC-functions called for via RFC protocol may transmit confidential data (e.g., passwords or payment card numbers). When using RFC without encryption, there is a risk that this data will be available as a plain text. If SNC encryption for RFC connections and SSL encryption are not used for HTTP connections between the ABAP-based systems, it makes it possible for an intruder to get access to sensitive data by intercepting it with a spoofing attack.
It is recommended to carry out an analysis of a list of RFC connections between ABAP-based systems and verify those of them that require the use of SSL and SNC. For protection purposes it’s better to prevent connections with ABAP-based systems. Using SM59 transaction to manage RFC and its SNC settings, you can define the following SNC data:
- SNC mode for connection (active or inactive);
- quality of protection (QoP);
- SNC partner name.
Other essential SNC settings (SNC AS name, external library location, maximum and default QoP), as mentioned above, are defined in the application server instance profile (these are profile parameters at the AS ABAP). To enable SNC for RFC adapter and the SAP system, it is necessary to install the certificate to the server. After that, on the RFC control screen (SM59 transaction), select the Change option and go to the Security & Logon tab. There, on this tab go to Edit –> SNC Options. In the appeared dialog window SNC extension: Details make the following changes:
- Enter the quality of protection in the QOP field.
- Enter the SNC communication partner name in the Partners field (if the start of external server program is defined at the application server or at the front end workstation, the SNC partner name will be received automatically from the existing safe route, with no need to specify it).
- Save the SNC settings.
- Return to the initial screen and enable SNC.
For the cases, where SSL is needed, it is recommended to perform the following actions:
- execute the SM59 transaction;
- select connection for which SSL is required;
- in the Logon/Security tab, set the SSL option to Activate;
- save changes.
Well, it’s high time we finish the article. We hope you like it. Remember that you can always check out a demo version of our product by the following link.