Seguridad de puerta de enlace RFC, parte 8: ejecución de comandos del sistema operativo mediante sapxpg

Desde mi experiencia, la seguridad de RFC Gateway es para muchos administradores de SAP un tema que aún no se comprende bien. Como resultado, muchos sistemas SAP carecen, por ejemplo, de ACL definidas adecuadas para evitar el uso malicioso.

Después de que se publicara un vector de ataque en una charla de Mathieu Geli y Dmitry Chastuhin en OPDCA 2019 Dubai (https://github.com/gelim/sap_ms) la seguridad de RFC Gateway es aún más importante que nunca. Esta publicación atrajo una atención pública considerable ya que 10KBBLAZE.

Con esta serie de publicaciones de blog, trato de dar una explicación completa de RFC Gateway Security:

Parte 1: Preguntas generales sobre la puerta de enlace RFC y la seguridad de la puerta de enlace RFC.
Parte 2: reginfo ACL en detalle.
Parte 3: secinfo ACL en detalle.
Parte 4: prxyinfo ACL en detalle.
Parte 5: ACL y la seguridad de RFC Gateway.
Parte 6: Registro de puerta de enlace RFC.
Parte 7: Comunicación segura
Parte 8: Ejecución de comandos del sistema operativo usando sapxpg

Actualizaciones:

---

Como habrá leído en la parte 1 de esta serie, iniciar un programa en el nivel del sistema operativo es una tarea interactiva. Esto significa que, en el nivel del sistema operativo, la llamada de un programa siempre está esperando una respuesta. Y en muchos casos, el código de retorno del programa ejecutado es relevante para su posterior procesamiento en ABAP. Si el programa llamado en el nivel del sistema operativo no es un programa habilitado para RFC (compilado con la biblioteca RFC de SAP), no hay un canal posterior para completar el código de retorno y, además, la conexión RFC utilizada para iniciar el programa puede agotarse, mientras que el programa todavía se está ejecutando en el nivel del sistema operativo.

Para superar esta situación, sapxpg Fue presentado.

¿Cuál es el propósito de sapxpg?

sapxpg es un programa habilitado para RFC (o programa de servidor RFC) que se utiliza como contenedor para ejecutar comandos o programas en el nivel del sistema operativo fuera de la pila ABAP. Mantiene abierta la conexión con la puerta de enlace hasta que finaliza el comando en el nivel del sistema operativo y envía el código de retorno a la pila ABAP para su posterior procesamiento.

¿Dónde encontramos sapxpg?

Si bien este programa se envía como sapxpg o sapxpg.exe con SAP Kernel, también se puede encontrar en un SAP RFC Gateway independiente o incluso como un ejecutable independiente en cualquier host.

¿Cuándo está involucrado sapxpg?

Al ejecutar programas externos:

Los programas externos son comandos del sistema operativo o programas/scripts ejecutables que se especifican directamente en un paso de un trabajo por lotes:

Tenga en cuenta: esto solo debe ser realizado por usuarios administrativos. El objeto de autorización S_RZL_ADM:ACTVT=01 debe asignarse al usuario correspondiente, pero No ¡Se lleva a cabo una verificación de autenticación adicional!

Al ejecutar comandos externos

Los comandos externos creados en la transacción SM49/SM69 se pueden iniciar en un paso de un trabajo por lotes:

Además, los comandos externos pueden ejecutarse directamente en SM49/SM69 o desde la codificación ABAP a través de FM SXPG_COMMAND_EXECUTE_LONG, SXPG_CALL_SYSTEMo SXPG_COMMAND_EXECUTE.

Tenga en cuenta: cuando se ejecutan comandos externos, se realiza una verificación de autorización para S_LOG_COM. El objeto de autorización S_LOG_COM permite especificar el comando externo, el proveedor del sistema operativo y el host de destino. Si todos esos campos usan el comodín «*», cualquier comando externo se puede ejecutar en cualquier host.

Existe un mecanismo de seguridad mejorado que permite restringir los programas o comandos del sistema operativo que pueden ser ejecutados por sapxpg en general. Esto se describirá en otra parte de esta serie.

¿Por qué está involucrada la información de seguridad de la puerta de enlace?

Como sapxpg actúa como un cliente RFC para devolver el código de retorno a ABAP, el archivo secinfo necesita las entradas relevantes que permitan esta comunicación. Por ejemplo,

P USER=* USER-HOST=local HOST=local TP=sapxpg
P USER=* USER-HOST=internal HOST=internal TP=sapxpg

Típicamente sapxpg ya está cubierto por las entradas predeterminadas:
P USER=* USER-HOST=local HOST=local TP=*
P USER=* USER-HOST=internal HOST=internal TP=*

Cuando se utilizan comandos o programas externos en trabajos por lotes, ¿las autorizaciones de qué usuario son relevantes?

Para trabajos por lotes que inician comandos externos, el archivo auth. check requiere que además del usuario de programación también el usuario de paso debe tener S_RZL_ADM:ACTVT=01 asignado.
Este comportamiento seguro por defecto debería no ser cambiado.

Al crear o copiar un trabajo donde se llama a un programa externo, se verifica si el usuario del paso tiene el objeto de autorización S_RZL_ADM asignado.
Este comportamiento seguro por defecto debería no ser cambiado.

Al crear o copiar un trabajo donde se llama a un programa externo, se puede habilitar una verificación de autenticación adicional. Esto verifica si el usuario de programación tiene el objeto de autorización S_LOG_COM también asignado, mientras que para el usuario del paso esto siempre está marcado.

Sugerencia: para habilitar esta verificación, crear las siguientes entradas en la tabla BTCOPTIONS:
BTCOPTION = LOGCOMM_AUTHCHECK
VALUE1 = ON

¿Sapxpg admite conexiones seguras SNC?

Para usar la comunicación segura SNC entre RFC Gateway y sapxpglas siguientes entradas deben realizarse con informe BTC_SAPXPG_SNC en la tabla BTCOPCIONES:
BTCOPTION = SAPXPG
VALUE1 = SNC
VALUE2 = <SNC partner name of the gateway>

Tenga en cuenta: Al momento de escribir, VALUE2 tiene un límite de 40 caracteres que puede ser insuficiente. Como solución temporal, siga los pasos descritos en Nota SAP 1362020.

<– Anterior

Siguiente –>