| Author |
Message
|
| decaf |
 Posted: Wed Apr 13, 2005 11:33 am Post subject: Security concerns with WAS Embedded and WMQ under AIX NIS |
 |
|
Novice
Joined: 27 Apr 2004
Posts: 12
|
We have recognized a large security hole in our AIX environment and we are seeking a recommendation to fix this issue.
In our environment user authentication under AIX is managed by NIS. We have a mix of servers that use WebSphere App Server v5.0 & 5.1. These servers utilize JMS by way of WebSphere Embedded Messaging. According to the WAS documentation, the userid starting the JMS server must be a member of the mqm group. As it so happens, this userid and password is known to many people who support these applications. These are users outside of our WMQ Administration team.
This poses a gigantic security hole to our servers where full WMQ is installed since anyone knowing the JMS userid/password can log in to our WMQ servers with full WMQ administrative priviliges.
IBM WebSphere App Server support has provided us a quick answer that the user starting the jms server MUST be in the mqm group. Our PMR has been transferred to WMQ Support.
This doesn't seem like a new problem. Does anyone have experience with this issue?
Is there a way to remove the WAS JMS userid's from the 'mqm' group? Is it possible write setmqaut scripts for these WAS servers so they'll be operational, but limit the scope of authority? |
|
| Back to top |
|
 |
| malammik |
| Posted: Wed Apr 13, 2005 12:49 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
I dont have a solution for you but I agree with you 100% that this is a serious security problem that must be dealt with.
Here are few suggestions that might help.
1. Establish a policy that is supported by the management that only certain individuals are allowed to make changes in the mq environment even though others might have access as well. Define punishment measures for those in the violation of the policy
2. Beef up your auditing. Make sure every changed is logged.
3. Limit the number of people having access to the environment to the minimum and the number of people having admin access in production to 1 or 2.
Hope this helps. Let us know if IBM recommends any solution for you.
_________________
Mikhail Malamud
http://www.netflexity.com
http://groups.google.com/group/qflex |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 13, 2005 6:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Now we are talking about 2 complete different scenarios here:
a) embedded messaging
b) WMQ Server on the same hardware.
a) Is there a specific reason to mix embedded messaging and an WMQ server on the same host. ??
b) If you are concerned about the security why not open your WMQ Server and allow WAS to access it. You can set the security on your WMQ server and WAS does not have to be in the mqm group, but you will have to grant the WAS user access to the necessary objects.
Enjoy  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 14, 2005 3:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
| a) Is there a specific reason to mix embedded messaging and an WMQ server on the same host. ?? |
fjb_saper... I don't think that's the situation.
The situation is that they are using a shared user registry between multiple hosts, with a single mqm group in that user registry. Because they are running WAS using embedded messaging, the WAS service user needs to be in the single mqm group.
Because many people need access to the WAS service user and password, they now have no security on all of their queue managers, since many people now have full mqm rights to any queue manager using that shared user registry.
It's quite a twisted little problem.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| decaf |
| Posted: Thu Apr 14, 2005 7:00 am Post subject: |
|
|
Novice
Joined: 27 Apr 2004
Posts: 12
|
Jeff is correct. WebSphere Embedded Messaging and WMQ are not located on the same servers, but do share the same authentication directory, in this case NIS. This is a twisted little problem since two products, arguably related, share the same administrative group name "mqm".
This may be off topic a little, but does anyone know of a good WebSphere Application Server forum? Since this problem falls into the grey area between WAS and WMQ, maybe those folks have some suggestions.
Thanks. |
|
| Back to top |
|
|
| malammik |
| Posted: Thu Apr 14, 2005 7:13 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
How about this. In WAS one can define in external security authentication sources other than native OS. For example, we had our WAS on Z/OS authenticating users attempting to access admin console against LDAP. This would not solve ur problem entirely because was would still be sharing user domain with mq on process level but at least the users who need access just to the console wont.
_________________
Mikhail Malamud
http://www.netflexity.com
http://groups.google.com/group/qflex |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 14, 2005 7:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yeah, this is probably the solution.
Authenticate WAS console users against NIS. Change the password of the WAS service user, and don't tell anyone the new one. Anyone who needs to get into the WAS console has to use their NIS user, not the WAS service user.
But I don't know how difficult it is to get WAS to authenticate against NIS - unless NIS offers an LDAP interface, then it is "easy".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Apr 14, 2005 7:49 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
|
| Back to top |
|
|
| jantonitis |
| Posted: Thu Apr 14, 2005 8:08 am Post subject: |
|
|
Newbie
Joined: 27 Jun 2001
Posts: 7
Location: Jason Antonitis
|
Thanks for the suggestion on how to authenticate WAS Console users. However, our application support users do need telnet/ssh access to these servers to check logs, start/stop various processes outside of websphere, run scripts, etc.
Limiting them to the was console is not really an option.
_________________
Jason S. Antonitis
Cell: 630-697-3775
IBM Certified Product Specialist - MQSeries
IBM Cerfitied Solutions Developer - MQSeries
IBM Certified Solutions Expert - MQSeries |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 14, 2005 8:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
As long as your users don't need to stop and start WAS, then they don't need the WAS service user - and thus it's password.
In fact, even if they do need to stop and start WAS, then they still don't need the WAS service user password. If they are console authenticated to stop and start the WAS instance, then they can do the same from the command line using stopServer -username -password.
And I wasn't talking about limiting their access to only the WAS console. Just getting them to log into both the WAS console and the box as their NIS user, rather than the WAS service user.
Which they should be doing for auditing and security reasons anyway.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Apr 14, 2005 10:10 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi Jason,
What is 'NIS'? (I'm not an AIX expert.)
The first thing that I would is disable 'JMSAdmin' logons to the WMQ Server boxes where the WMQ Server installed and running (do not allow them to telnet into these boxes).
But that is only the beginning. If you have NOT locked down ALL of the queue manager's SVRCONN channels then anyone can do anything they want to queue managers. This includes BOTH WMQ Server and WMQ Embedded Messaging Server.
After doing the first step, I would STRONGLY suggest that you implement a server-side security exit that would either allow or restrict the incoming UserID and/or IP address (or both).
Or you go with doing full authentication using both server-side security exit & client-side security exit to give you complete security (but since they know both the UserID & password this won't help.).
I think you are SOL with regards to using setmqaut because really, WMQ Embedded is just a cut down version of WMQ Server.
Actually, what you point out is a great selling point for WebLogic. Their embedded messaging does not have this conflict / difficulty.
Since, IBM only half way converted WMQ Server to WMQ Embedded hence it left an administration nightmare. Seriously, people at Hursley, why didn't you go the FULL 10-yards and create a new and separate group for JMS MQ Admin?????
i.e. jmsmq or emqm or emq rather than mqm
Regards,
Roger Lacroix
P.S. For more information on security exits for SVRCONN channels, go to Capitalware's web site.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| malammik |
| Posted: Thu Apr 14, 2005 10:21 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
| jantonitis wrote: |
Thanks for the suggestion on how to authenticate WAS Console users. However, our application support users do need telnet/ssh access to these servers to check logs, start/stop various processes outside of websphere, run scripts, etc.
Limiting them to the was console is not really an option. |
ok. There is a solution for that as well. deny mq and was access to all. make everyone login with their own userids and execute commands via sudo. sudo automtically audits who is executing what and and deters most of the unwanted activity. With a little bit of scripting and permission settings a unix admin can control who can sudo what commands. it is possible to configure a unix system so that user joe can do
sudo wasid start server1 but cannot do sudo wasid strmqm even though wasid is the member of the mqm group.
_________________
Mikhail Malamud
http://www.netflexity.com
http://groups.google.com/group/qflex |
|
| Back to top |
|
|
| decaf |
| Posted: Thu Apr 14, 2005 2:19 pm Post subject: |
|
|
Novice
Joined: 27 Apr 2004
Posts: 12
|
After meeting with some of our security and AIX folks we came to the same conclusion malammik suggested. We're going to implement sudo on the WAS servers. The users will sudo to the support userid and use their own password to authenticate, not the password of the support userid. Since sudo rules are defined locally to each server, users won't be able to sudo to our WMQ servers. The only people who will know the real support userid passwords are our security folks.
Thanks for everyones help. I'll tell you how it goes. I think my stress level has gone down a few notches. |
|
| Back to top |
|
|
| malammik |
| Posted: Thu Apr 14, 2005 2:30 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
|
| Back to top |
|
|
|
|
