Skip Headers
Oracle® Coherence Security Guide
Release 3.7.1

Part Number E22841-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

2 Enabling General Security Measures

This chapter provides instructions for general security steps that can be taken to help secure a Coherence environment. The steps can be considered first-line security measures that should always be set if possible.

The following sections are included in this chapter:

2.1 Specifying Coherence Privileges in the Java Security Policy File

The minimum set of privileges required for Coherence to function are specified in the security.policy file which is included as part of the Coherence installation. This file can be found in COHERENCE_HOME/lib/security/security.policy.

The policy file format is fully described in Java SE Security Guide. See

http://download.oracle.com/javase/6/docs/technotes/guides/security/permissions.html

To specify Coherence privileges:

  1. Enter the minimum set of privileges in the policy file.

    For example:

    grant codeBase "file:${coherence.home}/lib/coherence.jar"
        {
                permission java.security.AllPermission;
        };
    
  2. Sign the binaries using the JDK jarsigner tool, for example:

    jarsigner -keystore ./keystore.jks -storepass password coherence.jar admin
    

    and then additionally protected in the policy file:

    grant SignedBy "admin" codeBase "file:${coherence.home}/lib/coherence.jar"
        {
                permission java.security.AllPermission;
        };
    
  3. Use operating system mechanisms to protect all relevant files such as policy format, coherence binaries, and permissions from malicious modifications.

  4. To use the security policy file, turn on the Java Security Manager by defining the java.security.manager system property and setting the java.security.policy system property to the location of this security policy file. You must also set the tangosol.home system property to COHERENCE_HOME. For example:

    -Djava.security.manager
    -Djava.security.policy=c:/tangosol/lib/security/security.policy
    -Dtangosol.home=c:/tangosol
    

    Note:

    The security policy file assumes the default JRE security permissions have been granted. Therefore, you must be careful to use a single equals sign (=) and not two equals signs (==) when setting the java.security.policy system property.

2.2 Using Host-Based Authorization

Host-based authorization is a type of access control that allows only specified hosts to connect to a cluster. The feature can be used for both cluster member connections and extend client connections. This type of access control is ideal for environments were known hosts are joining or accessing the cluster.

The following topics are in this section:

2.2.1 Specifying Cluster Member Authorized Hosts

A cluster's default behavior is to allow any host to connect to the cluster and become a cluster member. This behavior can be changed to only allow hosts to connect to the cluster based on their host name or IP address. A customized filter can also be created to determine whether to accept a particular cluster member.

Authorized hosts for a cluster are configured in an operational override file using the <authorized-hosts> element within the <cluster-config> element. Specific addresses are entered using the <host-address> element or a range of addresses can be defined using the <host-range> element.

The following example configures a cluster to only accept cluster members whose IP address is either 192.168.0.5, 192.168.0.6, or within the range of 192.168.0.10 to 192.168.0.20:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/
   coherence-operational-config coherence-operational-config.xsd">
   <cluster-config>
      <authorized-hosts>
         <host-address>192.168.0.5</host-address>
         <host-address>192.168.0.6</host-address>
         <host-range>
            <from-address>192.168.0.10</from-address>
            <to-address>192.168.0.20</to-address>
         </host-range>
      </authorized-hosts>
   </cluster-config>
</coherence>

2.2.2 Specifying Extend Client Authorized Hosts

The extend proxy's default behavior is to accept all extend client connections. This behavior can be changed to only allow client connections based on their host name or IP address. A customized filter can also be created to determine whether to accept a particular client.

Authorized hosts for a cluster are configured in a cache configuration file using the <authorized-hosts> element within the <tcp-acceptor> element of a proxy scheme definition. Specific addresses are entered using the <host-address> element. A range of addresses can be defined using the <host-range> element.

The following example configures an extend proxy to only accept client connections from client's whose IP address is either 192.168.0.5, 192.168.0.6, or within the range of 192.168.0.10 to 192.168.0.20:

<proxy-scheme>
   <service-name>ExtendTcpProxyService</service-name>
   <thread-count>5</thread-count>
   <acceptor-config>
      <tcp-acceptor>
         ...
         <authorized-hosts>
            <host-address>192.168.0.5</host-address>
            <host-address>192.168.0.6</host-address>
            <host-range>
               <from-address>192.168.0.10</from-address>
               <to-address>192.168.0.20</to-address>
            </host-range>
         </authorized-hosts>
         ...
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>

2.2.3 Using a Filter Class to Determine Authorization

A filter class can determine whether to accept a particular host connection. A filter class can be used for both extend client connections and cluster member connections. A filter class must implement the com.tangosol.util.Filter interface. The evaluate() method of the interface is passed the java.net.InetAddress of the host. Implementations should return true to accept the connection.

To enable a filter class, enter a fully qualified class name using the <class-name> element within the <host-filter> element. Initialization parameters for the implementation class can also be set using the <init-params> element. See Oracle Coherence Java API Reference for details on the Filter interface.

The following example configures a filter named MyFilter, which is used to determine if a host connection is allowed.

<authorized-hosts>
   <host-address>192.168.0.5</host-address>
   <host-address>192.168.0.6</host-address>
   <host-range>
      <from-address>192.168.0.10</from-address>
      <to-address>192.168.0.20</to-address>
   </host-range>
   <host-filter>
      <class-name>package.MyFilter</class-name>
         <init-params>
            <init-param>
               <param-name>sPolicy</param-name>
               <param-value>strict</param-value>
            </init-param>
         </init-params>
   </host-filter>
</authorized-hosts>

2.3 Managing Rogue Clients

Extend clients that operate outside of acceptable limits are considered rogue clients. Rogue clients can be slow responding clients or abusive clients that attempt to overuse a proxy— as is the case with denial of service attacks. In both cases, the proxy could run out of memory and become unresponsive.

The suspect protocol is used to safeguard against such abuses. The suspect algorithm monitors client connections looking for abnormally slow or abusive clients. When a rouge client connection is detected, the algorithm closes the connection to protect the proxy server from running out of memory. The protocol works by monitoring both the size (in bytes) and length (in messages) of the outgoing connection buffer backlog for a client. Different levels are set to determine when a client is suspect, when it has returned to normal, or when it is considered rogue.

The suspect protocol is configured within the <tcp-acceptor> element of a proxy scheme definition. See "tcp-acceptor" in the Oracle Coherence Developer's Guide for details on using the <tcp-acceptor> element. The suspect protocol is enabled by default.

The following example demonstrates configuring the suspect protocol and is similar to the default settings. When the outgoing connection buffer backlog for a client reaches 10 MB or 10000 messages, the client is considered suspect and is monitored. If the connection buffer backlog for a client returns to 2 MB or 2000 messages, then the client is considered safe and the client is no longer monitored. If the connection buffer backlog for a client reaches the 95 MB or 60000 messages, then the client is considered unsafe and the connection with the client is closed:

<proxy-scheme>
   <service-name>ExtendTcpProxyService</service-name>
   <thread-count>5</thread-count>
   <acceptor-config>
      <tcp-acceptor>
         ...
         <suspect-protocol-enabled>true</suspect-protocol-enabled>
         <suspect-buffer-size>10M</suspect-buffer-size>
         <suspect-buffer-length>10000</suspect-buffer-length>
         <nominal-buffer-size>2M</nominal-buffer-size>
         <nominal-buffer-length>2000</nominal-buffer-length>
         <limit-buffer-size>95M</limit-buffer-size>
         <limit-buffer-length>60000</limit-buffer-length>
      </tcp-acceptor>
   </acceptor-config>
   <autostart>true</autostart>
</proxy-scheme>