5 Working with Oracle HTTP Server

This chapter describes some of the common tasks you might be required to perform when working with an installed version of Oracle HTTP Server. It contains the following sections:

5.1 Note on Editing Configuration Files

For instances that are part of a WebLogic Server Domain, Fusion Middleware Control and the management infrastructure manages the Oracle HTTP Server configuration. Direct editing of the configuration in the staging directory is subject to being overwritten after subsequent management operations, including modifying the configuration in Fusion Middleware Control. For such instances, direct editing should only be performed when the administration server is stopped. When the administration server is subsequently started (and with started), the results of any manual edits will be replicated to the run-time directory on the node of the managed instance.

For standalone instances, the configuration can be edited directly within the staging directory at any time. The configuration will be activated during start, restart, or stop operations. As with a WebLogic domain, whenever you modify a file that resides in the staging directory, you must first stop the administration server.

5.2 Specifying Server Properties

You can set Oracle HTTP Server only by using Fusion Middleware Control or direct editing of the Oracle HTTP Server configuration files. You cannot use WLST commands to specify the server properties.

5.2.1 Specifying Server Properties by Using Fusion Middleware Control

To specify the server properties by using Fusion Middleware Control:

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select Server Configuration from the Administration menu. The Server Configuration page appears.

    Description of srv_prop3.gif follows
    Description of the illustration ''srv_prop3.gif''

  3. Enter the documentation root directory in the Document Root field that forms the main document tree visible from the website.

  4. Enter the e-mail address in the Administrator's E-mail field that the server will includes in error messages sent to the client.

  5. Enter the directory index in the Directory Index field. The is the main (index) page that will be displayed when a client first accesses the website.

  6. Optional: Enter the user name in the Operating System User field.

    This field is normally blank. It may be set to the user that installed Oracle HTTP Server and starts .

  7. Optional: Enter the group name in the Operating System Group field.

    This field is normally blank. It may be set to the group of the user that installed Oracle HTTP Server and starts .

  8. The Modules region is used to enable or disable modules. There are three modules that you can enable or disable: mod_perl, mod_fcgi, and mod_plsql.

    For instructions on configuring the mod_perl module, see "Configuring mod_perl".

  9. Create an alias, if necessary in the Aliases table. An alias maps to a specified directory. For example, to use a specific set of content pages for a group you can create an alias to the directory that has the content pages.

  10. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  11. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

The server properties are saved, and shown on the Server Configuration page.

5.2.2 Editing the httpd.conf File to Specify Server Properties

To specify the server properties using the httpd.conf file:

Note:

Before attempting to edit any .conf file, you should familiarize yourself with the layout of the configuration file directories, mechanisms for editing the files, and learn more about the files themselves. For this information, see Section 1.6, "Understanding Configuration Files".

  1. Open the httpd.conf file by using either a text editor or the Advanced Server Configuration page in Fusion Middleware Control. (See Section 1.6.3, "Modifying a Configuration File.")

  2. In the DocumentRoot section of the file, enter the directory that stores the main content for the website. The following is an example of the syntax:

    DocumentRoot "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/htdocs"

  3. In the ServerAdmin section of the file, enter the administrator's email address. This is the e-mail address that will appear on client pages. The following is an example of the syntax:

    ServerAdmin WebMaster@example.com

  4. In the DirectoryIndex section of the file, enter the directory index. This is the main (index) page that will be displayed when a client first accesses the website. The following is an example of the syntax:

    DirectoryIndex index.html index.html.var

  5. Create aliases, if needed. An alias maps to a specified directory. For example, to use a specific set of icons, you can create an alias to the directory that has the icons for the Web pages. The following is an example of the syntax:

    Alias /icons/ "${PRODUCT_HOME}/icons/"

<Directory "${PRODUCT_HOME}/icons">
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

  6. Save the file.

  7. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

5.3 Configuring Oracle HTTP Server Instances

This section describes some of the more common Oracle HTTP Server instance configuration procedures. This section does not include initial system configuration information; for those configuration instructions, see Installing and Configuring Oracle HTTP Server.

includes the following sections:

Note:

Fusion Middleware Control and other Oracle software which manage the Oracle HTTP Server configuration might save configuration files in a different, equivalent format. After using the software to make a configuration change, multiple configuration files might be rewritten.

5.3.1 Configuring Secure Sockets Layer

Secure Sockets Layer (SSL) is an encrypted communication protocol that is designed to securely send messages across the Internet. It resides between Oracle HTTP Server on the application layer and the TCP/IP layer, transparently handling encryption and decryption when a secure connection is made by a client.

One common use of SSL is to secure Web HTTP communication between a browser and a Web server. This case does not preclude the use of non-secured HTTP. The secure version is simply HTTP over SSL (HTTPS). The differences are that HTTPS uses the URL scheme https:// rather than http://. The default communication port is 4443 in Oracle HTTP Server. Oracle HTTP Server does not use the 443 standard https:// privileged port because of security implications. For information about running Oracle HTTP Server on privileged ports see Section 4.3.2.4, "Starting Oracle HTTP Server Instances on a Privileged Port (UNIX Only)."

By default, an SSL listen port is configured and enabled using a default wallet during installation. Wallets store your credentials, such as certificate requests, certificates, and private keys.

The default wallet that is automatically installed with Oracle HTTP Server is for testing purposes only. A real wallet must be created for your production server. The default wallet is located in the DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName/keystores/default directory. You can either place the new wallet in this location, or change the SSLWallet directive in DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName/ssl.conf to point to the location of your real wallet.

For the changes to take effect, restart Oracle HTTP Server, as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

For information about configuring wallets and SSL by using Fusion Middleware Control, see "Enabling SSL for Oracle HTTP Server Virtual Hosts" in the Administering Oracle Fusion Middleware.

5.3.2 Configuring Secure Sockets Layer in Standalone Mode

The following sections contain information about how to enable and configure SSL for Oracle HTTP Server in standalone mode. These instructions use the mod_ossl plug-in to Oracle HTTP Server which enables the server to use SSL.

5.3.2.1 Configure SSL

By default, SSL is enabled when you install Oracle HTTP Server. Perform these tasks to modify and configure SSL:

5.3.2.1.1 Create a Real Wallet

To configure Oracle HTTP Server for SSL, you need a wallet that contains the certificate for the server. Wallets store your credentials, such as certificate requests, certificates, and private keys.

The default wallet that is automatically installed with Oracle HTTP Server is for testing purposes only. A real wallet must be created for your production server. The default wallet is located in $ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/instances/$COMPONENT_NAME/keystores/default. You can either place the new wallet in that location, or change the SSLWallet directive in $ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/instances/$COMPONENT_NAME/ssl.conf (the pre-installation location) to point to the location of your real wallet.

See Also:

"orapki" in Administering Oracle Fusion Middleware for instructions on creating a wallet. It is important that you do the following:

Generate a certificate request: For the Common Name, specify the name or alias of the site you are configuring. Make sure that you enable this auto_login_only feature.

5.3.2.1.2 (Optional) Customize Your Configuration

Optionally, you can further customize your configuration using mod_ossl directives.

See Also:

Note:

The files installed during configuration contain all of the necessary SSL configuration directives and a default setup for SSL.
5.3.2.1.3 Basic Configuration Example

Your SSL configuration must contain, at minimum, the following directives:

LoadModule ossl_module        "${PRODUCT_HOME}/modules/mod_ossl.so"
Listen 4443
ServerName www.testohs.com
SSLEngine on
#  SSL Protocol Support:
#  List the supported protocols.
SSLProtocol nzos_Version_1_2 nzos_Version_1_1 nzos_Version_1_0
#  SSL Cipher Suite:
#  List the ciphers that the client is permitted to negotiate.
SSLCipherSuite  SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
</VirtualHost>To enable client authentication, do the following:

5.3.2.2 Specify SSLVerifyClient on the Server Side

Use the appropriate client certificate on your client side for the HTTPS connection. See your client documentation for information on getting and using a client certificate. Be sure that your client certificate is trusted by the server wallet.

See Also:

"Importing a Certificate or a Trusted Certificate Using WLST" in Administering Oracle Fusion Middleware Guide for instructions on how to import a trusted certificate into your wallet.
5.3.2.2.1 Forcing Clients to Authenticate Using Certificates

You can force the client to validate its client certificate and allow access to the server using SSLVerifyClient. This scenario is valid for all clients having a client certificate supplied by the server Certificate Authority (CA). The server can validate client's supplied certificates against its CA for additional permission.

# require a client certificate which has to be directly
# signed by our CA certificate
SSLVerifyClient require
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
5.3.2.2.2 Forcing a Client to Authenticate for a Particular URL

To force a client to authenticate using certificates for a particular URL, you can use the per-directory reconfiguration features of mod_ossl. In this case, the SSLVerifyClient appears in a Location block.

SSLVerifyClient none
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
<Location /secure/area>
   SSLVerifyClient require
</Location>
5.3.2.2.3 Authorizing a Client for a Particular URL

To do this, check that part of the client certificate matches what you expect. Usually, this means checking all or part of the Distinguished Name (DN), to see if it contains some known string. There are two ways to do this, using either mod_auth_basic or SSLRequire.

The mod_auth_basic method is generally required when the certificates are completely arbitrary, or when their DNs have no common fields (usually the organization, and so on). In this case, you should establish a password database containing all of the clients allowed, for example:

SSLVerifyClient      none
<Directory /access/required>
    SSLVerifyClient      require
    SSLOptions           +FakeBasicAuth
    SSLRequireSSL
    AuthName             "Oracle Auth"
    AuthType             Basic
    AuthBasicProvider    file
    AuthUserFile         httpd.passwd
    Require              valid-user
</Directory>

The password used in this example is the DES encrypted string password. For more information on this directive, see Section F.3.10, "SSLOptions" which describes the SSLOptions directive of the mod_ossl module.

httpd.passwd
 
Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
Subject:        CN=localhost,OU=FOR TESTING ONLY,O=FOR TESTING ONLY
Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US

When your clients are all part of a common hierarchy, which is encoded into the DN, you can match them more easily using SSLRequire, for example:

SSLVerifyClient      none
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
 
<Directory /access/required>
  SSLVerifyClient      require
  SSLOptions           +FakeBasicAuth
  SSLRequireSSL
  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "VeriSign\, Inc." \    
and %{SSL_CLIENT_S_DN_OU} in {"Class", "Public", "Primary"}
</Directory>
5.3.2.2.4 Allowing Clients with Strong Ciphers and CA Client Certificate or Basic Authentication

The following examples presume that clients on the Intranet have IPs in the range 192.168.1.0/24, and that the part of the Intranet website you want to allow Internet access to is /access/required. This configuration should remain outside of your HTTPS virtual host, so that it applies to both HTTPS and HTTP.

SSLWallet "$ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/instances/$COMPONENT_NAME/keystores/default"
<Directory  /access/required>
    #   Outside the subarea only Intranet access is granted
    Require              ip 192.168.1.0/24
</Directory>
 
<Directory  /access/required>
    #   Inside the subarea any Intranet access is allowed
    #   but from the Internet only HTTPS + Strong-Cipher + Password
    #   or the alternative HTTPS + Strong-Cipher + Client-Certificate
 
    #   If HTTPS is used, make sure a strong cipher is used.
    #   Additionally allow client certs as alternative to basic auth.
    SSLVerifyClient      optional
    SSLOptions           +FakeBasicAuth +StrictRequire
    SSLRequire           %{SSL_CIPHER_USEKEYSIZE}>= 128
    #   Force clients from the Internet to use HTTPS
    RewriteEngine        on
    RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
    RewriteCond          %{HTTPS} !=on
    RewriteRule          . - [F]   
    #   Allow Network Access and/or Basic Auth
    Satisfy              any
 
    #   Network Access Control
    Require              ip 192.168.1.0/24
    #   HTTP Basic Authentication
    AuthType             basic
    AuthName             "Protected Intranet Area"
    AuthBasicProvider    file
    AuthUserFile         htpasswd
    Require              valid-user
</Directory>

5.3.2.3 Enable SSL Between Oracle HTTP Server and Oracle WebLogic Server

Use the Oracle WebLogic Server Proxy Plug-Ins to enable SSL between Oracle HTTP Server and Oracle WebLogic Server. The plug-ins allow you to configure SSL libraries and configure one-way and two-way SSL communications. For more information, see "Use SSL with Plug-Ins" and "Parameters for Web Server Plug-Ins" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.3.

5.3.3 Configuring MIME Settings

Oracle HTTP Server uses Multipurpose Internet Mail Extension (MIME) settings to interpret file types, encodings, and languages. MIME settings for Oracle HTTP Server can only be set using Fusion Middleware Control. You cannot use WLST commands to specify the MIME settings.

The following tasks can be completed on the MIME Configuration page:

5.3.3.1 Configuring MIME Types

MIME type maps a given file extension to a specified content type. The MIME type is used for filenames containing an extension.

5.3.3.1.1 Using Fusion Middleware Control to Configure MIME Types

To configure a MIME type using Fusion Middleware Control, do the following:

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select MIME Configuration from the Administration menu. The MIME configuration page appears.

  3. Click Add Row in MIME Configuration region. A new, blank row is added to the list.

  4. Enter the MIME type.

  5. Enter the file extension.

  6. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  7. Restart Oracle HTTP Server, as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

The MIME configuration is saved, and shown on the MIME Configuration page.

5.3.3.2 Configuring MIME Encoding

MIME encoding enables Oracle HTTP Server to determine the file type based on the file extension. You can add and remove MIME encodings. The encoding directive maps the file extension to a specified encoding type.

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select MIME Configuration from the Administration menu. The MIME configuration page appears.

  3. Expand the MIME Encoding region by clicking the plus sign (+) next to MIME Encoding.

  4. Click Add Row in MIME Encoding region. A new, blank row is added to the list.

  5. Enter the MIME encoding, such as x-gzip.

  6. Enter the file extension, such as .gx.

  7. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  8. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

5.3.3.3 Configuring MIME Languages

The MIME language setting maps file extensions to a particular language. This directive is commonly used for content negotiation, in which Oracle HTTP Server returns the document that most closely matched the preferences set by the client.

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select MIME Configuration from the Administration menu. The MIME configuration page appears.

  3. Expand the MIME Languages region by clicking the plus sign (+) next to MIME Languages.

  4. Click Add Row in MIME Languages region. A new, blank row is added to the list.

  5. Enter the MIME language, such as en-US.

  6. Enter the file extension, such as en-us.

  7. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  8. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

5.3.4 Configuring mod_perl

The mod_perl module embeds the Perl interpreter into Oracle HTTP Server. This eliminates start-up overhead and enables you to write modules in Perl. The module is disabled, by default.

This section contains the following procedures:

5.3.4.1 Enable mod_perl by Using Fusion Middleware Control

To enable the mod_perl module by using Fusion Middleware Control, do the following:

  1. Select Administration from the Oracle HTTP Server menu.

  2. Select mod_perl Configuration from the Administration menu. The mod_perl configuration page appears.

    Note:

    If mod_perl has not been enabled, then you will be redirected to the Server Configuration page. Select mod_perl and click Apply to enable mod_perl. After the confirmation page has been displayed, restart Oracle HTTP Server, and then return to the mod_perl Configuration page.

  3. Enter the switch information in the Switches field.

  4. Enter the environment variables to be passed to the scripts in the Environment field.

  5. Enter the required script names in the Require field.

  6. Click Add Row to create a new row.

  7. Configure mod_perl directives for a Location in the Perl Locations table. The Location assigns rules that the server should follow when the request's URI matches the Location.

    1. Enter the base URI for the Perl scripts in the Locations field. Just as it is the widely accepted convention to use /cgi-bin for your mod_cgi scripts, it is also conventional to use /perl as the base URI of the Perl scripts that run under mod_perl.

    2. Enter options in the Options field. The PerlOptions directive provides fine-grained configuration by providing control over which class of Perl interpreter pool to be used. Enable the options by prepending them with a plus sign (+); disable them by prepending them with a minus sign (-).

    3. If you want to send headers, then click the Send Header check box. The PerlSendHeader directive is for mod_perl 1.0 backward-compatibility. When enabled, the server sends an HTTP header to the browser on every script invocation. You should disable this option for NPH (non-parsed-headers) scripts.

    4. Enter the environment in the Environment field. The PerlSetEnv directive enables you to specify system environment variables and pass them into your mod_perl handlers.

    5. Enter the response handler in the Response Handler field. The PerlResponseHandler directive tells mod_perl which callback is going to do the job.

    6. Enter the authentication handler in the Authentication Handler field. The PerlAuthenHandler directive is used to set the handler to verify a user's identification credentials.

  8. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  9. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

The mod_perl module configuration is saved and shown on the mod_perl Configuration page.

Note:

If you are manually editing the mod_perl configuration instead of using Fusion Middleware Control, then all directives must be defined within the <IfModule mod_perl.c> block of the mod_perl.conf file. Any mod_perl related directives defined outside of this block might be ignored.

5.3.4.2 Enable mod_perl in a Standalone Domain

To enable mod_perl in a standalone domain, use this procedure:

  1. In the staging area ($DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1), manually move mod_perl.conf from the disabled directory to moduleconf directory.

  2. Upon running a start(), softRestart(), or shutdown() operation, the configuration change will take place, copying from staging to runtime area (for exampl;e, $DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs1).

  3. Upon being bounced, the ohs1 instance will not pick up the change and be running with mod_perl.

To disable the module, follow the same steps as above, but move from mod_perl from the moduleconf directory to the disabled directory.

5.3.5 Configuring the Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs)

You can configure the Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs) either by using Fusion Middleware Control or by editing the mod_wl_ohs.conf configuration file manually.

For information about the prerequisites and procedure for configuring the Oracle WebLogic Server Proxy Plug-In to proxy requests from Oracle HTTP Server to Oracle WebLogic Server, see "Configuring the Plug-In for Oracle HTTP Server" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.3.

5.3.6 Removing Access to Unneeded Content

By default, the httpd.conf file allows server access to extra content such as documentation and sample scripts. This access might present a low level security risk.

You might want to tailor this extra content in your own environment to suit your use cases. Follow the instructions in Section 1.6.3, "Modifying a Configuration File" to access the file.

5.3.6.1 Edit the cgi-bin Section

Examine the contents of the cgi-bin directory. You can either remove the code from the httpd.conf file that you do not need, or change the following Directory directive to point to your own CGI script directory.

...
# 
# "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
</Directory>
...

5.3.6.2 Edit the Fancy Indexing Section

Edit the following sections pertaining to fancy indexing in the httpd.conf file for your use cases.

...
#
# IndexOptions: Controls the appearance of server-generated directory
# listings.
#
IndexOptions FancyIndexing HTMLTable VersionSort
 
# We include the /icons/ alias for FancyIndexed directory listings.  If
# you do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "${PRODUCT_HOME}/icons/"
 
<Directory "${PRODUCT_HOME}/icons">
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>
 
#
# AddIcon* directives tell the server which icon to show for different
# files or filename extensions.  These are only displayed for
# FancyIndexed directories.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
 
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*
 
AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core
 
 
AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
 
#
# DefaultIcon is which icon to show for files which do not have an icon
# explicitly set.
#
DefaultIcon /icons/unknown.gif
 
#
# AddDescription allows you to place a short description after a file in
# server-generated indexes.  These are only displayed for FancyIndexed
# directories.
# Format: AddDescription "description" filename
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz
... 

#
# ReadmeName is the name of the README file the server will look for by
# default, and append to directory listings.
#
# HeaderName is the name of a file which should be prepended to
# directory indexes.
ReadmeName README.html
HeaderName HEADER.html
 
#
# IndexIgnore is a set of filenames which directory indexing should ignore
# and not include in the listing.  Shell-style wildcarding is permitted.
#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
...

5.3.6.3 Edit the Product Documentation Section

You can remove the following documentation configuration sections from the httpd.conf file if they are not needed.

... 
#
# This should be changed to the ServerRoot/manual/.  The alias provides
# the manual, even if you choose to move your DocumentRoot.  You may comment
# this out if you do not care for the documentation.
#
AliasMatch ^/manual(?:/(?:de|en|es|fr|ja|ko|pt-br|ru|tr))?(/.*)?$ "${PRODUCT_HOME}/manual$1"
 
<Directory "${PRODUCT_HOME}/manual">
    AllowOverride None
    Order allow,deny
    Allow from all
 
    <Files *.html>
        SetHandler type-map
    </Files>
    # .tr is text/troff in mime.types!
    <Files *.html.tr.utf8>
        ForceType text/html
    </Files>
 
    SetEnvIf Request_URI ^/manual/(de|en|es|fr|ja|ko|pt-br|ru|tr)/ prefer-language=$1
    RedirectMatch 301 ^/manual(?:/(de|en|es|fr|ja|ko|pt-br|ru|tr)){2,}(/.*)?$ /manual/$1$2
 
    LanguagePriority en de es fr ja ko pt-br ru tr
    ForceLanguagePriority Prefer Fallback
</Directory>
...

5.3.7 Using the apxs Command to Install Extension Modules

Note:

This command is only for UNIX and Linux and is necessary only for modules which are supplied in source code form. Follow the installation instructions for modules supplied in binary form.

For more information about the apxs command, see the Apache HTTP Server documentation at:

http://httpd.apache.org/docs/2.2/programs/apxs.html

Use the Apache Extension Tool (apxs) to build and install Apache HTTP Server extension modules for Oracle HTTP Server. apxs installs modules in the ORACLE_HOME/ohs/modules directory for access by any Oracle HTTP Server instances which run from this installation.

Note:

Once any third-party module is created and loaded, it falls under the third-party criteria specified in the Oracle HTTP Server support policy. Before continuing with this procedure, you should be aware of this policy. For more information, see Section 1.7, "Oracle HTTP Server Support"..

Recommended apxs options for use with Oracle HTTP Server are:

Option Purpose Example Command
-c Compile module source 
$ORACLE_HOME/ohs/bin/apxs -c mod_example.c
-i Install module binary into ORACLE_HOME 
$ORACLE_HOME/ohs/bin/apxs -ci mod_example.c

When the module binary has been installed into ORACLE_HOME, a LoadModule directive in httpd.conf or other configuration file is used to load the module into the server processes; for example:

LoadModule example_module "${ORACLE_HOME}/ohs/modules/mod_example.so"

The directive is required in the configurations for all instances which must load the module.

When the -a or -A option is specified, apxs will edit httpd.conf to add a LoadModule directive for the module. Do not use the -a and -A options with Oracle HTTP Server instances that are part of a WebLogic Server Domain. Instead, use Fusion Middleware Control to update the configuration, as described in Section 1.6.3, "Modifying a Configuration File".

You can use the -a or -A option with Oracle HTTP Server instances that are part of a standalone domain if the CONFIG_FILE_PATH environment variable is set to the staging directory for the instance before invoking apxs; for example:

CONFIG_FILE_PATH=$ORACLE_HOME/user_projects/domains/base_domain/config/fmwconfig/components/OHS/ohs1
export CONFIG_FILE_PATH
$ORACLE_HOME/ohs/bin/apxs -cia mod_example.c

By default, apxs uses the Perl interpreter in /usr/bin. If apxs cannot locate the product installation or encounters other operational errors when using /usr/bin/perl, use the Perl interpreter within the Middleware home by invoking apxs as follows:

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/ohs/bin/apxs -c mod_example.c

Modules often require directives besides LoadModule to properly function. After the module has been installed and loaded using the LoadModule directive, refer to the documentation for the module for any additional configuration requirements.

5.3.8 Disabling the Options Method

The Options method enables clients to determine which methods are supported by a web server. If enabled, it appears in the Allow line of HTTP response headers.

For example, if you send a request such as:

---- Request -------
OPTIONS / HTTP/1.0
Content-Length: 0
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: host123:80

you might get the following response from the web server:

---- Response --------
HTTP/1.1 200 OK
Date: Wed, 23 Apr 2008 20:20:49 GMT
Server: Oracle-Application-Server-11g/11.1.1.0.0 Oracle-HTTP-Server
Allow: GET,HEAD,POST,OPTIONS
Content-Length: 0
Connection: close
Content-Type: text/html

Some sources consider exposing the Options method a low security risk because malicious clients could use it to determine the methods supported by a web server. However, because web servers support only a limited number of methods, disabling this method will just slow down malicious clients, not stop them. In addition, the Options method may be used by legitimate clients.

If your Oracle Fusion Middleware environment does not have clients that require the Options method, you can disable it by including the following lines in the httpd.conf file:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteRule .* – [F]
</IfModule>

5.3.9 Updating Oracle HTTP Server Component Configurations on a Shared Filesystem

You might encounter functional or performance issues when an Oracle HTTP Server component is created on a shared filesystem, such as NFS (Network File System). In particular, lock files or UNIX sockets used by OHS might not work or may have severe performance degradation; WLS requests routed by mod_wl_ohs may have severe performance degradation due to filesystem accesses in the default configuration.

Table 5-1 provides information about the Lock file issues and the suggested changes in the httpd.conf file specific to the operating systems.

Table 5-1 Lock File issues

Operating System Description httpd.conf changes

Linux

Lock files when using a remote (non NFS4) file system.

Retain the AcceptMutex directive as fcntl and set the path to a local file system.

Solaris

Lock files are not required. The cross-process pthread mutex is the preferred cross-process mutex implementation.

Change AcceptMutex fcntl to AcceptMutex pthread (two places).

Comment out the LockFile directive (three places).

Other UNIX platforms

  

Change the LockFile directive to point to a local filesystem (three places).

UNIX socket issues

mod_cgid is not enabled by default. If enabled, use the ScriptSock directive to place mod_cgid's UNIX socket on a local filesystem.

mod_fastcgi is not enabled by default. If enabled, use the FastCgiIpcDir directive to place mod_fastcgi's UNIX sockets on a local filesystem.

  

5.4 Configuring mod_security

mod_security is an open-source module that you can use to detect and prevent intrusion attacks against Oracle HTTP Server; for example, you can specify a mod_security rule to screen all incoming requests and deny requests that match the conditions specified in the rule. The mod_security module (version 2.7.2) and its prerequisites are included in the Oracle HTTP Server installation as a shared object named mod_security2.so in the ORACLE_HOME/ohs/modules directory.

This version of OHS supports only mod_security (version 2.7.2) directives, variables, action, phases and functions. It will not be supported if you replace this module with a later version.

This appendix contains a usable example (Example E–1) of the mod_security.conf file, including the loadModule statement.

Notes:

Be aware of the following:

  • mod_security was removed from earlier versions of Oracle HTTP Server but was reintroduced in version 11.1.1.7. This version follows the recommendations and practices prescribed for open source mod_security 2.7.2. Only documentation applicable to open source mod_security 2.7.2 is applicable to the Oracle HTTP Server implementation of the module.

  • In Oracle HTTP Server 11.1.1.7 and later, mod_security is not loaded or configured by default; however, if you have an installation patched from 11.1.1.6, implementing the patch might have already loaded and configured the module.

  • Oracle only supports the Oracle-supplied version of mod_security. Newer versions from modsecurity.org will not be supported.

http://www.modsecurity.org/documentation/

This section contains the following information:

5.4.1 Enabling mod_security

To make the mod_security module available for use when Oracle HTTP Server is running, ensure that mod_security.conf begins with the following lines:

#Load module
LoadModule security2_module "${PRODUCT_HOME}/modules/mod_security2.so"

as shown in the mod_security.conf example in Example 5-1.

5.4.2 Configuring mod_security

Configuring mod_security involves specifying certain directives in the Oracle HTTP Server configuration file. You can specify the directives directly in the httpd.conf file in an IfModule container. Alternatively, you can specify the mod_security directives in a separate mod_security.conf file and include that .conf file in httpd.conf by using the Include directive.

By default, mod_security.conf does not exist, so you need to create it, preferably by using the template in Example 5-1. Copy and paste the sample into a text editor and read the entire file, editing it for your system. Then save it as your own mod_security.conf and include it from your httpd.conf. If you implement mod_security.conf as described, it will use the LoadModule directive to load mod_security2.so into the run time environment.

Example 5-1 mod_security.conf Sample

#Load module 
LoadModule security2_module "${PRODUCT_HOME}/modules/mod_security2.so"
# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
SecRuleEngine DetectionOnly


# -- Request body handling ---------------------------------------------------

# Allow ModSecurity to access request bodies. If you don't, ModSecurity
# won't be able to see any POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On

# Enable XML request body parser.
# Initiate XML Processor in case of xml content-type
#
SecRule REQUEST_HEADERS:Content-Type "text/xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"


# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When the multipart
# parser reachers this limit, it will start using your hard disk for
# storage. That is slow, but unavoidable.
#
SecRequestBodyInMemoryLimit 131072

# What do do if the request body size is above our configured limit.
# Keep in mind that this setting will automatically be set to ProcessPartial
# when SecRuleEngine is set to DetectionOnly mode in order to minimize
# disruptions when initially deploying ModSecurity.
#
SecRequestBodyLimitAction Reject

# Verify that we've correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
#
SecRule REQBODY_ERROR "!@eq 0" \
"id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request
 body.',logdata:'%{reqbody_error_msg}',severity:2"

# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
#
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200002',phase:2,t:none,log,deny,status:44, \
msg:'Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

# Did we see anything that might be a boundary?
#
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"

# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

# Some internal errors will set flags in TX and we will need to look for these.
# All of these are prefixed with "MSC_".  The following flags currently exist:
#
# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
#
SecRule TX:/^MSC_/ "!@streq 0" \
        "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"

# -- Response body handling --------------------------------------------------

# Allow ModSecurity to access response bodies. 
# You should have this directive enabled in order to identify errors
# and data leakage issues.
# 
# Do keep in mind that enabling this directive does increases both
# memory consumption and response latency.
#
SecResponseBodyAccess On

# Which response MIME types do you want to inspect? You should adjust the
# configuration below to catch documents but avoid static files
# (e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml

# Buffer response bodies of up to 512 KB in length.
SecResponseBodyLimit 524288

# What happens when we encounter a response body larger than the configured
# limit? By default, we process what we have and let the rest through.
# That's somewhat less secure, but does not break any legitimate pages.
#
SecResponseBodyLimitAction ProcessPartial

# -- Filesystem configuration ------------------------------------------------

# The location where ModSecurity stores temporary files (for example, when
# it needs to handle a file upload that is larger than the configured limit).
# 
# This default setting is chosen due to all systems have /tmp available however, 
# this is less than ideal. It is recommended that you specify a location that's private.
#
SecTmpDir /tmp/

# The location where ModSecurity will keep its persistent data.  This default setting 
# is chosen due to all systems have /tmp available however, it
# too should be updated to a place that other users can't access.
#
SecDataDir /tmp/

# -- File uploads handling configuration -------------------------------------

# The location where ModSecurity stores intercepted uploaded files. This
# location must be private to ModSecurity. You don't want other users on
# the server to access the files, do you?
#
#SecUploadDir /opt/modsecurity/var/upload/

# By default, only keep the files that were determined to be unusual
# in some way (by an external inspection script). For this to work you
# will also need at least one file inspection rule.
#
#SecUploadKeepFiles RelevantOnly

# Uploaded files are by default created with permissions that do not allow
# any other user to access them. You may need to relax that if you want to
# interface ModSecurity to an external program (e.g., an anti-virus).
#
#SecUploadFileMode 0600


# -- Debug log configuration -------------------------------------------------

# The default debug log configuration is to duplicate the error, warning
# and notice messages from the error log.
#
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3


# -- Audit log configuration -------------------------------------------------

# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,  
# level response status codes).
#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial
SecAuditLog "${ORACLE_INSTANCE}/servers/${COMPONENT_NAME}/logs/modsec_audit.log"

# Specify the path for concurrent audit logging.
SecAuditLogStorageDir "${ORACLE_INSTANCE}/servers/${COMPONENT_NAME}/logs"
#Simple test 
SecRule ARGS "\.\./" "t:normalisePathWin,id:99999,severity:4,msg:'Drive Access'" 

# -- Miscellaneous -----------------------------------------------------------

# Use the most commonly used application/x-www-form-urlencoded parameter
# separator. There's probably only one application somewhere that uses
# something else so don't expect to change this value.
#
SecArgumentSeparator &

# Settle on version 0 (zero) cookies, as that is what most applications
# use. Using an incorrect cookie version may open your installation to
# evasion attacks (against the rules that examine named cookies).
#
SecCookieFormat 0

# Specify your Unicode Code Point.
# This mapping is used by the t:urlDecodeUni transformation function
# to properly map encoded data to your language. Properly setting
# these directives helps to reduce false positives and negatives.
#
#SecUnicodeCodePage 20127
#SecUnicodeMapFile unicode.mapping