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.
Installation
We start by installing Java and Tomcat. You now arrive at a fork in the road. Your choices:
- Install packages from Ubuntu’s package manager.
- 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 /usr/share/tomcat8/bin/version.sh
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 tomcat8If you now pop your Public IP address or domain name into your browser, Tomcat goes like a bought one.
Hardening
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" connectionTimeout="20000" 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 ubuntu@ip-172-31-4-95:/var/lib/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 ubuntu@ip-172-31-4-95:/var/lib/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)
http://tomcat.apache.org/tomcat-8.5-doc/security-howto.html#Non-Tomcat_settings
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.
http://tomcat.apache.org/tomcat-8.5-doc/security-howto.html#Security_manager
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.