Exits, tools & such (was: Secure messaging...)

T.Rob

2013-11-01 21:41:45 UTC

Thanks for the update, Roger! I figured if it wasn't in MQAUSX the reason
would be that the data wasn't available.

Start date on my next gig got pushed back so I may have some time next week
to frolic in the sandbox. MQAUSX is definitely on the list of toys to play
with. Spent part of today getting up to speed on IR-360 and emailing Paul
about MQSCX. It's amazing how having some tools available, even if only on
my laptop, makes consulting SO much easier. There were a lot of things I
loved about working at IBM but consulting without access to the 3rd party
tools ecosystem was pretty confining. Now that I have some power tools to
work with I plan to take over the world! [Wrings hands and cackles
triumphantly.]

-- T.Rob

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

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-----
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, November 01, 2013 16:09 PM
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-----
Of T.Rob
Sent: Friday, November 01, 2013 2:26 PM
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-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, November 01, 2013 12:50 PM
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-----
Behalf Of T.Rob
Sent: Friday, November 01, 2013 11:06 AM
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-----

Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 31, 2013 18:29 PM
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-----

Behalf Of T.Rob
Sent: Thursday, October 31, 2013 12:15 PM
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

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

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

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

Behalf Of Costa, D. (Damian)
Sent: Thursday, October 31, 2013 11:10 AM
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.
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

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

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

**********************************************************

**
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 <http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

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

<http://www.lsoft.com/>

are

not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
**********************************************************
**
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

<http://www.lsoft.com/>

Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

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

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

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