WebSphere MQ security heats up

developerWorks article WebSphere MQ Security heats up from November 2007.

Are your MQ channels as secure as they should be? What you need to know about recent developments in IBM® WebSphere® MQ security and, more importantly, what you need to do — now.

WebSphere MQ had been in the market 14 years when this article was published.  During that time the two big changes to the product’s security posture were to set MCAUSER blank by default due to strong customer feedback, and the addition of SSL as a channel option.  The first made WMQ wide open by default and the second was only used by a relatively few customers.  Over the years, WMQ security was systematically ignored by users and hackers alike.

But Martyn Ruks presentation at Defcon 15 changed that.  WebSphere MQ was “outed” to the hacker community.  For me and at least a few WMQ shops out there, this signaled the start of an arms race.  In this article and in presentations at the conferences I made a case to start securing the messaging network now – before there is a breach reported.  Of course, for many shops out there it will take one or more publicly reported breaches of WMQ before they perceive a business case to secure WMQ.

The problem with that approach is that security is not something you just “turn on” and walk away.  As I discuss in my most recent article, WebSphere MQ, PCI DSS, and security standards, security is just as much about the human processes and policies as it is about configuration.  It is a discipline and as such it needs time to mature within an organization and it requires an ongoing commitment.  The idea that you can wait for a breach to occur (and hope it happens to someone else) and then just magically switch on security is unrealistic.

My other argument for implementing security sooner rather than later is the conversion cost.  Although the human element is the most important, the capital costs tend to be the biggest hurdle.  If the incremental overhead of security is factored into the baseline for a new queue manager when the network is small, the cost is allocated out to the lines of business in small, digestable bites.  But if there are 500 or 1,000 or more servers to secure in a big remediation project, the capital cost and effort approach that of any other major funded project.  I know of one shop that spent USD $500,000 just on on certificates.

So to sum up – enable WMQ security now.  The earlier you do it and the smaller your network, the better.  But even if you have a large network, the problem will only get worse over time.


Since publishing this article, I have taken a stronger stance on using generic authorizations.  In principle, this is due to an aversion I have developed for taking implicit actions in a security context.  The problem with implicit actions is that they sometimes do not behave as expected.  An example of this is that in WMQ v6 the authorization +allmqi applied to a queue manager granted +connect and +inquire only.  As of v7, the same permission also grants +set authority.  So in the code where it says +allmqi, this needs to be updated to read +connect +inq.

There were also some typos in the queue names.  These have been updated in the article but my corrections were not applied quite as I provided them so the queue names still need to be corrected.

Finally, I need to clarify how generic authorization profiles work.  If a group such as mqmmqi already has authorization profiles defined per-queue, running the scripts provided here will NOT delete or override the pre-existing authorizations.  The way it works is that if there are two profiles that apply to the same object, the most specific one takes precedence.  To put this another way, if you have a group that is over-authorized running these profiles against that group will NOT result in removal of their administrative rights.  It is necessary to first remove any profiles they have and then run the new profiles.

That said, here are the udated profiles for mqmmca and mqmmqi.

[Update 7 November, 2008: The script templates are now available as a separate download here.  But don’t let that stop you from reading the rest of the article.  The templates are the same as what’s in the text below so you can cut-n-paste or download, either way.]


This script allows QMgr-to-QMgr channels to put to any queue on the local queue manager *except* for a few administrative queues.  This is the bare minimum required to prevent administrative access.  In practice, the authorization list would probably be much finer grained.  Indeed, on a B2B gateway the policy would deny access to all queues and then override that by explicitly allowing fully-qualified queue names.

# --------------------------------------------------------------------
# mqmmca.aut
# This script allows the message channel agent (MCA) to PUT to any
# queue or topic *except* some of the SYSTEM.* ones.
# This is used when you want to lock down only admin access but not
# otherwise restrict the MCA.
# 20081022 - Updated to include Topics for v7
# --------------------------------------------------------------------
# Allow MCAUSER to connect.  Needs +setall per IBM docs.
setmqaut -m QMGR -g mqmmca -t qmgr -all +connect +inq +setall

# Grant MCAUSER default policy of "allow all" to all queues.  Channels
# put messages so no need for get, browse, etc.  Also needs +setall.
setmqaut -m QMGR -g mqmmca -n '**' -t queue -all +put +setall

# Grant access to topics for v7
setmqaut -m QMGR -g mqmmca -n '**' -t topic -all +pub +setall

# Now deny access to administrative queues
setmqaut -m QMGR -g mqmmca -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -all +none
setmqaut -m QMGR -g mqmmca -n SYSTEM.DEFAULT.INITIATION.QUEUE -t queue -all +none

# Restrict access to any additional initiation queues as well.
# Consider restricting access to any transmit queues.
# Consider restricting access to all SYSTEM.** queues and then adding back
# access to those that are legitimately required such as broker queues

# --------------------------------------------------------------------
# E N D   O F   S C R I P T
# --------------------------------------------------------------------

MQI Channels (SVRCONN)

The purpose of this script is to take a set of users who currently have anonymous administrative access and restrict the administrative rights.  These users will still have nearly unrestricted rights on the queue manager and this is NOT intended to be the security model you would want to use permanently.  This is intended to be an interim step that at least provides some accountability over the administrative functions.  To make this useful, the administrators need a channel that still allows administrative access but strongly authenticates the user based on an SSL certificate or other credential exchange.

# --------------------------------------------------------------------
# mqmmqi.aut
# This script allows users to do anything to any queue or topic
# *except* the SYSTEM.* ones which are restricted to read-only.
# Other object types are displayable only.
# This is used when you want to lock down only admin access but not
# otherwise restrict application users.
# 20081022 - Updated to include Topics for v7
# --------------------------------------------------------------------

# Allow MCAUSER to connect to QMgr
setmqaut -m QMNAME -g mqmmqi -t qmgr -all +connect +inq +dsp

# Allow inquire/display of non-queue objects
# Some of these object types are new for v6
setmqaut -m QMNAME -g mqmmqi -n '**' -t namelist -all +dsp +inq
setmqaut -m QMNAME -g mqmmqi -n '**' -t process  -all +dsp +inq
setmqaut -m QMNAME -g mqmmqi -n '**' -t authinfo -all +dsp +inq
setmqaut -m QMNAME -g mqmmqi -n '**' -t channel  -all +dsp
setmqaut -m QMNAME -g mqmmqi -n '**' -t service  -all +dsp
setmqaut -m QMNAME -g mqmmqi -n '**' -t listener -all +dsp
setmqaut -m QMNAME -g mqmmqi -n '**' -t clntconn -all +dsp

# Default allow-all to all queues
setmqaut -m QMNAME -g mqmmqi -n '**' -t queue  -all +inq +browse +dsp

# Default allow-all to all topics - new for v7
setmqaut -m QMNAME -g mqmmqi -n '**' -t topic  -all +pub +sub +dsp

# This gets us back to almost full admin but positions us to set
# additional restrictions.

# Restrict access to SYSTEM.** queues.  Browsing and display of these
# queues is reasonable but not PUT, SET, ALTUSR, etc.
setmqaut -m QMNAME -g mqmmqi -n 'SYSTEM.**' -t queue  -all +inq +browse +dsp

# Allow limited access to command queue.
setmqaut -m QMNAME -g mqmmqi -n 'SYSTEM.ADMIN.COMMAND.QUEUE' -t queue  -all +inq +put +dsp

# Allow access to SYSTEM.MQEXPLORER.REPLY.MODEL if it exists.
setmqaut -m QMNAME -g mqmmqi -n 'SYSTEM.MQEXPLORER.REPLY.MODEL' -t queue +all

setmqaut -m QMNAME -g mqmmqi -n 'SYSTEM.DEFAULT.MODEL.QUEUE' -t queue  -all +allmqi +dsp

# Restrict access to DLQ.  This assumes SYSTEM DLQ is used.  If not, you
# might want to script this to inquire on the QMgr DLQ property and set that.
setmqaut -m QMNAME -g mqmmqi -n 'SYSTEM.DEAD.LETTER.QUEUE' -t queue  -all +put +inq +browse +dsp

# In addition, restrict access to any user-defined initiation queues.
# Consider restricting access to any user-defined XMit queues as well.

# --------------------------------------------------------------------
# E N D   O F   S C R I P T
# --------------------------------------------------------------------
This entry was posted in Errata, News, Publications, WMQ, WMQ Security and tagged , , , , , , , , . Bookmark the permalink.

29 Responses to WebSphere MQ security heats up

  1. kishi says:

    Just to add it, exactly what kind of information will pass through command.queue for a read access? if a user is connecting mqmon or explorer with read access..does he need a put access on command.queue?

    • T.Rob says:

      The WMQ API provides access to WMQ objects. But it is the Command Server that provides information about MQ objects. For example, when Explorer or MQMon sign onto the queue manager and the user goes to the Queues screen, how does the tool populate that screen? It does so by putting the PCF equivalent of “DIS Q(*)” onto the command queue and getting the reply consisting of a list of queue names and a few other attributes. So if you don’t grant access to the command queue, tools like MQMon or Explorer won’t work.

      The danger in letting people put messages onto the command queue is that they might find a way to escalate their privileges to become admin. But ALL stakeholders need to have some inquiry access to look at the QMgr and its objects. There are a couple of ways to approach this. My articles generally take the approach of granting limited access. Yes, they can put to the command queue but they are strictly limited to very specific actions. For example, they NEVER are granted +set on the QMgr or +crt or +setid on a queue or topic because that would make them administrators. The other way to approach this is to use a central tool like IR-360. In this scenario the tool has admin access to WMQ but users are restricted by the tool. The great thing is that it’s possible to give people access without having to create accounts for them on each QMgr or provision TLS certificates to them. I’ll be talking with the folks from Avada about this topic at IMPACT.

      • kishi says:

        so, you mean, though We give System.admin.command.queue – put access for read only required users, if We also set as , setmqaut -m %%m -t qmgr -g %%g +connect +dsp +inq,
        setmqaut -m %%m -n “*.**” -t queue -g %%g +dsp +browse +inq , this will prevent readonly users preventing to get any admin related activities on Queue manager and queues..is my understanding correct?

        • T.Rob says:

          Where two profiles overlap, the most specific one takes precedence. So if you grant -n “**” -all +dsp +browse +inq and also grant -n “SYSTEM.ADMIN.COMMAND.QUEUE” -all +put +dsp +browse +inq then the group granted access will have +put on only the command queue and will have +dsp +browse +inq on all queues including the command queue. The resulting permissions are honored by both the QMgr for API calls and by the command server for PCF commands. Don’t forget the -all since that will remove any existing permissions for that profile/group combination.

          • kishi says:

            ok..it makes sense. thanks for the clarification. May be role based authority is the simplest and straight forward one.

      • kishi says:

        hi Rob,

        hope your new career is going well.

        Can you please answer for my below questions?

        1) Earlier you mentioned that
        Applications can grant access for put to the command queue but they are strictly limited to very specific actions. For example, they NEVER are granted +set on the QMgr or +crt or +setid on a queue or topic because that would make them administrators.

        Here you are mentioning +setid on any queue or system.admin.command queue?

        2) Also in one of your posts ( http://comments.gmane.org/gmane.network.mq.devel/8327),
        I was reading/understanding as
        for MQI channels, if We set mcauser id with less privilege, and if the application has setid privilege, it also can be overwritten by MCAUSER id..and that way, We can prevent applications to access with higher privileges..
        is this my understanding correct?

  2. kishi says:

    hi Rob,
    For read access, IBM infocenter suggests, We can give access to command queue as below:
    setmqaut -m QMgrName -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -g GroupName +dsp +inq +put, and your script also gives access as same.
    But, I read as it’s a risk for every user to give put access to command.queue?
    What’s your thoughts on this? also, what level the risk can occur?

  3. PETE HANBURY says:

    Ha T Rob,
    Thanks for your answer to my mail box yesterday. Finally i found somthink which answers the question : Taken from a blog yesterday
    best regards

    ( https://forums.oracle.com/forums/thread.jspa?threadID=1026304 )

    In your binding file QCF or XAQCF definition , you will see a Channel field since you are using a client mode to connect to the queue manager. This channel is called a Server Connection Channel [ SVRCONN]. At the queue manager side of things, when this SVRCONN is defined, MQ Admin teams tend to define an attribute called MCAUSER. In this setup the userid used for authorisation at queue manager is the following in the below precedence:

    1. If MCAUSER is defined in the channel, that will be the user id and it overrides any security context sent from client application. This user id should have sufficient permissions to connect to queue manager , get , put. The MQ admin teams on certain platforms will be able to get the exact permission that is missed from the queue manager error logs when a 2035 security exception occurs.

    2. If no MCAUSER is defined then the userid passed in the createConnection JMS call will be the user context used.

    I am not exactly sure of the behaviour when no MCAUSER and no user id in createConnection calls, but i think it takes the user of the MQ Listener process which starts the SVRCONN channel instance when a client initiates the connection.

    So for your situation, it will be worth start checking with how the MQ side configuration is. This issue tends to be a very common issue with client applns connecting to qmgr.

  4. PETE HANBURY says:

    Hi Rob,

    Can you assist. Its not clear what id takes precedence if we have a RCVR channel with both PUTAUT(CTX) & MCAUSER(low.level.account) in place ?

    Is the Context id ignored and the MCAUSER then become dominant ? i.e this is the id thats checked ?

  5. chetan says:

    Good to hear Rob.


  6. chetan says:

    Hi Rob,

    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.

    • T.Rob says:

      Hi chetan,

      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!

  7. RKPowers says:

    Hi T-Rob,

    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

    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:

    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?

    • T.Rob says:

      Hi Ray,

      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.

  8. T.Rob says:

    Hi Chetan,

    To solve this problem, place a low-privileged MCAUSER in the CLUSRCVR channel. Then use setmqaut to restrict access to the system command queue from the CLUSRCVR. You do need to allow the cluster channel to put messages onto the cluster command queue, however.

    — T.Rob

  9. chetan says:

    Hi Rob,

    I wanted to know if this is a security risk in my cluster.
    I have a queue manager A(Cluster ABC) , queue manager B(Cluster XYZ)

    queue manager A needs to talk to queue manager B

    so we add queue manager B to my Cluster ABC. but lets assume for now queue manager B belongs to more than one cluster.

    if i administer my queue manager in my cluster ABC and i use runmqsc -w option . i can administer queue manager B. which mean i can know pretty what other clusters it belongs.

    This is kind of a security risk. Am i correct?

    How can i work around this.

    security exits and Chad exits on queue manager B would help?

  10. veeru says:

    hi T-rob, has this been tested against v7.0.1, i am having the following difficulties

    Wondering any thing in access control changed in 7.0.1 thats not specified in the documentation. The scripts are working as expected against with no issues.

  11. Pingback: Deep Queue #11: Security breaches are not news?

  12. Pingback: Links from the Pauldotcom podcast

  13. Pingback: Update to MQ Security Heats Up comment thread

  14. T.Rob says:

    Correct on the model queue. All you need there should be +put +get +browse +inq +dsp.

    As for the other question, let me provide some references back to the v6.0 documentation. The comment box on this WordPress template won’t allow HTML code to embed links, so I will post this as a new blog entry.

  15. RKPowers says:

    So, if I understand correctly, we do not need or want +all for the model queue (the user will get that for the dynamic queue regardless, which is what we actually want). We do not want just anyone changing or deleting our model queue.

    And I am still confused about the +set option on the QMgr. I think what you are saying is that we need to use different security settings for different versions of WMQ. Thus, we should include +set for versions of WMQ prior to V7, and omit it for V7.

  16. T.Rob says:

    The +all on the model queue doesn’t represent a huge risk but it does allow someone to delete it or to change the settings. It only affects the model queue, not the dynamic one created from the model. Whenever a dynamic queue is created, the ID that creates it gets +all on it anyway. At the very least, I do need to make these consistent, though.

    The difference in +set was rather accidental. In the original scripts I used +allmqi for the QMgr. At v6.0 the QMgr did not have any attributes you could set with the API and so granting +allmqi just gave +connect and +inq. As of v7.0, the QMgr includes settable attributes and the API now supports the SET option. Because of this, +allmqi now also includes +set whereas with v6.0 it did not.

    These are distinct from the +setid and +setall rights. The +set right allows opening an object with SET in order to change its attributes whereas the +setid and +setall allow access to fields in the MQMD header. The requirement for the MCA to set fields in the message header has not changed from v6 to v7, just the new functionality in the QMgr.

  17. RKPowers says:

    I really appreciate this information, and implemented it when originally posted.

    I have a couple questions about the changes that were made to the scripts.

    Q1: In mqmmqi.aut, why does SYSTEM.MQEXPLORER.REPLY.MODEL now have +all when SYSTEM.DEFAULT.MODEL.QUEUE does not? And, isn’t +all too much access?

    Q2: In the original posting, in the mqmmca.aut script, the qmgr settings “+set” was included. According to the comments in that script at the time, the IBM docs said that was required. Now the comments and the command have changed to remove it. Is this a change to the IBM docs, and if so, at what version? Or, was this merely a correction?


  18. Pingback: Updated script templates

  19. T.Rob says:

    Updated templates for v7, added additional docs and comments to scripts, corrected some errors.

  20. Pingback: The Deep Queue - Episode #3: Ethical Administration

  21. T.Rob says:

    Hi Hatcher,

    Short answer – yes, but only the commands we allow.

    Remember that the channel MCAUSER has been set by the administrator, so we know what user ID will be accessing the command queue. Because the user ID cannot be spoofed (barring some exploit we don’t know about yet) then we allow it to place messages into the command queue but we enumerate the subset of commands it can execute using setmqaut rules. The command server looks in the MQMD.MsgID and finds the value from MCAUSER. It then applies our setmqaut rules to allow, for example, display of all the queues but reject requests to create or delete queues.

  22. Hatcher says:

    Question: If you allow ‘+put’ to command queue would not the person be able to inject commands and hae them processed by the command server?

Leave a Reply