| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Setup MQ security for the applications to connect |
« View previous topic :: View next topic » |
| Author |
Message
|
| chris boehnke |
 Posted: Fri May 23, 2008 7:35 am Post subject: Setup MQ security for the applications to connect |
 |
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
Hi Guys,
We are using Clustered QMgrs in our organization. We are planning to implement security for the application teams which are connecting our MQ. Some times the application teams not only connecting to our MQ, they are altering or deleting some of the objects of other applications. To prevent this we need to implement some kind of security.
What you guys suggest the best way to implement this kind of security?. We are not planning to Alias queuing as we dont want to administer many objects in our infrastructure.
Your thoughts and suggestions are appreciated.
Thanks. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri May 23, 2008 8:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| the application teams not only connecting to our MQ, they are altering or deleting some of the objects of other applications. |
First: read WMQ Security manual to get an understanding of what to secure, and how.
Second: take all non-administrative users (programmers, end-users, etc.) out of the MQM group and out of UNIX root.
Third: grant (with setmqaut control command) only object authorities required by the application users.
_________________
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 |
|
|
| RogerLacroix |
| Posted: Sat May 24, 2008 10:38 am Post subject: Re: Setup MQ security for the applications to connect |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| chris boehnke wrote: |
| We are using Clustered QMgrs in our organization. We are planning to implement security for the application teams which are connecting our MQ. Some times the application teams not only connecting to our MQ, they are altering or deleting some of the objects of other applications. To prevent this we need to implement some kind of security. |
Hi,
The first step is to implement a security solution at the queue manager (security exit or SSL) then you issue setmqaut commands to implement authorization.
Capitalware offers 2 security solutions that you may be interest in: MQSSX and MQAUSX.
If you have any questions regarding either product, please let me know.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon May 26, 2008 7:23 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
So, I see you've been "helped".
First, if the machine you are using is not secure then you need to secure it by following bruce2359's steps 1 & 2. If the machine is Windows, then it cannot be secured.
Second if you run a LISTENER of any form and any inbound channel has a blank MCAUSER and no security exit, then you cannot be secure (this includes SYSTEM objects).
Note that any remote application that connects to a QMGR with a blank ID will by default be running with the authority of the LISTENER object (that tends to be the service ID of WebSphere MQ). It is most trivial to connect with a blank ID (just read the manual and it will tell you how). It is also quite trivial for a remote user to just build a local account with the same ID as the service ID that run a QMGR. Once they do that, then they just happily hack your QMGR. SSL can secure your channel but more often then not, most sites just limit hacking to their buddies that they have handed keys to.
You also mentioned that you didn't what to construct Alias queues. I assume that you said that because you know that users that put to remotely hosted cluster queues will be putting to the S.C.T.Q and that they will need permission to put to that queue. Any ID that has permission to put to that queue, can put to any queue (clustered or not) on an adjacent QMGR (and all QMGRs in a cluster are adjacent). One of the not-so-obvious implications is that some one can gain control over a remote QMGR by using this path (by putting PCF msgs to the S.C.Q at the remote QMGR).
Here is a free security exit: http://www.mrmq.dk/index.htm?BlockIP.htm |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon May 26, 2008 8:49 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| JosephGramig wrote: |
| So, I see you've been "helped". |
| JosephGramig wrote: |
| If the machine is Windows, then it cannot be secured. |
I disagree. If the company AND the Windows Admin lock down the server in the data center and then disallow non-authorized users from connecting with VNC or Terminal Services then yes it can be locked down.
| JosephGramig wrote: |
| any remote application that connects to a QMGR with a blank ID will by default be running with the authority of the LISTENER object |
Here's a description for Java apps:
http://www.mqseries.net/phpBB2/viewtopic.php?t=17842
Here's a description for native apps:
http://www.mqseries.net/phpBB2/viewtopic.php?t=21782
BlockIP was the original exit and it is now obsolete. The current free security exit from Jorgan is BlockIP2. It does not come with support.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
