| Author |
Message
|
| PeterPotkay |
 Posted: Mon May 20, 2013 12:14 pm Post subject: CHLAUTH on Cluster Receiver Channels - How to Whitelist |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
My Full Repositories are QMGRFRP1 and QMGRFRP2.
Cluster Receiver Channels are like TO.QMGRFRP1.
The Partial Repositories are running on all sorts of systems with a wide variety of IP addresses. SSL and/or Security Exits are not option for every single QM in this cluster.
I’d like to understand how to block all connections to the cluster receiver channel on the Full Repository, and then allow only the legitimate partner Full Respository and the legitimate Partial Repositories. This is to handle clusters where not every cluster member can do SSL or Exits on their channels.
I assume the following will block all connections to this Cluster Receiver; that this rule will make this cluster receiver channel 100% inaccessible.
| Code: |
SET CHLAUTH('TO.QMGRFRP1') +
TYPE(ADDRESSMAP) +
ADDRESS('*') +
DESCR('CLSRCVR Back Stop Rule - block all connections to the CLUSRCVR for this Full Repsoitory') +
USERSRC(NOACCESS) +
WARN(NO) +
ACTION(REPLACE) |
OK, so how do we get a white list going?
The ‘Channel_ID’ ID is an ID with restricted access to the QM (it does allow access the S.C.C.Q).
The problem as I see it is that the ADDRESS parameter does not allow a list. I can use wild cards, but to wildcard it enough to allow all the potential legit Partial Repositories would make it too open.
| Code: |
SET CHLAUTH('TO.QMGRFRP1) +
TYPE(ADDRESSMAP) +
ADDRESS('<list valid IP addresses here, or if only 1 IP is allowed, make multiple records each with one IP?>') +
DESCR('This rule only allows the IP addresses of legit QMs we want in this cluster') +
USERSRC(MAP) +
MCAUSER(‘Channel_ID’) +
ACTION(REPLACE) |
Is there any way to provide a specific white list of IP addresses into an ADDRESSMAP rule?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon May 20, 2013 8:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
CHeck it out. You can also specify in your whitelist the name of the partner qmgr on the channel. This would prevent having a non authorized qmgr connect if it was built on the same host as an authorized one...
By the way have you tried separating the ip addresses with commas?
Also look at action add instead of replace...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 24, 2013 6:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
OK, using ACTION(ADD) works and ends up producing a seperate entry for each. So the first rule should block all incoming IP addresses to this CLUSRCVR channel. And then the second rule will allow connections only from '123.456.123.33', the 3rd rule adds the ability of the '123.789.123.22' address to connect and the 4th rule allows the '123.555.222.11' address.
The CLUSRCVR ends up not allowing any connections unless they come from one of these 3 and when they do the channel instance runs under the MCAUSER of CHANNEL_ID. I think / hope so. The new servers will be here in a couple of weeks and we'll get to play with it then to confirm.
Anyone see any holes? Assume all other incoming channels are protected with similiar CHLAUTH rules and/or a security exit that does authentication.
The only drawback I see is now we are tied to IP addresses. We were always able to say "MQ is fine, don't worry, we do everything by DNS name." But now we are hard coding IPs. Ugh.
Yes, I voted for this RFE.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=30715
| Code: |
SET CHLAUTH('TO.QMGRFRP1') +
TYPE(ADDRESSMAP) +
ADDRESS('*') +
DESCR('DEFAULT RULE TO BLOACK ALL ACCESS TO THIS CLUSRCVR CHANNEL') +
USERSRC(NOACCESS) +
WARN(NO) +
ACTION(ADD)
SET CHLAUTH('TO.QMGRFRP1') +
TYPE(ADDRESSMAP) +
ADDRESS('123.456.123.33') +
DESCR('TO ALLOW THIS IP ADDRESS TO CONNECT TO THIS CLUSRCVR CHANNEL') +
USERSRC(MAP) +
MCAUSER('CHANNEL_ID') +
ACTION(ADD)
SET CHLAUTH('TO.QMGRFRP1') +
TYPE(ADDRESSMAP) +
ADDRESS('123.789.123.22') +
DESCR('TO ALLOW THIS IP ADDRESS TO CONNECT TO THIS CLUSRCVR CHANNEL') +
USERSRC(MAP) +
MCAUSER('CHANNEL_ID') +
ACTION(ADD)
SET CHLAUTH('TO.QMGRFRP1') +
TYPE(ADDRESSMAP) +
ADDRESS('123.555.222.11') +
DESCR('TO ALLOW THIS IP ADDRESS TO CONNECT TO THIS CLUSRCVR CHANNEL') +
USERSRC(MAP) +
MCAUSER('CHANNEL_ID') +
ACTION(ADD)
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 24, 2013 9:42 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Tying to IP addresses is a "security" feature. Because a DNS entry could always be spoofed?...
But you can also use auth records to allow only qmgrs with a specific name to access the channel... Not a protection against anyone building a qmgr with an authorized name and adding it to an authorized host...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 24, 2013 10:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Tying to IP addresses is a "security" feature. Because a DNS entry could always be spoofed?...
|
I suppose there is a reason the firewall guys only deal with IP addresses even for the connections originating from the internal systems.
Regarding spoofing, I've heard of IP addresses being vulnerable to the same thing.
Being able to CHLAUTH by remote QM name is a nice feature, but as you say its trivial to create a QM with any name you want, even if its a QM name already in use.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri May 24, 2013 2:33 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
Being able to CHLAUTH by remote QM name is a nice feature, but as you say its trivial to create a QM with any name you want, even if its a QM name already in use. |
Would a filter on remote QMID be a safer option as it is harder to reproduce?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 24, 2013 3:45 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Michael Dag wrote: |
| PeterPotkay wrote: |
Being able to CHLAUTH by remote QM name is a nice feature, but as you say its trivial to create a QM with any name you want, even if its a QM name already in use. |
Would a filter on remote QMID be a safer option as it is harder to reproduce? |
A great idea! But do all sending QM to QM channels (CLUSNDR, SNDR ,SRVR) send a QMID? I'm guessing not and they would have to be changed to do so before CHLAUTH by QMID could be fully implemented by IBM. But I like it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
