Author |
Message
|
sundar |
Posted: Mon Jul 18, 2005 3:32 am Post subject: MQ Security on queues while using receiver channels |
|
|
Newbie
Joined: 05 Jun 2005 Posts: 7
|
Hi all,
Trying to block a queue to avoid put messages in unix enviroment.
Used setmqaut and controlled the rights,so I am unable to put messages locally or through some application using admin channel.It is working fine.
But for the same queue with no rights for put, the messages fall into the queue if I try to put messages from another mq server using server/receiver channels.
Should I have to do anyother setup or there is no otherway other than to have a exit at the receiver end.??
Can you suggest your ideas?? |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jul 18, 2005 3:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I bet the channel has the mqm user set on it's MCA. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Nigelg |
Posted: Mon Jul 18, 2005 5:19 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
|
Back to top |
|
 |
EddieA |
Posted: Mon Jul 18, 2005 5:20 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
What do you have set for PUTAUT. With DEF, the "user" is MQ, and so is allowed to write to the Queue. If you use CTX, then the UserID from the message is used to check the authority.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jul 18, 2005 5:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Nigelg wrote: |
I would also hzard a small wager that <b>balaji sr</b> is the same person as<b>sundar</b>. |
I can not imagine anyone being so rude. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
vennela |
Posted: Mon Jul 18, 2005 5:57 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Nigelg wrote: |
I would also hzard a small wager that <b>balaji sr</b> is the same person as<b>sundar</b>. |
Most likely the above statement is true, because both the posts came from the same IP.
If not they both might be working at the same place. |
|
Back to top |
|
 |
sundar |
Posted: Mon Jul 18, 2005 6:32 am Post subject: |
|
|
Newbie
Joined: 05 Jun 2005 Posts: 7
|
Hi all,
Myself & balaji are working in the same firm. I was not aware that he would post the same question.
.
EddieA
Thanks , changing to PUTAUT works and its blocking the messages coming in to queue. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Jul 18, 2005 7:36 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
sundar wrote: |
....changing to PUTAUT works and its blocking the messages coming in to queue. |
and now you have to maintain a list of all the valid IDs and make sure they have the proper authorities, meanwhile anyone on the remote system can log on as "mqm" and still send any message to any queue on your system.
All PUTAUT does is make more work and provides zero security. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
hopsala |
Posted: Mon Jul 18, 2005 10:17 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
I agree with Peter, changing PUTAUT(CTX) is the wrong idea. if someone creates a local QM on his comp, and a channel to connect to your receiver, he will be granted MQM privilages.
This is a complex subject, but in short, you should do the following:
1. Configure channels to work with SSL - secure RCVR-SDR pairs.
This way you'll know no other qm will connect to your receiver, and your sender will be sure he is connecting to the right sender. to ensure this, use the parameter SSLPEER.
There is no need for a security exit, contrary to what some people here may say, SSL comes as a feature with MQ 5.3 onwards, and is simply a matter of proper MQ configuration. No need to install anything but MQ.
2. use MCAUSER(USR1), with PUTAUT(DEF) where USR1 has all privilages to all queues this channel might possibly write to. (don't forget the deadq!)
3. In each QMgr, secure access using setmqaut.
If you don't see why this is better than CTX, re-read it and see: This way you make sure only YOUR QM's are participating, you do not need to distribute authorization lists, and you give permissions only locally. Much easier to administrate, far more difficult to crack.
See Redbook "MQ v5.3 Security in an Enterprise Envioronment" (sg246814.pdf) for a complete breakdown of this process. |
|
Back to top |
|
 |
sebastianhirt |
Posted: Mon Jul 18, 2005 12:17 pm Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004 Posts: 620 Location: Germany
|
Alternativley you could either,
- get capitalware's security exit
- code your own security exit,
cheers
Sebastian |
|
Back to top |
|
 |
hopsala |
Posted: Tue Jul 19, 2005 6:01 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
I am glad, sebastian, that you posted that answer, because i've been meaning to ask this q for a long time:
why should one buy a proprietary security exit (spending money, and relying on support from another company) if the feature comes with the official product version?
(I by no means mean to deride capitalware's product here, I have never tried it and have no opinion concerning quality. I do, however, have a general rule not to buy what I already have...)
oh, and p.s - coding exits is not fun at all. been there. It is not recommended to anyone other than an MQ Expert with a lot of time and no other alternatives. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jul 19, 2005 6:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
hopsala wrote: |
why should one buy a proprietary security exit (spending money, and relying on support from another company) if the feature comes with the official product version? |
Why would someone write a proprietary product to replicate a feature that already comes with an official product? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jul 19, 2005 2:11 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
hopsala wrote: |
why should one buy a proprietary security exit (spending money, and relying on support from another company) if the feature comes with the official product version?
(I by no means mean to deride capitalware's product here, I have never tried it and have no opinion concerning quality. I do, however, have a general rule not to buy what I already have...)
|
MQ out of the box does not have the functionality that Capitalware's product provides. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
RogerLacroix |
Posted: Tue Jul 19, 2005 6:35 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
All,
And IBM will not be changing how security is handled for MQ for the foreseeable future. Hence, out of the box, MQ has minimum, minimum security.
Did you read Capitalware's ad on the back of this year's MQ Conference directory?
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
hopsala |
Posted: Wed Jul 20, 2005 1:29 pm Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
I must say, I don't know what you mean by "minimum minimum security"...?
With MQ 5.3, one has encription over the net, and SSL handshaking, coupled with a mechanism to control local security. This is all one needs for a tightly secured site.
Have read CapitalWare forum stickies and see nothing that mq does not already supply.
There is one prob that I have encountered, and that is that there is no way to administer distributed security settings from a single remote computer.
Anyway, will appreciate ref on this subject, maybe there's something I don't know. |
|
Back to top |
|
 |
|