Re: More Client Channel Security - was Puzzled: MQJE001, MQRC 2102 fo r non-mqm users
> Man, do I hope > the Eclipse version of MQExplorer addresses the problem of security! What eclipse version of MQExplorer??? Do tell... Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Potkay, Peter M (PLC, IT) Verzonden: vrijdag 9 januari 2004 5:46 Aan: [EMAIL PROTECTED] Onderwerp: More Client Channel Security - was Puzzled: MQJE001, MQRC 2102 fo r non-mqm users 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 Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for Windows) or CHIN (for OS/390 - where 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) > tran
Re: More Client Channel Security - was Puzzled: MQJE001, MQRC 2102 fo r non-mqm users
Hi, 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 Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for Windows) or CHIN (for OS/390 - where 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 cur
More Client Channel Security - was Puzzled: MQJE001, MQRC 2102 fo r non-mqm users
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
Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for
Windows) or CHIN (for OS/390 - where 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.
>
>
