Uncannier Software

It's not enough to just be uncanny

Tomcat in AWS – Part 3 – Installation and Security Hardening

This article is part 3 of a series that started here. In this post we get down to the business of actually installing Tomcat into the Ubuntu 18.04 LTS AWS EC2 instance created in earlier posts. I go in to some detail on how to secure your Tomcat installation.


We start by installing Java and Tomcat. You now arrive at a fork in the road. Your choices:

  1. Install packages from Ubuntu’s package manager.
  2. Install specific versions, perhaps even installing Oracle JRE instead of the OpenJDK JRE.

The second option will appeal to you if you require precise control over tool versions for compatibility reasons. Or if you enjoy self-flagellation. In my case, I’m going with option 1. This gets me Tomcat 8.5 and Java 10.

sudo apt install default-jre
sudo apt install tomcat8

This installs Tomcat to /var/lib/tomcat8

You can check the installed versions as follows:

java -version

Apache AJP Connector

In the previous post on Apache Web Server, we setup Proxy AJP for forwarding of requests from Apache Web Server to Tomcat. We now need to enable Tomcat’s AJP Connector so it can receive the forwarded requests.

sudo nano /var/lib/tomcat8/conf/server.xml

Uncomment the following line.

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

And restart Tomcat.

sudo systemctl restart tomcat8

If you now pop your Public IP address or domain name into your browser, Tomcat goes like a bought one.


OK so let’s make the Tomcat installation a little more secure.

Default Web Applications

Administration and example web applications are often installed as part of a Tomcat installation, although they aren’t installed by default using Ubuntu Tomcat8 package installation.

Per Apache’s advice, you should remove all of these default web applications. In case you are in any doubt, you should NOT use the Manager and Host Manager applications to deploy and manage your web applications. Instead, you should use the ubuntu user over SSH, and restrict the SSH port (22) to only be accessible from your IP address, as per the AWS Security Group configuration in part 1 of this series.

Remove HTTP Connector

The HTTP Connector is the only connector enabled by default in a Tomcat installation. In my previous post, I installed Apache Web Server as a front-end to Tomcat, and used Proxy AJP to forward all requests to Tomcat. In that architecture, only the AJP Connector is required, and the HTTP Connector is redundant. Thus it should be disabled.

sudo nano /var/lib/tomcat8/conf/server.xml

Comment out the following definition.

    <Connector port="8080" protocol="HTTP/1.1"
               redirectPort="8443" />

Note that port 8080 was not open in our AWS Security Group anyway, so this port is only a threat if an attacker can exploit some other vulnerability first.

Disable Shutdown Port

By default, Tomcat supports shutdown commands being received on port 8005. We don’t have this port open in the AWS Security Group, so there’s not much risk associated with it. Ubuntu doesn’t even use it for systemctl. Instead it kills Tomcat using the PID. Nonetheless we disable the port, to be sure to be sure, by changing 8005 to -1.

sudo nano /var/lib/tomcat8/conf/server.xml
<Server port="-1" shutdown="SHUTDOWN">

File & Directory Ownership

Per Apache’s advice, we tighten the file and directory ownership and permissions.

In the Ubuntu package Tomcat8 installation, Tomcat will already be running under the tomcat8 user instead of root. However, the tomcat8 user is left with write permissions to the lib and webapps directories:

ubuntu@ip-172-31-4-95:/var/lib/tomcat8$ ls -l
total 12
lrwxrwxrwx 1 root    root      12 Aug 13  2018 conf -> /etc/tomcat8
drwxr-xr-x 2 tomcat8 tomcat8 4096 Aug 13  2018 lib
lrwxrwxrwx 1 root    root      17 Aug 13  2018 logs -> ../../log/tomcat8
drwxr-xr-x 2 root    root    4096 Apr 14 09:23 policy
drwxrwxr-x 3 tomcat8 tomcat8 4096 Apr 11 13:05 webapps
lrwxrwxrwx 1 root    root      19 Aug 13  2018 work -> ../../cache/tomcat8

This is less than desirable because, if an attacker could compromise a web application, they could modify the contents of these directories.

Therefore we aim to disallow the tomcat8 user from changing anything in the lib and webapps directories, but allow the ubuntu user to write to the lib and webapps directories when deploying over SSH.

We set lib and webapps directories to both be owned by root but with ubuntu group. We set permissions to 775 on both directories. That way, the ubuntu user can write, but the tomcat8 user can only read.

ubuntu@ip-172-31-4-95:/var/lib/tomcat8$ sudo chown root:ubuntu lib
ubuntu@ip-172-31-4-95:/var/lib/tomcat8$ sudo chown root:ubuntu webapps
ubuntu@ip-172-31-4-95:/var/lib/tomcat8$ sudo chmod 775 lib
ubuntu@ip-172-31-4-95:/var/lib/tomcat8$ ls -l
total 12
lrwxrwxrwx 1 root root     12 Aug 13  2018 conf -> /etc/tomcat8
drwxrwxr-x 2 root ubuntu 4096 Aug 13  2018 lib
lrwxrwxrwx 1 root root     17 Aug 13  2018 logs -> ../../log/tomcat8
drwxr-xr-x 2 root root   4096 Apr 14 09:23 policy
drwxrwxr-x 3 root ubuntu 4096 Apr 11 13:05 webapps
lrwxrwxrwx 1 root root     19 Aug 13  2018 work -> ../../cache/tomcat8

Disable Automatic Deployment

I take heed of Apache’s own practices:

Taking the Tomcat instances at the ASF as an example (where auto-deployment is disabled and web applications are deployed as exploded directories)


Thus I disable automatic deployment and unpacking of WARs.

sudo nano /var/lib/tomcat8/conf/server.xml

Set unpackWARs and autoDeploy both to false.

      <Host name="localhost"  appBase="webapps"
            unpackWARs="false" autoDeploy="false">

With unpackWARs disabled, it will likely be desirable to unpack from the command line over SSH. Since we only have JRE, not JDK, installed, you may wish to install a jar tool. You can use the following command to avoid installing the entire JDK.

sudo apt install fastjar

Security Manager

In Apache’s own words:

Enabling the security manager is usually done to limit the potential impact, should an attacker find a way to compromise a trusted web application . A security manager may also be used to reduce the risks of running untrusted web applications (e.g. in hosting environments) but it should be noted that the security manager only reduces the risks of running untrusted web applications, it does not eliminate them.


The aim of this series is to create an environment for running trusted applications. Hence we can dismiss the untrusted motivations for using the Security Manager.

If Security Manager is enabled, it’s not possible to include a context.xml within your web applications. Instead the context needs to be specified within the Tomcat installation. As I’m advocating to use the ubuntu user and SSH port to both manage your server and deploy web applications, there is no material advantage to this restriction. Thus I have elected to not enable the Security Manager. YMMV.


Tagged ,

Leave a Reply

Your email address will not be published. Required fields are marked *