IBM WebSphere MQ Channel Access: Delete or Block?
Marcela Adan 100000THF9 email@example.com | | Tags:  messaging channel security access middleware websphere mq
0 Comments | 3,959 Visits
By Craig Both
WebSphere MQ Software Engineer
IBM Hursley Laboratory
As a level 3 support engineer for WebSphere MQ, the first customer problem I picked up has stuck with me. It was my first foray into providing customer service for the product I'd been working on testing for the best part of 10 years. It was my first customer service success. I gave my response and the customer was happy. What more could I want? Having now been in level 3 support for 20 months, I look back and, despite it being my first customer service success, I would handle it very differently. I solved what the customer was trying to achieve, but I didn't consider why they wanted to achieve it.
They were a security conscious company, and as a result, out of fear of rogue channel usage, they decided to delete the default channel definitions on their queue manager. Their rationale: they're default channels, everyone that uses WebSphere MQ knows we have them, we don't want people connecting to them.
Seems perfectly reasonable to me, except for the following...try this...
Create a queue manager (TRASH_QM) that you don’t mind trashing, at any release. Using runmqsc delete one of the default channel objects, say SYSTEM.DEF.SVRCONN, using the command delete chl(SYSTEM.DEF.SVRCONN). Now try to create your own SVRCONN type channel (MY.TRASH.SVRCONN) using the command def chl(MY.TRASH.SVRCONN) chltype(SVRCONN). The command will fail, with the reason that SYSTEM.DEF.SVRCONN doesn’t exist. What does SYSTEM.DEF.SVRCONN have to do with me creating a new channel?
This is the problem they hit...they deleted their default channels, but then they could not create any new channels! At least they did not have to worry about any rogue connections now! This fails because for any attributes you don't supply on their define channel command, MQ refers to the default objects to fill those parts in. So of course, the customer has one get out route...each time they define a channel they can specify every single channel attribute. For example....
DEF CHL(MY.TRASH.SVRCONN) CHLTYPE(SVRCONN) COMPHDR(NONE) COMPMSG(NONE) DESCR(' ') DISCINT(300) HBINT(30) KAINT(AUTO) MAXINST(9999999) MAXMSGL(99999999) MONCHL(QMGR) MCAUSER('nobody') MAXINSTC(99999999) RCVDATA(' ') RCVEXIT(' ') SCYDATA(' ') SCYEXIT(' ') SENDDATA(' ') SENDEXIT(' ') SHARECNV(10) SSLCAUTH(OPTIONAL) SSLCIPH(' ') SSLPEER(' ') TRPTYPE(TCP)
An administrative nightmare to say the least. But it works.
WebSphere MQ 7.1 introduced channel authentication records, designed to allow granular control over access to channels. This sounds exactly like what my first customer was trying to do! Basically they wanted to block access to any channels that were named SYSTEM.*. One of the rules that you get out of the box with 7.1 is precisely that rule...All access to the queue manager over any channel called SYSTEM.* is blocked. No matter who you are, no matter where you're coming from, the gates are closed.
After 20 months of customer service work, if I could go back, I wouldn't just give that customer the answer to their question, I'd take the time to understand what their requirement was and provide them with a better solution.
Being part of a team that wrote the IBM Redbooks publication IBM WebSphere MQ V7.1 and V7.5 Features and Enhancements, made me think about why WebSphere MQ is providing these features in the new releases, who are they for, and what are they for. Who would have thought that it would land me back thinking about my first success in customer service?
So delete or block? NEVER delete! If you're not using WebSphere MQ V7.1 set your default SVRCONN/CLNTCONN channels to use MCAUSER('nobody') and with WebSphere MQ 7.1 and above, block, block, block with channel access control!
Other blog posts from the team:
How to write a WebSphere MQ book in 4 weeks (and survive to tell about it!) by Craig Both and Alex Ross