| Oracle® Fusion Middleware Oracle HTTP Serverの管理 12c (12.1.3) E56227-07 |
|
 前 |
 次 |
この付録では、Oracle HTTP Server (OHS)に関するよくある質問とそれに対する回答について説明します。内容は次のとおりです。
該当する場合は、Apache Software Foundationのドキュメントを参照しています。
|
注意: このガイドをPDF版またはハード・コピー形式でご利用いただく場合、HTML形式でのみのご提供となるサードパーティのドキュメントを参照できません。文中で参照されているサードパーティのドキュメントをご利用いただくためには、このガイドのHTML版をご利用のうえ、文中のハイパーリンクをクリックしてください。 |
Oracle HTTP Serverには、エラー処理用のデフォルトのコンテンツ・ハンドラが用意されています。ErrorDocumentディレクティブを使用すると、デフォルトをオーバーライドできます。
HTTPの場合、Oracle HTTP Serverでは、名前ベースとIPベースの両方の仮想ホストがサポートされます。名前ベースの仮想ホストは共通のリスニング・アドレス(IPとポートの組合せ)を共有する仮想ホストですが、クライアントにより送信されたHostヘッダーとVirtualHost内のServerNameディレクティブの間の一致に基づいてリクエストをルーティングします。IPベースの仮想ホストは、固有のリスニング・アドレスを持つ仮想ホストです。IPベースの仮想ホストは、リクエストが受信されたアドレスに基づいてリクエストをルーティングします。
HTTPSの場合、Oracle HTTP Serverで使用できるのはIPベースの仮想ホストのみです。これは、名前ベースの仮想ホストの場合、リクエストの処理に使用する仮想ホストを判別するために、リクエストを読み取って調査する必要があるためです。HTTPSが使用されている場合、リクエストを読み取る前にSSLハンドシェイクを実行する必要があります。SSLハンドシェイクを実行するためには、サーバー証明書を提供する必要があります。意味のあるサーバー証明書を提供するには、証明書のホスト名が、クライアントがリクエストしたホスト名に一致する必要があります。これは、仮想ホストごとにサーバー証明書が一意であることを意味します。しかし、サーバーはリクエストを読み取るまで、そのリクエストのルーティング先の仮想ホストを認識できず、また提供するサーバー証明書がわからなければリクエストを適切に読み取ることもできないため、HTTPSでは名前ベースの仮想ホスティングを行うことは不可能です。
使用できます。Apache HTTP Serverの機能に与えられた汎用名であるMultiviewsを使用すると、リクエストに対するレスポンスで様々なバージョンの言語と文字固有のドキュメントを提供できます。
|
関連項目: コンテント・ネゴシエーションの詳細は、次のApache HTTP ServerのドキュメントのMultiviewsオプションを参照してください。
|
次の理由で、Oracle HTTP ServerにはApache HTTP Serverセキュリティ・パッチを適用できません。
OracleではOracle HTTP Serverユーザーにリリースする前に、セキュリティ・パッチをテストして適切に変更しています。
Oracleではセキュリティ・パッチのコンポーネントをスタックから削除しているため、多くの場合、OpenSSLアラートなどのApache HTTP Serverアラートは適用できません。
Oracle HTTP Serverに対するセキュリティ関連の最新の修正は、Oracle Critical Patch Update (CPU)を介して実行します。詳細は、OracleのWebページ「Critical Patch Updates and Security Alerts」を参照してください。
|
注意: CPUを適用した後、Apache HTTP Serverベースのバージョンがそのまま残っていることがありますが、脆弱性は修正されます。バージョンを確認できるサード・パーティのセキュリティ検出ツールがありますが、これらのツールで脆弱性そのものを確認することはできません。 |
Oracle HTTP Server内のApache HTTP Serverバージョンのみをアップグレードすることはできません。Oracle HTTP ServerのベースとなるApache HTTP Serverの新バージョンが、パッチ更新またはOracle Fusion Middlewareの次期メジャー・リリースかマイナー・リリースの一部として提供されます。
一般に、Oracle HTTP Serverに組み込まれているmod_deflateを使用することをお薦めします。mod_deflateに関する詳細は、http://httpd.apache.org/docs/current/mod/mod_deflate.htmlを参照してください。
一般的には、1つの分散Webサイトの全サーバーで、単一のURLネームスペースを使用する必要があります。すべてのサーバーでネームスペースの一部を処理し、処理しないURLのリクエストをそのURLにより近いサーバーにリダイレクトまたはプロキシできます。たとえば、次のようなネームスペースがあるとします。
/app1/login.html /app1/catalog.html /app1/dologin.jsp /app2/orderForm.html /apps/placeOrder.jsp
最初に、server1にapp1、server2にapp2を置いて、これらのネームスペースを2つのWebサーバーにマップします。server1の構成は次のようになります。
Redirect permanent /app2 http://server2/app2 Alias /app1 /myApps/application1 <Directory /myApps/application1> ... </Directory>
server2の構成は補足的です。
ネームスペースをコンテンツ・タイプ(server1ではHTML、server2ではJSP)別にパーティション化すると決定した場合、サーバー構成を変更してファイルを移動できますが、アプリケーション自体を変更する必要はありません。その結果、server1の構成は次のようになります。
RedirectMatch permanent (.*) \.jsp$ http://server2/$1.jsp AliasMatch ^/app(.*) \.html$ /myPages/application$1.html <DirectoryMatch "^/myPages/application\d"> ... </DirectoryMatch>
実際のリダイレクションの量は、ハードウェアのロード・バランサ(F5システムのBIG-IPなど)を、URLに基づいてserver1またはserver2にリクエストが送信されるように構成することで、最小限に抑えることが可能です。
ハッカーによる攻撃は多く、日々新しい攻撃が開発されています。サイトの保護に関する一般的なガイドラインは、次のとおりです。サイトを完全に保護することはできませんが、攻撃されさやすいターゲットとなることは回避できます。
ISPとWebサーバーの間に、Checkpoint FW-1やCisco PIXのような市販のファイアウォールを使用します。ただし、すべてのハッカーが組織の外にいるわけではないことに注意してください。
切替式のイーサネットを使用して、セキュリティを破られたサーバーにより検出される可能性のある通信量を制限します。Webサーバー・マシンと、データベースやエンタープライズ・アプリケーションを実行中の機密性の高い内部サーバーの間に、追加のファイアウォールを使用します。
RPC、Finger、telnetなど、不要なネットワーク・サービスをサーバーから削除します。
Webフォームからのすべての入力を慎重に検証します。特に、長い入力文字列や、印刷不能文字、HTMLタグまたはJavaScriptタグを含む入力には注意してください。
機密情報を含むCookieの内容を暗号化(ランダム化)して、ハッカーによる有効なセッションのハイジャックを防止します。たとえば、有効なセッションIDを推測しにくくする必要があります。
すべてのシステムとアプリケーション・ソフトウェアのセキュリティ・パッチを頻繁にチェックし、入手後すぐにインストールします。これらのパッチは必ず信頼できるソースから入手してください。パッチは信頼できるサイトからのみダウンロードし、暗号チェックサムを検証します。
侵入検出パッケージを使用して、改変されたWebページ、ウイルスおよびハッカーがサイトに侵入したことを示すrootkitの有無をモニターします。可能な場合は、システムの実行可能ファイルとWebのコンテンツを読取り専用ファイル・システムにマウントしてください。
法的分析パッケージを用意して、侵入が検出されたらすぐにその証拠を取得します。これは、ハッカーを告発する際に役立ちます。
アプリケーションに対して侵入テストやその他の適切なセキュリティ・テストを実行します。アプリケーションを保護するために適切なカスタムmod_securityルールを構成します。mod_securityの詳細は、5.4項「mod_securityの構成」および9.6項「mod_securityの使用」を参照してください。
オープン・ソースのOpen Web Application Security Project (OWASP)ベースのコア・ルール・セットを使用する場合、このルール・セットがOracle HTTP Serverに含まれるmod_securityのバージョンに対応することを確認する必要があります。コア・ルール・セットは一般的なルール・セットのみを提供し、あまりアプリケーション固有のものではありません。このため、コア・ルール・セットではアプリケーションを適切に保護できない場合があります。OWASPコア・ルール・セットの詳細は、次のURLを参照してください。
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
httpd.confファイルから不要なコンテンツを削除します。詳細は、5.3.6項「不要なコンテンツへのアクセス権の削除」を参照してください。
Webページをクリックジャック攻撃から保護するための予防措置を講じます。インターネットには多くの使用可能な参考情報があります。クリックジャックの詳細は、Oracle DatabaseおよびFusion Middlewareのセキュリティ脆弱性に関するFAQ (Doc ID 1074055.1)のセキュリティのベスト・プラクティスに関する項を参照してください。
Apache HTTP Serverとの互換性によって、この条件でのCGIおよび他のアプリケーションで、この情報を使用可能にしていないため、Oracle HTTP Serverでは、REDIRECT_ERROR_NOTES CGI環境変数は「ファイルが見つかりません」というエラーに設定されていません。
この情報をWebサーバーで生成されたレスポンスから削除するには、ServerSignature Offを指定します。Oracle HTTP ServerがWebサーバー・レスポンス・ヘッダーを生成したときにWebサーバー・ソフトウェアを非表示にするには、ServerTokens Custom some-server-stringを指定します。(バックエンド・サーバーがレスポンスを生成するときは、プロキシ・メカニズムに応じてバックエンド・サーバーからサーバー・レスポンス・ヘッダーが生成される場合があります。)
|
注意: ServerTokens Custom some-server-stringは、Oracle HTTP Server 10gのServerHeader Off設定の置換文字列です。 |
Oracle HTTP Server 12c (12.1.3)のプロセス管理はノード・マネージャによって処理されます。startComponentコマンドを使用して、WLSTまたはFusion Middleware Controlを直接使用せずに、Oracle HTTP Serverを起動することができます。詳細は、4.3.2.3項「コマンド行を使用したOracle HTTP Serverインスタンスの起動」を参照してください。
