10 Managing Security

This chapter describes how you can secure access to the Oracle Traffic Director administration server and enable SSL/TLS for Oracle Traffic Director virtual servers. It also describes how to configure client authentication and how you can use Oracle Traffic Director to secure access to origin servers.

This chapter contains the following sections:

Note:

For information about some steps that you can take to secure Oracle Traffic Director in your environment, see Appendix C, "Securing Oracle Traffic Director Deployment."

10.1 Configuring SSL/TLS Between Oracle Traffic Director and Clients

This section describes how you can use SSL/TLS to secure communication between clients and Oracle Traffic Director instances. The information in this section is aimed at readers who are familiar with the concepts of SSL/TLS, certificates, ciphers, and keys. For basic information about those concepts, see Section 10.1.7, "SSL/TLS Concepts."

This section contains the following subsections:

10.1.1 Overview of the SSL/TLS Configuration Process

To enable SSL/TLS for an Oracle Traffic Director instance, you must associate an RSA or ECC certificate, or both, with one more listeners of the instance. Additionally, you can associate an RSA or ECC certificate, or both, directly with virtual servers. The process of configuring SSL/TLS for Oracle Traffic Director instances involves the following steps:

  1. Obtain the required certificates, which could be self-signed, issued by a third-party Certificate Authority (CA) like VeriSign or a certificate that you generated.

    For more information, see the following sections:

  2. Install the certificates as described in Section 10.3.3, "Importing a Certificate."

  3. Associate the certificates with the required HTTP or TCP listeners as described in Section 10.1.2, "Configuring SSL/TLS for a Listener."

    You can also associate certificates directly with virtual servers as described in Section 10.1.3, "Associating Certificates with Virtual Servers." For information about the logic that Oracle Traffic Director uses to select the certificate to be sent to a client during the SSL/TLS handshake, see Section 10.1.5, "Certificate-Selection Logic."

  4. Configure ciphers supported for the HTTP or TCP listeners as described in Section 10.1.4, "Configuring SSL/TLS Ciphers for a Listener."

10.1.2 Configuring SSL/TLS for a Listener

You can configure a listener to receive HTTPS or TCP requests by using either Fusion Middleware Control or the WLST. Before you start, obtain the required certificates and install them as described in sections Section 10.3.1, "Generating a Keypair", Section 10.3.2, "Obtaining a CA-Signed Certificate", and Section 10.3.3, "Importing a Certificate".

Note:

  • When you modify listeners, you are, in effect, modifying a configuration. So for the updated configuration to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Section 3.3, "Activate Configuration Changes."

  • If you associate new certificates with a listener or remove previously associated certificates, for the changes to take effect, you must restart the instances. It is not sufficient to merely deploy the updated configuration.

  • For information about invoking WLST, see Section 1.7.1, "Accessing WebLogic Scripting Tool."

Configuring SSL/TLS for a Listener Using Fusion Middleware Control

To configure SSL/TLS for an HTTP or TCP listener by using Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to configure SSL/TLS-enabled listeners.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Administration > Virtual Servers.

    The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration

    You can view the properties of a virtual server by clicking on its name.

  7. Select the listener for which you want to enable and configure SSL/TLS.

    The Listener Settings page is displayed.

  8. Select Settings > Advanced Settings > SSL/TLS Settings.

    The SSL/TLS settings page i s displayed.

  9. In the SSL Settings section, select the SSL Enabled check box.

  10. In the RSA Certificate and ECC Certificate fields, select the certificates that you want to use to authenticate the server.

    If you associate a listener with an RSA certificate and with an ECC certificate, the certificate that the server eventually presents to the client is determined during the SSL/TLS handshake, based on the cipher suite that the client and the server negotiate to use.

    You can also specify the following advanced SSL/TLS settings in the Advanced Settings section of the Listener Settings page:

    • Enable and disable settings for client authentication. For more information, see Section 10.6, "Configuring Client Authentication."

    • Enable and disable strict SNI host matching. For more information, see the Section 10.1.6, "About Strict SNI Host Matching." section.

    • Enable and disable the following TLS-specific features:

      • Version Rollbacks

        Select this check box if you want Oracle Traffic Director to detect and block attempts at rolling back the TLS version. For example, if the client requested TLS 1.0, but an attacker changed it to a lower version (say, SSL 3.0), Oracle Traffic Director can detect and block the rollback even if it supports the lower version.

      • Session Ticket Extension

        If enabled, TLS sessions can be resumed without storing the session state of each client on the server. Oracle Traffic Director encapsulates the session state of each client in a ticket and forwards the ticket to the client. The client can subsequently resume the TLS session by using the previously obtained session ticket.

    • Enable and disable SSL and TLS ciphers. For more information, see Section 10.1.4, "Configuring SSL/TLS Ciphers for a Listener."

    On-screen help and prompts are provided for all of the parameters.

    When you change the value in a field or tab out of a text field that you changed, the Apply button near the upper right corner of the page is enabled.

    At any time, you can discard the changes by clicking the Revert button.

  11. After making the required changes, click Apply.

    A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.

  12. Restart the instances of the configuration by clicking Start/Restart Instances in the Common Tasks pane.

Configuring SSL/TLS for a Listener Using WLST

  • To view the SSL/TLS properties of an HTTP or TCP listener, run the otd_getHttpListenerSslProperties or otd_getTcpListernerSslProperties command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
otd_getHttpListenerSslProperties(props)

enabled=false
client-auth=false
client-auth-timeout=60
max-client-auth-data=1048576
ssl3=true
tls10=true
tls11=true
tls12=true
override-cipher-order=false
...

  • To configure SSL/TLS for an HTTP or TCP listener, run the otd_setHttpListenerSslProperties or otd_setTcpListenerSslProperties command, as shown in the following example:

    props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
props['tls10'] = 'false'
otd_setHttpListenerSslProperties(props)

10.1.3 Associating Certificates with Virtual Servers

You can associate one RSA and one ECC certificate with each virtual server, by using either Fusion Middleware Control or the WLST. For information about the logic that Oracle Traffic Director uses to select the certificate to be sent to a client during the SSL/TLS handshake, see Section 10.1.5, "Certificate-Selection Logic."

Before you start, obtain the required certificates and install them as described in sections Section 10.3.1, "Generating a Keypair", Section 10.3.2, "Obtaining a CA-Signed Certificate", and Section 10.3.3, "Importing a Certificate".

Note:

  • When you modify virtual servers, you are, in effect, modifying a configuration. So for the updated configuration to take effect in the Oracle Traffic Director instances, you should redeploy the configuration as described in Section 3.3, "Activate Configuration Changes."

  • If you associate new certificates with a virtual server or remove previously associated certificates, for the changes to take effect, you must restart the instances. It is not sufficient to merely deploy the updated configuration.

  • For information about invoking WLST, see Section 1.7.1, "Accessing WebLogic Scripting Tool."

Associating Certificates with Virtual Servers Using Fusion Middleware Control

To associate certificates with virtual servers by using Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to associate certificates with virtual servers.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Administration > Virtual Servers.

    The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration

    You can view the properties of a virtual server by clicking on its name.

  7. Select the listener for which you want to enable and configure SSL/TLS.

    The Listener Settings page is displayed.

  8. Select Settings > Advanced Settings > SSL/TLS Settings.

    The SSL/TLS settings page i s displayed.

  9. In the SSL Settings section, select the SSL Enabled check box.

  10. In the RSA Certificate and ECC Certificate fields, select the certificates that you want to use to authenticate the server.

    When you change the value in a field or tab out of a text field that you changed, the Apply button near the upper right corner of the page is enabled.

    At any time, you can discard the changes by clicking the Revert button.

  11. After making the required changes, click Apply.

    A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.

  12. Restart the instances of the configuration by clicking Start Instances/Restart Instances in the OTD Configuration pane.

Associating Certificates with Virtual Servers Using WLST

  • To view the certificates that are currently associated with a virtual server, run the otd_getVirtualServerProperties command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_getVirtualServerProperties(props)

  • To associate a certificate with a virtual server, run the otd_setVirtualServerSslProperties command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['server-cert-alias'] = 'cert-1'
props['http-listener'] = 'http-listener-1'
otd_setVirtualServerProperties(props)

For more information about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Note:

Make sure that a certificate of the same type—ECC or RSA—that you want to associate with the virtual server, is also associated with the listeners to which the virtual server is bound.

10.1.4 Configuring SSL/TLS Ciphers for a Listener

During the SSL/TLS handshake, the client and server inform each other about the SSL and TLS ciphers that they support and then negotiate the cipher—typically, the strongest—that they will use for the SSL/TLS session. For basic conceptual information about ciphers, see About Ciphers.

You can configure the ciphers that Oracle Traffic Director supports for a listener by using either Fusion Middleware Control or the WLST.

Configuring Ciphers for a Listener Using Fusion Middleware Control

To configure the ciphers supported for an HTTP or TCP listener by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to configure ciphers.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Administration > Listeners.

    The Listeners page is displayed. It shows a list of the HTTP/TCP listeners defined for the configuration

    You can view the properties of a HTTP/TCP listener by clicking on its name.

  7. Select the HTTP/TCP listener for which you want to enable and configure SSL/TLS.

    The Listener Settings page is displayed.

  8. Select Settings > Advanced Settings > SSL/TLS Settings.

    The SSL/TLS settings page i s displayed.

  9. In the SSL Settings section, you can manage the Certificates.

  10. When you change the value in a field or tab out of a text field that you changed, the Ok button near the upper right corner of the page is enabled.

    At any time, you can discard the changes by clicking the Cancel button.

  11. After making the required changes, click Ok.

    A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.

Configuring Ciphers for a Listener Using WLST

  • To view the ciphers that are currently enabled for an HTTP or TCP listener, run the otd_getHttpListenerSslProperties or otd_getTcpListernerSslProperties command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['http-listener'] = 'http-listener-1'
otd_getHttpListenerSslProperties(props)

    A comma-separated list of ciphers that are currently enabled is returned in the cipher property.

  • To enable or disable specific ciphers for a listener, run the otd_setHttpListenerSslProperties or otd_setTcpListenerSslProperties command and specify the ciphers to be enabled in the ciphers property.

  • The list of supported ciphers will be listed as apart of a property "supported-ciphers", when you run the otd_getHttpListenerSslProperties or otd_getTcpListenerSslProperties command.

For more information about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

Cipher Suites Supported by Oracle Traffic Director

During the SSL/TLS handshake, Oracle Traffic Director and clients negotiate the cipher suites to be used. Table 10-1 lists the cipher suites supported in Oracle Traffic Director. You can view this list by running the otd_getVirtualServerSslProperties WLST, as described earlier in this section. The name of each cipher suite indicates the key-exchange algorithm, the hashing algorithm, and the encryption algorithm, as depicted in.

  • Protocols supported

    • TLS: TLS 1.0, 1.1, 1.2

    • SSL: SSL 3

  • Key exchange algorithms supported

    • RSA

    • RSA_EXPORT

    • RSA_EXPORT1024

    • RSA_FIPS

    • ECDHE_RSA

    • ECDH_RSA

    • ECDH_ECDSA

    • ECDHE_ECDSA

  • Encryption algorithms supported

    • AES_256_CBC: 256-bit key

    • 3DES_EDE_CBC: 168-bit key

    • AES_128_CBC: 128-bit key

    • RC4_128: 128-bit key

    • DES_CBC: 56-bit key

    • RC4_56: 56-bit key

    • RC4_40 and RC2_CBC_40: 128-bit key but only 40 bits have cryptographic significance

    • NULL: No encryption

  • Message Authentication Code (MAC) algorithms supported

    • SHA: 160-bit hash

    • NULL: No hashing

Table 10-1 Cipher Suites Supported in Oracle Traffic Director

Cipher Suite FIPS 140 Compliant?

SSL_RSA_WITH_RC4_128_SHA

  

SSL_RSA_WITH_3DES_EDE_CBC_SHA

  

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Yes

TLS_ECDHE_RSA_WITH_RC4_128_SHA

  

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Yes

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Yes

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

Yes

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

  

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

Yes

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

Yes

TLS_RSA_WITH_AES_128_CBC_SHA

Yes

TLS_RSA_WITH_AES_256_CBC_SHA

Yes

TLS_RSA_WITH_AES_128_CBC_SHA256

  

TLS_RSA_WITH_AES_256_CBC_SHA256

  

TLS_RSA_WITH_AES_128_GCM_SHA256

  

TLS_RSA_WITH_AES_256_GCM_SHA384

  

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

  

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

  

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

  

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  

Source for FIPS 140-compliance information: http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html

10.1.5 Certificate-Selection Logic

When an HTTPS request is received, the certificate that Oracle Traffic Director sends to the client during the SSL/TLS handshake could be one of the following:

  • A certificate associated with a virtual server bound to a configured HTTP/TCP listener

  • A certificate associated with the default virtual server of the listener

  • A certificate associated with the listener

Oracle Traffic Director uses the following logic to determine the certificate that should be sent to the client during the SSL/TLS handshake.

Table 10-2 Certificate-Selection Logic

Condition Case A Case B Case C Case D

Client sent SNI host extension

Yes

Yes

Yes

No

A matchingFoot 1  virtual server is found.

Yes

No

No

--

The matching virtual server has a certificate of a type—RSA or ECC— that matches the ciphers sent by the client.

Yes

--

--

--

The default virtual server of the listener has a certificate of a type—RSA or ECC— that matches the ciphers sent by the client.

--

Yes

--

--

The listener has a certificate of a type—RSA or ECC— that matches the ciphers sent by the client.

--

--

Yes

Yes

Certificate selected:

Certificate of the matching virtual server

Certificate of the default virtual server

Certificate of the listener

Certificate of the listener

Footnote 1 A matching virtual server is a virtual server that is bound to the listener and has a host pattern that matches the Host: header sent by the client.

10.1.6 About Strict SNI Host Matching

When a client sends an HTTPS request to an SSL/TLS-enabled Oracle Traffic Director instance, the server needs to send a certificate to the client to initiate the SSL/TLS handshake. If the host name in the request does not match the server name (common name, CN) in the certificate provided by the server, a warning message is displayed by the client to the user. To continue with the SSL/TLS handshake process, the user must then explicitly choose to trust the certificate.

If an Oracle Traffic Director instance contains multiple, name-based virtual servers configured with a single IP address and port combination, to determine the appropriate certificate that should be sent to the client, the server needs to know the value of the Host header in the HTTP request, which it cannot read until after the SSL/TLS connection is established.

An extension to the SSL and TLS protocols, called Server Name Indication (SNI), addresses this issue, by allowing clients to provide the requested host name during the SSL/TLS handshake in the SNI host extension. Oracle Traffic Director uses the host name in the SNI host extension to determine the virtual server certificate that it should send to the client. For information about associating certificates with virtual servers, see Section 10.1.3, "Associating Certificates with Virtual Servers."

Support for SNI is enabled by default for SSL/TLS-enabled HTTP listeners in Oracle Traffic Director. For stricter control, like if you want to prevent non-SNI clients from accessing name-based virtual servers, you should enable the Strict SNI Host Matching parameter.

When Strict SNI Host Matching is enabled for an HTTP listener, and if for that listener at least one of the virtual servers has certificates, then Oracle Traffic Director returns a 403-Forbidden error to the client, if any of the following conditions is true:

  • The client did not send the SNI host extension during the SSL/TLS handshake.

  • The request does not have the Host: header.

  • The host name sent by the client in the SNI host extension during the SSL/TLS handshake does not match the Host: header in the request.

10.1.7 SSL/TLS Concepts

This section provides basic information about security-related concepts. It contains the following topics:

About SSL

Secure Socket Layer (SSL) is a protocol for securing Internet communications and transactions. It enables secure, confidential communication between a server and clients through the use of digital certificates. Oracle Traffic Director supports SSL v3 and Transport Layer Security (TLS) v1.

In a 2-way HTTP over SSL (HTTPS) connection, each party—say a browser or a web server—first verifies the identity of the other. This phase is called the SSL/TLS handshake. After the identities are verified, the connection is established and data is exchanged in an encrypted format. The following are the steps in the SSL/TLS handshake between an SSL-enabled browser and an SSL-enabled server:

  1. The browser attempts to connect to the server by sending a URL that begins with https:// instead of http://.

  2. The server sends its digital certificate (see "About Certificates") and public key to the client.

  3. The client checks whether the server's certificate is current (that is, it has not expired) and is issued by a certificate authority (CA) that the client trusts.

  4. If the certificate is valid, the client generates a one-time, unique session key and encrypts it with the server's public key, and then sends the encrypted session key to the server.

  5. The server decrypts the message from the client by using its private key and retrieves the session key.

At this point, the client has verified the identity of the server; and only the client and the server have a copy of the client-generated, unique session key. Till the session is terminated, the client and the server use the session key to encrypt all communication between them.

About Ciphers

A cipher is an algorithm, a mathematical function, used for encrypting and decrypting data. Some ciphers are stronger and more secure than others. Usually, the more bits a cipher uses, the harder it is to decrypt the data encrypted using that cipher.

SSL v3 and TLS v1 support a variety of ciphers. Clients and servers may support different cipher suites (sets of ciphers), depending on factors such as the protocol they support, the organizational policies on encryption strength, and government restrictions on export of encrypted software.

In any 2-way encryption process, the client and the server must use the same cipher suite. During the SSL/TLS handshake process, the server and client negotiate the cipher suite—typically, the strongest one—that they will use to communicate.

About Keys

Encryption using ciphers, by itself, does not ensure data security. A key must be used with the encrypting cipher to produce the actual encrypted result, or to decrypt previously encrypted information. The encryption process uses two keys—a public key and a private key. The keys are mathematically related; so information that is encrypted using a public key can be decrypted only using the associated private key, and vice versa. The public key is published by the owner as part of a certificate (see "About Certificates"); only the associated private key is safeguarded.

About Certificates

A certificate is a collection of data that uniquely identifies a person, company, or other entity on the Internet. It enables secure, confidential communication between two entities. Personal certificates are used by individuals; server certificates are used to establish secure sessions between the server and clients over SSL.

Certificates can be self-signed (by the server), signed by a trusted third party called Certification Authority (CA) or one that you created. The holder of a certificate can present the certificate as proof of identity to establish encrypted, confidential communication. The CA could be a third-party vendor or an internal department responsible for issuing certificates for an organization's servers.

Certificates are based on public-key cryptography, which uses a pair of keys (very long numbers) to encrypt information so that it can be read only by its intended recipient. The recipient then decrypts the information using one of the keys.

A certificate binds the owner's public key to the owner's identity. In addition to the public key, a certificate typically includes information such as the following:

  • The name of the holder and other identification, such as the URL of the server using the certificate

  • The name of the CA that issued the certificate

  • The digital signature of the issuing CA

  • The validity period of the certificate

10.2 Configuring SSL/TLS Between Oracle Traffic Director and Origin Servers

This section describes how to use SSL/TLS to secure connections between Oracle Traffic Director instances and origin servers that are Oracle WebLogic Server and Oracle HTTP Server instances. It contains the following topics:

10.2.1 About One-Way and Two-Way SSL/TLS

The connections between Oracle Traffic Director and origin servers in the back end can be secured using one-way or two-way SSL/TLS.

  • One-way SSL/TLS: The SSL/TLS-enabled origin server presents its certificate to the Oracle Traffic Director instance. The Oracle Traffic Director instance is not configured to present any certificate to the origin server during the SSL/TLS handshake.

  • Two-way SSL/TLS: The SSL/TLS-enabled origin server presents its certificate to the Oracle Traffic Director instance. The Oracle Traffic Director instance too presents its own certificate to the origin server. The origin server verifies the identity of the Oracle Traffic Director instance before establishing the SSL/TLS connection. Additionally, either end of the SSL/TLS connection—Oracle Traffic Director and/or origin servers—can be configured to verify the host name while exchanging certificates.

10.2.2 Configuring One-Way SSL/TLS Between Oracle Traffic Director and Origin Servers

To configure one-way SSL/TLS between Oracle Traffic Director and origin servers, you must export the origin servers' certificates in PKCS#12 format, install them in the certificate database of Oracle Traffic Director, and, optionally, configure Oracle Traffic Director to trust the certificates.

Note:

  • The procedure described in this section is for a scenario where all of the servers in the origin-server pool use certificates issued by the same CA. In such a scenario, you can configure one-way SSL/TLS by importing just the root certificate of the CA that signed the certificates for the origin servers into the certificates database of Oracle Traffic Director.

  • If the origin servers use self-signed certificates or certificates issued by different CAs, you should individually export and import each of the server certificates or the individual root certificates of the CAs that signed the server certificates.

  • If the WebLogic Server Plug-In Enabled attribute, which can be accessed using the Weblogic Server Fusion Middleware Control, is set to true and when Oracle Traffic Director terminates an SSL connection, Oracle Traffic Director communicates the certificate information to the applications deployed on the WebLogic Server. An application can then validate for specific information in the certificate, such as key size or cipher, before allowing the clients to access the application.

  1. Export the root certificate of the CA that issued certificates to the origin servers into the PKCS#12 format.

    • For Oracle WebLogic Server origin servers:

      Use the keytool command available in Java SE 6.

      Syntax:

      > $JAVA_HOME/bin/keytool -exportcert -alias alias -file file -keystore keystore -storepass storepass -rfc

      alias is the nickname of the certificate to be exported, file is the name for the exported certificate, keystore is the name of the custom Oracle WebLogic Server identity store file, and storepass is the password for the specified keystore.

      Example:

      > $JAVA_HOME/bin/keytool -exportcert -alias wlsos1 -file wls_os_cert
 -keystore $DOMAIN_HOME/soa_domain/soa_keystore.jks -storepass stpass -rfc

      For more information about keytool, see the documentation at:

      http://docs./javase/6/docs/technotes/tools/windows/keytool.html

    • For Oracle HTTP Server origin servers:

      Use the exportWalletObject WebLogic Scripting Tool (WLST) command.

      Syntax:

      exportWalletObject(instName, compName, compType, walletName, password, type, path, DN)

      Example:

      > exportWalletObject('inst1', 'ohs1', 'ohs','wallet1', 'password', 'Certificate', '/tmp','cn=soa.example.com')

      This command exports the certificate with the DN cn=soa.example.com from the wallet wallet1, for Oracle HTTP Server instance ohs1. The trusted certificate is exported to the directory /tmp.

      For more information about the exportWalletObject command, see the documentation at exportWalletobject in Oracle Fusion Middleware Infrastructure Security WLST Command Reference.

  2. Install the root certificate, which you just exported, in the certificates database of Oracle Traffic Director by using the importKeyStoreCertificate WLST.

    Note:

    For information about installing a certificate using Fusion Middleware Control, see Section 10.3.3, "Importing a Certificate"

    Syntax:

    -----BEGIN CERTIFICATE-----
(Server SSL certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root certificate)
-----END CERTIFICATE-----

    Example:

    svc = getOpssService("KeyStoreService")
 # generate a key pair with the proper DN
svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')

    Note:

    If the origin servers use self-signed certificates or certificates issued by different CAs, do the following instead of steps 1 and 2:

    1. Export each server certificate, or each root certificate of the CAs that signed the server certificates, individually, by using the same commands used in step 1.

    2. Install each certificate, which you exported in the previous step, in the certificates database of Oracle Traffic Director, by using the importKeyStoreCertificate WLST, as described in step 2 but with --cert-type=server.

  3. If required, configure Oracle Traffic Director to verify the host name in the origin server's certificate by using the otd_setRouteProperties WLST.

    Syntax:

    otd_setRouteProperties(props)

    Example:

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['websocket-idle-timeout'] = '1200'
otd_setRouteProperties(props)

    To view a list of the virtual servers in a configuration and the routes defined for a virtual server, use the otd_listVirtualServers and otd_listRoutes WLST commands, respectively.

    Note:

    If you choose to configure Oracle Traffic Director to validate the host name in the origin server's certificate during the SSL/TLS handshake, then you must do the following:

    Otherwise, when the origin server presents its certificate, Oracle Traffic Director cannot validate the host name in the certificate, and so the SSL/TLS handshake will fail.

10.2.3 Configuring Two-Way SSL/TLS Between Oracle Traffic Director and Origin Servers

To configure two-way SSL/TLS between Oracle Traffic Director and origin servers, do the following:

Note:

For more information, about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the commands with the --help option.

  1. Perform the procedure for configuring one-way SSL/TLS, as described in Section 10.2.2, "Configuring One-Way SSL/TLS Between Oracle Traffic Director and Origin Servers."

  2. Obtain a CA-issued server certificate for Oracle Traffic Director, as described in Section 10.3.2, "Obtaining a CA-Signed Certificate."

  3. Install the CA-issued server certificate in the Oracle Traffic Director configuration, as described in Section 10.3.3, "Importing a Certificate.".

  4. Configure the required Oracle Traffic Director route with the certificate that Oracle Traffic Director should present to the origin server, by using the otd_enableRouteAuth WLST.

    Syntax:

    otd_enableRouteAuth(props)

    Example:

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['auth-user'] = 'baz'
props['auth-password'] = 'qux'
otd_enableRouteAuth(props)

    To view a list of the virtual servers in a configuration and the routes defined for a virtual server, use the otd_listVirtualServers and otd_listRoutes WLST commands, respectively.

  5. Deploy the updated configuration to the Oracle Traffic Director instances by using the activate command.

    pullComponentChanges(<instance_name>)

  6. Export the root certificate of the CA that signed the certificate for the Oracle Traffic Director instance, from the keystore.

    Syntax:

    svc = getOpssService("KeyStoreService")
svc.exportKeyStoreCertificate(appStripe='<stripe>', name='<keystore>', password='<password>', alias='<alias>', type='<entrytype>', filepath='<absolute_file_path>')

    svc is the service command object obtained through a call to getOpssService(), appstripe is the name of the stripe containing the keystore, name is the name of the keystore, password is the keystore password, alias is the alias of the entry to be exported, type is the type of keystore entry to be exported. Valid values are 'Certificate', 'Trusted Certificate', or 'Certificate Chain', and filepath is the absolute path of the file where certificate, trusted certificate or certificate chain is exported.

    Example:

    svc = getOpssService("KeyStoreService")
svc.exportKeyStoreCertificate(appStripe='OTD', name='myconfig', password='', alias='rootca', keypassword='', type='TrustedCertificate', filepath='/scratch/rootcert.txt')

    For more information about the exportKeyStoreCertificate command, run the following command:

    svc = getOpssService("KeyStoreService")
svc.help('exportKeyStoreCertificate')

  7. Import the root certificate that you exported in the previous step into the trust keystore for the Oracle WebLogic Server origin servers (and the Oracle wallet for Oracle HTTP Server origin servers).

    • For Oracle WebLogic Server origin servers:

      Use the keytool command available in Java SE 8.

      Syntax:

      > $JAVA_HOME/bin/keytool -importcert -v -trustcacerts -alias alias
-file cert_file -keystore keystore_file -storepass keystore_password
-noprompt

      alias is the nickname of the CA-issued root CA exported in the previous step, file is the name of the exported certificate file, keystore is the name of the custom Oracle WebLogic Server identity store file, and storepass is the password for the specified keystore.

      Example:

      > $JAVA_HOME/bin/keytool -importcert -v -trustcacerts -alias rootca1
 -file /tmp/rootca1.pem -keystore $DOMAIN_HOME/soa_domain/soa_keystore.jks
 -storepass stpass -noprompt

      For more information about keytool, see the documentation at:

      http://docs./javase/8/docs/technotes/tools/windows/keytool.html

    • For Oracle HTTP Server origin servers:

      Use the importWalletObject WLST command.

      Syntax:

      importWalletObject(instName, compName, compType, walletName, password, type, filePath)

      Example:

      > importWalletObject('inst1', 'ohs1', 'ohs','wallet1', 'password', 'TrustedCertificate','/tmp/rootca1.pem')

      For more information about the importWalletObject command, see the section on importwalletobject in Oracle Fusion Middleware Infrastructure Security WLST Command Reference.

  8. Configure the origin servers to require Oracle Traffic Director to present its client certificate during the SSL/TLS handshake.

10.2.4 Converting a non-SSL Oracle Traffic Director Instance to an SSL Oracle Traffic Director Instance

To convert a non-SSL Oracle Traffic Director instance to an SSL Oracle Traffic Director instance, do the following:

  1. Create a wallet, as described in ”Creating a Wallet” in Administering Oracle Fusion Middleware.

  2. Import required root, intermediate, and server certificates to a wallet as described ”Importing a Certificate or Trusted Certificate” in Administering Oracle Fusion Middleware

  3. Create a new HTTPS listener for port 4443 as described section Section 9.1, "Creating a Listener".

  4. Restart the services as described in Section 4.3, "Starting, Stopping, and Restarting Oracle Traffic Director Instances".

10.3 Managing Certificates

This section contains the following topics:

Note:

10.3.1 Generating a Keypair

You can generate a keypair if you do not need your certificate to be signed by a CA, or if you want to test the SSL/TLS implementation while the CA is in the process of signing your demo CA certificate.

Note that if you use a keypair to enable SSL/TLS for an Oracle Traffic Director virtual server, when a client accesses the https:// URL of the virtual server, an error message is displayed indicating that the signing CA is unknown and not trusted. To proceed with the connection, the client can choose to trust the self-signed certificate.

You can generate a keypair by using either Fusion Middleware Control or the WLST.

Before You Begin

Before you begin generating a keypair, decide the following:

  • The nickname of the keypair (required only for generating a keypair).

  • The key type—RSA or ECC.

    Oracle Traffic Director supports generation of the traditional RSA-type keys and the more advanced Elliptic Curve Cryptography (ECC) keys. ECC offers equivalent security with smaller key sizes, which results in faster computations, lower power consumption, and memory and bandwidth savings.

  • The key size (for RSA) or curve (for ECC).

    For RSA keys, you can specify 512, 1024, 2048, 4096 bits. Long keys provide better encryption, but Oracle Traffic Director would need more time to generate them.

    For ECC keys, you should specify the curve for generating the key pair. Oracle Traffic Director supports the following curves: 163 (sect163r2), 192 (secp192r1), 224(secp224r1), 233(sect233k1), 256(secp256r1), 283(sect283k1), 384(secp384r1), 409(sect409k1), 521(secp521r1), 571(sect571k1).

Generating a Keypair Using Fusion Middleware Control

To create a self-signed certificate by using Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to create an self-signed certificate.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Security > Manage Certificates

    A new page displays on screen.

  7. Click the Generate Keypair button in the common task bar.

    The New Generate Keypair wizard opens.

    Figure 10-1 New Generate Keypair Wizard

    Description of Figure 10-1 follows
    Description of ''Figure 10-1 New Generate Keypair Wizard''

  8. Click OK. The new certificate is displayed in the certificate list.

  9. View the certificate details by clicking on the certificate alias

    The key pair is wrapped in a demonstration CA signed certificate and stored in the truststore. If your applications not using the truststore, then you must import the demonstration CA certificate to a custom keystore.

Generate keypair using WLST

To generate a keypair, run the generateKeyPair command, as shown in the following example:

svc = getOpssService("KeyStoreService")
svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='',dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information, about generateKeyPair, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

10.3.2 Obtaining a CA-Signed Certificate

To obtain a certificate signed by a Certificate Authority (CA), you should submit a Certificate Signing Request (CSR) to the CA, pay the prescribed fee if required, and wait for the CA to approve the request and grant the certificate.

The CSR is a digital file—a block of encrypted text in Base-64 encoded PEM format—containing information such as your server name, organization name, and country. It also contains the public key that will be included in the certificate.

You can generate a CSR by using either Fusion Middleware Control or the WLST of Oracle Traffic Director.

Generating a CSR Using Fusion Middleware Control

To generate a CSR by using Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to create a CSR.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Security > Manage Certificates

    A new page displays on screen.

  7. A list of the available certificates are displayed.
    Select the certificate for which you want to generate CSR.

  8. Click the Generate CSR button in the common pane.

    It opens a new window where you can export Generate CSR.

  9. Follow the on-screen prompts to Export CSR, Click on Export CSR to have a copy of it, and click Close

You can now send the CSR with the required certificate-signing fee to a CA of your choice.

Generating a CSR Using WLST

To generate a CSR, run the exportKeyStoreCertificateRequest command, as shown in the following example:

# generate the CSR and put it in to a text file
svc.exportKeyStoreCertificateRequest(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', filepath='/scratch/certreq.crt')

This command generates a CSR and displays the encrypted text of the CSR as shown in Generating a Keypair using Fusion Middleware Control.

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information, about exportKeyStoreCertificateRequest, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

After obtaining the CA-signed certificate in response to your CSR, you should import the certificate in the appropriate configuration, as described in Section 10.3.3, "Importing a Certificate."

10.3.3 Importing a Certificate

You can import a generated keypair or CA-signed certificate by using Fusion Middleware Control or the WLST.

This section contains the following topics:

  • Importing a Certificate Using Fusion Middleware Control

  • Importing a Certificate Using WLST

Importing a Certificate Using Fusion Middleware Control

To Import a Certificate or trusted certificate by using Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to import a certificate.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Security > Manage Certificates

    A new page displays on screen.

  7. Click the Import button.

    The import Certificate wizard opens, see Figure 10-2.

    Figure 10-2 Import Certificate

    Description of Figure 10-2 follows
    Description of ''Figure 10-2 Import Certificate''

  8. Choose Certificate, Trusted Certificate, or Certificate Chain from the Certificate Type drop-down.

    Note:

    • If you are importing a self-signed certificate, select Trusted Certificate from the Certificate Type drop-down.

    • If you are importing a CA-signed certificate, select Certificate Chain from the Certificate Type drop-down.

    • If you are importing a Certificate Chain, ensure that the Certificate chain obtained from the CA is created in the PKCS7 format.

  9. Choose the Alias from the drop-down if you are importing a Certificate or a Certificate Chain. Specify the name of the Alias if you are importing a Trusted Certificate.

  10. Specify the certificate source. If using the Paste option, then copy and paste the certificate directly into the text field. If using the Select a file option, then click Browse to choose the file from the operating system.

  11. Click OK. The imported certificate or trusted certificate is displayed in the list of certificates.

Importing a Certificate Using WLST

To Import a Certificate, run the importKeyStoreCertificate command, as shown in the following example:

svc.importKeyStoreCertificate(appStripe='OTD', name='myconfig', password='', alias='ca-cert', keypassword='', type='Certificate', filepath='/scratch/cacert.crt')

To Import a Certificate Chain, run the importKeyStoreCertificate command, as shown in the following example:

svc.importKeyStoreCertificate(appStripe='TEST_STRIPE',name='sample',password='welcome1', alias='test_cert', keypassword='welcome1',type='CertificateChain',filepath='/scratch/mwport/rpolavar/CERTS/testCertChain.crt')

This command installs the server certificate with the nickname soa-cert in the configuration soa. To install a CA certificate, specify ca for the --cert-type option.

Note:

If you are importing a Certificate Chain, ensure that the Certificate chain obtained from the CA is created in the PKCS7 format.

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about importKeyStoreCertificate, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

10.3.4 Viewing a List of Certificates

You can view a list of the certificates installed in a configuration by using either Fusion Middleware Control or the WLST.

Viewing a List of Certificates Using Fusion Middleware Control

To view a list of the certificates installed in a configuration by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to view certificates.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Security > Manage Certificates

    A new page displays on screen.

  7. Below the common task bar it displays a list of certificates.

Viewing a List of Certificates Using WLST

  • To view a list of the certificates installed in a configuration, run the otd_listCertificates command, as shown in the following examples.

    • The following command displays a list of the server certificates in the configuration.

      props = {}
props['configuration'] = 'foo'
otd_listCertificates(props)

  • To view the properties of a certificate, run the getKeyStoreCertificates command, as shown in the following example.

    svc = getOpssService("KeyStoreService")
svc.getKeyStoreCertificates(appStripe='OTD', name='myconfig', password='', alias='mycert')

Note:

If the pin is enabled for a token in the specified configuration, a prompt to enter the token pin is displayed when you run the otd_listCertificates and getKeyStoreCertificates commands.

For more information about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

10.3.5 Renewing a Server Certificate

To renew a certificate, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the Configurations button that is situated at the upper left corner of the page.

    A list of the available configurations is displayed.

  3. Select the configuration for which you want to renew certificates.

  4. In the navigation pane, expand SSL and select Server Certificates.

    The resulting page displays the installed server certificates.

    Note:

    If the pin is enabled for a token in the selected configuration, the installed certificates are not displayed. Instead, a message to enter the token pins is displayed on the page.

    1. Click Cache Token Pin.

    2. In the resulting dialog box, enter the pins for the tokens, and click OK.

  5. Click the Renew button for the certificate that you want to renew.

    The Renew Server Certificate dialog box is displayed.

  6. Specify the new validity period and click Next.

  7. Click Renew Certificate.

  8. Click Close.

    • A message is displayed in the Console Messages pane, confirming that the certificate has been renewed for the specified period.

    • The new expiry date for the certificate is displayed on the Server Certificates page.

10.3.6 Deleting a Certificate

You can delete certificates in a configuration by using either Fusion Middleware Control or the WLST.

Deleting a certificate using Fusion Middleware Control

To delete a certificate in a configuration by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to delete certificates.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Security > Manage Certificates

    A new page displays on screen.

  7. Below the common task bar it displays a list of certificates.

  8. Click the Delete button for the certificate that you want to delete.

    • If one or more listeners are associated with the certificate that you are deleting, a message is displayed indicating that the certificate cannot be deleted.

    • If the certificate that you are deleting is not associated with any listener, a prompt to confirm deletion of the certificate is displayed.

      Click OK to proceed.

    A message is displayed in the Console Messages pane, confirming that the certificate has been deleted.

Deleting a Certificate Using WLST

To delete a certificate, run the deleteKeyStoreEntry command.

Example:

svc = getOpssService("KeyStoreService")
svc.deleteKeyStoreEntry(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='')

If the certificate that you are deleting is associated with one or more listeners, the following message is displayed.

OTD-64309 Certificate 'rsa-1' is being referred by listeners: listener1,listenerN

You can delete the certificate forcibly by including the --force option.

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about deleteKeyStoreEntry, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

10.4 Managing Certificate Revocation Lists

A Certificate Revocation List (CRL) is a list that a CA publishes to inform users about certificates that the CA has decided to revoke before they expire. CRLs are updated periodically; the updated CRLs can be downloaded from the CA's website.

To ensure that Oracle Traffic Director servers do not trust server certificates that have been revoked by CA, you should download the latest CRLs from the CAs' websites regularly and install them in your Oracle Traffic Director configurations.

You can install CRLs manually. You can also configure Oracle Traffic Director to take the downloaded CRLs from a specified directory and install them automatically at specified intervals.

This section contains the following topics:

Note:

10.4.1 Installing and Deleting CRLs Manually

You can install and delete CRLs manually by using either Fusion Middleware Control or the WLST.

Installing CRLs Manually Using Fusion Middleware Control

To install a downloaded CRL by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to install a certificate.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Security > Certificate Revocation List

    A new page displays on screen.

  7. Click the Install CRL button.

    The Install Certificate Revocation List dialog box is displayed.

  8. Specify the location of the downloaded CRL file, and click Install CRL.

    • A message, confirming successful installation of the CRL, is displayed in the Console Messages pane.

    • The CRL that you just installed is displayed on the Certificate Authorities page.

Installing and Deleting CRLs Manually Using WLST

  • To install a downloaded CRL, run the otd_installCrl command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['file-path'] = '/export/ServerSign.crl'
otd_installCrl(props).

  • To view a list of the installed CRLs in a configuration, run the otd_listCrls command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
otd_listCrls(props)
---------------------------
"Class 1 Public Primary Certification Authority" "Sat Apr 15 16:59:59 PDT 2000"
"VeriSign Class 3 Code Signing 2010 CA" "Mon Aug 29 14:00:03 PDT 2011"
"VeriSign Class 3 Organizational CA" "Sun May 18 13:48:16 PDT 2014"

  • To delete a CRL, run the otd_deleteCrl command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['issuer'] = 'CN=GlobalSign ServerSign CA,OU=ServerSign CA,O=GlobalSign nv-sa,C=BE'
otd_deleteCrl(props)

    When you delete a CRL, it is removed from the Oracle Traffic Director configuration and from the directory in which the downloaded CRL was stored.

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about the WLST commands mentioned in this section, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the commands with the --help option.

10.4.2 Update CRLs Automatically

You can configure Oracle Traffic Director to periodically take downloaded CRL files from a specified directory and install them automatically by using either Fusion Middleware Control or the WLST.

At the specified interval, Oracle Traffic Director looks for updated CRL files in the specified directory.

  • If Oracle Traffic Director detects new CRL files, it installs them in the configuration and logs a message in the server log.

  • If existing CRL files have been changed, Oracle Traffic Director installs the updated CRL files in the configuration and logs a message in the server log.

  • If Oracle Traffic Director detects that previously installed CRL files have been removed from the directory, it deletes the CRLs from the configuration and logs a message in the server log.

  • If no changes are detected in the CRL directory, Oracle Traffic Director does not perform any update.

Configuring Oracle Traffic Director to Install CRLs Automatically Using Fusion Middleware Control

To configure Oracle Traffic Director to install CRLs automatically by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Click the name of the configuration that you want to set up to install CRLs automatically.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Security > Certificate Revocation List

    A new page displays on screen.

  7. Click the Install CRL button.

    The Install Certificate Revocation List dialog box is displayed.

  8. Specify the location of the downloaded CRL file, and click Install CRL.

    • A message, confirming successful installation of the CRL, is displayed in the Console Messages pane.

    • The CRL that you just installed is displayed on the Certificate Authorities page.

  9. Go to the Advanced Settings section of the page.

  10. In the CRL Update Event field, enter the absolute path to the directory that contains the updated CRL files.

  11. Click New Event.

    The New CRL Update Event dialog box is displayed.

  12. Specify the interval or time of the day at which the CRLs should be updated, and then click OK.

    • A message, confirming creation of the event, is displayed in the Console Messages pane.

    • The new event is displayed in the CRL Update Events list.

      • New events are enabled by default. To change the status, select the Enable/Disable check box.

      • To delete an event, click the Delete button.

Configuring Oracle Traffic Director to Install CRLs Automatically Using WLST

To configure Oracle Traffic Director to install CRLs automatically, do the following:

  1. Schedule an event for Oracle Traffic Director to take the downloaded CRLs from the specified directory and install them automatically, by using the otd_createEvent command.

    For example, the following command specifies that the CRLs for the configuration foo should be updated after every 12:00.

    props = {}
props['configuration'] = 'foo'
props['event'] = 'event-1'
props['command'] = 'update CRL'
props['time'] = '12:00'
otd_createEvent(props)

For more information about the WLST commands mentioned in this section, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the commands with the --help option.

10.5 Managing Web Application Firewalls

A Web Application Firewall (WAF) is a filter or server plugin that applies a set of rules, called rule sets, to an HTTP request. Web Application Firewalls are useful for establishing an increased security layer in order to identify and prevent attacks. It acts as a firewall for applications hosted within the origin server. In addition, it enables administrators to inspect any part of an HTTP request, such as headers and body, and configure conditions to accept or reject the HTTP request based on the condition.

Several free and commercial versions of web application firewall modules are available for use. The web application firewall module for Oracle Traffic Director supports ModSecurity 2.8, which is an intrusion detection and prevention engine for web applications. The ModSecurity rule sets can be customized to shield applications from common attacks such as cross-site scripting (XSS) and SQL injection. Based on various criterion, such as HTTP headers, environment variables and CGI variables, ModSecurity filters and rejects incoming requests. For more information about ModSecurity, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Introduction.

Among the many providers who have published different versions of the rule sets for ModSecurity, Oracle Traffic Director has been tested with the Open Web Application Security Project (OWASP), which is an open-source application security project, and is one of the most commonly used rule set providers. For more information, see https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project.

This section contains the following topics:

10.5.1 Overview of Web Application Firewalls

With Oracle Traffic Director, Web Application Firewalls can be enabled (or disabled) for each virtual server in your configuration. This in turn applies a set of rules, and acts as a firewall for the web applications deployed on the origin servers. For more information about origin servers and virtual servers, see Chapter 6, "Managing Origin Servers" and Chapter 7, "Managing Virtual Servers" respectively.

Oracle Traffic Director supports rule sets at both virtual server level and configuration level. Note that rules defined at the virtual server level will override rules defined at the configuration level. When deployed, these rules and the configuration changes are pushed to the instances, reconfiguring the instances. For more information about the Web Application Firewall works, see Appendix B, "Web Application Firewall Examples and Use Cases."

10.5.2 Configuring Web Application Firewalls

To configure Web Application Firewalls, you can either download an open source web application firewall rule sets or create your own rule sets. For example, download the ModSecurity Core Rule Set (CRS) from the OWASP repository, and unzip the rule sets to any folder. Oracle Traffic Director supports rules in the following directories:

  • base_rules

  • optional_rules

  • slr_rules

Note:

Web Application Firewall supports the ModSecurity 2.8 directives that are used by the configurations within the base_rules, optional_rules and slr_rules directories of OWASP ModSecurity Core Rule Set. However, it does not support Apache core config directives such as <IfDefine...> and <Location...>, and the ones supported by other Apache modules such as RequestHeader, Header and so on.

Note:

Make sure that all the dependent files are installed before the Web Application Firewall rule file is installed. If not, the Web Application Firewall rule file fails to install.

After unzipping the above directories, the files in these directories can be edited and uploaded to the administration server. These rule set files are then pushed to the Oracle Traffic Director instances when deployed. For more information, see Section 10.5.2.1, "Enabling and Installing Web Application Firewall Rule Sets."

Note:

  • Though the server can be configured to pick up the rule set files from a directory outside the config directory, rule file management will not be supported. When Oracle Traffic Director is configured for high availability, it is recommended that the web application firewall rule sets are placed within the config directory.

  • Using unsupported directives, variables, operators, actions, phases, functions and storages can cause server startup errors. For example, installing the rule set file modsecurity_crs_42_tight_security.conf without removing the unsupported action ver can cause Oracle Traffic Director to display the following error message when you start the server:

    [ERROR:16] [OTD-20016] Syntax error on line 20 of /scratch/rgoutham/instance1/net-config1/config/ruleset/config1/modsecurity_crs_42_tight_security.conf:
[ERROR:16] [OTD-20016] Error parsing actions: Unknown action: ver
[ERROR:32] [OTD-20008] Failed to parse VS webapp-firewall-ruleset (ruleset/config1/*.conf)
[ERROR:32] [OTD-10422] Failed to set configuration
[ERROR:32] server initialization failed

    To avoid getting this error, modify the rule set file, and remove or comment out unsupported directives, variables, operators, actions, phases, functions and storages, and then start the server.

10.5.2.1 Enabling and Installing Web Application Firewall Rule Sets

You can enable and install web application firewall rule sets by using either Fusion Middleware Control or the WLST.

Note:

Enabling and Installing Web Application Firewall Rule Sets Using Fusion Middleware Control

To configure web application firewall for a virtual server by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to configure web application firewall.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Advanced Configuration > Web Application Firewall

  7. The Web Application Firewall page is displayed.

    1. Click Install Rule Set Files.

      In the Install Rule Set Files dialog box, either browse to the folder where you unzipped the rule set files and select the rule set file or enter the full path to the location of the rule set file. To install multiple rule set files, install them one at a time.

      After you install one or more rule set files, the following text is added to the Rule Set Pattern field:

      ruleset/<virtual-server-id>/*.conf

      Note:

      • When you install rule set files at the configuration level, the rule set pattern appears as follows:

        ruleset/*.conf

      • If required, you can add custom rule set patterns. However, rule sets outside the ruleset/<virtual-server-id> directory (if at the virtual server level) or the ruleset directory (if at the configuration level) cannot be viewed or deleted using the Oracle Traffic Director Fusion Middleware Control or WLST. These rule sets will need to be managed manually.

Enabling Web Application Firewall Using WLST

To enable web application firewall using WLST, run the otd_enableWebAppFirewall command.

For example, the following command enables web application firewall for the virtual server bar in the configuration foo.

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_enableWebappFirewall(props)

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about otd_enableWebAppFirewall, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

Installing Web Application Firewall Rule Sets Using WLST

To install web application firewall rule sets using WLST, run the otd_installVirtualServerWebappFirewallRulesetFile command.

For example, the following command installs the web application firewall rule set modsecurity_crs_20_protocol_violations.conf for the virtual server bar in the configuration foo.

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['file-path'] = '/export/rulesets/baz.conf'
otd_installVirtualServerWebappFirewallRulesetFile(props)

To install web application firewall rule sets at the configuration level, run the otd_installWebappFirewallRulesetFile command. For example, the following command installs the web application firewall rule set modsecurity_crs_50_outbound.conf for the configuration foo.

props = {}
props['configuration'] = 'foo'
props['file-path'] = '/export/rulesets/baz.conf'
otd_installVirtualServerWebappFirewallRulesetFile(props)

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about otd_installWebappFirewallRulesetFile and otd_installVirtualServerWebappFirewallRulesetFile, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

Note:

You can use the otd_setConfigurationProperties and otd_setVirtualServerProperties commands to set the value of otd_deleteWebappFirewallRulesetFile/otd_deleteVirtualServerWebappFirewallRulesetFile property at the configuration level and virtual server level respectively. For more information, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

10.5.3 Listing the Rule Set Files

You can view the list of rule set files by using either Fusion Middleware Control or the WLST.

Note:

For information about invoking WLST, see Section 1.7.1, "Accessing WebLogic Scripting Tool."

Viewing the List of Rule Set Files Using Fusion Middleware Control

To view the list of rule set files by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to view rule set files.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Advanced Configuration > Web Application Firewall

  7. On the Web Application Firewall page, the Rule Set Files table lists the installed rule set files. To view the contents of these files either click and select individual rule files, or click the Name check box to select all the rules files.

  8. Click View.

    The contents of each rule file is displayed in the Rule set file contents window.

Viewing the List of Rule Set Files Using WLST

While it is not possible to view the contents of individual rule set files using CLI, you can view the list of installed rule set files. To view the list of rule set files, run the otd_listVirtualServerWebappFirewallRulesetFiles command.

For example, the following command lists the installed web application firewall rule set files for the virtual server bar in the configuration foo:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listVirtualServerWebappFirewallRulesetFiles(props)

To view the list of web application firewall rule sets that are installed at the configuration level, run the otd_listWebappFirewallRulesetFiles command. For example, the following command lists the web application firewall rule sets that are installed at the configuration level for the configuration foo.

props = {}
props['configuration'] = 'foo'
otd_listVirtualServerWebappFirewallRulesetFiles(props)

You can view the properties of a web application firewall by running the otd_getWebappFirewallProperties command.

For more information about the otd_listWebappFirewallRulesetFiles, otd_listVirtualServerWebappFirewallRulesetFiles and otd_getWebappFirewallProperties commands, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

10.5.4 Removing Rule Set Files

You can remove rule set files by using either Fusion Middleware Control or the WLST.

Note:

For information about invoking WLST, see Section 1.7.1, "Accessing WebLogic Scripting Tool."

Removing Rule Set Files Using Fusion Middleware Control

To remove rule set files for a particular virtual server:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to delete rule set files.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Advanced Configuration > Web Application Firewall

  7. On the Web Application Firewall page, either click and select individual rule files or click the Name check box to select all the rule files.

  8. Click the Delete button. At the confirmation prompt, click OK.

    A message is displayed in the Console Message pane confirming that the rule set files were deleted.

Removing Rule Set Files Using WLST

To remove rule set files for a particular virtual server, run the otd_deleteVirtualServerWebappFirewallRulesetFile command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['ruleset-file'] = 'baz.conf'
otd_deleteVirtualServerWebappFirewallRulesetFile(props)

To remove rule set files for run the otd_deleteWebappFirewallRulesetFile command, as shown in the following example:

props = {}
props['configuration'] = 'foo'
props['ruleset-file'] = 'baz.conf'
otd_deleteVirtualServerWebappFirewallRulesetFile(props)

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about otd_deleteWebappFirewallRulesetFile, otd_deleteVirtualServerWebappFirewallRulesetFile see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the command with the --help option.

Note:

The otd_disableWebAppFirewall command can be used to disable a web application firewall. For more information, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

10.5.5 Supported Web Application Firewall Directives, Variables, Operators, Actions, Functions, Persistent Storages and Phases

Oracle Traffic Director supports various ModSecurity 2.8 directives, variables, operators, actions, functions, persistent Storages and phases.

Supported Web Application Firewall Directives

Oracle Traffic Director supports the following ModSecurity 2.8 directives. For more information and to see the full list of ModSecurity directives, including unsupported directives, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Configuration_Directives.

SecAction
SecArgumentSeparator
SecAuditEngine
SecAuditLog
SecAuditLog2
SecAuditLogDirMode
SecAuditLogFileMode
SecAuditLogParts
SecAuditLogRelevantStatus
SecAuditLogStorageDir
SecAuditLogType
SecComponentSignature
SecContentInjection
SecCookieFormat
SecDataDir (see note below)
SecDebugLog
SecDefaultAction
SecDebugLogLevel
SecGeoLookupDb
SecInterceptOnError
SecMarker
SecPcreMatchLimit (see note below)
SecPcreMatchLimitRecursion (see note below)
SecRequestBodyAccess
SecRequestBodyInMemoryLimit (see note below)
SecRequestBodyNoFilesLimit (see note below)
SecRequestBodyLimitAction
SecResponseBodyAccess
SecResponseBodyLimit
SecResponseBodyLimitAction (see note below)
SecResponseBodyMimeType
SecResponseBodyMimeTypesClear
SecRule
SecRuleEngine (see note below)
SecRuleRemoveById
SecRuleRemoveByMsg
SecRuleRemoveByTag
SecRuleUpdateActionById
SecRuleUpdateTargetById
SecTmpDir
SecUnicodeMapFile (see note below)
SecUnicodeCodePage (see note below)
SecUploadDir
SecUploadFileLimit
SecUploadFileMode
SecUploadKeepFiles
SecWebAppId (see note below)
SecCollectionTimeout

Note:

  • SecWebAppId can be specified within virtual server specific web application firewall configuration file to associate the application namespace to a particular virtual server.

  • The directive SecRequestBodyLimitAction enables you to set action against requests that hit SecRequestBodyNoFilesLimit. However, the directive SecRequestBodyLimit is not supported by Oracle Traffic Director and hence, you cannot set action against this directive.

  • Oracle Traffic Director does not support the directive SecRequestBodyLimit, which is used for configuring the maximum request body size that ModSecurity accepts for buffering. In place of this directive, the following options can be used:

    Option 1: Use the directives, SecRequestBodyNoFilesLimit and SecRequestBodyLimitAction. Example:

    SecRequestBodyNoFilesLimit 100
SecRequestBodyLimitAction Reject

    Option 2: For Reject behavior, Oracle Traffic Director can be configured to check a request's Content-Length header in obj.conf. In addition, max-unchunk-size value can be set in server.xml.

    Similarly, for ProcessPartial behavior, body-buffer-size element in server.xml can be set to the desired limit. In this case, only the first part of the body that fits the limit is processed and the rest is passed through.

  • If the directive SecRuleEngine is specified within the configuration file(s) specified by the webapp-firewall-ruleset element, then it will be ignored. However, this condition is not applicable if SecRuleEngine is set to DetectionOnly mode.

  • The directive SecRequestBodyInMemoryLimit is ignored if the header Content-Type is set to x-www-form-urlencoded.

  • The directives SecDataDir, SecPcreMatchLimit, SecPcreMatchLimitRecursion, SecUnicodeCodePage, and SecUnicodeMapFile can only be used at configuration level. The scope of these directives is considered to be Main. All the other directives can be used at both virtual server level and configuration level. The scope of these directives is considered to be Any. If a directive with Main scope is specified within the virtual server level configuration file, then an error will be logged and the server will fail to start.

Supported Web Application Firewall Variables

Oracle Traffic Director supports the following ModSecurity 2.8 variables. For more information and to see the full list of ModSecurity variables, including the unsupported variables, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Variables.

ARGS
ARGS_COMBINED_SIZE
ARGS_GET
ARGS_GET_NAMES
ARGS_NAMES
ARGS_POST
ARGS_POST_NAMES
AUTH_TYPE
DURATION
ENV
FILES
FILES_COMBINED_SIZE
FILES_NAMES
FILES_SIZES
GEO
HIGHEST_SEVERITY
MATCHED_VAR
MATCHED_VARS
MATCHED_VAR_NAME
MATCHED_VARS_NAMES
MODSEC_BUILD 
MULTIPART_BOUNDARY_QUOTED
MULTIPART_BOUNDARY_WHITESPACE
MULTIPART_DATA_AFTER
MULTIPART_DATA_BEFORE
MULTIPART_FILE_LIMIT_EXCEEDED
MULTIPART_HEADER_FOLDING
MULTIPART_INVALID_QUOTING
MULTIPART_INVALID_HEADER_FOLDING
MULTIPART_LF_LINE 
MULTIPART_MISSING_SEMICOLON
MULTIPART_CRLF_LF_LINES
MULTIPART_STRICT_ERROR
MULTIPART_UNMATCHED_BOUNDARY
PERF_COMBINED
PERF_GC
PERF_LOGGING
PERF_PHASE1
PERF_PHASE2
PERF_PHASE3
PERF_PHASE4
PERF_PHASE5
PERF_SREAD
PERF_SWRITE
QUERY_STRING
REMOTE_ADDR
REMOTE_PORT
REMOTE_USER
REQBODY_ERROR
REQBODY_ERROR_MSG
REQBODY_PROCESSOR
REQBODY_PROCESSOR_ERROR
REQUEST_BASENAME
REQUEST_BODY (see note below)
REQUEST_BODY_LENGTH
REQUEST_COOKIES
REQUEST_COOKIES_NAMES
REQUEST_FILENAME
REQUEST_HEADERS (see note below)
REQUEST_HEADERS_NAMES
REQUEST_LINE
REQUEST_METHOD
REQUEST_PROTOCOL
REQUEST_URI
REQUEST_URI_RAW
RESPONSE_BODY
RESPONSE_CONTENT_LENGTH
RESPONSE_CONTENT_TYPE
RESPONSE_HEADERS
RESPONSE_HEADERS_NAMES
RESPONSE_PROTOCOL
RESPONSE_STATUS
RULE
SERVER_ADDR
SERVER_NAME
SERVER_PORT
SESSIONID
TIME
TIME_DAY
TIME_EPOCH
TIME_HOUR
TIME_MIN
TIME_MON
TIME_SEC
TIME_WDAY
TIME_YEAR
TX
UNIQUE_ID
URL_ENCODED_ERROR
USERID
WEBAPPID
WEBSERVER_ERROR_LOG (see note below)
XML

Note:

  • The REQUEST_BODY variable, which holds raw request body, will contain the body content that is available after it passes through other filters.

  • In open source ModSecurity, apache error log for each request/response can be collected and stored in the WEBSERVER_ERROR_LOG variable, and printed in the auditlog action. However, Oracle Traffic Director does not support this feature.

  • As request headers with the same name are concatenated into a single one, the header count is always 1. Hence, &REQUEST_HEADERS:<any header name> will always return 1 in spite of how many same request headers were sent.

Supported Web Application Firewall Operators

Oracle Traffic Director supports the following ModSecurity 2.8 operators. For more information and to see the full list of ModSecurity operators, including unsupported operators https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Operators.

beginsWith
contains
containsWord
endsWith
eq
ge
geoLookup
gt
inspectFile
ipMatch
le
lt
pm
pmf
pmFromFile
rbl (see note below)
rx
streq
strmatch
validateByteRange
validateDTD
validateSchema
validateUrlEncoding
validateUtf8Encoding
verifyCC
verifyCPF
verifySSN
within

Note:

ModSecurity 2.8 does not support the directive SecHttpBlKey. Hence use of Project Honey Pot (dnsbl.httpbl.cong) as RBL, which requires SecHttpBlKey, is not supported.

Supported Web Application Firewall Actions

Oracle Traffic Director supports the following ModSecurity 2.8 actions. For more information and to see the full list of ModSecurity actions, including the unsupported actions, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Actions.

allow
append
auditlog (see note below)
block
capture
chain
ctl
deny (see note below)
deprecatevar
drop (see note below)
exec
expirevar
id
initcol
log
logdata
msg
multiMatch
noauditlog
nolog
pass
pause
phase
prepend
redirect
rev
sanitiseArg
sanitiseMatched
sanitiseMatchedBytes
sanitiseRequestHeader
sanitiseResponseHeader
severity
setuid
setsid
setenv
setvar
skip
skipAfter
status
t
tag
xmlns

Note:

  • In open source ModSecurity, apache error log for each request/response can be collected and stored in the WEBSERVER_ERROR_LOG variable, and printed in the auditlog action. However, Oracle Traffic Director does not support this feature.

  • Actions that change HTTP response status, such as deny, will not successfully change the response status when it is invoked in phase 4. In such a scenario, the following error message is logged in the server log:

    " ModSecurity: Access denied with code 403 (phase 4)."

  • When drop action is invoked in phase 4, Oracle Traffic Director will send out HTTP headers to the client and then drop the connection.

  • When deny action is invoked in phase 4, Oracle Traffic Director strips the response body, instead of sending 403 response status. This might cause the following warning to appear in the server log:

    Response content length mismatch (0 bytes with a content length of <original content length>)

Supported Web Application Firewall Transformation Functions

Oracle Traffic Director supports the following ModSecurity 2.8 transformation functions. For more information and to see the full list of ModSecurity transformation functions, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Transformation_functions.

base64Decode
sqlHexDecode
base64DecodeExt
base64Encode
cmdLine
compressWhitespace
cssDecode
escapeSeqDecode
hexDecode
hexEncode
htmlEntityDecode
jsDecode
length
lowercase
none
normalisePath
normalisePathWin
parityEven7bit
parityOdd7bit
parityZero7bit
removeNulls
removeWhitespace
replaceComments
removeCommentsChar
removeComments
replaceNulls
urlDecode
urlDecodeUni
urlEncode
sha1
trimLeft
trimRight
trim

Supported Web Application Firewall Persistent Storages

Oracle Traffic Director supports the following ModSecurity 2.8 persistent storages. For more information and to see the full list of ModSecurity persistent storages, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Persistant_Storage.

GLOBAL
IP
RESOURCE
SESSION
USER

Supported Web Application Firewall Phases

Oracle Traffic Director supports the following ModSecurity 2.8 phases. For more information and to see the full list of ModSecurity phases, see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Processing_Phases.

Phase:1 - Request headers stage
Phase:2 - Request body stage
Phase:3 - Response headers stage
Phase:4 - Response body stage
Phase:5 - Logging

Note:

  • Actions that change HTTP response status, such as deny, will not successfully change the response status when it is invoked in phase 4.

  • When drop action is invoked in phase 4, Oracle Traffic Director will send out HTTP headers to the client and then drop the connection.

  • When deny action is invoked in phase 4, Oracle Traffic Director strips the response body, instead of sending 403 response status. This might cause the following warning to appear in the server log:

    Response content length mismatch (0 bytes with a content length of <original content length>)

10.6 Configuring Client Authentication

Client authentication is the verification of a client by the Oracle Traffic Director virtual server or TCP proxy, based on the certificate that the client provides.

Client authentication is not enabled by default. You can configure the Oracle Traffic Director listeners to require clients to provide a certificate, by using either Fusion Middleware Control or the WLST.

Note:

For information about invoking WLST, see Section 1.7.1, "Accessing WebLogic Scripting Tool."

Configuring Client Authentication Using Fusion Middleware Control

To enable client authentication for a listener by using Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to enable client authentication for listeners.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Administration > virtual server.

    The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration.

  7. Select the name of the virtual server you want to configure.

  8. Select Settings > Advanced Settings > SSL/TLS Settings.

  9. Select the required SSL/TLS Client Authentication mode.

    • Required: The server requests the client for a certificate; if the client does not provide a certificate, the connection is closed.

    • Optional: The server requests the client for a certificate, but does not require it. The connection is established even if the client does not provide a certificate.

    • Disabled (default): Client authentication is disabled.

  10. Specify the Authentication Timeout and Maximum Authentication Data parameters.

    On-screen help and prompts are provided for all of the parameters.

    When you change the value in a field or tab out of a text field that you changed, the Apply button near the upper right corner of the page is enabled.

    At any time, you can discard the changes by clicking the Revert button.

  11. After making the required changes, click Apply.

    • A message, confirming that the updated listener was saved, is displayed in the Console Messages pane.

Configuring Client Authentication Using WLST

To enable client authentication for an HTTP or TCP listener, run the otd_setVirtualServerSslProperties command for virtual server.

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['client-auth'] = 'false'
otd_setVirtualServerSslProperties(props)

For more information about the WLST commands mentioned in this section, see the WebLogic Scripting Tool Command Reference for Oracle Traffic Director or run the commands with the --help option.

10.7 Preventing Denial-of-Service Attacks

A denial-of-device (DoS) attack is an attempt by a malicious user to prevent legitimate users from accessing a service, by sending continuous requests to the server.

To prevent DoS attacks, you can configure Oracle Traffic Director virtual servers to reject requests when the frequency of requests or the number of concurrent connections exceeds a specified limit. For more granular control over requests, you can define several request limits and configure each limit to be applied to requests that match specified URL patterns and query string patterns, request headers that match specified values, and so on.

This section contains the following subsections:

10.7.1 Request Limiting Parameters

You can specify multiple request limits for a virtual server. For each request limit, you can configure several parameters:

  • You can make each request limit applicable to requests fulfilling a specified condition that you specify using expressions such as the following:

    $path = "*.jsp"
$url = "/images/*"
$ip =~ "^130\.35\.46\..*"

    You can use any variable or a combinations of variables to specify the condition for a limit. For more information about building expressions for request limit conditions, see "Using Variables, Expressions, and String Interpolation" in the Configuration File Reference for Oracle Traffic Director .

  • In each request limit, you can specify the number of concurrent requests (max-connections) and the average number of requests per second (max-rps).

    For example, if you specify a limit (say, max-rps=20), Oracle Traffic Director continuously tracks the request rate by recalculating it at a compute interval that you specify (default: 30 seconds), based on the number of requests received during that interval. When the specified request limit is reached, Oracle Traffic Director rejects all subsequent requests.

  • You can also specify an optional attribute that Oracle Traffic Director should monitor when applying request limits. Oracle Traffic Director uses separate counters to track the request statistics for each monitored attribute.

    For example, to specify that Oracle Traffic Director should track the request rate separately for each client IP, you can specify the variable $ip as the monitor attribute. When the request rate exceeds the specified limit for any client, subsequent requests from that client are rejected, but requests from other clients continue to be served.

    You can also combine variables when specifying the attribute to be monitored. For example, to limit requests from clients that request the same URIs too frequently, you can specify $ip:$uri as the attribute to be monitored. When the request rate from any client for any single URI exceeds the limit, further requests to the same URI from that client are rejected, but requests from that client to other URIs, as well as requests from other clients to any URI continue to be served.

  • For requests that Oracle Traffic Director rejects, it returns the HTTP response code that you specify. The default status code is 503 (service unavailable).

  • After a specified limit—max-connections or max-rps—is reached, Oracle Traffic Director continues to reject all subsequent requests until a specified continue condition is satisfied. You can specify one of the following continue conditions:

    • Threshold (default): Service resumes when the request rate falls below the specified limit.

    • Silence: Service resumes when the incoming request falls to zero for an entire interval.

10.7.2 Configuring Request Limits for a Virtual Server

You can configure request limits for a virtual server by using either Fusion Middleware Control or the WLST.

Note:

Configuring Request Limits Using Fusion Middleware Control

To configure request limits by using the Fusion Middleware Control, do the following:

  1. Log in to Fusion Middleware Control, as described in Section 1.7.2, "Displaying Fusion Middleware Control."

  2. Click the WebLogic Domain button at the upper left corner of the page.

  3. Select Administration > OTD Configurations.

    A list of the available configurations is displayed.

  4. Select the configuration for which you want to configure request limits.

  5. Click the Traffic Director Configuration In the Common Tasks pane.

  6. Select Administration > virtual server.

    The Virtual Servers page is displayed. It shows a list of the virtual servers defined for the configuration.

  7. In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to configure request limits, and select Request Limits.

    The Request Limits page is displayed. It lists the request limits that are currently defined for the virtual server.

    Creating a Request Limit

    1. Click New Request Limit.

      The New Request Limit dialog box is displayed.

      In the Name field, enter a name for the new request limit.

      In the Connections field, specify the maximum number of concurrent connections to the virtual server.

      In the Requests Per Second field, specify the maximum number of requests that the virtual server can accept per second.

      Note:

      You must specify at least one of the limits—maximum number of connections or maximum number of requests per second.

      In the Monitor Attribute field, specify the attribute in the request header, which the virtual server should monitor for applying the request limit. If you do not specify this parameter, the request limit is applied to all requests.

      In the Applies To field, select the default one, the request limit is applied to all requests.

    2. Click OK and then new Create Request Limit.is created.

      The request limit that you just created is displayed on the Request Limits page.

    Editing a Request Limit

    To change the settings of a request limit, do the following:

    1. Click the Name of the request limit.

      The Editing Request Limit page is displayed.

      Note:

      To access the condition builder to edit conditions, select Requests satisfying the condition and click Edit. The condition builder enables you to delete old expressions and add new ones.

    2. Specify the parameters that you want to change.

      While editing a request limit, in addition to changing the parameters that you specified while creating the request limit, you can set and change the requests-per-second compute interval, and the HTTP status code that the virtual server should return for requests that it rejects when the specified limits are reached. In addition, you can edit the condition that you have set by clicking Edit, which allows you to edit the condition either manually or using the condition builder. You can also delete old expressions and add new ones.

      On-screen help and prompts are provided for all of the parameters.

      When you change the value in a field or tab out of a text field that you changed, the Save button near the upper right corner of the page is enabled.

      At any time, you can discard the changes by clicking the Reset button.

    3. After making the required changes, click Save.

      A message, confirming that the updated configuration was saved, is displayed in the Console Messages pane.

    Deleting a Request Limit

    To delete a request limit, click the Delete button. At the confirmation prompt, click OK.

Configuring Request Limits Using WLST

  • To create a request limit, run the otd_createRequestLimit command.

    Examples:

    • The following command creates a request limit named request-limit-1 in the virtual server bar of the configuration foo.

      props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['max-connections'] = '2048'
otd_createRequestLimit(props)

    Note that the value of the --condition option should be a regular expression. For information about building condition expressions, see "Using Variables, Expressions, and String Interpolation" in the Configuration File Reference for Oracle Traffic Director .

  • To view a list of the request limits defined for a virtual server, run the otd_listRequestLimits command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listRequestLimits(props)

  • To view the properties of a request limit, run the otd_getRequestLimitProperties command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['event-notification-interval'] = '60'
otd_getRequestLimitProperties(props)

  • To change the properties of a request limit, run the otd_setRequestLimitProperties command.

    For example, the following command changes the request-per-second compute interval of the request limit request-limit-1 in the virtual server bar of the configuration foo.

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
props['max-connections'] = '1024'
otd_setRequestLimitProperties(props)

  • To delete a request limit, run the otd_deleteRequestLimit command, as shown in the following example:

    props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['request-limit'] = 'request-limit-1'
otd_deleteRequestLimit(props)

For the updated configuration to take effect, you should deploy it to the Oracle Traffic Director instances by using the activate command.

For more information about the WLST commands mentioned in this section, see WebLogic Scripting Tool Command Reference for Oracle Traffic Director.

10.8 Configure SSL Pass through on OTD

Oracle Traffic Director (OTD) is a software based application delivery controller for Oracle engineered systems and includes the ability to terminate SSL, load-balance, limit, and throttle the incoming requests while front ending Oracle Fusion Middleware and Business Application deployments like SOA, ATG (E-Commerce), PeopleSoft, E-Business Suite etc.

Oracle Traffic Director (OTD) offers the following key capabilities:

  • "Full fledged Layer-7 software load balancer with advanced load balancing algorithms and traffic management capabilities based on either HTTP headers or HTTP entity data.

  • A Layer-5 (Single connection-TCP) load balancer to front-end TCP traffic like WebLogic RMI t3, LDAP protocols etc.

  • ModSecurity based Web Application Firewall (WAF) capability to protect back-end application from common security vulnerabilities like SQL injection, command injection vulnerabilities etc.

  • High Availability (Active-Passive / Active-Active) fail-over capability within load balancer tier.

In addition, OTD offers the ability to offload SSL cipher processing, while handling HTTP(s)/SSL requests, to the underlying Intel processor for better throughput. However, in production systems, customers terminate SSL at an external hardware load balancer. This document will go through the list of configuration steps necessary to handle this use case.

10.8.1 Configure OTD to pass through SSL information from an external (hardware) Load Balancer

In a typical production deployment topology (as shown below), customers terminate SSL within the (external) hardware load balancer and have only HTTP communication within the internal load balancer (reverse proxy) and application tiers.

Description of screen1.jpg follows
Description of the illustration ''screen1.jpg''

In this scenario, customers need to perform a few additional steps within the internal load balancer / reverse proxy solution as well as the application tiers so that any request redirect can happen correctly. This section will focus on the steps necessary within the internal load balancer (OTD) / reverse proxy solution.

  1. Configure Hardware Load Balancer to send additional header to OTD

    • "If you terminate SSL within OTD, you will need to configure your hardware load balancer to send header - 'WL-Proxy-SSL:true'- to OTD. Refer to section -Configure F5-BigIP to send specific header to OTD- for more information.

    • "If you are terminating SSL within your hardware load balancer and also using OTD/OHS to front-end Oracle Access Manager (OAM/IDM), then you will need to configure your hardware load balancer to additionally insert header -'IS_SSL:ssl'- to the incoming request headers. This step is similar to inserting WL-Proxy-SSL header as documented within Configure F5-BigIP to send specific header to OTD- section.

  2. Enable WLS Plug-In Enabled configuration settings within WebLogic Server:

    • If the origin server is neither a WebLogic Server nor using the underlying WebLogic Server container, then you can skip this step!

    • For more information, refer to section -Configure WebLogic to receive SSL information from Web Tier / Traffic Director-section.

  3. Configure OTD 11g (using Admin Console UI) to pass through SSL:

    • Login to OTD Admin Console with the appropriate credentials.

    • Expand the Virtual Server and select the corresponding / relevant 'Route' screen.

    • Update Route (Virtual Server -> Routes -> Default -> Advanced) and disable OTD from rewriting any 'Location or 'Content-Location' headers. This is important when SSL termination is happening at an external load balancer.

    • Change the 'Rewrite-headers' to be empty.

    • Under 'Advanced Settings' for the Route, uncheck all SSL related headers sent to the Origin Server (as shown below) and save and deploy this configuration.

    • Save the changes and click on the 'Deploy Changes' button.

At the end of the above step, Oracle Traffic Director now does NOT rewrite any headers (typically this happens when the application tier redirects the request to another location) and can pass through the external hardware load balancer provided SSL information, via the incoming request headers, within the incoming requests.

10.8.2 Configure WebLogic to receive SSL information from Web Tier / Traffic Director

When you front-end WebLogic application server with Oracle's Web Tier solutions such as WebLogic Proxy Plug-In, Oracle HTTP Server, or with Oracle Traffic Director, then you will need to explicitly turn on 'WebLogic Plug-In Enabled' settings within WebLogic console. This flag can be tuned on either within a specific WebLogic Managed Server or at WebLogic cluster level. We recommend turning on this flag at WebLogic cluster level.

This ensures that WebLogic is able to appropriately rewrite the headers when SSL termination happens within Traffic Director / Web Tier.

Open http://<wls-admin-hostname>:7001/console and login with weblogic user/password.

(If you have Weblogic cluster enabled, then we recommend doing this at cluster level).

(If you do not have enabled Weblogic cluster, then you can enable this setting within WLS Managed Server). Within 'Configuration->General' settings tab, expand 'Advanced Settings' and scroll down to check "Weblogic Plugin Enabled" to 'Yes' and click "Save".

10.8.3 Configure F5-BigIP to send specific header to OTD

Oracle Traffic Director can offload cipher processing to take advantage of the underlying hardware processors to achieve overall better SSL performance compared to generic reverse proxy solutions.

If you choose to terminate SSL within the hardware load balancer such as F5-BigIp, then you will need to configure this hardware load balancer to explicitly send a specific header - WL-Proxy-SSL - to OTD and WLS.

This below step covers how to configure F5-BigIp to send this header (Source: F5 Big IP product documentation).

To create a new HTTP profile for SSL:

  1. On the Main tab, expand Local Traffic, and then click Profiles. The HTTP Profiles screen opens.

  2. In the upper right portion of the screen, click the Create button. The New HTTP Profile screen opens.

  3. In the Name box, type a name for this profile. In our example, we type bea-ssl.

  4. From the Parent Profile list, select http-acceleration if you are using the WebAccelerator. If you are not using the WebAccelerator, select http-wan-optimized-compression-caching.

  5. In the Request Header Insert row, check the Custom box. In the box, type: WL-Proxy-SSL:true.

  6. In the Redirect Rewrite row, check the Custom box. From the Redirect Rewrite list, select Match.

  7. Modify any of the other settings as applicable for your network. In our example, we leave the settings at their default levels.

  8. Click the Finish button.