Manager Application | Security | Tomcat 5.5.27

[Anurag Kapur]

Hello,

Context
We need to use the JMX Proxy servlet, bundled with the manager application
on our production environments. However, as a best practice, the manager
webapp should not be deployed on production environments for security
reasons. Thus, we need to migrate the JMX proxy servlet to an independent
custom webapp.

Questions
1. Why is it considered that the manager webapp should not be deployed on
production environments? Am I just believing a rumour here or does it
actually impose any security risks?
2. If the answer to question 1 is yes, Is it a good idea to migrate the jmx
proxy servlet code to an independent webapp if one does not want to use the
complete manager webapp? Or is there another way of using the servlet
without imposing any security risks on the environment?
3. If the answer to question 2 is yes, any best practices/easy way of doing
it?

Additional Details
Tomcat version: 5.5.27
Java Version: 1.5.0_14
OS: Solaris 5.10 Generic_127128-11 i86pc i386 i86pc

Any pointers/ideas would be appreciated.

Regards
Anurag

------------------------------------------------------------------
Anurag Kapur
Associate - Technology,
Sapient Corporation.

http://www.linkedin.com/in/anuragkapur

http://www.google.com/profiles/anuragkapur
------------------------------------------------------------------
Sent from Greater London, United Kingdom

[Tobias Crefeld-2]

Am Thu, 5 Nov 2009 11:04:06 +0000
schrieb Anurag Kapur <anuragkapur@...>:

> 1. Why is it considered that the manager webapp should not be
> deployed on production environments? Am I just believing a rumour
> here or does it actually impose any security risks?

With "manager" you only need a credential to control the whole
application server which possibly could be evaluated by social
engineering. There are already some bots in the web that test the
default credentials of early manager installations automatically.

It is always better to use 2 or 3 barriers. For example you could setup
a filter that some IP-addresses from management systems only could get
access to /manager/.

Separating JMX Proxy from manager won't be very helpful because JMX
Proxy itself is offering control over tomcat. And it needs direct
access to MBeans of Tomcat's JVM.


RU,
 Tobias.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Anurag Kapur]

Thank you  for your reply.

On Thu, Nov 5, 2009 at 12:29 PM, Tobias Crefeld <tc@...> wrote:

> Am Thu, 5 Nov 2009 11:04:06 +0000
> schrieb Anurag Kapur <anuragkapur@...>:
>
> > 1. Why is it considered that the manager webapp should not be
> > deployed on production environments? Am I just believing a rumour
> > here or does it actually impose any security risks?
>
> With "manager" you only need a credential to control the whole
> application server which possibly could be evaluated by social
> engineering. There are already some bots in the web that test the
> default credentials of early manager installations automatically.
>
> It is always better to use 2 or 3 barriers. For example you could setup
> a filter that some IP-addresses from management systems only could get
> access to /manager/.
>

Ok. I know putting the manager app behind 2-3 barriers is better than
leaving it in the hands of basic tomcat authentication. But again, this
method is *better* and not foolproof. Thus we want to get rid of the manager
application completely.


> Separating JMX Proxy from manager won't be very helpful because JMX
> Proxy itself is offering control over tomcat. And it needs direct
> access to MBeans of Tomcat's JVM.
>

My Understanding:

Even if an attacker gets access to the jmx proxy servelt, it would not pose
the same risk as access to the manager application would. With the proxy
servlet you can only query the MBeans and get information about the state of
the container. However, with access to manager application, you can
potentially reload/start/stop contexts which is a big risk.

Am I correct with this understanding?


>


> RU,
>  Tobias.


Does any one else have any other views on this topic? Your
inputs/suggestions would be highly appreciated.

Thanks
Anurag

[Tobias Crefeld-2]

Am Thu, 5 Nov 2009 19:42:58 +0000 schrieb Anurag Kapur
> On Thu, Nov 5, 2009 at 12:29 PM, Tobias Crefeld <tc@...> wrote:

> > Separating JMX Proxy from manager won't be very helpful because JMX
> > Proxy itself is offering control over tomcat. And it needs direct
> > access to MBeans of Tomcat's JVM.

> My Understanding:
>
> Even if an attacker gets access to the jmx proxy servelt, it would
> not pose the same risk as access to the manager application would.
> With the proxy servlet you can only query the MBeans and get
> information about the state of the container. However, with access to
> manager application, you can potentially reload/start/stop contexts
> which is a big risk.
>
> Am I correct with this understanding?

The doc under
http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#Using the
JMX Proxy Servlet describes a command "set" in addition to the "query"
you mentioned. I haven't tested but it looks like that it offers nearly
the same possibilities as "manager" does.

Actually "query" alone discloses enough information that a potential
attacker could use to get real confidential information via other
channels that I don't want to have it in the web.

I don't know how safe you webserver is - standard-setup of Solaris
runs with no active packet filter... - but if you have no other
firewall with ALG I would strongly suggest that you run e.g. an Apache
in front of Tomcat with no access by Tomcat-deployers. Today in our
standard setup there is such an Apache2 that offers the same Tomcat via
two different virtual hosts. One is only proxying URIs that belong to
the production context and can be reached from the whole web. The other
is proxying the manager-applications as well (manager, probe and j4p)
but there are some Apache-rules that allow only access for clients from
VPN-users.


BTW: j4p might be another nice approach to get a read-only monitoring.
It's a Tomcat application that delivers all (?) the data that can get
reached by JMX/TCPIP or Mbeans. There is script jmx4perl to read this
data and there is a plugin check_jmx4perl to poll this data by a
Nagios-server.
I found a article which describes this nice tool:
http://blog.techstacks.com/2009/09/tomcat-management-jmx4perl-makes-it-easier.html

Actually I haven't tested it in detail and so I can't promise that this
tool is already ready for production. Ask me in two months when I can
tell you more... ;)


RU,
 Tobias.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Anurag Kapur]

Thank you for the information you provided.

I had totally missed the point that JMX proxy servlet can also be used to
specific attributes of the exposed MBeans.

Yes, we do have apache in front of the tomcat container as well as firewalls
as part of our infrastructure. I was still looking for best practices around
the manager webapp and security.

Thanks again for your reply.

Regards
Anurag


On Thu, Nov 5, 2009 at 9:53 PM, Tobias Crefeld <tc@...> wrote:

> Am Thu, 5 Nov 2009 19:42:58 +0000 schrieb Anurag Kapur
> > On Thu, Nov 5, 2009 at 12:29 PM, Tobias Crefeld <tc@...> wrote:
>
> > > Separating JMX Proxy from manager won't be very helpful because JMX
> > > Proxy itself is offering control over tomcat. And it needs direct
> > > access to MBeans of Tomcat's JVM.
>
> > My Understanding:
> >
> > Even if an attacker gets access to the jmx proxy servelt, it would
> > not pose the same risk as access to the manager application would.
> > With the proxy servlet you can only query the MBeans and get
> > information about the state of the container. However, with access to
> > manager application, you can potentially reload/start/stop contexts
> > which is a big risk.
> >
> > Am I correct with this understanding?
>
> The doc under
> http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#Using the
> JMX Proxy Servlet describes a command "set" in addition to the "query"
> you mentioned. I haven't tested but it looks like that it offers nearly
> the same possibilities as "manager" does.
>
> Actually "query" alone discloses enough information that a potential
> attacker could use to get real confidential information via other
> channels that I don't want to have it in the web.
>
> I don't know how safe you webserver is - standard-setup of Solaris
> runs with no active packet filter... - but if you have no other
> firewall with ALG I would strongly suggest that you run e.g. an Apache
> in front of Tomcat with no access by Tomcat-deployers. Today in our
> standard setup there is such an Apache2 that offers the same Tomcat via
> two different virtual hosts. One is only proxying URIs that belong to
> the production context and can be reached from the whole web. The other
> is proxying the manager-applications as well (manager, probe and j4p)
> but there are some Apache-rules that allow only access for clients from
> VPN-users.
>
>
> BTW: j4p might be another nice approach to get a read-only monitoring.
> It's a Tomcat application that delivers all (?) the data that can get
> reached by JMX/TCPIP or Mbeans. There is script jmx4perl to read this
> data and there is a plugin check_jmx4perl to poll this data by a
> Nagios-server.
> I found a article which describes this nice tool:
>
> http://blog.techstacks.com/2009/09/tomcat-management-jmx4perl-makes-it-easier.html
>
> Actually I haven't tested it in detail and so I can't promise that this
> tool is already ready for production. Ask me in two months when I can
> tell you more... ;)
>
>
> RU,
>  Tobias.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>