TDS Tutorial: Additional Security Configuration

We have compiled a list of a few additional step you should take to help secure Tomcat and your TDS server. This is not a complete laundry list of security fixes! Please use it as a starting point when securing your server.

Keep Tomcat, Java and the TDS up-to-date

Running the most current versions of software keeps your environment protected against known security vulnerabilities.

Resources to help stay informed:

• Tomcat security reports
  A complete list of known and documented security vulnerabilities associated with each Tomcat release.
• tomcat-users mailing list
  A high-traffic mailing list made up of Tomcat users. New releases of Tomcat are likely to be announced here.
• Java SE Security
  Sun's Java security page which includes a chronology of Java security issues and user forums.
• thredds mailing list
  The THREDDS mailing list where announcements of new releases will be made.
• Buqtraq vunerability database
  SecurityFocus' database of all known vulnerabilities for all different types of software from different vendors.

Removing the default Tomcat web applications

It is generally good practice to remove any un-used web applications out of ${tomcat_home}/webapps. Tomcat ships with several default web applications, that you may want to consider removing if they are not being utilized:

• The ROOT application is Tomcat's DocumentRoot and contains the server's main web page. Give thought tot he content that is placed in ROOT/, as it will be readily available. (Note: if you want to utilize a robots.txt file to restrict crawler activity, ROOT/ is the place it will go.)
• The manager application is used for remote management of web applications. To use this application, you must add a user with role of manager in tomcat-users.xml. Obviously, if you are not planning to use the manager application, it should be removed.
• The host-manager application is used for management of virtual hosts. To use this application, you must add a user with role of host-manager in tomcat-users.xml. If you are not planning to do a lot of virtual hosting in Tomcat this application should be removed.
• The examples application should probably be removed from a production server to minimize security exposure.
• The docs are a copy of the Tomcat documentation found online. Unless you have need for a local copy, removing docs would help to tidy-up ${tomcat_home}/webapps.

Denying access to the TDS by remote IP address or host

Use the RemoteHostValve or RemoteAddrValve to restrict access to the TDS. For example, the following Valve declarations show ways to either allow or deny access to content (note that the allow and deny values are comma separated lists of regular expressions):

<!-- This example denies access based on IP addresses -->
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
       deny="128\.117\.47\.201,128\.107\.157\.210,96\.33\.56\.215" />

<!-- This example denies access based on host names -->
<Valve className="org.apache.catalina.valves.RemoteHostValve"
           deny="www\.badguys\.com,www\.bandwidthhog\.net" />

<!-- Wildcard characters can with the both valves -->
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
       deny="128\.117\.47\..*" />

<!-- This example only allows the specified IPs to access  -->
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
          allow="128\.117\.140\..*" />

The last example above would be a good candidate to utilize for adding an extra layer of security to the manager application if you were certain it would only need to be accessed from within a specific range of IP address.

Note: These valves rely on incoming IP addresses or hostnames which are vulnerable to spoofing.

For more information, see the Tomcat Valve Component documentation.

Blocking TDS content from being indexed by web crawlers

Use a robots.txt file to prevent crawlers from indexing content.

The TDS provides a basic and very restrictive robots.txt file for you to use:

-bash-3.2$ less ${tomcat_home}/webapps/thredds/WEB-INF/initialContent/root/robots.txt
# disallow everything
User-agent: *
Disallow: /

The "User-agent: *" means this section applies to all robots. The "Disallow: /" tells the robot that it should not visit any pages on the site.

To active the robots.txt file, you will need to move it to Tomcat's DocumentRoot:

-bash-3.2$ cd  ${tomcat_home}/webapps/ROOT
-bash-3.2$ cp ${tomcat_home}/webapps/thredds/WEB-INF/initialContent/root/robots.txt .

Note: not all crawlers obey the robots.txt file.

For more information, see: http://www.robotstxt.org/robotstxt.html.

Running Tomcat as a user other than root

Background info: The JVM doesn't fork at all, nor does it support setuid() calls. The JVM (and therefore Tomcat) is one process. The JVM is a virtual machine with many threads under the same process. Because of OS constraints - all threads in the same process must run under the same user id. No thread may run as root unless they are all root.

Hence, any programs run in Tomcat (TDS, manager application, other JSPs and servlets) will run as the root user.

The scenario: Imagine an attacker who manages to exploit a weakness in Tomcat or something running in webapps/ to run arbitrary commands: those commands will be run as the superuser!

The solution: We strongly discourage running Tomcat as the root user and recommend creating a dedicated user and group for running the Tomcat process.

• Creating the dedicated user and group for running Tomcat both called: tomcat. /opt/tomcat is the home directory of the tomcat user. The groupadd and useradd commands were run as the root:

# groupadd tomcat
# useradd -g tomcat -d /opt/tomcat tomcat
# passwd tomcat

• Changing permission in ${tomcat_home} for the new user:

# cd ${tomcat_home}/../
# chown -R tomcat:tomcat apache-tomcat-6.0.18
# ls -l  apache-tomcat-6.0.18
total 92
drwxr-xr-x 2 tomcat tomcat  4096 2008-10-28 16:45 bin
drwxr-xr-x 2 tomcat tomcat  4096 2008-11-02 09:45 conf
drwxr-xr-x 3 tomcat tomcat  4096 2008-10-28 17:15 content
drwxr-xr-x 2 tomcat tomcat  4096 2008-10-28 16:45 lib
-rw-r--r-- 1 tomcat tomcat 37951 2008-07-21 18:01 LICENSE
drwxr-xr-x 2 tomcat tomcat  4096 2008-10-30 15:11 logs
-rw-r--r-- 1 tomcat tomcat   556 2008-07-21 18:01 NOTICE
-rw-r--r-- 1 tomcat tomcat  7317 2008-07-21 18:01 RELEASE-NOTES
-rw-r--r-- 1 tomcat tomcat  6587 2008-07-21 18:01 RUNNING.txt
drwxr-xr-x 2 tomcat tomcat  4096 2008-10-28 16:45 temp
drwxr-xr-x 7 tomcat tomcat  4096 2008-10-31 11:45 webapps
drwxr-xr-x 3 tomcat tomcat  4096 2008-10-28 16:47 work

Note: the tomcat user and group should not have permission to write or execute in other directories outside of ${tomcat_home}.

• Modify any scripts you have for server init processes to invoke the tomcat user:

su - tomcat -c /opt/tomcat/bin/startup.sh

Blocking non-essential port access at the firewall

Type the following in your terminal window:

-bash-3.2$ telnet localhost 8005

When prompted, issue Tomcat the shutdown command by typing SHUTDOWN:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SHUTDOWN

This should have shutdown Tomcat. Confirm this by running the ps command:

Connection to localhost closed by foreign host.
-bash-3.2$ ps -ef | grep tomcat
thredds  21715 21682  0 14:02 pts/2    00:00:00 grep tomcat

This example showed how easy it was issue commands to Tomcat if you know:

1. the correct port number; and
2. the command expected on that port.

.

Unless you are on a private network, you need a firewall to restrict who is allowed to access network ports. We recommend working with you systems/network administrator to block access to all non-essential ports at the firewall. For running the TDS, keep in mind the following:

• Port 8080 should have unrestricted access unless you plan to proxy requests to Tomcat from and HTTP server.
• If you are allowing any remote management by using the TDS Remote Management Tool or the Tomcat manager application, you must also open up port 8443.

For more information, see: Linux Firewalls Using iptable

Running Tomcat behind an HTTP server

It is not uncommon to run Tomcat as an application server behind an HTTP server. Tomcat has a couple of different connectors that allow you to set up this configuration:

• AJP
• mod_proxy on Apache HTTP Server 2.x

For an interesting analysis on Tomcat performance when run as an application server behind an HTTP server, see the Tomcat Tuning free online chapter in Tomcat: The Definitive Guide (2007). Check out the timings between Tomcat and Apache.

For more information on Tomcat connectors in general, see the Tomcat connector Documentation Index.

Running Tomcat under a JVM Security Manager

The JVM Security Manager that comes with Tomcat imposes a fine-grained security restrictions to all Java applications running the JVM. It confines the Java applications in a sandbox, and restricts them from utilizing certain features of the Java language Tomcat normally is able to access.

There are pros and cons to using the Security Manager. If are hosting untrusted servlets or JSP on your server, then implementing the Security Manager may be a good idea. Be aware the Security Manager may prevent trusted web applications (like the TDS) from performing certain functions if configured to restrictively.

For more information about the Security Manager, see the Tomcat Security Manager HOW-TO documentation.

Online Resources

• Tomcat Security FAQ

Last changed Sep 2012. Please send comments to THREDDS support.