Tomcat Security Primer

02/03/2017 11:35 AM
- Tech Tips & Other Resources

Apache Tomcat Security Primer

Tomcat is one of the most widely used Java application server. More than 1 in 200 web sites are powered by Tomcat, and when considering the most active web sites on the Internet the percentage is even higher. This is because Tomcat is designed for high performance and security.

According to the official Apache Tomcat Wiki Pages: “The Apache Tomcat Security Team rates the impact of each security flaw that affects Tomcat. We've chosen a rating scale quite similar to those used by other major vendors in order to be consistent. Basically the goal of the rating system is to answer the question "How worried should I be about this vulnerability?".

Since Tomcat is built as part of a community process that involves both user and developer, most vulnerabilities (categorized as Critical, Important, Moderate and Low) are discovered by the Tomcat community itself or security researchers, and quickly patched.

The default configuration of Tomcat is secure but there are some additional steps you can take to harden the service.

This primer provides some guidance on how to implement practical restrictions and hardening to prevent unwanted access, in the following 4 areas:

Securing Tomcat Installation
Securing Tomcat Manager
Securing your Operating System
Securing Your Applications deployed in Tomcat

Securing Apache Tomcat

Keep your version up to date - As Tomcat is an active open source project, the most important way to improve the security is to keep your version up to date. New bug fixes and security patches are added in every release. New issues that may apply to your use of Tomcat are discussed in the “Apache Tomcat Security Updates”. We advise that you always upgrade to the latest stable version of Tomcat. You can download the latest version of Tomcat from the eApps Repository. If you are using a Tomcat package provided by eApps we recommend you check the Release Notes section of our support portal.
Check your logs - Checking your logs is a valuable procedure in identifying security holes, application failures, database connection issues, application bugs and sources of attacks. The Tomcat package provided by eApps logs to /var/log/tomcatX/catalina.out by default. You can change the log level from /etc/tomcatX/tomcat.conf file.
Directory and files permissions - Even though Tomcat has a great security ranking, you should make sure to close out back doors, and limit file access from the front / back end to unwanted visitors. For example:

Always set tomcat user as the owner of the folder of tomcat

chown -R tomcat:tomcat /opt/tomcat

Users can not modify the configuration of tomcat

chmod -R g+r /opt/tomcat/conf

Users can modify the other folders

chmod -R g+w /opt/tomcat/logs

chmod -R g+w /opt/tomcat/temp

chmod -R g+w /opt/tomcat/webapps

chmod -R g+w /opt/tomcat/work

Activate the sticky-bit for new files keep permissions defined

chmod -R g+s /opt/tomcat/conf

chmod -R g+s /opt/tomcat/logs

chmod -R g+s /opt/tomcat/temp

chmod -R g+s /opt/tomcat/webapps

chmod -R g+s /opt/tomcat/work

Finally, Add other users who should use tomcat to the “tomcat” user group

usermod -a -G tomcat USER

Additional information can be found in the Apache Tomcat Security How to:

Tomcat 7: https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

Tomcat 8: https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html

Tomcat 9: https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html

If you are using a Tomcat package provided by eApps, these permissions are already set.

If you have a custom setup, make sure your tomcat is run as “tomcat” user and not “root” as it is a security risk.

Deployment settings - Tomcat can be configured to automatically deploy applications based on one of the deployment parameters :

Deploying on a running Tomcat server
Deployment on Tomcat startup
Deploying using the Tomcat Manager
Deploying using the Client Deployer Package

If you would like to know more about each deployment configuration, then check the official documentation

In most of the scenarios, developers will use the auto-deployment feature. According to the official documentation you can use any of the deployment options above, however enabling auto deployment on a production environment is highly discouraged, Enabling this feature makes it a lot easier for an attacker to gain access to the server. Setting it to “false” will disable this feature.

If you are not sure how this is being configured, please contact eApps Support - support@eapps.com

If you’re deploying your applications using the Tomcat Manager, please check the next section

Shutdown Port - By default, Tomcat servers listen on localhost to Port 8005 for shutdown commands. This address is configured via the Server component's "port" attribute:

You may set the port to a non standard number like “-1”. With this configuration tomcat can only be shutdown from the Terminal by the root or tomcat user via a "kill" command. It is always recommended to use the sysctl or init scripts for tomcat shutdown or restarts.

Limiting AJP Connector - Default configuration will enable connector on all IP addresses. You can modify it below to only allow on a specific IP.

This might be a little complicated if you have several applications running on the same server, but it will improve the security of the app.

Security Manager

SecurityManager on Tomcat can protect your server from trojan servlets, JSPs, JSP beans, and tag libraries. Sometimes it can cause permission problem with your code. If you want to run sandboxed applets we recommend reviewing the official Tomcat Security Manager documentation. If you need assistance working with Security Manager please contact sales@eapps.com.

Tomcat Manager

In many production environments it is very useful to have the capability to manage your web applications without having to shutdown and restart Tomcat. However, for security reasons, Manager is disabled by default. Our User Guide for Tomcat includes a section for enabling the Tomcat Manager. Enabling tomcat manager is not recommended unless you strictly follow the below.

Limit access - Access to the Manager application should be limited to your/developers IP addresses. Application users don’t need access to Tomcat Manager - You can use Fail2ban to protect yourself from brute force attackers. Fail2ban is installed in all our virtual servers.
Access passwords – Each tomcat installations come with random passwords set for tomcat manager users. We strongly advice you to change the passwords every few months. You can change the passwords from the file /opt/tomcatX/conf/tomcat-users.xml.

You can learn more about the Web Tomcat Manager here

Secure your OS

Securing your base OS should be the first place you start. Keep the OS updated with all the latest patches and updates.

Setup your firewall to block unwanted ports
Always run Tomcat using the tomcat user, and make sure if you allow other users to make changes over tomcat, allow the minimum privileges as possible. If you install tomcat from the eApps repository, the service will run as tomcat user.
Start/stop/restart services should be done from the control panel or using the sysctl commands or init scripts, not from the tomcat binary files.
If you have a custom install, setup a tomcat user and run the service as this user.

Secure your applications

Your application security has an equal or greater role in securing the overall service. Hackers scan for known vulnerabilities on applications to gain access to the servers. Most of the DDOS attacks on tomcat applications are being performed on the following:

SQL Injection, XSS, CSRF, Request Header/URI exploits are the common vulnerabilities used by hackers.

How to prevent these attacks?

Testing for vulnerabilities – Test your applications using online scanning tools such as SiteLock Malware & Vulnerability Scanning or ratproxy
Enforcing HTTPS on your application, You should install an SSL certificate (in case you have not yet done so), and force all HTTP traffic to redirect over HTTPS. Also make sure your webserver is configured to only allow the most secure protocols (TLS 1.2 or higher)
No caching of secure data - Disable caching of secure data in the application.
No Small Key Length Ciphers - Make sure you perform a Security Optimization for webserver.