Talk:Securing tomcat

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? - Darren Edmonds

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)

Network Security

Generic advice common to all server security (link).

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

I was thinking of a firewall discussion in relation to protecting the server. Perhaps this should be changed to only mention the shutdown port needs protecting in tomcat dledmonds

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. Stephendv 04:24, 16 October 2006 (EDT)

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? dledmonds

Securing Manager WebApp

• Brief description of how to create a valid manager capable user

• Using a valve to filtering by IP or hostname to only allow a subset of machine to connect (i.e. LAN machines). Add one of the following within the Context tag in CATALINA_HOME/conf/Catalina/localhost/manager.xml

 <!-- allow only LAN IPs to connect to the manager webapp -->
 <!-- contrary to the current Tomcat 5.5 documation the value for allow is not a regular expression -->
 <!-- future versions may have to be specificed as 192\.168\.1\.* -->
 <Valve className="org.apache.catalina.valves.RemoteAddrValve"
        allow="192.168.1.*" />

 <!-- allow only LAN hosts to connect to the manager webapp -->
 <!-- contrary to the current Tomcat 5.5 documation the value for allow is not a regular expression -->
 <!-- future versions may have to be specificed as *\.localdomain\.com -->
 <Valve className="org.apache.catalina.valves.RemoteHostValve"
        allow="*.localdomain.com" />

• Renaming the manager webapp

Miscellaneous

• Tomcat Security FAQ

Using Port 80

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;

• 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;

• 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 Iptables to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
• Run Squid as a web accelerator in front of Tomcat
• Use JSVC/procrun

Cleartext Passwords in CATALINA_HOME/conf/server.xml

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.

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.

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.

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 the case of a JDBC pool what you can do is;

• make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
• make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
• make sure the Tomcat configuration files are only accessible to the tomcat user