Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MQ Security Overview


Published on

An introduction to the security capabilities of IBM MQ.

Presented at the WebSphere Integration User Group UK, held on 14 July 2015 at IBM Hursley.

Published in: Software
  • Be the first to comment

MQ Security Overview

  1. 1. MQ Security
  2. 2. Introduction – Typical MQ  In a Typical MQ setup there are: ● A Queue Manager ● A number of Queues and Topics ● Applications that connect to the QMGR via: ● Local Bindings ● Client connections MQCONNX Application (User4) MQCONNX Application (User2) QMGR Inter process Communications Q1..Qn
  3. 3. Introduction – Security Checks (Client)  When a user Connects via Client: CHLAUTH BlockAddr SSL/TLS CHLAUTH Mapping Security Exit MQCSP UserID/Password CHLAUTH Block User Authorisation MQ v8 Only!
  4. 4. Authorisation Introduction - Security Checks (Local)  When a user Connects via Local: MQCSP UserID/Password MQ v8 Only!
  5. 5. Authentication
  6. 6. Connection Authentication – Use case  Authentication asks clients connecting to prove they are who they say they are  Usually used in combination with authorisation to limit user's abilities  A failure to authenticate results in an error being returned. RC=2035  More information usually given to the MQ administrator in error logs  Also Authorisation events written on Distributed platforms
  7. 7. QMGR Connection Authentication – Use Case Q1..Qn Only Let Good People Connect (Bob = Good, Tim = Bad) Bob Tim I'm Bob I'm Bob PROVE IT
  8. 8. QMGR Connection Authentication – Use Case Q1..Qn Bob Tim My Password is: XXXX Errrr....
  10. 10. Connection Authentication – User repositories  User Repository?  Currently two options: –Machine OAM –LDAP server QMGR O/S User Repository (z/OS + Dist) LDAP Server (Dist only) DEFINE AUTHINFO(USE.OS) AUTHTYPE(IDPWOS) DEFINE AUTHINFO(USE.LDAP) AUTHTYPE(IDPWLDAP) CONNAME(‘ldap1(389),ldap2(389)’) LDAPUSER(‘CN=QMGR1’) LDAPPWD(‘passw0rd’) SECCOMM(YES) MQCONNX User1 + pwd1 Application (User2)
  11. 11. Assist applications that are unchanged to participate in authentication. Consists of: • Client channel security exit to insert uid/passwd • Command line tool to protect passwords in a config file Exit: mqccred Connection Authentication – Client-side security exit MQCONN Application QMgrQMA Network Communications AllQueueManagers: User=abc OPW=%^&aervrgtsr QueueManager: Name=QMA User=user1 OPW=H&^dbgfh AllQueueManagers: User=abc password=newpw QueueManager: Name=QMA User=user1 password=passw0rd Tool: runmqccred mqccred.ini mqccred.ini File permissions
  12. 12. MQ Security – Authentication via PAM  For Unix platforms  Configure authentication to go via PAM modules  Gives more flexibility in mechanisms for verification and account validation • For example, use in conjunction with nsswitch to store Unix account information in Active Directory  Requires queue manager command level to be updated • Similar to NEWFUNC on z/OS  AUTHENMD(OS|PAM) as attribute on AUTHINFO(IDPWOS) New in FP3 strmqm –e CMDLEVEL=802 QMgr
  13. 13. Authorisation
  14. 14. Authorisation – Use Case  Authorisation limits what connected users and inbound messages can do • Allowed to put messages, set context fields, subscribe to topics etc  Authority rules (ACLs) are assigned to a specific user or group.  If a user or group does not have authority to do what they are trying to do, they get blocked • Permissions apply to administrative actions and to MQI operations  Some authorisation checks are made based on the UserId in a message • The ability to set that field during MQPUT is itself controlled by a permission  On Distributed platforms, authorisations are controlled through an MQ component, OAM • On z/OS, queue manager calls external security managers such as RACF via a public interface
  15. 15. Controlling authorisations on Distributed platforms  Use the setmqaut command to make adjustments  Also have SET AUTHREC equivalent in MQSC • Client-mode runmqsc makes it easy to set ACLs on remote queue managers
  16. 16. MQ Security - Authorisation using LDAP  Fixpack 2 for Unix/Linux/i builds on LDAP authentication feature  User and group information can now be centrally located in LDAP • No need to define OS users/groups other than mqm • And "mqm" group loses a lot of its automatic power  Extended attributes on AUTHINFO/IDPWLDAP object show how to discover groups • Very similar to the authentication attributes for discovery of identities  Requires queue manager command level to be updated • Similar to NEWFUNC on z/OS  Authorities can be set for individual users • Does not use "primary groups" setmqaut –t qmgr –p "cn=User 1,ou=users,o=ibm,c=uk" +connect setmqaut –t qmgr –g "cn=Group 1,ou=groups,o=ibm,c=uk" +connect strmqm –e CMDLEVEL=801 QMgr New in FP2
  17. 17. Adding administrators  Users do not need to be in the 'mqm' group to do most MQ administration  Create ACLs for other groups instead  Explorer Wizard makes it easy • Shows commands so you can script  FP2 includes real script •
  18. 18. SSL/TLS
  19. 19. TLS – Introduction  TLS is the follow-on to SSL • These days, trying to just say TLS and not SSL!  Uses public-key techniques to protect data travelling across a network • Personal certificates, signing certificates, signing and encrypting data  SSL protocols are deprecated after all the vulnerabilities found  But many MQ attributes still include SSL in their name for historic reasons
  20. 20. TLS – Use Case QMGR Q1..Qn Bob Tim I don't know Bob's password so let's find it out by listening in! 0@;;7A//#ca £66!j:sdw) What the...?
  21. 21. CipherSpec currency  2014-2015: Security vulnerabilities with cool names • Heartbleed, POODLE, BEAST, FREAK, Bar Mitzvah, LogJam • Secure protocols as well as crypto algorithms found to have vulnerabilities  Before V8.0.0.3, 44 different CipherSpecs to choose from • SSLv3, TLSv1.0, TLSv1.2  With V8.0.0.3, subset of just 17 CipherSpecs • TLSv1.0, TLSv1.2 • Predominantly Ecliptic Curve, AES and SHA-2 based  It is possible, but not recommended, to re-enable the older CipherSpecs • Environment variable or qm.ini  Errors if you define or start a channel with a deprecated CipherSpec • Changes also made to older in-service versions of MQ More in FP3
  22. 22. Channel Authentication
  23. 23. Channel Authentication – Use Case  CHLAUTH rules are basically filters.  The rules tell the queue manager to will allow or block a connection that matches the filter  The filter can be either very specific or generic.  Types of filters: • SSL Distinguished Name (Issuer and Subject) • Client User ID • Remote Queue Manager name • IP address/Hostname (hostname was added in V8)
  24. 24. Channel Authentication – Use Case Tim Bob QMGR Q1..Qn Only Allow connections from 129.888.2.543 IP: 129.888.2.543 IP: Hello I am Bob and my password is 1234 Hello Bob!
  25. 25. Channel Authentication – Use Case Tim Bob QMGR Q1..Qn IP: 129.888.2.543 IP: 126.666.6.666 Hello I am Bob and my password is 1234 DENIED! But I did everything right!
  26. 26. Channel Authentication – Side note  Channel Authentication rules have an order of checking: • ADDRESSMAP • BLOCKADDR • SSLPEERMAP • QMGRMAP • USERMAP • BLOCKUSER  In addition if a connection matches two CHLAUTH rules where one has a specific filter and one has a generic filter then the CHLAUTH that is SPECIFIC will be used to work out what to do. • For example two ADDRESSMAP: • 1, Block where address=* • 2, Allow where address= • Connection from will be allowed through.
  27. 27. Channel Authentication  When you create a CHLAUTH rule you can specify what it should do when triggered.  The options are: • CHANNEL – Use the userid set in the channel MCAUSER for the future checks • MAP - Use the userid set in this CHLAUTH MCAUSER for the future checks • NOACCESS – Block the connection  In addition you can raise the security of the channel by setting a higher CHCKCLNT value on the channel • If a user connects to CHANNEL.1 they are required to pass valid credentials • If a user connects to CHANNEL.2 they don't have to pass valid credentials.
  28. 28. Channel Authentication – MQ Explorer  To create a new Channel Authentication rule right click on the channel authentication folder and select “New=>Channel Authentication Record...”
  29. 29. Channel Authentication – MQ Explorer  Next follow the steps to set up your channel authentication rule.  In the Channel profile screen you can put the name of a channel or a generic name • For example: “INCOMING.CHANNEL” or “System.*”  The next screens allow you to put the filter rules in for the CHLAUTH rule which will cause the rule to trigger • In ADDRESSMAP rule putting address=* will cause the rule to trigger for all addresses
  30. 30. Channel Authentication – Command Line  CHLAUTH rules are added and removed using the SET command in RUNMQSC – The difference between adding and removing is what ACTION(x) is set to
  31. 31. AMS
  32. 32. Advanced Message Security  AMS is an end-to-end security model, messages stay signed/encrypted through the whole lifetime of a message • Certain types of data fall under standards compliance that requires encryption whilst 'at rest' as well as in transit - e.g. credit card numbers (PCI), healthcare (HIPAA)  AMS allows messages to be selectively encrypted so that even MQ administrators cannot see the cleartext content without the right certificate  You create policies for a queue that describe how messages should be protected when applications put or get messages using that queue  The policies describe whether messages should be signed or signed + encrypted. • Signing and encryption uses digital certificates, such as those used by TLS
  33. 33. Recommended reading  Lots of MQ security articles on developerworks  MQ v8 information: d_mq_v8_information?lang=en  MQ v8 Security Demo:
  34. 34. Bob Tim Questions?