Author |
Message
|
samsansam |
Posted: Thu May 08, 2014 8:09 am Post subject: Blocking mqm on SVRCONN |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
Hello, (' ')
MQ Version 7.0.1.5
We have three applications use three different users to contact to our QMGR.
The three applications used the same SVRCONN channel to connect to our QMGR.
App1 used user name App1user
App2 used user name App2user
App3 used user name App3user
All Apps use one SVRCONN channel know as SVRCONN.USER.
Currently, MCUSER on the SVRCONN is set to blank. I know by leaving MCUSER blank, I am trusting that whoever connects to the channel is properly allowed to send in the User ID that they are sending in which is not good because application can do MQEnvironment.userID = "mqm" and control queue manager.
My question is:-
Is there any way to not allow any of the applications to use mqm?
I know I could fix my problem by defending two different SVRCONN channels and set MCUSER in each one of them to match one of the users. But I cannot go with this option right now.
Also, we have no SSL, so SSL will be no option here.
Same case go to BlockIP2, I cannot use it right now.
I know MQ 7.1 would fix my problem but also I cannot go with option right now.
Is there any other option to block mqm user ?
Is there any option to block mqm user from used in MQ Exploere ?
I am not trying to make it more complected by saying (I cannot go with this option right now) but I have to mention that because it is not up tome to upgrade or defining new objects. I hoping someone have better understand can give me more option.
 |
|
Back to top |
|
 |
Vitor |
Posted: Thu May 08, 2014 8:20 am Post subject: Re: Blocking mqm on SVRCONN |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
samsansam wrote: |
Is there any other option to block mqm user ? |
Though all the options you mention but can't use would solve your problem. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
JosephGramig |
Posted: Thu May 08, 2014 9:11 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
What do you mean "we have no SSL"?
Of course you do because you have WMQ and could also download any number of tools to generate certificates. Worst case, you build an Internal CA and you enforce who comes in on the channel. This will at least reduce the number of folks who impersonate mqm to those you have issued certificates.
In any case, looks like you have the ammo to argue with the powers that be to upgrade. If they want it to be secure, then upgrade. |
|
Back to top |
|
 |
Vitor |
Posted: Thu May 08, 2014 9:23 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
JosephGramig wrote: |
Worst case, you build an Internal CA and you enforce who comes in on the channel. |
In defence of the OP, that's often a larger political challenge than you'd expect.
But I concur and stick with "all the options you mention will solve your problem" _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
samsansam |
Posted: Thu May 08, 2014 11:25 am Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014 Posts: 41
|
I really appreciated both of your responds and your time to answer me, and I agree with both of you as well. the whole purpose of this post is to listen to people who has MQ experience like you guys. I want to make sure that there is no other option. I am building my case against the applications team and , I guess I have enough ammo now.
For SSL, we use channel with disable SSL . We don't use SSL at all with QMGR, I know sound stupid and not secure but again it is not up to me.  |
|
Back to top |
|
 |
Vitor |
Posted: Thu May 08, 2014 11:35 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
samsansam wrote: |
I know sound stupid and not secure but again it is not up to me.  |
It's so often the case and we all struggle against it.
Go forth in good fortune with your struggle.
FWIW I'd push for 3 SVRCONN channels with 3 specific MCAUsers. Easy to set up, fewest application changes and easy to migrate to SSL and/or BlockIP2 later.
But I'm just some guy on the Internet. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu May 08, 2014 11:55 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Our standard is to setup a SVRCONN channel for each different client connection to the QMGR. Ok, so we only have at most a dozen clients so it isn't a problem.
We Auth each one separately along with the specific object that each client is allowed to use.
Having a separate one for each client makes it easy to see which clients are running. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
|