| Author |
Message
|
| Vitor |
 Posted: Mon Jan 26, 2009 5:39 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| masteringmq wrote: |
| Actually our customer is our company itself. |
Makes no difference. The majority of most successful attacks originate from inside the network boundary.
I include attempts to define or modify objects by well meaning but non-authorised people in "attacks" in this context.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jan 26, 2009 9:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
One other layer in the security onion:
You could stop the command server (endmqcsv) on production qmgrs until administration is required. A simple application can MQINQ on the SYSTEM.COMMAND.INPUT.QUEUE before starting the command server, and then consume and discard any errant messages in the queue before starting the command server (strmqcsv).
Alternatively, you could PUT(INHIBIT) the command queue so that errant applications trying to MQPUT PCF messages in the queue would fail. Then use an aplication to PUT(ENABLE) it when administration is needed.
_________________
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 |
|
|
| zhanghz |
| Posted: Tue Jan 27, 2009 7:34 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
Hi guys, I am back and I tested RCVR with non-existing ID in MCSUSER on a z/OS QMGR with security switches on.
The channel (RCVR on z/OS qmgr and SDR on my laptop windows qmgr) is still in RUNNING status.
The test setup is:
Created RCVR channel on z/OS qmgr; created SDR channel on windows qmgr.
z/OS qmgr has the following in MSTR log:
NO.SUBSYS.SECURITY' not found
NO.CONNECT.CHECKS' not found
NO.CMD.CHECKS' not found
NO.CONTEXT.CHECKS' not found
NO.ALTERNATE.USER.CHECKS' not found
NO.CMD.RESC.CHECKS' not found
NO.PROCESS.CHECKS' not found
NO.NLIST.CHECKS' not found
NO.QUEUE.CHECKS' not found
I put "TTTTTTT" in MCAUSER for z/OS RCVR channel. "TTTTTTT" is not a ID defined in z/OS RACF. I stopped channles on both sides, started them both, the channels are running.
Anything I miss here? How come channels are still running? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 27, 2009 7:45 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Likely so.
Find your RACF administrator.
Refer him/her to the WMQ z/OS System Setup Guide (v6), Task 11, and Part 5 Setting up security.
There's much to do. As with everything else mainframe, it's different and more complicated than Windows and UNIX.
_________________
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 |
|
|
| zhanghz |
| Posted: Tue Jan 27, 2009 10:05 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
Our RACF people will only do what we ask them to do.. They won't read the whole section of manual for MQ RACF.
I have roughly gone through Part 5 on RACF security. I think I am lost. What I understand is:
1) 'qmgr.NO.CONNECT.CHECKS' not found, meaning RACF is checked before connection can be made
2) MQADMIN.RESLEVEL is set to blank, meaning RACF check is not bypassed
3) Then I don't understand why MCAUSER "TTTTTTT" is able to start the RCVR channel.
How to achieve what Peter mentioned below?
| PeterPotkay wrote: |
Put a bogus ID in the MCAUSER of the RCVR channel and watch the SNDR retry. |
I tried setting MCAUSER to "TTTTTTT" for the SDR channel on my laptop Windows qmgr. THe SDR channel is also still running. Is it that MCAUSER does not apply to SDR channel??
Please advise. |
|
| Back to top |
|
|
| zax |
| Posted: Tue Jan 27, 2009 10:50 pm Post subject: |
|
|
Newbie
Joined: 20 Jan 2009
Posts: 2
|
From the Command Ref manual
| Quote: |
If it is nonblank, it is the user identifier that is to be used by the message channel agent for authorization to access WebSphere MQ resources, including (if PUTAUT is DEF) authorization to put the message to the destination queue for receiver or requester channels.
|
MCAUSER is used to authorise a user to open queues and put msgs, not to start channels. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Tue Jan 27, 2009 11:00 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| zax wrote: |
From the Command Ref manual
| Quote: |
If it is nonblank, it is the user identifier that is to be used by the message channel agent for authorization to access WebSphere MQ resources, including (if PUTAUT is DEF) authorization to put the message to the destination queue for receiver or requester channels.
|
MCAUSER is used to authorise a user to open queues and put msgs, not to start channels. |
It says "including" opening queue and putting to queue, so "access WebSphere MQ resources" must access other resources too, i assume connection included... |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Jan 27, 2009 11:22 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
It is all documented in the MQ Security manual, chapter "channel security", for MQV6 it starts at page 43. There are also plattform depencencies here, e.g. on z/OS, the userid that is checked for the queuemanager connect of the MCA is the userid of the channel initiator started task, not the MCAUSER defined in the channel.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 28, 2009 12:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| bruce2359 wrote: |
Likely so.
As with everything else mainframe, it's different and more complicated than Windows and UNIX. |
Strange - I find the opposite is true. But then I know RACF down to the assembler macro level. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Wed Jan 28, 2009 1:55 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
[EDIT]Now think about it, what I quoted here do not seem to be relevant to what I was testing.. Just take note please. [/EDIT]
Thanks, Mr Butcher, yes, MQ Security manual states:
| Quote: |
| On z/OS, every task in the channel initiator address space that needs to connect to the queue manager does so when the channel initiator address space is started. This includes the dispatcher tasks that run as MCAs. The channel initiator address space user ID is used to check the authority of a task to connect to the queue manager. |
z/OS MQ System Setup manual also mentions in Chapter 15,
| Quote: |
Connection type: Channel initiator connection
User ID contents: The channel initiator address space user ID. |
So it's safe to say what Peter mentioned is not true for z/OS channels as MCAUSER is not used to check for connection authority:
| Quote: |
Put a bogus ID in the MCAUSER of the RCVR channel and watch the SNDR retry. |
So what I told application team was not wrong after all. 
Last edited by zhanghz on Wed Jan 28, 2009 10:42 pm; edited 2 times in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 28, 2009 4:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 28, 2009 5:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Check for the existence of the ssid.CHIN profile.
Check for the existence of ssid.RESLEVEL. With the appropriate RESLEVEL, zero, one or more ids can be checked.
As you have discovered (and as well-documented), WMQ security it wide open after installation of the product.
| Quote: |
| Our RACF people will only do what we ask them to do.. They won't read the whole section of manual for MQ RACF. |
Sounds like you have an opportunity to visit with RACF management and ask them for help.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jan 28, 2009 6:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zhanghz wrote: |
| Our RACF people will only do what we ask them to do. |
I consider you fortunate. I have bitter memories of the day the RACF team on one site decided to tighten security on the dev LPAR by granting access only "on properly justifed need". To enforce this new order they deleted all the RACF profiles at 10:30 one Wednesday morning and replaced them with a single global profile *.* UACC(NONE). Naturally they told no-one (presumably for security reasons) nor finalised the procedure for requesting access.
Thankfully (if selfishly) I was only editing a small piece of JCL in ISPF at the time, rather than the somewhat larger COBOL programmes in use on the site. The sound of 200 developers screaming as one is a blood-chilling sound.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 28, 2009 6:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
I worked at a site where the RACF folks decided to try PROTECT ALL UNPROTECTED in production - without trying it first in TEST. There were lots of so-called unprotected resources, like: CICS signon transaction, all terminal sessions, most of DB2.
And when I mentioned that mainframes are more complicated, what I meant was that they are more robust.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jan 28, 2009 6:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| And when I mentioned that mainframes are more complicated, what I meant was that they are more robust. |
i.e. you need a fairly high level of knowledge & access to stuff them up!
Plus the detailed auditing ensures greater levels of future robustness by ensuring the guilty are found and punished. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
