| Author |
Message
|
| JBrown |
 Posted: Wed Feb 14, 2007 12:48 pm Post subject: Untrusted Cluster Members |
 |
|
Newbie
Joined: 14 Feb 2007
Posts: 6
|
My department operates QMGR1 on BOX1 and QMGR2 on BOX2 and another department operates QMGR3 on BOX3. All boxes run W2K and are on the same domain and all are using v6 of the MQ software. Our queue mangers are administered by a local user mqadminA and their queue manager is administered by a domain user mqadminB. All three queue managers are in a cluster CLSTR1. For legal reasons we have to keep our departments as seperate as possible, and for political reasons we have to use a cluster setup.
How can I prevent them from making changes to our queue managers?
As far as I understand it, if a user is not in the Administrators or MQM group they cannot administor MQSeries, yet I can use MQ Explorer to connect remotely and modify queue managers on machines I am not an admin on. |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Thu Feb 15, 2007 12:30 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I don't think this is a clustering issue, how are you connecting remotely to 'their' Qmgr(s)?
Can you logon to their machines and act as mqm?
if the above is no, then their SVRCONN channels are probably not secured against you accessing them.
Get at least a security exit on the SVRCONN's or enable SSL on these channels...
Last thing... can they access your Qmgr? (or don't they know...  )
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| JBrown |
| Posted: Thu Feb 15, 2007 7:35 am Post subject: |
|
|
Newbie
Joined: 14 Feb 2007
Posts: 6
|
It is a clustering issue in part because our queue managers are clustered with theirs. The problem is that if you have the authority to administer one queue manager in the cluster, you apparently have the authority to administer all of them. I want to be able to prevent the other department from being able to administer the queue managers that we're responsible for. Our queue managers are administered by a local user on each box and their queue managers are administered by a single domain user.
I can use MQ Explorer to remotly connect to their queue managers and make changes even though I am not in the administrators or mqm group on their boxes. And I know they can do the same to ours. I want to prevent this.
I cannot logon to their machines because I dont have physical or remote access to their servers. If you login to our machines as a user who does not have mqm admin rights you cant make changes, but as I said they can use the MQ Explorer to make changes. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Sun Feb 18, 2007 6:46 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
You say that the queue managers are i the same Windows domain.
Are the queuemanages domain aware started with a domain user or are they running under MUSR_MQADMIN ?
When you have administrative contact with QMGR3 please check status of the SVRCONN channels to see if that's the way MQExplorer are trying to administrer QMGR3.
You could use BlockIP2 to secure your queue manager, by filtering the connames that are alowed to connect to the queuemanager....
If the administration are happening theu the MQ Cluster infrastructure it's another game.... Because you can't just remove the access to the COMMAND.QUEUE, if you do the cluster will stop working....
And about playing with exits to lift this scenario is also quite complicated because you maight have to create multple exits and have other exits to help them.. A non trivial task. (I've been playing with cluster security for some time now).
So let's see if it's possible to smack the door using the SVRCONN channels. You could try to stop: SYSTEM.ADMIN.SVRCONN and then try remote admin.
If this works then it's just a SSL or BlockIP2 job or SecureMQ or more fancy..
I know a lot of happy friends using BlockIP2
I hope it can help you.
-- lock it or Lose it -- 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| JBrown |
| Posted: Tue Feb 20, 2007 12:22 pm Post subject: |
|
|
Newbie
Joined: 14 Feb 2007
Posts: 6
|
| They are running under MUSR_MQADMIN. I'm not sure where to look for the SVRCONN channel. MQExplorer uses the Cluster-Sender and Cluster-Receiver channels to do remote administration. In MQExplorer I can stop the Command Server for the queue manager and that prevents remote administration and still allows the putting of messages, but I have to turn it back on every time I want to make changes to the queue manager. While I could just stop the Command Server when Im not making changes, there is something to be said about doing it right. If I could restrict access to the COMMAND.QUEUE so that only a certain username can put to it, that would be great. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Feb 20, 2007 3:27 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
keep the command server down and use runmqsc instead, it does not need the command server to run.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 21, 2007 3:38 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Michael Dag wrote: |
| keep the command server down and use runmqsc instead, it does not need the command server to run. |
Only if you use it local to the box the server is on.
If you use it remotely (remote admin through a default qmgr) or use MO72 support pack you will need the command server...)
Have you thought about limiting their access to your cluster?
Set an mcauser on the cluster receiver. Allow only connect display inquire and put access to that user...
Run the qmgrs with a service user that has the same characteristics and group memberships as the default service user but has a different name. Remove the default service user from the mqm and admin groups...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Feb 21, 2007 4:24 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| fjb_saper wrote: |
| Michael Dag wrote: |
| keep the command server down and use runmqsc instead, it does not need the command server to run. |
Only if you use it local to the box the server is on.
|
true, i thought that was clear 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| JBrown |
| Posted: Wed Feb 28, 2007 11:17 am Post subject: |
|
|
Newbie
Joined: 14 Feb 2007
Posts: 6
|
| fjb_saper wrote: |
Have you thought about limiting their access to your cluster?
Set an mcauser on the cluster receiver. Allow only connect display inquire and put access to that user... |
Okay, here is what I did:
1) Created a separate cluster-receiver for the other department to connect to
2) Set the MCAUSER on the new cluster-receiver to the domain user that they use
3) Set the permissions for that user for my queue manager to +setall +connect +inq
4) Set the permissions for the SYSTEM.CLUSTER.COMMAND.QUEUE and SYSTEM.DEAD.LETTER.QUEUE to +setall +put
5) Set any queues the other department needs to put to to +setall +put
After working through the error logs, these are the minimum amount of permissions I can give and still have it work. Also I didn't have to use their domain user as the MCAUSER but it was handy and self-documenting. Now that it works I guess my only question is what does the 'setall' permission do and why does it need to be set? |
|
| Back to top |
|
|
| ppdollar |
| Posted: Thu Mar 15, 2007 7:06 pm Post subject: |
|
|
Novice
Joined: 31 Aug 2005
Posts: 20
|
remove SYSTEM.ADMIN.SVRCONN channels from your qmgrs and if there are any SVRCONN channels on your qmgrs add 'mcauser' as 'nobody'.
Be careful and make sure that no apps are using these svrconn channels.
and I'm pretty sure that nobody will be able to connect to the qmgrs remotely using any third party tools. |
|
| Back to top |
|
|
|
|
