Applying Recommended Security Settings

Configuring SSL with WebLogic

For instructions on configuring SSL with WebLogic Server, see the WebLogic documentation:

Overview of Configuring SSL in WebLogic Server

Parent topic: Applying Recommended Security Settings

Configuring SSL with Tomcat

To enable encrypted connections with Tomcat, the HTTPS connector must be configured using the following procedure:

Locate the server.xml file for the Tomcat installation (generally this would be conf/server.xml within the Tomcat directory). By default it contains a section such as the following:

<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443
This connector uses the NIO implementation that requires the JSSE
style configuration. When using the APR/native implementation, the
OpenSSL style configuration is required as described in the APR/native
documentation -->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->

Enable the Connector element by removing the XML comment characters around it.
Set the port value for HTTPS if needed. The default is 8443, so if a different value is used also change the redirectPort value in the HTTP connector to match.

Remember that if using a port below 1024, the server may require special permissions depending on the OS.
Generate the server key and certificate, and have the certificate signed by a recognized certificate authority. Self-signed certificates can be used, however they will need to be installed on the client machines in order for them to be recognized.

Note:

The certificate is stored either in a Java keystore (JKS format) or as a PKCS#12 file. The latter may be preferred in certain instances, as there are many tools available for working with PKCS#12 files.

Update the connector element as follows, replacing pathtokeystorefile, keystorepassword and keystoretype with the referenced information:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" 
keystoreFile="pathtokeystorefile" 
keystorePass="keystorepassword"
keystoreType="keystoretype"
/>

Set the keystoreType value to JKS or PKCS12 as required. If the key store contains multiple certificates, use the keyAlias attribute to set the alias.

Some Tomcat distributions include the Apache Portable Runtime (APR) native library. If this is the case, the certificate must be configured using Apache HTTPD mod_ssl style attributes. For example:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false"
SSLCertificateFile="pathtocrtfile"
SSLCertificateKeyFile="pathtokeyfile" />

For additional Tomcat information, see Apache Tomcat Configuration Reference at

http://tomcat.apache.org/tomcat-8.0-doc/config/http.html

For additional mod_ssl information, see Apache Module mod_ssl at

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

Parent topic: Applying Recommended Security Settings

Processor Security

EDQ, now allows optional use of security controls which can be used to increase the security level of EDQ processors, for example to block insecure uses of the Script processor. For backward compatibility reasons processor security is off by default, but it can be enabled by adding the following line to [EDQ Local Home]/director.properties:

processor.securitymode = off/low/medium/high

The processor security option acts in conjunction with the use of a Java Security Manager. The use of a Java Security Manager is controlled by a Java option specified on the server (-Djava.security.manager). If required, you should specify the Java option manually in the setStartupEnv.sh script for installing EDQ on WebLogic Server.

The security level of each of the different processor.security settings is summarized below:

Off:

No security restrictions are applied.
Low

The following restrictions are applied:
- The use of the Script processor from the tool palette, for direct use in processes, is disabled if the system is not running with a Java Security Manager.
- If the system is running with a Java Security Manager, the Script processor is available but is only granted a very small set of default permissions, limited to data processing. Scripts will not be able to make network connections or issue commands outside of the application.
Note:

Java processors and scripts that are packaged in jars will run without any restrictions; if a jar contains a permissions element the processor will be granted only those permissions.
Medium:

The same restrictions as Low apply, except that Java processors and scripts that are packaged in jars will be granted a very limited set of permissions. Any additional permissions required by the processor must be listed in permissions elements.

To clarify the difference, in 'low' level, all permissions are granted and permissions elements restrict permissions; in 'medium' level, permissions are limited and permissions elements extend permissions. In both levels a processor with a permissions element will run with exactly the same set of permissions.
High:

The same restrictions as 'medium' apply, except that only processors that are signed by the Oracle EDQ certificate, or by certificates granted to approved partners, will be allowed to include permissions elements that grant additional permissions to processors.

If a permissions element is found in an unsigned jar the processors in the jar will be rejected and will not appear in the processor palette.

Parent topic: Applying Recommended Security Settings

Default Permissions

When running with processor security set to medium or high, the permissions granted to processors allow the reading of these system properties:

java.version
java.vendor
java.vendor.url
java.class.version
os.name
os.version
os.arch
file.separator
path.separator
line.separator
java.specification.version
java.specification.vendor
java.specification.name
java.vm.specification.version
java.vm.specification.vendor
java.vm.specification.name
java.vm.version
java.vm.vendor
java.vm.name

No other permissions will be granted.

Parent topic: Processor Security

Giving Scripts More Permissions

An installation may wish to run with secure scripts but still allow users to perform some additional operations in ad-hoc scripts. A typical example will be to make web service calls. To allow this additional functionality, the system supports a configuration file listing additional permissions for ad-hoc scripts.

Additional permissions files are located in the security/permissions folder in the local configuration directory. For script processors, the file is named scriptprocessor.xml and for script match gadgets the file is named scriptgadget.xml. The file XML format is:

<permissions>
  <permission type="permissionclass" [name="targetname" [action="action"]]/>
  …
</permissions>

The permission class is the full name of any Java permissions class. The name attribute is present if the permission has a target name - the class has a two- or three-argument constructor. The action is present if the permission has an action - the class has a three-argument constructor.

For example, to grant the permission to read the file /etc/hosts:

<permission type="java.io.FilePermssion" name="file:/etc/hosts" action="read"/>

System properties can be included in the name using ${…} substitution. Alongside the standard system properties, these additional properties are available:

rootdir: The location of the web application root.
webinfdir: The location of the web application WEB-INF directory.
config.path: The configuration directory path. A permissions entry using ${config.path} in its name will be replaced by an entry for each location in the path.

Parent topic: Processor Security

Encrypting LDAP Connections

Connections from EDQ to an LDAP directory can be encrypted using either an SSL/TLS connection layer or by negotiating encryption after a connection has been established (StartTLS).

Parent topic: Applying Recommended Security Settings

Encrypting Database Connections

JDBC URL syntax for connections over TLS is dependent on the database driver being used. Connections to an Oracle database can be encrypted by adding the following property to the datasource connection pool configuration.:

oracle.net.encryption_client = REQUIRED

Parent topic: Applying Recommended Security Settings

Limit Concurrent Logins

A limit can be specified in login.properties for the number of concurrent logins by an individual user. The limit is concurrent logins per application. So if the sessionlimit is 1 a user can login to director, server console, case management at the same time but cannot login twice to any.

This can be configured either globally or on a per realm basis. To set this globally for all realms, use the following line:

sessionlimit = 1

To use different settings for different realms, specify the realm name before the parameter - for example:

internal.sessionlimit = 1

Note:

Using the line given above, you can also limit the concurrent logins in an `internal' realm, meaning the users set up and administered in EDQ itself.

<external realm name>.sessionlimit = 1

Parent topic: Applying Recommended Security Settings

Disable FTP/SFTP Access

Where it is not needed, FTP/SFTP access to EDQ should be disabled for optimum security. Standard FTP can be disabled by adding the following line in director.properties within the local configuration folder:

launch.ftpserver = 0

SFTP/SCP can be disabled using the following line within the same file:

launch.sshd = 0

Parent topic: Applying Recommended Security Settings

Exclude Configuration Area from FTP/SFTP

If non-admin users are allowed access to FTP/SFTP, it is advisable to remove access to the configuration folder from the SFTP server, as follows:

Create the folders extras/ftpserver/conf and extras/sshd/conf within oedq.local.home, if they do not already exist.
Copy the files extras/ftpserver/conf/ftpserver.xml and extras/sshd/conf/sshd.xml from the oedq.home configuration directory to the corresponding subfolders of oedq.local.home.
In each of the two files from the previous stage, comment out the following lines:
```

<ref bean="configspaces"/>

<ref bean="commandspaces"/>
```
The first reference is to the configuration directories; the second is to the command areas used for external tasks.
Restart the application server. The only location visible to the FTP and SFTP servers is now the landing area.

Parent topic: Applying Recommended Security Settings

Account with Minimal Permissions for Service Integration

An EDQ account used by a remote system such as Siebel or Oracle Data Integrator should have the minimum set of permissions on an EDQ system. Specifically, the account should be in a custom group with the following permissions only, and no access to log into any user applications or perform any other functions:

System / Connect to Messaging System - so that it is authorized to communicate with EDQ web services and JMS.
System/ System Administration - so that it is authorized to connect to the EDQ Management (JMX) Port and can initiate jobs.
Permissions to any projects containing any service interfaces (e.g. web services or jobs) that it needs to be able to call.

Parent topic: Applying Recommended Security Settings

Protect JNDI Data Sources

Unless specific steps are taken, a user in EDQ can set up a data store with a reference to the JNDI name of any existing data source and then access data in these schemas, which can contain very sensitive information. To protect JNDI data sources in EDQ, specify the names (or regular expressions matching the names) in director.properties:

protected.jndi.datasources = <space separated list of JNDI names>

For example:

protected.jndi.datasources = jdbc/edqconfig jdbc/edqresults

The property is a space-separated list of regexes so you could also use:

protected.jndi.datasources = jdbc/edq.*

Note:

When setting this value in the local director.properties, always include the default setting from the base properties file. This setting prevents access to the WebLogic internal data sources as well as the EDQ data sources.

Parent topic: Applying Recommended Security Settings

Blocking the Upload of Malicious Files

To configure the server to block the upload of files according to the names or type of files, set the following parameters in director.properties.

Parameter Name	Type	Default Value
`upload.check.names`	Boolean	True. If the value is set to false, no checks are done for the parameter name.
`upload.valid.names`	Text	A comma or separated list of valid file names.
`upload.valid.types`	Text	A comma or separated list of Java-recognised MIME file types, such as text/csv, image/bmp, text/plain etc For a list of MIME file types, see MIME types. Note: To disable the check (to allow files of any type), set an empty value to the parameter, `upload.valid.types` =
`upload.invalid.names`	Text	A comma or separated list of invalid file names.

Note:

The following properties are applicable for upload.valid.names and upload.invalid.names parameters.

Each name in this list is either a suffix (such as .pdf) or a regex prefixed with ~. If a regex is used it is matched against the full name of the file.
A file name is rejected if:
- upload.valid.names is specified and the file name does not match any of the items in the list.
- upload.invalid.names is specified and the name matches any of the items in the list.
All checks are not case sensitive.

Parent topic: Applying Recommended Security Settings