| Author |
Message
|
| mqjeff |
 Posted: Wed Mar 27, 2013 6:56 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| Now, my food is cooked, my shirts are pressed, my house is cleaned, my laundry is done, and she is dressy when I come home from work. |
Sounds dull.
Aside from all this, getting back to the topic at hand...
I don't believe that a PR can be used to join a cluster, I believe that an FR must be contacted first.
That doesn't mean that one can't go to extra steps to misuse a PR to forward messages to an FR that would cause the FR to register a new member of the cluster.
It really depends on what one means when one says "rogue queue manager".... I'm assuming Peter means "uninformed but well-meaning and not malicious" rather than "someone hooked their laptop up to my production network and is now attempting to cause harm". |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Mar 27, 2013 7:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| That doesn't mean that one can't go to extra steps to misuse a PR to forward messages to an FR that would cause the FR to register a new member of the cluster. |
IMHO if you believe there's a creditable threat from a party with that level of skill you should put your hand in your pocket & spend on security.
| mqjeff wrote: |
| It really depends on what one means when one says "rogue queue manager".... I'm assuming Peter means "uninformed but well-meaning and not malicious" rather than "someone hooked their laptop up to my production network and is now attempting to cause harm". |
In the internal, controlled scenario of the original post then you can assume that. If all the SVRCONN channels are locked down then that mitigates the "man with a laptop" risk.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 27, 2013 7:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqjeff wrote: |
| That doesn't mean that one can't go to extra steps to misuse a PR to forward messages to an FR that would cause the FR to register a new member of the cluster. |
IMHO if you believe there's a creditable threat from a party with that level of skill you should put your hand in your pocket & spend on security. |
| Vitor wrote: |
| mqjeff wrote: |
| It really depends on what one means when one says "rogue queue manager".... I'm assuming Peter means "uninformed but well-meaning and not malicious" rather than "someone hooked their laptop up to my production network and is now attempting to cause harm". |
In the internal, controlled scenario of the original post then you can assume that. If all the SVRCONN channels are locked down then that mitigates the "man with a laptop" risk. |
only if the laptop doesn't have a qmgr on it...  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 27, 2013 7:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vitor wrote: |
| mqjeff wrote: |
| In the internal, controlled scenario of the original post then you can assume that. If all the SVRCONN channels are locked down then that mitigates the "man with a laptop" risk. |
only if the laptop doesn't have a qmgr on it... |
Shush.....
....lost count of the number of topologies I've got into with that dodge. 
Though in my own defence, in each case it was a topology on which I'd been employed to work. So I was stopping the client wasting money. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 29, 2013 7:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
| It really depends on what one means when one says "rogue queue manager".... I'm assuming Peter means "uninformed but well-meaning and not malicious" rather than "someone hooked their laptop up to my production network and is now attempting to cause harm". |
I am considering both scenarios. We are standing up a new batch of servers, MQ Clustered, with MQ 7.5.0.1, and there will be dedicated servers for the Full Repositores and they will be MQ 7.5.0.1. BUT, there will need to be some legacy QMs in the cluster as Partial Repositories, at MQ 7.0.1 - so no Channel Authentication possible on those guys, yet. (Upgrading them is not a trivial process and will not happen before we implement the new guys and before we have to add them into the cluster).
So, that's my line of questioning - are we protected from an MQ Cluster perspective if the CLUSRCVR on one PR is open - no SSL, no Exit, no CHALAUTH, but the MCAUSER is tagged with an ID without access to the SYSTEM.ADMIN.COMMAND.QUEUE. Apparently there is still a risk that has to be mitigated by SSL, Exit and/or upgrade to 7.1.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Mar 30, 2013 7:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Think about your 2 repositories. If on the cluster receiver of the 2 repositories you set up your channel auth records to refuse connection except from the white listed qmgrs, you cannot have a rogue qmgr join the cluster as it would require to connect to the full repository and be denied access there.
What you are worried about and with reason is somebody trying to bypass this protection.
Just disable the automatic start of the command server on the FRs and have the SYSTEM.COMMAND.QUEUE of the FRs cleared before starting any work there.
If you are paranoid:
- bounce the FR
- start it with the -ns flag
- clear the admin queue
- do the work (runmqsc)
- bounce the FR bringing it back up in normal mode
You don't need the command server on the FRs...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Thu May 09, 2013 8:19 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
For the record, I am both a British citizen, and Scottish, in fact from Shetland.
On forms, such as U.S. immigration I always write:-
Nationality: British
Country of Residence: England
just to see if whichever computer reads the forms is checking for Nationality != Country of Residence.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 09, 2013 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hughson wrote: |
| just to see if whichever computer reads the forms is checking for Nationality != Country of Residence. |
The U.S. Immigration computers check things?
I suppose I've never seen them working long enough to notice.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
