Oh, I agree fully. Like I said earlier, client & server-side security exits are the only way to go.
This method is there only to say "we are monitoring the queues", so don't be a bad boy!!! Even if a message hangs around for only a second, we may catch it (Murphy's law - the user might get burnt).
Funny you should mention the "knucklehead" idea. I have been creating / playing around with an security exit that blocks any connection that does NOT have a UserId specified. Of course, that does not stop a user from using 'mqm' but at least it would stop blank UserIds.
Also, you could enhance BlockIP to do a combo check. If the IP comes from your VPN say 10.10.10.*, you could also check the UserId to see if it is in your list of acceptable UserIds from the VPN subnet. Of course, this is not as good as a static IP check but it is better than being wide open.
Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz
At 11:45 PM 1/8/2004, Potkay, Peter M (PLC, IT) wrote:
I would think that the below method would work great for capturing somebody that puts messages to queues where those messages hang around for a while. But what damage serious damage could a message sitting in a queue do?
The real problem I see is a user coming in as mqm can drop messages to your command queue (oh, I don't know, change all the letter Os to zeros on your connames in your SNDR channels, or delete a q or 2) and then get their replies from the temp dyn reply queue. This would not leave any trace, unless they happened to do it at the exact second that your job runs, and you browsed the message before the command server grabbed it.
I think the only solution to really stop this if the MCAUSER is to be blank is to have an exit on that channel to stop this ID.
If I had a magic wand, I would make it so that SVRCONN channels with blank MCAUSERs would default the userID to "knucklehead" if the client did not present one (instead of defaulting to mqm). Also, a new channel attribute called BlockMQM which could be turned on to reject (with no further exits or efforts) any connections coming in as mqm or MUSR_MQADMIN. Hey Paul, for Christmas 2004?!?! ;-)
I was really looking forward to using that blockIp address security exit to lockdown MQExplorer access (I got static IP address for all our team members). But, the first time I logged in from home it failed. Actually it worked as designed, and blocked me, because dialing over VPN gave me a dynamic IP address, and they tell me it has to be this way. Man, do I hope the Eclipse version of MQExplorer addresses the problem of security!
-----Original Message----- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 3:04 PM To: MQSeries List Cc: Potkay, Peter M (PLC, IT) Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Peter,
How could I charge an outrageously large hourly rate if I give out my secrets. I wish!!!! <grin>
Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for Windows) or XXXXCHIN (for OS/390 - where XXXX is the QMgr name) then you know you have a bad boy. I have created some "Q sampler programs" to look to at the UserId field of all messages in all queues. I run it in binding mode and it
browses all messages (remember to get message of length 0 - zero) and checks
the UserId field. (It is very fast!) It is setup to run 'X' times per hour (we use a random number).
The other thing you should do is to add a simple server-side security channel exit to log or better verify the incoming IP address. For a PROD box, these IP addresses should be well-known and well-defined. Here is an excellent source for a sample (see LogIP or BlockIP): http://d1o111.dk.telia.net/~u149101068/index.htm?tips_and_tricks.htm
Hope that helps.
Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz
Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>:
> " Nobody, except for MQAdmins, is allowed to use > the 'mqm' UserId (it is monitored)." > > Roger, how do you monitor that? > > > > -----Original Message----- > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 08, 2004 12:27 PM > To: [EMAIL PROTECTED] > Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > > Hi Ben, > > I believe you have some misconceptions about your JMS / JNDI values. > > First off, if you are using 'transport(client)' then you WILL be using a > SVRCONN channel - hence a MQI channel. Just because you did not specify it, > does NOT mean you are not using one. I believe the default SVRCONN channel > used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. > > Under normal circumstances, the 'MCA USER ID' field of the > 'SYSTEM.DEF.SVRCONN' > is blank. This generally means that you will be connecting / opening / > getting / putting messages under the UserId of 'mqm'. > > Secondly, you can implement a reasonable amount of MQ security in this > scenario > (of course, client & server security exits would be better). > > At my current client, developers do not have access to the JMS / JNDI tree > in > UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore, > we > code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps: > > def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415) > transport(client) ClientId(FRED) > > An alternate approach that is sometimes done (not strongly recommended) is > to > allow the developer to code the UserId in their application. > i.e. > ((Message)outMessage).setStringProperty("JMSXUserID", "FRED"); > > In either case, we apply the necessary security to the UserId 'FRED' for the > queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use > the 'mqm' UserId (it is monitored). > > We have standards that state that developers, QA people, etc are not > allowed > access to the PROD queue managers unless approved but never with the 'mqm' > UserId. We assign the appropriate authority to THEIR UserId. > > Since my client is a bank / brokage-house, it is a fire-able offense to > access > PROD data if you have not been approved. Hence, generally speaking, people > do > not risk it. > > Hope that helps. > > Regards, > Roger Lacroix > Capitalware Inc. > http://www.capitalware.biz > > > Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>: > > > Rob, > > > > thanks for the insight. > > However, a JMS application accesses a qmgr via a connection factory object > > defined in the JNDI namespace, NOT through a svrconn channel on the > server, > > i,e. it's actually not using the MQI channel. It can be seen from the > > following entry in my definition script, that it actually creates a direct > > socket connection to the host and port: > > > > def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) > > port(1415) > > > > So such a definition makes it even more dangerous since there is no more > MQ > > level security can be activated. > > > > While writing this, it became clear to me that the above is provided as an > > alternative to using MQI channel to access a remote qmgr in order to avoid > > having to define a client channel on the client side. Certainly, the above > > definition can be altered to use MQI channel instead of the host propery: > > > > def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) > > > > However, the first is a dangerous alternative. Any comment? > > > > regards, > > Ben > > > > > > > > > > > > > > > > > > > > "Wyatt, T. Rob" > > <[EMAIL PROTECTED] To: > > [EMAIL PROTECTED] > > MERICA.COM> cc: > > Sent by: MQSeries Subject: Re: Puzzled: > > MQJE001, MQRC 2102 for non-mqm users > > List > > <[EMAIL PROTECTED] > > C.AT> > > > > > > 01/05/2004 10:50 AM > > Please respond to > > MQSeries List > > > > > > > > > > > > > > Benjamin, > > > > That is because the channel used by the client is using the authority of > > the > > QMgr. Unless you put an MCAUSER or a security exit that substitutes a > > different UserID on the channel, you will get administrative rights. This > > is true of all client-connections and, yes, it is dangerous. > > > > -- T.Rob > > > > -----Original Message----- > > From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] > > Sent: Monday, January 05, 2004 9:55 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > > > > > Bob, that's a good point. I've opened a ticket with IBM on this misleading > > reason code. > > > > However, if I use client mode, the jms application needs neither +inq nor > > +connect to the qmgr, to put a message to a queue. It dosn't even need a > > +put/+get/+brose. It seems to me that in the case of MQClient, it is the > > local qmgr that actually does the puts/gets. So no authorization is needed > > at all. But this sounds too dangerous, doesn't it? > > > > regards, > > > > Benjamin F. Zhou > > Mercedes-Benz USA > > x.2474 > > > > > > > > > > > > Robert Broderick > > <[EMAIL PROTECTED] To: > > [EMAIL PROTECTED] > > OTMAIL.COM> cc: > > Sent by: MQSeries Subject: Re: Puzzled: > > MQJE001, MQRC 2102 for non-mqm users > > List > > <[EMAIL PROTECTED] > > .AC.AT> > > > > > > 01/02/2004 03:39 > > PM > > Please respond to > > MQSeries List > > > > > > > > > > > > > > Still....the unanswered question > > > > Why the 2102???? Is something looping. I cannot see why insufficient > access > > authority would generate this type of error. It seems there is an > > unresolved > > bug. > > > > About 2 months ago there was a discussin on the +inq for the JMS stuff and > > if I remember correctly the person at that time was not getting a 2102. > > > > > > bobbee > > > > > > >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Date: Fri, 2 Jan 2004 13:40:13 -0600 > > > > > >When this happened to us, my developers were not printing the linked JMS > > >exception so I did not have a reason code to look at. If I had been > given > > >a > > >2102, it sure would have thrown me off! I like to keep the events turned > > >on > > >so when I was presented with the problem I very quickly found an event > > >message showing the UserID, the QMgr INQ call and a 2035. Discussion > with > > >the user revealed that any QMgr inquiry calls were happening inside the > > >Java > > >classes and not in his code. We have since learned that Java will > inquire > > >on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it > > >has to back out a GET. > > > > > >-- T.Rob > > > > > >-----Original Message----- > > >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] > > >Sent: Friday, January 02, 2004 2:24 PM > > >To: [EMAIL PROTECTED] > > >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > > > > > > > >Hi Rob, > > > > > >Great ! Your tip on adding inq right to non-mqm users did the trick. > Here > > >is the setmqaut command: > > > > > > setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq > > > > > >But how did you know that a JMS appl needs inq right to the qmgr to > > >establish connection? I didn't find such information on the JMS manual. > > > > > >thanks a lot for the insight ! > > > > > >Ben > > > > > > > > > > > > > > > > > > > > > > > > "Wyatt, T. Rob" > > > <[EMAIL PROTECTED] To: > > >[EMAIL PROTECTED] > > > MERICA.COM> cc: > > > Sent by: MQSeries Subject: Re: Puzzled: > > >MQJE001, MQRC 2102 for non-mqm users > > > List > > > <[EMAIL PROTECTED] > > > C.AT> > > > > > > > > > 01/02/2004 12:44 PM > > > Please respond to > > > MQSeries List > > > > > > > > > > > > > > > > > > > > >Benjamin, > > > > > >Are the classpaths the same between the two UserIDs? If you are on Unix, > > >try > > > > > >echo $CLASSPATH | tr ":" "\n" > > > > > >...from each user's command line and compare. There are generally two > > >types > > >of problems that manifest themselves differently under different users - > > >security, which you covered, and environment. > > > > > >Incidentally, you did not mention whether you gave the user Inquire on > the > > >QMgr and queues. JMS will inquire the QMgr right after connecting. This > > >usually generates 2035's though. > > > > > >-- T.Rob > > > > > >-----Original Message----- > > >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] > > >Sent: Friday, January 02, 2004 11:48 AM > > >To: [EMAIL PROTECTED] > > >Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > > > > > > > >Hi, > > > > > >first, happy new year to everyone. > > > > > >while trouble-shooting a WAS application's MQRC2102 problem, I wrote a > > >simple jms program to put msg to a queue. > > > > > >The program runs without problem if I start it as "mqm", but if I logon > as > > >a different user than mqm, got the same MQJE001, MQRC 2102 exception. > > >I explicitely allowed that user the right to connect to the same qmgr and > > >put/get to the queues, and run the sample executible amqsput, amqsget > > >without any problem. > > > > > >MQRC 2102 is resource problem, but I don't understand why it happen to > WAS > > >users, but not to mqm, and only happens to jms applications. > > > > > >Any idea would be greatly appreciated. > > > > > >Benjamin F. Zhou > > >Messaging & Integration > > >Research & Technology, ITM > > >Mercedes-Benz USA > > >x.2474 > > > > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If > you are not the intended recipient, please notify the sender > immediately by return email and delete this communication and destroy all > copies. > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive >
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
