| Author |
Message
|
| ivanachukapawn |
 Posted: Wed Feb 28, 2007 6:28 am Post subject: plugging security vulnerability via SYSTEM.DEF.SVRCONN |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
We're preparing for a SOX Audit and looking pretty good because all our user defined channels are SSL with client authentication required. However, I discovered that we have SAP JMS Adapter accessing our MQ Infrastructure via SYSTEM.DEF.SVRCONN. I am taking steps to modify the SAP access to either use an SSL enabled SVRCONN or do a binding connection. However, we'll still have a security vulnerability related to the existance of SYSTEM.DEF.SVRCONN.
I know that I shouldn't delete SYSTEM.DEF.SVRCONN and I'm guessing that the appropriate way to plug this security hole would be to ALTER CHANNEL on SYSTEM.DEF.SVRCONN to specify SSL Cipher Spec. I'm thinking that this should prevent any hacker/cracker from accessing our MQ Infrastructure via SYSTEM.DEF.SVRCONN.
Could an MQSeries Guru out there please confirm that this method is correct for plugging this security hole?
Also, should I take similar action with other SYSTEM.DEF channels such as SYSTEM.AUTO.SVRCONN, SYSTEM.DEF.RECEIVER, SYSTEM.DEF.SENDER, etc. etc. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Feb 28, 2007 6:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
SYSTEM.AUTO.SVRCONN definitely needs to be plugged.
The others aren't SVRCONNs, so client apps can't connect to them. But it would be reasonable to set an invalid MCA on them to prevent someone from deleting their local SYSTEM.DEF.SENDER, and creating a new receiver named SYSTEM.DEF.SENDER...
If you tell the svrconn to require client authentication, you should be okay. But if you're facing a SOX audit, you probably want to get an *official* answer on that.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Feb 28, 2007 7:00 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| OK. I guess I'll put an invalid MCAUSER on all the SYSTEM.DEF. channels which aren't SVRCONNs. Do you think that specifying SSL Cipher Spec for SYSTEM.DEF.SVRCONN and SYSTEM.AUTO.SVRCONN is the right way to plug the SVRCONN security vulnerability? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 28, 2007 7:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Specifying the cipher spec is just going to suggest to the other side what the cipher spec to use should be....
I guess you could specify an invalid Cipher Spec, but...
Again, if you're facing an audit you probably need something more convincing than "some guy on the Internet said I'd be okay".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Feb 28, 2007 10:00 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Its not that I'm trying to get 'some guy on the internet' to say that I'm OK. I recently witnessed a SOX audit of MQ Infrastructure in which the modus operandi was to 1.) obtain unauthorized access (connection) to a queue manager and 2.) view message content in the clear via a packet sniffer. The auditor did not concern herself with the specifics of any MQ Object configurations.
I'm going to write a Java client which connects to a queue manager on SYSTEM.DEF.SVRCONN and then see if I can prevent this connection by altering the channel for 1.) an invalid MCAUSER and then 2.) altering the channel for SSL Cipher Spec with Client Auth required. If either or both of these ALTERS in combination prevent the connection I'd be able to satisfy the audit requirements. I was just trying to elicit your opinion as to the preferred method for plugging the security hole with SYSTEM.DEF.SVRCONN. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 28, 2007 10:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
An invalid MCA doesn't prevent the connection, it just removes all authorizations on the connection.
Otherwise, yes, SSL Cipher spec with client auth requried should prevent the connection. Assuming all your certs are safe.
Both will ensure that even if the certs are not safe, then the connection is useless anyway.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu Mar 01, 2007 12:41 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| jefflowrey wrote: |
| An invalid MCA doesn't prevent the connection, it just removes all authorizations on the connection. |
An invalid MCAUSER on all your SYSTEM.*.SVRCONN channels should stop connections. A client should get 2035 (not auth'd). Not sure how invalid SSL attributes would be presented back to the client.
As a matter of course, we set the MCAUSER on all SYSTEM.DEF.* channels to 'nobody' so that you have to explicitly change any channel created to allow access, and non of the SYSTEM.DEF.* channels can be used.
E.g. It might be possible for an attacker to define a YOURQM.TO.MYQM receiver channel on their own qmgr, then delete their SYSTEM.DEF.RECEIVER channel and create a sender channel called SYSTEM.DEF.RECEIVER with your connection details. Once connected to your SYSTEM.DEF.RECEIVER channel, they can send administration messages to create an xmitq called MYQM and a sender channel called YOURQM.TO.MYQM and they can now remotely administer your queue manager.
Setting invalid SSL attributes may be able to achieve the same results. Do both if it gives you a better comfort feeling 
Don't forget SYSTEM.ADMIN.SVRCONN either.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Mar 01, 2007 11:35 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Scott, thanks for the detailed and thoughtful reply (and thanks as well to the inimitable Jeff).
You comment about not forgetting SYSTEM.ADMIN.SVRCONN is interesting. I'm thinking of setting cipher spec TRIPLE_DES on SYSTEM.ADMIN.SVRCONN but I'm wondering about what trouble I might encounter if I wanted to use MQExplorer for remote admin. Also, do you know what uses there are currently in MQ6.0 for SYSTEM.ADMIN.SVRCONN? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 01, 2007 11:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You have to configure MQExplorer to use a client channel table file for the SSL connection.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
