5 Oracle HTTP Serverの操作
Oracle HTTP Serverのインストールされたバージョンを操作する場合、構成ファイルの編集やサーバー・プロパティの指定など、実行する必要のある共通タスクがいくつかあります。
この章の内容は次のとおりです。
- 構成ファイルの編集について
構成ファイルは、変更が失われないようにするため、管理サーバーが停止された後にのみ編集します。 - サーバー・プロパティの指定
サーバー・プロパティには、ドキュメント・ルート、管理者の電子メール、ディレクトリの索引およびオペレーティング・システムの詳細などの項目が含まれます。 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
ルールを指定して、すべての受信リクエストをスクリーニングし、ルールで指定された条件に一致するリクエストを拒否します。
親トピック: Oracle HTTP Serverの管理
構成ファイルの編集について
構成ファイルは、変更が失われないようにするため、管理サーバーが停止された後にのみ編集します。
WebLogic Serverドメインの一部であるインスタンスの場合、Fusion Middleware Controlおよび管理インフラストラクチャはOracle HTTP Server構成を管理します。ステージング・ディレクトリ内での構成に対する直接編集は、Fusion Middleware Controlでの構成の変更などの後続の管理操作の後で上書きされる可能性があります。このようなインスタンスでは、直接編集は管理サーバーが停止時にのみ実行できます。管理サーバーがその後に起動(または再起動)されると、手動編集の結果が、管理対象インスタンスのノード上のランタイム・ディレクトリにレプリケートされます。
「構成ファイルの理解」を参照してください。
次のセクションで、構成ファイルの変更の詳細を説明しています。
- スタンドアロン・ドメイン用の構成ファイルの編集
- WebLogic Serverドメイン用の構成ファイルの編集
WebLogic Serverドメイン用の構成ファイルを変更できます。Fusion Middleware Controlを使用してこれらのファイルを編集します。変更は、Oracle HTTP Serverの再起動後に、「サーバーの詳細構成」ページに表示されます。
親トピック: 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」メニューから「管理」を選択します。
-
「管理」メニューから「サーバー構成」を選択します。
-
「サーバー構成」ページで、サーバーのプロパティを入力します。
-
「ドキュメント・ルート」フィールドに、Webサイトから表示できるメイン・ドキュメント・ツリーを構成するドキュメント・ルート・ディレクトリを入力します。
-
「管理者の電子メール・アドレス」フィールドに、サーバーがクライアントに送信するエラー・メッセージに挿入する電子メール・アドレスを入力します。
-
「ディレクトリの索引」フィールドにディレクトリの索引を入力します。これは、クライアントがWebサイトに最初にアクセスしたときに表示されるメイン・ページ(indexページ)です。
-
「モジュール」リージョンを使用して、モジュールを有効化または無効化します。使用可能なモジュールはmod_authnz_fcgiおよびod_proxy_fcgiです。「mod_proxy_fcgiの構成について」を参照してください。
-
必要な場合は、「別名」表に別名を作成します。別名は、指定したディレクトリにマップされます。たとえば、あるグループでコンテンツ・ページの特定のセットを使用するため、そのコンテンツ・ページを含むディレクトリに別名を作成できます。
-
-
設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。
-
Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。
サーバー・プロパティが保存され、「サーバー構成」ページに表示されます。
親トピック: サーバー・プロパティの指定
httpd.confファイルの編集によるサーバー・プロパティの指定
httpd.conf
ファイルを手動で編集することでサーバー・プロパティを指定できます。次のステップに従って、httpd.conf
ファイルを編集してください。
ノート:
.conf
ファイルを編集しようとする前に、構成ファイル・ディレクトリのレイアウト、ファイル編集のメカニズムおよびファイル自体についてさらに学習する必要があります。「構成ファイルの理解」を参照してください。
親トピック: サーバー・プロパティの指定
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ソフトウェアは、同等の異なる形式で構成ファイルを保存する可能性があります。ソフトウェアを使用して構成を変更した後に、複数の構成ファイルがリライトされる可能性があります。
- Secure Sockets Layerの構成
- スタンドアロン・モードでのSecure Sockets Layerの構成
- WLSTを使用したキーストアのOracle HTTP Serverインスタンスへのエクスポート
- Fusion Middleware Controlを使用したMIME設定の構成
- mod_proxy_fcgiの構成について
- Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)の構成について
- 不要なコンテンツへのアクセス権の削除
- apxsコマンドを使用した拡張モジュールのインストール
- Optionsメソッドの無効化
- 共有ファイル・システムでのOracle HTTP Serverコンポーネント構成の更新
親トピック: 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インスタンスの起動(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の有効化を参照してください。
親トピック: Oracle HTTP Serverインスタンスの構成
スタンドアロン・モードでのSecure Sockets Layerの構成
次の各項では、スタンドアロン・モードでOracle HTTP ServerのSSLを有効化して構成する方法について説明します。これらの手順では、サーバーでSSLを使用できるようにするOracle HTTP Serverに対するmod_osslモジュールを利用します。
- SSLの構成
- サーバー側でのSSLVerifyClientの指定
- Oracle HTTP ServerとOracle WebLogic Serverとの間のSSLの有効化
- Oracle HTTP ServerでのSAN証明書の使用
親トピック: Oracle HTTP Serverインスタンスの構成
SSLの構成
デフォルトでは、Oracle HTTP ServerをインストールするときにSSLが有効化されます。次のタスクを実行して、SSLを変更および構成します。
タスク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
ディレクティブを使用して構成を詳細にカスタマイズすることができます。
関連項目:
-
mod_ossl
で使用できるディレクティブのリストおよび説明は、mod_osslモジュールを参照してください。 -
SSLFIPS
ディレクティブの構成方法および使用できる暗号スイートのリストについては、SSLFIPSディレクティブを参照してください。
ノート:
構成時にインストールされたファイルには、すべての必要なSSL構成ディレクティブおよびSSL用のデフォルト設定が含まれています。
親トピック: SSLの構成
基本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.1 TLSv1 # 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,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:
親トピック: SSLの構成
サーバー側でのSSLVerifyClientの指定
この項では、SSLVerifyClientディレクティブを使用してアクセスを認証および認可する様々な方法について説明します。HTTPS接続のためにクライアント側で適切なクライアント証明書を使用します。クライアント証明書の取得および使用方法については、クライアントのドキュメントを参照してください。Oracleサーバー・ウォレットによってクライアント証明書が信頼されていることを確認します。
サーバーがクライアント証明書を信頼していることを確認するには、クライアント証明書が自己署名されているか認証局(CA)によって署名されているかをチェックできます。どちらの場合も、証明書を信頼できる証明書のリストに追加する必要があります。
信頼できるクライアント証明書をOracleウォレットに追加するには、次のいずれかの方法を使用します。
次の項では、SSLVerifyClientディレクティブを使用してアクセスを認証および認可する様々な方法について説明します。
スタンドアロンOracle HTTP Serverインストールでの信頼できるクライアント証明書の追加
信頼できる証明書をスタンドアロン・インストールのウォレットに追加するには、orapki
コマンドを使用します。『Oracle Fusion Middlewareの管理』のorapkiに関する項を参照してください。
親トピック: サーバー側でのSSLVerifyClientの指定
コロケートOracle HTTP Serverインストールでの信頼できるクライアント証明書の追加
親トピック: サーバー側での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プロキシ・プラグインのパラメータに関する項を参照してください。
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ディレクティブを設定します。たとえば、
VH1
が最初の仮想ホスト・ブロックの場合、ServerNameをServerName ns1.example.com
に設定します。同様に、VH2
が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>
制限事項
Oracle HTTP Serverでは、Server Name Indication (SNI)拡張はサポートされていません。SNIサポートがない状況で、複数のSubjectAltName
拡張エントリのある証明書を使用して、2つ以上のSSL有効仮想ホストを設定する場合、1つ目の仮想ホストに対して設定されたper-vhost mod_ossl
ディレクトリのみが考慮されます。
次の構成について考えます。
# Ensure that Apache listens on port 443
Listen 443
<VirtualHost *:443>
# Because this virtual host is defined first, it will
# be used as the default
DocumentRoot /www/example1
ServerName ns1.example.com
# Other directives here
SSLCipherSuite AES
SSLProtocol TLSv1
</VirtualHost>
<VirtualHost *:443>
DocumentRoot /www/example2
ServerName ns2.example.com
# Other directives here
SSLCipherSuite AES-GCM
SSLProtocol TLSv1.2
</VirtualHost>
ns1.example.com
およびns2.example.com
の両方に接続する場合、許可される暗号およびプロトコルは、それぞれAESおよびTLSv1となります。ns2.example.com
に対して暗号スイート・ディレクティブがAES-GCMに設定され、プロトコル・バージョンがTLSv1.2に設定されていても、ns2.example.com
への接続中のハンドシェイクで使用されるものはAES暗号およびTLSv1プロトコルのみとなります。
WLSTを使用したキーストアのOracle HTTP Serverインスタンスへのエクスポート
コロケートされたOracle HTTPサーバーでは、実行時にOracleウォレットが使用されます。Oracleウォレットでは、証明書の管理にorapkiなどのツールを使用しないことをお薦めします。かわりに、中央記憶域およびキーストア・サービスで利用できる統合管理を使用して、そのサービスのエクスポート、インポートおよび同期化機能により、ウォレットとその内容を管理します。KSSによって提供されるexportKeyStore
コマンドは、キーストアからウォレットにエクスポートするために使用できます。ただし、exportKeyStore
コマンドを使用する際に、ユーザーが意識する必要がある意味合いが多数あります。したがって、ohs_exportKeystore
というカスタムOHS WLSTコマンドが用意されています。
キーストアの変更後、WLSTカスタム・コマンドohs_exportKeyStore
を使用して、キーストアをOracleウォレットにエクスポートします。このコマンドおよびキーストアの命名規則の詳細は、「ohs_exportKeyStore」を参照してください。
親トピック: 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構成」ページでは、次のタスクを実行できます。
MIMEタイプの構成
MIMEタイプにより、指定されたコンテンツ・タイプに特定のファイル拡張子がマップされます。MIMEタイプは、拡張子を含むファイル名に使用されます。
Fusion Middleware Controlを使用してMIMEタイプを構成するには、次の手順を実行します。
- 「Oracle HTTP Server」メニューから「管理」を選択します。
- 「管理」メニューから「MIME構成」を選択します。「MIME構成」ページが表示されます。「MIMEタイプ」リージョンにスクロールします。
- 「MIME構成」リージョンの「行の追加」をクリックします。新規の空白行がリストに追加されます。
- MIMEタイプおよびそれに関連付けられたファイル拡張子を入力します。
- 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。
- Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。
MIME構成が保存され、「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を再起動します。
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を再起動します。
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モジュールの構成の詳細は、タスク3: mod_proxy_fcgiを外部FastCGIサーバーへのリバース・プロキシとして動作するように構成およびタスク4: 外部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の構成
Secure Sockets Layer (SSL)プロトコルを使用することで、プラグインとOracle WebLogic Serverとの間の接続を保護できます。SSLプロトコルによって、プラグインとWebLogic Serverとの間で渡されるデータの機密性と整合性が保持されます。『Oracle WebLogic Serverプロキシ・プラグインの使用』のSSLのプラグインとの使用に関する項を参照してください。
不要なコンテンツへのアクセス権の削除
デフォルトでは、httpd.confファイルにより、サーバーはドキュメントやサンプル・スクリプトなどの追加のコンテンツにアクセスできます。このアクセスには低いレベルのセキュリティ・リスクが存在する可能性があります。Oracle HTTP Server 12c (12.2.1)リリースから、これらのセクションの一部はコメントアウトされています。
ユースケースに合せて使用環境でのこの追加コンテンツを調整することができます。httpd.confファイルにアクセスするには、構成ファイルの編集についてを参照してください。
この項には次のトピックが含まれます:
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のドキュメントを参照してください。
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の実装です。 |
|
Solaris |
ロック・ファイルは必要ありません。プロセス間pthread mutexが、推奨されるプロセス間mutexの実装です。 |
|
その他のUNIXプラットフォーム |
|
|
UNIXソケットの問題 |
mod_cgidは、デフォルトでは有効になっていません。有効な場合は、 |
親トピック: 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
です。
Windowsの場合:
curl-ca-bundle.crt
という名前のファイルを作成します。curl-ca-bundle.crt
を、Windowsシステム・ディレクトリ(C:\windows\system32
など)、Windowsディレクトリ(C:\windows
など)、または%PATH%
に存在するディレクトリ(${PRODUCT_HOME}/bin
など)に配置します。- リモート・サーバーの証明書への署名に使用されるCA証明書チェーンを
curl-ca-bundle.crt
に追加します。
Solaris x64およびSolaris SPARCプラットフォームでは、cURLライブラリは、CA証明書が/etc/pki/tls/certs/ca-bundle.crt
で使用可能である必要があります。
バージョン12c (12.2.1.1.0)からは、Oracle HTTP Serverではmod_security
(バージョン2.9.0)のディレクティブ、変数、アクション、フェーズおよび関数をサポートしています。http://www.modsecurity.org/documentation.html
を参照してください。
サンプルmod_security.confファイルでは、LoadModule
文を含む、mod_security.conf
ファイルの使用可能な例について説明します。
ノート:
-
mod_security
は、以前のバージョンのOracle HTTP Serverで削除されましたが、バージョン11.1.1.7で再度搭載されました。このバージョンはオープン・ソースのmod_security
2.9.0で定められた推奨およびプラクティスに従っています。オープン・ソースのmod_security
2.9.0に適用可能なドキュメントのみが、モジュールのOracle HTTP Server実装にも適用できます。 -
Oracle HTTP Serverバージョン11.1.1.7以降では、
mod_security
はデフォルトではロードまたは構成されません。ただし、バージョン11.1.1.6からパッチ適用されたインストールがある場合、パッチの実装によりこのモジュールがすでにロードおよび構成されている場合があります。 -
Oracleでは、Oracle提供のバージョンの
mod_security
がサポートされています。modsecurity.org
提供の新しいバージョンはサポートされません。
mod_security
構成はhttpd.conf
構成ファイルに追加することも、別個のmod_security.conf
構成ファイルに表示することもできます。
この項には次の情報が含まれます:
- httpd.confファイルのmod_securityの構成
- mod_security.confファイルのmod_securityの構成
- mod_security.confファイルのSecRemoteRulesの構成
SecRemoteRulesは、リモート・サーバーからルールをロードするために使用できるオプションのディレクティブです。 - サンプル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モジュールの構成
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サーバーに送信します。次のヘッダーが使用されます。
任意のオプション |
yourserver.com |
yourserver.comは、 SecRemoteRulesディレクティブがサーバーS1上で構成されるとき、S1はyourserver.comとのSSL接続を確立してmod_securityルールをフェッチします。ここで、 SSLクライアントは、 使用しているストアに含まれないCAによって署名された証明書をサーバーが使用する場合、このCA証明書を既存のデフォルトのCA証明書ストアに追加します。Linux上の リモート・サーバー証明書をトラスト・ストアに追加するには、次の手順を実行します。
ファイルの最後に新しい行を追加しないでください。
|
親トピック: mod_securityモジュールの構成
サンプルmod_security.confファイル
次のコードは、サンプルのmod_security.conf構成ファイルを示しています。
例5-1 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モジュールの構成