| Author |
Message
|
| kats |
 Posted: Wed Jan 10, 2007 11:57 am Post subject: Disabling System* Svrconn channels |
 |
|
Voyager
Joined: 20 Apr 2006
Posts: 78
|
SunOS 5.9, MQ 5.3 CSD12
The Audit agency requires that all SYSTEM* channels with CHLTYPE(SVRCONN) be disabled by putting a garbage value in MCAUSER attribute of these SVRCONN channels.
I'm just making sure that these channels are not under use by any application. Now, "On server level", what are the clues MQ admin can get about the determining whether these channels are under use or no.
I tried:
1. dis chs(SYSTEM.DEF.SVRCONN)
AMQ8420: Channel Status not found.
(So this is not active)
2 : dis CHANNEL(SYSTEM.DEF.SVRCONN)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN)
TRPTYPE(TCP) DESCR( )
SCYEXIT( ) MAXMSGL(4194304)
SCYDATA( ) HBINT(300)
SSLCIPH( ) SSLCAUTH(REQUIRED)
KAINT(AUTO) MCAUSER( )
ALTDATE(2005-11-12) ALTTIME(09.36.01)
SSLPEER()
SENDEXIT( )
RCVEXIT( )
SENDDATA( )
RCVDATA( )
So far I've checked these.
Ofcourse to make sure I'll check with application team, but just wondering, what more can I do as a MQ admin on server level. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jan 10, 2007 12:30 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If it's not running, it's not in use.
Even if it's in use, you can change the MCAUSER. The *next* time someone goes to connect, then the new MCA will take effect.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kats |
| Posted: Wed Jan 10, 2007 12:39 pm Post subject: |
|
|
Voyager
Joined: 20 Apr 2006
Posts: 78
|
| Quote: |
| Even if it's in use, you can change the MCAUSER. The *next* time someone goes to connect, then the new MCA will take effect |
I inferred, as in my case, the application will NOT be able to connect to that SVRCONN channel. That's one way of doing it. but that will generate lot of noise(as lot of tickets will be generated)
So I guess, contacting application team is the best bet or perhaps the only solution. So even if they stumble aferwards, that's not my problem 
Thanks Jeff for a quick response. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Jan 10, 2007 8:36 pm Post subject: Re: Disabling System* Svrconn channels |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| kats wrote: |
| The Audit agency requires that all SYSTEM* channels with CHLTYPE(SVRCONN) be disabled by putting a garbage value in MCAUSER attribute of these SVRCONN channels. |
Do you have other SVRCONN channels? If so, then what you are doing is pointless.
i.e. You've shut the front door but all other doors to the house are wide-open.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 11, 2007 7:27 am Post subject: |
|
|
Guest
|
Auditors should not specify exactly what steps to take, what software to implement, to effect a change. Auditors recommend; they don't mandate.
I'd push back - a little. (I mean, train them to do their job appropriately)
Ask them exactly what business exposure they believe exists. They should respond in writing to be ocnsidered a legitimate audit-item - one to which you should respond - in writing.
Then you, along with your management, should evaluate possible alternative resolutions (if you believe that one is necessary), then implement one of your choosing.
Disabling CHAD or implementing SSL might make more sense. There are always alternatives.
If you believe their recommendation doesn't make sense for the business, respond (in writing) with your business-case and your recommendations. It's good practice to know why you are doing what you are doing; and writing about it gives you creditility.
Auditors can be a great asset, if you train them. I've used them to keep IT management from creating security exposures and other stupid behaviors (like integrating unsecured networks, implementing untested programs, buying inappropriate hardware. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 11, 2007 7:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd be interested to hear your explanation of how disabling CHAD will increase security or reduce exposures to misuse of SYSTEM.DEF.SVRCONN by unapproved applications.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kats |
| Posted: Thu Jan 11, 2007 8:06 am Post subject: |
|
|
Voyager
Joined: 20 Apr 2006
Posts: 78
|
| Quote: |
Do you have other SVRCONN channels? If so, then what you are doing is pointless.
i.e. You've shut the front door but all other doors to the house are wide-open. |
Agreed. Only external party has to work little harder to know the "name" of the channel we've defined.
Our goal is:
To disable all System* SVRCONN channels.
To Implement SSL on all User defined SVRCONN as well as MCA channels; which is another recomendation/requirement(I don't know which one) of audit agency.
I'm thinking of applying SSL and NOT implement Channel Exits. Any comements over that. Am I leaving any security hole by not implementing Exits.
bruce2359, Could you pls throw little more light on CHAD parameter. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 11, 2007 1:12 pm Post subject: |
|
|
Guest
|
Here you go...
From the MQ Clients manual:
Automatically defined channels:
WebSphere MQ products on platforms other than z/OS include a feature that can automatically create a channel definition on the server if one does not exist.
If an inbound attach request is received from a client and an appropriate server-connection definition cannot be found on that queue manager, WebSphere MQ creates a definition automatically and adds it to the queue manager. The automatic definition is based on the definition of the default server-connection channel SYSTEM.AUTO.SVRCONN. You enable automatic definition of server-connection definitions by updating the queue manager object using the ALTER QMGR command with the CHAD parameter (or the PCF command Change Queue Manager with the ChannelAutoDef parameter).
For more information about the automatic creation of channel definitions, see the WebSphere MQ Intercommunication book. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jan 11, 2007 1:42 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
interesting I always thought CHAD applied to Cluster channels... so you cannot join a cluster automatically...
I believe the default setting is DISABLED anyway.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 11, 2007 2:40 pm Post subject: |
|
|
Guest
|
| Michael Dag wrote: |
interesting I always thought CHAD applied to Cluster channels... so you cannot join a cluster automatically...
I believe the default setting is DISABLED anyway. |
CHAD(DISABLED) is the default now. ENABLED was the default when CHAD was first deployed long ago. Yikes! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 11, 2007 2:57 pm Post subject: |
|
|
Guest
|
Kats, in his/her original post, wondered if "...these channels are not under use by any application."
SVRCONN channels on the qmgr are used to service client connections (non-client connection table). If you create a client-connection table, and export it to your client platforms, and use it for your client application connections, CLNTCONN channels are used - not SVRCONN.
So, if you don't use an MQ client (non-client connection table) to run applications, you are home free.
This is back to auditor behavior. Telling you to disable all SVRCONN channels may mean no longer supporting client applications. Again, SSL, disabling CHAD, together with channel exits, may provide sufficient security to meet the auditors perceived security exposure (if one exists). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 11, 2007 6:42 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bruce2359 wrote: |
| CLNTCONN channels are used - not SVRCONN. |
All MQ channels come in pairs - Sender/Receiver, Server/Requester, Clussdr/Clusrcvr, SVRCONN/CLNTCONN.
The CLIENTCONN channel type is the definition of the client half of the channel. When you use the MQSERVER environment variable or the MQEnvironment class in the object oriented interface, or MQCONNX - you are defining a CLNTCONN in one way or another.
When you use the client channel table, you are allowing your MQ administrator to create the CLNTCONN.
In all cases, there is always a SVRCONN instance running on the server side.
MQ channels come in pairs.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 12, 2007 7:34 am Post subject: |
|
|
Guest
|
Jeff says: All MQ channels come in pairs
Yep. You got me! And this will teach me to not attempt to do three things concurrently - one of which is post.
What I was getting at (skipping over my technical screwup) was what appears to be the auditors underlying - but not addressed - issue: does kats environment support client applications, or not.
This is why I suggested pushing back - asking the auditors to explain what they were trying to accomplish. How had they arrived at this (odd) suggestion.
In any case, Kat could set the mcauser attribute of the system default svrconn channel definition to NOBODY (what was the default a long time ago), where NOBODY had no access to MQ objects. (This may be a good idea for all system default channel definitions.)
Again, what is it that the auditors are trying to accomplish?
Auditors are seldom IT specilaists; IT specialists are seldom audit specialists. I've worked in both these roles. We need to meet them part way - train them. |
|
| Back to top |
|
|
| kats |
| Posted: Fri Jan 12, 2007 9:44 am Post subject: |
|
|
Voyager
Joined: 20 Apr 2006
Posts: 78
|
| Quote: |
| Again, what is it that the auditors are trying to accomplish? |
Auditors might have taken this decision thinking that it will be "more" difficult for unsolicited CLINTCONN stubs to attach to the SVRCONN Chl. Now he's(hacker or whatever) to figure out user defined "names" of SVRCONN chl. But again, if he's has gathered all the other info for connection, he'll find out the names too... 
Perhaps, that's why they're come up with idea of SSL also. But my another question remains: I'm implementing SSL on User defined SVRCONN and MCA channels and not channel exits. Any comments. Am I leaving security hole?
| Quote: |
| Auditors are seldom IT specilaists; IT specialists are seldom audit specialists. I've worked in both these roles. |
I like that...
Thanks gentlemen for giving your time and ideas. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 12, 2007 10:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you configure SSL properly, and you carefully manage and control access to your certificates, then the certificates act to ensure that the person connecting to the SVRCONN is a) who they say they are, and b) allowed to connect.
By setting a garbage MCA on system defined SVRCONNs, you are preventing anyone from connecting to those channels (I hope you don't have message broker, it's hard not to use SYSTEM.BKR.CONFIG on a regular basis).
By configuring SSL on all other SVRCONNs, and presumably forcing them to authenticate the client - you are preventing anyone who doesn't have a valid certificate FOR THAT CHANNEL from connecting to those channels.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
