MQ Security

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

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!

Authorisation

Introduction - Security Checks (Local)

When a user Connects via Local:

MQCSP UserID/Password

MQ v8 Only!

Authentication

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

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

QMGR

Connection Authentication – Use Case

Q1..Qn

Bob

Tim

My Password is: XXXX

Errrr....

Connection Authentication – Setting up

CHCK…

NONE

OPTIONAL

REQUIRED

REQDADM MQCONNX

Application (User4)

MQCONNX

Application (User2)

QMGR

Inter process

Communications

DEFINE AUTHINFO(USE.PW) AUTHTYPE(xxxxxx)

CHCKLOCL(OPTIONAL)

CHCKCLNT(REQUIRED)

ALTER QMGR CONNAUTH(USE.PW)

REFRESH SECURITY TYPE(CONNAUTH)

MQRC_NOT_AUTHORIZED (2035)

MQRC_NONE (0) User

Repository

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)

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

QM

gr

QM

A

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

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

Authorisation

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

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

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

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 • amqauthg.sh

SSL/TLS

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

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...?

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

Channel Authentication

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)

Channel Authentication – Use Case

Tim

Bob

QMGR

Q1..Qn

Only Allow connections from

129.888.2.543

IP: 129.888.2.543

IP: 126.66.6.66

Hello I am Bob and my password is 1234

Hello Bob!

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!

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=129.12.9.9

• Connection from 129.12.9.9 will be allowed through.

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.

Channel Authentication – MQ Explorer

To create a new Channel Authentication rule right click on the channel

authentication folder and select “New=>Channel Authentication Record...”

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

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

AMS

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

Recommended reading

Lots of MQ security articles on developerworks

MQ v8 information:

https://www.ibm.com/developerworks/community/blogs/messaging/entry/where_can_i_fin

d_mq_v8_information?lang=en

MQ v8 Security Demo:

https://www.youtube.com/watch?v=0aKamUTS4rs&feature=youtu.be

Bob Tim

Questions?