ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » Using the Listener's IP White List to prevent rogue QMs fro

Post new topic  Reply to topic Goto page Previous  1, 2
 Using the Listener's IP White List to prevent rogue QMs fro « View previous topic :: View next topic » 
Author Message
mqjeff
PostPosted: Wed Mar 27, 2013 6:56 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Mar 27, 2013 7:01 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Wed Mar 27, 2013 7:10 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Mar 27, 2013 7:25 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Fri Mar 29, 2013 7:31 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sat Mar 30, 2013 7:40 pm    Post subject: Reply with quote

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:
  1. bounce the FR
  2. start it with the -ns flag
  3. clear the admin queue
  4. do the work (runmqsc)
  5. 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
View user's profile Send private message Send e-mail
hughson
PostPosted: Thu May 09, 2013 8:19 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Vitor
PostPosted: Thu May 09, 2013 8:24 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » IBM MQ Security » Using the Listener's IP White List to prevent rogue QMs fro
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.