Oracle HTTP Serverの操作

5 Oracle HTTP Serverの操作

Oracle HTTP Serverのインストールされたバージョンを操作する場合、構成ファイルの編集やサーバー・プロパティの指定など、実行する必要のある共通タスクがいくつかあります。

この章の内容は次のとおりです。

構成ファイルの編集について
構成ファイルは、WebLogic ServerドメインのFusion Middleware Controlまたはスタンドアロン・ドメインのテキスト・エディタを使用して編集できます。
サーバー・プロパティの指定
サーバー・プロパティには、ドキュメント・ルート、管理者の電子メール、ディレクトリの索引およびオペレーティング・システムの詳細などの項目が含まれます。 Fusion Middleware Controlのみを使用するか、構成ファイルを直接編集することによって、Oracle HTTP Serverプロパティを設定可能です。WLSTコマンドを使用してサーバー・プロパティを指定することはできません。
Oracle HTTP Serverインスタンスの構成
一部の共通のOracle HTTP Serverインスタンスの構成手順は、セキュア・ソケット、MIME設定、Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)、mod_proxy_fcgiなどに関連しています。
mod_securityモジュールの構成
オープン・ソースのmod_securityモジュールを使用してOracle HTTP Serverに対する侵入攻撃を検出および防止できます。たとえば、mod_securityルールを指定して、すべての受信リクエストをスクリーニングし、ルールで指定された条件に一致するリクエストを拒否します。

構成ファイルの編集について

構成ファイルは、WebLogic ServerドメインのFusion Middleware Controlまたはスタンドアロン・ドメインのテキスト・エディタを使用して編集できます。

WebLogic Serverドメインの一部であるインスタンスの場合、Fusion Middleware Controlおよび管理インフラストラクチャはOracle HTTP Server構成を管理します。ステージング・ディレクトリ内での構成に対する直接編集は、Fusion Middleware Controlでの構成の変更などの後続の管理操作の後で上書きされる可能性があります。このようなインスタンスでは、直接編集は管理サーバーが停止時にのみ実行できます。管理サーバーがその後に起動(または再起動)されると、手動編集の結果が、管理対象インスタンスのノード上のランタイム・ディレクトリにレプリケートされます。

「構成ファイルの理解」を参照してください。

次のセクションで、構成ファイルの変更の詳細を説明しています。

親トピック: Oracle HTTP Serverの操作

スタンドアロン・ドメイン用の構成ファイルの編集

スタンドアロン・インスタンスの場合、構成はいつでもステージング・ディレクトリ内で直接編集できます。ランタイム構成ファイルは、Oracle HTTP Serverインスタンスの起動、再起動または停止時に更新されます。

親トピック: 構成ファイルの編集について

WebLogic Serverドメイン用の構成ファイルの編集

WebLogic Serverドメイン用の構成ファイルを変更できます。Fusion Middleware Controlを使用してこれらのファイルを編集します。変更は、Oracle HTTP Serverの再起動後に、「サーバーの詳細構成」ページに表示されます。

ノート:

Fusion Middleware Controlを使用してadmin.confファイルを編集することはできません。admin.confファイルを手動で編集するには、テキスト・エディタを使用する必要があります。

Fusion Middleware Controlを使用して構成ファイルを開いて編集するには、次の手順を実行します:

「HTTP Server」メニューから「管理」を選択します。
「管理」メニュー・アイテムから「詳細構成」を選択します。
「サーバーの詳細構成」ページで、「ファイルの選択」ドロップダウン・リストから、httpd.confファイルなどの構成ファイルを選択して「実行」をクリックします。
必要に応じてファイルを編集します。
設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。
Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

ファイルが保存され、「サーバーの詳細構成」ページに表示されます。

親トピック: 構成ファイルの編集について

サーバー・プロパティの指定

サーバー・プロパティには、ドキュメント・ルート、管理者の電子メール、ディレクトリの索引およびオペレーティング・システムの詳細などの項目が含まれます。 Fusion Middleware Controlのみを使用するか、構成ファイルを直接編集することによって、Oracle HTTP Serverプロパティを設定可能です。WLSTコマンドを使用してサーバー・プロパティを指定することはできません。

この項には次のトピックが含まれます:

親トピック: Oracle HTTP Serverの操作

Fusion Middleware Controlを使用したサーバー・プロパティの指定

次のステップに従い、Fusion Middleware Controlを使用してサーバー・プロパティを指定します。

「Oracle HTTP Server」メニューから「管理」を選択します。
「管理」メニューから「サーバー構成」を選択します。
「サーバー構成」ページで、サーバーのプロパティを入力します。
1. 「ドキュメント・ルート」フィールドに、Webサイトから表示できるメイン・ドキュメント・ツリーを構成するドキュメント・ルート・ディレクトリを入力します。
2. 「管理者の電子メール・アドレス」フィールドに、サーバーがクライアントに送信するエラー・メッセージに挿入する電子メール・アドレスを入力します。
3. 「ディレクトリの索引」フィールドにディレクトリの索引を入力します。これは、クライアントがWebサイトに最初にアクセスしたときに表示されるメイン・ページ(indexページ)です。
4. 「モジュール」リージョンを使用して、モジュールを有効化または無効化します。使用可能なモジュールはmod_authnz_fcgiおよびod_proxy_fcgiです。「mod_proxy_fcgiの構成について」を参照してください。
5. 必要な場合は、「別名」表に別名を作成します。別名は、指定したディレクトリにマップされます。たとえば、あるグループでコンテンツ・ページの特定のセットを使用するため、そのコンテンツ・ページを含むディレクトリに別名を作成できます。
設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。
Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

サーバー・プロパティが保存され、「サーバー構成」ページに表示されます。

親トピック: サーバー・プロパティの指定

httpd.confファイルの編集によるサーバー・プロパティの指定

httpd.confファイルを手動で編集することでサーバー・プロパティを指定できます。次のステップに従って、httpd.confファイルを編集してください。

ノート:

.confファイルを編集しようとする前に、構成ファイル・ディレクトリのレイアウト、ファイル編集のメカニズムおよびファイル自体についてさらに学習する必要があります。「構成ファイルの理解」を参照してください。

テキスト・エディタまたはFusion Middleware Controlの「サーバーの詳細構成」ページを使用して、httpd.confファイル(「マスター」または「ステージング」コピー: $DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name/httpd.conf)を開きます。(Oracle HTTP Server構成ファイルの変更を参照してください。)
ファイルのServerAdminセクションに、管理者の電子メール・アドレスを入力します。これは、クライアント・ページに表示される電子メール・アドレスです。この構文の例を次に示します。
```
ServerAdmin WebMaster@example.com
```
ファイルのDirectoryIndexセクションに、ディレクトリの索引を入力します。これは、クライアントがWebサイトに最初にアクセスしたときに表示されるメイン・ページ(indexページ)です。この構文の例を次に示します。
```
DirectoryIndex index.html index.html.var
```
必要に応じて別名を作成します。別名は、指定したディレクトリにマップされます。たとえば、アイコンの特定のセットを使用するため、Webページ用のアイコンを含むディレクトリに別名を作成できます。この構文の例を次に示します。
```
Alias /icons/ "${PRODUCT_HOME}/icons/"<Directory "${PRODUCT_HOME}/icons">    Options Indexes MultiViews    AllowOverride None    Require all granted</Directory> 
```
ファイルを保存します。
Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

親トピック: サーバー・プロパティの指定

Oracle HTTP Serverインスタンスの構成

一部の共通のOracle HTTP Serverインスタンスの構成手順は、セキュア・ソケット、MIME設定、Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)、mod_proxy_fcgiなどに関連しています。

ノート:

この項には、初期システム構成の情報は含まれていません。初期システム構成の説明は、『Oracle HTTP Serverのインストールと構成』を参照してください。

この項には次のトピックが含まれます:

ノート:

Oracle HTTP Server構成を管理するFusion Middleware Controlおよびその他のOracleソフトウェアは、同等の異なる形式で構成ファイルを保存する可能性があります。ソフトウェアを使用して構成を変更した後に、複数の構成ファイルがリライトされる可能性があります。

親トピック: Oracle HTTP Serverの操作

Secure Sockets Layerの構成

Secure Sockets Layer (SSL)は、インターネット経由でメッセージを安全に送信することを目的に設計された、暗号化された通信プロトコルです。SSLは、アプリケーション層のOracle HTTP ServerとTCP/IP層の中間に存在します。クライアントによりセキュアな接続が作成されたときに暗号化と復号化を透過的に処理します。

SSLの一般的な用途の1つは、ブラウザとWebサーバー間のWeb HTTP通信を保護することです。この場合、保護されていないHTTPの使用は排除されません。保護されたバージョンは、単純にHTTP over SSL (HTTPS)と呼ばれます。HTTPSではURLスキームとしてhttp://ではなくhttps://を使用するという点が異なります。Oracle HTTP Serverのデフォルト通信ポートは4443です。Oracle HTTP Serverでは、セキュリティ上の理由から443標準https://特権ポートを使用しません。特権ポートでOracle HTTP Serverを実行する方法の詳細は、「特権ポートでのOracle HTTP Serverインスタンスの起動(LinuxおよびUNIXのみ)」を参照してください。

デフォルトでは、SSLリスニング・ポートはインストール中にデフォルトのウォレットを使用して構成されて有効化されます。ウォレットには、証明書リクエスト、証明書および秘密キーなど、資格証明が格納されます。

Oracle HTTP Serverとともに自動的にインストールされるデフォルトのウォレットは、テスト目的のみに使用されるものです。本番サーバーに対して実際のウォレットを作成する必要があります。デフォルトのウォレットは、DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName/keystores/defaultディレクトリにあります。新しいウォレットをこの場所に配置することも、実際のウォレットの場所を示すようにDOMAIN_HOME/config/fmwconfig/components/OHS/componentName/ssl.confのSSLWalletディレクティブを変更することもできます。

Message Digest 5 algorithm (MD5)を使用する証明書を使用しないことをお薦めします。このアルゴリズムは、セキュリティが著しく侵害されています。MD5証明書は、より安全な暗号化を提供するSecure Hash Algorithm 2 (SHA-2)を使用する証明書と置き換える必要があります。

変更を有効にするには、Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

Fusion Middleware ControlでウォレットとSSLを構成する方法の詳細は、Oracle Fusion Middlewareの管理ガイドのOracle HTTP Server仮想ホストに対するSSLの有効化を参照してください。

ノート:

サポートされるのは、auto_login_onlyウォレットのみです。

親トピック: Oracle HTTP Serverインスタンスの構成

スタンドアロン・モードでのSecure Sockets Layerの構成

次の各項では、スタンドアロン・モードでOracle HTTP ServerのSSLを有効化して構成する方法について説明します。これらの手順では、サーバーでSSLを使用できるようにするOracle HTTP Serverに対するmod_osslモジュールを利用します。

親トピック: Oracle HTTP Serverインスタンスの構成

SSLの構成

デフォルトでは、Oracle HTTP ServerをインストールするときにSSLが有効化されます。次のタスクを実行して、SSLを変更および構成します。

親トピック: スタンドアロン・モードでのSecure Sockets Layerの構成

タスク1: 本番ウォレットの作成

SSL用にOracle HTTP Serverを構成するには、サーバーの証明書を含むウォレットが必要です。ウォレットには、証明書リクエスト、証明書および秘密キーなど、資格証明が格納されます。

Oracle HTTP Serverとともに自動的にインストールされるデフォルトのウォレットは、テスト目的のみに使用されるものです。本番サーバーに対して実際のウォレットを作成する必要があります。デフォルトのウォレットは、ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/instances/$COMPONENT_NAME/keystores/defaultにあります。新規のウォレットをその場所に格納することも、ssl.conf (事前インストール場所)内のSSLWalletディレクティブを変更して実際のウォレットの場所を指し示すこともできます。

タスク2: (オプション)構成のカスタマイズ

オプションで、mod_osslディレクティブを使用して構成を詳細にカスタマイズすることができます。

基本SSL構成の例

SSL構成には、最低でも次の例のディレクティブが含まれている必要があります。

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 TLSv1.2 TLSv1.3
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate. 
SSLCipherSuite TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"

親トピック: SSLの構成

サーバー側でのSSLVerifyClientの指定

この項では、SSLVerifyClientディレクティブを使用してアクセスを認証および認可する様々な方法について説明します。HTTPS接続のためにクライアント側で適切なクライアント証明書を使用します。クライアント証明書の取得および使用方法については、クライアントのドキュメントを参照してください。Oracleサーバー・ウォレットによってクライアント証明書が信頼されていることを確認します。

サーバーがクライアント証明書を信頼していることを確認するには、クライアント証明書が自己署名されているか認証局(CA)によって署名されているかをチェックできます。どちらの場合も、証明書を信頼できる証明書のリストに追加する必要があります。

信頼できるクライアント証明書をOracleウォレットに追加するには、次のいずれかの方法を使用します。

親トピック: スタンドアロン・モードでのSecure Sockets Layerの構成

スタンドアロンOracle HTTP Serverインストールでの信頼できるクライアント証明書の追加

信頼できる証明書をスタンドアロン・インストールのウォレットに追加するには、orapkiコマンドを使用します。『Oracle Fusion Middlewareの管理』のorapkiに関する項を参照してください。

親トピック: サーバー側でのSSLVerifyClientの指定

コロケートOracle HTTP Serverインストールでの信頼できるクライアント証明書の追加

信頼できる証明書をコロケート・インストールのウォレットに追加するには、Fusion Middleware ControlまたはWebLogic Scripting Toolを使用します。

証明書をキーストアの信頼できる証明書リストにインポートします。
信頼できる証明書をキーストアにインポートした後、キーストアをサーバーのウォレットにエクスポートします。

Fusion Middleware Controlを使用して証明書をインポートするには、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlを使用した証明書の管理に関する項を参照してください。

WebLogic Scripting Toolを使用して証明書をインポートし、キーストアをエクスポートするには、『Oracle Platform Security Servicesによるアプリケーションの保護』のWLSTを使用した証明書の管理に関する項およびWLSTを使用したキーストアの管理に関する項を参照してください。

次の項では、SSLVerifyClientディレクティブを使用してアクセスを認証および認可する様々な方法について説明します。

親トピック: サーバー側でのSSLVerifyClientの指定

クライアントによる証明書を使用した強制的な認証

クライアントでSSLVerifyClientを使用してそのクライアント証明書を強制的に検証し、サーバーへのアクセスを許可することができます。このシナリオは、サーバー認証局(CA)から提供されたクライアント証明書を持つすべてのクライアントに有効です。サーバーは追加の権限のために、クライアントの提供された証明書をそのCAに対して検証できます。

# 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"

親トピック: サーバー側でのSSLVerifyClientの指定

クライアントによる特定のURLに対する強制的な認証

クライアントで特定のURLに対して証明書を使用して強制的に認証するには、mod_osslのディレクトリ単位の再構成機能を使用できます。この場合、SSLVerifyClientはLocationブロックに表示されます。

SSLVerifyClient none
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
<Location /secure/area>
   SSLVerifyClient require
</Location>

親トピック: サーバー側でのSSLVerifyClientの指定

特定のURLに対するクライアントの認可

特定のURLに対しクライアントを認証するには、クライアント証明書の一部が、必要としているものに一致していることを確認します。通常これは、識別名(DN)のすべてまたは一部をチェックして、特定の既知の文字列が含まれているかどうかを確認することを意味します。これを実行する方法は2つあり、mod_auth_basicまたはSSLRequireを使用します。

mod_auth_basicを使用する方法は一般的に、証明書が完全に任意である場合、またはそれらの証明書のDNに共通のフィールド(通常、組織など)がない場合に必要になります。この場合、許可されたすべてのクライアントを含むパスワード・データベースを構築する必要があります。たとえば、次のようになります。

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

この例で使用されているパスワードは、DESで暗号化された文字列passwordです。このディレクティブの詳細は、mod_osslモジュールのSSLOptionsディレクティブについて説明している「SSLOptionsディレクティブ」を参照してください。

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

クライアントがすべてDNにエンコードされる共通階層の一部である場合、SSLRequireを使用してそれらをより簡単に照合することができます。たとえば、次のようになります。

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>

親トピック: サーバー側でのSSLVerifyClientの指定

強力な暗号およびCAクライアント証明書またはBasic認証を使用したクライアントの許可

次の例では、イントラネット上のクライアントが範囲192.168.1.0/24内のIPを持ち、またインターネット・アクセスを許可するイントラネットWebサイトの一部が/access/requiredであると仮定しています。この構成は、HTTPS仮想ホストの外側に残す必要があります。これにより、HTTPSと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>

親トピック: サーバー側でのSSLVerifyClientの指定

Oracle HTTP ServerとOracle WebLogic Serverとの間のSSLの有効化

Oracle HTTP ServerとOracle WebLogic Serverとの間のSSLを有効化するには、Oracle WebLogic Serverプロキシ・プラグインを使用します。このプラグインを使用すると、SSLライブラリを構成して、一方向と双方向のSSL通信を構成できます。『Oracle WebLogic Serverプロキシ・プラグインの使用』のSSLのプラグインとの使用に関する項およびOracle WebLogic Serverプロキシ・プラグインのパラメータに関する項を参照してください。

親トピック: スタンドアロン・モードでのSecure Sockets Layerの構成

Oracle HTTP ServerでのSAN証明書の使用

Subject Alternative Name(SAN)証明書またはUnified Communications証明書(UCC)は、「サブジェクトの代替名」フィールドに指定された複数のサブドメインを保護できます。

「サブジェクトの代替名」(SAN)フィールドを使用して、単一のSSL証明書によって保護される追加のホスト名(たとえば、サイト、IPアドレス、コマンド名)を指定できます。SAN証明書を使用すると、異なるベース・ドメインにあるホスト名を1つのSSL証明書で保護できます。サブジェクトの代替名を持つ複数ドメイン(SAN)証明書を使用して、複数のSSL有効サイトを1つのサーバーにホストすることもできます。SAN拡張機能のある証明書では、ワイルドカードの使用はサポートされていません。そのため、各サブドメインを個別に追加する必要があります。

orapkiユーティリティを使用したSAN拡張機能のある証明書リクエストの作成

SAN拡張機能のある証明書リクエストを作成するには、orapkiユーティリティを使用します。証明書リクエストのOracleウォレットへの追加に関する項を参照してください。

SAN証明書を使用したサンプル構成

同じIPアドレスおよびポートを使用して処理する各ホストに対して<VirtualHost>ブロックを作成します。
各<VirtualHost>ブロックで、どのホストが処理されているかを指定するServerNameディレクティブを設定します。

たとえば、1つ目のVirtualHostが最初の仮想ホスト・ブロックの場合、ServerNameをServerName ns1.example.comに設定します。同様に、2つ目のVirtualHostが2番目の仮想ホスト・ブロックの場合、ServerNameをServerName ns2.example.comに設定します。
ホスト名が、SAN拡張機能フィールドに追加された様々な仮想ホストを参照している証明書を生成します。
各<VirtualHost>ブロックで、ステップ3で生成した証明書を含むウォレットに対してSSLWalletディレクティブを設定します。

たとえば、SSLwallet serverなどです。
変更を保存し、Oracle HTTP Serverを起動します。

サンプル構成例

Listen 4443
<VirtualHost>
 ServerName ns1.example.com
 SSLWallet "server"
</VirtualHost>

<VirtualHost>
 ServerName ns2.example.com
 SSLWallet "server"
</VirtualHost>

親トピック: スタンドアロン・モードでのSecure Sockets Layerの構成

Server Name Indicationの使用

Server Name Indication (SNI)を使用すると、クライアントは、要求されたホスト名をそのSSLハンドシェイクの最初のメッセージに含めることができます。

SNIを使用すると、サーバーはリクエストの正しい名前付き仮想ホストを特定でき、それに応じて最初から接続を設定できます。SNIによって、複数の仮想ホストで同じIPアドレスとポートを共有でき、それぞれに独自の証明書やその他の構成を設定できます。

SNIの構成

SSLStrictSNIVHostディレクティブを使用して、SNI以外のクライアントに名前ベースの仮想ホストへのアクセスを許可するかどうかを制御します。

SSL名前ベースの仮想ホストの最初(デフォルト)の仮想ホストには、TLSv1.2以降で許可されるプロトコルが少なくとも1つ含まれている必要があります。そうでない場合、Oracle HTTP Serverは、クライアントからSNI情報を受け入れず、クライアントがSNIをまったくサポートしていないかのように動作します。

指定されたサーバー名がもう1つの仮想ホストと一致しない場合に、最初の仮想ホストがすべてのリクエストに対して使用されるため、最初の仮想ホストのアクセス制御の制限を最も厳しくすることが重要です。そうしないと、クライアントが不明なホスト名に対してリクエストを送信することで、制限されたリソースにアクセスできます。

クライアントがSNIをサポートしていない場合

Oracle HTTP ServerがSNIをサポートしている場合、名前ベースの仮想ホストに対してSNIホスト名なしのリクエストがSSL経由で受信され、SSLStrictSNIVHostCheckがonのとき、そのリクエストは403エラー(禁止)で拒否され、次のメッセージが記録されます:

[error] No hostname was provided via SNI for a name based virtual host

SSLStrictSNIVHostCheckがoffの場合、リクエストは、サーバーがSNIをサポートしていないかのように処理されます。

例5-1 サンプル構成

Server Configuration :
 
# Ensure that Oracle HTTP Server listens on port 443
Listen 443
 
# Listen for virtual host requests on all IP addresses
NameVirtualHost *:443
 
# Go ahead and accept connections for these vhosts
# from non-SNI clients
SSLStrictSNIVHostCheck off
 
<VirtualHost *:443>
  # Because this virtual host is defined first, it will
  # be used as the default if the hostname is not received
  # in the SSL handshake, e.g. if the browser doesn't support
  # SNI.
  DocumentRoot /www/example1
  ServerName www.example.com
 
  # Other directives here
 
</VirtualHost>
 
<VirtualHost *:443>
  DocumentRoot /www/example2
  ServerName www.example2.org
 
  # Other directives here
 
</VirtualHost>

親トピック: スタンドアロン・モードでのSecure Sockets Layerの構成

WLSTを使用したキーストアのOracle HTTP Serverインスタンスへのエクスポート

コロケートされたOracle HTTPサーバーでは、実行時にOracleウォレットが使用されます。Oracleウォレットでは、証明書の管理にorapkiなどのツールを使用しないことをお薦めします。かわりに、中央記憶域およびキーストア・サービスで利用できる統合管理を使用して、そのサービスのエクスポート、インポートおよび同期化機能により、ウォレットとその内容を管理します。KSSによって提供されるexportKeyStoreコマンドは、キーストアからウォレットにエクスポートするために使用できます。ただし、exportKeyStoreコマンドを使用する際に、ユーザーが意識する必要がある意味合いが多数あります。したがって、ohs_exportKeystoreというカスタムOHS WLSTコマンドが用意されています。

キーストアの変更後、WLSTカスタム・コマンドohs_exportKeyStoreを使用して、キーストアをOracleウォレットにエクスポートします。このコマンドおよびキーストアの命名規則の詳細は、「ohs_exportKeyStore」を参照してください。

コマンド行からWLSTを起動します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd
管理サーバー・インスタンスに接続します。
```
connect('<userName', '<password>', '<host>:<port>')  
```
次のようにohs_exportKeyStoreカスタムWLSTコマンドを実行します。
```
ohs_exportKeyStore(keyStoreName = '<keystore_name>', instanceName = '<name_of_the_OHS_instance>') 
```
たとえば、キーストアohs1_myKeystoreをOracle HTTP Serverインスタンスohs1にエクスポートします。
```
ohs_exportKeyStore(keyStoreName = 'ohs1_myKeystore', instanceName = 'ohs1') 
```

親トピック: Oracle HTTP Serverインスタンスの構成

Fusion Middleware Controlを使用したMIME設定の構成

Oracle HTTP Serverでは、Multipurpose Internet Mail Extension (MIME)設定を使用してファイル・タイプ、エンコーディングおよび言語の解析を行います。Oracle HTTP ServerのMIME設定は、Fusion Middleware Controlでのみ指定できます。WLSTコマンドを使用してMIME設定を指定することはできません。

「MIME構成」ページでは、次のタスクを実行できます。

親トピック: Oracle HTTP Serverインスタンスの構成

MIMEタイプの構成

MIMEタイプにより、指定されたコンテンツ・タイプに特定のファイル拡張子がマップされます。MIMEタイプは、拡張子を含むファイル名に使用されます。

Fusion Middleware Controlを使用してMIMEタイプを構成するには、次の手順を実行します。

「Oracle HTTP Server」メニューから「管理」を選択します。
「管理」メニューから「MIME構成」を選択します。「MIME構成」ページが表示されます。「MIMEタイプ」リージョンにスクロールします。
「MIME構成」リージョンの「行の追加」をクリックします。新規の空白行がリストに追加されます。
MIMEタイプおよびそれに関連付けられたファイル拡張子を入力します。
設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。
Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

MIME構成が保存され、「MIME構成」ページに表示されます。

親トピック: Fusion Middleware Controlを使用したMIME設定の構成

MIMEエンコーディングの構成

MIMEエンコーディングにより、Oracle HTTP Serverでは、ファイル拡張子に基づいてファイル・タイプを判別できます。MIMEエンコーディングは、追加および削除できます。エンコーディング・ディレクティブにより、指定のエンコーディング・タイプにファイル拡張子をマップします。

「Oracle HTTP Server」メニューから「管理」を選択します。
「管理」メニューから「MIME構成」を選択します。「MIME構成」ページが表示されます。「MIMEエンコーディング」リージョンにスクロールします。
必要に応じて、「MIMEエンコーディング」の横にあるプラス記号(+)をクリックして「MIMEエンコーディング」リージョンを開きます。
「MIMEエンコーディング」リージョンの「行の追加」をクリックします。新規の空白行がリストに追加されます。
MIMEエンコーディング(x-gzipなど)を入力します。
ファイル拡張子(.gxなど)を入力します。
設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。
Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

親トピック: Fusion Middleware Controlを使用したMIME設定の構成

MIME言語の構成

MIME言語設定により、特定の言語にファイル拡張子がマップされます。このディレクティブは、一般的にコンテンツ・ネゴシエーションに使用されます(クライアントにより設定されたプリファレンスに対する一致度が最も高いドキュメントがOracle HTTP Serverから返されます)。

「Oracle HTTP Server」メニューから「管理」を選択します。
「管理」メニューから「MIME構成」を選択します。「MIME構成」ページが表示されます。「MIME言語」リージョンにスクロールします。
必要に応じて、「MIME言語」の横にあるプラス記号(+)をクリックして「MIME言語」リージョンを開きます。
「MIME言語」リージョンの「行の追加」をクリックします。新規の空白行がリストに追加されます。
MIME言語(en-USなど)を入力します。
ファイル拡張子(en-usなど)を入力します。
デフォルトのMIME言語を選択するには、必要な行を選択し、「デフォルトとして設定」をクリックします。デフォルト言語が「デフォルトのMIME言語」フィールドに表示されます。
設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。
Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

親トピック: Fusion Middleware Controlを使用したMIME設定の構成

mod_proxy_fcgiの構成について

mod_proxy_fcgiモジュールに構成ディレクティブはありません。そのかわりに、mod_proxyモジュール上のディレクティブ・セットを使用します。mod_fcgidおよびmod_fastcgiモジュールとは異なり、mod_proxy_fcgiモジュールにはアプリケーション・プロセスの開始のプロビジョニングはありません。mod_proxy_fcgiの目的は、より速いパフォーマンスのためにこの機能をWebサーバーの外に移動することです。そのため、mod_proxy_fcgiは外部FastCGIサーバーへのリバース・プロキシとして動作するだけです。

mod_proxy_fcgiモジュールの構成の詳細は、「mod_proxy_fcgiを外部FastCGIサーバーへのリバース・プロキシとして動作するように構成」および「外部FastCGI Serverの設定」を参照してください。

親トピック: Oracle HTTP Serverインスタンスの構成

Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)の構成について

Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)を構成するには、Fusion Middleware Controlを使用するか、またはmod_wl_ohs.conf構成ファイルを手動で編集します。

リクエストをOracle HTTP ServerからOracle WebLogic ServerにプロキシできるようにOracle WebLogic Serverプロキシ・プラグインを構成する際の前提条件と手順の詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』のOracle HTTP ServerのWebLogicプロキシ・プラグインの構成に関する項を参照してください。

mod_wl_ohsのSSLの構成

親トピック: Oracle HTTP Serverインスタンスの構成

mod_wl_ohsのSSLの構成

Secure Sockets Layer (SSL)プロトコルを使用することで、プラグインとOracle WebLogic Serverとの間の接続を保護できます。SSLプロトコルによって、プラグインとWebLogic Serverとの間で渡されるデータの機密性と整合性が保持されます。『Oracle WebLogic Serverプロキシ・プラグインの使用』のSSLのプラグインとの使用に関する項を参照してください。

親トピック: Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)の構成について

不要なコンテンツへのアクセス権の削除

デフォルトでは、httpd.confファイルにより、サーバーはドキュメントやサンプル・スクリプトなどの追加のコンテンツにアクセスできます。このアクセスには低いレベルのセキュリティ・リスクが存在する可能性があります。Oracle HTTP Server 12c (12.2.1)リリースから、これらのセクションの一部はコメントアウトされています。

ユースケースに合せて使用環境でのこの追加コンテンツを調整することができます。httpd.confファイルにアクセスするには、構成ファイルの編集についてを参照してください。

この項には次のトピックが含まれます:

親トピック: Oracle HTTP Serverインスタンスの構成

cgi-binセクションの編集

cgi-binディレクトリのコンテンツを調査します。不要なコードをhttpd.confファイルから削除したり、固有のCGIスクリプト・ディレクトリを指す次の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
    Require all granted
</Directory>
...

親トピック: 不要なコンテンツへのアクセス権の削除

Fancy Indexingセクションの編集

ユースケースに応じたhttpd.confファイルのfancy indexingに関する次のセクションを編集します。

...
# Uncomment the following line to enable the fancy indexing configuration
# below.
# Define ENABLE_FANCYINDEXING
<IfDefine ENABLE_FANCYINDEXING>

# 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">
    Options Indexes MultiViews
    AllowOverride None
    Require all granted
</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
</IfDefine>

親トピック: 不要なコンテンツへのアクセス権の削除

製品ドキュメント・セクションの編集

Define MANUAL_ENABLE行をアンコメントにして、製品ドキュメントの手動での構成を有効にします。

... 
#
# Uncomment the following line to enable the manual configuration below.
# Define ENABLE_MANUAL
<IfDefine ENABLE_MANUAL>
AliasMatch ^/manual(?:/(?:de|en|es|fr|ja|ko|pt-br|ru|tr))?(/.*)?$ "${PRODUCT_HOME}/manual$1"
 
<Directory "${PRODUCT_HOME}/manual">
    Options Indexes
    AllowOverride None
    Require all granted
 
    <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>
</IfDefine>

親トピック: 不要なコンテンツへのアクセス権の削除

apxsコマンドを使用した拡張モジュールのインストール

ノート:

このコマンドはUNIXとLinux専用であり、ソース・コード形式で提供されているモジュールに対してのみ使用する必要があります。バイナリ形式で提供されているモジュールのインストール手順に従ってください。

apxsコマンドの詳細は、次のApache HTTP Serverのドキュメントを参照してください。

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

Apache拡張ツール(apxs)では、Oracle HTTP Server用のApache HTTP Server拡張モジュールをビルドおよびインストールできます。apxsは、モジュールをORACLE_HOME/ohs/modulesディレクトリにインストールし、このインストールから実行されるOracle HTTP Serverインスタンスがアクセスできるようにします。

ノート:

いったんなんらかのサードパーティ製モジュールの生成とロードが行われると、Oracle HTTP Serverサポート・ポリシーに記載されたサードパーティ条件に該当することになります。この手順を続ける前に、このポリシーをお読みください。Oracle HTTP Serverサポートに関する項を参照してください。

Oracle HTTP Serverで使用する場合に推奨されるapxsオプションを次に示します。

オプション	用途	コマンド例
-c	モジュール・ソースのコンパイル	$ORACLE_HOME/ohs/bin/apxs -c mod_example.c
-i	ORACLE_HOMEへのモジュール・バイナリのインストール	$ORACLE_HOME/ohs/bin/apxs -ci mod_example.c

モジュール・バイナリがORACLE_HOMEにインストールされると、httpd.confファイルまたはその他の構成ファイルのLoadModuleディレクティブによりモジュールがサーバー・プロセスにロードされます。たとえば:

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

このディレクティブは、モジュールをロードする必要があるすべてのインスタンスの構成で必須です。

-aまたは-Aオプションが指定されている場合、apxsはhttpd.confを編集してモジュールのLoadModuleディレクティブを追加します。WebLogic Serverドメインの一部であるOracle HTTP Serverインスタンスでは-aおよび-Aオプションを使用しないでください。かわりに、Oracle HTTP Server構成ファイルの変更の説明に従って、Fusion Middleware Controlを使用して構成を更新します。

スタンドアロン・ドメインの一部であるOracle HTTP Serverインスタンスでは、apxsの起動前にCONFIG_FILE_PATH環境変数がインスタンスのステージング・ディレクトリに設定されている場合、-aまたは-Aオプションを使用できます。たとえば:

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

デフォルトでは、apxsは、/usr/binにあるPerlインタプリタを使用します。apxsが製品のインストールを見つけることができない場合または/usr/bin/perlの使用時にその他の操作エラーが発生した場合は、次のようにapxsを起動することによってMiddlewareホーム内でPerlインタプリタを使用します。

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

多くの場合、モジュールは正常に機能するためにLoadModule以外のディレクティブも必要とします。モジュールがインストールされ、LoadModuleディレクティブを使用してロードされた後、その他の構成要件についてモジュールのドキュメントを参照してください。

親トピック: Oracle HTTP Serverインスタンスの構成

Optionsメソッドの無効化

Optionsメソッドにより、クライアントは、Webサーバーでサポートされるメソッドを確認できます。これが有効の場合、HTTPレスポンス・ヘッダーのAllow行に出力されます。

たとえば、次のようなリクエストを送信するとします。

---- 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

この場合、Webサーバーから次のようなレスポンスが返されます。

---- 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

一部のソースでは、Optionsメソッドを公開することはセキュリティ上のリスクが低いと考えられます。悪質なクライアントは、このメソッドを使用してWebサーバーでサポートされるメソッドを判断できます。ただし、Webサーバーでサポートされるメソッドの数は限られているため、このメソッドを無効にしても悪質なクライアントに対して時間稼ぎとなるだけで、攻撃をやめさせることはできません。また、Optionsメソッドは、正当なクライアントによって使用されることもあります。

Oracle Fusion Middleware環境にOptionsメソッドを必要とするクライアントが存在しない場合、httpd.confファイルに次の行を追加してこのメソッドを無効化できます。

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

親トピック: Oracle HTTP Serverインスタンスの構成

共有ファイル・システムでのOracle HTTP Serverコンポーネント構成の更新

NFS(ネットワーク・ファイル・システム)などの共有ファイル・システムでOracle HTTP Serverコンポーネントが作成される際、機能上またはパフォーマンス上の問題が発生する場合があります。特に、Oracle HTTP Serverで使用されるロック・ファイルまたはUNIXソケットが機能しない、またはそのパフォーマンスが大幅に低下する可能性があります。また、mod_wl_ohsでルーティングされるOracle WebLogic Serverリクエストが、デフォルト構成のファイル・システム・アクセスが原因で、パフォーマンスが大幅に低下する場合があります。

表5-1に、ロック・ファイルの問題と推奨されるhttpd.confファイルの変更に関する詳細を、オペレーティング・システム別に示します。

表5-1 ロック・ファイルの問題

オペレーティング・システム	説明	httpd.confの変更点
Linux	ロック・ファイルは必要ありません。Sys Vセマフォが、推奨されるプロセス間mutexの実装です。	`Mutex` `fnctl:fileloc default`を`Mutex` `sysvsem` `default`に変更します。ここで、`fileloc`はディレクティブ`Mutex`の値です(httpd.conf内の3箇所)。
Solaris	ロック・ファイルは必要ありません。プロセス間pthread mutexが、推奨されるプロセス間mutexの実装です。	`Mutex` `fnctl:fileloc default`を`Mutex pthread default`に変更します。ここで、`fileloc`はディレクティブ`Mutex`の値です(httpd.conf内の3箇所)。
その他のUNIXプラットフォーム		`Mutex`ディレクティブに指定されたファイルの場所をローカルのファイル・システムを指すように変更します(httpd.conf内の3箇所)。
UNIXソケットの問題	mod_cgidは、デフォルトでは有効になっていません。有効な場合は、`ScriptSock`ディレクティブを使用してmod_cgidのUNIXソケットをローカル・ファイル・システムに配置します。

親トピック: Oracle HTTP Serverインスタンスの構成

mod_securityモジュールの構成

オープン・ソースのmod_securityモジュールを使用してOracle HTTP Serverに対する侵入攻撃を検出および防止できます。たとえば、mod_securityルールを指定して、すべての受信リクエストをスクリーニングし、ルールで指定された条件に一致するリクエストを拒否します。

mod_securityモジュールとその前提条件は、mod_security2.soという共有オブジェクトとして、ORACLE_HOME/ohs/modulesディレクトリ内のOracle HTTP Serverインストールに含まれています。共有オブジェクトmod_security2.soは、cURLおよびOpenSSLライブラリに依存しています。これらのライブラリは、Oracle HTTP Serverのインストールにも含まれています。Oracle HTTP Serverインストールの一部として提供されるmod_securityモジュールは、SecRemoteRulesディレクティブをサポートしています。このディレクティブにより、ユーザーはターゲット・サーバーからルールをロードできます。Oracle HTTPサーバーから、mod_securityルールをホストするターゲット・サーバーへの通信は、TLSを介して行われ、cURLおよびOpenSSLを使用して実装されます。

Oracle HTTP Serverとターゲット・サーバー間のTLS通信は、Oracle HTTP Serverが通信先のリモート・サーバーを信頼している場合にのみ成功します。信頼を確立するには、Oracle HTTP Serverで使用されるトラスト・ストアを、リモート・サーバーのCA証明書で更新します。

リモート・サーバーのCA証明書チェーンをトラスト・ストアに追加するには:

リモート・サーバーのCA証明書チェーンを取得します。
証明書チェーンの内容をデフォルトのトラスト・ストア・パスに追加します。

Linux上のlibcurlで使用されるトラスト・ストアのパスは、/etc/pki/tls/certs/ca-bundle.crtです。

Linuxの場合:

リモート・サーバーのCA証明書チェーンを取得します。

次のOpenSSLコマンドを使用してリモート・サーバーに接続し、証明書チェーンをPEM形式で取得します。


$ openssl s_client  -showcerts -connect host:sslport         
    
PEM  Format will look like this :
===========================       

-----BEGIN CERTIFICATE----- 
……………
------END CERTIFICATE-----
==============================


Example :  openssl s_client  -showcerts -connect oracle.com:443
Sample output for oracle.com:443 which  contains three certificates in cert chain.  
=========================Sample output==============================
CONNECTED(00000005)
….. 
Certificate chain
 0 s:/C=US/ST=California/L=Redwood City/O=Oracle Corporation/CN=oracle.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
-----BEGIN CERTIFICATE-----
F8XNzDlYAiEAq/wO4SuGY12xwbrqXsYf7+eGP8hjUyqwx0QQZ8n1WcoAdgDm0jFj
…….
tgr6NGY=
-----END CERTIFICATE-----
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
MI--------------
--------------------
A7sKPPcw7+uvTPyLNhBzPvOk
-----END CERTIFICATE-----
 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
Mi-….
------------------
CAUw7C29C79Fv1C5qfPrmAE
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Redwood City/O=Oracle Corporation/CN=oracle.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1

/etc/pki/tls/certs/ca-bundle.crtファイルを開き、PEMテキスト・ファイル内のテキストを追加します。

ノート:

ファイルの末尾に新しい行を追加しないでください。

証明書チェーンに複数の証明書が存在する場合は、それぞれのPEM形式の証明書をca-bundle.crtファイルにコピーします。

Windowsの場合:

次のリンクから、cacert.pemをダウンロードします:

https://curl.se/docs/caextract.html
cacert.pemファイルの名前をcurl-ca-bundle.crtに変更します。
次のいずれかのディレクトリにcurl-ca-bundle.crtを配置します:
1. Windowsシステム・ディレクトリ。たとえば、C:\windows\system32です。
2. Windowsディレクトリ。たとえば、C:\windowsです。
3. %PATH%に存在する任意のディレクトリ。たとえば、%PRODUCT_HOME%\binです。

CA証明書をcurl-ca-bundle.crtに追加します。

次のOpenSSLコマンドを使用してリモート・サーバーに接続し、証明書チェーンをPEM形式で取得します。


$ openssl s_client  -showcerts -connect host:sslport         
    
PEM  Format will look like this :
===========================       

-----BEGIN CERTIFICATE----- 
……………
------END CERTIFICATE-----
==============================


Example :  openssl s_client  -showcerts -connect oracle.com:443 
Sample output for oracle.com:443 which  contains three certificates in cert chain.  
=========================Sample output==============================
CONNECTED(00000005)
….. 
Certificate chain
 0 s:/C=US/ST=California/L=Redwood City/O=Oracle Corporation/CN=oracle.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
-----BEGIN CERTIFICATE-----
F8XNzDlYAiEAq/wO4SuGY12xwbrqXsYf7+eGP8hjUyqwx0QQZ8n1WcoAdgDm0jFj
…….
tgr6NGY=
-----END CERTIFICATE-----
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
MI--------------
--------------------
A7sKPPcw7+uvTPyLNhBzPvOk
-----END CERTIFICATE-----
 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
Mi-….
------------------
CAUw7C29C79Fv1C5qfPrmAE
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Redwood City/O=Oracle Corporation/CN=oracle.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1

curl-ca-bundle.crtファイルを開き、PEMテキスト・ファイル内のテキストを追加します。

ノート:

ファイルの末尾に新しい行を追加しないでください。

証明書チェーンに複数の証明書が存在する場合は、それぞれのPEM形式の証明書をcurl-ca-bundle.crtファイルにコピーします。

Oracle HTTP Serverでは、mod_securityバージョン2.9.0のディレクティブ、変数、アクション、フェーズおよび関数がサポートされています。https://modsecurity.org/を参照してください。

サンプルmod_security.confファイルでは、LoadModule文を含む、mod_security.confファイルの使用可能な例について説明します。

mod_security構成はhttpd.conf構成ファイルに追加することも、別個のmod_security.conf 構成ファイルに表示することもできます。

この項には次の情報が含まれます:

親トピック: Oracle HTTP Serverの操作

httpd.confファイルのmod_securityの構成

IfModuleコンテナのhttpd.confファイルにmod_securityディレクティブを入力することで、mod_securityモジュールを構成できます。Oracle HTTP Serverの実行時にmod_securityモジュールを使用できるようにするには、mod_security構成が次の行で開始されていることを確認します。

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

親トピック: mod_securityモジュールの構成

mod_security.confファイルのmod_securityの構成

別個のmod_security.confファイルにmod_securityディレクティブを指定し、Includeディレクティブを使用してhttpd.confファイルにその.confファイルを含めることもできます。

できればサンプルmod_security.confファイルのテンプレートを使用して、mod_security.confファイルを自身で作成する必要があります。

テキスト・エディタにサンプルをコピーして貼り付け、使用しているシステム用に編集します。
Oracle HTTP Serverの実行時にmod_securityモジュールを使用できるようにするには、mod_security.confが次の行で開始されていることを確認します。
```
#Load module
LoadModule security2_module "${PRODUCT_HOME}/modules/mod_security2.so"
```
「mod_security.conf」という名前でファイルを保存し、Includeディレクティブを使用してそれをhttpd.confファイルに含めることができます。

記載の手順に従ってmod_security.confファイルを実装する場合は、LoadModuleディレクティブを使用してmod_security2.soを実行環境にロードします。

親トピック: mod_securityモジュールの構成

mod_security.confファイルのSecRemoteRulesの構成

SecRemoteRulesは、リモート・サーバーからルールをロードするために使用できるオプションのディレクティブです。

構文

SecRemoteRules some-key https://www.yourserver.com/plain-text-rules.txt

表5-2に、SecRemoteRulesの変数についての情報を示します。

表5-2 SecRemoteRulesの変数

変数説明

変数	説明
some-key	これらのキーは、様々なキーに対して様々なコンテンツを提供するために、ターゲット・サーバーによって使用されます。これらのキーを指定する必要があります。これらのキーとともに、`mod_security`は、その一意のIDおよびステータス・コールをヘッダーの形式でターゲットWebサーバーに送信します。次のヘッダーが使用されます。 ModSec-status ModSec-unique-id ModSec-key 任意のオプション`crypto`では、`mod_security`にサーバーからの暗号化コンテンツを期待するように指示します。`SecRemoteRules`の使用は、TLSでのみ可能です。そのため、このオプションは必要でないことがあります。
yourserver.com	yourserver.comは、`mod_security`ルールをホストするリモート・サーバーです。 SecRemoteRulesディレクティブがサーバーS1上で構成されるとき、S1はyourserver.comとのSSL接続を確立してmod_securityルールをフェッチします。ここで、`plain-text-rules.txt`ファイルにはmod_securityルールが含まれます。サーバーS1はSSLクライアントとして機能し、yourserver.comはSSLサーバーとして機能します。 SSLクライアントは、`libcurl`を使用して実装されます。デフォルトでは、`libcurl`によりピアSSL証明書が検証されます。この検証は、SSLライブラリが使用できるCA証明書ストアを使用して、ピアのサーバー証明書が有効であることを確認するために行われます。使用しているストアに含まれないCAによって署名された証明書をサーバーが使用する場合、このCA証明書を既存のデフォルトのCA証明書ストアに追加します。Linux上の`libcurl`で使用されるトラスト・ストアのパスは、`/etc/pki/tls/certs/ca-bundle.crt`です。リモート・サーバー証明書をトラスト・ストアに追加するには、次の手順を実行します。特定のサーバーのCA証明書を抽出します。 opensslツールを使用する場合、次の手順を実行すると特定のサーバーのCA証明書を抽出できます。 `openssl s_client -connect xxxxx.com:443 \|tee logfile` QUITと入力し、[Enter]を押します。証明書には、BEGIN CERTIFICATEおよびEND CERTIFICATEのマーカーが付きます。証明書の内容をデフォルトのトラスト・ストア・パスに追加します。 `/etc/pki/tls/certs/ca-bundle.crt` ファイルの最後に新しい行を追加しないでください。 `libcurl`によってもサーバー・ホスト名の検証を実行できます。つまり、`libcurl`は、証明書のCommon NameフィールドまたはSubject Alternate Nameフィールドが、curlに接続するように指定したURLのホスト名と一致するとき、サーバーが意図したサーバーであるとみなします。この条件が一致しない場合、通信は失敗する場合があります。

some-key

これらのキーは、様々なキーに対して様々なコンテンツを提供するために、ターゲット・サーバーによって使用されます。これらのキーを指定する必要があります。

これらのキーとともに、mod_securityは、その一意のIDおよびステータス・コールをヘッダーの形式でターゲットWebサーバーに送信します。次のヘッダーが使用されます。

ModSec-status
ModSec-unique-id
ModSec-key

任意のオプションcryptoでは、mod_securityにサーバーからの暗号化コンテンツを期待するように指示します。SecRemoteRulesの使用は、TLSでのみ可能です。そのため、このオプションは必要でないことがあります。

yourserver.com

yourserver.comは、mod_securityルールをホストするリモート・サーバーです。

SecRemoteRulesディレクティブがサーバーS1上で構成されるとき、S1はyourserver.comとのSSL接続を確立してmod_securityルールをフェッチします。ここで、plain-text-rules.txtファイルにはmod_securityルールが含まれます。サーバーS1はSSLクライアントとして機能し、yourserver.comはSSLサーバーとして機能します。

SSLクライアントは、libcurlを使用して実装されます。デフォルトでは、libcurlによりピアSSL証明書が検証されます。この検証は、SSLライブラリが使用できるCA証明書ストアを使用して、ピアのサーバー証明書が有効であることを確認するために行われます。

使用しているストアに含まれないCAによって署名された証明書をサーバーが使用する場合、このCA証明書を既存のデフォルトのCA証明書ストアに追加します。Linux上のlibcurlで使用されるトラスト・ストアのパスは、/etc/pki/tls/certs/ca-bundle.crtです。

リモート・サーバー証明書をトラスト・ストアに追加するには、次の手順を実行します。

特定のサーバーのCA証明書を抽出します。
opensslツールを使用する場合、次の手順を実行すると特定のサーバーのCA証明書を抽出できます。
1. openssl s_client -connect xxxxx.com:443 |tee logfile
2. QUITと入力し、[Enter]を押します。
  
  証明書には、BEGIN CERTIFICATEおよびEND CERTIFICATEのマーカーが付きます。
証明書の内容をデフォルトのトラスト・ストア・パスに追加します。

/etc/pki/tls/certs/ca-bundle.crt

ファイルの最後に新しい行を追加しないでください。

libcurlによってもサーバー・ホスト名の検証を実行できます。つまり、libcurlは、証明書のCommon NameフィールドまたはSubject Alternate Nameフィールドが、curlに接続するように指定したURLのホスト名と一致するとき、サーバーが意図したサーバーであるとみなします。この条件が一致しない場合、通信は失敗する場合があります。

親トピック: mod_securityモジュールの構成

監査ロギングのためのmod_securityの構成

SecAuditEngineディレクティブは、完全なトランザクションを記録する監査エンジンの構成に使用されます。ModSecurityは現在、ほとんどのトランザクションを記録できますが、すべてではありません。エラーを含むトランザクション(400または404トランザクションなど)では、ModSecurityがサポートしていない別の実行パスが使用されます。

監査ログエンジンに指定できる値:

On: すべてのトランザクションを記録します。
Off:トランザクションをまったく記録しません。
RelevantOnly: 警告またはエラーをトリガーしたログ・トランザクション、または関連があるとみなされるステータス・コード(SecAuditLogRelevantStatusディレクティブによって決定される)のログ・トランザクションのみ。

詳細は、『OWASP ModSecurityリファレンス・マニュアル』のSecAuditEngineを参照してください。

次の例は、SecAuditEngineの使用方法を示しています:

SecAuditEngine RelevantOnly
SecAuditLog logs/audit/audit.log
SecAuditLogParts ABCFHZ
SecAuditLogType concurrent
SecAuditLogStorageDir logs/audit
SecAuditLogRelevantStatus ^(?:5|4(?!04))

親トピック: mod_securityモジュールの構成

サンプルmod_security.confファイル

次のコードは、サンプルのmod_security.conf構成ファイルを示しています。

例5-2 mod_security.confの例

#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 minimizes 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

親トピック: mod_securityモジュールの構成