| Author |
Message
|
| eswarnv |
 Posted: Fri Nov 21, 2003 6:35 pm Post subject: How to prevent a queue manager from remote admin in solaris? |
 |
|
Voyager
Joined: 20 Dec 2001
Posts: 88
|
HI
Can any one help me in the following.
I am exploring remote admin of a queue manager. In windows I created all the required objects and it is working fine. My doubt is in MQSeries Explorer I have an option to prevent the queue manager from remote administration even though the required objects are present. How to do the same in solaris.????
Thanks in advance
Eswar. |
|
| Back to top |
|
 |
| EddieA |
| Posted: Fri Nov 21, 2003 7:01 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
All that does is delete the SYSTEM.ADMIN.SVRCONN channel.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| leongor |
| Posted: Sun Nov 23, 2003 1:25 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
Do not start Command Server on the queue manager's machine.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Nov 24, 2003 5:44 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Dont place any remote userids in the mqm group
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| JasonE |
| Posted: Mon Nov 24, 2003 1:35 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Think security - The Explorer does nothing 'unusual' which could not be achieved by other programmers in other languages when in remote mode. There was at one point, for example, a version written in Java.
So disabling the system.admin.svrconn would stop the explorer, but not anyone else. Disabling the command server would prevent any PCF commands from any source. Also think about securing the svrconn channels to only let in who you want. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Nov 24, 2003 10:12 pm Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Just curious how can you setup svrconn channels to only let in who you want ???
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue Nov 25, 2003 2:49 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| I think you would need to have channel exit(s) to provide such security (possibly SSL would help here, it would certainly stop explorer, and you could only allow people with appropriate certificates in) |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Nov 25, 2003 5:47 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Jeff,
"Just curious how can you setup svrconn channels to only let in who you want ???"
You could achieve this by specifying a userid of your choice that you setup on the desitnation system with specific authority in MCAUSER attribute of the svrconn channel.
And i believe you could achieve enough security to allow only known users through that route.
The other way to handle this is, to define principals with appropriate authorities on the destination system and keeping the MCAUSER attribute of the svrconn channel blank. This way, even if anyone tries to connect to this qm to perform any admin functions, they must have an appropriate userid/principal with authorizations to do that. This way you could control who can and who cannot.
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| cmdmqm |
| Posted: Sat Dec 06, 2003 7:01 am Post subject: |
|
|
Novice
Joined: 04 Feb 2002
Posts: 24
Location: Berlin
|
| mqonnet wrote: |
The other way to handle this is, to define principals with appropriate authorities on the destination system and keeping the MCAUSER attribute of the svrconn channel blank. This way, even if anyone tries to connect to this qm to perform any admin functions, they must have an appropriate userid/principal with authorizations to do that. This way you could control who can and who cannot.
|
The problem is that if you use eg. MQJExplorer, it doesn't have a specified user id (MQExplorer does - it's the current user id with witch you logged in to your Windows). If no user id is specified, the user id of the one who started the channel jobs is taken - this is on AIX the mqm user, which of course has to have all right possible, otherwise it wouldn't be able to start the processes. So if you connect to the queuemanager without a userid, you automatically have all rights.
MQ therefore has no "built in" security, you either have to disable remote administration, use external tools or channel exits.
Bye
cmdmqm |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Sat Dec 06, 2003 8:52 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Quote: |
| MQ therefore has no "built in" security, you either have to disable remote administration, use external tools or channel exits |
.
MQ used to be 'pretty' secure, until the arrival of the java clients. AFAIK the inheritance of the user authority that runs the listener only happens with java clients that do not provide a userid.
I am still surprised IBM never fixed this 'BUG'...
my 2 cents...
Michael |
|
| Back to top |
|
|
| JasonE |
| Posted: Sun Dec 07, 2003 2:17 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Actually thats incorrect. 'Old' clients had this ability until such time we could reliably get a signed on user.
Also, consider the fact that any user can install a windows machine and define any specific user name they want on it and use that userid to come into your MQ configuration. Is this any different to writing a java pgm which sends that userid in instead?
Basically you must view clients as insecure, then you have a better chance of securing your environment. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Sun Dec 07, 2003 2:28 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Jason,
thanks for your comments. I know clients can be insecure and a user in a windows environment can setup local users like mqm... that's why i used the phrase 'pretty' secure.
IMHO with the introduction of the java clients the door was put WIDE open...
there is still a difference between a user trying to fool the system and this grand reception for any java client that is not 'willing' to supply a userid and then have that unidentified user 'inherit' the authority of the listener (which is usually mqm...).
On the listener subject... what is the minimum authority required for the listener?
Michael |
|
| Back to top |
|
|
| cmdmqm |
| Posted: Mon Dec 08, 2003 1:00 am Post subject: |
|
|
Novice
Joined: 04 Feb 2002
Posts: 24
Location: Berlin
|
| MichaelDag wrote: |
MQ used to be 'pretty' secure, until the arrival of the java clients. AFAIK the inheritance of the user authority that runs the listener only happens with java clients that do not provide a userid.
|
That's a problem of every programming language, not just Java. It was a security flaw (or a design flaw) which came to the mind of MQ users maybe through the upcoming of clients like MQJExplorer. But they didn't "open" that security hole, it was always there. Before it was "security by obscurity". |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Tue Dec 09, 2003 3:24 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
I did write a small (and free) security exit, all it does is checking the connection name, and if there are a match, it passes the call, else just die the communication.....
This is not the max security level to archive here, but it's bette than nothing, and it logs even the connection attempt and who did it ;o)
http://home19.inet.tele.dk/m-invent/tips_and_tricks.htm#BlockIP%20security%20exit
I know some friends using it on Solaris...
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
|
|
