Author |
Message
|
Volodya |
Posted: Wed Jan 19, 2005 6:01 am Post subject: Is WebSphere MQ the unprotected system ? |
|
|
 Novice
Joined: 04 Mar 2004 Posts: 22 Location: Moscow
|
WebSphere MQ is the unprotected system and messages are accessible to reading and putting in enterprise network even if SSL using. The administrator on own computer and a member of mqm group has access with arbitrary password to all remote managers of enterprise network. He can read messages in any queue. He can put messages in any queue. For example, the malefactor can will be connected to queue manager on UNIX server as the user with name "root" on own computer.
He can use anyone password !!!
IP addresses of UNIX server and name of remote queue manager to learn simply. After that the malefactor can read messages, put the messages, etc. In fact SSL messages protects only in the channel. Messages are accessible to reading in queue. The malefactor can direct the message to queue if he will create recever channel without SSL on remote manager. All this can be cause of information losses and financial losses.
How protected from such malefactor?  _________________ Vladimir Makushkin, WebSphere MQ administrator
Last edited by Volodya on Wed Jan 19, 2005 11:47 pm; edited 3 times in total |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jan 19, 2005 6:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Don't set your queue managers up for remote administration (i.e. don't run a command server).
Use SSL to authenticate all channels, and very closely guard your keys.
Don't allow developers or users to have local administration rights on their machines.
Read about and understand WebSphere security. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Volodya |
Posted: Wed Jan 19, 2005 6:36 am Post subject: |
|
|
 Novice
Joined: 04 Mar 2004 Posts: 22 Location: Moscow
|
jefflowrey wrote:
>Don't set your queue managers up for remote administration (i.e. don't run a command server).
Work of the big organization with intensive streams of messages is impossible without the remote administration.
>Use SSL to authenticate all channels, and very closely guard your keys.
SSL on SYSTEM.ADMIN.SVRCONN is good idea. I shall check it will prevent administration of other managers.
>Don't allow developers or users to have local administration rights on their machines.
The malefactor will not execute such interdictions.
>Read about and understand WebSphere security.
The answer to my question there is absent in this manual.
Thanks. _________________ Vladimir Makushkin, WebSphere MQ administrator
Last edited by Volodya on Thu Jan 20, 2005 1:30 am; edited 1 time in total |
|
Back to top |
|
 |
KeeferG |
Posted: Wed Jan 19, 2005 6:36 am Post subject: |
|
|
 Master
Joined: 15 Oct 2004 Posts: 215 Location: Basingstoke, UK
|
If messages being visible on a queue is an issue you could always look at WebSPhere MQ Extended Security edition. Other wise the recommendation to lock down your system with restricted access to WebSphere MQ objects using the OAM or other security module is a good one. Create an ID and group for the apps to run under. Create a seperate ID and group for the support guys and restrict access to objects using the new ID's. That way the channels are secure with SSL and people only have access to specific objects. _________________ Keith Guttridge
-----------------
Using MQ since 1995 |
|
Back to top |
|
 |
Volodya |
Posted: Wed Jan 19, 2005 6:53 am Post subject: |
|
|
 Novice
Joined: 04 Mar 2004 Posts: 22 Location: Moscow
|
KeeferG write:
> ...restricted access to WebSphere MQ objects ..
The administrator on own computer and a member of mqm will have access to such objects.
About WebSPhere MQ Extended Security edition: Where it can be looked? _________________ Vladimir Makushkin, WebSphere MQ administrator |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jan 19, 2005 7:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Volodya wrote: |
jefflowrey write:
>Don't set your queue managers up for remote administration (i.e. don't run a command server).
Work of the big organization with intensive streams of messages is impossible without the remote administration. |
ssh+runmqsc counts as remote administration in a lot of cases.
Also, if you really have a big organization, you are better off using a professional management tool, which should have an agent infrastructure that will act locally on the server without using the command server..
Volodya wrote: |
>Don't allow developers or users to have local administration rights on their machines.
The malefactor will not execute such interdictions.
|
If you can't prevent someone from getting administrative access to any machine in your organization, then MQ security is the least of your worries. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
JT |
Posted: Wed Jan 19, 2005 8:30 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003 Posts: 1564 Location: Hartford, CT.
|
|
Back to top |
|
 |
zpat |
Posted: Wed Jan 19, 2005 9:18 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
MQ delivers messages, it is really up to the application to require suitable security credentials in the message payload and to verify them.
However if you want message integrity or privacy transparent to the application, use MQ Secure edition (aka Tivoli Access Manager for E-business integration). |
|
Back to top |
|
 |
Volodya |
Posted: Wed Jan 19, 2005 11:39 pm Post subject: |
|
|
 Novice
Joined: 04 Mar 2004 Posts: 22 Location: Moscow
|
Thanks all for care.
Our enterprise have thousands workstations and tens servers with WMQ servers. On many workstations users have administration rights of workstation. Such user can create the new user with a name "root" for example and enter it into administrator group and mqm. After that there can be problems with the non-authorized access.
We have millions messages a day. We use OMEGAMON as monitoring tools. Constantly it is necessary to understand with alert situation and to look why the message has got stuck in queue. That is why we need the remote administration and using command server.
We want to get means such as TAMBI, MQsecure, etc. Expenses on MQ secure are not included in the budget of our enterprise here the second year. That is why I have addressed in your forum for the help.
I very much like recommendations of type
> ssh+runmqsc counts as remote administration in a lot of cases.
I can establish the control for connection name for QM by OMEGAMON and delete non-authorized connection name by ACTION. It is not the best decision. It is reaction to infringement. I want that such infringements were impossible event.
What you tell about SSL on SYSTEM.ADMIN.SVRCONN?
Can work the remote administration in this case ?
Thank all. _________________ Vladimir Makushkin, WebSphere MQ administrator |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Jan 20, 2005 3:37 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Volodya wrote: |
What you tell about SSL on SYSTEM.ADMIN.SVRCONN?
Can work the remote administration in this case ?
[color=darkblue]Thank all. |
Yes, as long as the MQ Administrator has the SSL certificates.
I prefer using a Security Exit. You install one on the QM side, and its partner is installed on the Client side (where the MQ Admin sits). When you try and admin MQ over a channel with the exit, you are forced to provide a valid ID/Password. If you don't have the client side exit, the channel doesn't start at all/
Both methods (SSl or Exit) will work. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Volodya |
Posted: Thu Jan 20, 2005 4:16 am Post subject: |
|
|
 Novice
Joined: 04 Mar 2004 Posts: 22 Location: Moscow
|
PeterPotkay wrote: |
I prefer using a Security Exit. ...
Both methods (SSL or Exit) will work. |
This decision to like me also.
I think that it is the best variant for us.
I take a time-out on check and realization.
After that I shall inform about results or I shall ask new questions.
Thanks all. _________________ Vladimir Makushkin, WebSphere MQ administrator |
|
Back to top |
|
 |
Volodya |
Posted: Thu Feb 24, 2005 2:44 am Post subject: |
|
|
 Novice
Joined: 04 Mar 2004 Posts: 22 Location: Moscow
|
SSL on SYSTEM.ADMIN.SVRCONN work in MO71 SupportPac and we have started to use such way of protection.
Security exit work also and MQ Authenticate User Security Exit' from http://www.capitalware.biz may be used.
 _________________ Vladimir Makushkin, WebSphere MQ administrator |
|
Back to top |
|
 |
Volodya |
Posted: Sun Apr 24, 2005 11:07 pm Post subject: |
|
|
 Novice
Joined: 04 Mar 2004 Posts: 22 Location: Moscow
|
Advice about a Security Exit has very much liked me.
I has started to use free BlockIP2 from www.mrmq.dk
Security exit blocks connections based on IP addresses on SYSTEM.ADMIN.SVRCONN.
ID/Password can be checked up also.
BlockIP works fine on Windows, AIX and HP_UX servers.
This is really elegant and beautiful decision. _________________ Vladimir Makushkin, WebSphere MQ administrator |
|
Back to top |
|
 |
RogerLacroix |
Posted: Mon Apr 25, 2005 9:08 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Volodya wrote: |
BlockIP ... ID/Password can be checked up also. |
This is not true. It can ONLY block the UserID.
To do UserID & password checking, it requires both a client-side and server-side security exits. This is the purpose of Capitalware's MQ Authenticate User Security Exit solution.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
oz1ccg |
Posted: Tue Apr 26, 2005 12:47 am Post subject: |
|
|
 Yatiri
Joined: 10 Feb 2002 Posts: 628 Location: Denmark
|
About BlockIP2:
There are No authentication, all what BlockIP2 can is do a screening based on connection-name and supplied userid.
This can be enhanced using SSL, where BlockIP2 can set MACUSER according to the specified rules.
Just my $0.02  _________________ Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
Back to top |
|
 |
|