| Author |
Message
|
| Sam Uppu |
 Posted: Wed Sep 16, 2009 7:07 am Post subject: |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| I will turn on the QMgr authority events and see. I will update you on this. |
|
| Back to top |
|
 |
| Sam Uppu |
| Posted: Wed Sep 16, 2009 7:16 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mqjeff wrote: |
| Sam Uppu wrote: |
| Lets say we are using the 'App1' in the MCAUSER of SVRCONN channel and provided +connect on Qmgr, put/get/browse permissions on queues for 'App1' id(OAM) |
*Every* app, malicious or not, that can successfully connect to that Channel will ONLY be AUTHORIZED as 'App1'. |
This is dangerous as anybody(some malicious) who knows the QMgr and its details can access the qmgr/ queues.
1. Its not possible to track who is sending the msgs or where they are coming from when we set the appropriate user in the MCAUSER of SVRCONN channel.
2. If we leave the MCAUSER blank on SVRCONN and provide the OAM perms for the objects would be good but this applies only when the app is providing the user id in the msg by using MQ_USER_ID environment variable. By leaving the MCAUSER blank is wide open. Anybody can access this qmgr which is also not good.
To avoid these loop holes SSL is only the option?. Do we have any security exits from IBM?. Any further information on this would be great.
How you are securing your environments to close these loop holes?. Which procedures are you following?.
I appreciate your your thoughts/ suggestions...thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 16, 2009 7:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| mqjeff wrote: |
| Sam Uppu wrote: |
| Lets say we are using the 'App1' in the MCAUSER of SVRCONN channel and provided +connect on Qmgr, put/get/browse permissions on queues for 'App1' id(OAM) |
*Every* app, malicious or not, that can successfully connect to that Channel will ONLY be AUTHORIZED as 'App1'. |
This is dangerous as anybody(some malicious) who knows the QMgr and its details can access the qmgr/ queues. |
But only so far as the App1 user is allowed to do. Typically the authorisation is limited to prevent such actions.
| Sam Uppu wrote: |
| To avoid these loop holes SSL is only the option?. Do we have any security exits from IBM?. Any further information on this would be great. |
SSL is an option; exits are available, I'm not aware of any from IBM but I'm prepared to be corrected on that. If you want an IBM solution buy the Extended Security Edition of WMQ.
| Sam Uppu wrote: |
| How you are securing your environments to close these loop holes?. Which procedures are you following?. |
Proper use of authorities & MCAUser. BlockIP if the queue manager isn't on a secured internal network (which typically mine are). SSL where appropriate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Sep 16, 2009 7:38 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
I heard/ read somewhere about the Extended Security Edition of WMQ cost saying its very expensive and its cost is more than an MQ license. I think in this link Roger was saying this. Does anybody agree with this?.
Would like to have any other security exits from IBM.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 16, 2009 7:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| I heard/ read somewhere about the Extended Security Edition of WMQ cost saying its very expensive and its cost is more than an MQ license. I think in this link Roger was saying this. Does anybody agree with this?. |
The only 2 people who can discuss this are Roger and your IBM Sales Rep. I think it's true to say that WMQ ESE costs more than standard WMQ, and that WMQ ESE is generally more expensive than Roger's product.
As he also points out in that thread, some sites still purchase WMQ ESE despite the cost. I imagine factors here are the site's attitude to risk & their attitude to non-IBM products.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 16, 2009 7:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ESE also has considerably more capabilities than merely providing distributed user authentication. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 16, 2009 7:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| ESE also has considerably more capabilities than merely providing distributed user authentication. |
And I did not wish to indicate that the factors I mentioned were the only ones.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
