| Author |
Message
|
| kishi_25 |
 Posted: Mon Aug 22, 2011 12:17 pm Post subject: SSL Setup for Clustered QM |
 |
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi,
I'm having the following setup of QM.
Q Manager A - Non Cluster QM on Windows
Q Manager B - Partial repository on Cluster X - Aixx
Q Manager C - Full repositoitory on Cluster X - Aix
Q Manager D - Full repository on Cluster X - Aix
Regular sender/receiver channels are defined between Q Manager A and Q Manager B.
Now,
i) If I setup a SSL Between Q Manager A (non cluster QM) and Q Manager B, how does it effect the other cluster members since, Q Manager B is part of cluster. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Aug 22, 2011 12:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You do not configure SSL on a queue manager.
You configure SSL on channels.
That statement tells you absolutely everything you need to know about SSL and MQ clusters. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 22, 2011 12:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| That statement tells you absolutely everything you need to know about SSL and MQ clusters. |
If you need more details, start here and follow the links.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Mon Aug 22, 2011 12:34 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
Jeff,
I didn't mention in my original question as, I'm setting up SSL on QM.
I mentioned as I want to setup SSL between QM. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 22, 2011 12:38 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kishi_25 wrote: |
Jeff,
I didn't mention in my original question as, I'm setting up SSL on QM.
I mentioned as I want to setup SSL between QM. |
| mqjeff wrote: |
You do not configure SSL on a queue manager.
You configure SSL on channels.
That statement tells you absolutely everything you need to know about SSL and MQ clusters. |
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 22, 2011 1:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| mqjeff wrote: |
You do not configure SSL on a queue manager.
You configure SSL on channels.
That statement tells you absolutely everything you need to know about SSL and MQ clusters. |
And you may well need multiple SSL cluster receivers as the SSLPEER does not behave the same from Windows to Unix as it does from Windows to Windows or Unix to Unix... (I suspect it has to do with most significant bit )... especially when you use multiple OUs.
To avoid creating 1 channel per qmgr, you SSL peer should check for an OU that represents the cluster...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Mon Aug 22, 2011 1:11 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
Jeff, agree with you. I was under the impression, since some of the Keyrepository information is stored at QM level and since my QM is Gateway QM for cluster, it might have some impact for other cluster members...
since the essence of your inputs says, the configuration is completely focused on non-cluster channels, it shouldn't have any impact for other cluster members as long as cluster channels doesn't participate in SSL.
thanks for your inputs. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 22, 2011 2:12 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kishi_25 wrote: |
| Jeff, agree with you. I was under the impression, since some of the Keyrepository information is stored at QM level and since my QM is Gateway QM for cluster, it might have some impact for other cluster members... |
OK, a fair concern for someone unfamiliar with WMQ and SSL...
| kishi_25 wrote: |
| ...since the essence of your inputs says, the configuration is completely focused on non-cluster channels, it shouldn't have any impact for other cluster members as long as cluster channels doesn't participate in SSL... |
I can find nothing in mqjeff's posts that so much as hints, suggests, implies, or states that. For SSL, a channel is a channel is a channel - why would you consider securing one type of channel and not another? But take heed of what fjb_saper has advised you.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Mon Aug 22, 2011 6:31 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi exerk,
I guess you are focusing more on cross examining others posts rather than providing inputs. I want to secure one type of channel due to the messages are coming from outside for that particular channel and other channels are internal to our organization.
Also, I appreciate if you stop copying others posts repeatedly and stop evaluating others with your expert knowledge.
We should use our valuable time in forums to address others questions.
If you think, people are asking basic questions you can route them to referrenece links or you dont need to respond that |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 23, 2011 1:42 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kishi_25 wrote: |
| ...I want to secure one type of channel due to the messages are coming from outside for that particular channel... |
Very commendable...
| kishi_25 wrote: |
| ...and other channels are internal to our organization... |
So what? If your external organisation can get to an IP and Port, they can get to your other channels too. Have you secured just what this external entity can do? Can you stop them putting messages to your SYSTEM.ADMIN.COMMAND.QUEUE?
| kishi_25 wrote: |
| ...Also, I appreciate if you stop copying others posts repeatedly... |
Merely highlighting the relevant sections of posts...
| kishi_25 wrote: |
| ...and stop evaluating others with your expert knowledge... |
Expert knowledge is one thing I do not possess...
| kishi_25 wrote: |
| ...We should use our valuable time in forums to address others questions... |
I do when I can address their questions, or highlight valuable information provided by others when I think the OP may have misread/not read/or otherwise ignored what is there...
| kishi_25 wrote: |
| ...If you think, people are asking basic questions you can route them to referrenece links or you dont need to respond that |
Yours was not a basic question, more of an inquiry. However, as you seem to feel somewhat aggrieved by my replies I shall make this my last post on the subject 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Tue Aug 23, 2011 2:58 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi,
Somehow, earlier I was not comfort with your messages. But, after verifying your postings on other forums only, I commented you as expert.  . I don't want you stop posting here.
Have you secured just what this external entity can do? Can you stop them putting messages to your SYSTEM.ADMIN.COMMAND.QUEUE?
I'm setting security for this queue with setmqaut |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 23, 2011 3:12 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kishi_25 wrote: |
hi,
Somehow, earlier I was not comfort with your messages. But, after verifying your postings on other forums only, I commented you as expert. . I don't want you stop posting here... |
No worries. Sometimes I come across as terse and abrupt, for which I offer my apologies to all I may have offended or upset.
| kishi_25 wrote: |
| ...I'm setting security for this queue with setmqaut |
Good. It's surprising how many people forget to do this or just plain can't be bothered, so your post can now be used as a good example of what should be done.
Now, what about your internal channels? 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Tue Aug 23, 2011 3:56 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
thanks Exerk. For internal channels, We are setting for MCAUSER access.
Do you suggest any other security for internal channels? Ofcourse we have
setmqauth for each of QM.
I want to limit the SSL for only external channel as
i) My external channel communicates with one of the partial repository QM on cluster
ii) Also my external channels are distributed sender/receiver
iii) All my internal channels are cluster receiver/sender
do you suggest any other things here? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Aug 23, 2011 5:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kishi_25 wrote: |
| ...We are setting for MCAUSER access... |
As far as I am concerned that should be a default for any channel, irrespective of internal or external - plus SSL of course!
| kishi_25 wrote: |
| ...Do you suggest any other security for internal channels? Ofcourse we have setmqauth for each of QM. |
The minimum I suggest for any channel, again irrespective of internal or external but most emphatically where a queue manager is a mixture of internal and external connections, is SSL and OAM.
| kishi_25 wrote: |
I want to limit the SSL for only external channel as
i) My external channel communicates with one of the partial repository QM on cluster |
And is therefore a gateway to your cluster - lock it, or lose it.
| kishi_25 wrote: |
| ii) Also my external channels are distributed sender/receiver |
I'll restate - a channel is a channel is a channel. If the external party can inquire and discover channel names etc. then OAM is not enough on the internal channels.
| kishi_25 wrote: |
| iii) All my internal channels are cluster receiver/sender |
Even more reason to ensure lock-down as there is the potential for n queue managers to be compromised.
| kishi_25 wrote: |
| ...do you suggest any other things here? |
Only that you should define the level of paranoia as 'the world is against me' when it comes to external parties joining your infrastructure. That is not to suggest that the parties act in any way maliciously, but you have a duty of care toward your employer/client/customer that you will take all necessary precautions to prevent security exposure.
There are some great security related discussions HERE, and I suggest you take some time out to read some of them.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 23, 2011 6:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Only that you should define the level of paranoia as 'the world is against me' when it comes to external parties joining your infrastructure. That is not to suggest that the parties act in any way maliciously, but you have a duty of care toward your employer/client/customer that you will take all necessary precautions to prevent security exposure. |
Expressed more formally, all external parties are by definition outside of the auditible security boundary your organisation has round it. This mean, by extension, you have to apply rigerious security measures against them to meet audit requirements.
How, and how much, security you apply depends a lot of corporate standards, how hard your auditors bite and how much jail time senior executives can do if there's non-compliance or a breach.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
