| Author |
Message
|
| jonesn |
 Posted: Mon Apr 26, 2010 2:30 am Post subject: Secure cluster channels against internal attack |
 |
|
Apprentice
Joined: 09 Jan 2002
Posts: 47
|
Chaps,
I have a cluster containing about 20 queue managers and some very strict security requirements.
Applications cannot write to S.C.T.Q so all cluster queues have alias queues at point to entry. This allows us to secure at point of entry using OAM.
The cluster is secured using SSL.
We have a gateway queue manager that any legacy queue manager connects through. The channels are secured using SSL & we use BlockIP2 to force a particular userid into the message so that we can use OAM to restrict object access.
Any applications that use MQ Client are also secured using SSL & BlockIP2.
There are no problems with the above requirements but I am also being asked to implement BlockIP2 on the internal clussdr/clusrcvr channels.
I know that I would need to use a channel auto definition exit to load the BlockIP2 exit at channel start time. I have coded chadexits before & it was a complex process.
But I am not sure that I will be able to effectively secure the cluster channels anyway using the BlockIP2 exit. Like with the legacy & clients above I can force a userid into the messages & restrict using OAM but this only works for business messages.
These channels will also be processing internal cluster messages which will be targetting the system queues that my security architect wants me to guard. These internal messages are largely undocumented, occur infrequently & are critical to the health of the cluster.
Has anyone out there secured a cluster to this extent, considered it or have any thoughts on the matter?
Thanks
_________________
---
Nick Jones
IBM Certified Solutions Expert (WebSphere MQ Integrator) |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Apr 26, 2010 2:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Nick,
Don't let the security get too paranoid on you. In my opinion using SSL on the cluster receiver and cluster sender channels should be enough. You can add common name restrictions like:
| Code: |
| O="your org", ou="cluster name", ou="something" |
This should be enough to prevent an unauthorized qmgr to join the cluster.
If no qmgr outside your organization is involved, you could even use an internal CA.
Talk to your security team 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jonesn |
| Posted: Mon Apr 26, 2010 3:16 am Post subject: |
|
|
Apprentice
Joined: 09 Jan 2002
Posts: 47
|
FJB,
This is a bit of opinion gathering before I tackle the security team.
We already have SSL across all channels across the cluster (CLUSSDR/CLUSRCVR), into the cluster at the gateway (SDR/RCVR) and MQ Client (SVRCONN). And we are creating the certificates using a private CA with DN naming convention similar to your suggestion.
This paricular security guideline states that all queue managers must ensure that any messages arriving on any channel must be subject to OAM restrictions. I am able to challenge this requirement but wanted to ensure I am not missing something.
Thanks
_________________
---
Nick Jones
IBM Certified Solutions Expert (WebSphere MQ Integrator) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 26, 2010 7:06 am Post subject: Re: Secure cluster channels against internal attack |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| jonesn wrote: |
There are no problems with the above requirements but I am also being asked to implement BlockIP2 on the internal clussdr/clusrcvr channels.
|
Why? What is BlockIP2 going to provide that properly set up SSL won't that the Security guys want? (I don't have expirience with BlockIP2). Are you looking to reject any messages with a blank User ID, or ones that have mqm as the ID, for example?
I would tag every CLUSRCVR with an ID in the MCAUSER that does not have access to the SYSTEM.ADMIN.COMMAND.QUEUE (or any of its Aliases if they exist) or to any of the Initiation queues. Unfortunately you can't block access to the SYSTEM.CLUSTER.COMMAND.QUEUE, but that's where SSL comes into play insuring only QMs you intend are talking to your cluster.
| Quote: |
This paricular security guideline states that all queue managers must ensure that any messages arriving on any channel must be subject to OAM restrictions. |
Technically, every message is, unless you turned off the OAM for that QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 26, 2010 3:08 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Presumably they're looking for role-based authorization across a cluster channel, such that they need to map a specific userid coming across the clusrcvr to a specific different id.
That is, presumably they need to ensure that App A can only talk to App A's queues across the cluster and can't send messages to App B's queues.
Or they'd just set an MCAUSER on the clusrcvr and not worry about blockip.
The fact that this can still be done without using blockIP at any point, merely by using a *lot* of qaliases and SSL and MCAUSER is a different point. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 26, 2010 4:23 pm Post subject: Re: Secure cluster channels against internal attack |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| PeterPotkay wrote: |
| Quote: |
This paricular security guideline states that all queue managers must ensure that any messages arriving on any channel must be subject to OAM restrictions. |
Technically, every message is, unless you turned off the OAM for that QM. |
I just quoted myself.... 
What I wrote is true for SVRCONN channels. For QM to QM channels, including CLUSRCVRs, this is true if you additionally set the Put Authority to "Context" instead of Default. But that is useless in my opinion, unless you trust every message from every other QM in the cluster to have the correct ID associated with it, and how would you enforce / prove that?
You're far better off trusting no IDs, and setting the MCAUSERs on your channels to lowest amount of access that channel needs, and then insuring via SSL and/or an Exit that only the intended apps / QMs use that channel.
>>>If your MCAUSER is blank, you are saying you trust the connecting client application or connecting QM 100% to not mess with you.
I suppose you could have an exit with a black list or white list of IDs, but who needs the administrative headache to maintain that list?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 26, 2010 7:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Peter,
Wouldn't that be about the same as having all svrconn channels in the MQ network attached to the cluster using SSL and MCAUserid, having OAM set on all the queues / aliases and using the appropriate distinguished name on the SSL for cluster receiver/sender so to prevent an unauthorized qmgr to join the cluster.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 27, 2010 5:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| fjb_saper wrote: |
Peter,
Wouldn't that be about the same as having all svrconn channels in the MQ network attached to the cluster using SSL and MCAUserid, having OAM set on all the queues / aliases and using the appropriate distinguished name on the SSL for cluster receiver/sender so to prevent an unauthorized qmgr to join the cluster. |
Yes......but, I think I'm missing something you are implying with your reply?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 27, 2010 8:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
The only implied thing there was "no need for a user exit"
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Apr 28, 2010 7:05 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| fjb_saper wrote: |
| Wouldn't that be about the same as having all svrconn channels in the MQ network attached to the cluster using SSL and MCAUserid, having OAM set on all the queues / aliases and using the appropriate distinguished name on the SSL for cluster receiver/sender so to prevent an unauthorized qmgr to join the cluster. |
So, any hacker simply needs the "appropriate distinguished name" and then they can join the cluster without being stopped. 
That is why most people use a security exit to restrict which IP address can connect to the queue manager. Convoluted but it does work.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 28, 2010 7:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| RogerLacroix wrote: |
| fjb_saper wrote: |
| Wouldn't that be about the same as having all svrconn channels in the MQ network attached to the cluster using SSL and MCAUserid, having OAM set on all the queues / aliases and using the appropriate distinguished name on the SSL for cluster receiver/sender so to prevent an unauthorized qmgr to join the cluster. |
So, any hacker simply needs the "appropriate distinguished name" and then they can join the cluster without being stopped. |
They would need to supply an SSL certificate that was signed by a known signer AND had a correct distinguished name value that matched SSLPEER.
Yes, this means you are putting your trust in the Certificate Authority.
That is what it means to use certificates in the first place! That you TRUST the SIGNER.
Using an exit means that you are putting your TRUST in the author of the EXIT. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Apr 28, 2010 7:37 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| mqjeff wrote: |
| They would need to supply an SSL certificate that was signed by a known signer AND had a correct distinguished name value that matched SSLPEER. |
It takes a minute to copy a certificate from one client server to another client server. 
| mqjeff wrote: |
| Using an exit means that you are putting your TRUST in the author of the EXIT. |
My comment about "Convoluted but it does work" was in regard to using both SSL and the aforementioned free security exit. 
Personally, I would rather "TRUST" something on the server-side that is doing full authentication of user credentials rather than hoping someone isn't stealing certificates on the client-side.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 29, 2010 3:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| RogerLacroix wrote: |
| Personally, I would rather "TRUST" something on the server-side that is doing full authentication of user credentials rather than hoping someone isn't stealing certificates on the client-side. |
I'd agree whole heartedly with that if there were any way to trust user credentials.
Copying a certificate is no easier or harder than stealing a password.
If you can't trust your users, you can't trust your users! |
|
| Back to top |
|
|
|
|
