| Author |
Message
|
| sebulba_dz |
 Posted: Tue Jun 03, 2003 1:03 am Post subject: Security headaches |
 |
|
Novice
Joined: 02 Jun 2003
Posts: 20
Location: UK
|
there's no security in place in our current environment (5.1) and i need some ideas on what to implement for 5.3.
we're quite unwilling to write our own security exits (we're a lazy bunch), are there any tools available on the market that can do application level security? this is especially an issue since most of our clients are connected using JMS and they use "mqm" id by default and we cannot stop them from doing so...
also is the ssl in 5.3 robust enough for link level security?
thanks. |
|
| Back to top |
|
 |
| tillywern |
| Posted: Mon Jun 16, 2003 12:58 pm Post subject: Insane. |
|
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
Sorry for stating the blatently obvious but..... Never allow applications to connect as MQM. Well they could also connect as root too.. If you like... O
But realy. The most basic layer of security is at the user and group level. From the client perspective the only think you really know about them is the id under which they are connecting to the queue manager.
I would create application user ids and perhaps an "mqmapp" like group and then assign rights to the users or group as appropriate.
If you aren't willing to to this, then you realy don't want any security.
You could try forcing user ids to be associated with incomming traffic by specifying the user id in the SRVCONN channel definition.. This may allow them to connect as MQM but be associated with a different user id. They may never know the difference if you assign all rights to the new ids.
PS: It is really easy to create user right grant scripts to make your life easier. Especially if you are running in a UNIX like environment. |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Jun 16, 2003 4:00 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Also, there are many types of security (although as tillywern explained, sometimes one type doesn't make sense without another).
So what exactly are you looking for?
Do you want the contents of the messages to be encrypted while sitting on a queue?
Do you want the entire message (header + contents) to be encrypted while moving across a channel?
Do you want channels to work with firewalls and DMZs?
Do you want to allow only certain MQ operations for a given user/group?
etc...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| sebulba_dz |
| Posted: Tue Jun 17, 2003 7:54 pm Post subject: |
|
|
Novice
Joined: 02 Jun 2003
Posts: 20
Location: UK
|
Application user ids are created and the rights assigned to the appropriate users currently. But all this is in vain if the user uses JMS cuz the default id is MQM and they don't even bother to change it. I guess a flaw here is that there's no seperate group assigned, so the assignment of individual ids is redundant since the user group's mqm.
Bad news for me is this is the architecure that i've inherited, and looks like there's a need for a huge overhaul.
Other stuff that I may need are:
1. protection of message content when it's in queue.
2. encrypt entire message when moving across channel
3. prevent messages from being viewed by unauthorised party.
Does this all come in 5.3? (SSL in 5.3 should solve point 2).. |
|
| Back to top |
|
|
| rwa |
| Posted: Wed Jun 18, 2003 3:23 am Post subject: |
|
|
Voyager
Joined: 22 Jan 2002
Posts: 76
Location: Duesseldorf/Germany
|
| JMS as every client connects to the server using a channel. I channel can be bound to a userid. This is done by setting the mcauser. This userid overrides the userid setting from JMS. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jun 18, 2003 8:09 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Your application would have to handle #1 by encrypting the contents of the message before putting it on a queue. This way, whether or not the queue manager encrypts the entire message as it moves across the channel, the message contents will still be encrypted when it is sitting on the destination queue. Of course the getting application will need some means of decrypting it.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 18, 2003 10:34 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You can implement message encryption in the queue in different ways - eg at the application program level or at the API crossing exit level.
There are several commercial products that will do this for you - eg Tivoli Access Manager for Business Integration or Primeur Data Secure. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jun 18, 2003 3:13 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
True. I forgot about that...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| techno |
| Posted: Wed May 05, 2004 12:49 pm Post subject: |
|
|
Chevalier
Joined: 22 Jan 2003
Posts: 429
|
If all of above still holds good,
how do I restrict any jms client app connecting to make calls to mq objects at qmgr? Above discussion is to avoid getting 2035. What I want is not to allow any jms client to access qmgr. I do not have any influence of client code. Can we do something on server channel? We are not using any security exists also.
Thanks |
|
| Back to top |
|
|
| tkane |
| Posted: Wed May 05, 2004 6:53 pm Post subject: |
|
|
Voyager
Joined: 23 Dec 2002
Posts: 82
Location: Kansas City
|
I'm looking at doing a similar thing in a large shop.
Our steps so far have been to require mcauser to be set to non-mqm.
True, we haven't gotten this across all applications yet, but I still think it's the right direction.
Each application should have a unique Unix group name. Because OAM security under setmqaut will grant access to a user's primary group if you attempt to set it by a principal.
Then with a logical queue name standard and Generic OAM profiles we're getting a lot closer to a manageable solution.
Now to keep working on moving applications out of the mqm group.
Good Luck
Tom |
|
| Back to top |
|
|
| techno |
| Posted: Thu May 06, 2004 7:16 am Post subject: |
|
|
Chevalier
Joined: 22 Jan 2003
Posts: 429
|
Once you set up MCA user, everything gets overwritten from client-application. Any client connecting to that channel will have no problem in connecting to qmgr.
I think client app should send the userid and it should be verified on server channel/qmgr. Then you can restrict which app be allowed to connect to which qmgr. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 06, 2004 7:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
I think client app should send the userid
|
Not a good idea. Its to easy to have a client send the mqm ID, and then do whatever they want.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| techno |
| Posted: Thu May 06, 2004 11:04 am Post subject: |
|
|
Chevalier
Joined: 22 Jan 2003
Posts: 429
|
Yes, you are correct.
But server should be able to deny the service to client depnding on something! Should it be IP or something else?? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 06, 2004 11:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Yes, you could deny a connection on CHANNEL1 if it does not come from ip address 123.123.456.45. But it is technically possible to spoof an IP address, so that method is vulnerable.
SSL is the best way to insure the other side is who they say they are. This of course assumes the certificates are kept secure.
Use a hardcoded MCAUSER on the channel def ("TECHNO"). Then give TECHNO authority only to the queues TECHNO should be able to use.
SSL insures only the correct people come across the channel.
The Hardcoded MCA insures that those people can only do what you allow.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| techno |
| Posted: Fri May 14, 2004 10:39 am Post subject: |
|
|
Chevalier
Joined: 22 Jan 2003
Posts: 429
|
That info is very useful Thanks.
I would like to try secured communication in our development environment. How do I create trial certificates?
What are the initial steps I should follow. I have so many documents. They don't seem to be giving exact initial steps to configure SSL. I have my client app on windows and mq server on unix. Applications are java based.
Can I create certificates using java and use it for MQ SSL?
Pls throw some light.
Thanks |
|
| Back to top |
|
|
|
|
