How do you get a QM to QM Alias itself

[Potkay, Peter M (CTO Architecture + Engineering)]

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Peter,

I think you could reverse the QMEDGEx option.

Instead of QMZ changing their QRemote, delete the QMEDGE queue manager and replace it with QMEDGEx.

All of the queues, channels, cluster memberships etc of QMEDGE would be recreated on QMEDGEx. It’s a bit ugly, quite disruptive, and might require QMZ to issue channel sequence number resets, but I think it should work.

The only other way I can think of is to use a channel message exit to alter the QMGR name in the transmission queue header of the incoming message.

There is a sample exit in the "Secure Messaging Scenarios with WebSphere MQ” rebook which might assist. It doesn’t change the MQMD qmgr name as it stands, but it could be enhanced to provide that function.

Have a look at the section with the comment block…
“/* Modifying the ReplyToQmgr and ReplyToQ on normal channels to allow */
/* a flexible B2B integration without revealing your bussiness partners */
/* when modifying your WebSphere MQ infrastructure. */”

Excerpt From: IBM Redbooks. “Secure Messaging Scenarios with WebSphere MQ.” iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=646325420

You should be able to use that as an example of how to alter data in a message exit before passing the message through so that the MCA can put it to the target queue. The MQXQH contains the original target qmgr value (pXqh->RemoteQMgrName).

Regards,


Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by Potkay, Peter M (CTO Architecture + Engineering)
QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')
And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')
The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.
Here's the topology change and my question.
QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.
The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')
I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.
Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.
I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.
A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Hi Peter,

I don't know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE('FOR.COMPANYZ') on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
would become
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMGWAYàCLUSTER CHANNELàQMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by Neil Casey
Hi Peter,
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.
Thanks,
Tim
Sent: Wednesday, June 04, 2014 8:10 PM
Subject: How do you get a QM to QM Alias itself
QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')
And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')
The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.
Here's the topology change and my question.
QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.
The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')
I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.
Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.
I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.
A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn't do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('NOQMGR') +
XMITQ('QMGWAY')

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE('NOQMGR') +
RQMNAME(' ') +
RNAME(' ') +
XMITQ(' ')

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-***@public.gmane.org]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:***@AON.COM>> wrote:


Hi Peter,

I don't know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE('FOR.COMPANYZ') on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected - we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for 'BOBLOBLAW', so the just sit there. I don't think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won't resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won't work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')



I don't think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I'm stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn't allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn't do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('NOQMGR') +
XMITQ('QMGWAY')

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE('NOQMGR') +
RQMNAME(' ') +
RNAME(' ') +
XMITQ(' ')

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-***@public.gmane.org]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:***@AON.COM>> wrote:

Hi Peter,

I don't know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE('FOR.COMPANYZ') on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jefferson Lowrey]

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and
then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)"
<***@THEHARTFORD.COM>
To: ***@listserv.meduniwien.ac.at
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>



Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is
expected – we forced the messages into the S.C.T.Q with the Remote Queue
Definition specifying the XMITQ to use, but there are no cluster channels
looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think
its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the
XMITQ parameter of a remote queue def. If the message won’t resolve on its
own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t
work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on
EDGEQM with 2091 XMIT queue type error, and the Destination QM still
showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')



I don’t think there is any way to make a remote queue definition

Post by Potkay, Peter M (CTO Architecture + Engineering)
defined on a QM in the cluster<<< load balance to the queues on other

QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and
the MCAUSER on the RCVR channel from the business partner only has access
to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I’m stuck if the remote queue def on the 3rd party QM
specifies the name of the EDGEQM in the RQMNAME field. It eliminates the
use of an Alias queue on EDGEQM, and forces the use of a Remote Q on
EDGEQM, which doesn’t allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something
that is not spaces. I got an error in my testing when the RQMNAME was
spaces.

From a security perspective, I am thinking QMZ still only has access to
PUT to FOR.COMPANYZ, with the current qremote set up. So they really can
only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering
that QMEDGE participates in, via the qremote definition on QMEDGE. So I
would think they are still limited to just accessing the
THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect
the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on
QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish
it in the cluster? I would expect that to work, but it doesn’t do a good
job of locking down the security, as it could be used to target any queue
on QMB or QMC (although hopefully the OAM rules would prevent the messages
actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is
a problem, because without an exit, there is nothing to prevent the 3rd
party from trying to send to any queue on any cluster connected queue
manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to
add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that
QMEDGE is not a member of the cluster. This also solves the resolution
problem as the QR on QMEDGE can map the actual queue manager name to an
alias which resolves to blank on the cluster gateway.

In other words:

QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
would become
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMGWAYàCLUSTER CHANNELàQMB
or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes
to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the
cluster.


Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] ***@syntegrity.com.au
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC
3006
Analyse >> Integrate >> Secure >> Educate



On 5 Jun 2014, at 1:27 pm, Tim Zielke <***@AON.COM> wrote:

Hi Peter,

I don’t know how you feel about this change, but it looks like this would
work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE(‘FOR.COMPANYZ’) on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on
QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and
QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who
want to send messages to queues on your QMs that they have no business
sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called
THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with
an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up
for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from
Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as
QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called
THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA.
And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to
have a remote queue on a clustered QM aim at clustered queues on other QMs
in that cluster and get load balancing. (if you know a way stop reading
now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same
name, it can load balance. On QMEDGE I delete the remote queue def and
replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and
QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE
starts getting messages with 2082 - Unknown Alias Base Queue. Their remote
queue def specifies QMEDGE as the destination QM. That locks in the name
resolution to QMEDGE and doesn't allow the Alias queue def to pass the
message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on
QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE
with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the
destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then
defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get
around this without making a change on QMZ? I thought a QM Alias to itself
to blank out the QM name would work, but no luck. I was hoping I could
stay with Remote Queue Defs but they don't allow load balancing
apparently.



Peter Potkay

************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can’t QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________



Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')



I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:***@01CF80A4.A8700820][phone]<tel:+61%20414%20615%20334>[cid:***@01CF80A4.A8700820] ***@syntegrity.com.au <mailto:***@syntegrity.com.au>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:***@01CF80A4.A8700820]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <***@AON.COM<mailto:***@AON.COM>> wrote:

Hi Peter,

I don’t know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE(‘FOR.COMPANYZ’) on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jefferson Lowrey]

Ok.

define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.

define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on
EDGEQM

note the difference between FOR and FROM.

Don't currently have a cluster I can play with, but this should do the
trick.

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)"
<***@THEHARTFORD.COM>
To: ***@listserv.meduniwien.ac.at
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>



Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is
telling EDGEQM to only consider EDGEQM as potential targets for the
message. This was fine when the destination queue on EDGEQM was a remote
queue, but is a problem when we want/need to replace that with an Alias
queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM
might see the clustered instances on QMB and QMC, its not free to load
balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from
the incoming messages but apparently you can’t QM Alias a QM to itself.
The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination
QM in the incoming message it gives up on any funky happenings with
changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and
then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <
***@THEHARTFORD.COM>
To: ***@listserv.meduniwien.ac.at
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>




Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is
expected – we forced the messages into the S.C.T.Q with the Remote Queue
Definition specifying the XMITQ to use, but there are no cluster channels
looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think
its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the
XMITQ parameter of a remote queue def. If the message won’t resolve on its
own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t
work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on
EDGEQM with 2091 XMIT queue type error, and the Destination QM still
showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')



I don’t think there is any way to make a remote queue definition

Post by Potkay, Peter M (CTO Architecture + Engineering)
defined on a QM in the cluster<<< load balance to the queues on other

QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and
the MCAUSER on the RCVR channel from the business partner only has access
to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I’m stuck if the remote queue def on the 3rd party QM
specifies the name of the EDGEQM in the RQMNAME field. It eliminates the
use of an Alias queue on EDGEQM, and forces the use of a Remote Q on
EDGEQM, which doesn’t allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something
that is not spaces. I got an error in my testing when the RQMNAME was
spaces.

From a security perspective, I am thinking QMZ still only has access to
PUT to FOR.COMPANYZ, with the current qremote set up. So they really can
only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering
that QMEDGE participates in, via the qremote definition on QMEDGE. So I
would think they are still limited to just accessing the
THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect
the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on
QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish
it in the cluster? I would expect that to work, but it doesn’t do a good
job of locking down the security, as it could be used to target any queue
on QMB or QMC (although hopefully the OAM rules would prevent the messages
actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is
a problem, because without an exit, there is nothing to prevent the 3rd
party from trying to send to any queue on any cluster connected queue
manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to
add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that
QMEDGE is not a member of the cluster. This also solves the resolution
problem as the QR on QMEDGE can map the actual queue manager name to an
alias which resolves to blank on the cluster gateway.

In other words:

QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
would become
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMGWAYàCLUSTER CHANNELàQMB
or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes
to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the
cluster.


Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] ***@syntegrity.com.au
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC
3006
Analyse >> Integrate >> Secure >> Educate



On 5 Jun 2014, at 1:27 pm, Tim Zielke <***@AON.COM> wrote:

Hi Peter,

I don’t know how you feel about this change, but it looks like this would
work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE(‘FOR.COMPANYZ’) on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on
QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and
QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who
want to send messages to queues on your QMs that they have no business
sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called
THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with
an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up
for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from
Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as
QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called
THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA.
And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to
have a remote queue on a clustered QM aim at clustered queues on other QMs
in that cluster and get load balancing. (if you know a way stop reading
now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same
name, it can load balance. On QMEDGE I delete the remote queue def and
replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and
QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE
starts getting messages with 2082 - Unknown Alias Base Queue. Their remote
queue def specifies QMEDGE as the destination QM. That locks in the name
resolution to QMEDGE and doesn't allow the Alias queue def to pass the
message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on
QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE
with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the
destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then
defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get
around this without making a change on QMZ? I thought a QM Alias to itself
to blank out the QM name would work, but no luck. I was hoping I could
stay with Remote Queue Defs but they don't allow load balancing
apparently.



Peter Potkay

************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com





List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com




List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

“define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.”
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I’ll skip the step of definining another Q Alias on QMB and QMC – not sure what it buys.


“define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM”
I tried the following, since that is the clustered name
“define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM”

But it throws a MQRC 2087 when you try and put to it – Unknown Remote QM. It won’t take a blank RQMNAME.



Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 10:12 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

Ok.

define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.

define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM

note the difference between FOR and FROM.

Don't currently have a cluster I can play with, but this should do the trick.

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________



Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can’t QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________




Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')



I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:***@01CF80AF.5E9048E0][phone]<tel:+61%20414%20615%20334>[cid:***@01CF80AF.5E9048E0] ***@syntegrity.com.au <mailto:***@syntegrity.com.au>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:***@01CF80AF.5E9048E0]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <***@AON.COM<mailto:***@AON.COM>> wrote:

Hi Peter,

I don’t know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE(‘FOR.COMPANYZ’) on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>




________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.


On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')

On EDGEQM I do not delete the Remote Queue Def, I alter it to look like this:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')

I do not create an Alias queue of any kind on EDGEQM.


On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'

But then I add this to QMB and QMC:
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER (‘My ClusterName’)


And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.

It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what’s wrong with it.



Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 11:18 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

“define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.”
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I’ll skip the step of definining another Q Alias on QMB and QMC – not sure what it buys.


“define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM”
I tried the following, since that is the clustered name
“define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM”

But it throws a MQRC 2087 when you try and put to it – Unknown Remote QM. It won’t take a blank RQMNAME.



Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 10:12 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Ok.

define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.

define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM

note the difference between FOR and FROM.

Don't currently have a cluster I can play with, but this should do the trick.

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________



Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can’t QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________




Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')



I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:***@01CF80B1.FF0F1920][phone]<tel:+61%20414%20615%20334>[cid:***@01CF80B1.FF0F1920] ***@syntegrity.com.au <mailto:***@syntegrity.com.au>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:***@01CF80B1.FF0F1920]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <***@AON.COM<mailto:***@AON.COM>> wrote:

Hi Peter,

I don’t know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE(‘FOR.COMPANYZ’) on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>




________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Peter,

I believe your plan will work, but is exposing a security hole, albeit perhaps a small one, depending on your point of view.

Since the routing to QMB and QMC is now via the QMgr alias, instead of via the QName, your OAM rules on EDGEQM will have to grant +PUT +SETALL access to FROMZ to the MCAUSER of the incoming channel from QMZ. I believe FROMZ is the profile which will be checked, not THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF, and in fact, THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF doesn’t need to be exposed in the cluster at all. Its definition won’t get used.

So, If the administrators of QMZ were to create a new QRemote pointing to EDGEMQ:
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)

Then the message will flow to EDGEQM, be routed to FROMZ (which is actually QMB or QMC) via the cluster (which will be allowed). The message will only be blocked when arriving at QMB or QMC by well planned OAM rules and MCAUSER configuration at those queue managers.

So if nothing else, QMZ could manage to place messages on the DLQ of QMB and QMC either by putting to non-existent queues, or by putting to queues which it doesn’t have access to.

Either way, my view of the purpose of having a gateway queue manager is to block access attempts at it, and not allow the potential for messages to flow through to queue managers closer to the heart of your organisation unless they are explicitly permitted. Allowing routing to queue managers via a clustered QMgr alias violates that function of the gateway. The same exposure would be in place if you granted access to the channel to put messages to a conventional (distributed) queue manager alias too.

So, to recap, your plan should work, but allows messages to flow to QMB and QMC which should not reach there. Even though OAM should block the messages from reaching non-permitted queues, your are still exposing core queue managers to exposures that should be blocked at the gateway.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by Potkay, Peter M (CTO Architecture + Engineering)
I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.
On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')
I do not create an Alias queue of any kind on EDGEQM.
On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER (‘My ClusterName’)
And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.
It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what’s wrong with it.
Peter Potkay
Sent: Thursday, June 05, 2014 11:18 AM
Subject: Re: How do you get a QM to QM Alias itself
“define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.”
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I’ll skip the step of definining another Q Alias on QMB and QMC – not sure what it buys.
“define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM”
I tried the following, since that is the clustered name
“define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM”
But it throws a MQRC 2087 when you try and put to it – Unknown Remote QM. It won’t take a blank RQMNAME.
Peter Potkay
Sent: Thursday, June 05, 2014 10:12 AM
Subject: Re: How do you get a QM to QM Alias itself
Ok.
define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.
define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM
note the difference between FOR and FROM.
Don't currently have a cluster I can play with, but this should do the trick.
Thank you,
Jeff Lowrey
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.
If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.
Peter Potkay
Sent: Thursday, June 05, 2014 9:48 AM
Subject: Re: How do you get a QM to QM Alias itself
What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?
Thank you,
Jeff Lowrey
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Tim,
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.
I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')
DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')
I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.
Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.
But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/
Peter Potkay
Sent: Thursday, June 05, 2014 8:10 AM
Subject: Re: How do you get a QM to QM Alias itself
Hi Neil,
BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.
From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.
Thanks,
Tim
Sent: Wednesday, June 04, 2014 10:49 PM
Subject: Re: How do you get a QM to QM Alias itself
Hi Tim,
this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.
Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).
Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.
Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
would become
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMGWAYàCLUSTER CHANNELàQMB or QMC
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)
And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Hi Peter,
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.
Thanks,
Tim
Sent: Wednesday, June 04, 2014 8:10 PM
Subject: How do you get a QM to QM Alias itself
QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')
And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')
The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.
Here's the topology change and my question.
QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.
The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')
I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.
Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.
I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.
A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Neil,
I don't think the security hole is there.

If Company Z defined the ATTACK.VECTOR queue as you describe below
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)

the RCVR channel in EDGEQM will attempt to resolve to the FROMZ object, which the User ID the RCVR channel is running as does not have access to. The message will go to the DLQ with a 2035, and an Authority Event will be generated by the EDGEQM (if Auth Events are enabled like they should be). Testing confirms this.


If Company Z then tried this
define qr(ATTACK.VECTOR) +
rqmname(EDGEQM) +
rrname(ANY.QUEUE.NAME.YOU.WANNA.TRY.PUNK)
xmitq(EDGEQM)

any attempt to use this would also end up in the DLQ with a corresponding Auth event.

Company Z can only address the specific queues I intend them to use on EDGEQM, because the channel they are restricted to can only put to a very specific subset of queues that only exist on EDGEQM. I do not need to give them access to the S.C.T.Q. or the clustered QM alias names on the internal QMs.


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, June 05, 2014 6:59 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself

Hi Peter,

I believe your plan will work, but is exposing a security hole, albeit perhaps a small one, depending on your point of view.

Since the routing to QMB and QMC is now via the QMgr alias, instead of via the QName, your OAM rules on EDGEQM will have to grant +PUT +SETALL access to FROMZ to the MCAUSER of the incoming channel from QMZ. I believe FROMZ is the profile which will be checked, not THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF, and in fact, THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF doesn't need to be exposed in the cluster at all. Its definition won't get used.

So, If the administrators of QMZ were to create a new QRemote pointing to EDGEMQ:
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)

Then the message will flow to EDGEQM, be routed to FROMZ (which is actually QMB or QMC) via the cluster (which will be allowed). The message will only be blocked when arriving at QMB or QMC by well planned OAM rules and MCAUSER configuration at those queue managers.

So if nothing else, QMZ could manage to place messages on the DLQ of QMB and QMC either by putting to non-existent queues, or by putting to queues which it doesn't have access to.

Either way, my view of the purpose of having a gateway queue manager is to block access attempts at it, and not allow the potential for messages to flow through to queue managers closer to the heart of your organisation unless they are explicitly permitted. Allowing routing to queue managers via a clustered QMgr alias violates that function of the gateway. The same exposure would be in place if you granted access to the channel to put messages to a conventional (distributed) queue manager alias too.

So, to recap, your plan should work, but allows messages to flow to QMB and QMC which should not reach there. Even though OAM should block the messages from reaching non-permitted queues, your are still exposing core queue managers to exposures that should be blocked at the gateway.

Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-***@public.gmane.org]

On 6 Jun 2014, at 1:33 am, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:


I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.


On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')

On EDGEQM I do not delete the Remote Queue Def, I alter it to look like this:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')

I do not create an Alias queue of any kind on EDGEQM.


On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'

But then I add this to QMB and QMC:
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER ('My ClusterName')


And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.

It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what's wrong with it.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 11:18 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

"define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster."
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I'll skip the step of definining another Q Alias on QMB and QMC - not sure what it buys.


"define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM"
I tried the following, since that is the clustered name
"define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM"

But it throws a MQRC 2087 when you try and put to it - Unknown Remote QM. It won't take a blank RQMNAME.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 10:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Ok.

define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.

define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM

note the difference between FOR and FROM.

Don't currently have a cluster I can play with, but this should do the trick.

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________



Jeff,
Company Z's Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can't QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________




Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected - we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for 'BOBLOBLAW', so the just sit there. I don't think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won't resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won't work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')



I don't think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I'm stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn't allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn't do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('NOQMGR') +
XMITQ('QMGWAY')

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE('NOQMGR') +
RQMNAME(' ') +
RNAME(' ') +
XMITQ(' ')

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

<image001.jpg>[phone]<tel:+61%20414%20615%20334><image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

<image003.png>

On 5 Jun 2014, at 1:27 pm, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:***@AON.COM>> wrote:

Hi Peter,

I don't know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE('FOR.COMPANYZ') on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>




________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

OK, I see what’s going on now.

That’s clever… devious AND clever.

The security check is still against the QR, which then resolves to the cluster visible qmgr alias, but you don’t have to grant access to that, because MQ only performs the security check against the original queue name.

I think it will work for you. I would still prefer personally that my external gateway queue manager wasn’t in an internal cluster because qmgr names have to be resolvable, and only OAM security is protecting you, but that is a matter of whether you need a belt and braces, or feel comfortable with just one layer of protection.

All the best.

Regards,

Neil C.

Neil,
I don’t think the security hole is there.
If Company Z defined the ATTACK.VECTOR queue as you describe below
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)
the RCVR channel in EDGEQM will attempt to resolve to the FROMZ object, which the User ID the RCVR channel is running as does not have access to. The message will go to the DLQ with a 2035, and an Authority Event will be generated by the EDGEQM (if Auth Events are enabled like they should be). Testing confirms this.
If Company Z then tried this
define qr(ATTACK.VECTOR) +
rqmname(EDGEQM) +
rrname(ANY.QUEUE.NAME.YOU.WANNA.TRY.PUNK)
xmitq(EDGEQM)
any attempt to use this would also end up in the DLQ with a corresponding Auth event.
Company Z can only address the specific queues I intend them to use on EDGEQM, because the channel they are restricted to can only put to a very specific subset of queues that only exist on EDGEQM. I do not need to give them access to the S.C.T.Q. or the clustered QM alias names on the internal QMs.
Peter Potkay
Sent: Thursday, June 05, 2014 6:59 PM
Subject: Re: How do you get a QM to QM Alias itself
Hi Peter,
I believe your plan will work, but is exposing a security hole, albeit perhaps a small one, depending on your point of view.
Since the routing to QMB and QMC is now via the QMgr alias, instead of via the QName, your OAM rules on EDGEQM will have to grant +PUT +SETALL access to FROMZ to the MCAUSER of the incoming channel from QMZ. I believe FROMZ is the profile which will be checked, not THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF, and in fact, THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF doesn’t need to be exposed in the cluster at all. Its definition won’t get used.
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)
Then the message will flow to EDGEQM, be routed to FROMZ (which is actually QMB or QMC) via the cluster (which will be allowed). The message will only be blocked when arriving at QMB or QMC by well planned OAM rules and MCAUSER configuration at those queue managers.
So if nothing else, QMZ could manage to place messages on the DLQ of QMB and QMC either by putting to non-existent queues, or by putting to queues which it doesn’t have access to.
Either way, my view of the purpose of having a gateway queue manager is to block access attempts at it, and not allow the potential for messages to flow through to queue managers closer to the heart of your organisation unless they are explicitly permitted. Allowing routing to queue managers via a clustered QMgr alias violates that function of the gateway. The same exposure would be in place if you granted access to the channel to put messages to a conventional (distributed) queue manager alias too.
So, to recap, your plan should work, but allows messages to flow to QMB and QMC which should not reach there. Even though OAM should block the messages from reaching non-permitted queues, your are still exposing core queue managers to exposures that should be blocked at the gateway.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.
On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')
I do not create an Alias queue of any kind on EDGEQM.
On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER (‘My ClusterName’)
And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.
It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what’s wrong with it.
Peter Potkay
Sent: Thursday, June 05, 2014 11:18 AM
Subject: Re: How do you get a QM to QM Alias itself
“define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.”
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I’ll skip the step of definining another Q Alias on QMB and QMC – not sure what it buys.
“define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM”
I tried the following, since that is the clustered name
“define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM”
But it throws a MQRC 2087 when you try and put to it – Unknown Remote QM. It won’t take a blank RQMNAME.
Peter Potkay
Sent: Thursday, June 05, 2014 10:12 AM
Subject: Re: How do you get a QM to QM Alias itself
Ok.
define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.
define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM
note the difference between FOR and FROM.
Don't currently have a cluster I can play with, but this should do the trick.
Thank you,
Jeff Lowrey
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.
If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.
Peter Potkay
Sent: Thursday, June 05, 2014 9:48 AM
Subject: Re: How do you get a QM to QM Alias itself
What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?
Thank you,
Jeff Lowrey
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Tim,
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.
I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')
DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')
I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.
Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.
But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/
Peter Potkay
Sent: Thursday, June 05, 2014 8:10 AM
Subject: Re: How do you get a QM to QM Alias itself
Hi Neil,
BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.
From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.
Thanks,
Tim
Sent: Wednesday, June 04, 2014 10:49 PM
Subject: Re: How do you get a QM to QM Alias itself
Hi Tim,
this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.
Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).
Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.
Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
would become
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMGWAYàCLUSTER CHANNELàQMB or QMC
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)
And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Hi Peter,
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.
Thanks,
Tim
Sent: Wednesday, June 04, 2014 8:10 PM
Subject: How do you get a QM to QM Alias itself
QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')
And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')
The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.
Here's the topology change and my question.
QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.
The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')
I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.
Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.
I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.
A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

OAM Security the only thing protecting you in the end whether the Edge QM is in the internal cluster or not.

It can be QMZ-->EDGEQM-->THISQM-->THATQM-->GATEWAYQM

If OAM Security isn't correct at EDGEQM, they'll get to THISQM, and if its wrong there, they can get to THATQM, and if its wrong there, they can get to GATEWAYQM.

I'd like to understand if there is any vulnerability in having EDGEQM and GATEWAYQM be one and the same that can't be mitigated by proper OAM rules and MCAUSER values on secured incoming channels. If we can avoid the costs of an additional QM and be no less secure, I'd prefer one less QM in the environment and one less hop in the route between companies.


I'd never allow the QMZ QM in my cluster.

Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Friday, June 06, 2014 8:34 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself

OK, I see what's going on now.

That's clever... devious AND clever.

The security check is still against the QR, which then resolves to the cluster visible qmgr alias, but you don't have to grant access to that, because MQ only performs the security check against the original queue name.

I think it will work for you. I would still prefer personally that my external gateway queue manager wasn't in an internal cluster because qmgr names have to be resolvable, and only OAM security is protecting you, but that is a matter of whether you need a belt and braces, or feel comfortable with just one layer of protection.

All the best.

Regards,

Neil C.
On 6 Jun 2014, at 10:18 pm, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:


Neil,
I don't think the security hole is there.

If Company Z defined the ATTACK.VECTOR queue as you describe below
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)

the RCVR channel in EDGEQM will attempt to resolve to the FROMZ object, which the User ID the RCVR channel is running as does not have access to. The message will go to the DLQ with a 2035, and an Authority Event will be generated by the EDGEQM (if Auth Events are enabled like they should be). Testing confirms this.


If Company Z then tried this
define qr(ATTACK.VECTOR) +
rqmname(EDGEQM) +
rrname(ANY.QUEUE.NAME.YOU.WANNA.TRY.PUNK)
xmitq(EDGEQM)

any attempt to use this would also end up in the DLQ with a corresponding Auth event.

Company Z can only address the specific queues I intend them to use on EDGEQM, because the channel they are restricted to can only put to a very specific subset of queues that only exist on EDGEQM. I do not need to give them access to the S.C.T.Q. or the clustered QM alias names on the internal QMs.


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, June 05, 2014 6:59 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Peter,

I believe your plan will work, but is exposing a security hole, albeit perhaps a small one, depending on your point of view.

Since the routing to QMB and QMC is now via the QMgr alias, instead of via the QName, your OAM rules on EDGEQM will have to grant +PUT +SETALL access to FROMZ to the MCAUSER of the incoming channel from QMZ. I believe FROMZ is the profile which will be checked, not THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF, and in fact, THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF doesn't need to be exposed in the cluster at all. Its definition won't get used.

So, If the administrators of QMZ were to create a new QRemote pointing to EDGEMQ:
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)

Then the message will flow to EDGEQM, be routed to FROMZ (which is actually QMB or QMC) via the cluster (which will be allowed). The message will only be blocked when arriving at QMB or QMC by well planned OAM rules and MCAUSER configuration at those queue managers.

So if nothing else, QMZ could manage to place messages on the DLQ of QMB and QMC either by putting to non-existent queues, or by putting to queues which it doesn't have access to.

Either way, my view of the purpose of having a gateway queue manager is to block access attempts at it, and not allow the potential for messages to flow through to queue managers closer to the heart of your organisation unless they are explicitly permitted. Allowing routing to queue managers via a clustered QMgr alias violates that function of the gateway. The same exposure would be in place if you granted access to the channel to put messages to a conventional (distributed) queue manager alias too.

So, to recap, your plan should work, but allows messages to flow to QMB and QMC which should not reach there. Even though OAM should block the messages from reaching non-permitted queues, your are still exposing core queue managers to exposures that should be blocked at the gateway.

Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

<image001.jpg> [phone]<tel:+61%20414%20615%20334><image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

<image003.png>

On 6 Jun 2014, at 1:33 am, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:



I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.


On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')

On EDGEQM I do not delete the Remote Queue Def, I alter it to look like this:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')

I do not create an Alias queue of any kind on EDGEQM.


On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'

But then I add this to QMB and QMC:
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER ('My ClusterName')


And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.

It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what's wrong with it.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 11:18 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

"define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster."
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I'll skip the step of definining another Q Alias on QMB and QMC - not sure what it buys.


"define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM"
I tried the following, since that is the clustered name
"define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM"

But it throws a MQRC 2087 when you try and put to it - Unknown Remote QM. It won't take a blank RQMNAME.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 10:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Ok.

define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.

define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM

note the difference between FOR and FROM.

Don't currently have a cluster I can play with, but this should do the trick.

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________



Jeff,
Company Z's Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can't QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________




Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected - we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for 'BOBLOBLAW', so the just sit there. I don't think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won't resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won't work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')



I don't think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I'm stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn't allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn't do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('NOQMGR') +
XMITQ('QMGWAY')

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE('NOQMGR') +
RQMNAME(' ') +
RNAME(' ') +
XMITQ(' ')

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

<image001.jpg>[phone]<tel:+61%20414%20615%20334><image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

<image003.png>

On 5 Jun 2014, at 1:27 pm, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:***@AON.COM>> wrote:

Hi Peter,

I don't know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE('FOR.COMPANYZ') on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>




________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Peter,

After your description which made me realise that the security check was against the QMEDGE:FOR.COMPANYZ queue, I couldn’t see any mechanism that QMZ could use the put messages to unauthorised locations beyond EDGEQM. So it looks to me like you should be meeting your objective with this design.

Regards,

Neil C.

Post by Potkay, Peter M (CTO Architecture + Engineering)
OAM Security the only thing protecting you in the end whether the Edge QM is in the internal cluster or not.
It can be QMZàEDGEQMàTHISQMàTHATQMàGATEWAYQM
If OAM Security isn’t correct at EDGEQM, they’ll get to THISQM, and if its wrong there, they can get to THATQM, and if its wrong there, they can get to GATEWAYQM.
I’d like to understand if there is any vulnerability in having EDGEQM and GATEWAYQM be one and the same that can’t be mitigated by proper OAM rules and MCAUSER values on secured incoming channels. If we can avoid the costs of an additional QM and be no less secure, I’d prefer one less QM in the environment and one less hop in the route between companies.
I’d never allow the QMZ QM in my cluster.
Peter Potkay
Sent: Friday, June 06, 2014 8:34 AM
Subject: Re: How do you get a QM to QM Alias itself
OK, I see what’s going on now.
That’s clever… devious AND clever.
The security check is still against the QR, which then resolves to the cluster visible qmgr alias, but you don’t have to grant access to that, because MQ only performs the security check against the original queue name.
I think it will work for you. I would still prefer personally that my external gateway queue manager wasn’t in an internal cluster because qmgr names have to be resolvable, and only OAM security is protecting you, but that is a matter of whether you need a belt and braces, or feel comfortable with just one layer of protection.
All the best.
Regards,
Neil C.
Neil,
I don’t think the security hole is there.
If Company Z defined the ATTACK.VECTOR queue as you describe below
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)
the RCVR channel in EDGEQM will attempt to resolve to the FROMZ object, which the User ID the RCVR channel is running as does not have access to. The message will go to the DLQ with a 2035, and an Authority Event will be generated by the EDGEQM (if Auth Events are enabled like they should be). Testing confirms this.
If Company Z then tried this
define qr(ATTACK.VECTOR) +
rqmname(EDGEQM) +
rrname(ANY.QUEUE.NAME.YOU.WANNA.TRY.PUNK)
xmitq(EDGEQM)
any attempt to use this would also end up in the DLQ with a corresponding Auth event.
Company Z can only address the specific queues I intend them to use on EDGEQM, because the channel they are restricted to can only put to a very specific subset of queues that only exist on EDGEQM. I do not need to give them access to the S.C.T.Q. or the clustered QM alias names on the internal QMs.
Peter Potkay
Sent: Thursday, June 05, 2014 6:59 PM
Subject: Re: How do you get a QM to QM Alias itself
Hi Peter,
I believe your plan will work, but is exposing a security hole, albeit perhaps a small one, depending on your point of view.
Since the routing to QMB and QMC is now via the QMgr alias, instead of via the QName, your OAM rules on EDGEQM will have to grant +PUT +SETALL access to FROMZ to the MCAUSER of the incoming channel from QMZ. I believe FROMZ is the profile which will be checked, not THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF, and in fact, THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF doesn’t need to be exposed in the cluster at all. Its definition won’t get used.
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)
Then the message will flow to EDGEQM, be routed to FROMZ (which is actually QMB or QMC) via the cluster (which will be allowed). The message will only be blocked when arriving at QMB or QMC by well planned OAM rules and MCAUSER configuration at those queue managers.
So if nothing else, QMZ could manage to place messages on the DLQ of QMB and QMC either by putting to non-existent queues, or by putting to queues which it doesn’t have access to.
Either way, my view of the purpose of having a gateway queue manager is to block access attempts at it, and not allow the potential for messages to flow through to queue managers closer to the heart of your organisation unless they are explicitly permitted. Allowing routing to queue managers via a clustered QMgr alias violates that function of the gateway. The same exposure would be in place if you granted access to the channel to put messages to a conventional (distributed) queue manager alias too.
So, to recap, your plan should work, but allows messages to flow to QMB and QMC which should not reach there. Even though OAM should block the messages from reaching non-permitted queues, your are still exposing core queue managers to exposures that should be blocked at the gateway.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.
On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')
I do not create an Alias queue of any kind on EDGEQM.
On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER (‘My ClusterName’)
And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.
It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what’s wrong with it.
Peter Potkay
Sent: Thursday, June 05, 2014 11:18 AM
Subject: Re: How do you get a QM to QM Alias itself
“define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.”
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I’ll skip the step of definining another Q Alias on QMB and QMC – not sure what it buys.
“define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM”
I tried the following, since that is the clustered name
“define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM”
But it throws a MQRC 2087 when you try and put to it – Unknown Remote QM. It won’t take a blank RQMNAME.
Peter Potkay
Sent: Thursday, June 05, 2014 10:12 AM
Subject: Re: How do you get a QM to QM Alias itself
Ok.
define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.
define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM
note the difference between FOR and FROM.
Don't currently have a cluster I can play with, but this should do the trick.
Thank you,
Jeff Lowrey
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.
If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.
Peter Potkay
Sent: Thursday, June 05, 2014 9:48 AM
Subject: Re: How do you get a QM to QM Alias itself
What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?
Thank you,
Jeff Lowrey
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Tim,
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.
I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')
DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')
I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.
Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.
But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/
Peter Potkay
Sent: Thursday, June 05, 2014 8:10 AM
Subject: Re: How do you get a QM to QM Alias itself
Hi Neil,
BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.
From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.
Thanks,
Tim
Sent: Wednesday, June 04, 2014 10:49 PM
Subject: Re: How do you get a QM to QM Alias itself
Hi Tim,
this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.
Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).
Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.
Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
would become
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMGWAYàCLUSTER CHANNELàQMB or QMC
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)
And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Hi Peter,
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.
Thanks,
Tim
Sent: Wednesday, June 04, 2014 8:10 PM
Subject: How do you get a QM to QM Alias itself
QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF
QMZàSNDR/RCVR CHANNELàQMEDGEàSNDR/RCVR CHANNELàQMA
There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')
And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')
The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.
Here's the topology change and my question.
QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.
The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')
I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.
Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.
I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.
A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Hi Peter,

I swear this was working last night, but it is not this morning. Also, this idea wasn't taking into account (due to my own ignorance) the role that the RQMNAME plays with message routing. When I test now, the message just sits on the SCTQ since the BOBLOBLAW queue manager is unknown. And directly writing to the SYSTEM.CLUSTER.TRANSMIT.QUEUE from a qremote definition is probably not appropriate, too.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 7:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself

Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected - we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for 'BOBLOBLAW', so the just sit there. I don't think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won't resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won't work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')



I don't think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I'm stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn't allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn't do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('NOQMGR') +
XMITQ('QMGWAY')

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE('NOQMGR') +
RQMNAME(' ') +
RNAME(' ') +
XMITQ(' ')

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-cDCb70gxDLk+***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-cDCb70gxDLk+***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-cDCb70gxDLk+***@public.gmane.org]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:***@AON.COM>> wrote:

Hi Peter,

I don't know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE('FOR.COMPANYZ') on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Meekin, Paul]

Hi Peter,

Is this what you are looking for?
Configuring workload balancing from outside a cluster

http://www-01.ibm.com/support/knowledgecenter/api/content/SSFKSJ_7.1.0/com.ibm.mq.doc/qc10870_.htm

Seems to describe what you want to do.

Cheers,
Paul


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 05 June 2014 02:10
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=3b2abcbd69ba269849ccba69477d67f9fa5e1c915485d35ff4ad08ac2d017afa> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=aa6f1ef5e3d508e49e007c855ddac6c8cdcd2229b20c28e197324d96aee54259> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=fb5da0f7dbac1bea4023084c447e1ad4d673f3847a914be48ac5fd8be367073f>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Paul,
To make my original description below match what is described in the link you provided, I would need to ask Company Z to make the QM Alias in Procedure step #3, and for Company Z to modify their existing remote queue definition's RQMNAME to that new Alias queue.

I think it would work, but it would be 2 changes at Company Z which I'm trying to avoid.


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Meekin, Paul
Sent: Thursday, June 05, 2014 8:08 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself

Hi Peter,

Is this what you are looking for?
Configuring workload balancing from outside a cluster

http://www-01.ibm.com/support/knowledgecenter/api/content/SSFKSJ_7.1.0/com.ibm.mq.doc/qc10870_.htm

Seems to describe what you want to do.

Cheers,
Paul


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 05 June 2014 02:10
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=3b2abcbd69ba269849ccba69477d67f9fa5e1c915485d35ff4ad08ac2d017afa> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=aa6f1ef5e3d508e49e007c855ddac6c8cdcd2229b20c28e197324d96aee54259> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=fb5da0f7dbac1bea4023084c447e1ad4d673f3847a914be48ac5fd8be367073f>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Meekin, Paul]

Hi Peter,

Yeah, sorry. Forgot about that bit...


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 05 June 2014 13:17
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself

Paul,
To make my original description below match what is described in the link you provided, I would need to ask Company Z to make the QM Alias in Procedure step #3, and for Company Z to modify their existing remote queue definition's RQMNAME to that new Alias queue.

I think it would work, but it would be 2 changes at Company Z which I'm trying to avoid.


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Meekin, Paul
Sent: Thursday, June 05, 2014 8:08 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Peter,

Is this what you are looking for?
Configuring workload balancing from outside a cluster

http://www-01.ibm.com/support/knowledgecenter/api/content/SSFKSJ_7.1.0/com.ibm.mq.doc/qc10870_.htm<https://urldefense.proofpoint.com/v1/url?u=http://www-01.ibm.com/support/knowledgecenter/api/content/SSFKSJ_7.1.0/com.ibm.mq.doc/qc10870_.htm&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=c9pptkyVGzt2%2BnqCLj8196hYg%2B1e15uxgCOsIumbHpA%3D%0A&s=0ecd202b9a50bc21f7744200f5e75887934b1c2947bfe8a328a621566b889eea>

Seems to describe what you want to do.

Cheers,
Paul


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 05 June 2014 02:10
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=3b2abcbd69ba269849ccba69477d67f9fa5e1c915485d35ff4ad08ac2d017afa> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=aa6f1ef5e3d508e49e007c855ddac6c8cdcd2229b20c28e197324d96aee54259> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=eRwo0IDmFHkw3q7X0%2Fv9c0MsCavmWjaZ5a1pcLkpjCE%3D%0A&s=fb5da0f7dbac1bea4023084c447e1ad4d673f3847a914be48ac5fd8be367073f>

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=c9pptkyVGzt2%2BnqCLj8196hYg%2B1e15uxgCOsIumbHpA%3D%0A&s=3888ea9a002ad14efe18bb0d0792ba3c3814c15d7e3c832518841f915deef617> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=c9pptkyVGzt2%2BnqCLj8196hYg%2B1e15uxgCOsIumbHpA%3D%0A&s=765e2e299c3e825a88d0fa122ffa9b5795862c11e76a3ab8b3f12098e4ca2245> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=c9pptkyVGzt2%2BnqCLj8196hYg%2B1e15uxgCOsIumbHpA%3D%0A&s=836d04cc3fbd118263dc07b7c039845b0b3d1a1810492de8f20bccf8b6291908>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=c9pptkyVGzt2%2BnqCLj8196hYg%2B1e15uxgCOsIumbHpA%3D%0A&s=3888ea9a002ad14efe18bb0d0792ba3c3814c15d7e3c832518841f915deef617> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=c9pptkyVGzt2%2BnqCLj8196hYg%2B1e15uxgCOsIumbHpA%3D%0A&s=765e2e299c3e825a88d0fa122ffa9b5795862c11e76a3ab8b3f12098e4ca2245> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=ci4D8otONlaL2hVZCpx3l04VZWct8XdbLYsnfUNUrTc%3D%0A&m=c9pptkyVGzt2%2BnqCLj8196hYg%2B1e15uxgCOsIumbHpA%3D%0A&s=836d04cc3fbd118263dc07b7c039845b0b3d1a1810492de8f20bccf8b6291908>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Ian Alderson]

Peter,
I thought this was an interesting challenge, but trying various combinations of qremote and qalias on my sandbox cluster I couldn’t get it to work unless I created an additional hop to a 4th qmgr in the cluster.

As a left-field alternative, and I understand if it’s one that you don’t want to consider, could be to create a second EDGE qmgr, say EDGEQM2. And presuming that you have some IP/port mapping between you and Company Z (e.g. MQ IPT or NAT) then you could redirect incoming connections from Company Z to the new IP/port for EDGEQM2. That way when the message arrives you can use a regular queue manager alias. Of course that may well be more work trouble than its worth and it may be easier to ask Company Z to alter their Qremote.






Ian Alderson
MQ Technical Architect

[cid:***@f47f8bad.46a7c49e]

DL 0203 003 3055


________________________________
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET

http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 3:07 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can’t QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________



Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')



I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:***@01CF80D5.3C89FFE0][phone]<tel:+61%20414%20615%20334>[cid:***@01CF80D5.3C89FFE0] ***@syntegrity.com.au <mailto:***@syntegrity.com.au>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:***@01CF80D5.3C89FFE0]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <***@AON.COM<mailto:***@AON.COM>> wrote:

Hi Peter,

I don’t know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE(‘FOR.COMPANYZ’) on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


**************************************************************
The information contained in this email (including any attachments transmitted within it) is confidential and is intended solely for the use of the named person.
The unauthorised access, copying or re-use of the information in it by any other person is strictly forbidden.
If you are not the intended recipient please notify us immediately by return email to ***@ignisasset.com.

Internet communication is not guaranteed to be timely, secure, error or virus free. We accept no liability for any harm to systems or data, nor for personal emails. Emails may be recalled, deleted and monitored.

Ignis Asset Management is the trading name of the Ignis Asset Management Limited group of companies which includes the following subsidiaries:
Ignis Asset Management Limited (Registered in Scotland No. SC200801), Ignis Investment Services Limited* (Registered in Scotland No. SC101825)
Ignis Fund Managers Limited* (Registered in Scotland No. SC85610) Scottish Mutual Investment Managers Limited* (Registered in Scotland No. SC88674)
Registered Office: 50 Bothwell Street, Glasgow, G2 6HR, Tel: [phone] and Scottish Mutual PEP & ISA Managers Limited* (Registered in England No. 971504)
Registered Office: 1 Wythall Green Way, Wythall, Birmingham B47 6WG and Ignis Investment Management Limited (Registered in England No. 5809046)
Registered Office: 150 Cheapside, London, EC2V 6ET Tel: [phone]. Scottish Mutual is a registered trade mark of Scottish Mutual Assurance Limited

*Authorised and regulated by the Financial Conduct Authority.

**************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Ian Alderson]

Thanks for sharing Peter. That looks a good solution!




Ian Alderson
MQ Technical Architect

[cid:***@5db90d43.4e8aa48b]

DL 0203 003 3055


________________________________
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET

http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 4:34 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: How do you get a QM to QM Alias itself

I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.


On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')

On EDGEQM I do not delete the Remote Queue Def, I alter it to look like this:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')

I do not create an Alias queue of any kind on EDGEQM.


On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'

But then I add this to QMB and QMC:
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER (‘My ClusterName’)


And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.

It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what’s wrong with it.



Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 11:18 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

“define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.”
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I’ll skip the step of definining another Q Alias on QMB and QMC – not sure what it buys.


“define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM”
I tried the following, since that is the clustered name
“define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM”

But it throws a MQRC 2087 when you try and put to it – Unknown Remote QM. It won’t take a blank RQMNAME.



Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 10:12 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Ok.

define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.

define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM

note the difference between FOR and FROM.

Don't currently have a cluster I can play with, but this should do the trick.

Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________



Jeff,
Company Z’s Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.

If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.

I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can’t QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.




Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?


Thank you,

Jeff Lowrey




From: "Potkay, Peter M (CTO Architecture + Engineering)" <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>
________________________________




Tim,
I did the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')


And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected – we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for ‘BOBLOBLAW’, so the just sit there. I don’t think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won’t resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won’t work either.

I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')

DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ‘) +
XMITQ(' ')



I don’t think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.


Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.

But I think I’m stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn’t allow load balancing to occur. <:-/


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Neil,

BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.

From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: How do you get a QM to QM Alias itself

Hi Tim,

this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.

Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn’t do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).

Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.

Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.

In other words:

QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC

The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME(‘THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME(’NOQMGR') +
XMITQ(‘QMGWAY’)

On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE(’NOQMGR') +
RQMNAME(‘ ‘) +
RNAME(‘ ‘) +
XMITQ(‘ ‘)

And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.


Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:***@01CF80DD.7D6CE510][phone]<tel:+61%20414%20615%20334>[cid:***@01CF80DD.7D6CE510] ***@syntegrity.com.au <mailto:***@syntegrity.com.au>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:***@01CF80DD.7D6CE510]

On 5 Jun 2014, at 1:27 pm, Tim Zielke <***@AON.COM<mailto:***@AON.COM>> wrote:

Hi Peter,

I don’t know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:

Change the QREMOTE(‘FOR.COMPANYZ’) on QMEDGE to the following:

DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')

Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: How do you get a QM to QM Alias itself

QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF


QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA


There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')

And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')


The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.


Here's the topology change and my question.

QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.

The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:

DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')

I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.


Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.


I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.

A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')

But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.



Peter Potkay


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>




________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________


List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html