| Author |
Message
|
| spfdgio |
 Posted: Thu Oct 07, 2004 12:09 pm Post subject: MQ Client security |
 |
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
We are MQ v5.3 CSD05 and MQ Client CSD06 level. We are running JMS applications that connect as MQ Clients to the SVRCONN channel of the target qmgr. The MCAUSER is blank - I know, that is bad. I am planning to implement Jorden's BlockIP2 channel security exit to prevent a blank userid, mqm or musr_mqadmin from being passed - as well as setting up a separate SVRCONN channel per client application. For each SVRCONN channel I'll configure the BlockIP2 exit to limit to certain IP addresses and userids allowed through to OAM and setmqaut on the target objects to limit to only these userids. I'll modify the SYSTEM.DEF.SVRCONN and other receiver/responder channel defaults to MCAUSER equals 'none'. Now I am struggling with how to authenticate the userid being passed from that IP is truly who he says he is. I cannot guarentee the integrity of the client machine (internal politics), so whether I modify the BlockIP2 exit to check for a password or implement SSL channels with digital certificates I am still exposed to someone getting the password or certificate - or even making a copy of the java code and running it under a different process on the same client machine! The complexity of SSL and slowdown in performance due to the handshake would be costly and if we made the java client app pass a password I would have to watch for password expiration - and if we kept the password 'non-expiring' it would be like giving the keys away, although limited to the security permissions granted to the userid in OAM. I dont want to have the java client app have to hardcode a password and then administer to it. From my point of view, I can't see that the authentication issue is satisfied. I've read most postings on security and java and mq clients - can anyone propose a clean and thorough solution to closing this hole when I cannot guarentee that the machine the java client is running on is secure? The only clean way I can see is to eliminate MQ Clients from our shop and put MCAUSER as 'none' for the svrconn /receiver/responder system defaults. Can someone offer some way to close this 'authentication' hole without guarentee of the client machine being secure? Thanks in advance for your help.....Dan in Harrisburg, Pa  |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Oct 07, 2004 1:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hi Dan,
Check out the C code in the Ipsecure2 exit. You can specify as well a security exit on the qmgr in JAVA. That security exit will need the corresponding class to be defined on the client. The c code on the server and the java class on the client interact with each other. You can then use java and JNI to get the authentication from windows or any jaas service.
I know it's a lot and it demands a lot of work to make it work but it would probably cover your requirements...
Enjoy  |
|
| Back to top |
|
|
| spfdgio |
| Posted: Fri Oct 08, 2004 4:35 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Thanks. Could you please tell me where I may locate the Ipsecure2 exit you reference? I am interested in pursuing this and not afraid of some work for the benefits it provides. Your help is much appreciated - I will post a followup with my results for others to benefit also.
Dan |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Oct 08, 2004 2:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do a search on this site for IPSecure2. You will find the link in one of the posts...
Enjoy |
|
| Back to top |
|
|
| spfdgio |
| Posted: Wed Oct 13, 2004 12:28 pm Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
| Cant find it here.....any other clues? Thanks! Dan |
|
| Back to top |
|
|
| siliconfish |
| Posted: Wed Oct 13, 2004 12:37 pm Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 14, 2004 8:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Thanks Siliconfish. That's the one I was thinking about. Version 2 of it. |
|
| Back to top |
|
|
| spfdgio |
| Posted: Fri Oct 15, 2004 6:56 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2002
Posts: 36
|
Thanks - but as I mentioned in my original posting I am already planning to implement the BlockIP2 channel security exit and that C code does not have any "authentication" code or technique built into it. I've got to put something in place at the target since I can't really be sure of the client java code or where they are running from. I wish I could count on the IP address for authentication, but I know better - it can be changed by a smart user inside our firewall. Is there any other technique out there by which I can authenticate with less chance of compromise given that I cannot lock down the client machines well enough to prevent spoofing?
Thanks for your help.....if I am missing something, or one of my comments is not correct, please help me understand this better. Dan |
|
| Back to top |
|
|
| hguapluas |
| Posted: Fri Oct 15, 2004 7:16 am Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
| Utilizing SSL combined with BlockIP2 should be quite sufficient. The SSL certificate will prevent unauthorized users who are attempting to spoof a message and BlockIP2 can block other IP addresses/users. You may be going overboard in your quest for perfect security. I would suggest you try the SSL/BlockIP2 combination first. You will likely find that it will be more than secure for your needs as long as you protect your SSL keys properly. |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Fri Oct 15, 2004 7:52 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
This is not a 100% MQ solution, but it may solve your problem and it uses existing, openly available technology.
1. As you planned, use the block ip exit.
2. Establish seperate queues for the client applications.
3. Using setmqaut set these queues up so only one user id (not MQM) can put to them. Use this user ID on the SVRCONN as well. The only thing this user should be able to do is put and connect. Block any connection that doesn't use that user id and server ip.
4. Now come the programing parts that will actually help secure things:
a. Build a Java app to wrapper the MQ client application, don't give them the code for the Java app just the complied class. If you have the know-how you should be able to get the client code into this class or into a package or jar so only your application can use it.
b. Using the Crypto packages from Java, encrypt the message information with a one-time public key set. Then put it out on the queue.
c. Build an application on the other side that gets the message and decrypts the message with the one-time public key set. Then it can put it into a "clear" queue to be handled by the existing application.
This is pretty GD secure. The only issue I see is that you really need an system to issue the onetime keys, which has been implemented a whole bunch of times.
This can be much more secure then SSL and is total independent of it.
It is also essentially tamper proof as every message has been encrypted with a private key and a one time public key. Without the combination of keys + the right user id the person on the other end can't spoof anything.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
|
|
