This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Talk:Securing tomcat"

From OWASP
Jump to: navigation, search
(Securing Manager WebApp)
 
(32 intermediate revisions by 12 users not shown)
Line 1: Line 1:
== Installation ==
+
== InvokerServlet ==
* Choose an installation directory (referenced as '''TOMCAT_DIR''' from now on), preferably on a different drive to the OS.  
+
There needs to be an addendum in here about disabling the InvokerServlet. See my blog entry at [[http://yet-another-dev.blogspot.com/2009/12/this-post-is-especially-for-anyone.html yet-another-dev.blogspot.com]] for details about why this is a bad idea. --[[User:Chris Schmidt|Chris Schmidt]] 22:03, 17 December 2009 (UTC)
 
:do we get many advantages separating application and webapps? - Darren Edmonds
 
::it could prevent path traversal under windows, but not unix. Separating apps from OS is common good practice anyway. [[User:Stephendv|Stephendv]] 02:32, 9 October 2006 (EDT)
 
  
== Network Security ==
+
== File permissions ==
  
Generic advice common to all server security (link).
+
Hmm, what does "Make sure tomcat user has read/write access to /tmp" mean? 
  
:Not sure what information should go here? [[User:Stephendv|Stephendv]] 04:21, 16 October 2006 (EDT)
+
Tomcat creates a directory "temp", not "tmp", and read/write on a directory doesn't actually allow reading or writingI assume the intention is "chmod 700 temp"... would love if anyone can clarify.
:I was thinking of a firewall discussion in relation to protecting the serverPerhaps this should be changed to only mention the shutdown port needs protecting in tomcat [[User:dledmonds|dledmonds]]
+
[[User:Douglasheld|Douglasheld]] 18:06, 3 April 2009 (UTC)
  
== User Input ==
+
== Newer Tomcat branches ==
  
User data, whether it be HTTP headers or parameters, should '"never"' be trustedIt is usually the responsibility of the application to validate data, but it is important that one poorly written application doesn't compromise Tomcat as a whole.
+
This page is hopelessly outdated for anyone working with the Tomcat 6 branchWe need to figure out the best way to document security measures for the different supported branches.
 +
[[User:Ken|Ken]] 10:25, 20 March 2009 (UTC)
  
* global filters
+
I've not had call to use Tomcat 6, but in a few months I plan to start experimenting with the embedded version.  I don't mind expanding the article to have a section on 6 (and keep the section on 5.5), but I can't contribute anything just yet.  My preference would be a single article as it will cut down on duplication.  In the meantime, any differences, areas to cover, new features, etc. that others could note down will help speed things up. [[User:Dledmonds|Darren]] 09:11, 26 March 2009 (UTC)
* global error pages (see above)
 
* permission lockdown (see below)
 
  
:I think this section would be more appropriate for apps themselves, rather than applying to the server as a whole. [[User:Stephendv|Stephendv]] 04:24, 16 October 2006 (EDT)
+
== HttpOnly configuration ==
:Agree the section doesn't seem relevant to Tomcat as it is, but I wanted to focus on preventing one webapp ruining it for everyone.  Perhaps a full rundown on java security is out of scope, but how could we prevent a poorly written download webapp from using path traversal exploits to download files of other webapps? [[User:dledmonds|dledmonds]]
 
  
== Securing Manager WebApp ==
+
Tomcat versions from 5.5.28 and 6.0.19 support the HttpOnly [http://www.owasp.org/index.php/HttpOnly] cookie option.
  
* By default there are no users with the manager role.  To make use of the manager webapp you need to add a new user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
+
This is configured in the conf/context.xml file:
  <user username="darren" password="ReallyComplexPassword" roles="manager"/>
 
  
* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml
+
  <Context useHttpOnly="true">
  &lt;!-- allow only LAN IPs to connect to the manager webapp --&gt;
+
...
  &lt;!-- contrary to the current Tomcat 5.5 documation the value for '''allow''' is not a regular expression --&gt;
+
</Context>
  &lt;!-- future versions may have to be specificed as 192\.168\.1\.* --&gt;
 
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
 
        allow="192.168.1.*" />
 
  
  &lt;!-- allow only LAN hosts to connect to the manager webapp --&gt;
+
[[User:Simon Bennetts|Simon Bennetts]] 14:40, 18 June 2010 (UTC)
  &lt;!-- contrary to the current Tomcat 5.5 documation the value for '''allow''' is not a regular expression --&gt;
 
  &lt;!-- future versions may have to be specificed as *\.localdomain\.com --&gt;
 
  <Valve className="org.apache.catalina.valves.RemoteHostValve"
 
        allow="*.localdomain.com" />
 
  
* You can rename the manager webapp to something else, e.g. ''foobar''  (''confirm nothing breaks in this move'')
+
== Overriding Tomcat Version Number ==
** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
 
** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
 
** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''
 
  
== Miscellaneous ==
+
Rebuilding the catalina.jar to alter ServerInfo.properties may not be an ideal way to override the version number, the same effect can be achieved without repackaging JARs in the default distribution (repackaging can be somewhat intrusive and/or impractical). Classloader classpaths can be patched using strategically placed files on the classpath. Classes that are loaded first always take precedence, the same goes for properties files, hence you can override by creating files in the following places:
  
* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]
+
# For Tomcat 5.5 (inject your new file onto the path of the server classloader):
 +
${catalina.home}/server/classes/org/apache/catalina/util/ServerInfo.properties
  
=== Using Port 80 ===
+
# For Tomcat 6 (inject it onto the path of the common classloader, or whichever classloader is loading catalina.jar):
 +
${catalina.home}/lib/org/apache/catalina/util/ServerInfo.properties
  
If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
+
In both cases, ${catalina.home} is typically either the root of your local installation, or your global installation if you are making use of disjoint installs using ${catalina.base} to provide instance-specific information.
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat
 
  
On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this).  It is a very bad idea to run Tomcat as root, so the options are;
+
== autoDeploy feature ==
* Use Apache running on port 80 and mod_jk to proxy requests to Tomcat  (''is mod_jk the correct version?'')
 
* Run Tomcat as root, but in a chroot jail
 
* Use a tool like authbind to enable a non root user to bind to ports below 1024
 
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80.  This has the disadvantage that internal redirects still need to use 8080.
 
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
 
* Use JSVC/procrun
 
  
=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===
+
Wouldn't it make sense to disable the autoDeploy feature in production environments for added security?
  
When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml  Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.
+
[[User:Pierre Ernst|Pierre Ernst]] 2011-08-12
  
If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.
+
== Disabling weak ciphers in Tomcat ==
  
If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.
+
Copied from [https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1225]
  
Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files.  You'd also need a way to create encoded passwords.
+
In order to disable weak ciphers, please modify your SSL Connector container attribute inside server.xml with the following information.
  
In the case of a JDBC pool what you can do is;
+
ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
+
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
+
  SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
* make sure the Tomcat configuration files are only accessible to the tomcat user
+
  SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
 +
 
 +
Example:
 +
 
 +
<Connector port="443" maxHttpHeaderSize="8192" address="192.168.1.1"
 +
enableLookups="false" disableUploadTimeout="true"
 +
acceptCount="100" scheme="https" secure="true"
 +
clientAuth="false" sslProtocol="SSL"
 +
ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
 +
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
 +
  SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, 
 +
  SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
 +
keystoreFile="SomeDir/SomeFile.key" keystorePass="Poodle"
 +
truststoreFile="SomeDir/SomeFile.truststore" truststorePass="HomeRun"/>
 +
 
 +
[[User:Psiinon]] 2011-10-06
 +
 
 +
[[User:Dirk Wetter]] 2014-03-27 : Those ciphers were maybe ok in 2011, in 2014 I would not recommend using RC4 and CBC ciphers!
 +
 
 +
==  No missing steps required in Tomcat 7 or 8 ==
 +
I've done some research and as far as I can tell there are no recommended hardening steps for Tomcat 7 or 8 missing from this guide.
 +
 
 +
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Securing_Management_Applications
 +
http://chandank.com/application-server/tomcat/apache-tomcat-hardening-and-security-guide
 +
 
 +
The SSL Cipher list should be upgraded however:
 +
http://www.sslshopper.com/article-how-to-disable-weak-ciphers-and-ssl-2-in-tomcat.html
 +
 
 +
[[User:Kenneth Kron|Kenneth Kron]] ([[User talk:Kenneth Kron|talk]]) 16:56, 22 August 2014 (CDT)

Latest revision as of 00:38, 23 August 2014

InvokerServlet

There needs to be an addendum in here about disabling the InvokerServlet. See my blog entry at [yet-another-dev.blogspot.com] for details about why this is a bad idea. --Chris Schmidt 22:03, 17 December 2009 (UTC)

File permissions

Hmm, what does "Make sure tomcat user has read/write access to /tmp" mean?

Tomcat creates a directory "temp", not "tmp", and read/write on a directory doesn't actually allow reading or writing. I assume the intention is "chmod 700 temp"... would love if anyone can clarify. Douglasheld 18:06, 3 April 2009 (UTC)

Newer Tomcat branches

This page is hopelessly outdated for anyone working with the Tomcat 6 branch. We need to figure out the best way to document security measures for the different supported branches. Ken 10:25, 20 March 2009 (UTC)

I've not had call to use Tomcat 6, but in a few months I plan to start experimenting with the embedded version. I don't mind expanding the article to have a section on 6 (and keep the section on 5.5), but I can't contribute anything just yet. My preference would be a single article as it will cut down on duplication. In the meantime, any differences, areas to cover, new features, etc. that others could note down will help speed things up. Darren 09:11, 26 March 2009 (UTC)

HttpOnly configuration

Tomcat versions from 5.5.28 and 6.0.19 support the HttpOnly [1] cookie option.

This is configured in the conf/context.xml file:

<Context useHttpOnly="true">
...
</Context>

Simon Bennetts 14:40, 18 June 2010 (UTC)

Overriding Tomcat Version Number

Rebuilding the catalina.jar to alter ServerInfo.properties may not be an ideal way to override the version number, the same effect can be achieved without repackaging JARs in the default distribution (repackaging can be somewhat intrusive and/or impractical). Classloader classpaths can be patched using strategically placed files on the classpath. Classes that are loaded first always take precedence, the same goes for properties files, hence you can override by creating files in the following places:

# For Tomcat 5.5 (inject your new file onto the path of the server classloader):
${catalina.home}/server/classes/org/apache/catalina/util/ServerInfo.properties
# For Tomcat 6 (inject it onto the path of the common classloader, or whichever classloader is loading catalina.jar):
${catalina.home}/lib/org/apache/catalina/util/ServerInfo.properties

In both cases, ${catalina.home} is typically either the root of your local installation, or your global installation if you are making use of disjoint installs using ${catalina.base} to provide instance-specific information.

autoDeploy feature

Wouldn't it make sense to disable the autoDeploy feature in production environments for added security?

Pierre Ernst 2011-08-12

Disabling weak ciphers in Tomcat

Copied from [2]

In order to disable weak ciphers, please modify your SSL Connector container attribute inside server.xml with the following information.

ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, 
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, 
 SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, 
 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"

Example:

<Connector port="443" maxHttpHeaderSize="8192" address="192.168.1.1"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="SSL"
ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, 
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, 
 SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,   
 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
keystoreFile="SomeDir/SomeFile.key" keystorePass="Poodle"
truststoreFile="SomeDir/SomeFile.truststore" truststorePass="HomeRun"/>

User:Psiinon 2011-10-06

User:Dirk Wetter 2014-03-27 : Those ciphers were maybe ok in 2011, in 2014 I would not recommend using RC4 and CBC ciphers!

No missing steps required in Tomcat 7 or 8

I've done some research and as far as I can tell there are no recommended hardening steps for Tomcat 7 or 8 missing from this guide.

http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Securing_Management_Applications http://chandank.com/application-server/tomcat/apache-tomcat-hardening-and-security-guide

The SSL Cipher list should be upgraded however: http://www.sslshopper.com/article-how-to-disable-weak-ciphers-and-ssl-2-in-tomcat.html

Kenneth Kron (talk) 16:56, 22 August 2014 (CDT)