Controlando los accesos remotos a MQ con Racf

Todo lo relacionado con MQ en ambiente OS/390 o z/OS
Responder
CPO

Controlando los accesos remotos a MQ con Racf

Mensaje por CPO » 04 Feb 2004, 18:06

Tenemos una duda de cómo securitizar una cola local en 390, para evitar que le pongan mensajes desde MQSeries client.
Vimos una demo de share que dicen usar la clase MQCONN y el PROFILE= CSQD.CHIN , probamos y no anda.
Quien nos podria dar una mano?


A continuación ....
Les adjunto la consulta elevada al laboratorio de IBM y la respuesta recibida.

Customer would like to secure a Local Queue in his MQseries OS/390 R2.10,
trying to avoid messages input from Windows 2000 MQseries client.

Customer has defined in RACF the following profile:
CLASS=MQCONN PROFILE= CSQD.CHIN UACC=NONE ACCESS LIST= USERTEST

ACTIVE CLASSES =
MQQUEUE GMQQUEUE MQPROC GMQPROC MQNLIST GMQNLIST MQADMIN

The MQseries user has the following Permits:

MQCONN CSQD.BATCH UACC(NONE)
MQCONN CSQD.CICS UACC(NONE)
MQCONN CSQD.CHIN UACC(NONE)
MQCONN CSQD.** UACC(NONE)

PE CSQD.** CLA(MQCONN ) ID(MQMSTC ) ACC(READ )
PE CSQD.BATCH CLA(MQCONN ) ID(MQMSTC ) ACC(READ )
PE CSQD.BATCH CLA(MQCONN ) ID(GTSOUSER) ACC(READ )
PE CSQD.CICS CLA(MQCONN ) ID(MQMSTC ) ACC(READ )
PE CSQD.CICS CLA(MQCONN ) ID(CICSD ) ACC(READ )
PE CSQD.CHIN CLA(MQCONN ) ID(USERTEST) ACC(READ )

USER=MQMSTC NAME=STC OF MQSERIES OWNER=GRESTC CREATED=00.229
USER=CICSD NAME=USER OF THE CICSTEST OWNER=GRESTC CREATED=98.324
USER=USERTEST NAME=TEST MQSERIES CLIENT OWNER=GRESTC CREATED=00.229

LG GTSOUSER
INFORMATION FOR GROUP GTSOUSER
SUPERIOR GROUP=SYS1 OWNER=SYS1
INSTALLATION DATA=GROUP BASIC FOR ALL USERS TSO
NO MODEL DATA SET
TERMUACC
NO SUBGROUPS
USER(S)= ACCESS= ACCESS COUNT= UNIVERSAL ACCESS=
RT02 USE 000630 NONE
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
XXXX
..
..
XXXX

Customer understood that all client users are controlled by: CLA( MQCONN )
CSQD.CHIN
but, any MQseries client CAN transmit messages to Local Queues
without any problem, it acts like RACF is inactive or no profiles
were defined. Nobody in the client enviroment has RACF user defined.

If a RACF user (S/390) attempt transmit a message to a MQ Local Queue,
it will fail because of RACF related profiles in MQ Classes.

MCAUSER is not defined.

SEARCH CLASS(MQADMIN) MASK(CSQD.NO)
ICH31005I NO ENTRIES MEET SEARCH CRITERIA


***************
***************


The approved method for protecting client channels is to create
and define a security exit for the channels.

The logic in the exit can be any suitable logic which identifies
the user as an authorized user of the channel.

For example,
it could cross-reference the signed on userid with a TSO userid and pass that in the MD.

Please refer to:
- WMQ Clients book.
- WMQ Intercommunication Guide. ( How to write the exit )


Regards, Beverly


Tambien les adjunto el dialogo sostenido con Mario Bolo ( Certified IT Architect IBM Argentina - SWG - Especialista en MQ )
De este modo, evitarán pensar en alternativas que ya fueron probadas.
Es largo, pero les va dar un panorama de lo actuado.

Pueden Leer el dialogo tal como aparece, porque ya reacomodé toda la cadena de mails.
Muchas Gracias.



Mario:
La clase que usamos fue la MQCONN con UACC(NONE) y definiendo un profile CSQD.CHIN y sin usuarios en su access list.
Esta acción no fue suficiente para frenar los mensajes desde MQSeries
client.
Cabe aclarar que aun no hemos avanzado demasiado, en la revisión de la configuración de seguridad del producto.
Muchas Gracias.
Carlos Pose - Seguridad Informática


Carlos:
Lo único que se me ocurre es que haya algún switch definido para desactivar los controles de seguridad sobre el queue manager. Chequeen que no haya algún profile CSQD.NO definido, usando el siguiente comando:
SEARCH CLASS(MQADMIN) MASK(CSQD.NO)
Si lo hay deberían eliminarlo porque esos switches anulan los controles de
seguridad sobre los diferentes recursos de MQ. Por favor chequeen eso y
díganme como resultó.
Saludos / Best Regards
Lic. Mario E Bolo


Mario:
No existe tal switch.
SEARCH CLASS(MQADMIN) MASK(CSQD.NO)
ICH31005I NO ENTRIES MEET SEARCH CRITERIA
***
Solo tenemos definido:
CSQD.** MQADMIN UACC(NONE)
CSQD.CONTEXT MQADMIN UACC(NONE)
y en la access list, solo existen usuarios relacionados con la
administración y algunas STC del producto.
Gracias.
Carlos Pose - Seguridad Informática


Carlos:
Estarán activadas las clases de seguridad ? Probá con este comando:
SETROPTS CLASSACT(MQADMIN,MQQUEUE,MQPROC,MQNLIST,MQCMDS,MQCONN)
Saludos / Best Regards
Lic. Mario E Bolo


Mario:
Todas ellas, están activas.
Mañana temprano preparo algo, y te mando un resumen de todas las
definiciones relacionadas.
Sería interesante también, chequear algunos parámetros de configuración
del MQ.
Hoy me comentaban que algunos controles solo se conseguían aplicando una exit, aunque no me parece que este sea el caso.
ACTIVE CLASSES =
MQQUEUE GMQQUEUE MQPROC GMQPROC MQNLIST GMQNLIST MQADMIN
GMQADMIN MQCMDS MQCONN
No se que pasaría con estas dos, porque no las tengo: ( Existen ? )
GMQCMDS GMQCONN
Lo que puedo agregarte es que el control de comandos, si está funcionando de manera adecuada. ( Desde el Host )
Gracias.
Carlos Pose - Seguridad Informática


Carlos:
Todo parece estar OK. Lo que me estoy preguntando ahora es: cual será el userid asociado con los requerimientos que vienen de los clients ? Me
pregunto si no será el userid asociado con el address-space del channel
initiator. Si los clientes corren bajo Win 98 es casi seguro que no están
seteando un userid y por lo tanto usa el del CHIN. Verificá eso... En una
de esas los controles funcionan, pero simplemente ocurre que el usuario
asociado con el requerimiento está autorizado a hacer un MQCONN al
queue-manager.
Saludos / Best Regards
Lic. Mario E Bolo


Mario:
Estos serían todos los permisos del usuario del MQ
CSQD.** MQCONN MQMSTC READ
CSQD.BATCH MQCONN MQMSTC READ
CSQD.CICS MQCONN MQMSTC READ
Debería tener definido este profile ?
CLA( MQCONN ) CSQD.CHIN
Las transmisiones del cliente, no deberían validar contra ese recurso del
mismo modo que un browse desde TSO valida contra:
CLA( MQCONN ) CSQD.BATCH
Cualquier usuario tso que pretenda acceder una cola desde el 390 tiene que estar en esa lista de acceso.
Porque no ocurre lo mismo con los acceden desde el cliente ?
Que opinás de esto ?
Carlos Pose - Seguridad Informática


Carlos:
Entiendo que es tal como vos lo decís... Así como los usuarios de TSO
validan contra:
CLA( MQCONN ) CSQD.BATCH
los usuarios asociados con un cliente MQ validan contra:
CLA( MQCONN ) CSQD.CHIN.
Por lo que me dijiste en notas previas, ese profile lo tienen definido, de
modo que no tengo ni idea de porque no funciona. De todos modos, y para aclarar las cosas, lo que se está protegiendo con ese profile no es la
conexión del cliente al server, sino la conexión del programa cliente al
queue-manager. Me gustaría entender un poco más como es el entorno de prueba que están usando... Por lo que entiendo parece haber clientes MQ instalados en PCs. En estas PCs corren algún aplicativo (tal vez uno de los programas sample) que se conecta a uno de los queue managers del mainframe (el CSQD) y mete mensajes en una cola de ese queue manager. Esto es efectivamente así ?
Si la respuesta es "si" me temo que va a haber que hacer alguna consulta
afuera. Mi escasa ciencia acerca de la seguridad de los clientes MQ hasta
aquí llegó.
Saludos / Best Regards
Lic. Mario E Bolo


Mario:
El usuario que está haciendo las pruebas, y me refiero al que está sentado
en un puesto Windows 2000, no tiene y nunca tuvo un usuario válido para
Racf.
Esta persona, basándose en las dll que conforman el cliente MQ, realiza las transmisiones con todo éxito sin que pueda controlarlo con ninguna de las herramientas habituales de Racf.
Concretamente, se conecta lee y escribe colas sin usuario, sin password y
sin permisos. ( De Racf )
Como remate del "chiste" , recibo junto con los datos de la cola, el
usuario Windows que el utiliza en su puesto, pero que nada tiene que ver
con una autorización de Racf ,que se supone es el custodio de la
información que reside en las colas y a su vez en el Mainframe.
Todos los permisos que te describo en el mail anterior funcionan
correctamente cuando los requerimientos son internos dentro del Mainframe.
Si quiero acceder una cola desde un panel de TSO o desde Cics, todo
funciona Ok.
En este caso se requiere permisos para el recurso (1) y también para el
medio de conexión (2):
CSQD.AS.** MQQUEUE (1)
CSQD.BATCH MQCONN (2)
CSQD.CICS MQCONN
Si el usuario no cuenta con estos permisos ( ambos ) , la violación se
produce normalmente y el acceso es impedido
En cambio cuando se utilizan clientes remotos, nada de esto funciona.
Ni el permiso para acceder una cola determinada (1). ni la restricción para
usar un medio de conexión autorizado (2).
CSQD.AS.** MQQUEUE (1)
CSQD.CHIN MQCONN (2)
Si queres, pasame un teléfono y te llamo a la tarde para conversar sobre el tema.
Probablemente tenga más información, debido a que tenemos previstas más pruebas para hoy.
Carlos Pose - Seguridad Informática


Carlos:
Lo que decís en esta nota significa que el usuario con el que están
haciendo las pruebas tiene todos esos permisos ? Disculpá mi ignorancia en temas de RACF, pero que significa CSQD.* * ??? No significa que tiene
permisos de MQCONN al queue manager CSQD desde cualquier entorno ?
Saludos / Best Regards
Lic. Mario E Bolo


Mario:
El problema es que la validación contra CLA(MQCONN)CSQD.CHIN no funciona, lo cual me impide controlar los accesos.
Por eso creo que el origen del problema no es "Racf-Puro" y me inclino por algo relacionado con la configuración del MQ ( Exits de seguridad incluidas).
En la prueba que estamos realizando, se transmite desde un cliente MQ
instalado en un puesto de Windows 2000, sin informar ID ni PW y la
escritura de la cola se realiza con toda normalidad.
En el segmento de seguridad de esa cola, se aprecia el ID que se encontraba
logoneado en el puesto en el momento de la transmisión.
Estoy tratando de encontrar información relacionada con las exits de
seguridad de MQ, que me permitan controlar las transmisiones de los
clientes remotos. Cualquier dato que tengas sobre el particular será bien
recibido.
Carlos Pose - Seguridad Informática


Carlos:
No, este no es un tema de exits... Teóricamente al menos no hacen falta
exits para controlar los accesos.
Pensando y repensando en el problema me surgió una duda muy básica: será el profile CSQD.CHIN el que controla los accesos desde un cliente MQ ? Lo pregunto porque en ningún lugar lo encontré escrito con claridad. Sin duda alguna ese es el profile que entra a jugar en casos de distributed queuing (colas remotas) pero... entrará también a jugar en los casos de programas cliente ?
La única que se me ocurre es probar si funciona CLA(MQCONN)CSQD.BATCH para controlar los MQCONN de los programas cliente.
Saludos / Best Regards
Lic. Mario E Bolo


Mario:
La prueba que me planteas, ya la hicimos.
Todos los accesos que se realizan desde paneles de tso o requeridos por un job, validan contra CLA(MQCONN)CSQD.BATCH
Para los casos de transmisiones desde el cliente, no funciona.
Carlos Pose - Seguridad Informática


** THE END **

Capcop

Re: Controlando los accesos remotos a MQ con Racf

Mensaje por Capcop » 14 Abr 2005, 12:16

Que tipo de canal estas usando?...

Conexion de servidor (SVRCONN)?

Si es asi, este canal cuando seteas el ID MCA con un usuario que pertenece al grupo mqm, permite conectar a cualquier cliente.



javascript:emoticon(':shock:')
Shocked
:shock:

Alexis Gargurevich

Re: Controlando los accesos remotos a MQ con Racf

Mensaje por Alexis Gargurevich » 16 May 2005, 22:20

Para poder autenticar MQClients necesitas empezar a usar Certificados Digitales. La versión de MQ 4.3 ya incluye el uso de encripción del canal y Certificados.

Ahora, si no quieres usar esto puedes usar una Security Exit (SECEXIT).

Entiendo que son MQClients que se conectarán a un QManager que se encuentra instalado en un z/OS protegido por RACF. Una solución podría ser proteger las colas haciendo referencia a los DataSets referenciados por estas (Cola P.PRUEBA = DataSet P.Prueba). Necesitarás otorgar permisos de UPDATE tanto para hacer PUT y GET.

Si tu MQClient se encuentra en Windows, y la solicitud de información la realizas con un componente, ejecutable, servicio, etc., configura un usuario genérico que identifique a tu aplicación y firma la trama que envíes con este usuario, por ejemplo en el identity del componente. Asegúrate de que este usuario esté definido a nivel de dominio y en RACF con NOPASSWORD. Este es el usuario al que darás permiso en la cola.

Con la SECEXIT trasladas la identidad de este usuario hasta RACF. Tienes una SECEXIT dll en tu MQClient, y un programa en Assembler por ejemplo en z/OS para recibir los datos que te ayudarán a identificar tu MQClient.

Esto encaja muy bien cuando tienes un esquema en el que se han definido colas diferentes para cada aplicación que usa MQ, y por supuesto, usuarios diferentes.

Espero haber ayudado. 8)

Alexis Gargurevich
Seguridad Informática

David Segovia

Controlando los accesos remotos a MQ con Racf

Mensaje por David Segovia » 19 Feb 2007, 15:01

Estimados,
Me gustaria retomar este tema: Como evitar que le pongan mensajes desde un MQClient a un Server o directamente al host un usurio no autorizado... Al parecer la unica opción es utilizando SECEXIT...? Entiendo que a la fecha podrian existir nuevos SW externos, o alguna mejor configuración de MQM o RACF para solucionar este problema.

Debemos de consiserar que usando la protección de RACF debe de requerir alguna consideracion adicional, cuando se usan los usuarios STC para que un usuario del MQClient no autorizado utilice este usuario STC y obtenga la información.

Responder