i see one recommendation from MQ security presentation that is making command server down if you don't need it. my question is how i can determine if i really require it or not. From the point of my view, if no administrative program for target QMGR runs such as MQ Explorer or other ones which send command message to QMGR, we can stop that command server, am i right、
Thanks
The command server is used by desktop tools such as WebSphere MQ Explorer and SupportPac MO71 and central productivity/admin tools such as IR-360, AppWatch, QPasa! and others. It is also used by monitoring agents such as Tivoli Omegamon XE for Messaging and other instrumentation such as custom scripts you might write. If you do not use any of these tools, you can shut off the command server.
As a rule, I recommend people shut off the command server in cases where it will never be used. The alternative of shutting it off most of the time and then turning it on during approved change windows is a bit more complex. In that case what you really get is a reduced window of opportunity for an attacker but you trade that for additional complexity. For example, when it is time to turn on the command server, you first need to make sure the queue is clear or else an attacker can just pre-load the command queue with commands. Also, if an attacker with access to the QMgr is able to leave a background process running on the server it can poll the command queue and watch for an input handle before putting commands to the queue.
You may think that the pre-conditions of having access to the QMgr and the ability to run daemon programs is a high bar to set but consider that most shops run WebSphere App Server and WebSphere Message Broker with full MQ admin rights. In those cases, every program or workflow is a potential attacker. Although there has not yet been a publicly reported external breach involving MQ, I have worked on many assignments where WMQ was breached by well-meaning employees who were just trying to get their jobs done and took a shortcut by using their application's administrative privileges to the QMgr to "fix" something.
The exception I usually make is for B2B gateway QMgrs. I typically put a lot of security on these and don't mind the added complexity. In fact one of the reasons for using a gateway QMgr for B2B is so that you can limit that complexity to one host rather than allowing external connections to terminate on many QMgrs and having to put added security on all of them. So I use a gateway and secure it to an extent that would be impractical to do across the entire network.
So to sum up, if you do not use any remote productivity or admin tools, go ahead and shut off the command server. If you do need to run it occasionally, automate the startup so that the command queue is cleared (including a subsequent check to make sure depth is zero) before starting the command server. This should be considered a secondary security control because it will have only limited effectiveness if the channels allow administrative access. So get to V7.1 or higher as soon as you can and then use the CHLAUTH rules and SET AUTHREC commands to lock down the channels before worrying too much about the command server.