It’s a commonly held view that MQSeries is not a secure product and that to install it in your network infrastructure is to give hackers a free reign. In this article I’ll demonstrate that this isn’t necessarily so.
Security is a general term that covers such tasks as sender and receiver authentication, encryption and privacy, non-repudiation, and message integrity and data authentication.
When communications between companies occurs, MACs, digital signatures, and public key encryption may be employed to enforce security, perhaps by means of third-party products, such as Baltimore Secure MQ from Baltimore. However, many companies consider that, when it comes to communication within an enterprise, such measures are not required as all machines in their infrastructure are managed by administrators whom they trust. All that’s required is to provide administrators with the means to prevent unauthorised users from accessing the network and creating messages, while still providing access to authorised users.
This can be done using third-party products, many of which have the potential to secure communications completely. Nevertheless, there is a lot that can be achieved using just the security mechanisms provided by MQSeries itself – that is, using RACF on MVS and the Object Authority Manager (OAM) on distributed platforms.
This article covers the policies that a company would need to put in place and the configuration that administrators would need to implement in order to establish an acceptable level of security in an environment where administrators are trusted but users are not.
Consider the following example:
For a number of years a large company has successfully used techniques such as file transfer (FTP) to carry out point-to-point communication. However, in order to improve speed of development they decide to move to an MQSeries-based infrastructure, also deciding to use a central hub managed by a trusted group, as this yields benefits in manageability and allows new connections to be added quickly.
Most of the machines are based in a secure machine room (while it’s possible to log on to the machines from outside the room, a discussion of how to secure this type of access is beyond the scope of this article). Each business unit owns one machine. Business units don’t trust users (who could be disgruntled employees), and they don’t trust administrators of machines belonging to other business units, though they do trust their own administrators. Most security problems, such as ‘sniffers’ on the communication lines, were addressed when FTP was set up (possible solutions include using encryption at the communications layer, splitting SNA packets into so many parts that they are virtually impossible to read, and using security calls within applications themselves).
Consider a situation in which A and B need to communicate with each other using MQSeries, as do C and D (see Figure 1). Most of the security issues that exist in this environment also apply to FTP, though a major new one is introduced.
With the environment shown above, if business A decides that it needs to talk to business D, the infrastructure is already in place and only the application development needs to be done. This is a very strong reason for using MQSeries and a hub environment. However, it also introduces the problem that an unauthorised person on A could send a message to D.
In order to secure the end-to-end connection, including preventing the generation of unauthorised messages, it is necessary to carry out the measures detailed in this article.
COMMUNICATIONS LAYER SECURITY
Firstly, security needs to be set up at the level of the communication layer. SNA bind or session-level security can be used to ensure that, when an SNA bind request comes from A, the hub knows that the request really does originate at A. This is a default with most communications packages (but not ones from Tandem) and involves providing the same password at each end. Obviously the password must be kept secret and should be accessible only by the machines’ administrators. Something similar can be done for TCP/IP using secure domain units or some form of Virtual Private Network.
CHANNEL INITIATION SECURITY
We’ve now ensured that no boxes are connected to the hub that shouldn’t be connected to it. However, it’s still possible for a user on A to define a queue manager called C and a channel on A called C.TO.HUB (for example, by knowing the naming convention or by querying the hub’s command server), and then connect to the hub by impersonating C and having messages routed to D.
If the channel is a sender/receiver channel, the only way around this is to use a security exit provided by a third-party product (such as Baltimore, mentioned earlier). However, if A is a secure machine, users won’t have the authority necessary to add these definitions to the system. An alternative is to use requester/sender channels. This is similar to a call-back system: the hub acts as a requester and thus needs to initiate the conversation. It calls out to the known LU/IP address stating that it wants to start a channel. A, acting as the sender, would then initiate the channel back to the hub. If A were to try to start a channel to the wrong requester, the request would not be accepted. Similarly D, acting as a requester, could initiate a conversation asking the hub, as a sender, to call it back. As the hub’s sender channel contains D’s CONNAME and calls it back the most that A could do in this set-up is to get the hub to call D.
So now we have a system where we can be confident that all messages coming to the hub on any channel are from the machine that they should be from.
The hub is merely a queue manager, looking after transmission queues and running the associated channels. Each transmission queue is named after the queue manager that it points to. The next problem, as mentioned above, is that a user on A could, by default, do an MQPUT specifying as its target the queue manager of D. The message would be put on A’s default transmission queue (to the hub); when it reaches the hub, it would automatically be put on transmission queue D, and thus get to a destination that it shouldn’t be able to reach.
The way around this is to specify the MCAUSER parameter on the receiver/requester channel definitions. By default the inbound channel at the hub puts messages on its target transmission queue using the userid running the channel. This userid has full access to put messages on all queues. However, if you change the channel’s MCAUSER parameter, the message will be put on the queue using the userid specified by the parameter.
So, define one userid for each inbound channel on the hub. For example, define a userid called A for the channel from A, a userid called C for the channel from C, etc. Alter the inbound channels to put messages on queues using their corresponding userid – for example:
ALTER CHL(A.TO.HUB) CHLTYPE(RQSTR) TRPTYPE(LU62) MCAUSER(A)
ALTER CHL(C.TO.HUB) CHLTYPE(RQSTR) TRPTYPE(LU62) MCAUSER(C)
Next set the permissions on the hub’s transmission queues to accept only messages from authorised channels. How you do this depends on your set-up – on distributed platforms, use the following commands:
SETMQAUT –M HUB –T QMGR –P A +CONNECT +SETALL
SETMQAUT –M HUB –T QMGR –P C +CONNECT +SETALL
SETMQAUT –M HUB –T Q –N B –P A +PUT +SETALL
SETMQAUT –M HUB –T Q –N D –P C +PUT +SETALL
If you use RACF, then the following commands are needed:
RDEFINE MQQUEUE HUB.B UACC(NONE)
PERMIT HUB.B CLASS(MQQUEUE) ID(A) ACCESS(UPDATE)
RDEFINE MQQUEUE HUB.D UACC(NONE)
PERMIT HUB.D CLASS(MQQUEUE) ID(B) ACCESS(UPDATE)
TARGET QUEUE SECURITY
So now B and D can be confident that all the messages they receive are from authorised queue managers. The next problem is to make sure that the right messages go to the right queues. For example, user UserX on A might be allowed to send messages to queue QueueQ on B, and user UserY on A might be allowed to send messages to queue QueueR on B (see Figure 2). However, we need to ensure that UserX cannot send messages to QueueR. To do so without either using security exits or changing applications, business B needs to trust A’s administrator (but not C’s, etc). Also a system-wide naming convention of userids needs to be enforced.
By default, when a user on A sends a message, the user’s userid is put in the USERID field of the message descriptor. The user is not allowed to change this. Also, by default the inbound channel at the receiver (for instance, B) puts messages on its target queue using the userid that’s used to run the channel. This userid has sufficient access rights to put messages on all queues. If you change the PUTAUT parameter of the channel from PUTAUT(DEF) to PUTAUT(CTX), messages are placed on the queue using the authority of the userid specified in the message descriptor.
So queues can now be secured by defining userids on the receiving machines that have the same names as the userids on the sending machines. The receiving userids do not need authority to log on. So, in this example:
Define two users, UserX and UserY, on B.
ALTER CHL(HUB.TO.B) CHLTYPE(RQSTR) TRPTYPE(LU62) PUTAUT(CTX)
On distributed platforms, issue the following command:
SETMQAUT –M B –T QMGR –P UserX +CONNECT
SETMQAUT –M B –T Q –N QueueQ –P UserX +PUT +SETALL
SETMQAUT –M B –T QMGR –P UserY +CONNECT
SETMQAUT –M B –T Q –N QueueR –P UserY +PUT +SETALL
If you use RACF, the following commands are needed (assuming MQM runs the channel):
RDEFINE MQQUEUE B.QueueQ UACC(NONE)
PERMIT B.QueueQ CLASS(MQQUEUE) ID(MQM) ACCESS(UPDATE)
PERMIT B.QueueQ CLASS(MQQUEUE) ID(UserX) ACCESS(UPDATE)
RDEFINE MQQUEUE B.QueueR UACC(NONE)
PERMIT B.QueueR CLASS(MQQUEUE) ID(MQM) ACCESS(UPDATE)
PERMIT B.QueueR CLASS(MQQUEUE) ID(UserY) ACCESS(UPDATE)
As mentioned previously, security is a bit more complex on Tandem systems. On Tandem, the ‘userid’ in the message descriptor is actually a groupid. For the above to work when a Tandem system is the receiver, it is necessary to use a group that’s defined and authorised with the same name as the sending userid. When a Tandem system is the sender, the receiver needs a userid defined and authorised with the same name as the sending group.
LOCAL QUEUE SECURITY AT THE SENDER
If users on the sender machine do not trust one another, some additional work is necessary to set up security.
If QREMOTE queues are not used, and users specify the target queue manager in the MQPUT call, then messages from UserX and UserY on A are put directly on the transmission queue and there is no way for MQSeries to stop them specifying one another’s target queues. It is also possible, when the channel is not running, for them to remove one another’s messages before the messages are sent.
The best way to solve this problem is to restrict access to transmission queues (this is the default) and to allow users to put messages only on QREMOTE queues that point to the target queues. Using this approach, a secure structure can be set up such that UserX and UserY cannot put messages on one another’s queues.
For instance, using RUNMQSC, enter the following definitions:
DEFINE QR(TO.Q.ON.B) RNAME(QueueQ) RQMNAME(B)
DEFINE QR(TO.R.ON.B) RNAME(QueueR) RQMNAME(B)
The commands below are the ones to use on distributed platforms.
SETMQAUT –M A –T QMGR –P UserX +CONNECT
SETMQAUT –M A –T QMGR –P UserY +CONNECT
SETMQAUT –M A –T Q –N TO.Q.ON.B –P UserX +PUT
SETMQAUT –M A –T Q –N TO.R.ON.B –P UserY +PUT
While the ones below are for use with RACF.
PERMIT A.BATCH CLASS(MQCONN) ID(UserX) ACCESS(READ)
PERMIT A.BATCH CLASS(MQCONN) ID(UserY) ACCESS(READ)
RDEFINE MQQUEUE A.TO.Q.ON.B UACC(NONE)
RDEFINE MQQUEUE A.TO.R.ON.B UACC(NONE)
PERMIT A.TO.Q.ON.B CLASS(MQQUEUE) ID(UserX) ACCESS(UPDATE)
PERMIT A.TO.R.ON.B CLASS(MQQUEUE) ID(UserY) ACCESS(UPDATE)
However, if you are happy to allow applications to write to the transmission queue, you could use either the following commands on distributed platforms:
SETMQAUT –M A –T Q –N B –P UserX +PUT
SETMQAUT –M A –T Q –N B –P UserY +PUT
or this one with RACF:
RDEFINE MQQUEUE A.B UACC(UPDATE)
LOCAL QUEUE SECURITY AT THE RECEIVER
If users on the receiving machine do not trust one another, then it’s necessary to set up some additional security.
Say UserQ is able to read messages on queue QueueQ and UserR is able to read messages on queue QueueR. If the users are not considered trustworthy, then one needs to guard against the possibility that UserR may put a message on queue QueueQ and for UserQ to receive it believing it to have come from A. Similarly UserR could get messages from queue QueueQ before UserQ gets them. To prevent this, it is necessary to run the following OAM commands:
SETMQAUT –M B –T QMGR –P UserQ +CONNECT
SETMQAUT –M B –T QMGR –P UserR +CONNECT
SETMQAUT –M B –T Q –N QueueQ –P UserQ +GET
SETMQAUT –M B –T Q –N QueueR –P UserR +GET
With RACF, the following commands would be needed:
PERMIT B.BATCH CLASS(MQCONN) ID(UserQ) ACCESS(READ)
PERMIT B.BATCH CLASS(MQCONN) ID(UserR) ACCESS(READ)
RDEFINE MQQUEUE B.QueueQ UACC(NONE)
RDEFINE MQQUEUE B.QueueR UACC(NONE)
PERMIT B.QueueQ CLASS(MQQUEUE) ID(UserQ) ACCESS(UPDATE)
PERMIT B.QueueR CLASS(MQQUEUE) ID(UserR) ACCESS(UPDATE)
Note that on MVS a problem still remains. UserQ (or perhaps a member of the same group) can run an application that puts messages on queue QueueQ that the main UserQ application then reads off in the belief that they came from A. On distributed platforms, the OAM command SETMQAUT can be used to ensure that UserQ can get messages from a queue but not put them on it. RACF does not have this facility. A user is either able to both get and put messages on a queue or neither. One solution to this is to use ‘alias’ queues.
DEFINE QA(ACCESS.BY.USERQ) TARGQ(QueueQ) PUT(DISABLED)
RACF could then be used to be used to prevent UserQ from directly accessing queue QueueQ while giving the user full access to the ACCESS.BY.USERQ alias queue. The PUT(DISABLED) attribute ensures that the user can’t put messages on the queue. Note that the PUT(DISABLED) attribute could not have been used directly on queue QueueQ, as this would have stopped the channel from being able to write messages.
While this method works, it’s a bit of overkill. As it’s common in MVS for a user to have read/write access to a dataset, allowing them also to have read/write access to a queue is usually seen as a natural extension. Another consideration is that, in MVS, it’s less likely that the same userid is used to run different applications.
Note that, on all platforms, such measures are unnecessary if the administrator has secured the machine so that users cannot add or run their own applications.
SJG Consulting Ltd (UK) © S Garforth 1999
The following comments have been made by a reader more recently and need to be incorporated into the article:
The statement is made that “If A were to try to start a channel to the wrong requester, the request would not be accepted.” This is not true. In the diagram, A, B, C or D could all start the same requestor on the hub (although not more than one at a time).
Also, if you give the MCAUSER +setall authority and set PUTAUT(CTX), what is to prevent a malicious user on A from sending messages as mqm to the command server (or any arbitrary queue) at the hub or any of the other machines? Each company has to trust the MQ administrators at all the other companies using that hub. That’s a lot to ask.
You might want to add a note in the document for TCP/IP users. It’s good practice to have the users coming in on different ports from each other and from the one you use internally. If, for example, you use 1414 internally and A, B, C and D use 1415, 1416, 1417 and 1418 respectively you gain a lot of control. You can stop all external traffic while allowing internal traffic to continue by shutting down listeners on all ports other than 1414. Or you can stop traffic from one business partner without affecting the others.
There are a bunch of other measures that can and probably should be taken to secure a hub QMgr that talks to several different external partners. These include adjusting the channel retry to enforce some flood control, disabling QMgr resolution by not naming XMit queues after the QMgr they serve and SVR channel behavior which can be exploited in a hub environment.
SJG Consulting Ltd (UK) © S Garforth 2003