>what are the drawbacks of just making one big cluster (external and
>internal queue managers in the same cluster) as opposed to having a
>"gateway" queue manager in overlapping clusters (which is recommended from
>one document that I've read).

Your firewall administration can get unwieldy.  Rather than setting up a
couple rules on the firewall, you now have to allow for the possibility of
however many external QMgrs connecting to some number of internal QMgrs.  So
if you have three internal QMgrs talking to two external QMgrs you will need
6 sets of rules.

You will also need to set up the firewall with no address translation among
all the related hosts.  When you set up a CLUSRCVR channel, both the
external hosts and the internal hosts (the repositories at the very least)
need to access it using the same IP address.

>Aside from issues with server connection channels, what other security
>issues should we be concerned with, and how would those issues be

An MQ cluster is basically a Pub/Sub engine feeding a modified Command
Server.  When you advertise a queue or join a cluster, the configuration
change is published to the repositories and propagated to anyone subscribed
to those changes.  When the published changes arrive at a repository or
subscribing QMgr they are acted on by the modified Command Server which then
builds channels or updates the local repository (whether full or partial).

>From a security standpoint, you should be aware that any member of the
cluster can publish these messages and your QMgrs will automatically
respond.  That means any QMgr which can join the cluster can become a full
repository and/or alter the cluster's configuration.

Also, any QMgr which can join the cluster can send messages anywhere
throughout the cluster, whether the target queues are advertised to the
cluster or not.  So if your QMgrA is in the cluster I can send PCF messages
to [EMAIL PROTECTED] and because they arrive over your
CLUSRCVR channel, chances are they have full mqm admin privileges.

Since the attacker can be a repository, they generally know enough about
your cluster to go at least one hop beyond the cluster further into your MQ
network.  The gateway is meant to restrict that one-hop access to just the
QMgrs the other side needs to know about.  Remove the gateway and the
one-hop now extends considerably further in.

-- T.Rob

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Reply via email to