SNC: Protecting SAP Communication Channels

Why SNC?

SAP systems include a reduced set of security features, which cover the SAP authorization concept and user authentication based on passwords. SNC is a software layer in the SAP Netweaver system architecture that provides an interface to an external security product offering stronger authentication methods, by encryption and by single sign-on mechanisms allowing SAP customers to extend SAP system security beyond the built in set of features shipped with SAP.

Keep in mind SNC is not a security product by itself. It only provides an interface to external security products which must implement any desired functionality in a manner defined in the standard interface GSS-API V2 (Generic Security Services Application Programming Interface Version 2). SNC uses this interface to communicate with an external security product (usually a library).

SAP provides free-of-charge libraries that can be used for the encryption of server to server communications as well as communications between SAP GUI and the SAP Application Server ABAP.

Levels of Protection

SNC can be used to secure the data communication paths between the various SAP Systems. There are three levels of security protection you can apply.
Authentication only – When using the Authentication only protection level, the system verifies the identity of the communication partners. This is the minimum protection level offered by SNC.
Integrity protection – When using Integrity protection, the system detects any changes or manipulation of the data which may have occurred between the two end points of a communication.
Privacy protection – When using Privacy protection, the system encrypts the messages being transferred to make eavesdropping useless. Privacy protection also includes integrity protection of the data. This is the maximum level of protection provided by SNC.

When should you use SNC?

SNC can be used in RFC based communication. Two types of RFC destinations can be encrypted:

  • For the communication path between two SAP Systems when using RFC. In this case, the calling SAP System is the initiator of the communication while the SAP System defined as the RFC destination is the acceptor.
  • For internal RFC destinations although there could be a significant performance degradation so its use is not recommended, for performance reasons.

When not to use SNC

  • SNC protection only applies to connections that use SAP protocols such as DIAG, RFC or CPIC protocols. For Internet protocols, use SSL/TLS for protection.
  • Also, you cannot apply SNC protection between your application servers and your database. Instead, keep your application and database servers in a secured LAN that is protected with a firewall and SAProuter.

Testing Your SNC Installation

Once you successfully installed and configured SNC on two SAP systems by following one of the several tutorials you can find online (for example: http://goo.gl/oyfvlY), you are ready to test the installation.
We will test the communication path between two SAP Systems when using RFC, that’s why you needed to install and configure it in two of your SAP systems, by following these steps:

  1. Allow SNC RFC connections that come from the initiator in the acceptor system. So as to do so:
    1. Connect to the acceptor through SAPGUI and start Transaction SM30 and enter the view VSNCSYSACL.
    2. This view is used to restrict the SNC RFC Connections by an Access Control List (ACL). You will see an alert window pop-up, just click on the “right” symbol.
    3. Choose E for the Type of ACL entry.
    4. Enter System ID and SNC name (do not forget the p: in front of the DN).
    5. Check the boxes ‘Entry for RFC activated’ and ‘Entry for CPIC activated’.
    6. Save the entry.
  2. Configure the acceptor as an RFC destination in the initiator. In order to do so, connect to the initiator through SAPGUI using the transaction SM59:
    1. In the ABAP Connection node press ‘create’ and fill in the RFC Destination field. Then fill the ‘Logon & Security’ tab with the destination server’s log-on information and the ‘Target Host’ and ‘System Number’ fields in the ‘Technical Settings’ tab.
    2. Click on the ‘SNC’ button, fill in the QoP field and the SNC Names section’s partners field with exact Distinguished Name field of the destination server (do not forget the ‘p:’ in front of the name).
    3. Save and then activate SNC.
  3. Now you can use the buttons ‘Remote Logon’ and ‘Connection Test’ to actually test the connection.

In order to test the differences between using and not using SNC, run the command tcpdump in the initiator as follows:
tcpdump src port -i eth1 -XXX -w
With XX the corresponding instance number.

Then, press the ‘Connection Test’ button described in step 3. The captured packets will be saved in a pcap file called <pcap_filename>. Loading this file into wireshark, we can see some information is disclosed when SNC is deactivated. In this particular case, the information corresponds to the acceptor’s TP Name:

Sniffing Acceptor's TP Name

We can verify the same information is disclosed if we run the same command in the acceptor, filtering the connection by the corresponding port.
Instead, when using SNC, this information is not found:

Sniffing Acceptor's TP Name not possible with SNC support active

Helpful stuff when errors occurs

Share Button

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>