| Author |
Message
|
| dzifchock |
 Posted: Tue Apr 14, 2009 11:50 am Post subject: Securing an auto-defined receiver channel |
 |
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
Because the manually defined sender/receiver channels are only used to join a cluster, do you define a security exit on the SYSTEM.AUTO.RECEIVER channel in order to secure the auto defined cluster receiver that receives data?
If that is the case, to apply said security exit to already auto-defined receivers, would I just use the refresh cluster command after updating the SYSTEM.AUTO.RECEIVER ?
I tried following a couple posts about this but they did more damage than help.
Thx
Dave |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Apr 14, 2009 11:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
No, SYSTEM.AUTO.RECEIVER is not a cluster object.
The manually defined cluster channels are only ever *started* to join the cluster.
But they are used as the MODEL for all other cluster channels.
Set the exit properties on the CLUSRCVRs. |
|
| Back to top |
|
|
| dzifchock |
| Posted: Tue Apr 14, 2009 12:13 pm Post subject: |
|
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
ok, done ... however when i set the exit information on the cluster receiver on QM1 , the sender on QM2 looks for the config file as well as exit program on its side as well. Kinda sucks that it works that way, unless im completely missing something, and would be fine if all my queue managers were on unix.
How does one accomplish this on mixed env clusters unix/windows? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 14, 2009 12:41 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Take a look in the Cluster Manual. You need a Channel Auto Definition Exit. You're in for some fun, especially if your cluster spans z/OS, UNIX and Windows!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 14, 2009 1:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| You're in for some fun, especially if your cluster spans z/OS, UNIX and Windows! |
Just spanning Unix & Windoze will yield quite a lot of fun. If your idea of fun is fire walking, crawling over broken glass or juggling live grenades.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dzifchock |
| Posted: Wed Apr 15, 2009 6:48 am Post subject: |
|
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
| Are there any sample channel auto definition exits available from IBM or out on the web ? I've looked around and haven't been able to find anything and dont have the slightest clue about writing the exit. We are using BlockIP2 at the moment... |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 15, 2009 6:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dzifchock wrote: |
| dont have the slightest clue about writing the exit. |
This phrase, in general terms, is an indication you shouldn't try writing the exit. See my comment above about juggling live grenades. This kind of exit is a particually interesting example of the genre.
If you're trying to prevent unauthorised data moving round the cluster (like BlockIP blocks applications) I put it to you that it's better to prevent unauthorised queue managers joining the cluster, and use BlockIP to prevent applications as usual. Remember applications don't connect to clusters, they connect to queue managers some of who are members of clusters.
My personal viewpoint, other opinions may be equally valid, etc, etc
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 15, 2009 7:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Check out Capitalware's MQAUSX Exit.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| dzifchock |
| Posted: Wed Apr 15, 2009 8:05 am Post subject: |
|
|
Apprentice
Joined: 21 Feb 2007
Posts: 41
|
| Vitor wrote: |
I put it to you that it's better to prevent unauthorised queue managers joining the cluster, and use BlockIP to prevent applications as usual. Remember applications don't connect to clusters, they connect to queue managers some of who are members of clusters.
|
In order to prevent queue managers from joining the cluster, wouldn't I need to put an exit on the cluster receiver(s) for the FRs , and if the qmgrs are multiplatform wouldn't there be a need for a channel auto definition exit to accomplish that? From the clustermanual it states that there are 2 ways of stopping a qmgr from joining a cluster
"If you want to ensure that only certain authorized queue managers attempt to join a cluster, you must either use a security exit program on the cluster-receiver channel, or write an exit program to prevent unauthorized queue managers from writing to SYSTEM.CLUSTER.COMMAND.QUEUE." So looks like I will need to use an exit program on the queue in order to get by without using a CHAD exit?
Peter thanks for the suggestion, i checked it out but i definately wont get the ok for a 90k PO =( |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 15, 2009 9:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| dzifchock wrote: |
| Vitor wrote: |
I put it to you that it's better to prevent unauthorised queue managers joining the cluster, and use BlockIP to prevent applications as usual. Remember applications don't connect to clusters, they connect to queue managers some of who are members of clusters.
|
In order to prevent queue managers from joining the cluster, wouldn't I need to put an exit on the cluster receiver(s) for the FRs , and if the qmgrs are multiplatform wouldn't there be a need for a channel auto definition exit to accomplish that? |
Correct. As soon as one of your QMs is on a platform where the path to the exit location is different, you need an exit.
I also tag the MCAUSER of all CLUSRCVRs with an ID that does not have access to the SYSTEM.ADMIN.COMMAND.QUEUE. You don't want some clown trying to admin QM1 via QM2.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 15, 2009 9:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dzifchock wrote: |
| In order to prevent queue managers from joining the cluster, wouldn't I need to put an exit on the cluster receiver(s) for the FRs |
Yes. But an easier one.
| dzifchock wrote: |
| if the qmgrs are multiplatform wouldn't there be a need for a channel auto definition exit to accomplish that? |
No. Cluster membership is controlled by the manually defined channels.
| dzifchock wrote: |
| So looks like I will need to use an exit program on the queue in order to get by without using a CHAD exit? |
| dzifchock wrote: |
| i checked it out but i definately wont get the ok for a 90k PO =( |
You say that now, but after a little while developing exits it may seem like money well spent......! 
Seriously, consider the TCO of any exits you develop before you dismiss the commercial solution. Remember you'll need to review the exits with each maintenance release, and certainly on any major release. Also remember how much damage a badly behaved exit can cause, and run that risk past your budget holder.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 15, 2009 9:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| dzifchock wrote: |
| if the qmgrs are multiplatform wouldn't there be a need for a channel auto definition exit to accomplish that? |
No. Cluster membership is controlled by the manually defined channels.
|
If your FR is Windows, you need an exit on the CLUSRCVR to prevent a yo-yo creating a PR QM on his laptop and connecting to the FR. If you have legitimate QMs in your cluster on UNUX and/or z/OS, you will need a Channel Auto Def exit to make it all work.
Or use SSL and the exit issue goes away, replaced with other joyous "challenges and oppourtunities" that SSL brings 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 15, 2009 9:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| dzifchock wrote: |
| i checked it out but i definately wont get the ok for a 90k PO =( |
You say that now, but after a little while developing exits it may seem like money well spent......!
Seriously, consider the TCO of any exits you develop before you dismiss the commercial solution. Remember you'll need to review the exits with each maintenance release, and certainly on any major release. Also remember how much damage a badly behaved exit can cause, and run that risk past your budget holder. |
How many QMs do you have in this cluster? Maybe you don't need or want an Enterprise lioense. Perhaps just secure your Production QMs that are clustered? But I think you'll find MQAUSX so useful that you'll probably want it on every QM. I have no interest in Capitalware, other than being a very satisfied customer.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 15, 2009 9:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| I have no interest in Capitalware, other than being a very satisfied customer. |
Likewise - my comments are entirely philosophical.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 15, 2009 9:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Of course, if you enable SSL on your cluster channels, use SSLPEER properly and tighly control who can create and move certificates, you probably don't need an exit at all. |
|
| Back to top |
|
|
|
|
