| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Is an ANONYMOUS connection possible in MQ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jeevan |
 Posted: Sat Aug 15, 2009 4:27 pm Post subject: |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
| Quote: |
| Does mq allow to connect and put /get mesage to a blank user? |
Yes.
As delivered from IBM and installed, WMQ is completely unsecured. Unless you do something to secure WMQ, it is completely unsecured. This is well documented. WMQ relies on OAM, or whatever underlying security component your o/s uses. Refer to the WMQ Security manual. |
I am really sorry. I amnot sure how it posted double. |
|
| Back to top |
|
 |
| jeevan |
| Posted: Sat Aug 15, 2009 5:24 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
| Quote: |
| Does mq allow to connect and put /get mesage to a blank user? |
Yes.
As delivered from IBM and installed, WMQ is completely unsecured. Unless you do something to secure WMQ, it is completely unsecured. This is well documented. WMQ relies on OAM, or whatever underlying security component your o/s uses. Refer to the WMQ Security manual. |
Does not this contradict with what you said:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12200_.htm
Controlling access (Windows only)
When you install WebSphere® MQ, default access permissions are set up for the AMQMSRVN process. These default access permissions grant access to the process to:
mqm (local WebSphere MQ administrators group)
Administrators (local administrators of this machine) (Windows® only)
These permissions restrict access to the alert monitor task bar application and the amqmdain command to these users and groups only. Other users trying to access these functions are denied access. The WebSphere MQ Explorer uses amqmdain to start and end queue managers. If the WebSphere MQ Explorer is run by a user not authorized to run amqmdain, then an error is reported when the user attempts to start or stop a queue manager.
Before users run the WebSphere MQ Explorer, you must configure the access permissions of the objects involved. Use a tool called DCOMCNFG.EXE, shipped with Windows systems, to do this.
what is the missing link? What am I missing to grasp?
Last edited by jeevan on Sat Aug 15, 2009 5:30 pm; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 15, 2009 5:26 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Hello. There is really nothing to elaborate on. Yes, it takes membership in mqm or root to install and administer WMQ.
Once you have created a qmgr and objects, unless you do something to grant/revoke application access to the MQI calls (MQCONN, MQOPEN, ...), there is no application-level or channel-level security; which means that the qmgr and its objects are unsecured. Which means that anything that can access the o/s can access anything MQ.
However unlikely it might seem... is the o/s secured? Are all users required to authenticate - provide a username/password? Can you telnet to the o/s without username/password?
This has been discussed here many, many times. Please read the WMQ Security manual.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 15, 2009 5:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Your most recent post described administrative tasks; and yes, you need mqm or Administrator priviledge to use administrative tools.
You are confusing administrative tools with end-user applications (payroll, a/p, etc).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jeevan |
| Posted: Sat Aug 15, 2009 5:35 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
Hello. There is really nothing to elaborate on. Yes, it takes membership in mqm or root to install and administer WMQ.
Once you have created a qmgr and objects, unless you do something to grant/revoke application access to the MQI calls (MQCONN, MQOPEN, ...), there is no application-level or channel-level security; which means that the qmgr and its objects are unsecured. Which means that anything that can access the o/s can access anything MQ.
However unlikely it might seem... is the o/s secured? Are all users required to authenticate - provide a username/password? Can you telnet to the o/s without username/password?
This has been discussed here many, many times. Please read the WMQ Security manual. |
I already mentioned in my first post. This is a production box and is in dmz. The access is only through firewall rule. |
|
| Back to top |
|
|
| jeevan |
| Posted: Sat Aug 15, 2009 5:35 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
Hello. There is really nothing to elaborate on. Yes, it takes membership in mqm or root to install and administer WMQ.
Once you have created a qmgr and objects, unless you do something to grant/revoke application access to the MQI calls (MQCONN, MQOPEN, ...), there is no application-level or channel-level security; which means that the qmgr and its objects are unsecured. Which means that anything that can access the o/s can access anything MQ.
However unlikely it might seem... is the o/s secured? Are all users required to authenticate - provide a username/password? Can you telnet to the o/s without username/password?
This has been discussed here many, many times. Please read the WMQ Security manual. |
I already mentioned in my first post. This is a production box and is in dmz. The access is only through firewall rule. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 15, 2009 5:36 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
A quick search on Mr. Google for windows+anonymous yielded a variety of known security exposures on a variety of Windows platforms. I'm guessing that you are likely running an older version of Windows.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 15, 2009 5:44 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I already mentioned in my first post. This is a production box and is in dmz. The access is only through firewall rule. |
Security is like an onion - with many layers to achieve effective security.
Clearly, someone/something is getting anonymous access to the box.
If you have no local/domain security rules preventing application-level access to the qmgr and its objects, then anyone with legitimage dmz access can do whatever to mq on the box. This is like giving a trades-person a key to your front door; but not locking up the expensive silver.
You stated early on that dspmqaut/dmpmqaut produced no rules granting/denying access to mq things. Therefore, no application-level (not admin) mq security at all.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jeevan |
| Posted: Sat Aug 15, 2009 5:51 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
| Quote: |
| Does mq allow to connect and put /get mesage to a blank user? |
Yes.
As delivered from IBM and installed, WMQ is completely unsecured. Unless you do something to secure WMQ, it is completely unsecured. This is well documented. WMQ relies on OAM, or whatever underlying security component your o/s uses. Refer to the WMQ Security manual. |
I appreciate if you can comments in the follwoing discussion as these are the points I am making:
Hello,
I have some questions about security on an MQServer.
1. The users that are referred to, are they LOCAL users or DOMAIN users? (I guess they are local users)
2. When connecting from a certain client to an MQSeries Queue manager, what user/password is used? How to define it?
3.I have here the following situation:
We have 5 servers with a Queue manager on each of it (SC1 - SC5). I can connect to the queue managers SC2 to SC5, with my client PC. When I look at the administrators group & mqm group on the servers (which is also a PDC, hence my first question), I am a member of the administrators group and the mqm group is empty. So I'd guess, since I'm a member of the administrators group on that server, I should be able to connect to ALL the queue managers, ALSO to SC1, to which I can not connect at the moment (error message 4036 'you are not authorized to perform this operation'). Am I missing something here?
4. Another question is about MCAUSER:
When I connect from a client, using a server connection channel that has an MCAUSER (say, MQMCAUser), does it connact by the MQMCAUser then? So anyone that knows the name of that server connection channel can connect, even without knowing any password, or being member of the mqm or administrators group, whatsoever?? I guess that is rather UNSAFE??
Answer:
1) Local.
2) Your logon id on the client system is passed in by default. You can change it within your app using ALTERNATEUSERID.
3) When you connect to the server system using a client, your logon id is passed over. If you DO NOT have a userid defined on the server system, then you would get a 2035. You would get this even when this userid on server has not been granted appropriate authority.
4) You got it. Thats the reason its advisible to leave MCAUSER attribute blank and grant appropriate auths to those whom you wish to allow to access this channel and mq objects.
This is what exactly i am making. When the app passes the id( which is not authorised) how can it access the mq?
But I am not sure if the app does not pass any user id. Our app is written in java. It is request/reply app( not permanent listener) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 15, 2009 6:14 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Since you said that dspmqaut yielded NO rules for mq objects, then there will be no 2035 reason codes returned (for non-admin userids). This includes MCAUSER().
If you specify a name in MCAUSER(name), AND you have granted/denied authority with setmqaut, THEN the name specified will be used instead of the username passed from the client platform. This is discussed in both WMQ Security and WMQ Clients manuals.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 16, 2009 3:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| jeevan wrote: |
| But I am not sure if the app does not pass any user id. Our app is written in java. It is request/reply app( not permanent listener) |
This has been discussed multiple times in this forum.
If you do not set an mcauserid on the svrconn channel and do not pass a userid the channel will run with the authority of the channel initiator (by default mqm ).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jeevan |
| Posted: Sun Aug 16, 2009 6:26 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| fjb_saper wrote: |
| jeevan wrote: |
| But I am not sure if the app does not pass any user id. Our app is written in java. It is request/reply app( not permanent listener) |
This has been discussed multiple times in this forum.
If you do not set an mcauserid on the svrconn channel and do not pass a userid the channel will run with the authority of the channel initiator (by default mqm ).
Have fun |
I understand that and agree with you without any doubt.
http://t-rob.net/Downloads/2008IMPACT1312HardeningWMQ.pdf
T rob also emphasises this fact in his preseentation.
Howeverm, what I was confused was that I have read somewhere that a java app always passes an user id. If not set explicitely, it will passes the logged in user id. that is why I am so much confused.
OUr app is written in java. The same app when picks message from a jms queue has a user id and password. Tibco has a command to see the message producer and consumer in a queue.
In mq, we can only see security set with amqoand or dmpmqaut command. Both of these commands do not show any user permitted to these queues and connections to the queue manager. Also, windows event viewer/security shows a ANONYMOUS connection with category 3 which is a connection from a port.
By now, I am agreeing that our app is not passing an id. MCAUSER being blank, it goes and put a message with full mqm permission.
I am in fact writing this to the app ower and my manager. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 16, 2009 7:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| In mq, we can only see security set with amqoand or dmpmqaut command. Both of these commands do not show any user permitted to these queues and connections to the queue manager. |
For regular application programs, application objects, and application users - meaning non-administrative users, everything is permitted unless and until you setmqaut to revoke access.
RULE number 1: MQ is unsecured unless you do something. The only exception to this rule is administrative tasks (MQExplorer, runmqsc, amqoamd, setmqaut, script commands, etc.). These are secured to mqm group by the installation process.
Once you start creating objects, you will need to setmqaut to grant/deny access to objects - as your business rules dictate.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Sun Aug 16, 2009 7:25 am; edited 2 times in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Aug 16, 2009 7:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jeevan wrote: |
| Howeverm, what I was confused was that I have read somewhere that a java app always passes an user id. If not set explicitely, it will passes the logged in user id. that is why I am so much confused. |
Not in v5.3.
I forget if that's a change in v6 or v7. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 16, 2009 7:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Let me try to explain it this way:
mqm group members have explicit access to everything.
With NO setmqauts, non-mqm users have application-level (MQI or equivalent) access to all qmgrs and all objects.
With NO setmqauts, it makes no difference whether MCAUSER() is blank or non-blank since no rules deny access to MCAUSER(name).
With NO setmqauts, it makes no difference what username/password the user logs in with because there are no groups/principals authorizations to deny access to qmgrs and objects.
Non-mqm users cannot use MQ admin applications.
Firewall rules do not apply to MQ qmgrs or mq objects; rather, firewall rules apply to ipaddresses, ports, protocols, etc..
(If someone can explain this better, please do so.)
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
