Secure messaging red book (sg248069) questions

[Costa, D. (Damian)]

HI all,
I read with great interest the red book (sg248069), on secure messaging scenarios. Mainly because I need to setup a secure MQ environment for MQ.
So I have these questions for those who wrote the red book:
1: Did the MQIPT server use vanilla MQ protocol out the firewalls to the 3rd party? Or was it wrapped in a HTTP request envelope? I glossed over the MQ IPT pdf and sort of grasped that it could wrap the MQ protocol in a HTTP envelope. Our paranoid security team are very note keen to open the QM port 1414 on their firewalls. Which is where the http wrapper become very interesting for our requirements.... This would clearly require the 3rd party client to also have an MQ PIT proxy server running to parse the http wrapper and extract the MQ protocol data.
2: Is it (really) safe to connect the DMZ qmgr directly , using sender receiver channel pairs, to qmgrs on the trusted network? Would it be better to disconnect that gateway qmgr from the trusted network qmgrs via a data power device connecting via a MQ client to the DMZ and trusted qmgrs. That should isolate the MQ connectivity into the trusted network.
Definitely more 'spensive.....
Or does the MQIPT proxy perform more protection services than I realise?
3: Do the channel security exits need to be compiled at all? or do they come in a binary (compiled ) format ready for deployment?
4; what was the reasoning behind using different listener ports for the inbound and outbound connections on the DMZ qmgr?
Was it a form of DOS mitigation or just a way of decoupling the internal MQ connections with the external (3rd party) ?

Any guidance would be most appreciated.

Thanks.


********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[T.Rob]

Hi Damian,

> 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to the
3rd
> party?

I'm sure Neil will jump in on this if I'm wrong, but I believe the answer is
that we used 1414. The reasoning was that we can't require the 3rd party to
also run MQIPT. Nice if they do but for purposes of the book we wanted the
broadest application.

> 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
receiver
> channel pairs, to qmgrs on the trusted network? Would it be better to
> disconnect that gateway qmgr from the trusted network qmgrs via a data
> power device connecting via a MQ client to the DMZ and trusted qmgrs.

Define "safe". An MCA channel agent will only ever do OPEN, INQ, and PUT
and it's IBM code running on your server. A client can do any WMQ API and
may be code running on someone else's server. If you were to accept a
client connection on the DMZ it would be necessary to fully authenticate it
and to use CHLAUTH rules to ensure that only the authorized entity could
start that channel. If any of that is mis-configured, it is possible that
the system degrades to a point where external parties can start a client
channel and that opens you up to resource enumeration. For purposes of
security, a good rule of thumb is that the fewer client channels the better.

On the other hand, a DataPower box has the ability to inspect the payload of
the messages. That may be a huge advantage if for example they contain XML
and you wish to filter out malicious payloads. Or perhaps you wish to use
the DP box as a policy enforcement point and authorize messages based on the
MQMD.UserID or a token they carry. The difference is that DataPower does
things that WMQ cannot do. They address fundamentally *different* threats.
It's not that one is safer than the other but rather a question of the right
controls for the right threats.

If the intent is to not allow externally initiated connections, you can run
SDR/RQSTR pairs and initiate the connection to the DMZ from the internal
QMgr.

Again, the design philosophy was to use only WMQ components available "out
of the box" wherever possible so as to achieve the greatest applicability of
the scenarios.

> 3: Do the channel security exits need to be compiled at all? or do they
come
> in a binary (compiled ) format ready for deployment?

The ITSO Message Exit is supplied as source code.

> 4; what was the reasoning behind using different listener ports for the
> inbound and outbound connections on the DMZ qmgr?

Actually, it's even more granular than that. In the event of multiple 3rd
parties, each gets their own listener as a way of isolating their access
path to the QMgr. So each 3rd party has their own listener, channel,
QRemotes or QAliases, etc. This was a compromise that provides limited
isolation and stops short of giving each 3rd party their own QMgr or virtual
server. Also, the way that MQIPT works, it helps to isolate routes.

Of the listeners, we further classify them into "internal-facing" and
"external-facing" and use CHLAUTH rules to ensure that they can only be
accessed by the intended parties. If possible, we use a multi-homed server
so that we can bind the listeners to specific sub-nets. Furthermore, I
routinely provision a dedicated administrative listener separate from any
other traffic.

This is standard securiy stuff and we did it for the same reasons that a
DataPower box has 3 interfaces. One is for admin, one for internal-facing
connections and one for external-facing connections. The result is that it
becomes possible to rely on the context of the connection for some of the
authorization bits. You would not, for instance, expect to see
administrative tasks performed on anything other than the administrative
connection. It is my hope that someday WMQ would actually be able to
enforce that deep in the code like DataPower does, rather than requiring the
admin to configur it from scratch.

-- T.Rob

> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of Costa, D. (Damian)
> Sent: Thursday, October 31, 2013 11:10 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Secure messaging red book (sg248069) questions
>
> HI all,
> I read with great interest the red book (sg248069), on secure messaging
> scenarios. Mainly because I need to setup a secure MQ environment for
> MQ.
> So I have these questions for those who wrote the red book:
> 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to the
3rd
> party? Or was it wrapped in a HTTP request envelope? I glossed over the
> MQ IPT pdf and sort of grasped that it could wrap the MQ protocol in a
> HTTP envelope. Our paranoid security team are very note keen to open the
> QM port 1414 on their firewalls. Which is where the http wrapper become
> very interesting for our requirements.... This would clearly require the
3rd
> party client to also have an MQ PIT proxy server running to parse the http
> wrapper and extract the MQ protocol data.
> 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
receiver
> channel pairs, to qmgrs on the trusted network? Would it be better to
> disconnect that gateway qmgr from the trusted network qmgrs via a data
> power device connecting via a MQ client to the DMZ and trusted qmgrs.
> That should isolate the MQ connectivity into the trusted network.
> Definitely more 'spensive.....
> Or does the MQIPT proxy perform more protection services than I realise?
> 3: Do the channel security exits need to be compiled at all? or do they
come
> in a binary (compiled ) format ready for deployment?
> 4; what was the reasoning behind using different listener ports for the
> inbound and outbound connections on the DMZ qmgr?
> Was it a form of DOS mitigation or just a way of decoupling the internal
> MQ connections with the external (3rd party) ?
>
> Any guidance would be most appreciated.
>
> Thanks.
>
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> 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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[RW]

There's supposed to be an "Impact Analysis" feature available in the
Message Broker version 8 Toolkit, but I can't find it.
Supposedly, all I have to do is right-click any artifact in the
navigation window and choose "Impact Analysis" in the drop-down menu,
but no such choice appears.
(I have gone into the Preferences and checked the "Enable indexing of
Message Broker artifacts" check-box.)

Is there something else I'm missing?

Thanks,
RW

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Neil Casey]

Hi,

I really don’t plan to contradict anything that T.Rob has said, but I will try to add some comments that might help to explain our thinking and intentions in the scenario we built and described.

1. We did not use http proxy, but preferred MQ channel protocol. There are a couple of reasons for this.

My opinion of using http is that it actually provides an undesirable capability. An administrator could configure a B2B connection through the proxy server without it being reviewed and authorised by the security control team. This has the effect of implementing a B2B connection by stealth.

This is because using http via MQIPT exploits firewall rules for std web ports that are likely to be allowed through the corporate firewall anyway. By using native MQ protocol on a specified (and most likely non-default) port, the MQ administrator is going to have to properly request the firewall rule, which is the right behaviour anyway in most organisations.

Also, using http proxies introduces bandwidth, latency and reliability issues compared with using MQ protocol directly.

2. You have identified a concern which we had, but were not able to address. In section 10.2.1 we describe a desirable configuration where a B2B application would run against the gateway queue manager. This would act to provide validation, information hiding, routing and potentially transformation services. Unfortunately, neither an IBM nor 3rd Party B2B application was within the scope of the residency. So we mentioned that such an application would be good, but we did not attempt to implement it.

We did implement an exit to provide a very limited amount of the capability that would normally be provided by the B2B application running against the gateway queue manager.

T.Rob addresses the possibility of using a DataPower appliance to provide this B2B application functionality as you suggested. Personally, I wouldn’t want to connect to separate front and rear side to different queue managers, because it adversely impacts message reliability (QOS). DataPower cannot implement distributed unit of work between 2 queue managers. Instead, I would connect both the front and rear side handler in the DataPower to the same queue manager. With unit of work management, DP could then maintain persistent message reliability.

So there is a trade off between (maybe) better security provided by complete separation using DP and connections to separate queue managers vs better message reliability by including the GET and PUT operations into the same unit of work on the DP. I would tend to fall to the reliability side of the question.

3. As T.Rob said… it is source code only. This is a necessary thing. A residency does not have ongoing resources which could provide support to a binary implementation. It also doesn’t have the resources or capability to compile for all (or even more than one or two of) the available WebSphere MQ platforms. Finally, the exit is provided without warrantee of any kind. From a security perspective, the code should be reviewed and customised before use to ensure that it meets the needs of the organisation, and that it does not present new security exposures.

4. Really can’t add to T.Rob’s explanation. :-)


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



On 1 Nov 2013, at 3:15 am, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org> wrote:

> Hi Damian,
>
>> 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to the
> 3rd
>> party?
>
> I'm sure Neil will jump in on this if I'm wrong, but I believe the answer is
> that we used 1414. The reasoning was that we can't require the 3rd party to
> also run MQIPT. Nice if they do but for purposes of the book we wanted the
> broadest application.
>
>> 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
> receiver
>> channel pairs, to qmgrs on the trusted network? Would it be better to
>> disconnect that gateway qmgr from the trusted network qmgrs via a data
>> power device connecting via a MQ client to the DMZ and trusted qmgrs.
>
> Define "safe". An MCA channel agent will only ever do OPEN, INQ, and PUT
> and it's IBM code running on your server. A client can do any WMQ API and
> may be code running on someone else's server. If you were to accept a
> client connection on the DMZ it would be necessary to fully authenticate it
> and to use CHLAUTH rules to ensure that only the authorized entity could
> start that channel. If any of that is mis-configured, it is possible that
> the system degrades to a point where external parties can start a client
> channel and that opens you up to resource enumeration. For purposes of
> security, a good rule of thumb is that the fewer client channels the better.
>
> On the other hand, a DataPower box has the ability to inspect the payload of
> the messages. That may be a huge advantage if for example they contain XML
> and you wish to filter out malicious payloads. Or perhaps you wish to use
> the DP box as a policy enforcement point and authorize messages based on the
> MQMD.UserID or a token they carry. The difference is that DataPower does
> things that WMQ cannot do. They address fundamentally *different* threats.
> It's not that one is safer than the other but rather a question of the right
> controls for the right threats.
>
> If the intent is to not allow externally initiated connections, you can run
> SDR/RQSTR pairs and initiate the connection to the DMZ from the internal
> QMgr.
>
> Again, the design philosophy was to use only WMQ components available "out
> of the box" wherever possible so as to achieve the greatest applicability of
> the scenarios.
>
>> 3: Do the channel security exits need to be compiled at all? or do they
> come
>> in a binary (compiled ) format ready for deployment?
>
> The ITSO Message Exit is supplied as source code.
>
>> 4; what was the reasoning behind using different listener ports for the
>> inbound and outbound connections on the DMZ qmgr?
>
> Actually, it's even more granular than that. In the event of multiple 3rd
> parties, each gets their own listener as a way of isolating their access
> path to the QMgr. So each 3rd party has their own listener, channel,
> QRemotes or QAliases, etc. This was a compromise that provides limited
> isolation and stops short of giving each 3rd party their own QMgr or virtual
> server. Also, the way that MQIPT works, it helps to isolate routes.
>
> Of the listeners, we further classify them into "internal-facing" and
> "external-facing" and use CHLAUTH rules to ensure that they can only be
> accessed by the intended parties. If possible, we use a multi-homed server
> so that we can bind the listeners to specific sub-nets. Furthermore, I
> routinely provision a dedicated administrative listener separate from any
> other traffic.
>
> This is standard securiy stuff and we did it for the same reasons that a
> DataPower box has 3 interfaces. One is for admin, one for internal-facing
> connections and one for external-facing connections. The result is that it
> becomes possible to rely on the context of the connection for some of the
> authorization bits. You would not, for instance, expect to see
> administrative tasks performed on anything other than the administrative
> connection. It is my hope that someday WMQ would actually be able to
> enforce that deep in the code like DataPower does, rather than requiring the
> admin to configur it from scratch.
>
> -- T.Rob
>
>> -----Original Message-----
>> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
>> Behalf Of Costa, D. (Damian)
>> Sent: Thursday, October 31, 2013 11:10 AM
>> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
>> Subject: Secure messaging red book (sg248069) questions
>>
>> HI all,
>> I read with great interest the red book (sg248069), on secure messaging
>> scenarios. Mainly because I need to setup a secure MQ environment for
>> MQ.
>> So I have these questions for those who wrote the red book:
>> 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to the
> 3rd
>> party? Or was it wrapped in a HTTP request envelope? I glossed over the
>> MQ IPT pdf and sort of grasped that it could wrap the MQ protocol in a
>> HTTP envelope. Our paranoid security team are very note keen to open the
>> QM port 1414 on their firewalls. Which is where the http wrapper become
>> very interesting for our requirements.... This would clearly require the
> 3rd
>> party client to also have an MQ PIT proxy server running to parse the http
>> wrapper and extract the MQ protocol data.
>> 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
> receiver
>> channel pairs, to qmgrs on the trusted network? Would it be better to
>> disconnect that gateway qmgr from the trusted network qmgrs via a data
>> power device connecting via a MQ client to the DMZ and trusted qmgrs.
>> That should isolate the MQ connectivity into the trusted network.
>> Definitely more 'spensive.....
>> Or does the MQIPT proxy perform more protection services than I realise?
>> 3: Do the channel security exits need to be compiled at all? or do they
> come
>> in a binary (compiled ) format ready for deployment?
>> 4; what was the reasoning behind using different listener ports for the
>> inbound and outbound connections on the DMZ qmgr?
>> Was it a form of DOS mitigation or just a way of decoupling the internal
>> MQ connections with the external (3rd party) ?
>>
>> Any guidance would be most appreciated.
>>
>> Thanks.
>>
>>
>> ********************
>> Nedbank Limited Reg No 1951/000009/06. The following link displays the
>> names of the Nedbank Board of Directors and Company Secretary.
>> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
>> confidential and is intended for the addressee only.
>> The following link will take you to Nedbank's legal notice.
>> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
>> ********************
>>
>> 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
>
> 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


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)]

T.rob,
How was this accomplished?

>>>>>" Of the listeners, we further classify them into "internal-facing" and "external-facing" and use CHLAUTH rules to ensure that they can only be accessed by the intended parties "

I didn't see it explained in the Redbook and I don't think there is a CHLAUTH rule that sends connections to specific port# based on something the CHLAUTH rule can see on the incoming connection. We use classic Firewall rules to insure a business partner company can only hit the port # where the listener we have dedicated for them is listening.



Or when you say "... use CHLAUTH rules to ensure that they can only be accessed..." the 'they' you were referring to was the channels and not the listeners?




Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Thursday, October 31, 2013 12:15 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Secure messaging red book (sg248069) questions

Hi Damian,

> 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> the
3rd
> party?

I'm sure Neil will jump in on this if I'm wrong, but I believe the answer is that we used 1414. The reasoning was that we can't require the 3rd party to also run MQIPT. Nice if they do but for purposes of the book we wanted the broadest application.

> 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
receiver
> channel pairs, to qmgrs on the trusted network? Would it be better to
> disconnect that gateway qmgr from the trusted network qmgrs via a data
> power device connecting via a MQ client to the DMZ and trusted qmgrs.

Define "safe". An MCA channel agent will only ever do OPEN, INQ, and PUT and it's IBM code running on your server. A client can do any WMQ API and may be code running on someone else's server. If you were to accept a client connection on the DMZ it would be necessary to fully authenticate it and to use CHLAUTH rules to ensure that only the authorized entity could start that channel. If any of that is mis-configured, it is possible that the system degrades to a point where external parties can start a client channel and that opens you up to resource enumeration. For purposes of security, a good rule of thumb is that the fewer client channels the better.

On the other hand, a DataPower box has the ability to inspect the payload of the messages. That may be a huge advantage if for example they contain XML and you wish to filter out malicious payloads. Or perhaps you wish to use the DP box as a policy enforcement point and authorize messages based on the
MQMD.UserID or a token they carry. The difference is that DataPower does
things that WMQ cannot do. They address fundamentally *different* threats.
It's not that one is safer than the other but rather a question of the right controls for the right threats.

If the intent is to not allow externally initiated connections, you can run SDR/RQSTR pairs and initiate the connection to the DMZ from the internal QMgr.

Again, the design philosophy was to use only WMQ components available "out of the box" wherever possible so as to achieve the greatest applicability of the scenarios.

> 3: Do the channel security exits need to be compiled at all? or do
> they
come
> in a binary (compiled ) format ready for deployment?

The ITSO Message Exit is supplied as source code.

> 4; what was the reasoning behind using different listener ports for
> the inbound and outbound connections on the DMZ qmgr?

Actually, it's even more granular than that. In the event of multiple 3rd parties, each gets their own listener as a way of isolating their access path to the QMgr. So each 3rd party has their own listener, channel, QRemotes or QAliases, etc. This was a compromise that provides limited isolation and stops short of giving each 3rd party their own QMgr or virtual server. Also, the way that MQIPT works, it helps to isolate routes.

Of the listeners, we further classify them into "internal-facing" and "external-facing" and use CHLAUTH rules to ensure that they can only be accessed by the intended parties. If possible, we use a multi-homed server so that we can bind the listeners to specific sub-nets. Furthermore, I routinely provision a dedicated administrative listener separate from any other traffic.

This is standard securiy stuff and we did it for the same reasons that a DataPower box has 3 interfaces. One is for admin, one for internal-facing connections and one for external-facing connections. The result is that it becomes possible to rely on the context of the connection for some of the authorization bits. You would not, for instance, expect to see administrative tasks performed on anything other than the administrative connection. It is my hope that someday WMQ would actually be able to enforce that deep in the code like DataPower does, rather than requiring the admin to configur it from scratch.

-- T.Rob

> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of Costa, D. (Damian)
> Sent: Thursday, October 31, 2013 11:10 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Secure messaging red book (sg248069) questions
>
> HI all,
> I read with great interest the red book (sg248069), on secure
> messaging scenarios. Mainly because I need to setup a secure MQ
> environment for MQ.
> So I have these questions for those who wrote the red book:
> 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> the
3rd
> party? Or was it wrapped in a HTTP request envelope? I glossed over
> the MQ IPT pdf and sort of grasped that it could wrap the MQ protocol
> in a HTTP envelope. Our paranoid security team are very note keen to
> open the QM port 1414 on their firewalls. Which is where the http
> wrapper become very interesting for our requirements.... This would
> clearly require the
3rd
> party client to also have an MQ PIT proxy server running to parse the
> http wrapper and extract the MQ protocol data.
> 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
receiver
> channel pairs, to qmgrs on the trusted network? Would it be better to
> disconnect that gateway qmgr from the trusted network qmgrs via a data
> power device connecting via a MQ client to the DMZ and trusted qmgrs.
> That should isolate the MQ connectivity into the trusted network.
> Definitely more 'spensive.....
> Or does the MQIPT proxy perform more protection services than I realise?
> 3: Do the channel security exits need to be compiled at all? or do
> they
come
> in a binary (compiled ) format ready for deployment?
> 4; what was the reasoning behind using different listener ports for
> the inbound and outbound connections on the DMZ qmgr?
> Was it a form of DOS mitigation or just a way of decoupling the
> internal MQ connections with the external (3rd party) ?
>
> Any guidance would be most appreciated.
>
> Thanks.
>
>
> ********************
> Nedbank Limited Reg No 1951/000009/06. The following link displays the
> names of the Nedbank Board of Directors and Company Secretary.
> [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> confidential and is intended for the addressee only.
> The following link will take you to Nedbank's legal notice.
> [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> ********************
>
> 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

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
************************************************************
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

[T.Rob]

To clarify, I don't recall whether we did this in the book but what *I*
shoot for is that the internal and external facing NICs are on distinct
subnets. Then it's possible to use listener blocking CHLAUTH rules to
filter.

-- T.Rob

> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> Sent: Thursday, October 31, 2013 18:29 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> T.rob,
> How was this accomplished?
>
> >>>>>" Of the listeners, we further classify them into "internal-facing"
and
> "external-facing" and use CHLAUTH rules to ensure that they can only be
> accessed by the intended parties "
>
> I didn't see it explained in the Redbook and I don't think there is a
CHLAUTH
> rule that sends connections to specific port# based on something the
> CHLAUTH rule can see on the incoming connection. We use classic Firewall
> rules to insure a business partner company can only hit the port # where
> the listener we have dedicated for them is listening.
>
>
>
> Or when you say "... use CHLAUTH rules to ensure that they can only be
> accessed..." the 'they' you were referring to was the channels and not the
> listeners?
>
>
>
>
> Peter Potkay
>
> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of T.Rob
> Sent: Thursday, October 31, 2013 12:15 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> Hi Damian,
>
> > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> > the
> 3rd
> > party?
>
> I'm sure Neil will jump in on this if I'm wrong, but I believe the answer
is
> that we used 1414. The reasoning was that we can't require the 3rd party
> to also run MQIPT. Nice if they do but for purposes of the book we wanted
> the broadest application.
>
> > 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
> receiver
> > channel pairs, to qmgrs on the trusted network? Would it be better to
> > disconnect that gateway qmgr from the trusted network qmgrs via a data
> > power device connecting via a MQ client to the DMZ and trusted qmgrs.
>
> Define "safe". An MCA channel agent will only ever do OPEN, INQ, and PUT
> and it's IBM code running on your server. A client can do any WMQ API and
> may be code running on someone else's server. If you were to accept a
> client connection on the DMZ it would be necessary to fully authenticate
it
> and to use CHLAUTH rules to ensure that only the authorized entity could
> start that channel. If any of that is mis-configured, it is possible that
the
> system degrades to a point where external parties can start a client
channel
> and that opens you up to resource enumeration. For purposes of security,
> a good rule of thumb is that the fewer client channels the better.
>
> On the other hand, a DataPower box has the ability to inspect the payload
> of the messages. That may be a huge advantage if for example they contain
> XML and you wish to filter out malicious payloads. Or perhaps you wish to
> use the DP box as a policy enforcement point and authorize messages based
> on the
> MQMD.UserID or a token they carry. The difference is that DataPower does
> things that WMQ cannot do. They address fundamentally *different*
> threats.
> It's not that one is safer than the other but rather a question of the
right
> controls for the right threats.
>
> If the intent is to not allow externally initiated connections, you can
run
> SDR/RQSTR pairs and initiate the connection to the DMZ from the internal
> QMgr.
>
> Again, the design philosophy was to use only WMQ components available
> "out of the box" wherever possible so as to achieve the greatest
> applicability of the scenarios.
>
> > 3: Do the channel security exits need to be compiled at all? or do
> > they
> come
> > in a binary (compiled ) format ready for deployment?
>
> The ITSO Message Exit is supplied as source code.
>
> > 4; what was the reasoning behind using different listener ports for
> > the inbound and outbound connections on the DMZ qmgr?
>
> Actually, it's even more granular than that. In the event of multiple 3rd
> parties, each gets their own listener as a way of isolating their access
path
> to the QMgr. So each 3rd party has their own listener, channel, QRemotes
> or QAliases, etc. This was a compromise that provides limited isolation
and
> stops short of giving each 3rd party their own QMgr or virtual server.
Also,
> the way that MQIPT works, it helps to isolate routes.
>
> Of the listeners, we further classify them into "internal-facing" and
> "external-facing" and use CHLAUTH rules to ensure that they can only be
> accessed by the intended parties. If possible, we use a multi-homed
server
> so that we can bind the listeners to specific sub-nets. Furthermore, I
> routinely provision a dedicated administrative listener separate from any
> other traffic.
>
> This is standard securiy stuff and we did it for the same reasons that a
> DataPower box has 3 interfaces. One is for admin, one for internal-facing
> connections and one for external-facing connections. The result is that
it
> becomes possible to rely on the context of the connection for some of the
> authorization bits. You would not, for instance, expect to see
> administrative tasks performed on anything other than the administrative
> connection. It is my hope that someday WMQ would actually be able to
> enforce that deep in the code like DataPower does, rather than requiring
> the admin to configur it from scratch.
>
> -- T.Rob
>
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> On
> > Behalf Of Costa, D. (Damian)
> > Sent: Thursday, October 31, 2013 11:10 AM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Secure messaging red book (sg248069) questions
> >
> > HI all,
> > I read with great interest the red book (sg248069), on secure
> > messaging scenarios. Mainly because I need to setup a secure MQ
> > environment for MQ.
> > So I have these questions for those who wrote the red book:
> > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> > the
> 3rd
> > party? Or was it wrapped in a HTTP request envelope? I glossed over
> > the MQ IPT pdf and sort of grasped that it could wrap the MQ protocol
> > in a HTTP envelope. Our paranoid security team are very note keen to
> > open the QM port 1414 on their firewalls. Which is where the http
> > wrapper become very interesting for our requirements.... This would
> > clearly require the
> 3rd
> > party client to also have an MQ PIT proxy server running to parse the
> > http wrapper and extract the MQ protocol data.
> > 2: Is it (really) safe to connect the DMZ qmgr directly , using sender
> receiver
> > channel pairs, to qmgrs on the trusted network? Would it be better to
> > disconnect that gateway qmgr from the trusted network qmgrs via a data
> > power device connecting via a MQ client to the DMZ and trusted qmgrs.
> > That should isolate the MQ connectivity into the trusted network.
> > Definitely more 'spensive.....
> > Or does the MQIPT proxy perform more protection services than I realise?
> > 3: Do the channel security exits need to be compiled at all? or do
> > they
> come
> > in a binary (compiled ) format ready for deployment?
> > 4; what was the reasoning behind using different listener ports for
> > the inbound and outbound connections on the DMZ qmgr?
> > Was it a form of DOS mitigation or just a way of decoupling the
> > internal MQ connections with the external (3rd party) ?
> >
> > Any guidance would be most appreciated.
> >
> > Thanks.
> >
> >
> > ********************
> > Nedbank Limited Reg No 1951/000009/06. The following link displays the
> > names of the Nedbank Board of Directors and Company Secretary.
> > [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
> > confidential and is intended for the addressee only.
> > The following link will take you to Nedbank's legal notice.
> > [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> > ********************
> >
> > 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
>
> 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
> **********************************************************
> **
> 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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

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

I'm not aware of a way to have CHLAUTH block a Listener, or prevent a particular remote connection from using a specific local listener port while allowing it to connect to another local listener port.

CHLAUTH is either going to allow the connection or not based on the remote source IP address, irrespective of what local listener port its attempting to come in on.

I think classic firewalls are still the only way to keep a remote system from hitting port 1414 (for example) on your server, but allow them to hit port 1415 (for example).




Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Friday, November 01, 2013 11:06 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Secure messaging red book (sg248069) questions

To clarify, I don't recall whether we did this in the book but what *I* shoot for is that the internal and external facing NICs are on distinct subnets. Then it's possible to use listener blocking CHLAUTH rules to filter.

-- T.Rob

> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> Sent: Thursday, October 31, 2013 18:29 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> T.rob,
> How was this accomplished?
>
> >>>>>" Of the listeners, we further classify them into "internal-facing"
and
> "external-facing" and use CHLAUTH rules to ensure that they can only
> be accessed by the intended parties "
>
> I didn't see it explained in the Redbook and I don't think there is a
CHLAUTH
> rule that sends connections to specific port# based on something the
> CHLAUTH rule can see on the incoming connection. We use classic
> Firewall rules to insure a business partner company can only hit the
> port # where the listener we have dedicated for them is listening.
>
>
>
> Or when you say "... use CHLAUTH rules to ensure that they can only be
> accessed..." the 'they' you were referring to was the channels and not
> the listeners?
>
>
>
>
> Peter Potkay
>
> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of T.Rob
> Sent: Thursday, October 31, 2013 12:15 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> Hi Damian,
>
> > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> > the
> 3rd
> > party?
>
> I'm sure Neil will jump in on this if I'm wrong, but I believe the
> answer
is
> that we used 1414. The reasoning was that we can't require the 3rd
> party to also run MQIPT. Nice if they do but for purposes of the book
> we wanted the broadest application.
>
> > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > sender
> receiver
> > channel pairs, to qmgrs on the trusted network? Would it be better
> > to disconnect that gateway qmgr from the trusted network qmgrs via a
> > data power device connecting via a MQ client to the DMZ and trusted qmgrs.
>
> Define "safe". An MCA channel agent will only ever do OPEN, INQ, and
> PUT and it's IBM code running on your server. A client can do any WMQ
> API and may be code running on someone else's server. If you were to
> accept a client connection on the DMZ it would be necessary to fully
> authenticate
it
> and to use CHLAUTH rules to ensure that only the authorized entity
> could start that channel. If any of that is mis-configured, it is
> possible that
the
> system degrades to a point where external parties can start a client
channel
> and that opens you up to resource enumeration. For purposes of
> security, a good rule of thumb is that the fewer client channels the better.
>
> On the other hand, a DataPower box has the ability to inspect the
> payload of the messages. That may be a huge advantage if for example
> they contain XML and you wish to filter out malicious payloads. Or
> perhaps you wish to use the DP box as a policy enforcement point and
> authorize messages based on the
> MQMD.UserID or a token they carry. The difference is that DataPower does
> things that WMQ cannot do. They address fundamentally *different*
> threats.
> It's not that one is safer than the other but rather a question of the
right
> controls for the right threats.
>
> If the intent is to not allow externally initiated connections, you
> can
run
> SDR/RQSTR pairs and initiate the connection to the DMZ from the
> internal QMgr.
>
> Again, the design philosophy was to use only WMQ components available
> "out of the box" wherever possible so as to achieve the greatest
> applicability of the scenarios.
>
> > 3: Do the channel security exits need to be compiled at all? or do
> > they
> come
> > in a binary (compiled ) format ready for deployment?
>
> The ITSO Message Exit is supplied as source code.
>
> > 4; what was the reasoning behind using different listener ports for
> > the inbound and outbound connections on the DMZ qmgr?
>
> Actually, it's even more granular than that. In the event of multiple
> 3rd parties, each gets their own listener as a way of isolating their
> access
path
> to the QMgr. So each 3rd party has their own listener, channel,
> QRemotes or QAliases, etc. This was a compromise that provides
> limited isolation
and
> stops short of giving each 3rd party their own QMgr or virtual server.
Also,
> the way that MQIPT works, it helps to isolate routes.
>
> Of the listeners, we further classify them into "internal-facing" and
> "external-facing" and use CHLAUTH rules to ensure that they can only
> be accessed by the intended parties. If possible, we use a
> multi-homed
server
> so that we can bind the listeners to specific sub-nets. Furthermore,
> I routinely provision a dedicated administrative listener separate
> from any other traffic.
>
> This is standard securiy stuff and we did it for the same reasons that
> a DataPower box has 3 interfaces. One is for admin, one for
> internal-facing connections and one for external-facing connections.
> The result is that
it
> becomes possible to rely on the context of the connection for some of
> the authorization bits. You would not, for instance, expect to see
> administrative tasks performed on anything other than the
> administrative connection. It is my hope that someday WMQ would
> actually be able to enforce that deep in the code like DataPower does,
> rather than requiring the admin to configur it from scratch.
>
> -- T.Rob
>
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> On
> > Behalf Of Costa, D. (Damian)
> > Sent: Thursday, October 31, 2013 11:10 AM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Secure messaging red book (sg248069) questions
> >
> > HI all,
> > I read with great interest the red book (sg248069), on secure
> > messaging scenarios. Mainly because I need to setup a secure MQ
> > environment for MQ.
> > So I have these questions for those who wrote the red book:
> > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> > the
> 3rd
> > party? Or was it wrapped in a HTTP request envelope? I glossed over
> > the MQ IPT pdf and sort of grasped that it could wrap the MQ
> > protocol in a HTTP envelope. Our paranoid security team are very
> > note keen to open the QM port 1414 on their firewalls. Which is
> > where the http wrapper become very interesting for our
> > requirements.... This would clearly require the
> 3rd
> > party client to also have an MQ PIT proxy server running to parse
> > the http wrapper and extract the MQ protocol data.
> > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > sender
> receiver
> > channel pairs, to qmgrs on the trusted network? Would it be better
> > to disconnect that gateway qmgr from the trusted network qmgrs via a
> > data power device connecting via a MQ client to the DMZ and trusted qmgrs.
> > That should isolate the MQ connectivity into the trusted network.
> > Definitely more 'spensive.....
> > Or does the MQIPT proxy perform more protection services than I realise?
> > 3: Do the channel security exits need to be compiled at all? or do
> > they
> come
> > in a binary (compiled ) format ready for deployment?
> > 4; what was the reasoning behind using different listener ports for
> > the inbound and outbound connections on the DMZ qmgr?
> > Was it a form of DOS mitigation or just a way of decoupling the
> > internal MQ connections with the external (3rd party) ?
> >
> > Any guidance would be most appreciated.
> >
> > Thanks.
> >
> >
> > ********************
> > Nedbank Limited Reg No 1951/000009/06. The following link displays
> > the names of the Nedbank Board of Directors and Company Secretary.
> > [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
> > is confidential and is intended for the addressee only.
> > The following link will take you to Nedbank's legal notice.
> > [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> > ********************
> >
> > 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
>
> 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
> **********************************************************
> **
> 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

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
************************************************************
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

[T.Rob]

Hi Peter,

OK, so let's say that my DMZ QMgr has 2 NICs where one is on an external
address 184.154.160.239 and the other is on 192.168.1.2. First define the
listeners and bind them to specific NIC addresses. Then define the channels
and bind them to specific distinguished names. Finally, define some CHLAUTH
rules that bind the channels to those same distinguished names.

The external partner can only see the listener on 3414 and the CHLAUTH rule
ensures that they can start only the one channel that was provisioned for
them. Similar restrictions are placed on the internal channels and the
internal listener. If we had more than one listener for external parties,
we'd have the same issue as we do here for internal parties in that any
external party could "see" both listeners (firewall rules permitting).
However, the CHLAUTH rules matching on DN would cause these connections to
bounce off.

It's going around your ass to get to your elbow but it works. It would be
dramatically simpler (and a lot more secure) if WMQ would allow binding
between channels and ports without requiring distinguished names to close
the loop.

I haven't tested these for syntax but here's a rough approximation...

* DEF Internal, external and admin listeners.
DEF LISTENER(TCP.1414) TRPTYPE(TCP) +
PORT(1414) +
IPADDR(192.168.1.2) +
DESCR('Listener for internal traffic') +
REPLACE
DEF LISTENER(TCP.2414) TRPTYPE(TCP) +
PORT(2414) +
IPADDR(192.168.1.2) +
DESCR('Listener for Admin traffic') +
REPLACE
DEF LISTENER(TCP.3414) TRPTYPE(TCP) +
PORT(3414) +
IPADDR(184.154.160.239) +
DESCR('Listener for external traffic') +
REPLACE

* DEF some channels
DEF CHANNEL('ADMIN.TLS.SVRCONN') CHLTYPE(SVRCONN) +
TRPTYPE(TCP) +
MCAUSER('bad!admin') +
SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
REPLACE
DEF CHANNEL('BIZ.PARTNER.RQSTR') CHLTYPE(RQSTR) +
TRPTYPE(TCP) +
CONNAME('1.2.3.4(5050)') +
LOCLADDR('184.154.160.239') +
MCAUSER('bizprtner') +
SCYDATA('entry') +
SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
SCYEXIT('itsome') +
REPLACE
DEF CHANNEL('INTERNAL.DMZ') CHLTYPE(RCVR) +
TRPTYPE(TCP) +
MCAUSER('internal') +
SCYDATA('entry') +
SCYEXIT('itsome') +
SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
REPLACE

* Set some CHLAUTH rules
SET CHLAUTH('*') TYPE(ADDRESSMAP) +
ADDRESS('184.*') +
USERSRC(NOACCESS) +
ACTION(REPLACE)
SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(ADDRESSMAP) +
ADDRESS('184.*') +
USERSRC(CHANNEL) +
ACTION(REPLACE)
SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(SSLPEERMAP) +
SSLPEER('CN=SOMEQMGR,O=Biz Partner')
USERSRC(CHANNEL) +
ADDRESS('1.2.3.4') +
ACTION(REPLACE)
SET CHLAUTH('INTERNAL.DMZ') TYPE(SSLPEERMAP) +
SSLPEER('CN=OURQMGR,O=IoPT Consulting LLC') +
USERSRC(CHANNEL) +
ADDRESS('192.168.*') +
ACTION(REPLACE)

-- T.Rob

> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> Sent: Friday, November 01, 2013 12:50 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> I'm not aware of a way to have CHLAUTH block a Listener, or prevent a
> particular remote connection from using a specific local listener port
while
> allowing it to connect to another local listener port.
>
> CHLAUTH is either going to allow the connection or not based on the
> remote source IP address, irrespective of what local listener port its
> attempting to come in on.
>
> I think classic firewalls are still the only way to keep a remote system
from
> hitting port 1414 (for example) on your server, but allow them to hit port
> 1415 (for example).
>
>
>
>
> Peter Potkay
>
> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of T.Rob
> Sent: Friday, November 01, 2013 11:06 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> To clarify, I don't recall whether we did this in the book but what *I*
shoot
> for is that the internal and external facing NICs are on distinct subnets.
> Then it's possible to use listener blocking CHLAUTH rules to filter.
>
> -- T.Rob
>
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> On
> > Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> > Sent: Thursday, October 31, 2013 18:29 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > T.Rob,
> > How was this accomplished?
> >
> > >>>>>" Of the listeners, we further classify them into "internal-facing"
> and
> > "external-facing" and use CHLAUTH rules to ensure that they can only
> > be accessed by the intended parties "
> >
> > I didn't see it explained in the Redbook and I don't think there is a
> CHLAUTH
> > rule that sends connections to specific port# based on something the
> > CHLAUTH rule can see on the incoming connection. We use classic
> > Firewall rules to insure a business partner company can only hit the
> > port # where the listener we have dedicated for them is listening.
> >
> >
> >
> > Or when you say "... use CHLAUTH rules to ensure that they can only be
> > accessed..." the 'they' you were referring to was the channels and not
> > the listeners?
> >
> >
> >
> >
> > Peter Potkay
> >
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> On
> > Behalf Of T.Rob
> > Sent: Thursday, October 31, 2013 12:15 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > Hi Damian,
> >
> > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> > > the
> > 3rd
> > > party?
> >
> > I'm sure Neil will jump in on this if I'm wrong, but I believe the
> > answer
> is
> > that we used 1414. The reasoning was that we can't require the 3rd
> > party to also run MQIPT. Nice if they do but for purposes of the book
> > we wanted the broadest application.
> >
> > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > sender
> > receiver
> > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > to disconnect that gateway qmgr from the trusted network qmgrs via a
> > > data power device connecting via a MQ client to the DMZ and trusted
> qmgrs.
> >
> > DEF "safe". An MCA channel agent will only ever do OPEN, INQ, and
> > PUT and it's IBM code running on your server. A client can do any WMQ
> > API and may be code running on someone else's server. If you were to
> > accept a client connection on the DMZ it would be necessary to fully
> > authenticate
> it
> > and to use CHLAUTH rules to ensure that only the authorized entity
> > could start that channel. If any of that is mis-configured, it is
> > possible that
> the
> > system degrades to a point where external parties can start a client
> channel
> > and that opens you up to resource enumeration. For purposes of
> > security, a good rule of thumb is that the fewer client channels the
better.
> >
> > On the other hand, a DataPower box has the ability to inspect the
> > payload of the messages. That may be a huge advantage if for example
> > they contain XML and you wish to filter out malicious payloads. Or
> > perhaps you wish to use the DP box as a policy enforcement point and
> > authorize messages based on the
> > MQMD.UserID or a token they carry. The difference is that DataPower
> does
> > things that WMQ cannot do. They address fundamentally *different*
> > threats.
> > It's not that one is safer than the other but rather a question of the
> right
> > controls for the right threats.
> >
> > If the intent is to not allow externally initiated connections, you
> > can
> run
> > SDR/RQSTR pairs and initiate the connection to the DMZ from the
> > internal QMgr.
> >
> > Again, the design philosophy was to use only WMQ components available
> > "out of the box" wherever possible so as to achieve the greatest
> > applicability of the scenarios.
> >
> > > 3: Do the channel security exits need to be compiled at all? or do
> > > they
> > come
> > > in a binary (compiled ) format ready for deployment?
> >
> > The ITSO Message Exit is supplied as source code.
> >
> > > 4; what was the reasoning behind using different listener ports for
> > > the inbound and outbound connections on the DMZ qmgr?
> >
> > Actually, it's even more granular than that. In the event of multiple
> > 3rd parties, each gets their own listener as a way of isolating their
> > access
> path
> > to the QMgr. So each 3rd party has their own listener, channel,
> > QRemotes or QAliases, etc. This was a compromise that provides
> > limited isolation
> and
> > stops short of giving each 3rd party their own QMgr or virtual server.
> Also,
> > the way that MQIPT works, it helps to isolate routes.
> >
> > Of the listeners, we further classify them into "internal-facing" and
> > "external-facing" and use CHLAUTH rules to ensure that they can only
> > be accessed by the intended parties. If possible, we use a
> > multi-homed
> server
> > so that we can bind the listeners to specific sub-nets. Furthermore,
> > I routinely provision a dedicated administrative listener separate
> > from any other traffic.
> >
> > This is standard securiy stuff and we did it for the same reasons that
> > a DataPower box has 3 interfaces. One is for admin, one for
> > internal-facing connections and one for external-facing connections.
> > The result is that
> it
> > becomes possible to rely on the context of the connection for some of
> > the authorization bits. You would not, for instance, expect to see
> > administrative tasks performed on anything other than the
> > administrative connection. It is my hope that someday WMQ would
> > actually be able to enforce that deep in the code like DataPower does,
> > rather than requiring the admin to configur it from scratch.
> >
> > -- T.Rob
> >
> > > -----Original Message-----
> > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > On
> > > Behalf Of Costa, D. (Damian)
> > > Sent: Thursday, October 31, 2013 11:10 AM
> > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > Subject: Secure messaging red book (sg248069) questions
> > >
> > > HI all,
> > > I read with great interest the red book (sg248069), on secure
> > > messaging scenarios. Mainly because I need to setup a secure MQ
> > > environment for MQ.
> > > So I have these questions for those who wrote the red book:
> > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls to
> > > the
> > 3rd
> > > party? Or was it wrapped in a HTTP request envelope? I glossed over
> > > the MQ IPT pdf and sort of grasped that it could wrap the MQ
> > > protocol in a HTTP envelope. Our paranoid security team are very
> > > note keen to open the QM port 1414 on their firewalls. Which is
> > > where the http wrapper become very interesting for our
> > > requirements.... This would clearly require the
> > 3rd
> > > party client to also have an MQ PIT proxy server running to parse
> > > the http wrapper and extract the MQ protocol data.
> > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > sender
> > receiver
> > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > to disconnect that gateway qmgr from the trusted network qmgrs via a
> > > data power device connecting via a MQ client to the DMZ and trusted
> qmgrs.
> > > That should isolate the MQ connectivity into the trusted network.
> > > Definitely more 'spensive.....
> > > Or does the MQIPT proxy perform more protection services than I
> realise?
> > > 3: Do the channel security exits need to be compiled at all? or do
> > > they
> > come
> > > in a binary (compiled ) format ready for deployment?
> > > 4; what was the reasoning behind using different listener ports for
> > > the inbound and outbound connections on the DMZ qmgr?
> > > Was it a form of DOS mitigation or just a way of decoupling the
> > > internal MQ connections with the external (3rd party) ?
> > >
> > > Any guidance would be most appreciated.
> > >
> > > Thanks.
> > >
> > >
> > > ********************
> > > Nedbank Limited Reg No 1951/000009/06. The following link displays
> > > the names of the Nedbank Board of Directors and Company Secretary.
> > > [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
> > > is confidential and is intended for the addressee only.
> > > The following link will take you to Nedbank's legal notice.
> > > [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> > > ********************
> > >
> > > 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
> >
> > 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
> >
> **********************************************************
> > **
> > 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
>
> 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
> **********************************************************
> **
> 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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

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

Aha, using a RQSTR and using LOCLADDR is the key to get that connection to use a particular IP address, and thus the one and only Listener on that IP. And as you starte, if you have more than to partners coming in over that same external IP nothing in the MQ layer can restrict each to their own port/Listener, but classic firewalls solve that.


Thanks for writing it up.


Peter Potkay


-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Friday, November 01, 2013 2:26 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Secure messaging red book (sg248069) questions

Hi Peter,

OK, so let's say that my DMZ QMgr has 2 NICs where one is on an external address 184.154.160.239 and the other is on 192.168.1.2. First define the listeners and bind them to specific NIC addresses. Then define the channels and bind them to specific distinguished names. Finally, define some CHLAUTH rules that bind the channels to those same distinguished names.

The external partner can only see the listener on 3414 and the CHLAUTH rule ensures that they can start only the one channel that was provisioned for them. Similar restrictions are placed on the internal channels and the internal listener. If we had more than one listener for external parties, we'd have the same issue as we do here for internal parties in that any external party could "see" both listeners (firewall rules permitting).
However, the CHLAUTH rules matching on DN would cause these connections to bounce off.

It's going around your ass to get to your elbow but it works. It would be dramatically simpler (and a lot more secure) if WMQ would allow binding between channels and ports without requiring distinguished names to close the loop.

I haven't tested these for syntax but here's a rough approximation...

* DEF Internal, external and admin listeners.
DEF LISTENER(TCP.1414) TRPTYPE(TCP) +
PORT(1414) +
IPADDR(192.168.1.2) +
DESCR('Listener for internal traffic') +
REPLACE
DEF LISTENER(TCP.2414) TRPTYPE(TCP) +
PORT(2414) +
IPADDR(192.168.1.2) +
DESCR('Listener for Admin traffic') +
REPLACE
DEF LISTENER(TCP.3414) TRPTYPE(TCP) +
PORT(3414) +
IPADDR(184.154.160.239) +
DESCR('Listener for external traffic') +
REPLACE

* DEF some channels
DEF CHANNEL('ADMIN.TLS.SVRCONN') CHLTYPE(SVRCONN) +
TRPTYPE(TCP) +
MCAUSER('bad!admin') +
SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
REPLACE
DEF CHANNEL('BIZ.PARTNER.RQSTR') CHLTYPE(RQSTR) +
TRPTYPE(TCP) +
CONNAME('1.2.3.4(5050)') +
LOCLADDR('184.154.160.239') +
MCAUSER('bizprtner') +
SCYDATA('entry') +
SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
SCYEXIT('itsome') +
REPLACE
DEF CHANNEL('INTERNAL.DMZ') CHLTYPE(RCVR) +
TRPTYPE(TCP) +
MCAUSER('internal') +
SCYDATA('entry') +
SCYEXIT('itsome') +
SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
REPLACE

* Set some CHLAUTH rules
SET CHLAUTH('*') TYPE(ADDRESSMAP) +
ADDRESS('184.*') +
USERSRC(NOACCESS) +
ACTION(REPLACE)
SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(ADDRESSMAP) +
ADDRESS('184.*') +
USERSRC(CHANNEL) +
ACTION(REPLACE)
SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(SSLPEERMAP) +
SSLPEER('CN=SOMEQMGR,O=Biz Partner')
USERSRC(CHANNEL) +
ADDRESS('1.2.3.4') +
ACTION(REPLACE)
SET CHLAUTH('INTERNAL.DMZ') TYPE(SSLPEERMAP) +
SSLPEER('CN=OURQMGR,O=IoPT Consulting LLC') +
USERSRC(CHANNEL) +
ADDRESS('192.168.*') +
ACTION(REPLACE)

-- T.Rob

> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> Sent: Friday, November 01, 2013 12:50 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> I'm not aware of a way to have CHLAUTH block a Listener, or prevent a
> particular remote connection from using a specific local listener port
while
> allowing it to connect to another local listener port.
>
> CHLAUTH is either going to allow the connection or not based on the
> remote source IP address, irrespective of what local listener port its
> attempting to come in on.
>
> I think classic firewalls are still the only way to keep a remote
> system
from
> hitting port 1414 (for example) on your server, but allow them to hit
> port
> 1415 (for example).
>
>
>
>
> Peter Potkay
>
> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> Behalf Of T.Rob
> Sent: Friday, November 01, 2013 11:06 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> To clarify, I don't recall whether we did this in the book but what
> *I*
shoot
> for is that the internal and external facing NICs are on distinct subnets.
> Then it's possible to use listener blocking CHLAUTH rules to filter.
>
> -- T.Rob
>
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> On
> > Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> > Sent: Thursday, October 31, 2013 18:29 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > T.Rob,
> > How was this accomplished?
> >
> > >>>>>" Of the listeners, we further classify them into "internal-facing"
> and
> > "external-facing" and use CHLAUTH rules to ensure that they can only
> > be accessed by the intended parties "
> >
> > I didn't see it explained in the Redbook and I don't think there is
> > a
> CHLAUTH
> > rule that sends connections to specific port# based on something the
> > CHLAUTH rule can see on the incoming connection. We use classic
> > Firewall rules to insure a business partner company can only hit the
> > port # where the listener we have dedicated for them is listening.
> >
> >
> >
> > Or when you say "... use CHLAUTH rules to ensure that they can only
> > be accessed..." the 'they' you were referring to was the channels
> > and not the listeners?
> >
> >
> >
> >
> > Peter Potkay
> >
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> On
> > Behalf Of T.Rob
> > Sent: Thursday, October 31, 2013 12:15 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > Hi Damian,
> >
> > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls
> > > to the
> > 3rd
> > > party?
> >
> > I'm sure Neil will jump in on this if I'm wrong, but I believe the
> > answer
> is
> > that we used 1414. The reasoning was that we can't require the 3rd
> > party to also run MQIPT. Nice if they do but for purposes of the
> > book we wanted the broadest application.
> >
> > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > sender
> > receiver
> > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > to disconnect that gateway qmgr from the trusted network qmgrs via
> > > a data power device connecting via a MQ client to the DMZ and
> > > trusted
> qmgrs.
> >
> > DEF "safe". An MCA channel agent will only ever do OPEN, INQ, and
> > PUT and it's IBM code running on your server. A client can do any
> > WMQ API and may be code running on someone else's server. If you
> > were to accept a client connection on the DMZ it would be necessary
> > to fully authenticate
> it
> > and to use CHLAUTH rules to ensure that only the authorized entity
> > could start that channel. If any of that is mis-configured, it is
> > possible that
> the
> > system degrades to a point where external parties can start a client
> channel
> > and that opens you up to resource enumeration. For purposes of
> > security, a good rule of thumb is that the fewer client channels the
better.
> >
> > On the other hand, a DataPower box has the ability to inspect the
> > payload of the messages. That may be a huge advantage if for
> > example they contain XML and you wish to filter out malicious
> > payloads. Or perhaps you wish to use the DP box as a policy
> > enforcement point and authorize messages based on the
> > MQMD.UserID or a token they carry. The difference is that DataPower
> does
> > things that WMQ cannot do. They address fundamentally *different*
> > threats.
> > It's not that one is safer than the other but rather a question of
> > the
> right
> > controls for the right threats.
> >
> > If the intent is to not allow externally initiated connections, you
> > can
> run
> > SDR/RQSTR pairs and initiate the connection to the DMZ from the
> > internal QMgr.
> >
> > Again, the design philosophy was to use only WMQ components
> > available "out of the box" wherever possible so as to achieve the
> > greatest applicability of the scenarios.
> >
> > > 3: Do the channel security exits need to be compiled at all? or do
> > > they
> > come
> > > in a binary (compiled ) format ready for deployment?
> >
> > The ITSO Message Exit is supplied as source code.
> >
> > > 4; what was the reasoning behind using different listener ports
> > > for the inbound and outbound connections on the DMZ qmgr?
> >
> > Actually, it's even more granular than that. In the event of
> > multiple 3rd parties, each gets their own listener as a way of
> > isolating their access
> path
> > to the QMgr. So each 3rd party has their own listener, channel,
> > QRemotes or QAliases, etc. This was a compromise that provides
> > limited isolation
> and
> > stops short of giving each 3rd party their own QMgr or virtual server.
> Also,
> > the way that MQIPT works, it helps to isolate routes.
> >
> > Of the listeners, we further classify them into "internal-facing"
> > and "external-facing" and use CHLAUTH rules to ensure that they can
> > only be accessed by the intended parties. If possible, we use a
> > multi-homed
> server
> > so that we can bind the listeners to specific sub-nets.
> > Furthermore, I routinely provision a dedicated administrative
> > listener separate from any other traffic.
> >
> > This is standard securiy stuff and we did it for the same reasons
> > that a DataPower box has 3 interfaces. One is for admin, one for
> > internal-facing connections and one for external-facing connections.
> > The result is that
> it
> > becomes possible to rely on the context of the connection for some
> > of the authorization bits. You would not, for instance, expect to
> > see administrative tasks performed on anything other than the
> > administrative connection. It is my hope that someday WMQ would
> > actually be able to enforce that deep in the code like DataPower
> > does, rather than requiring the admin to configur it from scratch.
> >
> > -- T.Rob
> >
> > > -----Original Message-----
> > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > On
> > > Behalf Of Costa, D. (Damian)
> > > Sent: Thursday, October 31, 2013 11:10 AM
> > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > Subject: Secure messaging red book (sg248069) questions
> > >
> > > HI all,
> > > I read with great interest the red book (sg248069), on secure
> > > messaging scenarios. Mainly because I need to setup a secure MQ
> > > environment for MQ.
> > > So I have these questions for those who wrote the red book:
> > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls
> > > to the
> > 3rd
> > > party? Or was it wrapped in a HTTP request envelope? I glossed
> > > over the MQ IPT pdf and sort of grasped that it could wrap the MQ
> > > protocol in a HTTP envelope. Our paranoid security team are very
> > > note keen to open the QM port 1414 on their firewalls. Which is
> > > where the http wrapper become very interesting for our
> > > requirements.... This would clearly require the
> > 3rd
> > > party client to also have an MQ PIT proxy server running to parse
> > > the http wrapper and extract the MQ protocol data.
> > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > sender
> > receiver
> > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > to disconnect that gateway qmgr from the trusted network qmgrs via
> > > a data power device connecting via a MQ client to the DMZ and
> > > trusted
> qmgrs.
> > > That should isolate the MQ connectivity into the trusted network.
> > > Definitely more 'spensive.....
> > > Or does the MQIPT proxy perform more protection services than I
> realise?
> > > 3: Do the channel security exits need to be compiled at all? or do
> > > they
> > come
> > > in a binary (compiled ) format ready for deployment?
> > > 4; what was the reasoning behind using different listener ports
> > > for the inbound and outbound connections on the DMZ qmgr?
> > > Was it a form of DOS mitigation or just a way of decoupling the
> > > internal MQ connections with the external (3rd party) ?
> > >
> > > Any guidance would be most appreciated.
> > >
> > > Thanks.
> > >
> > >
> > > ********************
> > > Nedbank Limited Reg No 1951/000009/06. The following link displays
> > > the names of the Nedbank Board of Directors and Company Secretary.
> > > [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
> > > is confidential and is intended for the addressee only.
> > > The following link will take you to Nedbank's legal notice.
> > > [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> > > ********************
> > >
> > > 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
> >
> > 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
> >
> **********************************************************
> > **
> > 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
>
> 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
> **********************************************************
> **
> 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

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
************************************************************
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

[T.Rob]

Well, I use a RQSTR for external connections pretty much as standard but
that doesn't mean we don't allow the other side to start them. Typically,
these are RQSTR/SDR pairs. When they are initiated remotely, I don't
believe that LOCLADDR has any effect. That just tells the OS which IP stack
to bind to when *it* creates the socket. When the remote partner initiates
the connection, the socket is created by the time WMQ sees it.

That said, you are correct that nothing in WMQ prevents someone external
from seeing all listeners bound to the external-facing IP address. My
method is capable of bouncing connections that arrive over the wrong one but
not of blocking at the listener on a per-listener basis. So one partner can
still easily flood another's listener if the firewall allows them to see it,
which is why we are still so tightly coupled to the firewall configuration
and why we are forced to use dedicated QMgrs and/or servers when greater
isolation across partners is required.

Unfortunately, most of us WMQ admins can't *see* the firewall configuration
and are prevented from actively testing that the expected settings have been
implemented. We know only that the desired access works, not whether some
superset of that was also granted and that's a problem during the audit. It
would be EXTREMELY helpful if the WMQ admin was able to get just a bit more
granular and do per-listener blocking by address and port rather than global
listener blocking by address only. We'd still ask the firewall people to do
their thing but we'd have a layer of defense capable of stopping
unauthorized requests and also alerting us to misconfigurations at the
firewall should a connection request arrive on the wrong port or IP.

In that case, the incomplete list I provided below would be narrowed down to
one line per listener.

Roger may pipe in here but in the meantime, I *think* MQAUSX can filter on
the port. Not sure about that, though. Now that I'm not IBM I should
probably get a copy of that. :-)

-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Potkay, Peter M (CTO Architecture + Engineering)
> Sent: Friday, November 01, 2013 16:09 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> Aha, using a RQSTR and using LOCLADDR is the key to get that connection
> to use a particular IP address, and thus the one and only Listener on
> that IP. And as you starte, if you have more than to partners coming in
> over that same external IP nothing in the MQ layer can restrict each to
> their own port/Listener, but classic firewalls solve that.
>
>
> Thanks for writing it up.
>
>
> Peter Potkay
>
>
> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of T.Rob
> Sent: Friday, November 01, 2013 2:26 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Secure messaging red book (sg248069) questions
>
> Hi Peter,
>
> OK, so let's say that my DMZ QMgr has 2 NICs where one is on an external
> address 184.154.160.239 and the other is on 192.168.1.2. First define
> the listeners and bind them to specific NIC addresses. Then define the
> channels and bind them to specific distinguished names. Finally, define
> some CHLAUTH rules that bind the channels to those same distinguished
> names.
>
> The external partner can only see the listener on 3414 and the CHLAUTH
> rule ensures that they can start only the one channel that was
> provisioned for them. Similar restrictions are placed on the internal
> channels and the internal listener. If we had more than one listener for
> external parties, we'd have the same issue as we do here for internal
> parties in that any external party could "see" both listeners (firewall
> rules permitting).
> However, the CHLAUTH rules matching on DN would cause these connections
> to bounce off.
>
> It's going around your ass to get to your elbow but it works. It would
> be dramatically simpler (and a lot more secure) if WMQ would allow
> binding between channels and ports without requiring distinguished names
> to close the loop.
>
> I haven't tested these for syntax but here's a rough approximation...
>
> * DEF Internal, external and admin listeners.
> DEF LISTENER(TCP.1414) TRPTYPE(TCP) +
> PORT(1414) +
> IPADDR(192.168.1.2) +
> DESCR('Listener for internal traffic') +
> REPLACE
> DEF LISTENER(TCP.2414) TRPTYPE(TCP) +
> PORT(2414) +
> IPADDR(192.168.1.2) +
> DESCR('Listener for Admin traffic') +
> REPLACE
> DEF LISTENER(TCP.3414) TRPTYPE(TCP) +
> PORT(3414) +
> IPADDR(184.154.160.239) +
> DESCR('Listener for external traffic') +
> REPLACE
>
> * DEF some channels
> DEF CHANNEL('ADMIN.TLS.SVRCONN') CHLTYPE(SVRCONN) +
> TRPTYPE(TCP) +
> MCAUSER('bad!admin') +
> SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
> REPLACE
> DEF CHANNEL('BIZ.PARTNER.RQSTR') CHLTYPE(RQSTR) +
> TRPTYPE(TCP) +
> CONNAME('1.2.3.4(5050)') +
> LOCLADDR('184.154.160.239') +
> MCAUSER('bizprtner') +
> SCYDATA('entry') +
> SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
> SCYEXIT('itsome') +
> REPLACE
> DEF CHANNEL('INTERNAL.DMZ') CHLTYPE(RCVR) +
> TRPTYPE(TCP) +
> MCAUSER('internal') +
> SCYDATA('entry') +
> SCYEXIT('itsome') +
> SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
> REPLACE
>
> * Set some CHLAUTH rules
> SET CHLAUTH('*') TYPE(ADDRESSMAP) +
> ADDRESS('184.*') +
> USERSRC(NOACCESS) +
> ACTION(REPLACE)
> SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(ADDRESSMAP) +
> ADDRESS('184.*') +
> USERSRC(CHANNEL) +
> ACTION(REPLACE)
> SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(SSLPEERMAP) +
> SSLPEER('CN=SOMEQMGR,O=Biz Partner')
> USERSRC(CHANNEL) +
> ADDRESS('1.2.3.4') +
> ACTION(REPLACE)
> SET CHLAUTH('INTERNAL.DMZ') TYPE(SSLPEERMAP) +
> SSLPEER('CN=OURQMGR,O=IoPT Consulting LLC') +
> USERSRC(CHANNEL) +
> ADDRESS('192.168.*') +
> ACTION(REPLACE)
>
> -- T.Rob
>
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> > Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> > Sent: Friday, November 01, 2013 12:50 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > I'm not aware of a way to have CHLAUTH block a Listener, or prevent a
> > particular remote connection from using a specific local listener port
> while
> > allowing it to connect to another local listener port.
> >
> > CHLAUTH is either going to allow the connection or not based on the
> > remote source IP address, irrespective of what local listener port its
> > attempting to come in on.
> >
> > I think classic firewalls are still the only way to keep a remote
> > system
> from
> > hitting port 1414 (for example) on your server, but allow them to hit
> > port
> > 1415 (for example).
> >
> >
> >
> >
> > Peter Potkay
> >
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> > Behalf Of T.Rob
> > Sent: Friday, November 01, 2013 11:06 AM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > To clarify, I don't recall whether we did this in the book but what
> > *I*
> shoot
> > for is that the internal and external facing NICs are on distinct
> subnets.
> > Then it's possible to use listener blocking CHLAUTH rules to filter.
> >
> > -- T.Rob
> >
> > > -----Original Message-----
> > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > On
> > > Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> > > Sent: Thursday, October 31, 2013 18:29 PM
> > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > Subject: Re: Secure messaging red book (sg248069) questions
> > >
> > > T.Rob,
> > > How was this accomplished?
> > >
> > > >>>>>" Of the listeners, we further classify them into "internal-
> facing"
> > and
> > > "external-facing" and use CHLAUTH rules to ensure that they can only
> > > be accessed by the intended parties "
> > >
> > > I didn't see it explained in the Redbook and I don't think there is
> > > a
> > CHLAUTH
> > > rule that sends connections to specific port# based on something the
> > > CHLAUTH rule can see on the incoming connection. We use classic
> > > Firewall rules to insure a business partner company can only hit the
> > > port # where the listener we have dedicated for them is listening.
> > >
> > >
> > >
> > > Or when you say "... use CHLAUTH rules to ensure that they can only
> > > be accessed..." the 'they' you were referring to was the channels
> > > and not the listeners?
> > >
> > >
> > >
> > >
> > > Peter Potkay
> > >
> > > -----Original Message-----
> > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > On
> > > Behalf Of T.Rob
> > > Sent: Thursday, October 31, 2013 12:15 PM
> > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > Subject: Re: Secure messaging red book (sg248069) questions
> > >
> > > Hi Damian,
> > >
> > > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls
> > > > to the
> > > 3rd
> > > > party?
> > >
> > > I'm sure Neil will jump in on this if I'm wrong, but I believe the
> > > answer
> > is
> > > that we used 1414. The reasoning was that we can't require the 3rd
> > > party to also run MQIPT. Nice if they do but for purposes of the
> > > book we wanted the broadest application.
> > >
> > > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > > sender
> > > receiver
> > > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > > to disconnect that gateway qmgr from the trusted network qmgrs via
> > > > a data power device connecting via a MQ client to the DMZ and
> > > > trusted
> > qmgrs.
> > >
> > > DEF "safe". An MCA channel agent will only ever do OPEN, INQ, and
> > > PUT and it's IBM code running on your server. A client can do any
> > > WMQ API and may be code running on someone else's server. If you
> > > were to accept a client connection on the DMZ it would be necessary
> > > to fully authenticate
> > it
> > > and to use CHLAUTH rules to ensure that only the authorized entity
> > > could start that channel. If any of that is mis-configured, it is
> > > possible that
> > the
> > > system degrades to a point where external parties can start a client
> > channel
> > > and that opens you up to resource enumeration. For purposes of
> > > security, a good rule of thumb is that the fewer client channels the
> better.
> > >
> > > On the other hand, a DataPower box has the ability to inspect the
> > > payload of the messages. That may be a huge advantage if for
> > > example they contain XML and you wish to filter out malicious
> > > payloads. Or perhaps you wish to use the DP box as a policy
> > > enforcement point and authorize messages based on the
> > > MQMD.UserID or a token they carry. The difference is that DataPower
> > does
> > > things that WMQ cannot do. They address fundamentally *different*
> > > threats.
> > > It's not that one is safer than the other but rather a question of
> > > the
> > right
> > > controls for the right threats.
> > >
> > > If the intent is to not allow externally initiated connections, you
> > > can
> > run
> > > SDR/RQSTR pairs and initiate the connection to the DMZ from the
> > > internal QMgr.
> > >
> > > Again, the design philosophy was to use only WMQ components
> > > available "out of the box" wherever possible so as to achieve the
> > > greatest applicability of the scenarios.
> > >
> > > > 3: Do the channel security exits need to be compiled at all? or do
> > > > they
> > > come
> > > > in a binary (compiled ) format ready for deployment?
> > >
> > > The ITSO Message Exit is supplied as source code.
> > >
> > > > 4; what was the reasoning behind using different listener ports
> > > > for the inbound and outbound connections on the DMZ qmgr?
> > >
> > > Actually, it's even more granular than that. In the event of
> > > multiple 3rd parties, each gets their own listener as a way of
> > > isolating their access
> > path
> > > to the QMgr. So each 3rd party has their own listener, channel,
> > > QRemotes or QAliases, etc. This was a compromise that provides
> > > limited isolation
> > and
> > > stops short of giving each 3rd party their own QMgr or virtual
> server.
> > Also,
> > > the way that MQIPT works, it helps to isolate routes.
> > >
> > > Of the listeners, we further classify them into "internal-facing"
> > > and "external-facing" and use CHLAUTH rules to ensure that they can
> > > only be accessed by the intended parties. If possible, we use a
> > > multi-homed
> > server
> > > so that we can bind the listeners to specific sub-nets.
> > > Furthermore, I routinely provision a dedicated administrative
> > > listener separate from any other traffic.
> > >
> > > This is standard securiy stuff and we did it for the same reasons
> > > that a DataPower box has 3 interfaces. One is for admin, one for
> > > internal-facing connections and one for external-facing connections.
> > > The result is that
> > it
> > > becomes possible to rely on the context of the connection for some
> > > of the authorization bits. You would not, for instance, expect to
> > > see administrative tasks performed on anything other than the
> > > administrative connection. It is my hope that someday WMQ would
> > > actually be able to enforce that deep in the code like DataPower
> > > does, rather than requiring the admin to configur it from scratch.
> > >
> > > -- T.Rob
> > >
> > > > -----Original Message-----
> > > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > > On
> > > > Behalf Of Costa, D. (Damian)
> > > > Sent: Thursday, October 31, 2013 11:10 AM
> > > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > > Subject: Secure messaging red book (sg248069) questions
> > > >
> > > > HI all,
> > > > I read with great interest the red book (sg248069), on secure
> > > > messaging scenarios. Mainly because I need to setup a secure MQ
> > > > environment for MQ.
> > > > So I have these questions for those who wrote the red book:
> > > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls
> > > > to the
> > > 3rd
> > > > party? Or was it wrapped in a HTTP request envelope? I glossed
> > > > over the MQ IPT pdf and sort of grasped that it could wrap the MQ
> > > > protocol in a HTTP envelope. Our paranoid security team are very
> > > > note keen to open the QM port 1414 on their firewalls. Which is
> > > > where the http wrapper become very interesting for our
> > > > requirements.... This would clearly require the
> > > 3rd
> > > > party client to also have an MQ PIT proxy server running to parse
> > > > the http wrapper and extract the MQ protocol data.
> > > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > > sender
> > > receiver
> > > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > > to disconnect that gateway qmgr from the trusted network qmgrs via
> > > > a data power device connecting via a MQ client to the DMZ and
> > > > trusted
> > qmgrs.
> > > > That should isolate the MQ connectivity into the trusted network.
> > > > Definitely more 'spensive.....
> > > > Or does the MQIPT proxy perform more protection services than I
> > realise?
> > > > 3: Do the channel security exits need to be compiled at all? or do
> > > > they
> > > come
> > > > in a binary (compiled ) format ready for deployment?
> > > > 4; what was the reasoning behind using different listener ports
> > > > for the inbound and outbound connections on the DMZ qmgr?
> > > > Was it a form of DOS mitigation or just a way of decoupling the
> > > > internal MQ connections with the external (3rd party) ?
> > > >
> > > > Any guidance would be most appreciated.
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > ********************
> > > > Nedbank Limited Reg No 1951/000009/06. The following link displays
> > > > the names of the Nedbank Board of Directors and Company Secretary.
> > > > [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
> > > > is confidential and is intended for the addressee only.
> > > > The following link will take you to Nedbank's legal notice.
> > > > [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> > > > ********************
> > > >
> > > > 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
> > >
> > > 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
> > >
> > **********************************************************
> > > **
> > > 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
> >
> > 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
> > **********************************************************
> > **
> > 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
>
> 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
> ************************************************************
> 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

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Roger Lacroix]

Hi T.Rob,

> Roger may pipe in here but in the meantime, I *think* MQAUSX can
filter on the port. Not sure about that, though.

Actually, when I was reading this email chain earlier today, I had
the same thought and quickly checked the MQCXP and MQCD
structures. The port number that an MCA is listening on is not
available to an MQ security exit. Well, I guess it is time for an RFE. :)

> Now that I'm not IBM I should probably get a copy of that.

Anybody can get a copy to play with anytime they want. :)

Regards,
Roger Lacroix
Capitalware Inc.

At 04:53 PM 11/1/2013, you wrote:
>Well, I use a RQSTR for external connections pretty much as standard but
>that doesn't mean we don't allow the other side to start them. Typically,
>these are RQSTR/SDR pairs. When they are initiated remotely, I don't
>believe that LOCLADDR has any effect. That just tells the OS which IP stack
>to bind to when *it* creates the socket. When the remote partner initiates
>the connection, the socket is created by the time WMQ sees it.
>
>That said, you are correct that nothing in WMQ prevents someone external
>from seeing all listeners bound to the external-facing IP address. My
>method is capable of bouncing connections that arrive over the wrong one but
>not of blocking at the listener on a per-listener basis. So one partner can
>still easily flood another's listener if the firewall allows them to see it,
>which is why we are still so tightly coupled to the firewall configuration
>and why we are forced to use dedicated QMgrs and/or servers when greater
>isolation across partners is required.
>
>Unfortunately, most of us WMQ admins can't *see* the firewall configuration
>and are prevented from actively testing that the expected settings have been
>implemented. We know only that the desired access works, not whether some
>superset of that was also granted and that's a problem during the audit. It
>would be EXTREMELY helpful if the WMQ admin was able to get just a bit more
>granular and do per-listener blocking by address and port rather than global
>listener blocking by address only. We'd still ask the firewall people to do
>their thing but we'd have a layer of defense capable of stopping
>unauthorized requests and also alerting us to misconfigurations at the
>firewall should a connection request arrive on the wrong port or IP.
>
>In that case, the incomplete list I provided below would be narrowed down to
>one line per listener.
>
>Roger may pipe in here but in the meantime, I *think* MQAUSX can filter on
>the port. Not sure about that, though. Now that I'm not IBM I should
>probably get a copy of that. :-)
>
>-- T.Rob
>
>
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> > Of Potkay, Peter M (CTO Architecture + Engineering)
> > Sent: Friday, November 01, 2013 16:09 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > Aha, using a RQSTR and using LOCLADDR is the key to get that connection
> > to use a particular IP address, and thus the one and only Listener on
> > that IP. And as you starte, if you have more than to partners coming in
> > over that same external IP nothing in the MQ layer can restrict each to
> > their own port/Listener, but classic firewalls solve that.
> >
> >
> > Thanks for writing it up.
> >
> >
> > Peter Potkay
> >
> >
> > -----Original Message-----
> > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> > Of T.Rob
> > Sent: Friday, November 01, 2013 2:26 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > Subject: Re: Secure messaging red book (sg248069) questions
> >
> > Hi Peter,
> >
> > OK, so let's say that my DMZ QMgr has 2 NICs where one is on an external
> > address 184.154.160.239 and the other is on 192.168.1.2. First define
> > the listeners and bind them to specific NIC addresses. Then define the
> > channels and bind them to specific distinguished names. Finally, define
> > some CHLAUTH rules that bind the channels to those same distinguished
> > names.
> >
> > The external partner can only see the listener on 3414 and the CHLAUTH
> > rule ensures that they can start only the one channel that was
> > provisioned for them. Similar restrictions are placed on the internal
> > channels and the internal listener. If we had more than one listener for
> > external parties, we'd have the same issue as we do here for internal
> > parties in that any external party could "see" both listeners (firewall
> > rules permitting).
> > However, the CHLAUTH rules matching on DN would cause these connections
> > to bounce off.
> >
> > It's going around your ass to get to your elbow but it works. It would
> > be dramatically simpler (and a lot more secure) if WMQ would allow
> > binding between channels and ports without requiring distinguished names
> > to close the loop.
> >
> > I haven't tested these for syntax but here's a rough approximation...
> >
> > * DEF Internal, external and admin listeners.
> > DEF LISTENER(TCP.1414) TRPTYPE(TCP) +
> > PORT(1414) +
> > IPADDR(192.168.1.2) +
> > DESCR('Listener for internal traffic') +
> > REPLACE
> > DEF LISTENER(TCP.2414) TRPTYPE(TCP) +
> > PORT(2414) +
> > IPADDR(192.168.1.2) +
> > DESCR('Listener for Admin traffic') +
> > REPLACE
> > DEF LISTENER(TCP.3414) TRPTYPE(TCP) +
> > PORT(3414) +
> > IPADDR(184.154.160.239) +
> > DESCR('Listener for external traffic') +
> > REPLACE
> >
> > * DEF some channels
> > DEF CHANNEL('ADMIN.TLS.SVRCONN') CHLTYPE(SVRCONN) +
> > TRPTYPE(TCP) +
> > MCAUSER('bad!admin') +
> > SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
> > REPLACE
> > DEF CHANNEL('BIZ.PARTNER.RQSTR') CHLTYPE(RQSTR) +
> > TRPTYPE(TCP) +
> > CONNAME('1.2.3.4(5050)') +
> > LOCLADDR('184.154.160.239') +
> > MCAUSER('bizprtner') +
> > SCYDATA('entry') +
> > SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
> > SCYEXIT('itsome') +
> > REPLACE
> > DEF CHANNEL('INTERNAL.DMZ') CHLTYPE(RCVR) +
> > TRPTYPE(TCP) +
> > MCAUSER('internal') +
> > SCYDATA('entry') +
> > SCYEXIT('itsome') +
> > SSLCIPH('TLS_RSA_WITH_AES_256_CBC_SHA256') +
> > REPLACE
> >
> > * Set some CHLAUTH rules
> > SET CHLAUTH('*') TYPE(ADDRESSMAP) +
> > ADDRESS('184.*') +
> > USERSRC(NOACCESS) +
> > ACTION(REPLACE)
> > SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(ADDRESSMAP) +
> > ADDRESS('184.*') +
> > USERSRC(CHANNEL) +
> > ACTION(REPLACE)
> > SET CHLAUTH('BIZ.PARTNER.RQSTR') TYPE(SSLPEERMAP) +
> > SSLPEER('CN=SOMEQMGR,O=Biz Partner')
> > USERSRC(CHANNEL) +
> > ADDRESS('1.2.3.4') +
> > ACTION(REPLACE)
> > SET CHLAUTH('INTERNAL.DMZ') TYPE(SSLPEERMAP) +
> > SSLPEER('CN=OURQMGR,O=IoPT Consulting LLC') +
> > USERSRC(CHANNEL) +
> > ADDRESS('192.168.*') +
> > ACTION(REPLACE)
> >
> > -- T.Rob
> >
> > > -----Original Message-----
> > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> > > Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> > > Sent: Friday, November 01, 2013 12:50 PM
> > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > Subject: Re: Secure messaging red book (sg248069) questions
> > >
> > > I'm not aware of a way to have CHLAUTH block a Listener, or prevent a
> > > particular remote connection from using a specific local listener port
> > while
> > > allowing it to connect to another local listener port.
> > >
> > > CHLAUTH is either going to allow the connection or not based on the
> > > remote source IP address, irrespective of what local listener port its
> > > attempting to come in on.
> > >
> > > I think classic firewalls are still the only way to keep a remote
> > > system
> > from
> > > hitting port 1414 (for example) on your server, but allow them to hit
> > > port
> > > 1415 (for example).
> > >
> > >
> > >
> > >
> > > Peter Potkay
> > >
> > > -----Original Message-----
> > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
> > > Behalf Of T.Rob
> > > Sent: Friday, November 01, 2013 11:06 AM
> > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > Subject: Re: Secure messaging red book (sg248069) questions
> > >
> > > To clarify, I don't recall whether we did this in the book but what
> > > *I*
> > shoot
> > > for is that the internal and external facing NICs are on distinct
> > subnets.
> > > Then it's possible to use listener blocking CHLAUTH rules to filter.
> > >
> > > -- T.Rob
> > >
> > > > -----Original Message-----
> > > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > > On
> > > > Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
> > > > Sent: Thursday, October 31, 2013 18:29 PM
> > > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > > Subject: Re: Secure messaging red book (sg248069) questions
> > > >
> > > > T.Rob,
> > > > How was this accomplished?
> > > >
> > > > >>>>>" Of the listeners, we further classify them into "internal-
> > facing"
> > > and
> > > > "external-facing" and use CHLAUTH rules to ensure that they can only
> > > > be accessed by the intended parties "
> > > >
> > > > I didn't see it explained in the Redbook and I don't think there is
> > > > a
> > > CHLAUTH
> > > > rule that sends connections to specific port# based on something the
> > > > CHLAUTH rule can see on the incoming connection. We use classic
> > > > Firewall rules to insure a business partner company can only hit the
> > > > port # where the listener we have dedicated for them is listening.
> > > >
> > > >
> > > >
> > > > Or when you say "... use CHLAUTH rules to ensure that they can only
> > > > be accessed..." the 'they' you were referring to was the channels
> > > > and not the listeners?
> > > >
> > > >
> > > >
> > > >
> > > > Peter Potkay
> > > >
> > > > -----Original Message-----
> > > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > > On
> > > > Behalf Of T.Rob
> > > > Sent: Thursday, October 31, 2013 12:15 PM
> > > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > > Subject: Re: Secure messaging red book (sg248069) questions
> > > >
> > > > Hi Damian,
> > > >
> > > > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls
> > > > > to the
> > > > 3rd
> > > > > party?
> > > >
> > > > I'm sure Neil will jump in on this if I'm wrong, but I believe the
> > > > answer
> > > is
> > > > that we used 1414. The reasoning was that we can't require the 3rd
> > > > party to also run MQIPT. Nice if they do but for purposes of the
> > > > book we wanted the broadest application.
> > > >
> > > > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > > > sender
> > > > receiver
> > > > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > > > to disconnect that gateway qmgr from the trusted network qmgrs via
> > > > > a data power device connecting via a MQ client to the DMZ and
> > > > > trusted
> > > qmgrs.
> > > >
> > > > DEF "safe". An MCA channel agent will only ever do OPEN, INQ, and
> > > > PUT and it's IBM code running on your server. A client can do any
> > > > WMQ API and may be code running on someone else's server. If you
> > > > were to accept a client connection on the DMZ it would be necessary
> > > > to fully authenticate
> > > it
> > > > and to use CHLAUTH rules to ensure that only the authorized entity
> > > > could start that channel. If any of that is mis-configured, it is
> > > > possible that
> > > the
> > > > system degrades to a point where external parties can start a client
> > > channel
> > > > and that opens you up to resource enumeration. For purposes of
> > > > security, a good rule of thumb is that the fewer client channels the
> > better.
> > > >
> > > > On the other hand, a DataPower box has the ability to inspect the
> > > > payload of the messages. That may be a huge advantage if for
> > > > example they contain XML and you wish to filter out malicious
> > > > payloads. Or perhaps you wish to use the DP box as a policy
> > > > enforcement point and authorize messages based on the
> > > > MQMD.UserID or a token they carry. The difference is that DataPower
> > > does
> > > > things that WMQ cannot do. They address fundamentally *different*
> > > > threats.
> > > > It's not that one is safer than the other but rather a question of
> > > > the
> > > right
> > > > controls for the right threats.
> > > >
> > > > If the intent is to not allow externally initiated connections, you
> > > > can
> > > run
> > > > SDR/RQSTR pairs and initiate the connection to the DMZ from the
> > > > internal QMgr.
> > > >
> > > > Again, the design philosophy was to use only WMQ components
> > > > available "out of the box" wherever possible so as to achieve the
> > > > greatest applicability of the scenarios.
> > > >
> > > > > 3: Do the channel security exits need to be compiled at all? or do
> > > > > they
> > > > come
> > > > > in a binary (compiled ) format ready for deployment?
> > > >
> > > > The ITSO Message Exit is supplied as source code.
> > > >
> > > > > 4; what was the reasoning behind using different listener ports
> > > > > for the inbound and outbound connections on the DMZ qmgr?
> > > >
> > > > Actually, it's even more granular than that. In the event of
> > > > multiple 3rd parties, each gets their own listener as a way of
> > > > isolating their access
> > > path
> > > > to the QMgr. So each 3rd party has their own listener, channel,
> > > > QRemotes or QAliases, etc. This was a compromise that provides
> > > > limited isolation
> > > and
> > > > stops short of giving each 3rd party their own QMgr or virtual
> > server.
> > > Also,
> > > > the way that MQIPT works, it helps to isolate routes.
> > > >
> > > > Of the listeners, we further classify them into "internal-facing"
> > > > and "external-facing" and use CHLAUTH rules to ensure that they can
> > > > only be accessed by the intended parties. If possible, we use a
> > > > multi-homed
> > > server
> > > > so that we can bind the listeners to specific sub-nets.
> > > > Furthermore, I routinely provision a dedicated administrative
> > > > listener separate from any other traffic.
> > > >
> > > > This is standard securiy stuff and we did it for the same reasons
> > > > that a DataPower box has 3 interfaces. One is for admin, one for
> > > > internal-facing connections and one for external-facing connections.
> > > > The result is that
> > > it
> > > > becomes possible to rely on the context of the connection for some
> > > > of the authorization bits. You would not, for instance, expect to
> > > > see administrative tasks performed on anything other than the
> > > > administrative connection. It is my hope that someday WMQ would
> > > > actually be able to enforce that deep in the code like DataPower
> > > > does, rather than requiring the admin to configur it from scratch.
> > > >
> > > > -- T.Rob
> > > >
> > > > > -----Original Message-----
> > > > > From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org]
> > > > On
> > > > > Behalf Of Costa, D. (Damian)
> > > > > Sent: Thursday, October 31, 2013 11:10 AM
> > > > > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> > > > > Subject: Secure messaging red book (sg248069) questions
> > > > >
> > > > > HI all,
> > > > > I read with great interest the red book (sg248069), on secure
> > > > > messaging scenarios. Mainly because I need to setup a secure MQ
> > > > > environment for MQ.
> > > > > So I have these questions for those who wrote the red book:
> > > > > 1: Did the MQIPT server use vanilla MQ protocol out the firewalls
> > > > > to the
> > > > 3rd
> > > > > party? Or was it wrapped in a HTTP request envelope? I glossed
> > > > > over the MQ IPT pdf and sort of grasped that it could wrap the MQ
> > > > > protocol in a HTTP envelope. Our paranoid security team are very
> > > > > note keen to open the QM port 1414 on their firewalls. Which is
> > > > > where the http wrapper become very interesting for our
> > > > > requirements.... This would clearly require the
> > > > 3rd
> > > > > party client to also have an MQ PIT proxy server running to parse
> > > > > the http wrapper and extract the MQ protocol data.
> > > > > 2: Is it (really) safe to connect the DMZ qmgr directly , using
> > > > > sender
> > > > receiver
> > > > > channel pairs, to qmgrs on the trusted network? Would it be better
> > > > > to disconnect that gateway qmgr from the trusted network qmgrs via
> > > > > a data power device connecting via a MQ client to the DMZ and
> > > > > trusted
> > > qmgrs.
> > > > > That should isolate the MQ connectivity into the trusted network.
> > > > > Definitely more 'spensive.....
> > > > > Or does the MQIPT proxy perform more protection services than I
> > > realise?
> > > > > 3: Do the channel security exits need to be compiled at all? or do
> > > > > they
> > > > come
> > > > > in a binary (compiled ) format ready for deployment?
> > > > > 4; what was the reasoning behind using different listener ports
> > > > > for the inbound and outbound connections on the DMZ qmgr?
> > > > > Was it a form of DOS mitigation or just a way of decoupling the
> > > > > internal MQ connections with the external (3rd party) ?
> > > > >
> > > > > Any guidance would be most appreciated.
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > > ********************
> > > > > Nedbank Limited Reg No 1951/000009/06. The following link displays
> > > > > the names of the Nedbank Board of Directors and Company Secretary.
> > > > > [ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
> > > > > is confidential and is intended for the addressee only.
> > > > > The following link will take you to Nedbank's legal notice.
> > > > > [ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
> > > > > ********************
> > > > >
> > > > > 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
> > > >
> > > > 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
> > > >
> > > **********************************************************
> > > > **
> > > > 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
> > >
> > > 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
> > > **********************************************************
> > > **
> > > 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
> >
> > 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
> > ************************************************************
> > 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
>
>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

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

[George Carey]

>From T-Rob: "It is my hope that someday WMQ would actually be able to
enforce that deep in the code like Data Power does, rather than requiring
the
admin to configure it from scratch.",

take the DataPower VE code strip it down to only MQ related functionality
(FSHes etc.) and make if part of MQ suite WMQ-DP, a la AMS and the like!?



GTC





From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Neil Casey
Sent: Friday, November 01, 2013 4:43 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Secure messaging red book (sg248069) questions



Hi,



I really don't plan to contradict anything that T.Rob has said, but I will
try to add some comments that might help to explain our thinking and
intentions in the scenario we built and described.



1. We did not use http proxy, but preferred MQ channel protocol. There are a
couple of reasons for this.



My opinion of using http is that it actually provides an undesirable
capability. An administrator could configure a B2B connection through the
proxy server without it being reviewed and authorised by the security
control team. This has the effect of implementing a B2B connection by
stealth.



This is because using http via MQIPT exploits firewall rules for std web
ports that are likely to be allowed through the corporate firewall anyway.
By using native MQ protocol on a specified (and most likely non-default)
port, the MQ administrator is going to have to properly request the firewall
rule, which is the right behaviour anyway in most organisations.



Also, using http proxies introduces bandwidth, latency and reliability
issues compared with using MQ protocol directly.



2. You have identified a concern which we had, but were not able to address.
In section 10.2.1 we describe a desirable configuration where a B2B
application would run against the gateway queue manager. This would act to
provide validation, information hiding, routing and potentially
transformation services. Unfortunately, neither an IBM nor 3rd Party B2B
application was within the scope of the residency. So we mentioned that such
an application would be good, but we did not attempt to implement it.



We did implement an exit to provide a very limited amount of the capability
that would normally be provided by the B2B application running against the
gateway queue manager.



T.Rob addresses the possibility of using a DataPower appliance to provide
this B2B application functionality as you suggested. Personally, I wouldn't
want to connect to separate front and rear side to different queue managers,
because it adversely impacts message reliability (QOS). DataPower cannot
implement distributed unit of work between 2 queue managers. Instead, I
would connect both the front and rear side handler in the DataPower to the
same queue manager. With unit of work management, DP could then maintain
persistent message reliability.



So there is a trade off between (maybe) better security provided by complete
separation using DP and connections to separate queue managers vs better
message reliability by including the GET and PUT operations into the same
unit of work on the DP. I would tend to fall to the reliability side of the
question.



3. As T.Rob said. it is source code only. This is a necessary thing. A
residency does not have ongoing resources which could provide support to a
binary implementation. It also doesn't have the resources or capability to
compile for all (or even more than one or two of) the available WebSphere MQ
platforms. Finally, the exit is provided without warrantee of any kind.
From a security perspective, the code should be reviewed and customised
before use to ensure that it meets the needs of the organisation, and that
it does not present new security exposures.



4. Really can't add to T.Rob's explanation. :-)





Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] <tel:+61%20414%20615%20334>
<mailto:neil.casey-VLLIzlmz+***@public.gmane.org> 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





On 1 Nov 2013, at 3:15 am, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org> wrote:




Hi Damian,




1: Did the MQIPT server use vanilla MQ protocol out the firewalls to the

3rd



party?


I'm sure Neil will jump in on this if I'm wrong, but I believe the answer is
that we used 1414. The reasoning was that we can't require the 3rd party to
also run MQIPT. Nice if they do but for purposes of the book we wanted the
broadest application.




2: Is it (really) safe to connect the DMZ qmgr directly , using sender

receiver



channel pairs, to qmgrs on the trusted network? Would it be better to
disconnect that gateway qmgr from the trusted network qmgrs via a data
power device connecting via a MQ client to the DMZ and trusted qmgrs.


Define "safe". An MCA channel agent will only ever do OPEN, INQ, and PUT
and it's IBM code running on your server. A client can do any WMQ API and
may be code running on someone else's server. If you were to accept a
client connection on the DMZ it would be necessary to fully authenticate it
and to use CHLAUTH rules to ensure that only the authorized entity could
start that channel. If any of that is mis-configured, it is possible that
the system degrades to a point where external parties can start a client
channel and that opens you up to resource enumeration. For purposes of
security, a good rule of thumb is that the fewer client channels the better.

On the other hand, a DataPower box has the ability to inspect the payload of
the messages. That may be a huge advantage if for example they contain XML
and you wish to filter out malicious payloads. Or perhaps you wish to use
the DP box as a policy enforcement point and authorize messages based on the
MQMD.UserID or a token they carry. The difference is that DataPower does
things that WMQ cannot do. They address fundamentally *different* threats.
It's not that one is safer than the other but rather a question of the right
controls for the right threats.

If the intent is to not allow externally initiated connections, you can run
SDR/RQSTR pairs and initiate the connection to the DMZ from the internal
QMgr.

Again, the design philosophy was to use only WMQ components available "out
of the box" wherever possible so as to achieve the greatest applicability of
the scenarios.




3: Do the channel security exits need to be compiled at all? or do they

come



in a binary (compiled ) format ready for deployment?


The ITSO Message Exit is supplied as source code.




4; what was the reasoning behind using different listener ports for the
inbound and outbound connections on the DMZ qmgr?


Actually, it's even more granular than that. In the event of multiple 3rd
parties, each gets their own listener as a way of isolating their access
path to the QMgr. So each 3rd party has their own listener, channel,
QRemotes or QAliases, etc. This was a compromise that provides limited
isolation and stops short of giving each 3rd party their own QMgr or virtual
server. Also, the way that MQIPT works, it helps to isolate routes.

Of the listeners, we further classify them into "internal-facing" and
"external-facing" and use CHLAUTH rules to ensure that they can only be
accessed by the intended parties. If possible, we use a multi-homed server
so that we can bind the listeners to specific sub-nets. Furthermore, I
routinely provision a dedicated administrative listener separate from any
other traffic.

This is standard securiy stuff and we did it for the same reasons that a
DataPower box has 3 interfaces. One is for admin, one for internal-facing
connections and one for external-facing connections. The result is that it
becomes possible to rely on the context of the connection for some of the
authorization bits. You would not, for instance, expect to see
administrative tasks performed on anything other than the administrative
connection. It is my hope that someday WMQ would actually be able to
enforce that deep in the code like DataPower does, rather than requiring the
admin to configur it from scratch.

-- T.Rob




-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Costa, D. (Damian)
Sent: Thursday, October 31, 2013 11:10 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Secure messaging red book (sg248069) questions

HI all,
I read with great interest the red book (sg248069), on secure messaging
scenarios. Mainly because I need to setup a secure MQ environment for
MQ.
So I have these questions for those who wrote the red book:
1: Did the MQIPT server use vanilla MQ protocol out the firewalls to the

3rd



party? Or was it wrapped in a HTTP request envelope? I glossed over the
MQ IPT pdf and sort of grasped that it could wrap the MQ protocol in a
HTTP envelope. Our paranoid security team are very note keen to open the
QM port 1414 on their firewalls. Which is where the http wrapper become
very interesting for our requirements.... This would clearly require the

3rd



party client to also have an MQ PIT proxy server running to parse the http
wrapper and extract the MQ protocol data.
2: Is it (really) safe to connect the DMZ qmgr directly , using sender

receiver



channel pairs, to qmgrs on the trusted network? Would it be better to
disconnect that gateway qmgr from the trusted network qmgrs via a data
power device connecting via a MQ client to the DMZ and trusted qmgrs.
That should isolate the MQ connectivity into the trusted network.
Definitely more 'spensive.....
Or does the MQIPT proxy perform more protection services than I realise?
3: Do the channel security exits need to be compiled at all? or do they

come



in a binary (compiled ) format ready for deployment?
4; what was the reasoning behind using different listener ports for the
inbound and outbound connections on the DMZ qmgr?
Was it a form of DOS mitigation or just a way of decoupling the internal
MQ connections with the external (3rd party) ?

Any guidance would be most appreciated.

Thanks.


********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

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


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





_____

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