You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2016/12/15 11:07:57 UTC

svn commit: r1774412 - /tomcat/trunk/webapps/docs/security-howto.xml

Author: markt
Date: Thu Dec 15 11:07:57 2016
New Revision: 1774412

URL: http://svn.apache.org/viewvc?rev=1774412&view=rev
Log:
Expand a little on JMX in the security considerations page

Modified:
    tomcat/trunk/webapps/docs/security-howto.xml

Modified: tomcat/trunk/webapps/docs/security-howto.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/security-howto.xml?rev=1774412&r1=1774411&r2=1774412&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/security-howto.xml (original)
+++ tomcat/trunk/webapps/docs/security-howto.xml Thu Dec 15 11:07:57 2016
@@ -74,6 +74,36 @@
     <p>At the network level, consider using a firewall to limit both incoming
     and outgoing connections to only those connections you  expect to be
     present.</p>
+
+    <subsection name="JMX">
+      <p>The security of the JMX connection is dependent on the implementation
+      provided by the JRE and therefore falls outside the control of Tomact.</p>
+
+      <p>Typically, access control is very limited (either read-only to
+      everything or read-write to everything). Tomcat exposes a large amount
+      of internal information and control via JMX to aid debugging, monitoring
+      and management. Give the limited access control available, JMX access
+      should be treated as equivalent to local root/admin access and restricted
+      accordingly.</p>
+
+      <p>The JMX access control provided by most (all?) JRE vendors does not
+      log failed authentication attempts, nor does it provide an account
+      lock-out feature after repeated failed authentications. This makes a
+      brute force attack easy to mount and difficult to detect.</p>
+
+      <p>Given all of the above, care should be taken to ensure that, if used,
+      the JMX interface is appropriately secured. Options you may wish to
+      consider to secure the JMX interface include:</p>
+
+      <ul>
+        <li>configuring a strong password for all JMX users;</li>
+        <li>binding the JMX listener only to an internal network;</li>
+        <li>limiting network access to the JMX port to trusted clients; and</li>
+        <li>providing an application specific health page for use by external
+            monitoring systems.</li>
+      </ul>
+    </subsection>
+
   </section>
 
   <section name="Default web applications">



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org