| Author |
Message
|
| marcioalcantara |
 Posted: Thu Jan 29, 2004 1:05 pm Post subject: Is secure using WMQ Client/Server from Windows to Mainframe? |
 |
|
Novice
Joined: 25 Jun 2001
Posts: 23
|
Hi, All.
I have a question about security on WMQ 5.3.x. We are looking for how we will communicate from applications under Windows or Unixes machines to our WMQ Server in Mainframe. I know that we need to have Client Attachment Feature (CAF) to allow this communication style, but our main preocupation is how secure that topology is it?
We don't use yet WMQ Client with SSL.
Thanks a lot. |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Fri Jan 30, 2004 12:58 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Client access without additional products or SSL can never be secure!
A client can come from anywhere and can pretend to be who it wants to be, like for example mqm or MUSR_MQADMIN...
Unless you put restrictions on the SVRCONN channel you can not be sure the client is the one you think it is. a good start is BlockIP2 (see news/updates). next is some authentication handshake, you can use SSL for that or buy a third party tool like SPAZIO datasecure or Candles MQSecure (now called PathWay something)
I hope this helps...
*** modified... just noticed you mention CAF, BlockIP2 is not available for z/OS... sorry
Michael |
|
| Back to top |
|
|
| offshore |
| Posted: Fri Jan 30, 2004 4:09 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
marcioalcantara,
The Windows/Unix boxes communicating to the Mainframe are they the end users system or do they have a QMGR running with channels defined to the mainframe?
If you are truely using CAF and the SVRCONN channel there isn't much security there.
If you have QMGR defined on the Windows/Unix boxes with define channels you can alter the PUT AUTHORITY on the recieving side channel definition to Context.
It will check the UserIdentifier field of the MQMD. By default it uses Default which pretty much lets anything put to a queue if you don't have MCA User ID configured. - This is explained in the MQSC Command Reference book under define channel.
Just have your RACF/ACF2/TopSecret security group set up the appropriate security for the Mainframe queues.
If the message is passed with an ID that doesn't have access to the queue it will be placed in the DLQ.
Just an a thought. |
|
| Back to top |
|
|
| marcioalcantara |
| Posted: Thu Feb 26, 2004 11:17 am Post subject: |
|
|
Novice
Joined: 25 Jun 2001
Posts: 23
|
Thank you for the support.
I'll consider your comments.
Bye. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 26, 2004 3:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
If you have QMGR defined on the Windows/Unix boxes with define channels you can alter the PUT AUTHORITY on the recieving side channel definition to Context.
It will check the UserIdentifier field of the MQMD. By default it uses Default which pretty much lets anything put to a queue if you don't have MCA User ID configured. - This is explained in the MQSC Command Reference book under define channel.
|
It is very simple for a user on Windows to create a user called "mqm", log on with that ID, and completly defeat the whole purpose of setting the channel to PUT AUTHORITY. All this does is give you a tremondous workload in order to maintain all the legitimate IDs, and does nothing to stop the bad guy.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| pgorak |
| Posted: Fri Feb 27, 2004 1:45 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
True, but can't one simply use a non-blank MCAUSER on the server-connection channel and set this to a USER ID that does not have access to MQSeries objects? This is at least what the manual says. Of course, this does not prevent an incoming connection from an unknown IP address.
Piotr
_________________
***
IBM Certified Solution Developer WebSphere MQ 5.3 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Feb 28, 2004 9:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
My comments were specific to RCVR channels, not SVRCONN channels, since SVRCONN channels do not have the PUT AUTHORITY attribute.
But with SVRCONN channels, if you leave the MCAUSER field blank, you get the same behaviour as if there was that attribute and it was turned on.
Hard coding is the MCAUSER to a value is better than leaving it wide open, but then you force everyone to run with that ID and thus everyone has the same rights. That could be OK or not.
The only real solution for SVRCONN channels is to apply a Security Exit that authenticates who the other side is via SSL, and then sets the MCAUSER dynamically each time based on the source of the channel request. Then you use the OAM to give different MQ authorities to these different MCAUSERs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
