CHLAUTH - the back-stop rule
Morag Hughson 110000EQPN Comments (11) Visits (7929)
WebSphere MQ V7.1 introduced a channel security feature, Channel Authentication Records, or CHLAUTH for short. This feature allows you to set up rules to detail how your inbound connections should be treated. Should they be allowed or blocked. Today we shall look at the best way to use CHLAUTH rules in MQ.
Allow or Block?
When thinking about the control of inbound connections into your queue manager, there are two perspectives. Either you can try to list all the connections that are not allowed, or you can start by saying all connections are not allowed and then try to list all the connections that are allowed. I favour the second perspective and here's why.
If you try to list all the connections that are not allowed and everything not listed is therefore allowed in, then the result of missing one off the list is that a connection who was not allowed in has been able to connect. This could result in bad things happening. If instead, you start by saying every connection is not allowed, and then list those that are, the result of missing one off this list is not a security breach, although it might be a phone-call from someone who is annoyed at not being allowed to connect, which you can then fix relatively quickly. This phone-call is preferable to the security breach situation.
So let's see how to do this with CHLAUTH rules.
Using CHLAUTH to allow connections in
The first thing to do is to create a (external link to wiktionary) back-stop rule. This is a rule that will catch any connections not otherwise matched by more specific rules. This rule has the effect of stopping any remote connections from being able to attach to your queue manager at all! See later on if this makes you nervous!
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule')
Now that we have closed the door on all remote connections we can start to put more specific rules in place to allow certain connections in. Here are some examples:
SET CHLAUTH('TO.QM2') TYPE(QMGRMAP) QMNAME('QM1') USERSRC(MAP) MCAUSER('QM1USER')
SET CHLAUTH('*') TYPE(SSLPEERMAP) SSLPEER('CN="Morag Hughson"') ADDRESS('9.*') MCAUSER('hughson')
I can't risk making the back-stop rule!
You may have been reading this thinking "I can't put the back-stop rule in place, I'll get lots of irate phone calls until I work out what all the other rules should be". If you were, then here is an alternative for you. When you create the back-stop rule initially, create it in warning mode
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule') WARN(YES)
Now you can continue on and make all your positive rules. When you believe you have created all the rules you need, turn on channel events.
ALTER QMGR CHLEV(EXCEPTION)
and monitor the SYST
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule') WARN(NO) ACTION(REPLACE)
Now you will get the phone-call if anyone fails to connect, but the aim here is that you have already got the rules in place for almost everyone.