test

Sun Java System Web Server 7.0 管理ガイド

第 7 章 サーバーへのアクセスの制御

Web サーバー上に存在するリソースは、認証、承認、アクセス制御など、いくつかのセキュリティーサービスおよび機構を使って保護できます。この章では、Sun Java System Web Server 7.0 へのアクセスを制御するためにサポートされているいくつかの機構について説明します。

アクセス制御とは

認証とは、識別情報を確認するためのプロセスのことです。承認とは、ある制限されたリソースへのアクセスをあるアイデンティティーに許可することを意味しますが、それらの制限はアクセス制御機構によって実現されます。認証と承認は、さまざまなセキュリティーモデル (Web アプリケーションセキュリティー、htaccess、認証レルムなど) やサービスを使って実現できます。

アクセス制御を使えば次のことを決定できます。

アクセス制御は、サーバーの全体、サーバーの一部、Web サイト上のファイルやディレクトリのいずれに対しても行えます。アクセスを許可または拒否するには、アクセス制御エントリ (ACE) と呼ばれる規則の階層を作成します。作成された ACE のコレクションは、アクセス制御リスト (ACL) と呼ばれます。

サーバーにはデフォルトで、複数の ACL を含む ACL ファイルが 1 つあります。Sun Java System Web Server は、受信要求に使用する仮想サーバーを決定したあと、その仮想サーバー用に構成された ACL の有無をチェックします。現在の要求に当てはまる ACL が見つかった場合、サーバーはそれらの ACL の ACE を評価することで、そのアクセスを許可すべきかどうかを決定します。

アクセスの許可または拒否は、次の情報に基づいて行われます。

アクセス制御のしくみ

サーバーは、あるページの要求を受信すると、ACL ファイル内の規則を使ってそのアクセスを許可すべきかどうかを決定します。規則は、要求を送信しているコンピュータのホスト名や IP アドレスを参照できます。また、規則が LDAP ディレクトリに格納されているユーザーやグループを参照するように設定することもできます。

注 –

一致する ACL が複数ある場合、サーバーは最後に一致した ACL 文を使用します。uri ACL が最後に一致する文であるため、default ACL は無視されます。

Sun Java System Web Server 7.0

上図は、Web Server 7.0 でのアクセス制御の処理手順を示したものです。ユーザーエージェント (クライアント) が Web Server にアクセスします。Web Server が obj.conf ファイル内の PathCheck 指令を実行します。Web Server が HTTP 401 (認証されない) をクライアントに返します。クライアントがユーザーに認証を要求します。クライアントがブラウザの場合、ログインダイアログボックスが表示されます。ユーザーがログイン情報を入力します。Web Server が内部 check-acl 関数を実行します。Web Server がユーザーの資格情報を検証し、要求を処理します。

ユーザー - グループに対するアクセス制御の設定

特定のユーザーまたはグループに対して、Web サーバーへのアクセスを制限することができます。ユーザー - グループのアクセス制御を設定した場合、サーバーにアクセスする前に、ユーザーはユーザー名とパスワードの入力を求められます。サーバーは、クライアント証明書内の情報をディレクトリサーバーのエントリと比較します。

管理サーバーでは、基本認証だけを使用します。管理サーバーでクライアント認証を要求する場合、ACL ファイルを手動で編集し、認証方法を SSL に変更する必要があります。

ユーザー - グループ認証は、Web Server がユーザーグループデータベース内のエントリを読み取ることによって実行されます。ディレクトリサービスがアクセス制御の実装に使用する情報は、次のソースのいずれかから入手できます。

サーバーは、外部 LDAP ベースのディレクトリサービスを使用するとき、サーバーインスタンスに対して次のタイプのユーザーグループ認証方法をサポートします。

サーバーが内部ファイルベースのディレクトリサービスを使用するときに、サーバーインスタンスに対してサポートされるユーザー - グループ認証方法には、次のものがあります。

ユーザー - グループ認証では、ユーザーがサーバーにアクセスしたり、Web サイト上のファイルやディレクトリにアクセスしたりするには、まず自身を認証する必要があります。認証を行う場合、ユーザーは、ユーザー名とパスワードを入力したりクライアント証明書を使用したりすることで、自身の身元を確認します。クライアント証明書が必要となるのは、SSL 通信を行う場合だけです。

デフォルト認証

デフォルト認証は、推奨される方法です。「標準」設定では、server.xml ファイル内のデフォルトの方法が使用されます。ただし、server.xml に設定が含まれていない場合は「基本」が使用されます。「デフォルト」を選択した場合、ACL 規則によって ACL ファイル内のメソッドが指定されることはありません。「標準」を選択すれば、obj.conf ファイル内で 1 行編集することですべての ACL の方法を簡単に変更できます。

基本認証

基本認証では、ユーザー名とパスワードを入力しないと、Web サーバーまたは Web サイトにアクセスできません。これがデフォルトの設定です。一連のユーザーとグループを作成し、それらを Sun Java System Directory Server などの LDAP データベース内またはファイル内に格納する必要があります。ディレクトリサーバーは、Web サーバーとは異なるサーバールートにインストールされたものか、リモートマシンにインストールされたものを使用する必要があります。

ユーザーが、管理サーバー内や Web サイト上のユーザー - グループ認証が必要なリソースにアクセスしようとすると、ユーザー名とパスワードの入力を求めるダイアログボックスが Web ブラウザによって表示されます。サーバーで暗号化が設定されているかどうかに応じて、サーバーはこの情報を暗号化された状態、または暗号化されていない状態で受信します。

注 –

SSL 暗号化なしで基本認証を使用する場合、暗号化されていないユーザー名とパスワードがネットワークを経由して送信されます。ネットワークパケットは傍受される可能性があり、ユーザー名とパスワードが不正に知られてしまう可能性があります。基本認証は、SSL 暗号化またはホスト - IP 認証、あるいはその両方と組み合わせるのがもっとも効果的です。ダイジェスト認証を使えばこの問題を回避できます。

SSL 認証

サーバーは、次の 2 つの方法で、セキュリティー証明書付きのユーザーの識別情報を確認できます。

クライアントの認証で証明書の情報を使用するようにサーバーを設定した場合、サーバーは次の処理を実行します。

特定のリソースへのアクセスを制御するためにクライアント認証を要求することは、サーバーへの接続のすべてに対してクライアント認証を要求することとは異なります。すべての接続に対してクライアント認証を要求するようにサーバーを設定した場合、クライアントは信頼できる CA によって発行された有効な証明書のみを提示する必要があります。SSL の方法を使ってユーザーとグループを認証するようにサーバーのアクセス制御を設定した場合、クライアントで次のことが必要になります。

アクセス制御でクライアント認証を要求する場合、Web サーバーの SSL 暗号化方式を有効にする必要があります。

SSL で認証されるリソースにアクセスするには、Web サーバーが信頼している CA から、クライアント証明書が発行されている必要があります。ブラウザのクライアント証明書とディレクトリサーバーのクライアント証明書を比較するように Web サーバーの certmap.conf ファイルが設定されている場合、クライアント証明書はディレクトリサーバーで発行されている必要があります。ただし、証明書から選択した情報とディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することもできます。たとえば、ブラウザ証明書のユーザー ID および電子メールアドレスとディレクトリサーバーのエントリだけを比較するように、certmap.conf ファイルを設定することができます。

注 –

SSL 認証方法の場合にのみ、certmap.conf ファイルを変更する必要があります。なぜなら、この方法では、LDAP ディレクトリに基づいて証明書がチェックされるからです。サーバーへのすべての接続に対してクライアント認証を要求する場合は、その必要はありません。クライアント証明書を使用することを選択する場合、magnus.conf の AcceptTimeout 指令の値を増やすべきです。

ダイジェスト認証

サーバーは、LDAP ベースまたはファイルベースのいずれかのディレクトリサービスを使用して、ダイジェスト認証を行うように設定できます。

ダイジェスト認証を使えば、ユーザー名とパスワードを平文として送信することなしに、ユーザー名とパスワードに基づく認証を行えます。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Web Server によって提供される情報の一部を使用するダイジェスト値を作成します。

サーバーが LDAP ベースのディレクトリサービスを使用してダイジェスト認証を行うとき、このダイジェスト値は、ダイジェスト認証プラグインを使用してサーバー側で計算され、クライアントによって提示されたダイジェスト値と比較されます。ダイジェスト値が一致した場合、ユーザーは認証されます。これが機能するには、ディレクトリサーバーが平文形式のユーザーのパスワードにアクセスできる必要があります。Sun Java System Directory Server にはリバーシブルパスワードプラグインが組み込まれています。このプラグインは、対称暗号化アルゴリズムを使用し、暗号化された形式にしてデータを格納し、あとで元の形式に復号化することができます。データへの鍵を持っているのは Directory Server だけです。

LDAP ベースのダイジェスト認証の場合、リバーシブルパスワードプラグインと、サーバーに組み込まれているダイジェスト認証専用のプラグインを有効にする必要があります。ダイジェスト認証を処理するように Web サーバーを構成するには、dbswitch.conf 内のデータベース定義の digestauth プロパティーを設定します。

ACL 方式を指定しない場合、認証が必要であればダイジェスト認証または基本認証のいずれかが使用され、認証が必要ない場合は基本認証が使用されます。これが推奨される方法です。

表 7–1 ダイジェスト認証要求の生成

ACL 方式 

認証データベースでダイジェスト認証がサポートされている 

認証データベースでダイジェスト認証がサポートされていない 

「標準」 

指定されていない 

ダイジェストと基本 

基本 

「基本」 

基本 

基本 

「ダイジェスト」 

ダイジェスト 

エラー 

method = digest を含む ACL を処理する場合、サーバーは次のようにして認証を試みます。

ホスト - IP に対するアクセス制御の設定

管理サーバーまたは Web サイト上のファイルとディレクトリに対して、特定のコンピュータを使用しているクライアントだけが利用できるように、アクセスを制限できます。許可または拒否するコンピュータのホスト名または IP アドレスを指定します。ワイルドカードパターンを使えば、複数のコンピュータやネットワーク全体を指定できます。ホスト - IP 認証経由でのファイルやディレクトリへのアクセスは、ユーザーにはシームレスに感じられます。このため、ユーザーは、ユーザー名やパスワードを入力することなく、すぐにファイルやディレクトリにアクセスできます。

ある特定のコンピュータを複数のユーザーが使用する可能性があるため、ホスト - IP 認証は、ユーザー - グループ認証と組み合わせると、より効果的です。両方の認証方法が使用されている場合、アクセス時にユーザー名とパスワードが必要になります。

ホスト - IP 認証の場合、サーバー上で DNS を構成する必要はありません。ホスト - IP 認証を使用することを選択した場合、ネットワーク内で DNS を稼働させ、その DNS を使用するようにサーバーを構成する必要があります。サーバーの DNS を有効にするには、サーバーマネージャーの「構成」タブの「パフォーマンス」ページを使用します。

DNS を有効にすると、サーバーで DNS 検索が強制的に実行されるため、サーバーのパフォーマンスが低下します。サーバーパフォーマンスへの DNS 検索の影響を減らすには、すべての要求で IP アドレスを解決するのではなく、アクセス制御および CGI でのみ IP アドレスを解決するようにします。それには、obj.conf ファイル内の AddLog fn="flex-log" name="access" に iponly=1 を追加します。

AddLog fn="flex-log" name="access" iponly=1

ACL ユーザーキャッシュの設定

サーバーはデフォルトで、ユーザーおよびグループ認証の結果を ACL ユーザーキャッシュに書き込みます。ACL ユーザーキャッシュの有効期間を制御するには、magnus.conf ファイル内の ACLCacheLifetime 指令を使用します。キャッシュ内のエントリが参照されるたびにその継続時間が計算され、ACLCacheLifetime に基づいてチェックされます。継続時間が ACLCacheLifetime に等しいかそれより大きい場合、そのエントリは使用されません。デフォルト値は 120 秒です。この値を 0 (ゼロ) に設定すると、キャッシュが無効になります。この値に大きな値を使用する場合、LDAP エントリを変更するたびにサーバーの起動が必要となる可能性があります。たとえば、この値を 120 秒に設定した場合は、サーバーと LDAP ディレクトリの同期が 2 分間にわたって取られない可能性があります。LDAP ディレクトリが頻繁に変更される可能性が低い場合にだけ、大きな値を設定します。

magnus.conf の ACLUserCacheSize パラメータを使用すると、キャッシュ内に保存できるエントリの最大数を設定できます。このパラメータのデフォルト値は 200 です。新しいエントリはリストの先頭に追加されます。キャッシュが最大サイズに達すると、リストの末尾のエントリは新しいエントリを作成するために再利用されます。

また、magnus.conf に含まれるパラメータである ACLGroupCacheSize を使用して、ユーザーエントリごとにキャッシュできるグループメンバーシップの最大数を設定することもできます。このパラメータのデフォルト値は 4 です。残念ながら、グループ内のユーザーの非メンバーシップはキャッシュに書き込まれないため、要求が発生するたびに数回の LDAP ディレクトリアクセスが発生します。

ACL ファイルの指令の詳細については、『NSAPI Developer’s Guide』を参照してください。

ACL キャッシュのプロパティーの設定

CLI 経由で ACL キャッシュのプロパティーを設定するには、次のコマンドを実行します。


wadm> set-acl-cache-prop --user=admin --password-file=admin.pwd --host=serverhost 
--port=8989 --config=config1 property=value

CLI リファレンスの set-acl-cache-prop(1) を参照してください。

設定できる有効なプロパティーは、次のとおりです。

アクセス制御の構成

サーバーは、ローカルに格納されたアクセス制御リスト (ACL) を使用することで、認証と承認をサポートします。ACL は、あるユーザーがあるリソースに対してどのようなアクセス権限を持つかを記述します。たとえば、ある ACL のエントリを使って、John という名前のユーザーに、特定のフォルダ misc に対する read アクセス権を許可することができます。

この節では、Web サイト上のファイルやディレクトリへのアクセスを制限するための手順について説明します。すべてのサーバーに対してグローバルアクセス制御規則を設定することも、特定のサーバーに対して個別に設定することもできます。たとえば、人事部門であれば、すべての認証済みユーザーが自分の給与データを参照できるが、そのデータを更新する機能へのアクセスは人事部門の給与担当者のみに制限するような ACL を作成できます。

サーバーがサポートするコア ACL では、3 種類の認証が使えます。基本、SSL、およびダイジェストです。

アクセス制御の設定を編集するには、次のタスクを実行します。

  1. 「構成」タブをクリックし、構成を選択します。

  2. 「セキュリティー」サブタブ>「アクセス制御」サブタブをクリックします。

  3. 「ACL を追加」ボタンをクリックして新しい ACL を追加するか、既存の ACL をクリックして設定を編集します。

アクセス制御リスト (ACL) の追加

次の節では、新しい ACL を構成に追加する手順について説明します。

  1. 「構成」タブをクリックし、構成を選択します。

  2. 「アクセス制御」サブタブ>「アクセス制御リスト (ACL)」サブタブをクリックします。

  3. 「新規」ボタンをクリックして新しい ACL を追加します。

下記のパラメータを設定します。

表 7–2 ACL パラメータ

パラメータ

説明

リソース

名前/URI/パス。アクセス制限を設定するリソースの種類を選択し、その値を指定します。URI リソースの例: — 「/sales」。パスリソースの例: — 「/usr/sun/server4/docs/cgi-bin/*」。 

認証データベース

「認証データベース」では、サーバーがユーザーの認証に使用するデータベースを選択できます。

デフォルトは keyfile です

認証方法

  1. 基本 — HTTP メソッドを使用してクライアントから認証情報を取得します。ユーザー名とパスワードがネットワーク上で暗号化されるのは、サーバーで SSL が有効になっている場合だけです。

  2. SSL — クライアント証明書を使用してユーザーの認証を行います。このメソッドを使用するには、サーバーの SSL を有効にする必要があります。暗号化が有効になっていれば、基本と SSL の方法を組み合わせることができます。

  3. ダイジェスト — ユーザー名とパスワードを平文として送信することなしにユーザー名とパスワードに基づく認証をブラウザが行うための手段を提供する認証機構を使用します。ブラウザは MD5 アルゴリズムを使用して、ユーザーのパスワードと Web Server によって提供される情報の一部を使用するダイジェスト値を作成します。「ダイジェスト」を使用するには、背後の auth-db もダイジェストをサポートしている必要があります。これは、ダイジェスト認証プラグインがインストールされている場合にのみ、digestfile を使用したファイル auth-db、LDAP auth-db のいずれかを意味します

  4. その他 — アクセス制御 API を使って作成されたカスタム方法を使用します。

認証確認テキスト

「認証確認テキスト」オプションでは、認証ダイアログボックス内に表示されるメッセージテキストを入力できます。このテキストを使用して、ユーザーが入力する必要のある項目について説明することができます。ブラウザによっては、最初の 40 文字程度しか表示されません。

Web ブラウザは通常、ユーザー名とパスワードをキャッシュし、それらをプロンプトのテキストと関連付けます。ユーザーが、サーバーの同じ確認テキストを持つファイルやディレクトリにアクセスしても、ユーザー名とパスワードを再度入力する必要はありません。特定のファイルやディレクトリでユーザーに再度認証させたい場合は、そのリソースの ACL の確認テキストを変更すればよいだけです。 

アクセス拒否時の応答

あるリソースへのアクセスが拒否された場合の応答アクションを指定します。 

1. デフォルトメッセージで応答 — サーバーから標準のアクセス拒否メッセージを表示する場合に、このオプションを選択します。 

2. URL で応答 — ほかの外部 URL やエラーページに要求を転送する場合に、このオプションを選択します。 

注 –

CLI の使用

CLI 経由で ACL を追加するには、次のコマンドを実行します。


wadm> set-acl --user=admin --password-file=admin.pwd 
--host=serverhost --port=8989 --vs=config1_vs_1 --config=config1 
--aclfile=aclfile1

CLI リファレンスの set-acl(1) を参照してください。

アクセス制御エントリ (ACE) の追加

この節では、選択された構成に対して新しいアクセス制御エントリ (ACE) を追加するプロセスについて説明します。

  1. 「構成」タブをクリックし、構成を選択します。

  2. 「アクセス制御」サブタブ>「アクセス制御リスト (ACL)」サブタブをクリックします。

  3. 「新規」ボタンをクリックします。

  4. 「アクセス制御エントリ (ACE)」の「新規」ボタンをクリックします。

次の ACE パラメータを設定します。

表 7–3 ACE パラメータ

パラメータ

説明

アクセス権

  • 許可する ユーザーまたはシステムが、要求されたリソースにアクセスできることを意味します

  • 許可しない ユーザーまたはシステムが、要求されたリソースにアクセスできないことを意味します

    サーバーはアクセス制御エントリ (Access Control Entry、ACE) のリストを参照して、アクセス権を決定します。

ユーザー

1.すべて (認証なし) — 認証は行われません。すべてのユーザーにアクセスを許可します。

2. 認証データベース中のすべて — 認証データベース内に指定されたすべてのユーザーにアクセスを許可します。

3. 認証データベース中の以下だけ — 認証データベースから選択されたユーザーだけにアクセスを制限します。

認証データベースに対するクエリーを、名、姓、電子メールアドレスなどの共通属性に基づいて実行できます。 

グループ

グループの認証が行われる場合、ユーザーがアクセス制御規則で指定されているリソースにアクセスするには、ユーザー名とパスワードを入力する必要があります。 

特定のグループにアクセスを制限する場合に、このオプションを使用します。 

アクセスを許可するホスト

どのコンピュータから要求が送られたかに基づいて、管理サーバーまたは Web サイトへのアクセスを制限できます。 

  • 「すべて」では、すべてのユーザーとシステムに対してアクセスを許可します

  • 「次の転送元からのみ」では、特定のホスト名または IP アドレスへのアクセスが制限できます

「次の転送元からのみ」オプションを選択する場合は、「ホスト名」フィールドまたは「IP アドレス」フィールドに、ワイルドカードパターンまたはコンマで区切ったリストを入力します。IP アドレスよりホスト名で制限する方が、より柔軟にできます。ユーザーの IP アドレスが変更された場合でも、このリストを更新する必要がありません。ただし、IP アドレスで制限する方が、より確実です。接続したクライアントの DNS 検索が失敗した場合、ホスト名による制限が使用できないためです。 

コンピュータのホスト名または IP アドレスに一致するワイルドカードパターン用として使用できるのは、* ワイルドカード記号だけです。たとえば、指定ドメインのすべてのコンピュータに対してアクセスを許可または拒否する場合、 *.sun.com のように、特定ドメイン内のすべてのホストと一致するワイルドカードパターンを指定します。管理サーバーにアクセスするスーパーユーザーに対しては、その他のユーザーとは異なるホスト名と IP アドレスを設定することができます。

ホスト名の場合、* は名前の構成要素全体を表している必要があります。つまり、*.sun.com は許容されますが、*users.sun.com は許容されません。* がホスト名に含まれる場合、それは左端の文字でなければいけません。

たとえば、*.sun.com は許容されますが、users.*.com は許容されません。IP アドレスの場合、* はアドレスのバイト全体を表している必要があります。たとえば、198.95.251.* は許容されますが、198.95.251.3* は許容されません。IP アドレスで * を使用する場合、この記号は文字列の一番右に使用する必要があります。たとえば、198.* は許容されますが、198.*.251.30 は許容されません。

権限

アクセス権は、Web サイトのファイルやディレクトリへのアクセスを制限します。すべてのアクセス権の許可または拒否に加えて、一部のアクセス権の許可または拒否を行うための規則を指定することもできます。たとえば、ユーザーに対してファイルへの読み取り専用アクセスを許可することができます。この設定では、ユーザーは情報を表示することはできますが、ファイルを変更することはできません。 

  • 「すべてのアクセス権限」はデフォルトで、すべてアクセス権を許可または拒否します。

  • 「次の権限のみ」では、許可または拒否するアクセス権の組み合わせを選択できます。

    • 「読み込み」を選択すると、ユーザーはファイルを表示できます。これには HTTP メソッド GET、HEAD、POST、および INDEX が含まれます

    • 「書き込み」を選択すると、ユーザーはファイルを変更または削除できます。これには、HTTP メソッド PUT、DELETE、MKDIR、RMDIR、および MOVE.が含まれます。ファイルを削除するには、ユーザーは書き込み権限と削除権限の両方を持っている必要があります

    • 「実行」を選択すると、ユーザーは CGI プログラム、Java アプレット、エージェントなどのサーバー側アプリケーションを実行できます

    • 「削除」を選択すると、書き込み特権も持つユーザーがファイルやディレクトリを削除できます。

    • 「リスト」を選択すると、ユーザーは、index.html ファイルを含んでいないディレクトリ内のファイルのリストにアクセスできます。

    • 「情報」を選択すると、ユーザーは、http_head などの URI に関する情報を受け取れます。

継続

サーバーはアクセス制御エントリ (Access Control Entry、ACE) のリストを参照して、アクセス権を決定します。たとえば、最初の ACE は通常、すべてのユーザーを拒否します。最初の ACE に「継続」が設定されている場合、サーバーはリストの 2 番目の ACE を確認し、一致している場合は、次の ACE を使用します。 

「継続」チェックボックスが選択されていない場合は、すべてのユーザーがリソースへのアクセスを拒否されます。サーバーは、一致しない ACE か、一致しているが継続しないように設定されている ACE のどちらかに到達するまでリストを参照し続けます。一致する最後の ACE によって、アクセスが許可されるか拒否されるかが決まります。

.htaccess ファイルの使用

サーバーは、.htaccess 動的構成ファイルをサポートします。.htaccess ファイルを有効にするには、ユーザーインタフェースを使用するか、構成ファイルを手動で変更します。

.htaccess ファイルは、サーバーの標準アクセス制御と組み合わせて使用できます。標準アクセス制御は常に、PathCheck 指令の順序にかかわらず、あらゆる .htaccess アクセス制御の前に適用されます。ユーザー - グループ認証が「基本」の場合、標準アクセス制御と .htaccess アクセス制御の両方を使ってユーザー認証を要求しないでください。サーバーの標準アクセス制御経由で SSL クライアント認証を使用し、さらに .htaccess ファイル経由で HTTP「基本」認証を要求することは可能です。

.htacess ファイルを使用可能にすると、サーバーはリソースを提供する前に、.htaccess ファイルを確認します。サーバーはリソースと同じディレクトリおよびそのディレクトリの親ディレクトリで .htaccess ファイルを検索します。この検索はドキュメントのルートまで続けられます。たとえば「Primary Document Directory」が /sun/server/docs に設定されているときに、クライアントが /sun/server/docs/reports/index.html を要求すると、サーバーは /sun/server/docs/reports/.htaccess および /sun/server/docs/.htaccess を確認します。

サーバーの「Addtional Document Directories」および「CGI Directory」機能で、管理者は代わりのドキュメントルートを定義できます。代わりのドキュメントルートが存在すると、.htaccess ファイルの処理に影響します。たとえば、サーバーの「Primary Document Directory」が /sun/server/docs に設定されていて、CGI プログラムが /sun/server/docs/cgi-bin/program.cgi にあるとします。CGI を「File Type」として有効にした場合、クライアントが CGI プログラムに要求を発行すると、サーバーは /sun/server/docs/.htaccess と /sun/server/docs/cgi-bin/.htaccess の両方の内容を評価します。しかし、「CGI Directory」として /sun/server/docs/cgi-bin を設定すると、サーバーは /sun/server/docs/cgi-bin/.htaccess は検査しますが、/sun/server/docs/.htaccess は検査しません。これは、「CGI Directory」で /sun/server/docs/cgi-bin を指定したことで、代替のドキュメントルートとしてマークされたためです。

サービス拒否攻撃からのサーバーの保護

サービス拒否 (DoS) 攻撃とは、サーバーの悪意のあるユーザーが故意に、正当なユーザーのサービス利用を妨害しようとすることです。そのような攻撃は、次の操作によって実現されます。

Sun Java System Web Server は、要求の発生頻度が非常に高い場合に、頻繁にアクセスされる URI を監視して要求を拒否することにより、DoS 攻撃を検出できます。

次の各節では、仮想サーバーレベルで DoS 攻撃を防ぐ方法について説明します。

サーバーへの要求の制限

今回、サーバーを調整することでサービス拒否攻撃を防止できるようになりました。具体的には、要求の制限を構成し、仮想サーバーごとの最大接続数を監視します。これらの値のいくつかを構成すると、サーバーのパフォーマンスに影響が及ぶ可能性があります。

サーバーの要求の制限を構成するには、「構成」>「仮想サーバー」>「サーバー設定」>「要求の制限」をクリックします。次の表に記載したパラメータを構成します。

表 7–4 要求の制限の構成

パラメータ

説明

要求の制限

この仮想サーバーで要求の制限を有効化/無効化します。要求の制限オプションはデフォルトで無効になっています。 

最大接続数

この仮想サーバーで許可する最大同時接続数。 

最大 RPS

1 クライアントに許可される 1 秒あたりの最大要求数。 

RPS 計算間隔

秒あたりの平均要求数 (RPS) が計算される時間間隔。デフォルト値は 30 秒です。 

継続条件

ブロックされた要求タイプが再度サービスを受けられるようになるために満たす必要のある条件を決定します。 

サイレンス — サービスが再開するには、拒否された要求の数が後続の期間内でゼロまで落ちる必要があります。

しきい値 — サービスが再開するには、拒否された要求の発生頻度が低下して RPS のしきい値を下回る必要があります。

デフォルト値は「しきい値」です。 

エラーコード

ブロックされた要求に使用する HTTP 状態コード。デフォルトのコードは、HTTP 503 (サービス利用不可) です。 

属性の監視

省略可能な監視対象の要求属性。 

注 –

CLI の使用

CLI 経由でサーバーへの要求を制限するには、次のコマンドを実行します。


wadm> enable-request-limits --user=admin --password-file=admin.pwd 
--host=serverhost --port=8989 --config=config1 --vs=config1_vs_1

CLI リファレンスの enable-request-limits(1) を参照してください。

Procedure最大接続数を制限する

最大同時接続数を制限できます。処理中の要求が少なくとも指定された数だけ存在している状態で、一致する要求が受信されると、その要求は拒否されます。要求が拒否されるのはその特定の期間内だけである点に注意してください。同時要求数が低下してこの制限を下回るようになると、新しい要求が処理されます。

  1. 「構成」タブをクリックします。

  2. リストから構成を選択します。

  3. 「仮想サーバー」タブで仮想サーバーを選択します。

  4. 「サーバー設定」>「要求の制限」をクリックします。

  5. 「最大接続数」セクションに値を入力します。