Among other things, locking out the old SVRCONN. This is too deep a subject to cover in this format. Frankly, there aren’t any widely accepted best practices for PCI and WMQ yet, as far as I know. In fact, I believe PCI is only now beginning to look into what used to be called “the trusted internal network” at middleware in general. That said, you might have a look at this article for some additional thoughts on PCI and WMQ: http://bit.ly/63eIux

I’m working for a Retail Client and we have to implement PCI requirements on MQ Servers. As part of this, we asked the app folks to use new svrconn with MCAUSER instead of default one. I would like to know what are the other things has to be changed to meet the requirements.

MQ versions – 6.0.2.2 & above
OS – Solaris 10 & Win 2003

Thank You

Thanks.

I’m not sure I see the distinction you are making. It’s the same exposure as a RCVR or RQSTR channel with default settings and with the same mitigation – a low-privileged MCAUSER.

Believe it or not, this actually is documented. But the degree to which it is not understood tells me the documentation is not as accessible or perhaps explicit as it could be. I’ve been submitting changes and suggestions through the Infocenter feedback links at the bottom of each page and I’ve seen quite a number of them implemented. So I agree the docs still have room for improvement but I’m encouraged by the progress we’ve made so far and I’ll continue submitting suggestions. Of course, all readers are invited to submit their own suggestions through the Feedback links in the Infocenter so if you see something amiss, don’t wait for me to catch it!

It would be pretty unusual that a remote QMgr would need to put messages into the event queues. I make an exception for B2B QMgrs because I sometimes route their events to the internal QMgrs for off-the-box monitoring.

No channel should be putting messages into SYSTEM or user-defined initiation queues.

Point-to-point channels should not have access to the cluster command queue. Of course, this might mean setting up two different MCAUSER values for P2P and cluster channels.

There are several I’m not sure about like the SYSTEM.SELECTION.* and SYSTEM.JMS.* queues. I doubt any channel legitimately needs access to the selection queues. I think only SVRCONN channels would need access to the SYSTEM.JMS.* queues. It might be worth opening a PMR to get the official answer as to which ones legitimately should be accessed by adjacent QMgrs or client apps. If you do this, please send me the PMR number.

Thanks , it worked.

What this means is We must always secure the cluster receiver channels.

Simply setting up a cluster is a wide open backdoor.
I think IBM needs to document this. Most documentation is regarding remote administration in cluster is vague or does not address this fact.

I was reviewing our implementation of these today, and noticed the following in mqmmca.aut:

# Consider restricting access to all SYSTEM.** queues and then adding back
# access to those that are legitimately required such as broker queues
# or SYSTEM.CLUSTER.COMMAND.QUEUE

Since I don’t understand what all the SYSTEM.** queues do, I am not comfortable doing this. However, I believe that there are some queues that can and should be universally restricted, that I don’t see in the script.

You have mentioned (in other settings) that there are queues that nobody should be modifying (other than internal WMQ code).

The one I noticed was:
SYSTEM.AUTH.DATA.QUEUE

So, in our mqmmca.aut script, I am adding:
setmqaut -m QMGR -g mqmmca -n SYSTEM.AUTH.DATA.QUEUE -t queue -all +none

Are there any others?