As the MQ Technical Conference V2.0.1.8 t-shirts said “MQAdmin: the superhero of middleware messaging!“. Since, you are a “superhero”, you have secured your MQ environment. You have implemented CHLAUTH and/or CONNAUTH features in IBM MQ. So, give yourself a pat on the back, a gold star or have another cold one on you because you deserve it – you’re the middleware superhero who has implemented security for IBM MQ.
Question: How do you know it is secure? Seriously! MQ does not tell you it is secure. If someone connects with a valid UserId and Password but shouldn’t have connected to the production queue manager, the “superhero” will never know. Why? Because MQ doesn’t care about successful connections.
On the other hand, a good security auditor will care. They will want to know who is connecting – both successfully and unsuccessfully. If your company’s security auditor decided that your company’s MQ environment needed a security review, you can extract the error messages related to unsuccessful login attempts from the queue manager’s AMQERR01.LOG file (which may only hold the last few hours of information) but that is it. There is no information about successful connections.
Now some people will say, I’ll just issue the MQSC command to display the connections. Sure, that will let you see who is currently connected to the queue manager but it will not tell you who was connected 5 minutes ago or 1 hour ago or at 3:00AM. You will have absolutely no clue that a rogue user previously successfully connected, get and/or put messages to 1 or more queues, then disconnected.
So, still feeling “super”?
Around a year ago, a couple of Capitalware’s MQ Authenticate User Security Exit (MQAUSX) customers said that their management wanted them to start to use CHLAUTH and CONNAUTH which are included free with MQ rather than continue to use MQAUSX and pay for support. I would point out that MQAUSX has far more features and more robust features than what CHLAUTH and CONNAUTH offer but alas management only looks at the price and free is better than paying.
The MQAdmins came back to me and said that they missed having the MQAUSX logging of connection attempts. Since, their management won’t pay for MQAUSX, they have no way to verify that connections were legitimate. I suggested to them that they use MQ Auditor but they only wanted to track connections not everything in MQ and others said they need it on z/OS (mainframe). Since, MQ Auditor is an MQ API Exit, IBM does not support API Exits on z/OS, that was a no go.
I decided to create MQ Channel Connection Inspector (MQCCI). MQCCI uses a MQ Channel Security Exit like MQAUSX. A channel security exit is ONLY invoked/called by the queue manager’s MCA (Message Channel Agent) for MQCONN/X and MQDISC API calls (so it is very light-weight) and channel security exit is available on z/OS.
I decided to use the audit record format from MQ Auditor for MQCCI. And like MQ Auditor, MQCCI can write the audit information to either a file or to a queue. For each connection attempt, MQCCI will output 1 plain text CSV (Comma Separate Value) line.
If the MQAdmin uses the default values for MQCCI, this is what the audit record would look like for a connection attempt:
2018/09/14 18:07:00.654884, CONN, Tag=F4Evlx0T6ComjD20, CD_QMgrName=MQWT1, CD_ChannelName=TEST.CHL, CD_ConnectionName=127.0.0.1, , CD_ShortConnectionName=127.0.0.1, CD_MaxMsgLength=4194304, CD_PutAuthority=MQPA_DEFAULT, CD_MCAUserIdentifier=roger, CD_RemoteUserIdentifier=roger, CD_RemotePassword_Length=0, CD_SSLCipherSpec=, CD_SSLClientAuth=MQSCA_REQUIRED, CD_CertificateLabel=, CXP_PartnerName=roger, CXP_SSLCertUserid=, CXP_SecurityParms_AuthenticationType=MQCSP_AUTH_USER_ID_AND_PWD, CXP_SecurityParms_UserId=roger, CXP_SecurityParms_Password_Length=8, CXP_SharingConversations=TRUE, CXP_MCAUserSource=MQUSRC_MAP, CXP_RemoteProduct=MQJB, CXP_RemoteVersion=0800,
Optionally, the MQAdmin can select to have the MQDISC audit records as well. And this it what it would look like:
2018/09/14 18:07:02.161509, DISC, Tag=F4Evlx0T6ComjD20, CD_QMgrName=MQWT1, CD_ChannelName=TEST.CHL, CD_ConnectionName=127.0.0.1, Duration=1.506625,
For the default MQCD and MQCXP fields outputted by MQCCI, I tried to select the most relevant fields but the MQAdmin can have MQCCI outputted any field from the MQCD and MQCXP structures.
Here is an interesting footnote but not related to a security audit. Generally speaking, before an application is deployed, the MQAdmin will ask the application team “if the application connects and stays connected to the queue manager“. The application team will say “Yes“. But how do you verify this statement?
With MQCCI, you can review the audit file and see if the application only connected once or did it “connect then disconnect”, “connect then disconnect”, “connect then disconnect”, etc..
Not only is MQCCI good for security audits but it can also be used to identify poorly written applications.
- MQCCI is available for AIX, HP-UX, IBM i (OS/400), Linux (x86, x86_64, Power and System z), Solaris (SPARC and x86_64) and Windows.
- MQCCI for z/OS is available for z/OS v1.4 or higher.
For more information about MQCCI, please go to:
https://www.capitalware.com/mqcci_overview.html or MQCCI for z/OS
Note: We offer free a 60-day trial of MQCCI and MQCCI for z/OS which includes free support. If you interesting in trying it out, please send an email to support@capitalware.com to request a trial of it.
Regards,
Roger Lacroix
Capitalware Inc.
