Production Server Overview

Enabling TSL/SSL Encryption

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.

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"/>

Configuring web applications for TSL/SSL

• 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

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.

2. Modify ${tomcat_home}/conf/tomcat-users.xml to add the new tdsConfig and tdsMonitor roles. Add these roles to your list of roles:

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

3. Restart Tomcat

Resources

• Qualys SSL Server Test
  is a free online service that analyzes the configuration of any public TSL/SSL web server. Note: be sure to check the Do not show the results on the boards box if you do not want your results to be public.
• TSL/SSL Configuration HOW-TO
  The Apache Tomcat document detailing how to enable TSL/SSL.
• Tomcat Migration Guide
  A document detailing the various changes between Tomcat versions.
• When are self-signed certificates acceptable?
  A compelling argument as to why self-signed certificates should not be used in a production environment.

Securing the Tomcat manager Application

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.

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:
  

Restricting Access To The TDS By Remote IP Address Or Host

Rationale

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

<!-- 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" />

2. Using the RemoteHostValve to restrict access based on resolved host names.

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

3. Using wildcard characters.

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

4. Using the RemoteAddrValve to limit access to a specific range of IP addresses.

<!-- 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 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 The TDS Behind a Proxy Server
  How to set up a reverse proxy for the TDS using Tomcat and the Apache HTTP server.

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.