THREDDS Data Server version 4.6 Documentation

Production Server Overview

Notice: This section is out of date with respect to recent versions of Java and Tomcat

For a more up-to-date version of this content, please follow the TDS 5.0 guide.

Why Is Security Important?

Be afraid

  • Misconfiguration of Tomcat can introduce vulnerabilities in security.
  • The following recommendations should be considered "layers" of security: not completely effective by themselves, but more potent when combined.
  • This is not a complete laundry list of security fixes! Please use it as a starting point when securing your server.
  • Suggestions below listed in random order (section ordering is not a representation of the section importance).

Keeping Software Versions Up-To-Date

Rationale

  • Running the most current versions of software keeps your environment protected against known security vulnerabilities. This includes the JDK, Tomcat, the TDS and any other third-party libraries or software you run.
  • Stay Informed! Subscribe to announcement lists for Tomcat, the TDS and any other software you deploy, to stay abreast of new versions released due to security issues.
  • As soon as a security issue is disclosed, potential attackers will begin trying to exploit that vulnerability. It is important that you upgrade your software before an attacker uses the vulnerability against you.

Resources

  • Tomcat security reports
    A complete list of known and documented security vulnerabilities associated with each Tomcat release.
  • Tomcat mailing lists
    Various tomcat-related mailing lists, including tomcat-announce which is a low volume list for release announcements and security vulnerabilities.
  • Java SE Security
    Oracle'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.

Tomcat Process User/Group and ${tomcat_home} Permissions

Rationale

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 JVM process must run under the same user id. No thread may run as the root user unless they are all are run as the root user. Hence, any programs run in Tomcat (TDS, manager application, other JSPs and servlets) will run as the root user.
  • If you choose to run the Tomcat process as the root user, and an attacker manages to exploit a weakness in Tomcat or something running in webapps/ to run arbitrary commands, those commands will be run as the superuser!
  • We strongly discourage running Tomcat as the root user and recommend creating an unprivileged, dedicated user and group for running the Tomcat process.
    Create a dedicated user/group for running Tomcat

    In this example, both the user and group names will be names tomcat, and the user's home directory, aka ${tomcat_home}, is /opt/tomcat (notice the symlink below). The groupadd and useradd commands were run as the root:

    # groupadd tomcat
    # useradd -g tomcat -d /opt/tomcat tomcat
    # passwd tomcat
    
  • We also recommend restricting the permissions of the Tomcat user/group within ${tomcat_home}.
    Restrict the permissions in ${tomcat_home}
    1. Change the user/group ownership ${tomcat_home} to the tomcat user and tomcat group:
    2. # cd /opt
      # chown -R tomcat:tomcat apache-tomcat-8.0.24
      # ls -ld  *tomcat*
      drwxr-xr-x  9 tomcat tomcat  4096 Jul 15 16:03 apache-tomcat-8.0.24
      
    3. Change the user/ownership of the ${tomcat_home}/conf directory to be owned by the root user, have a group of tomcat and have a permission of user/group read only:
    4. # cd /opt/tomcat
      # ls -l
      total 92
      drwxr-xr-x 2 tomcat  tomcat  4096 Jul 15 16:05 bin
      drwxr-xr-x 2 tomcat  tomcat  4096 Jul 18 12:18 conf
      drwxr-xr-x 2 tomcat  tomcat  4096 Jul 15 16:03 lib
      drwxr-xr-x 2 tomcat  tomcat  4096 Feb  2 12:04 logs
      drwxr-xr-x 2 tomcat  tomcat  4096 Jul 15 16:03 temp
      drwxr-xr-x 7 tomcat  tomcat  4096 Jul 15 16:04 webapps
      drwxr-xr-x 2 tomcat  tomcat  4096 Feb  2 12:04 work
      
      # chown -R root:tomcat conf
      # chmod -R 440 conf/*
      # ls -l conf
      total 92
      -r--r----- 1 root    tomcat  9978 Feb  2 12:06 catalina.policy
      -r--r----- 1 root    tomcat  3713 Feb  2 12:06 catalina.properties
      -r--r----- 1 root    tomcat  1395 Feb  2 12:06 context.xml
      -r--r----- 1 root    tomcat  1353 Jul 18 12:14 keystore
      -r--r----- 1 root    tomcat  3257 Feb  2 12:06 logging.properties
      -r--r----- 1 root    tomcat  6814 Jul 18 12:18 server.xml
      -r--r----- 1 root    tomcat   210 Jul 18 12:10 tomcat-users.xml
      -r--r----- 1 root    tomcat 51835 Feb  2 12:06 web.xml
      
    5. Change the user/ownership of the ${tomcat_home}/bin and ${tomcat_home}/lib directories to be owned by the root user and have a group of tomcat:
    6. # chown -R root:tomcat lib
      # chown -R root:tomcat bin
      # ls -l
      total 92
      drwxr-xr-x 2 root    tomcat  4096 Jul 15 16:05 bin
      drwxr-xr-x 2 root    tomcat  4096 Jul 18 12:18 conf
      drwxr-xr-x 2 root    tomcat  4096 Jul 15 16:03 lib
      drwxr-xr-x 2 tomcat  tomcat  4096 Feb  2 12:04 logs
      drwxr-xr-x 2 tomcat  tomcat  4096 Jul 15 16:03 temp
      drwxr-xr-x 7 tomcat  tomcat  4096 Jul 15 16:04 webapps
      drwxr-xr-x 2 tomcat  tomcat  4096 Feb  2 12:04 work
      
    7. Change the user/group permissions of the ${tomcat_home}/conf directory and its subdirectories to give the root user and tomcat group read/write permissions. (Depending on the web applications you are running and/or your virtual host configurations, Tomcat will create a ${tomcat_home}/conf/Catalina) directory with corresponding subdirectories and files for context information. Allowing the tomcat group to write to ${tomcat_home}/conf allow this and prevent errors from appearing in your Tomcat logs.)
    8. # pwd
      # /opt/apache-tomcat-8.0.24
      # find conf -type d -exec chmod 775 {} \; -print
      # ls -l
      total 220
      total 92
      drwxr-xr-x 2 root    tomcat  4096 Jul 15 16:05 bin
      drwxrwxr-x 2 root    tomcat  4096 Jul 18 12:18 conf
      drwxr-xr-x 2 root    tomcat  4096 Jul 15 16:03 lib
      drwxr-xr-x 2 tomcat  tomcat  4096 Feb  2 12:04 logs
      drwxr-xr-x 2 tomcat  tomcat  4096 Jul 15 16:03 temp
      drwxr-xr-x 7 tomcat  tomcat  4096 Jul 15 16:04 webapps
      drwxr-xr-x 2 tomcat  tomcat  4096 Feb  2 12:04 work
      
    9. Change the user/group permissions of the files in ${tomcat_home}/conf directory to give the root user and tomcat group has read-only permissions:
    10. # cd conf
      # find . -type f -exec chmod 440 {} \; -print
      # ls -l
      total 220
      drwxr-xr-x 3 root tomcat   4096 2013-12-26 15:24 Catalina
      -r--r----- 1 root tomcat  12374 2015-07-01 14:23 catalina.policy
      -r--r----- 1 root tomcat   7086 2015-07-01 14:23 catalina.properties
      -r--r----- 1 root tomcat   1577 2015-07-01 14:23 context.xml
      -r--r----- 1 root tomcat   2899 2015-04-17 15:42 logging.properties
      -r--r----- 1 root tomcat   2330 2015-04-22 10:33 server.xml
      -r--r----- 1 root tomcat   1460 2015-04-24 14:33 tomcat-users.xml
      -r--r----- 1 root tomcat   1846 2015-07-01 14:23 tomcat-users.xsd
      -r--r----- 1 root tomcat 166582 2015-07-01 14:23 web.xml
      

Resources

Removing Unused Web Applications

Rationale

  • It is generally good practice to remove any un-used web applications out of ${tomcat_home}/webapps.
  • Tomcat "ships" with several default web applications 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 to the 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-gui 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 admin-gui 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.

Using Digested Passwords

Rationale

Tomcat Realms

A realm element represents a "database" of usernames, passwords, and roles (similar to Unix groups) assigned to those users.

Transport Layer Security
  • Passwords stored in clear text are a vulnerability if the host is compromised.
  • Better to have the passwords encrypted using a cryptographic hash functions (SHA, MD2, or MD5) and then stored in tomcat-users.xml file in the Tomcat conf/ directory.
  • Tomcat can be configured to support digested passwords (this is not the default setting).
  • How it works: When a client makes a request Tomcat will tell the client that a digested password is required. Based on this dialog, the client will automatically digest the password entered by the user.
Configure Tomcat to use digested passwords
  1. First we need to enable digest passwords support in Tomcat by modifying a couple of Tomcat Realms in the server.xml file in the Tomcat conf/ directory.
  2. A Tomcat Realm represents a "database" of usernames, passwords, and roles assigned to tomcat users.

    Realm Name Purpose
    UserDatabaseRealm The UserDatabaseRealm is enabled by default and reads clear text user password information stored in tomcat-users.xml.
    MemoryRealm The MemoryRealm reads the user password information stored in the tomcat-users.xml in a specified encrypted format.

    Open the server.xml with your favorite editor:

    $ vi server.xml
    

    Locate the UserDatabaseRealm (in the LockOutRealm, right above the Host element) and comment it out:

    <!-- Use the LockOutRealm to prevent attempts to guess user passwords
         via a brute-force attack -->
    <Realm className="org.apache.catalina.realm.LockOutRealm">
      <!-- This Realm uses the UserDatabase configured in the global JNDI
           resources under the key "UserDatabase".  Any edits
           that are performed against this UserDatabase are immediately
           available for use by the Realm.  -->
         <!--
           <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
           resourceName="UserDatabase"/>
           -->
    </Realm>
    
    <Host name="localhost"  appBase="webapps"
          unpackWARs="true" autoDeploy="true">
    

    Now add the following MemoryRealm information below the commented out UserDatabaseRealm:

    <!-- Use the LockOutRealm to prevent attempts to guess user passwords
         via a brute-force attack -->
    <Realm className="org.apache.catalina.realm.LockOutRealm">
      <!-- This Realm uses the UserDatabase configured in the global JNDI
           resources under the key "UserDatabase".  Any edits
           that are performed against this UserDatabase are immediately
           available for use by the Realm.  -->
         <!--
          <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
             resourceName="UserDatabase"/>
         -->
          <Realm className="org.apache.catalina.realm.MemoryRealm"
            digest="SHA" />
    </Realm>
    
    <Host name="localhost"  appBase="webapps"
          unpackWARs="true" autoDeploy="true">
    
  3. Create a SHA encrypted version of your password.
  4. Tomcat provides a script (${tomcat_home}/bin/digest.sh) that will encrypt a password string according to the algorithm specified. Use this script as follows with the password you made for yourself previously:

    $ /home/tds/apache-tomcat-8.0.24/bin/digest.sh -a SHA secret
    secret:e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4
    
  5. Update tomcat-users.xml.
  6. Replace your clear-text password in tomcat-users.xml with the encrypted version:

    <tomcat-users>
        <role rolename="manager-gui"/>
        <user username="admin" 
              password="e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4"
              roles="manager-gui"/>
    </tomcat-users>
    

    BASIC authentication

    Since we are using BASIC authentication, you will need to clear any authenticated sessions in your browser to test whether digested passwords have been enabled.

  7. Verify digest passwords have been successfully enabled in Tomcat.
  8. Restart Tomcat and verify digest passwords have been successfully enabled by logging into the Tomcat manager application using your password in clear text: http://localhost:8080/manager/html/

Troubleshooting

  • Check the XML syntax in tomcat-users.xml and server.xml to make sure it is well-formed and without error.
  • Did you restart Tomcat after you made your changes to tomcat-users.xml and server.xml ?
  • Any errors will be reported in the catalina.out file in the Tomcat logs/ directory.
  • You do not need to type the encrypted version of your password into the browser (the browser auto-magically encrypts your password for you before it transmits it to the server).

Enabling TSL/SSL Encryption

How TSL/SSL works

For more information on how SSL works, Wikipedia details the steps involved during an TSL/SSL transaction.

Rationale

  • Communication between two servers can be intercepted (i.e., an http transaction between client and server).
  • An attacker can eavesdrop on the conversation and control the relay of messages between the victims, making them believe that they are talking directly to each other over a private connection.
  • The use of digital certificates adds a layer of security by allowing the receiver of the message to verify the sender is who he or she claims to be.
  • Any intercepted information that is encrypted also adds a layer of security (the attacker must take the extra step of unencrypting the data to view the message).
  • Transport Layer Security (TLS), and formerly Secure Sockets Layer (SSL), is a cryptographic protocol that provides security and data integrity for communications over TCP/IP networks.
  • TSL/SSL allows applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery.
  • TSL/SSL uses a cryptographic system that uses two keys to encrypt data: a public key known to everyone and a private or secret key known only to the recipient of the message.
  • By convention, URLs that require an TSL/SSL connection start with https instead of http.

CA-signed Certificates

A self-signed certificate says to your users "Trust me - I am who I say I am."

A certificate signed by a CA says, "Trust me - the CA agrees I am who I say I am."

TSL/SSL certificates

  • A public key certificate is an electronic document which incorporates a digital signature to bind together a public key with identity information of the certificate user.
  • The certificate can be used to verify that a public key belongs to an individual.
  • The digital signature can be signed by a Certificate Authority (CA) or the certificate user (a self-signed certificate).
  • Unidata highly recommends the use of a certificate signed by a Certificate Authority (CA).
  • Browser warnings for self-signed certificates can be very confusing to users and make them question the legitimacy of your web site.
  • It's about trust: CA-signed certificates verify your identify to your users. If the traffic between your server and the client is intercepted, an attacker can inject their own self-signed cert in the place of yours and the visitor will likely not notice.
  • Self-signed certificates cannot (by nature) be revoked, which may allow an attacker who has already gained access to monitor and inject data into a connection to spoof an identity if a private key has been compromised. CAs on the other hand have the ability to revoke a compromised certificate, which prevents its further use.

Certificate keystore file

  • A keystore file stores the details of the TSL/SSL certificate necessary to make the protocol secured.
  • The Tomcat documentation includes a section on importing your certificate into a keystore file.
  • Tomcat uses the keystore file for TSL/SSL transactions. Example:
 <Connector protocol="HTTP/1.1" port="8443" maxThreads="200" 
    scheme="https" secure="true" SSLEnabled="true"
    keystoreFile="${user.home}/.keystore" 
    keystorePass="changeit"
    clientAuth="false" sslProtocol="TLS"/>
Enabling TSL/SSL in Tomcat
  1. Modify the Tomcat configuration to enable TSL/SSL:
  2. Based on what we know about Tomcat configuration, which file in ${tomcat_home}/conf should we edit to to enable TSL/SSL?

    Open ${tomcat_home}/conf/server.xml with your favorite editor:

    $ vi server.xml
    

    Locate the Java HTTP/1.1 Connector listening on port 8080 and verify it is redirecting TSL/SSL traffic to port 8443:

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

    Find and uncomment the SSL HTTP/1.1 Connector listening on port 8443 to activate this connector:

    <Connector port="8443" 
               protocol="HTTP/1.1" 
               SSLEnabled="true"
               maxThreads="150" 
               scheme="https" 
               secure="true"
               clientAuth="false" 
               sslProtocol="TLS" />
    

    Add a keystoreFile attribute to the SSL HTTP/1.1 Connector to tell Tomcat where to find your keystore:

    <Connector port="8443" 
               protocol="HTTP/1.1" 
               SSLEnabled="true"
               maxThreads="150" 
               scheme="https" 
               secure="true"
               clientAuth="false" 
               sslProtocol="TLS" 
               keystoreFile="/home/tds/apache-tomcat-8.0.24/conf/keystore" />
    

    Since we opted to not use the default keystore password, we need to specify the new password so Tomcat can open the file:

    <Connector port="8443" 
               protocol="HTTP/1.1" 
               SSLEnabled="true"
               maxThreads="150" 
               scheme="https" 
               secure="true"
               clientAuth="false" 
               sslProtocol="TLS" 
               keystoreFile="/home/tds/apache-tomcat-8.0.24/conf/keystore"
               keystorePass="foobar" />
    
  3. Verify TSL/SSL has been enabled.
  4. Restart Tomcat:

    $ ${tomcat_home}/bin/shutdown.sh
    $ ${tomcat_home}/bin/startup.sh
    

    Verify Tomcat is listening on port 8443 by running the netstat command:

    $ netstat -an | grep tcp | grep 8443
    

    man netstat

    Run man netstat in your terminal window to learn more about this command.

    netstat (short for network statistics) is available on Unix, Unix-like, and Windows NT-based operating systems. It is a command-line tool that displays:

    • network connections (both incoming and outgoing)
    • routing tables
    • and a number of network interface statistics

    Look for the following in the output:

    tcp        0      0 :::8443              :::*                  LISTEN
    

    Troubleshooting

    • Check the XML syntax in server.xml to make sure it is well-formed and without error.
    • When generating the self-signed certificate, the last password (the key password) and keystore password should be the same (changeit). If they differ, Tomcat cannot open the keystore and you will get this error: java.io.IOException: Cannot recover key.
    • Did you restart Tomcat after you made your changes to server.xml?
    • Did you specify the full path to the keystore file in server.xml?

Configuring web applications for TSL/SSL

Looking Ahead

Other than the compelling security reasons, you will want to enable TSL/SSL to take advantage of a couple of monitoring and debugging tools: the TDS Remote Management Tool, and the TdsMonitor Tool -- both of which (out-of-the-box) require TSL/SSL to access.

  • The web application deployment descriptor, aka web.xml, specifies if all or parts of it need to be accessed via TSL/SSL.
  • Deployment descriptors are found in the WEB-INF directory of the web application: ${tomcat_home}/webapps/application_name/WEB-INF/web.xml.
  • By convention, Tomcat and other servlet containers will read the web application deployment descriptors for initialization parameters and container-managed security constraints upon application deployment.
  • The TDS has been pre-configured to require that TSL/SSL encryption is enabled in order to access the both the TDS Remote Management Tool, and the TdsMonitor Tool.
  • web.xml from the TDS Remote Management Tool:

      <!-- This allows "remote configuration":
        /thredds/admin/debug gives access to various debug and status info.
        /thredds/admin/content/ -> "{tomcat_home}/content/thredds/"
        /thredds/admin/root/ -> "{tomcat_home}/webapps/thredds/" DISABLED
        /thredds/admin/dataDir/path -> "{dataRoot(path)}/webapps/thredds/"  DISABLED
       -->
      <security-constraint>
        <web-resource-collection>
          <web-resource-name>sensitive read access</web-resource-name>
          <url-pattern>/admin/*</url-pattern>
          <http-method>GET</http-method>
        </web-resource-collection>
        <auth-constraint>
          <role-name>tdsConfig</role-name>
        </auth-constraint>
        <user-data-constraint>
          <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
      </security-constraint>
    

    Configuration help

    For more information on how to configure security requirements for a web application in a deployment descriptor, see: Defining Security Requirements for Web Applications.

    • The <user-data-constraint> establishes a requirement that the constrained requests be received over a protected transport layer connection. This guarantees how the data will be transported between client and server.
    • <transport-guarantee> choices for type of transport guarantee include NONE, INTEGRAL, and CONFIDENTIAL:
      1. Specify CONFIDENTIAL when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission. (E.g., via TSL/SSL.)
      2. Specify INTEGRAL when the application requires that the data be sent between client and server in such a way that it cannot be changed in transit.
      3. Specify NONE to indicate that the container must accept the constrained requests on any connection, including an unprotected one.
    Accessing TDS Monitoring and Debugging Tools

    Other than the compelling security reasons, you will want to enable TSL/SSL to take advantage of a couple of monitoring and debugging tools: the TDS Remote Management Tool, and the TdsMonitor Tool -- both of which (out-of-the-box) require TSL/SSL to access.

    1. Enable TSL/SSL in Tomcat
    2. If Tomcat has not already been configured to run via TSL/SSL, follow the tutorial in the previous section to Enable TSL/SSL in Tomcat.

    3. Modify ${tomcat_home}/conf/tomcat-users.xml to add the new tdsConfig and tdsMonitor roles. Add these roles to your list of roles:
    4. <tomcat-users>
          <role rolename="manager-gui"/>
          <role rolename="tdsConfig"/>
            <role rolename="tdsMonitor"/>
          <user username="admin" 
                password="e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4" 
                roles="manager-gui,tdsConfig, tdsMonitor"/>
      </tomcat-users>
      
    5. Restart Tomcat

Resources

Securing the Tomcat manager Application

Changes to the manager application

The manager application URLs and roles has been re-structured. See the Tomcat Migration guide for more information.

Rationale

  • "Free" web application that comes with Tomcat distribution that lives in the Tomcat Lives in the ${tomcat_home}/webapps/manager directory.
  • Not enabled by default.
  • Allows Tomcat administrators to deploy, undeploy, or reload web applications such as the TDS without having to shut down and restart Tomcat.
  • If exploited, an attacker can use the manager application to install programs on your server willy-nilly.
  • If you choose to enable the manager application, we highly recommend enabling digested passwords and TSL/SSL encryption for the manager.
  • Restricting access to the manager application to a small subset of IP addressess or host names using a Tomcat valve, etc., is also a good idea.
  • Uninstall this application if you don't plan to use it.

Enabling TSL/SSL for the Tomcat manager application

  1. Modify the deployment descriptor of the Tomcat manager application.
  2. Using your favorite editor, open the deployment descriptor for the Tomcat manager application:

    $ vi ${tomcat_home}/webapps/manager/WEB-INF/web.xml
    

    Locate the <security-constraint> elements (near the bottom of the file):

    <!-- Define a Security Constraint on this Application -->
    <!-- NOTE:  None of these roles are present in the default users file -->
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>
          HTML Manager interface (for humans)
        </web-resource-name>
        <url-pattern>/html/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-gui</role-name>
      </auth-constraint>
    </security-constraint>
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>
          Text Manager interface (for scripts)
        </web-resource-name>
        <url-pattern>/text/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-script</role-name>
      </auth-constraint>
    </security-constraint>
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>JMX Proxy interface</web-resource-name>
        <url-pattern>/jmxproxy/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-jmx</role-name>
      </auth-constraint>
    </security-constraint>
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>Status interface</web-resource-name>
        <url-pattern>/status/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-gui</role-name>
         <role-name>manager-script</role-name>
         <role-name>manager-jmx</role-name>
         <role-name>manager-status</role-name>
      </auth-constraint>
    </security-constraint>
    
    

    The Tomcat 8 version of the manager application deployment descriptor contains a <security-constraint> section for each of the four possible ContactPaths (as per Manager Application section of the Tomcat Migration Guide).

    Add a <user-data-constraint> with a <transport-guarantee> of CONFIDENTIAL for the desired ContactPaths to to enable port-forwarding to port 8443:

    <!-- Define a Security Constraint on this Application -->
    <!-- NOTE:  None of these roles are present in the default users file -->
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>
         HTML Manager interface (for humans)
        </web-resource-name>
        <url-pattern>/html/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-gui</role-name>
      </auth-constraint>
      <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>
    
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>
         Text Manager interface (for scripts)
        </web-resource-name>
        <url-pattern>/text/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-script</role-name>
      </auth-constraint>
      <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>
    
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>JMX Proxy interface</web-resource-name>
        <url-pattern>/jmxproxy/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-jmx</role-name>
      </auth-constraint>  
      <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>
    
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>Status interface</web-resource-name>
        <url-pattern>/status/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>manager-gui</role-name>
         <role-name>manager-script</role-name>
         <role-name>manager-jmx</role-name>
         <role-name>manager-status</role-name>
      </auth-constraint>
      <user-data-constraint>
       <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
    </security-constraint>
  3. Verify TSL/SSL has been enabled for the Tomcat manager application.
  4. Restart Tomcat and verify TSL/SSL has been enabled for the Tomcat manager application: http://localhost:8080/manager/html/

    Tomcat manager authentication prompt

  5. NOTE: You will have to redo this every time you upgrade Tomcat.

Troubleshooting

  • Check the XML syntax in web.xml to make sure it is well-formed and without error.
  • Did you specify a <transport-guarantee> of CONFIDENTIAL?
  • Did you restart Tomcat after you made your changes to web.xml?

Resources

  • Manager App HOW-TO
    The Apache Tomcat document referencing how to use and configure the manager application.
  • Tomcat Migration Guide
    A document detailing the various changes between Tomcat versions contains a section dedicated to the manager application.

Blocking Non-Essential Port Access At The Firewall

Rationale

  • It is easy to 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 your 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 using any of the TDS monitoring and debugging tools, or the Tomcat manager application, you must also open up port 8443.

Resources

  • Your local systems/network administrator:
    systems/network administrator

Restricting Access To The TDS By Remote IP Address Or Host

Rationale

Tomcat Valves

A valve element represents a component that will be inserted into the request processing pipeline for the associated Catalina container.

  • Use the Tomcat RemoteHostValve or RemoteAddrValve to restrict access to the TDS and/or other web applications.
  • Configured in the Tomcat conf/server.xml file.
  • Valve declarations can be used to either allow or deny access to content.
  • Utilize the valves for adding an extra layer of security to the manager application to limit accessed to it from within a specific IP address range.
  • Caveat: these valves rely on incoming IP addresses or hostnames which are vulnerable to spoofing. Also, not much help when dealing with DHCP.

Examples

  1. Using the RemoteAddrValve to restrict access based on IP addresses.
  2. <!-- 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" />
    
  3. Using the RemoteHostValve to restrict access based on resolved host names.
  4. <!-- This example denies access based on host names -->
    <Valve className="org.apache.catalina.valves.RemoteHostValve"
               deny="www\.badguys\.com,www\.bandwidthhog\.net" />
    
  5. Using wildcard characters.
  6. <!-- Wildcard characters can with the both valves -->
    <Valve className="org.apache.catalina.valves.RemoteAddrValve"
           deny="128\.117\.47\..*" />
    
  7. Using the RemoteAddrValve to limit access to a specific range of IP addresses.
  8. <!-- This example only allows the specified IPs to access  -->
    <Valve className="org.apache.catalina.valves.RemoteAddrValve"
              allow="128\.117\.140\..*" />
    

Resources

  • The Valve Component
    Tomcat documentation about the various valve components available for use.

Reverse Proxy

Rationale

  • A reverse proxy is a proxy server that appears to clients to be an ordinary server. Requests are forwarded to one or more origin servers which handle the request. The response is returned as if it came directly from the proxy server.
  • Reverse Proxy For The TDS
  • Reverse proxies can be used to hide the existence and characteristics of the origin server(s) and can be an additional layer of defense and can protect against some OS and web server specific attacks. This additional security layer forces an attacker to attack the proxy because the firewall allows only the proxy to communicate with the back-end content servers.
  • However, it does not provide any protection to attacks against vulnerabilities in the web application or proxy service itself (e.g., Apache, Tomcat).
  • If an attacker can use the front-end proxy server to launch an attack on the back-end servers if he/she manages to exploit the web application, proxy transaction or some other service running on the proxy server.

Resources

Running Tomcat with a Security Manager

Rationale

  • 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.
  • If you 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 too restrictively.

Resources

  • Security Manager HOW-TO
    Information on the default settings of the Java Security Manager and instructions on how to make changes to these settings.

Protecting the Tomcat SHUTDOWN Port

SHUTDOWN on port 8005

  • Tomcat uses a the default port of 8005 as the designated shutdown port. Shutdown scripts make a call to this port and issue the SHUTDOWN command.
  • If need be, you can always change the shutdown command or even the port number in ${tomcat_home}/conf/server.xml.