Page History

...

1. How do I use OpenSSL to set up my own Certificate Authority (CA)?
2. Oh no! Port 8005 is available for anyone on localhost to shutdown my tomcat!
3. What about Tomcat running as root?
4. How do I force all my pages to run under HTTPS?
5. What is the default login for the manager and admin app?
6. How do I restrict access by ip address or remote host?
7. How do I use jsvc/procrun to run Tomcat on port 80 securely?
8. Has Tomcat's security been independently analyzed or audited?
9. How do I change the Server header in the response?
10. Why are passwords in plain text?
11. How can I restrict the list of ciphers used for HTTPS?
12. Which cipher suites should I use?
13. Is Tomcat affect by Log4Shell CVE-2021-44228?
14. I found a vulnerability in JMXProxy

Answers

Anchor
Q1 Q1

How do I use OpenSSL to set up my own Certificate Authority (CA)?

...

But that doesn't prevent an application deployed to Tomcat from using log4j2. In which case, please use general guidance on various remediations. As of this writing, they include any of these 

• Upgrading log4j2 to 2.1516.0 (or better)
  • This is the best fix (2.15.0 was also insufficient due to CVE-2021-45046)
• Use system property log4j2.formatMsgNoLookups=true to disable message formatting
  • This is a reasonable workaround - But due to CVE-2021-45046 you may still have other vulnerabilities
  • Setting a shell environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true should work too
• Remove the following files from your jar file: log4j-core-2.XX.Y.jar  (This is a hack. A simple one but effective. This also remediates CVE-2021-45046)

  • org/apache/logging/log4j/core/net/JndiManager$1.class

  • org/apache/logging/log4j/core/util/JndiCloser.class

  • org/apache/logging/log4j/core/net/JndiManager$JndiManagerFactory.class

  • org/apache/logging/log4j/core/lookup/JndiLookup.class

  • org/apache/logging/log4j/core/net/JndiManager.class

  • org/apache/logging/log4j/core/selector/JndiContextSelector.class

• Ensuring your JRE is 1.8.121 or better. (This version doesn't fix the issue, it just eliminates one very easy to exploit attack vector.)
  • Not recommended but better than nothing. When combined with the limiting of creating socket connections, this will make payloads harder (but not impossible) to deploy.
  • But these 2 system properties must also be set to false (or unset) com.sun.jndi.rmi.object.trustURLCodebase,com.sun.jndi.cosnaming.object.trustURLCodebase
  • Newer JVM's can still fall victim to this attack with the older log4j2. It is beyond the scope of this FAQ to explain how. But the TL;DR is it the exploit becomes more application or application server specific.

More details on these CVE's via the ASF blog

Anchor
Q14 Q14

I found a vulnerability in JMXProxy

JMXProxy is a powerful servlet which has full access to all JMX capabilities. By design, enabling it opens you to a lot of security challenges. The equivalent of enabling generic remote JMX access at the JVM level.

With that in mind, if you enable it: You should at a minimum require an extremely strong password to protect this URL as well restrict the IP client list which may access it. (Ideally restricting it to localhost if possible)