Production Server Overview

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
    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.

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 and group for running Tomcat
  • We also recommend restricting the permissions of the Tomcat user/group within ${tomcat_home}. Restrict the permissions in ${tomcat_home}

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.

  • 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

Enabling SSL Encryption

How SSL works

For more information on how SSL works, Wikipedia details the steps involved during an 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).
  • Secure Sockets Layer (SSL), and more recently Transport Layer Security (TLS), is a cryptographic protocol that provides security and data integrity for communications over TCP/IP networks.
  • SSL allows applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery.
  • 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 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."

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 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 SSL transactions.
Enabling SSL in Tomcat

Configuring web applications for SSL

Looking Ahead

Other than the compelling security reasons, you will want to enable 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 SSL to access.

  • The web application deployment descriptor, aka web.xml, specifies if all or parts of it need to be accessed via 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 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 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

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 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 SSL for the Tomcat manager application

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.