| Author |
Message
|
| madi |
 Posted: Tue Jun 30, 2009 8:57 am Post subject: Securing CLNTCONN and SVRCONN channels |
 |
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
Hi All
We are planning to setup object level security in MQ. What is the best possible way to restrict access to the application that can use CLNTCONN or SVRCONN channels to connect to qmgr. We are setting the MCAUSER blank. We are securing the qmgr and objects using setmqaut commands. We do not plan to use any exits or SSL.
I tried to go through the MQ Security manual but I still couldnot understand clearly how to secure those connections.
Thanks
_________________
IBM Certified Solutions Developer - WMB 6.0 |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Tue Jun 30, 2009 9:16 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
without SSL and/or exits, those channels leave your QMGR open to anonymous administration.
They are not secure in anyway. The application could assert any ID.
That would also be true for any inbound channel with a blank MCAUSER, no SSL and no exits. |
|
| Back to top |
|
|
| madi |
| Posted: Tue Jun 30, 2009 9:23 am Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
If we secure the qmgr and the XMIT queues wouldnt the regular sender and reciever channels be secure?
_________________
IBM Certified Solutions Developer - WMB 6.0 |
|
| Back to top |
|
|
| gs |
| Posted: Tue Jun 30, 2009 9:31 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
Yes, setting the MCAUSER to blank leaves the user id setting to the connecting application. I strongly recommend using SSL in addition to a specified MCAUSER.
Last edited by gs on Tue Jun 30, 2009 10:06 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 30, 2009 9:52 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
SSL does not alter the need to have a specific ID coded on the MCAUSER.
SSL (or a Security Exit) controls who can connect to the QM via that SVRCONN channel. It does not control, at all, what they can do once connected. With a blank MCAUSER, they can say they are an MQ Admin and do whatever they want to that QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Jun 30, 2009 9:54 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
This is not as good as SSL or even channel exits, but....
You can minimize your risk a bit by setting the MCAUSER on your svrconn chl to the same ID for which you are authorizing object level security.
We have different applications that use the same queue manager. Each application has its own svrconn channel; each application also has its own user ID. The application's user ID is set as MCAUSER and is authorized to access only its own application queues. At least this way, if a rogue connects to a particular svrconn channel, the damage is limited to a subset of queues (and the system queues are protected).
(We also use channel exits, btw, before anyone starts to lecture me.  ) |
|
| Back to top |
|
|
| madi |
| Posted: Tue Jun 30, 2009 10:22 am Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
Hey SAfraser
So do we set the MCAUSER for SYSTEM.DEFAULT.SVRCONN to mqm, since system queues are accesible only to mq admins? What about the client conn channel, can a rougue applicaiton use only CLNTCONN to connect to MQ? |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Jun 30, 2009 10:45 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
We set MCAUSER to 'nobody' for:
SYSTEM.ADMIN.SVRCONN
SYSTEM.DEF.SVRCONN
SYSTEM.AUTO.SVRCONN
For access through MQExplorer, we create a specific svrconn channel. We lock it down with a security exit; 'mqm' is not allowed to connect through it, only the specific user IDs of the MQ admins are allowed through the security exit. Those specific user IDs are members of the mqm group on the target queue manager's machine.
If you set the MCAUSER to 'mqm' for SYSTEM.DEF.SVRCONN, then anyone who connects through that channel will have mqm access to everything. This is a bad thing. Do not ever set the MCAUSER to 'mqm' on any channel, really.
The MCAUSER will only mitigate your risk. As others have said, SSL or exits+OAM authority are better alternatives.
I am not sure I understand your question about CLNTCONN channels. Any application can connect to a SVRCONN if it has accurate connection information.
Hope this helps! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 30, 2009 11:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| since system queues are accesible only to mq admins |
Unless you create rules for SYSTEM objects, they are unsecured - therefore accesible to anyone.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| madi |
| Posted: Tue Jun 30, 2009 11:15 am Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
If we restrict access to qmgr wouldnt that be sufficient to restrict access to queues. Our application ids are not part of mqm, they are a separate group and we plan to give those acceess to whatever queues they are using plus qmgr and XMITQ
_________________
IBM Certified Solutions Developer - WMB 6.0 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 30, 2009 11:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| If you don't put security on channels, it doesn't matter what you issue with setmqaut. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 30, 2009 11:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If we restrict access to qmgr ... |
This means granting mqconnect authority. Unless you have taken this away from everyone, anyone can mqconnect to the qmgr. Once successfully connected, then what?
Unless you have taken away object access, any mqconnected app can open and put/get messages.
Once more with feeling: wmq comes from the factory with NO security in place. This means that all objects, including the qmgr, are not secured. If you secure only the qmgr, then all the remaining object are not secured.
Please read the WMQ Security manual. It covers all this.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Jul 01, 2009 6:31 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| madi wrote: |
| If we restrict access to qmgr |
Hmmm, search this site on this topic and you will find this ground covered well. That would be in addition to the manual.
I think you will come to the conclusion that you need to do something at the channel level to secure the QMGR if your QMGR is going to use channels.
The MCAUSER by itself simply norms all anonymous users to a specific user (the one in MCAUSER) for client connections.
Beyond that, it's:
1) Exits
2) SSL (maybe with peer filtering) |
|
| Back to top |
|
|
| madi |
| Posted: Mon Jul 06, 2009 10:55 am Post subject: |
|
|
Chevalier
Joined: 17 Jan 2006
Posts: 475
|
Thanks guys for all replying patiently. I have a good idea now. I searched the forum and got some ideas.
Thanks again!
_________________
IBM Certified Solutions Developer - WMB 6.0 |
|
| Back to top |
|
|
|
|
