| Author |
Message
|
| rjlfc |
 Posted: Wed Jul 07, 2010 5:48 am Post subject: MCAUSER and setmqaut security |
 |
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Hi,
Been reading throgh multiple posts re. the above security, potential loopholes etc. and have the following queries - please bear with me!
NB - this is all on Windows 2003.....
We have 2 seperate websphere app server apps connecting to MQ via a client connection (one through a firewall, the other not) with 2 seperate client (serverconn) channels. Looking at the application connections on the MQ QM, I can see the user/service accounts the app servers run as as the names against the list of connections on the QM (say, WASUser1 and WASUser2 which are part of the domain mqm group).
Currently we have no MCAUSER value set in the svrconn channels. As I understand, this would allow another app to connect using these channels (they would have to pass no user to the connection, and MQ would then default to use the mcaagent user which would be part of the mqm group).
Q1. However, if I set up specific user authorisations against the application queues using the user/service accounts (say WASUser1 and WASUser2) and set the MCAUSER to these values, wouldn't this mean an app could use these channel and provide ANY user id to access these app queues?
Q2. Without going into user exits or SSL for the time being, am I better off leaving the MCAUSER on these channels blank and providing explicit access to the application queues to WASUser1 and WASUser2?
Q3. If I do this, do I need to remove these users from the domain mqm group, as otherwise they will have full mqm access and therefore override the setmqaut settings?
Q4. This leads me onto the admin queues, to be more secure and preventing a 'rogue' app/developer accessing them, should I give explicit access to the admin queues to a seperate user? That way, WASUser1 and WASUser2 and any other user outside of the domain mqm group will not have access to them?
I suppose in short, without going into user exits and SSL, what is the best practice for securing client connections to app queues and admin queues using MCAUSER and setmqaut??!!
many thanks. |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Jul 07, 2010 6:17 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I did the following.
Installed (free) exit BlockIP2 on SVRCONN channels. Configured it to prevent blank ids and powerful MQ ids from being accepted. Allow other ids to overide the default MCAUSER (which is set to nobody).
Ids which connect must be members of appropriate group to access queues. Queue access granted by generic setmqaut profile specifying group access rights (this is therefore very low maintenance).
It can be a little tricky to config the setmqauts to allow MQexplorer and other tools to work properly, but there are examples around (or ask me).
SSL channels can be used where proper client authentication is needed. BlockIP2 can be set up to check IP addresses as well, which can be useful.
Java programs have a bad habit of passing blank connection ids, this can be solved in a variety of ways (ask if interested). |
|
| Back to top |
|
|
| rjlfc |
| Posted: Wed Jul 07, 2010 6:38 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Thanks for the response. Before I go looking into a 3rd party channel exit, can you comment on some of my my queries if possible? I am trying to confirm if some of my understanding is correct and also I may have to make some interim changes to MCAUSER and setmqaut before I look at a channel exit longer term (even though I appreciate there a major limitations as to what can be done using MCAUSER and setmqaut.....
Thanks... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 07, 2010 7:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Q1: MCAUSER always *replaces* whatever is sent in. Setting MCAUSER on a channel without otherwise securing that channel means that EVERYONE who connects to that channel is authorized as the MCAUSER.
Q2: Without setting MCAUSER you are trusting that whoever connects to the channel is properly allowed to send in the User ID that they are sending in. This may or may not be valid, and may or may not be 'mqm'.
Q3: I'm not entirely sure I'm following this question...
As for "without using user exits or SSL", what you are left with is the basic fact that MQ only provides AUTHORIZATION and does nothing to provide AUTHENTICATION. So if you can really trust that all of your applications (and all of your development staff!) are only going to use legitimate and correct userids and not use Java based tools that don't provide a user id (and thus give them mqm privileges)...
If you want to provide for administrative security without forcing your applications to use SSL, then configure SSL on a single SVRCONN that has an MCAUSER of mqm, and then set an MCAUSER as appropriate on EVERY other SVRCONN, RCVR, CLUSRCVR and SERVER channel. And then use setmqaut to ensure that the non-mqm MCAUSER values don't have privileges to queues they don't want.
Or use an exit instead of SSL as above. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 07, 2010 7:34 am Post subject: Re: MCAUSER and setmqaut security |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rjlfc wrote: |
| Q1. However, if I set up specific user authorisations against the application queues using the user/service accounts (say WASUser1 and WASUser2) and set the MCAUSER to these values, wouldn't this mean an app could use these channel and provide ANY user id to access these app queues? |
Yes. Whatever user id they supply while connected to those channels, they will actually use the MCAUser in all dealings with the queue manager (like authorizations).
| rjlfc wrote: |
| Q2. Without going into user exits or SSL for the time being, am I better off leaving the MCAUSER on these channels blank and providing explicit access to the application queues to WASUser1 and WASUser2? |
No, because as you correctly point out an application could provide a blank id & obtain administrative control over the queue manager.
| rjlfc wrote: |
| Q3. If I do this, do I need to remove these users from the domain mqm group, as otherwise they will have full mqm access and therefore override the setmqaut settings? |
No application needs administrative authority and no non-administrative user should be a member of mqm.
| rjlfc wrote: |
| Q4. This leads me onto the admin queues, to be more secure and preventing a 'rogue' app/developer accessing them, should I give explicit access to the admin queues to a seperate user? That way, WASUser1 and WASUser2 and any other user outside of the domain mqm group will not have access to them? |
No, you should restrict access to the mqm group / id as above.
| rjlfc wrote: |
| I suppose in short, without going into user exits and SSL, what is the best practice for securing client connections to app queues and admin queues using MCAUSER and setmqaut??!! |
Those discussed on this forum over the years. These include (but are not limited to):
- Change the MCAUser of the SYSTEM SVRCONN channels to a dummy value
- Change the MCAUser of all other SVRCONN channnels to specific users granted specific authorities
Also think seriously about using SSL.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rjlfc |
| Posted: Wed Jul 07, 2010 7:39 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Thanks for this.
So if I go with the option of setting SSL on one SVRCONN channel with 'mqm' and all other channels with a seperate user(s) (using setmqaut to restrict access for these users to appropriate queues)....
1. What is the purpose of using SSL on the single channel? Would I (as a member of the domain mqm group) still have access to perform admin via Windows explorer?
Say I created two users ('userapp1' and 'userapp2') that will be used by each websphere app to connect to their appropriate queues (where websphere app 1 uses a client channel that has MCAUSER 'userapp1' and websphere app 2 uses another client channel that has MCAUSER 'userapp2'. I then use setmqaut to allow these users access to their queues.........
2. Do I need to explicitly deny accessing everything except 'userapp1' access to its queues and 'userapp2' access to its queues? Or is explicitly allowing these users access to their queues sufficient to prevent anything else accessing them?
3. Presumably these users should not be in the mqm group as this will override any access set in setmqaut?
4. Along the same line as 3., MQexplorer and any user with mqm access will still have access to queues?
Many thanks again! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 07, 2010 8:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rjlfc wrote: |
Thanks for this.
So if I go with the option of setting SSL on one SVRCONN channel with 'mqm' and all other channels with a seperate user(s) (using setmqaut to restrict access for these users to appropriate queues)....
1. What is the purpose of using SSL on the single channel? Would I (as a member of the domain mqm group) still have access to perform admin via Windows explorer? |
The purpose of the SSL on the channel is to use the certificate (and the SSLPEER) to ensure that you are allowed to connect to that particular channel. Once you are determined to be allowed to connect (by virtue of having a valid and matching certificate), then you are FORCED into the userid of mqm by the MCAUSER. Because, as previously stated, MCAUSER *replaces* the ID passed in.
So whether or not you are logged into your machine as 'dave' or 'mqm' or 'godemperer' or 'haxzorextrm', and whether or not you've constructed your MQCONN call to pass in a different userid than the one you log in as, once you connect to that channel all that MQ ever sees is that you are now 'mqm'.
Likewise, if you connect to a channel that has MCAUSER of 'userapp1', then all that mq ever sees is that you are now 'userapp1'.
I repeat. EVERYONE who can establish a network connection to the listener port and knows the name of that channel is TURNED INTO the user specifed on the MCAUSER.
So you're back to trusting that websphere app 1 will only ever connect to the channel with userapp1 on the MCAUSER and will NEVER connect to the channel with userapp2 on the MCAUSER. Because you've done nothing to ensure that the channel will grant or deny access - using either SSL or an exit.
As for the rest of it, setmqaut grants the privileges that you tell it to grant and removes the privileges that you tell it to remove. The act of granting privileges to a specific principle does not do anything to affect the privileges of another principle. |
|
| Back to top |
|
|
| rjlfc |
| Posted: Thu Jul 08, 2010 12:32 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
All, many thanks for your assistance.
If I set up a dummy value in the system svrconn client channel, will I still be able to access the QM via explorer (does MQ explorer use a different channel to connect?).
Can anybody please assist with the setmqaut command(s) to only allow priveleges for a specific user (say 'userapp1') to specific queus (say queues 'qa', 'qb' and 'qc'. For now, assume full access for the user to the named queues......
Mnay thanks..... |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jul 08, 2010 1:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| rjlfc wrote: |
| ...Can anybody please assist with the setmqaut command(s) to only allow priveleges for a specific user (say 'userapp1') to specific queus (say queues 'qa', 'qb' and 'qc')... |
Yes. They're all listed within the Info Centre and a search within it will reveal them. Either take away all privileges and add the ones you are sure are needed, or take them away one-by-one until you achieve the desired result.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 08, 2010 1:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I tend to code my setmqaut commands like this:
| Code: |
| setmqaut -m QMNAME -g groupname -n 'QPR.**' -t queue -all +allmqi +dsp +clr |
That way I know that all previous authorities are replaced. |
|
| Back to top |
|
|
| rjlfc |
| Posted: Thu Jul 08, 2010 3:49 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Thanks zpat.
As this command 'replaces' any previous permissions, does this effectively only allow the named user/group access to the queue and deny everyone else? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 08, 2010 4:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
It does not remove other users or groups. It resets the permissions for the users or groups mentioned.
You can actually have a list of users and groups on one command by repeating the -g groupname operand as necessary. Or you can have one command for each group, whichever you prefer.
Always permit by groups on Unix, because if you permit by users, it does not do that but it permits that user's primary group instead.
You can check the overall permissions using MQ explorer (latest v7 version), MO71 or list them like this
amqoamd -m QMGRNAME -s
This lists them in the command format (also useful for recovery).
When using generic profiles (as per my example) MQ will look at all profiles covering the resource and grant the cummulative authority. That's why you don't need to add mqm because there will be a specific profile for each queue created automatically.
When creating queues, ensure mqm is the primary group of the user creating the queue, since that group is added to the permissions automatically (yes this is a real pain and you may find your permissions are far too open because of it). |
|
| Back to top |
|
|
| rjlfc |
| Posted: Thu Jul 08, 2010 4:58 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
| Many thanks. So doe that mean that if I only want a particular user/group to access certain queues, I first need to deny all access to the queues, then allow access for said users? If so how do I do a setmqaut to deny EVERYONE access to said queues (presumably the mqm group wil always have permissions to all queues, regardless of the values set using setmqaut? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 08, 2010 5:13 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
On a new Queue Manager on Windows the only people with any access are memberss of the mqm group and members of the server's Administrators group.
Use the dmpmqaut command to see a list of who has what authorities to your QM at this time, and then take it from there, removing / adding access as required.
You cannot change any access for the mqm and Admin group. Those groups and everyone in them has 100% full access to MQ and you cannot change that, other than removing user IDs from those groups and refreshing MQ security (or restarting the QM).
Stick with best practices and apply permissions to groups rather than individual IDs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rjlfc |
| Posted: Thu Jul 08, 2010 5:14 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Just to add to my last reply (and sorry for all the questions, doing all this fir the first time)....
I have looked at our queues on our test system and they all have my user having full perms and the mqm group as having full perms (although I am part of mqm).
So as per some options above, I will add a user to the MCAUSER on each svrconn channel (and a dummy one on the system ones). then I will grant access to the specific queues required for each user(group)/channel. I will leave myself and the mqm group as having rights to these queues. Therefore anyone accessing these channels will only be able to see the queues associated to that user/channel and no others (importantly, no admin queues). Likewise, they will not be able to access the system svrconn queues. Only local access to the queue manager will be possible and then only by mqm priveldged users for admin purposes. Does this sound like a 'start' or minimum before onto security exits and ssl?
Last edited by rjlfc on Thu Jul 08, 2010 5:15 am; edited 1 time in total |
|
| Back to top |
|
|
|
|
