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
(→‎UNIX)
Line 1: Line 1:
−
== Introduction ==
+
== Installation ==
−
 
+
* Choose an installation directory (referenced as '''TOMCAT_DIR''' from now on), preferably on a different drive to the OS.   
−
Most weaknesses in [http://tomcat.apache.org/ Apache Tomcat] come from incorrect or inappropiate configuration.  It is nearly always possible to make Tomcat more secure than the default out of the box installation.  What follows documents best practices and recommendations on securing a production Tomcat server, whether it be hosted on a Windows or Unix based operating system.  ''Please note that the section ordering is not a representation of the section importance.''
+
  do we get many advantages separating application and webapps?''  
−
 
+
  - 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)
−
== Software Versions ==
 
−
 
 
−
The first step is to make sure you are running the latest stable releases of software;
 
−
* Java Runtime Environment (JRE) or SDK
 
−
* Tomcat
 
−
* Third party libraries
 
−
This does not mean you have to upgrade all your production servers to a new (and potentially buggy) release which has just been made available to the public.  What you must do is download the latest stable bugfix release that has continual support.  For the JRE and Tomcat you should be looking at the last digits in the version number (5.5.'''X''') as it represents the bugfix information.  The bugs fixed in these releases are publicly available so if you don't upgrade you could be providing attackers with a very easy route to compromise your server.
 
−
 
 
−
== Installation of Apache Tomcat 5.5 ==
 
−
 
 
−
=== UNIX ===
 
−
 
 
−
* Create a tomcat user/group
 
−
* Download and unpack the core distribution (referenced as '''TOMCAT_DIR''' from now on) - I don't mean to nit pick, but couldn't we use CATALINA_HOME same as the tomcat docs? [[User:Stephendv|Stephendv]] 07:57, 9 October 2006 (EDT)
 
−
* Change '''TOMCAT_DIR''' ownership to tomcat user and tomcat group
 
−
* Change files in '''TOMCAT_DIR'''/conf to be readonly
 
−
* Make sure tomcat user has read/write access to /tmp and write (yes, only write) access to '''TOMCAT_DIR'''/log
 
−
* Change the default HTTP port to something other than 8080, by editing the Connector port attribute within the Catalina Service ('''TOMCAT_DIR'''/conf/server.xml).  This ensures less scripted attacks on your server, but in no way helps protect you from vulnerabilities.
 
−
 
 
−
=== Windows ===
 
−
 
 
−
* Download the core windows service installer
 
−
* Start the installation, click ''Next'' and ''Agree'' to the licence
 
−
* Untick ''native'', ''documentation'', ''examples'' and ''webapps'' then click ''Next''
 
−
* Choose an installation directory (referenced as '''TOMCAT_DIR''' from now on), preferably on a different drive to the OS.  ''do we get many advantages separating application and webapps?''  
 
−
- 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)
 
 
* Change the default HTTP port to something other than 8080.  This ensures less scripted attacks on your server, but in no way helps protect you from vulnerabilities.  
 
* Change the default HTTP port to something other than 8080.  This ensures less scripted attacks on your server, but in no way helps protect you from vulnerabilities.  
−
- As you say, there's probably not any real benefit to recommending this.  [[User:Stephendv|Stephendv]] 02:32, 9 October 2006 (EDT)
+
  - As you say, there's probably not any real benefit to recommending this.  [[User:Stephendv|Stephendv]] 02:32, 9 October 2006 (EDT)
−
* Choose an administrator username (NOT admin) and a secure password that complies with your organisations password policy.
 
−
* Complete tomcat installation, but do not start service.
 
−
* TODO: ''filesystem security''
 
−
 
 
−
=== Common ===
 
−
 
 
−
* Remove everything from '''TOMCAT_DIR'''/webapps (ROOT, balancer, jsp-examples, servlet-examples, tomcat-docs, webdav)
 
−
* Remove everything from '''TOMCAT_DIR'''/server/webapps (host-manager, manager)
 
−
* Replace default HTTP error pages (i.e. 404) ''can we specify a container wide location?''
 
−
  <error-page>
 
−
    <error-code>404</error-code>
 
−
    <location>/404.jsp</location>
 
−
  </error-page>
 
−
* Replace default error page (default is stacktrace) ''can we specify a container wide location?''
 
−
  <error-page>
 
−
    <exception-type>java.lang.Exception</exception-type>
 
−
    <location>/error.jsp</location>
 
−
  </error-page>
 
−
* Consider replacing '''TOMCAT_DIR'''/conf/server.xml with '''TOMCAT_DIR'''/conf/server-minimal.xml - ''work out what we lose''
 
−
* ''is it easy to remove the version string from the server HTTP header (Apache-Coyote/1.1) ?''
 
−
* Start Tomcat, deploy your applications into '''TOMCAT_DIR'''/webapps and hope it works!
 
  
 
== Network Security ==
 
== Network Security ==
  
 
Generic advice common to all server security (link).
 
Generic advice common to all server security (link).
−
 
+
- Not sure what information should go here? [[User:Stephendv|Stephendv]] 04:21, 16 October 2006 (EDT)
−
== Logging ==
 
−
 
 
−
* Audit trails
 
  
 
== User Input ==
 
== User Input ==
Line 69: Line 19:
 
* permission lockdown (see below)
 
* permission lockdown (see below)
  
−
== Encryption ==
+
  - I think this section would be more appropriate for apps themselves, rather than applying to the server as a whole.
−
 
 
−
* SSL for password or other sensitive data exchange (''bordering on application security, not specific to tomcat'')
 
−
* SSL for connections (JDBC, LDAP, etc ..)
 
−
 
 
−
== Java Security ==
 
−
 
 
−
=== Running Tomcat with a Security Manager===
 
−
[[User:Stephendv|Stephendv]] 04:56, 9 October 2006 (EDT)
 
−
* The default Tomcat configuration provides good protection for most requirements.  Edit the $CATALINA_HOME/conf/catalina.policy to define a custom policy.
 
−
* Start Tomcat with the ''-security'' option to enable the security manager.  Optionally edit the startup scripts to ensure that  Tomcat is always started with the security manager.
 
−
 
 
−
===Locking down web application permissions===
 
−
* ...
 
−
 
 
−
== Miscellaneous ==
 
−
 
 
−
* Storing cleartext passwords in configuration files (article to add)
 

Revision as of 08:21, 16 October 2006

Installation

  • Choose an installation directory (referenced as TOMCAT_DIR from now on), preferably on a different drive to the OS. 
 do we get many advantages separating application and webapps? 
  - it could prevent path traversal under windows, but not unix.  Separating apps from OS is common good practice anyway.  Stephendv 02:32, 9 October 2006 (EDT)
  • Change the default HTTP port to something other than 8080. This ensures less scripted attacks on your server, but in no way helps protect you from vulnerabilities. 
  - As you say, there's probably not any real benefit to recommending this.  Stephendv 02:32, 9 October 2006 (EDT)

Network Security

Generic advice common to all server security (link). 

- Not sure what information should go here? Stephendv 04:21, 16 October 2006 (EDT)

User Input

User data, whether it be HTTP headers or parameters, should '"never"' be trusted. It 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.

  • global filters
  • 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.
Retrieved from "https://wiki.owasp.org/index.php?title=Talk:Securing_tomcat&oldid=10670"