Introducing SAP ICF Services: Concepts and General Considerations
The purpose of this blogpost is to introduce Internet Communication Framework services, also known as ICF services. ICF is an integrated component of the Application Server. From an architecture point of view, it is between the Internet Communication Manager (a.k.a ICM) and the HTTP (or HTTPS) enabled ABAP applications. It sounds similar, but it is not, because ICM communicates with the Internet through HTTP (and HTTPS) protocols. However, ICF are entry points for the HTTP enabled ABAP applications.;
In spite of the framework offered by SAP to configure each ICF service, it is more common to use the SICF transaction, where you can create and set up each service as per your preferences.
Related SAP Tables
There are two SAP tables related to ICF services. The first one is ICFSERVICE, which has two main columns: one to indicate the ICF service name, and another one to indicate its parent (see more information about ICF parents in the paragraph below). The second one is ICFSERVLOC, which has the same main columns as the previous table, and one extra column that indicates whether a service is active or not.
What Is the ICF Tree?
In transaction SICF you can see an ICF tree. There, it can be assumed that each ICF service has a parent and respects a hierarchy. When you create one, its location in the tree determines the path from which you can access it from a web browser. For example, for ICF service ITMVC2, the path is /sap/bc/bsp/sap/itmvc2 and the URL to use that service is <HOST>:<ICM_PORT>/sap/bc/bsp/sap/itmvc2. Of course, that node must be active to allow calls to that URL.
The ICF tree is built based on the information from the two tables mentioned before. It’s important to highlight that some ICF services may have the same name, however, their parents are not the same. Therefore, we can affirm that when being built, the ICF tree uses both main columns (name and parent id) to make sure which service is active. As an example, please see below image which shows two services with the same name, but under different parent nodes:
What Services Should Be Deactivated?
When an SAP AS ABAP is deployed, every ICF service is available, but in an inactive state. Having all services deactivated reduces the surface of possible attacks. Afterward, each SAP customer should decide which service to activate.
To know if ICF services are active or not, The Onapsis Platform has several vulnerability assessments that could be run to check those services. Also, there is a vulnerability assessment to retrieve the list of all ICF services that are enabled.
ICF Security Risks
Every ICF service that is active could potentially represent a security risk. It can be accessed directly from the Internet by HTTP protocol. Only the needed ICF services must be active and for specific users with restrictive authorizations.
Be careful with some services that do not require authentication, as all of them must be reviewed, including services with stored logon data. At Onapsis, we also have a vulnerability assessment to check if there is any ICF service with stored logon data. Contact us today for more information.
The authorization object that allows you to call an URL of an ICF service is S_ICF, so roles or profiles containing it should be assigned only to users that need it.
ICF services vs SAP Security Baseline
SAP Security Baseline is a document where it is detailed all the security settings that we should configure in our SAPs to be secure.
Regarding ICF services, it states everything we have already mentioned in this blog and the following two extra points:
- Review the ICF services which do not require authentication and use the report RSICFCHK
- As mentioned in several SAP Security Notes (#626073, #1394100, #1417568, #1422273, #1487606), the following services should be deactivated:
- /sap/bc/echo
- /sap/bc/FormToRfc
- /sap/bc/report
- /sap/bc/xrfc
- /sap/bc/xrfc_test
- /sap/bc/error
- /sap/bc/webrfc
- /sap/bc/soap/rfc
- /sap/bc/bsp/sap/certreq
- /sap/bc/bsp/sap/certmap
- /sap/bc/gui/sap/its/CERTREQ
- /sap/bc/gui/sap/its/CERTMAP
- /sap/bc/bsp/sap/bsp_veri
- /sap/bc/bsp/sap/icf
- /sap/bc/IDoc_XML
- /sap/bc/srt/IDoc
Inconsistencies in the ICF Tree and How to Fix It
When creating or deleting an ICF service’s node from the SICF tree, it should be changed in the source system and then transported to every system in the same landscape. This should keep the consistency in the ICF service hierarchy.
Some actions that should not be done to avoid inconsistencies are, for example, transporting a node from outside the landscape or manually create an ICF node in a system that is not the source one. Such actions could create inconsistencies in the ICF structure, which could lead to malfunction of transaction SICF, unexpected behavior of an ICF service, or even missing an ICF service. The following is an example of a corrupted system where ICFSERVLOC table has one more register of an ICF service called “ICF” with its Node Parent ID being “0N4PS1S4RGLHN7IW9R54I61RZ”. This will cause inconsistencies in the ICF tree because both main tables have different quantity of entries:
In case you need to check for any inconsistencies, SAP provides a report called ICFTREE_CONSISTENCY. Afterward, to fix the inconsistencies found, the function module REPAIR_HTTPTREE will reorder the “lost nodes” and delete the services that do not appear in the two tables we have mentioned before in this blog. If you need any of the deleted services in that system, you should transport them from the source system again.
Conclusion
At Onapsis, we are committed to providing our customers with the best recommendations and solutions for the security of their SAP systems. Good use of ICF services is important to avoid inconsistencies, and it assures integrity between the affected tables. As mentioned before, SAP recommends not only in its Security Baseline, but also in related security notes, the importance of maintaining those services.
Learn more about how The Onapsis Platform can protect your business-critical applications.