Hardening

Introduction

For more secure installations, these instructions demonstrate how to harden a DDF system.

Disabling the Web Administration Console

To harden DDF for security purposes, disable the Web Administration Console so that users do not have access. All configuration is done via the DDF command line console and/or .cfg configuration files.

Open the web administration console.

1. http://localhost:8181/system/console
2. Default Username/Password: admin/admin
3. Select the Features tab
4. Uninstall the webconsole-base feature by clicking the Install/Uninstall button on the right

Accessing any page on the web admin console will now result in an HTTP 404 error.

To re-enable the web administration console, go to the Karaf command line console and install the ddf-webconsole feature.

features:install webconsole

Enabling SSL for Services

Do not use the Web Administration Console to SSL enable the DDF services. While the Web Administration Console's Pax Web Runtime offers this configuration option, it has proven to be unreliable and may crash the system.

 

Edit the provided configuration file <DDF_INSTALL_DIR>/etc/org.ops4j.pax.web.cfg with the settings for the desired configuration.

Pax Web Configuration Settings

Property	Sample Value	Description
org.osgi.service.http.enabled	false	Set this to false to disable HTTP without SSL
org.osgi.service.http.secure.enabled	true	Set this to true to SSL enable the DDF services
org.osgi.service.http.port.secure	8993	Set this to the HTTPS port number. (Verify this port does not conflict with any other secure ports being used in the network. For example, JBoss and other application servers use port 8443 by default)
org.ops4j.pax.web.ssl.keystore.type	jks	Set this to the type of keystore (most likely jks)
org.ops4j.pax.web.ssl.keystore	/opt/ddf/keystore.jks	Set this to the fully-qualified path to the SSL keystore file
org.ops4j.pax.web.ssl.keypassword	password1	Set this to the password for the user's private key
org.ops4j.pax.web.ssl.password	password2	Set this to the password for overall keystore integrity checking

Here is an example .cfg file:

######################
# HTTP settings
######################

# Disable HTTP
org.osgi.service.http.enabled=false

# HTTP port number
org.osgi.service.http.port=8181


######################
# HTTPS settings
######################

# Enable HTTPS
org.osgi.service.http.secure.enabled=true

# HTTPS port number
# (Verify this port does not conflict with any other secure ports being used in the
# network. For example, JBoss and other application servers use port 8443 by default)

org.osgi.service.http.port.secure=8993

# Fully-qualified path to the SSL keystore
org.ops4j.pax.web.ssl.keystore=/opt/ddf/keystore.jks

# SSL Keystore Type
org.ops4j.pax.web.ssl.keystore.type=jks

# Keystore Integrity Password
org.ops4j.pax.web.ssl.password=abc123

# Keystore Password
org.ops4j.pax.web.ssl.keypassword=abc123

 

 

All .cfg files follow a strict formatting structure in that every entry is a key=value pair. There should be no whitespace before the key, around the equals sign (=), or after the value. Otherwise, the key or value may be misinterpreted.

Also take care if .cfg files originated on an operating system other than the operating system DDF is currently running on. Hidden characters, e.g., ^M, can be added during the file transfer between the operating systems. This occurs often when a DDF zip install file from a Unix operating system is transferred to a Windows operating system and installed.

Optional: Disable HTTP for the DDF services and only use HTTPS by setting the org.osgi.service.http.enabled property to false. After this, all DDF clients need to pass the appropriate certificates.

Reference

Configuring a Java Keystore for Secure Communications

Additional Pax-Web SSL configuration info: http://team.ops4j.org/wiki/display/paxweb/SSL+Configuration

Configuring DDF Without the Web Administration Console

In an environment hardened for security purposes, access to the DDF Web Administration Console will be denied. It is necessary to configure DDF (e.g., providers, Schematron rulesets, etc.) either using .cfg configuration files or by using the Karaf command line console. The OSGi container detects the addition, updating, or deletion of .cfg files in the etc/ddf directory.

The following sections describe how to configure each DDF item using both of these mechanisms. A template file is provided for each configurable DDF item so that it can be copied/renamed and then modified with settings.

Templates included with DDF:

Configuring Using a .cfg File Template

Configuring a new source or feature using a config file follows a standard procedure:

1. Copy/rename the provided template file in the etc/templates directory to the etc directory (consult preceding table to determine correct template).
   
   • Mandatory: The dash between the PID (e.g., OpenSearchSource_site.cfg) and the instance name (e.g., OpenSearchSource_site.cfg) is required. The dash is a reserved character used by OSGi to detect that an instance of a managed service factory should be created.
   • Not required, but a good practice is to change the instance name (e.g. federated_source) of the file to something identifiable (source1-ddf)
2. Edit the file copied to etc with the settings for the configuration (consult preceding table to determine the configurable properties).
   
   • This file is a Java properties file, hence the syntax is <key> = <value>
   • Consult the inline comments in the file for guidance on what to modify
   • The Configurable Properties tables in the Integrator's Guide for the Included Catalog Components also describe each field and its value
3. The new service can now be used in the same way as if it was created using the web administration console.

Configuring Using the Command Line Console

Configuring a new source, provider, or feature using the command console follows a standard procedure. The properties and their values will change based on type of service being created, but the actual commands entered at the command line do not change.
To help illustrate the commands, an example of creating a new OpenSearch Federated Source is shown after each step.

1. Create the federated source using the config:edit command

   

   • Mandatory: The dash between the PID (e.g., OpenSearch_source) and the instance name (e.g., search_source) is required. The dash is a reserved character used by OSGi to detect that an instance of a managed service factory should be created.

     config:edit OpenSearchSource-my_federated_source
     

2. Enter the settings for the federated source's properties. These properties can be found by looking in the template file for the specified service.

   config:propset endpointUrl http://ddf:8181/services/query?q={searchTerms}&src={fs:routeTo?}&mr={fs:maxResults?}&count={count?}&mt={fs:maxTimeout?}&dn={idn:userDN?}&lat={geo:lat?}&lon={geo:lon?}&radius={geo:radius?}&bbox={geo:box?}&polygon={geo:polygon?}&dtstart={time:start?}&dtend={time:end?}&dateName={cat:dateName?}&filter={fsa:filter?}&sort={fsa:sort?}

3. Save the configuration updates

   config:update
   

4. The new service can now be used in the same way as if it was created using the web administration console.