| Author |
Message
|
| bcostacurta |
 Posted: Fri Oct 25, 2013 1:41 am Post subject: CHLAUTH : how to block all and allow only explicite ? |
 |
|
Acolyte
Joined: 10 Dec 2009
Posts: 71
Location: Luxembourg
|
Hello to All,
I need to create a SVRCONN channel for admin team only.
So only admin user will be able to connect.
I tried the following :
* block all
SET CHLAUTH(TEST.CLIENT) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)
* block all
SET CHLAUTH(TEST.CLIENT) TYPE(BLOCKUSER) USERLIST(*)
* allow specific user as identified via logon ID
SET CHLAUTH(TEST.CLIENT) TYPE(USERMAP) CLNTUSER(bruno) USERSRC(MAP) MCAUSER(aut0200) action(ADD)
This obviously does not work.
So how can I block all users, and only accept the specific ?
Also cannot work on IP address as they change (via DHCP).
Could it be possible such behaviour is only possible via following mecanisms ?
- IP address
- SSLPEER usage, meaning authentication based on certificate
Thanks for attention and any clue.
Bruno |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Oct 25, 2013 5:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
| Code: |
| SET CHLAUTH(TEST.CLIENT) TYPE(BLOCKUSER) USERLIST(*) |
is where you're going wrong.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 25, 2013 5:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
You likely have this rule still there. Its created by default.
| Code: |
SET CHLAUTH('*') +
TYPE(BLOCKUSER) +
USERLIST('*MQADMIN') +
DESCR('Default rule to disallow privileged users') +
WARN(NO) +
ACTION(REPLACE) |
So that will prevent any SVRCONN channel, no matter what else you do, from running with elevated privelages like mqm.
So first thing you should do is create another rule that will open up the ability for just this one channel to run as a privelaged user.
| Code: |
SET CHLAUTH('TEST.CLIENT') +
TYPE(BLOCKUSER) +
USERLIST('BabaBooey') +
DESCR('To allow TEST.CLIENT to run w/ privelaged authority') +
WARN(NO) +
ACTION(REPLACE)
|
What this rule does is allow everyone EXCEPT a user called BabaBooey to connect over the channel called 'TEST.CLIENT'.
Now create the channel.
| Code: |
DEFINE CHANNEL('TEST.CLIENT') +
CHLTYPE(SVRCONN) +
DESCR('For MQ Admins for MO71, MQExplorer') +
TRPTYPE(TCP) +
MAXMSGL(104857600) +
MCAUSER('BOGUS_ID_999') +
HBINT(30) +
KAINT(AUTO) +
COMPHDR(NONE) +
COMPMSG(NONE) +
SSLCAUTH(REQUIRED) +
SCYEXIT('/var/mqm/exits64/mqausx(SecExit)') +
SCYDATA('/var/mqm/exits64/mqausx_AUTH.ini') +
MONCHL(QMGR) +
SHARECNV(1) +
MAXINST(999999999) +
MAXINSTC(999999999) +
REPLACE |
I have a security exit on this channel that will force the incoming client to authenticate who they are with an ID and password.
At this point the exit allows them thru, but the channel would try and run as 'BOGUS_ID_999' and obviously fail. We do this in case somebody with an ID on the box but not neccassarily and MQ Admin tries to connect and successfully does because the exit sees the valid ID and password.
So then we set up a mapping rule to provide a whitelist of MQ Admin IDs that when seen will cause the 'BOGUS_ID_999' to be over ridden to the ID of your choice, either the MQ Admin's ID, or the 'mqm' ID.
I have my Security Exit do that. Capitalware's MQAUSX.
Or, you can use a CHLAUTH rule to do that.
| Code: |
| SET CHLAUTH('TEST.CLIENT') TYPE(USERMAP) CLNTUSER('bcosta') USERSRC(MAP) MCAUSER('mqm') DESCR('This rule allows bcosta to override the MCAUSER of this channel') ACTION(ADD) |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Oct 25, 2013 6:29 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1237
Location: Gold Coast of Florida, USA
|
| PeterPotkay wrote: |
| Code: |
SET CHLAUTH('TEST.CLIENT') +
TYPE(BLOCKUSER) +
USERLIST('BabaBooey') +
DESCR('To allow TEST.CLIENT to run w/ privelaged authority') +
WARN(NO) +
ACTION(REPLACE)
|
|
I think you should use 'nobody' vs 'BabaBooey' because that is what this rule does. It blocks nobody's ID from using this channel, as in every ID except 'nobody' is a good ID.
At this point, I think SSL is a great choice. It is no cost to use a Self Signed CA and protects it quite well. If you want to use this channel for administrative and non-administrative purposes, then use CHLAUTH to map. I would not use a channel for both purposes and indeed, would keep secret the name of my administrative channel. Further, I would use a different LISTENER for administrative traffic, so I can turn everybody else off should I need to do that. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Oct 25, 2013 6:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
| JosephGramig wrote: |
Further, I would use a different LISTENER for administrative traffic, so I can turn everybody else off should I need to do that. |
You cannot turn everybody else off, if they know about the alternate listener.
If you only run the alternate listener when you need to turn everybody off, then yes. If you have it under qmgr control, it just provides another port for use... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 25, 2013 11:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Maybe its just me, but the 'nobody' ID just makes it confusing to me. Double negatives and all. Nobody is not allowed. And somebody might create an ID called nobody on the server for some other reason.
I guess its best to use a value in there that makes to most sense to you AND something you can be sure will not be created as an ID in your system. I don't use Bababooey on my real channels to convey this concept, but I do use values that will never be IDs in my shop. And I use unique values in each channel, so anytime I see one of these in my logs or Authority Events I know exactly which channel caused it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 25, 2013 11:32 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I've kicked around the idea of a seperate Admin listener and eventually decided against it. I'd rather all my tools use the port the apps are using - if I'm working they're working.
In the rare cases where I need to stop the listener but still need to do something I'll drop into a runmqsc session on the server.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bcostacurta |
| Posted: Mon Oct 28, 2013 5:06 am Post subject: |
|
|
Acolyte
Joined: 10 Dec 2009
Posts: 71
Location: Luxembourg
|
Thanks to All for clues and explanations.
Indeed our security tests looks OK (at least regarding our expectations) once implementing your advices.
Thanks again.
Bruno |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 28, 2013 5:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| Maybe its just me, but the 'nobody' ID just makes it confusing to me. |
Not just you. 'nobody' is a word that has built-in meaning on some o/s's. 'everybody' would make more (or less) sense.
NOACCESS seems like a better word choice - but NOACCESS a privilege, not a principal/group.
"Nobody knows the troubles I've seen, nobody knows my sorrow."
_________________
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 |
|
|
| mqjeff |
| Posted: Mon Oct 28, 2013 5:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| We could all agree to use TROBWASHERE |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Nov 04, 2013 4:34 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3258
Location: London, ON Canada
|
| JosephGramig wrote: |
| At this point, I think SSL is a great choice. It is no cost to use a Self Signed CA and protects it quite well. If you want to use this channel for administrative and non-administrative purposes, then use CHLAUTH to map. I would not use a channel for both purposes and indeed, would keep secret the name of my administrative channel. Further, I would use a different LISTENER for administrative traffic, so I can turn everybody else off should I need to do that. |
There are so many flaws with this statement, it makes me shake & bang my head in frustration. I wish T.Rob was more active here because he would get on you regarding your SSL statement.
| JosephGramig wrote: |
| If you want to use this channel for administrative and non-administrative purposes, then use CHLAUTH to map. |
Now from a MQ management point of view, it is best to have separate channels but if you have implemented proper security then ALL applications/users "could" connect on 1 SVRCONN channel.
You are mixing up front-end blocking/allowing feature with authorization. If the UserIDs/Groups have the proper privileges set in the OAM then it is totally irrelevant what channel was used.
| JosephGramig wrote: |
| I would not use a channel for both purposes and indeed, would keep secret the name of my administrative channel. |
Security by obfuscation is NOT security.
| JosephGramig wrote: |
| Further, I would use a different LISTENER for administrative traffic, so I can turn everybody else off should I need to do that. |
It is totally irrelevant what port the MCA is listening on. You cannot create a CHLAUTH rule based on port number. You cannot setup an OAM rule by port number. You cannot associate a SVRCONN channel with a particular port number. So, talking about a different Listener is a total red-herring.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bernard_fay |
| Posted: Wed Nov 20, 2013 11:14 am Post subject: |
|
|
Apprentice
Joined: 24 Jul 2012
Posts: 30
|
| bcostacurta wrote: |
Thanks to All for clues and explanations.
Indeed our security tests looks OK (at least regarding our expectations) once implementing your advices.
Thanks again.
Bruno |
Bruno,
I am trying to do something very similar. My need is to let developers have read-only access to the queues. I need to block everybody and let only a few developers connect to the QM with a svrconn channel.
How did you manage to get it working? So far I am unsuccessful.
Thanks |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Nov 21, 2013 7:12 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1237
Location: Gold Coast of Florida, USA
|
bernard_fay,
You can do this with a combination of SSL and CHLAUTH rules. First use SSL to establish a known universe of entities that can connect to the Qmgr using SSL. Just having a valid certificate is not good enough because the ID asserted has no relationship to the certificate (yet).
Then use a CHLAUTH rule to map something in their DN (like CN=<theirAD_ID>) to the actual ID you want them to be when they connect (this should override anything in the MCAUSER).
You can create your own Internal CA (by creating a key store and creating a self signed CA in that key store to be used as *this* Internal CA).
You then extract the Internal CA certificate in an ARM file and send that to the Qmgr and developers in question. Have them add this to their key store (the developers might want a unique key store). The SSL only works if the Qmgr is also signed, so create a certificate request from the Qmgrs key store and have the Internal CA sign it from the Internal CA key store and send back the Qmgrs signed certificate request. Have the Qmgr receive the signed certificate request into the Qmgr's key store.
Then the developers should create a certificate request with an OU that you intend to filter them with on this channel (something like OU=DEV_FOLKS). Then the developers can send you their certificate requests.
You sign the developers request with the Internal CA certificate (remember the key store I first told you to make). Send back the developers signed certificate requests and have them receive them into the key store where they added your Internal CA certificate.
Now you can create a specific channel that will filter on SSLPEER('OU=DEV_FOLKS'). Now you have limited the universe of people who can attach to your system with just about any ID to these folks. Now add a CHLAUTH rule for each person and map maybe their CN value to their ID on the system.
I recommend you start with no security on the channel. Add SSL. Then add CHLAUTH. Then stick an ID in the MCAUSER with no access to MQ (NOACCESS maybe as the ID?) to block all users that don't have a CHLAUTH rule. If you create a CHLAUTH rule specific to this channel that blocks 'NOACCESS' as the ID, then it will allow access of all other IDs (and then the OAM rules kick in).
RogerLacroix,
Since the WMQ admin is the one that creates the OAM rules governing access, it makes sense that they are also the ones managing the Internal CA. The onus is on the WMQ Admin to implement the SSL certificates in a way that can tie a certificate with an ID WMQ can use against OAM access control lists. Yes, I know the asserted ID (even with SSL) cannot be trusted. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Nov 21, 2013 7:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| JosephGramig wrote: |
| Since the WMQ admin is the one that creates the OAM rules governing access, it makes sense that they are also the ones managing the Internal CA... |
Joseph, I'm going to strongly disagree with you here because to me that's like giving the keys of the asylum to the inmates - too open to abuse.
_________________
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 |
|
|
| Michael Dag |
| Posted: Thu Nov 21, 2013 7:50 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| exerk wrote: |
| JosephGramig wrote: |
| Since the WMQ admin is the one that creates the OAM rules governing access, it makes sense that they are also the ones managing the Internal CA... |
Joseph, I'm going to strongly disagree with you here because to me that's like giving the keys of the asylum to the inmates - too open to abuse. |
I read this in the context to Developers needing access... so we are talking about DEV/TEST environments not ACC/PROD where NO Developers should be allowed...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
