Author |
Message
|
mhubbard |
Posted: Fri May 27, 2011 9:42 am Post subject: Separating Channel Access |
|
|
 Acolyte
Joined: 25 Aug 2004 Posts: 54
|
Hello -
I have several v6 queue managers that were configured some time ago with SSL channels that client applications out on the internet use to connect from "the outside world". On these same queue managers, there is a non-ssl channel that is used by server side programs to connect.
I'm struggling to find a way to ....basically connect a given channel to a particular port. It seems that as soon as you start up a listener on whatever port, you have access to any channel via that port. Is there any way to do this? What it boils down to is I am trying to make my local non-ssl channel inaccessible from the outside. _________________ Michael J. Hubbard |
|
Back to top |
|
 |
mqjeff |
Posted: Fri May 27, 2011 9:55 am Post subject: Re: Separating Channel Access |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
mhubbard wrote: |
Hello -
I have several v6 queue managers that were configured some time ago with SSL channels that client applications out on the internet use to connect from "the outside world". On these same queue managers, there is a non-ssl channel that is used by server side programs to connect.
I'm struggling to find a way to ....basically connect a given channel to a particular port. It seems that as soon as you start up a listener on whatever port, you have access to any channel via that port. Is there any way to do this? What it boils down to is I am trying to make my local non-ssl channel inaccessible from the outside. |
You can't.
So make it SSL and configure it with to only accept a DN that matches an internal certificate and explicitly doesn't match the external certs in any way.
or disable it, and set up a second qmgr on a different port that is only open to the inside, and do all of your admin work via that qmgr. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri May 27, 2011 9:56 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Nope. If you have access to a QM's port, you then have access to every incoming channel on that QM, so they all need to be protected or disabled. You're only as strong as your weakest link. Leave one channel unprotected and you are wide open.
You could give your open channel some goofy name and hope the outside world never figures it out, but that's lame. Security through obscurity ain't the way. It wouldn't take that long for some automated program to try every possible 20 character channel name. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mhubbard |
Posted: Tue May 31, 2011 12:06 pm Post subject: |
|
|
 Acolyte
Joined: 25 Aug 2004 Posts: 54
|
Wow.
And I guess since I don't see any port specification on my cluster sender / receiver channels that those are included also. Ouch. _________________ Michael J. Hubbard |
|
Back to top |
|
 |
mqjeff |
Posted: Tue May 31, 2011 12:25 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
mhubbard wrote: |
Wow.
And I guess since I don't see any port specification on my cluster sender / receiver channels that those are included also. Ouch. |
ALL channels on a given Qmgr are available over ALL listener ports on that qmgr (there is usually not more than one listener port).
Including SYSTEM.DEF.SVRCONN... |
|
Back to top |
|
 |
|