End to End Message Security using IBM® MQ

 View Only
Wed October 13, 2021 05:59 PM

The Objective is to demonstrate the implementation of IBM MQ built-in Security features in an Integrated Test Case Scenario which can be taken as a template for Large Scale Implementation at Enterprise Level.


Skill Level: Advanced

Knowledge on MQ Client Configuration using CCDT, MQ Cluster, Advanced Security features like OAM, SSL/TLS, CHLAUTH & AMS.

Ingredients

IBM MQ Software: version 7.5 & Above.

Platform: Linux

*** AMS Package have additional Licensing requirement on top of IBM MQ base package ***

Concepts: MQ Cluster, MQ Client Configuration using CCDT file (AMQCLCHL.TAB), SSL Certificate Management & its implementation on Cluster & Client Connection Channels, Object Authority Manager (OAM), Channel Auth Rules (CHLAUTH) & Advance Message Security (AMS).


Introduction:

The Objective of this article is to demonstrate the simultaneous implementation of IBM® MQ Security features like OAM, SSL, AMS & CHLAUTH in an Integrated Test Case Scenario which can be taken as a template for Large Scale Implementation at Enterprise Level. The specific configuration of Advanced Message Security (AMS) feature is required to meet the regulatory requirement of PCI DSS (Payment Card Industry Data Security Standard) which mandates business critial information like Credit / Debit Cards & other important Bank transactions to be secured & encrypted.

1-6

                                                   The above diagram depicts our Test Case Scenario at High Level

As per the above diagram, Application user Alice puts a messages through SSL/TLS enabled Client Connection Channel into an AMS enabled Cluster Queue Alias (AMS_A) defined under TEST1 Qmgr. This Q Alias points to AMS enabled Cluster Local Queue (AMS_E) defined under TEST2 Qmgr through a secure Cluster Channel. Once the business critical message(s) reaches Q Local (AMS_E), it will be encrypted using pre-defined AMS rules set at the Queue Level. Only authorized Application user Bob should be able to retrieve the the data from the Queue (AMS_E). Going by this configuration, even ‘mqm’ or ‘root’ user does Not have the default authority to read / browse the message from Queue (AMS_E) without setting explicit AMS security rules!

Hence, highly sensitive Customer data like Credit / Debit Card information is secured from the point it originates from Application user Alice till it is consumed by Application user Bob from the other end of the secure MQ network.

From Implementation Perspective, we have created & configured the following components:

1. Created a MQ Cluster called ‘POC’ having 3 Qmgrs TEST(1,2,3) where TEST(1,2) are Full Repository (FR) Qmgrs & TEST3 is the Partial Repository(PR) Qmgr.

2. Created an Internal Certificate Authority (CA) for signing Certificate Requests for MQ Clients & Cluster Qmgrs.

3. Configured SSL/TLS at Cluster Channels using in-house Certificate Authority (CA)

4. Created a dedicated Queue Manager CCDT for Administration & Maintenance of Client Connection Channel file (CCDT) called AMQCLCHL.TAB.

5. Configured MQ Clients (Alice & Bob) connectivity with Qmgrs using CCDT.

6. Configured Channel Authentication (CHLAUTH) rules to Allow / Block incoming requests from MQ Client users Alice & Bob.

7. Created & Configured have 2 AMS enabled Cluster Queues AMS_A (QA) defined under TEST1 & AMS_E (QL) define under TEST2 Qmgrs respectively.

8. AMS Keystores are created using Self-Signed Certificates of Alice & Bob.

With these Security Configurations in place, this Test Case demonstrate a comprehensive security solution by making use of most of the built-in IBM MQ Security features like OAM, SSL/TLS, CHLAUTH & AMS to achieve End to End Message Security Solution which includes Authentication, Authorization, Encryption & Digital Signature. Thus, MQ messages are secured while in transit through SSL/TLS enabled MQ Channels as well as while sitting in the AMS enabled Local Queue before being processed by receiving Application.

Step-by-step

  1. MQ Configuration Items

    This entire article on IBM MQ Security Solution can be broken down into 4 Major parts:

    1. Creation & Configuration of MQ Cluster with SSL/TLS Enabled Channels.

    2. Configuration of SSL/TLS enabled MQ Client Connectivity with Cluster Queue Managers using CCDT file AMQCLCHL.TAB.

    3. Setting up the CHLAUTH rules at Channel Level for enhanced Security.

    4. Implementation of AMS Security Rules at Queue Level.

    ####################################

    Internal Certificate Authority (CA): /home/mqm/CA

    TEST1 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST1/ssl
    TEST2 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST2/ssl
    TEST3 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST3/ssl

    Alice’s home directory: /home/alice/
    Alice’s SSL Keystore: /home/alice/keystore

    Bob’s home directory: /home/bob
    Bob’s SSL Keystore: /home/bob/keystore

    CCDT File: /home/CCDT/AMQCLCHL.TAB    ==> Centralized Location to be used by both Alice & Bob
    CCDT File Administration: /var/mqm/qmgrs/CCDT/@ipcc/AMQCLCHL.TAB

    #####################################################

  2. Define Queue Managers

    This is the first part of the exercise wherein we are going to create 3 Qmgrs & define the Listener Process for each.

    Create TEST1 Qmgr
    #################
    crtmqm TEST1
    DEFINE LISTENER(TEST1.LISTENER) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR)

    Create TEST2 Qmgr
    #################
    crtmqm TEST2
    DEFINE LISTENER(TEST2.LISTENER) TRPTYPE(TCP) PORT(1415) CONTROL(QMGR)

    Create TEST3 Qmgr
    #################
    crtmqm TEST3
    DEFINE LISTENER(TEST3.LISTENER) TRPTYPE(TCP) PORT(1416) CONTROL(QMGR)

    Checkpoint Test: Stop / Start the Queue Managers & verify if the Listener Programs are running using the command:

    ps -ef | grep runmqlsr

    Observation:

    1-1
  3. Create a MQ Cluster

    In this Section, we are going to create a Cluster called POC & make 3 Qmgrs part of the Cluster. Configured TEST1 & TEST2 as the Full Repository (FR) & TEST3 as the Partial Repository (PR) Qmgrs. The two FR Qmgrs should be fully interconnected using explicitly defined Cluster Sender/Receiver Channel pairs.On the other hand, the PR Qmgr must be fully interconnected with any one of the FR Qmgr (In this Case, TEST1 Qmgr).

    runmqsc TEST1(FR)
    #################
    ALTER QMGR REPOS(POC)
    DEFINE CHANNEL(TO.TEST1) CHLTYPE(CLUSRCVR) CONNAME(‘127.0.0.1(1414)’) CLUsTER(POC)
    DEFINE CHANNEL(TO.TEST2) CHLTYPE(CLUSSDR) CONNAME(‘127.0.0.1(1415)’) CLUSTER(POC)
    DEFINE QA(AMS_A) TARGET(AMS_E) CLUSTER(POC)

    runmqsc TEST2(FR)
    #################
    ALTER QMGR REPOS(POC)
    DEFINE CHANNEL(TO.TEST2) CHLTYPE(CLUSRCVR) CONNAME(‘127.0.0.1(1415)’) CLUSTER(POC)
    DEFINE CHANNEL(TO.TEST1) CHLTYPE(CLUSSDR) CONNAME(‘127.0.0.1(1414)’) CLUSTER(POC)
    DEFINE QL(AMS_E) CLUSTER(POC)

    runmqsc TEST3(PR)
    #################
    DEFINE CHANNEL(TO.TEST3) CHLTYPE(CLUSRCVR) CONNAME(‘127.0.0.1(1416)’) CLUSTER(POC)
    DEFINE CHANNEL(TO.TEST1) CHLTYPE(CLUSSDR) CONNAME(‘127.0.0.1(1414)’) CLUSTER(POC)

    *** Explicitly defined Cluster Sender Channel to FR Qmgr TEST1 ***

    Note: Created a Clustered QAlias (AMS_A) under TEST1 Queue Manager whose target Q is Clustered Local Q (AMS_E) defined under TEST2 Qmgr.

    Checkpoint Test: Verify if the Cluster Sender/Receiver Channels are running. Put a sample test message into the Alias Q (AMS_A) & see if the message is getting collected into the Local Q (AMS_E) using the MQ utility programs amqsput & amqsget.

     

  4. Create Certificate Authority (CA)

    In this Step, we are going to create the CA’s Keystore, generate & extract the Self-Signed Public Certificate (ssl_ca.cer) which acts as the Root CA for distribution among the 3 Queue Managers as well as to Applications users Alice & Bob in later Steps. (Create CA using ‘mqm’ ID)

    Create the keystore for CA (/home/mqm/CA)
    #######################################
    1. runmqckm -keydb -create -db SSL_CA -pw Passw0rd -type cms -expire 365 -stash

    Create Self Signed CA Certificate
    #############################
    2. runmqckm -cert -create -db SSL_CA.kdb -pw Passw0rd -label ssl_ca -dn “CN=SSL CA,O=IBM,C=China” -expire 365

    List Certificate under CA’s Keystore
    ################################
    3. runmqckm -cert -list -db SSL_CA.kdb -pw Passw0rd

    Extract Public (Self Signed) CA Certificate
    ######################################
    4. runmqckm -cert -extract -db SSL_CA.kdb -pw Passw0rd -label ssl_ca -target ssl_ca.cer -format ascii

    Observation:

    2-1

     

  5. Secure MQ Cluster using SSL

    Creation of Keystores, CSR files & Digitally Signed by Internal CA for 3 Qmgrs TEST(1,2.3)

    In the subsequent Steps mentioned below, we are going to create the Keystores for all 3 Queue Manager (TEST1,2,3), generate the CSR (Certificate Request) files & get it signed by CA. Once these 3 steps are completed, we will Add the Root CA Certificate (ssl_ca.cer) into the Queue Manager’s keystore along with Receiving the CA Signed certificates (e.g: test1.cer) into respective Qmgr’s key-repositories. After that, we have to alter the SSLKEYR parameter of the QMGRs to point to correct keystores. Then define the secure Cluster Receiver channel & select any TLS Cipher Spec algorithm.

    Note: At this point, we are NOT Defining the SSL enabled Cluster Sender Channel.

    Create the keystore for TEST1 Qmgr (/var/mqm/qmgrs/TEST1/ssl)
    #######################################################
    1. runmqckm -keydb -create -db TEST1 -pw Passw0rd -type cms -expire 365 -stash

    Create a Certificate Request for TEST1
    ###################################
    2. runmqckm -certreq -create -db TEST1.kdb -pw Passw0rd -label ibmwebspheremqtest1 -dn “CN=TEST1 Queue Manager,O=IBM,C=India” -file test1.req

    Sign TEST1’s Certificate using CA (/home/mqm/CA)
    ##########################################
    3. runmqckm -cert -sign -file test1.req -db SSL_CA.kdb -pw Passw0rd -label ssl_ca -target test1.cer -format ascii -expire 364

    ADD CA’s Public certificate into TEST1’s Keystore
    ###########################################
    4. runmqckm -cert -add -db TEST1.kdb -pw Passw0rd -label ssl_ca -file ssl_ca.cer -format ascii -trust enable

    RECEIVE the CA Signed Certificate into TEST1’s Keystore
    ##################################################
    5. runmqckm -cert -receive -db TEST1.kdb -pw Passw0rd -file test1.cer -format ascii

    List Certificate under TEST1’s Keystore
    ####################################
    6. runmqckm -cert -list -db TEST1.kdb -pw Passw0rd

    Alter SSLKEYR parameter in TEST1 Qmgr
    ##################################
    7. ALTER QMGR SSLKEYR(‘/var/mqm/qmgrs/TEST1/ssl/TEST1’)

    Only Define a SSL Enabled Cluster Receiver Channel **
    ############################################
    8. DEFINE CHANNEL(TO.TEST1.S) CHLTYPE(CLUSRCVR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1414)’) SSLCIPH(TLS_RSA_WITH_3DES_EDE_CBC_SHA)

    Refresh SSL Security
    ##################
    9. REFRESH SECURITY TYPE(SSL)

    Verify the Status of Cluster Channels
    ################################
    10. DISPLAY CLUSQMGR(TEST1) STATUS SSLCIPH

    Checkpoint Test: You should see the NON SSL Cluster Channels are Running & newly defined SSL Channel status is INACTIVE state.

    ** We will define the SSL enabled Cluster Sender channels in Section 5.11**

    Note: While generating the Certificate request or CSR in Step 5.2, Cert Label should be ibmwebspheremq<QM Name in Lower Case> i.e. ibmwebspheremqtest1.

    *** Repeat Steps 5.1 – 5.10 for the other 2 Qmgrs (TEST2,3) ***

    11. Under TEST1 Qmgr, define the SSL Enabled Cluster Sender Channel to TEST2 Qmgr (FR)

    As per Cluster design rules, 2 FR Qmgrs (TEST1 ,2) should be fully interconnected using manually defined Cluster Sender/Receiver Channel pairs. Since we have already defined the SSL enabled Cluster Receiver Channel (Section 5 Step 8), we are now creating the SSL enabled Cluster Sender Channel in this Step. Once defined, the SSL enabled Cluster Sender Channel will start running automatically. This sequence of creating SSL enabled Cluster channels is essential for its proper functioning, otherwise the Channels may fail to start.

    runmqsc TEST1
    #############
    DEFINE CHANNEL(TO.TEST2.S) CHLTYPE(CLUSSDR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1415)’) SSLCIPH(‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’)

    Check Cluster Channel Status
    ##########################
    DIS CHS(*) SSLPEER SSLCERTI

    AMQ8417: Display Channel Status details.
    CHANNEL(TO.TEST2.S) CHLTYPE(CLUSSDR)
    CONNAME(127.0.0.1(1415)) CURRENT
    RQMNAME(TEST2) SSLCERTI(CN=SSL CA,O=IBM,C=China)
    SSLPEER(SERIALNUMBER=58:BD:76:43,CN=TEST2 Queue Manager,O=IBM,C=India)
    STATUS(RUNNING) SUBSTATE(MQGET)
    XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)

    Checkpoint Test: SSL Cluster Channels should be running along with Normal Cluster Channels.

    12. Under TEST2 Qmgr, define the SSL Enabled Cluster Sender Channel to TEST1 Qmgr (FR)

    Similar to Step 11, Interconnect the 2 FR Qmgrs using manaully defined Cluster Sender/Receiver Channel pairs.

    runmqsc TEST2
    ##############
    DEFINE CHANNEL(TO.TEST1.S) CHLTYPE(CLUSSDR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1414)’) SSLCIPH(‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’)

    Check Cluster Channel Status
    #########################
    DIS CHS(*) SSLPEER SSLCERTI

    AMQ8417: Display Channel Status details.
    CHANNEL(TO.TEST1.S) CHLTYPE(CLUSSDR)
    CONNAME(127.0.0.1(1414)) CURRENT
    RQMNAME(TEST1) SSLCERTI(CN=SSL CA,O=IBM,C=China)
    SSLPEER(SERIALNUMBER=58:BD:76:28,CN=TEST1 Queue Manager,O=IBM,C=India)
    STATUS(RUNNING) SUBSTATE(MQGET)
    XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)

    Checkpoint Test: SSL Cluster Channels should be running along with Normal Cluster Channels.

    Note: Ensure that you select the Same Cipher Spec. Algorithm between the Sending/Receiving end of the Cluster Channels.

    13. Under TEST2 Qmgr, define the SSL Enabled Cluster Sender Channel to TEST1 Qmgr (FR)

    As per the Cluster design rules, any PR Qmgr needs to be fully interconnected with any one of FR Qmgr. In this case, PR Qmgr TEST3 has manually defined secure Cluster receiver (already defined in *** Repeat Step 51.-5.10 ***). In this step, we are going to define secure Cluster Sender channel to TEST1 Qmgr.

    runmqsc TEST3
    #############
    DEFINE CHANNEL(TO.TEST1.S) CHLTYPE(CLUSSDR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1414)’) SSLCIPH(‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’)

    Check Cluster Channel Status
    ########################
    DIS CHS(*) SSLPEER SSLCERTI

    Note: After activation of SSL/TLS Cluster Channels, stop the existing non SSL Cluster Channels, take them out of MQ Cluster POC. Steps for this part of the activity is not in scope of this exercise!

                     The below figure represents the High Level Details of the Solution, Post Completion of Section 5

    4-4

     

  6. Create Application Users Alice & Bob

    In this part of the exercise, we are going to create 2 users Alice & Bob using root ID. Alice (using MQ Client) should be able to put Messages using Client Connection Channel into a clustered QAlias defined under TEST1 Qmgr whose target is a cluster QLocal under TEST2 Qmgr. On the other hand, Bob (using MQ Client) should be able to get the Messages from this Local Q using CCDT file.

    Using root ID: useradd alice | useradd bob

  7. MQ Client Configuration using CCDT

    1. Create a Dedicated Qmgr CCDT for Administration & Maintenance of CCDT file

    In this Section, we are going to make use of a dedicated Qmgr CCDT for TAB file Administration & Maintenance activities. Define the Client Channel names to be used by TEST1 & TEST2 Qmgrs under CCDT using the below mentioned commands. Once completed, copy the updated AMQCLCHL.TAB file to a centralized location /home/CCDT accessible to both Alice & Bob. Define the corresponding SVRCONN Channels for each Client Connection Channel.

    Note: SVRCONN/Client Connection definition works in pair.

    2. Create & Start CCDT Qmgr
    #########################
    crtmqm CCDT
    strmqm CCDT

    3. Go to directory of the TAB File
    ############################
    cd /var/mqm/qmgrs/CCDT/@ipcc/

    runmqsc CCDT
    ############

    DEFINE CHANNEL(TEST1) CHLTYPE(CLNTCONN) CONNAME(‘127.0.0.1(1414)’) QMNAME(TEST1)
    DEFINE CHANNEL(TEST2) CHLTYPE(CLNTCONN) CONNAME(‘127.0.0.1(1415)’) QMNAME(TEST2)

    4. Now, copy the updated TAB File AMQCLCHL.TAB into /home/CCDT

    cd /var/mqm/qmgrs/CCDT/@ipcc/
    cp -p AMQCLCHL.TAB /home/CCDT

    Note: Give 777 permission to CCDT directory & AMQCLCHL.TAB file to avoid permission issues.

    5. Create the corresponding SVRCONN Channels for each Client Connection Channel
    ————————————————————————————————————————-
    runmqsc TEST1
    ############
    DEFINE CHANNEL(TEST1) CHLTYPE(SVRCONN)

    runmqsc TEST2
    ############
    DEFINE CHANNEL(TEST2) CHLTYPE(SVRCONN)

  8. Grant OAM Authorities

    In this Section, we are going to configure necessary OAM Level Permissions for Alice & Bob on MQ Objects. As per our requirement, Alice should be able to connect to the Qmgr TEST1 & have necessary authority to put messages into the Clustered Alias Q (AMS_A) which points to Clustered Local Q (AMS_E). Similarly, Bob should be able to connect to the Qmgr TEST2 & have necessary authority to read incoming messages from the Local Q (AMS_E).

    Note: Execute Refresh Security command under TEST1 & TEST2 Qmgrs after setting up the below permissions.

    Alice
    ———
    setmqaut -m TEST1 -t qmgr -p alice +inq +connect +dsp
    setmqaut -m TEST1 -t q -n AMS_A -p alice +put +browse +dsp
    setmqaut -m TEST2 -t q -n AMS_E -p alice +put +browse +dsp

    Bob
    ——
    setmqaut -m TEST2 -t qmgr -p bob +inq +connect +dsp
    setmqaut -m TEST2 -t q -n AMS_E -p bob +get +browse +dsp

    runmqsc TEST1(2)
    —————————
    REFRESH SECURITY

  9. Set MQ Client Environment Variables

    Here, we are going to setup the MQ Client Environment Variables for Alice & Bob. Open 2 different terminals; one each for Alice & Bob. Execute the below commands to set the MQ Client connection channel connectivity. Once ENV variables are set, go the sample programs & try to put / get Messages as Alice & Bob user respectively.

     Alice’s Terminal
    ———————–
    export MQCHLTAB=AMQCLCHL.TAB
    export MQCHLLIB=/home/CCDT

    cd /opt/mqm/samp/bin

    ./amqsputc AMS_A TEST1

    Bob’s Terminal
    ——————–
    export MQCHLTAB=AMQCLCHL.TAB
    export MQCHLLIB=/home/CCDT

    cd /opt/mqm/samp/bin

    ./amqsgetc AMS_E TEST2

    Checkpoint Test: Alice should be able to put Message into the Clustered QAlias (AMS_A) under TEST1 Qmgr which points to Cluster QLocal (AMS_E) under TEST2 Qmgr. And, Bob should be able to browse / get the messages from the QL(AMS_E) as shown in the below diagram.

                   The below figure depicts High Level Solution Details, Post completion of Section 9

    3-4

     

  10. Enable SSL for MQ Clients

    In this part, we are going to secure the MQ Client Channels (used by Alice & Bob) with Queue Managers. We already configured a working Client Connection Channel between Alice <==> TEST1 Qmgr and between Bob <==> TEST2 Qmgr, covered in Sections 7-9. In this part, we are going to enable SSL/TLS at MQ Client Channel Level.

    For this exercise, we will make use of the Internal CA created in Section 4.

    Create Keystore, generate CSR & get it signed by CA for Alice:

    ######################################################

    Create the Keystore for Alice (/home/alice/keystore)
    ========================================
    1. runmqckm -keydb -create -db alice -pw Passw0rd -type cms -expire 365 -stash

    Create a Certificate Request for Alice
    ==============================
    2. runmqckm -certreq -create -db alice.kdb -pw Passw0rd -label ibmwebspheremqalice -dn “CN=Alice Client,O=IBM,C=India” -file alice.req

    Sign Alice Clients’s certificate using CA (/home/mqm/CA) *** Section 4 ***
    ======================================================
    3. runmqckm -cert -sign -file alice.req -db SSL_CA.kdb -pw Passw0rd -label ssl_ca -target alice.cer -format ascii -expire 364

    Add CA’s Public Certificate into Alice’s Keystore
    ==========================================
    4. runmqckm -cert -add -db alice.kdb -pw Passw0rd -label ssl_ca -file ssl_ca.cer -format ascii -trust enable

    Receive the CA Signed Certificate Request into Alice’s Keystore
    =======================================================
    5. runmqckm -cert -receive -db alice.kdb -pw Passw0rd -file alice.cer -format ascii

    List Certificate under MQ Client’s keystore
    ====================================
    6. runmqckm -cert -list -db alice.kdb -pw Passw0rd

    Note: While generating CSR file in Step 2, the Certificate Label naming convention should be <ibmwebspheremq> followed by <ClientName in Lower Case> i.e. ibmwebspheremqalice

    Observation: Alice’s SSL Keystore

    SSL-Alice-1

    Repeat the Same Steps for Bob i.e. Create Keystore, generate CSR & get it signed by CA:

    ##############################################################################

    Create the Keystore for Bob (/home/bob/keystore)
    ====================================
    1. runmqckm -keydb -create -db bob -pw Passw0rd -type cms -expire 365 -stash

    Create a Certificate Request for Bob
    ===========================
    2. runmqckm -certreq -create -db bob.kdb -pw Passw0rd -label ibmwebspheremqbob -dn “CN=Bob Client,O=IBM,C=India” -file bob.req

    Sign Alice Clients’s certificate using CA (/home/mqm/CA) *** Section 4 ***
    ====================================================
    3. runmqckm -cert -sign -file bob.req -db SSL_CA.kdb -pw Passw0rd -label ssl_ca -target bob.cer -format ascii -expire 364

    Add CA’s Public certificate into Bob’s Keystore
    ==================================
    4. runmqckm -cert -add -db bob.kdb -pw Passw0rd -label ssl_ca -file ssl_ca.cer -format ascii -trust enable

    Receive the CA Signed Certificate Request into Bob’s Keystore
    =============================================
    5. runmqckm -cert -receive -db bob.kdb -pw Passw0rd -file bob.cer -format ascii

    List Certificate under Bob’s Keystore
    ==============================
    6. runmqckm -cert -list -db bob.kdb -pw Passw0rd

    Note: While generating CSR file in Step 2, the Certificate Label naming convention should be <ibmwebspheremq> followed by <ClientName in Lower Case> i.e. ibmwebspheremqbob

    Observation: Bob’s SSL Keystore

    SSL-Bob-1
  11. Update the TLS Cipher Spec

    As described in Section 7, we again need to make use of the CCDT Queue Manager to update the Cipher Spec Algorithm in the existing Client Channels definitions following the commands mentioned below:

    cd /var/mqm/qmgrs/CCDT/@ipcc/

    runmqsc CCDT
    ############

    ALTER CHANNEL(TEST1) chltype(CLNTCONN) SSLCIPH(‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’)
    ALTER CHANNEL(TEST2) chltype(CLNTCONN) SSLCIPH(‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’)

    Copy the updated AMQCLCHL.TAB file from (/var/mqm/qmgrs/CCDT/@ipcc/) to centralized location (/home/CCDT)

    Update the corresponding SVRCONN Channels with TLS Cipher Spec. Algorithm

    As mentioned in Previous Step, update the Same TLS Cipher Spec Algorithm for the corresponding SVRCONN Channels under TEST1 & TEST2 Qmgrs.

    runmqsc TEST1
    #############
    ALTER CHANNEL(TEST1) CHLTYPE(SVRCONN) SSLCIPH(‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’)
    REFRESH SECURITY TYPE(SSL)

    runmqsc TEST2
    ##############
    ALTER CHANNEL(TEST2) CHLTYPE(SVRCONN) SSLCIPH(‘TLS_RSA_WITH_3DES_EDE_CBC_SHA’)
    REFRESH SECURITY TYPE(SSL)

    Set the MQ Client related Environment Variables for Alice & Bob as mentioned in Section 9. This time, we need to setup another additional SSL related Environment Variable for both Alice & Bob to point to their respective SSL keystores.

    export MQSSLKEYR=/home/alice/keystore/alice

    export MQSSLKEYR=/home/bob/keystore/bob

    Using sample programs, Alice puts messages over SSL enabled Client Connection Channel while Bob get the same messages over secure Channel from the other end of the IBM MQ Cluster network as demonstrated in the Case Study pictorial diagram mentioned below.

    Alice
    ———-
    $/opt/mqm/samp/bin> ./amqsputc AMS_A TEST1
    Hello testing…

    runmqsc TEST1
    #############
    DIS CHS(TEST1) SSLPEER SSLCERTI

    dis chs(TEST1) SSLPEER SSLCERTI
    1 : dis chs(TEST1) SSLPEER SSLCERTI
    AMQ8417: Display Channel Status details.
    CHANNEL(TEST1) CHLTYPE(SVRCONN)
    CONNAME(127.0.0.1) CURRENT
    SSLCERTI(CN=SSL CA,O=IBM,C=China)
    SSLPEER(SERIALNUMBER=58:BE:A1:54,CN=Alice Client,O=IBM,C=India)
    STATUS(RUNNING) SUBSTATE(RECEIVE)

    Checkpoint Test: It will display that the Server Connection Channel is running with SSL enabled parameters SSLPEER & SSLCERTI.

    Bob
    ——-
    $/opt/mqm/samp/bin> ./amqgetc AMS_E TEST2
    Hello testing…

    runmqsc TEST2
    #############
    DIS CHS(TEST2) SSLPEER SSLCERTI

    dis chs(TEST2) SSLPEER SSLCERTI
    1 : dis chs(TEST2) SSLPEER SSLCERTI
    AMQ8417: Display Channel Status details.
    CHANNEL(TEST2) CHLTYPE(SVRCONN)
    CONNAME(127.0.0.1) CURRENT
    SSLCERTI(CN=SSL CA,O=IBM,C=China)
    SSLPEER(SERIALNUMBER=58:BE:A3:8B,CN=Bob Client,O=IBM,C=India)
    STATUS(RUNNING) SUBSTATE(RECEIVE)

    Checkpoint Test: It will display that the Server Connection Channel is running with SSL enabled parameters SSLPEER & SSLCERTI.

    The Below Diagram shows the End to End Message Encryption(in-transit) while passing through SSL/TLS enabled Secure Channels from Alice to Bob.

    2-5

     

    Thus we have implemented the scenario wherein Application (Alice) using MQ Clients is sending data over SSL/TLS enabled Client Connection Channel, passing through SSL enabled MQ Cluster (TEST1 & TEST2) before being consumed by receiving Application (Bob) over secured Client Connection Channel. Hence, Business data/messages are encrypted while in transit throughout the MQ network. However, the messages will still be available in Plain Text while sitting in the Local Queues & accessible to all administrator having ‘mqm’ privileges. To eliminate this part of the security vulnerability, AMS comes into the picture!

  12. Set AMS Rules & Configurations

    Ensure that the AMS package is installed in your system by using the commands:

    -bash-4.1$ rpm -qa|grep AMS*
    MQSeriesAMS-7.5.0-5.x86_64
    MQSeriesAMS_2-8.0.0-4.x86_64
    -bash-4.1$

    -bash-4.1$ dspmqver -p 128 -v
    Name: WebSphere MQ Advanced Message Security
    Version: 8.0.0.4
    Level: p800-004-151017
    BuildType: IKAP – (Production)
    -bash-4.1$

    AMS provides two Quality of Protections(QOP) i.e. Digital Signature & Encryption. Depending on the Customer requirement, one can select & setup policies. In this exercise, we have selected Encryption policy which also includes Digital Signature as well.

    We are going to use the below two Queues created in Section 3 for AMS related configuration & Testing:

    AMS_A Cluster QAlias Queue defined under TEST1 Qmgr whose Target Q is AMS_E defined under TEST2 Qmgr.

    AMS_E Cluster Local Queue defined under TEST2 Qmgr.

    1. Grant OAM Authorities to Alice & Bob on AMS enabled Application Queues (Completed in Section 8)

    2. Grant OAM Authorities to Alice & Bob on 2 AMS related SYSTEM Queues (SYSTEM.PROTECTION.POLICY.QUEUE &  SYSTEM.PROTECTION.ERROR.QUEUE) 

    Setup OAM related permissions on 2 AMS related SYSTEM queues on both TEST1 & TEST2 Qmgrs for Alice & Bob. Refresh Security Cache for both Qmgrs once completed.

    Alice
    ——–
    setmqaut -m TEST1 -t q -n SYSTEM.PROTECTION.POLICY.QUEUE -p alice +put +browse
    setmqaut -m TEST1 -t q -n SYSTEM.PROTECTION.ERROR.QUEUE -p alice +put +browse

    setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.POLICY.QUEUE -p alice +put +browse
    setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.ERROR.QUEUE -p alice +put +browse

    Bob
    ——–
    setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.POLICY.QUEUE -p bob +put +browse
    setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.ERROR.QUEUE -p bob +put +browse

    runmqsc TEST1(2)
    ————————–
    REFRESH SECURITY

    3. Create AMS Keystores & Config files for Alice & Bob

    In this Step, we are going to create Alice & Bob’s keystores along with generating & exchanging their self-signed certificates into each other’s repositories.

    Alice
    ——–
    Create the default path for Alice’s Configuration Directory
    =========================================
    mkdir /home/alice/.mqs -p

    Create the keystore for Alice
    ====================
    runmqakm -keydb -create -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -stash

    Generate the Self-Signed Certificate for Alice
    ================================
    runmqakm -cert -create -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label Alice_Cert -dn “cn=alice,o=IBM,c=IN” -default_cert yes

    Extract the Self-Signed Certificate of Alice into a /tmp/certs directory
    =================================================
    runmqakm -cert -extract -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label Alice_Cert -target /tmp/certs/alice_public.arm

    ################################################################

    Bob
    ——
    Create the default path for Bob’s Configuration Directory
    ========================================
    mkdir /home/bob/.mqs -p

    Create the keystore for Bob
    =====================
    runmqakm -keydb -create -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -stash

    Generate the Self-Signed Certificate for Bob
    ===============================
    runmqakm -cert -create -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -label Bob_Cert -dn “cn=bob,o=IBM,c=IN” -default_cert yes

    Extract the Self-Signed Certificate of Bob into a /tmp/certs directory
    =================================================
    runmqakm -cert -extract -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -label Bob_Cert -target /tmp/certs/bob_public.arm

    ################################################################

    4. Now, Add the Public Certificate of Alice & Bob into each other’s Keystores
    ======================================================
    runmqakm -cert -add -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -label Alice_Cert -file /tmp/certs/alice_public.arm

    runmqakm -cert -add -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label Bob_Cert -file /tmp/certs/bob_public.arm

    Observation:  Public Certs of Alice & Bob

    Tmp-1

     

    Observation: Alice’s AMS Keystore

    AMS-Alice-1
    Alice-Keystore-AMS-1

    Observation: Bob’s AMS Keystore

    AMS-Bob-1
    Bob-keystore-AMS-1

    5. Create the AMS Configuration files for Alice & Bob

    In this Step, create the config file keystore.conf under Alice & Bob’s default home directory as shown below:

    keystore.conf – Alice (/home/alice/.mqs/keystore.conf)
    ========================================
    cms.keystore=/home/alice/.mqs/alicekey
    cms.certificate=Alice_Cert

    keystore.conf – Bob (/home/bob/.mqs/keystore.conf)
    =======================================
    cms.keystore=/home/bob/.mqs/bobkey
    cms.certificate=Bob_Cert

    6. Setup Security Policies for Alice & Bob on AMS enabled Application Queues

    In the last part of this exercise, we are going to set the AMS rules which grant Alice user the necessary authority to put messages into AMS Queues.Those message will be Digitally signed using SHA1 algorithm & Encrypted using ASE256 Cipher Spec. Only Bob user has the required authority to decrypt & subsequently browse / get the messages from the AMS enabled Local Q (AMS_E).

    1. Alice should be able to Put Messages into AMS enabled Application Queues i.e. AMS_A & AMS_E

    2. Bob should be able to Get Messages from AMS_E Application Queue

    setmqspl -m TEST1 -p AMS_A -s SHA1 -a “CN=alice,O=IBM,C=IN” -e AES256 -r “CN=bob,O=IBM,C=IN”

    setmqspl -m TEST2 -p AMS_E -s SHA1 -a “CN=alice,O=IBM,C=IN” -e AES256 -r “CN=bob,O=IBM,C=IN”

    ################################################

    Observation: AMS Policy set on QAlias (AMS_A) under TEST1

    Policy-1

    Observation: AMS Policy set on QL (AMS_E) under TEST2

    Policy1-1
  13. Set Channel Auth (CHLAUTH) Rules

    On top of the above MQ Security settings, as discussed from Sections 4-12, we can configure Additional Level of Security at the SVRCONN Channel Level using a new security feature introduced in IBM MQ v7.5 onwards called CHLAUTH. Using this functionality, we can set Rules to Allow / Block access from specified range of IP Addresses, User IDs, SSL DN names etc. By default CHLAUTH security feature is enabled in MQ 7.5 & above; all user IDs having administrative privileges will be blocked automatically while connecting though SYSTEM channels.

    In this Case Study Implementation, we have added Two sets of CHLAUTH rules on TEST1 Qmgr as mentioned below.

    Create a rule which applies to channels whose names match the pattern “TEST1”.

    Allow inbound connections from SSL/TLS subject’s Distinguished Names which match pattern “CN=Alice Client,O=IBM,C=India”.

    Assign a user ID of “alice” for access control checks for these connections.

    runmqsc TEST1
    ———————–
    SET CHLAUTH(‘TEST1’) TYPE(SSLPEERMAP) SSLPEER(‘CN=Alice Client,O=IBM,C=India’) USERSRC(MAP) MCAUSER(‘alice’) DESCR(‘POC’) ACTION(ADD)

    SET CHLAUTH(‘TEST1’) TYPE(ADDRESSMAP) ADDRESS(‘10.9.*.*’) USERSRC(NOACCESS) DESCR(‘Block IP’) WARN(NO) ACTION(ADD)

    *// Block Inbound Connections from addresses which match pattern “10.9.*.*”. //*

    Observation:

    CHLAUTH-1-1

     

    On the other end of the MQ network i.e.under TEST2 Qmgr, we are going to set another CHLAUTH Rules to Allow Bob to connect while validating its Distinguished Names as mentioned below:

    1. Create a rule which applies to channels whose names match the pattern “TEST2”.

    2. Allow inbound connections from SSL/TLS subject’s Distinguished Names which match pattern “CN=Bob Client,O=IBM,C=India”.

    3. Assign a user ID of “bob” for access control checks for these connections.

    runmqsc TEST2
    ———————–
    SET CHLAUTH(‘TEST2’) TYPE(SSLPEERMAP) SSLPEER(‘CN=Bob Client,O=IBM,C=India’) USERSRC(MAP) MCAUSER(‘bob’) ACTION(ADD)

    Observation:

    CHLAUTH-TEST2-1

     

  14. Test Results

    Case 1: Alice puts a message into AMS enabled Queue (AMS_A) define under TEST1 Qmgr using sample utility program amqsputc.

    Observation 1:

    alice-put-1

     

    Case 2: As soon as Alice puts a message mentioned in Case 1, SSL Enabled SVRCONN Channel (TEST1) & Cluster Sender Channel (TO.TEST2.S) started running under TEST1 Qmgr as highlighted in the below screenshot:

    Observation 2:

    SSL-TEST1-1

     

    Case 3: Bob is able to read the encrypted Message from the AMS enable Queue (AMS_E) defined under TEST2 Qmgr in Plan text using sample program amqsgetc.

    Observation 3:

    AMS-Bob-Read-1

     

    Case 4: As soon as Bob issues the command to read the Message mentioned in Case 3, SSL Enabled SVRCONN (TEST2) started running under TEST2 Qmgr as mentioned in the below screenshot:

    Observation 4:

    SSL-TEST2-11-1

     

    Case 5: ‘mqm’ user does not have Authority to read (amqsbcg) the message from the AMS enable Queue (AMS_E) defined under TEST2 Qmgr.

    Observation 5:

    mqm-1

     

    Case 6: How to verify if the Message from Alice is Digitally Signed & Encrypted in AMS enabled Q (AMS_E) defined under TEST2 Qmgr ?

    To achieve this tasks, we have follow the Steps mentioned below:

    Define a Queue Alias (AMS_A) under TEST2 qmgr which points to the AMS enabled Local Q (AMS_E)

    runmqsc TEST2

    DEFINE QA(AMS_A) TARGET(AMS_E2)

    Observation 6:  As ‘mqm’ user try to browse the QAlias (AMS_A) whose target Q is the AMS enable LQ (AMS_E) defined under TEST2 Qmgr.

    read-1

     

    Note: PDMQ signifies that the message has been Digitally Signed & the remaining gibberish part signifies that message has been Encrypted.

     

    Enc-1

     

  15. Conclusion

    This article basically demonstrates the simultaneous usage & application of almost all the IBM® MQ built-in security features (Excluding Channel Exit Programs) in an Integrated Test Case as shown below diagrammatically. As per the below figure, Application (Alice) using MQ Clients is sending data over SSL/TLS enabled Client Connection Channel, passing through SSL enabled MQ Cluster (TEST1 & TEST2) before being consumed by receiving Application (Bob) over secured Client Connection Channel. Hence, Business data / messages are encrypted while in transit throughout the MQ network. However, the messages will still be available in Plain Text while sitting in the Local Queues & accessible to all administrator having ‘mqm’ privileges. To eliminate this part of the security vulnerability, IBM has introduced Advanced Message Security using which Administrators have the option to either Digitally Sign the data or Encrypt or both as per Client’s requirement.

    1-6

     

Related Topics

  1.  IBM MQ Knowledge Center
  2.  Object Authority Manager (OAM)
  3.  MQ Series Primer
  4.   AMS Installation & Configuration
  5.   Download IBM MQ trial version
  6.  Advanced Clustering Techniques using IBM MQ