Cisco ASDM ユーザ ガイド バージョン 6.0(3)

認証の概要

セキュリティ アプライアンスでは、AAA サーバを使用するネットワーク アクセス認証を設定できます。この項では、次のトピックについて取り上げます。

• 「一度だけの認証」

• 「認証確認を受けるために必要なアプリケーション」

• 「セキュリティ アプライアンスの認証プロンプト」

• 「スタティック PAT および HTTP」

• 「Web クライアントのセキュアな認証」

一度だけの認証

所定の IP アドレスのユーザは、認証セッションが期限切れになるまで、すべてのルールおよびタイプに対して一度だけ認証を受ける必要があります （タイムアウト値については、「グローバル タイムアウトの設定」を参照してください）。たとえば、セキュリティ アプライアンスに Telnet と FTP の認証を設定した場合、最初に Telnet の認証に成功したユーザは、その認証セッションが存在する限り、FTP の認証を受ける必要がありません。

認証確認を受けるために必要なアプリケーション

プロトコルまたはサービスへのネットワーク アクセス認証を要求するようにセキュリティ アプライアンスを設定することは、すべてのプロトコルまたはサービスについて可能ですが、ユーザが直接認証を受けることができるのは、HTTP、HTTPS、Telnet、または FTP だけです。ユーザがこれらのサービスのいずれかの認証を受けないと、セキュリティ アプライアンスは認証が必要な他のトラフィックを許可しません。

セキュリティ アプライアンスが AAA 用にサポートしている認証ポートは固定値です。

• ポート 21 は FTP 用

• ポート 23 は Telnet 用

• ポート 80 は HTTP 用

• ポート 443 は HTTPS 用

セキュリティ アプライアンスの認証プロンプト

Telnet および FTP の場合、セキュリティ アプライアンスは認証プロンプトを生成します。

HTTP の場合、セキュリティ アプライアンスはデフォルトで基本 HTTP 認証を使用し、認証プロンプトを提供します。オプションで、ユーザがユーザ名とパスワードを入力できる内部 Web ページにユーザをリダイレクトするようにセキュリティ アプライアンスを設定することもできます（「高度な AAA 機能の設定」を参照）。

HTTPS の場合、セキュリティ アプライアンスはカスタム ログイン画面を生成します。オプションで、ユーザがユーザ名とパスワードを入力できる内部 Web ページにユーザをリダイレクトするようにセキュリティ アプライアンスを設定することもできます（「高度な AAA 機能の設定」を参照）。

リダイレクションは、基本方式を強化したものです。これは、認証時に向上したユーザ エクスペリエンスが提供されると同時に、Easy VPN でもファイアウォール モードでも、HTTP および HTTPS と同じユーザ エクスペリエンスが提供されるためです。また、セキュリティ アプライアンスでの直接認証もサポートしています。

基本 HTTP 認証を使用し続けた方がよい場合もあります。セキュリティ アプライアンスでリスニング ポートを開く必要がない場合や、ルータ上の NAT を使用しているため、セキュリティ アプライアンスで提供される Web ページの変換ルールを作成する必要がない場合、あるいは基本 HTTP 認証の方がネットワークで効果的に機能する場合です。たとえば、電子メールに URL が埋め込まれている場合などのように、ブラウザ以外のアプリケーションでは基本認証の方が適していることがあります。

正常に認証されると、セキュリティ アプライアンスにより元の宛先にリダイレクトされます。宛先サーバにも独自の認証がある場合、ユーザは別のユーザ名とパスワードを入力します。基本 HTTP 認証を使用していて、宛先サーバ用に別のユーザ名とパスワードを入力する必要がある場合は、仮想 HTTP を設定する必要があります（ 「仮想アクセスの設定」 を参照） 。

（注） HTTP 認証を使用する場合、デフォルトでクリア テキストのユーザ名とパスワードがクライアントからセキュリティ アプライアンスに送信されます。さらにこのユーザ名とパスワードは宛先 Web サーバにも送信されます。クレデンシャルの保護の詳細については、「Web クライアントのセキュアな認証」を参照してください。

FTP の場合、セキュリティ アプライアンス ユーザ名、アット マーク（@）、FTP ユーザ名（name1@name2）を入力するオプションがあります。パスワードには、セキュリティ アプライアンス パスワード、アット マーク（@）、FTP パスワード（password1@password2）を入力します。たとえば、次のテキストを入力します。

この機能は、複数のログインを必要とするファイアウォールをカスケード接続している場合に有用です。複数の名前およびパスワードは、複数のアット マーク（@）で区切ることができます。

スタティック PAT および HTTP

HTTP 認証では、スタティック PAT が設定されている場合、セキュリティ アプライアンスは実際のポートをチェックします。セキュリティ アプライアンスは、マッピング ポートにかかわらず、実際のポート 80 を宛先とするトラフィックを検出した場合、HTTP 接続を代行受信し、認証を実行します。

たとえば、外部 TCP ポート 889 が次のようにポート 80（www）に変換されていて、関係するすべてのアクセス ルールでこのトラフィックが許可されているとします。

この場合、ユーザはポート 889 で 10.48.66.155 にアクセスを試み、セキュリティ アプライアンスはそのトラフィックを代行受信して、HTTP 認証を実行します。セキュリティ アプライアンスが HTTP 接続の完了を許可する前に、ユーザの Web ブラウザには HTTP 認証ページが表示されます。

ローカル ポートがポート 80 ではない場合、ユーザには認証ページは表示されません。代わりに、セキュリティ アプライアンスは Web ブラウザにエラー メッセージを送信して、要求されたサービスを使用する前にユーザが認証を受ける必要があることを通知します。

Web クライアントのセキュアな認証

HTTP 認証を使用する場合、デフォルトでクリア テキストのユーザ名とパスワードがクライアントからセキュリティ アプライアンスに送信されます。さらにこのユーザ名とパスワードは宛先 Web サーバにも送信されます。セキュリティ アプライアンスでは、次のような複数の方式で HTTP 認証を保護できます。

• リダイレクション方式による HTTP 認証：詳細については、「インタラクティブ認証ルールの追加」を参照してください。この方式では、認証クレデンシャルがその後続けて宛先サーバに送信されないようにします。

• 仮想 HTTP をイネーブルにする：「仮想 HTTP の設定」を参照して、セキュリティ アプライアンスの認証と HTTP サーバの認証を別々に受けることができます。HTTP サーバが 2 次認証を必要としない場合でも、このコマンドにより基本認証クレデンシャルは HTTP GET 要求から除去されます。

• Web クライアントとセキュリティ アプライアンスとの間の HTTPS によるユーザ名とパスワードの交換をイネーブルにする：「HTTPS を使用した HTTP 認証のクレデンシャルの交換」を参照して、Web クライアントとセキュリティ アプライアンスとの間の HTTPS によるユーザ名とパスワードの交換をイネーブルにします。これはセキュリティ アプライアンスと宛先サーバの間だけでなく、クライアントとセキュリティ アプライアンスの間のクレデンシャルを保護する唯一の方式です。この方式だけを使用することも、または他の方式のいずれかと組み合わせてセキュリティを最大限にすることもできます。

ネットワーク アクセス認証のイネーブル化

ネットワーク アクセス認証をイネーブルにするには、次の手順を実行します。

ステップ 1 「AAA サーバおよびユーザ アカウントの設定」に従って、AAA サーバ グループを設定します。

ステップ 2 [Configuration] > [Firewall] > [AAA Rules] ペインから、[Add] > [Add Authentication Rule] を選択します。

[Add Authentication Rule] ダイアログボックスが表示されます。

ステップ 3 [Interface] ドロップダウン リストから、ルールを適用するインターフェイスを選択します。

ステップ 4 [Authenticate] または [Do not Authenticate] をクリックします。

10.1.1.50 を除く 10.1.1.0/24 を認証する場合、2 つのルール（1 つには [Authenticate] オプションを使用、もう 1 つには [Do not Authenticate] オプションを使用）を作成します。ルールは必ず適切な順序に並べてください。たとえば、上記の [Do not Authenticate] ルールを [Authenticate] ルールよりも上に置き、10.1.1.50 からのトラフィックが最初に [Do not Authenticate] ルールに一致するようにします。

ステップ 5 [AAA Server Group] ドロップダウン リストから、サーバ グループまたは LOCAL ユーザ データベースを選択します。

ステップ 6 （任意）AAA サーバをサーバ グループに追加するには、[Add Server] をクリックします。ユーザを LOCAL データベースに追加するには、[Add User] をクリックします。

サーバ グループとローカル ユーザ データベースの設定の詳細については、「AAA サーバおよびユーザ アカウントの設定」を参照してください。

ステップ 7 [Source] フィールドで、送信元 IP アドレスを入力するか、[...] ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の送信元アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 8 [Destination] フィールドで、宛先 IP アドレスを入力するか、[...] ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の宛先アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 9 [Service] フィールドで、宛先サービスの IP サービス名または番号を入力するか、[...] ボタンをクリックしてサービスを選択します。

TCP または UDP のポート番号、あるいは ICMP サービス番号を指定する場合は、 プロトコル / ポート を入力します。たとえば、TCP/8080 と入力します。

デフォルトでは、サービスは TCP です。

サービスが複数ある場合はカンマで区切ります。

HTTP、HTTPS、Telnet、または FTP のいずれかの宛先ポートを必ず含めます。これは、ユーザがこれらのサービスのいずれかの認証を受けないと、他のサービスがセキュリティ アプライアンスの通過を許可されないためです。

ステップ 10 （任意）[Description] フィールドに説明を入力します。

ステップ 11 （任意）TCP または UDP の送信元サービスを指定するには、[More Options] 領域をクリックして開き、[Source Service] フィールドに TCP サービスまたは UDP サービスを入力します。

宛先サービスと送信元サービスは同じである必要があります。[Destination Service] フィールドをコピーし、[Source Service] フィールドに貼り付けます。

ステップ 12 （任意）ルールを非アクティブにするには、[More Options] 領域をクリックして開き、[Enable Rule] をオフにします。

この設定は、ルールを削除せずに無効にしたい場合に便利です。

ステップ 13 （任意）ルールの時間範囲を指定するには、[More Options] 領域をクリックして開き、[Time Range] ドロップダウン リストから時間範囲を選択します。

新しい時間範囲を追加するには、[...] ボタンをクリックします。詳細については、「時間範囲の設定」を参照してください。

この設定は、事前に設定した時間にだけルールをアクティブにする場合に便利です。

ステップ 14 [OK] をクリックします。

TACACS+ 許可の設定

TACACS+ でネットワーク アクセス許可を実行するように、セキュリティ アプライアンスを設定できます。

認証ルールと許可ルールは相互に独立したものですが、許可ルールで一致した未認証トラフィックはすべて拒否されます。ユーザが許可を受けるには、まずセキュリティ アプライアンスに認証される必要があります。認証セッションが期限切れになっていない場合、所定の IP アドレスを持つユーザが認証を受ける必要があるのは、すべてのルールおよびタイプで 1 回だけです。このため、トラフィックが認証ステートメントに一致した場合でも許可が発生する可能性があります。

ユーザの認証が完了すると、セキュリティ アプライアンスは、一致するトラフィックの許可ルールをチェックします。トラフィックが許可ルールに一致した場合は、セキュリティ アプライアンスによりユーザ名が TACACS+ サーバに送信されます。TACACS+ サーバはセキュリティ アプライアンスに応答し、ユーザ プロファイルに基づいてそのトラフィックの許可または拒否を示します。セキュリティ アプライアンスは、その応答内の許可ルールを実施します。

ユーザに対するネットワーク アクセス許可の設定については、ご使用の TACACS+ サーバのマニュアルを参照してください。

TACACS+ 許可を設定するには、次の手順を実行します。

ステップ 1 許可するトラフィックの認証をイネーブルにします。詳細については、「ネットワーク アクセス認証の設定」を参照してください。すでに認証をイネーブルにしてある場合は、次の手順に進みます。

ステップ 2 [Configuration] > [Firewall] > [AAA Rules] ペインから、[Add] > [Add Authorization Rule] を選択します。

[Add Authorization Rule] ダイアログボックスが表示されます。

ステップ 3 [Interface] ドロップダウン リストから、ルールを適用するインターフェイスを選択します。

ステップ 4 [Authorize] または [Do not Authorize] をクリックします。

たとえば、10.1.1.50 を除く 10.1.1.0/24 を許可する場合、2 つのルール（1 つには [Authorize] オプションを使用、もう 1 つには [Do not Authorize] オプションを使用）を作成します。ルールは必ず適切な順序に並べてください。たとえば、上記の [Do not Authorize] ルールを [Authorize] ルールよりも上に置き、10.1.1.50 からのトラフィックが最初に [Do not Authorize] ルールに一致するようにします。

ステップ 5 [AAA Server Group] ドロップダウン リストから、サーバ グループまたは LOCAL ユーザ データベースを選択します。

ステップ 6 （任意）AAA サーバをサーバ グループに追加するには、[Add Server] をクリックします。ユーザを LOCAL データベースに追加するには、[Add User] をクリックします。

サーバ グループとローカル ユーザ データベースの設定の詳細については、「AAA サーバおよびユーザ アカウントの設定」を参照してください。

ステップ 7 [Source] フィールドで、送信元 IP アドレスを入力するか、[...] ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の送信元アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 8 [Destination] フィールドで、宛先 IP アドレスを入力するか、[...] ボタンをクリックして ASDM にすでに定義されている IP アドレスを選択します。

プレフィックス/長さ表記（10.1.1.0/24 など）を使用してアドレスとサブネット マスクを指定します。マスクを使用せずに IP アドレスを入力すると、そのアドレスは最後が 0 であってもホスト アドレスと見なされます。

任意の宛先アドレスを指定するには、 any を入力します。

アドレスが複数ある場合はカンマで区切ります。

ステップ 9 [Service] フィールドで、宛先サービスの IP サービス名または番号を入力するか、[...] ボタンをクリックしてサービスを選択します。

TCP または UDP のポート番号、あるいは ICMP サービス番号を指定する場合は、 プロトコル / ポート を入力します。たとえば、TCP/8080 と入力します。

デフォルトでは、サービスは TCP です。

サービスが複数ある場合はカンマで区切ります。

ステップ 10 （任意）[Description] フィールドに説明を入力します。

ステップ 11 （任意）TCP または UDP の送信元サービスを指定するには、[More Options] 領域をクリックして開き、[Source Service] フィールドに TCP サービスまたは UDP サービスを入力します。

宛先サービスと送信元サービスは同じである必要があります。[Destination Service] フィールドをコピーし、[Source Service] フィールドに貼り付けます。

ステップ 12 （任意）ルールを非アクティブにするには、[More Options] 領域をクリックして開き、[Enable Rule] をオフにします。

この設定は、ルールを削除せずに無効にしたい場合に便利です。

ステップ 13 （任意）ルールの時間範囲を指定するには、[More Options] 領域をクリックして開き、[Time Range] ドロップダウン リストから時間範囲を選択します。

新しい時間範囲を追加するには、[...] ボタンをクリックします。詳細については、「時間範囲の設定」を参照してください。

この設定は、事前に設定した時間にだけルールをアクティブにする場合に便利です。

ステップ 14 [OK] をクリックします。

RADIUS 許可の設定

認証が成功すると、RADIUS プロトコルは RADIUS サーバによって送信される access-accept メッセージでユーザ許可を返します。認証の設定の詳細については、「ネットワーク アクセス認証の設定」を参照してください。

ネットワーク アクセスについてユーザを認証するようにセキュリティ アプライアンスを設定すると、RADIUS 許可も暗黙的にイネーブルになっています。したがって、この項では、セキュリティ アプライアンス上の RADIUS 許可の設定については取り上げません。ここでは、セキュリティ アプライアンスが RADIUS サーバから受信したアクセス リスト情報をどのように処理するかについて説明します。

アクセス リストをセキュリティ アプライアンスにダウンロードするように RADIUS サーバを設定できます。ユーザは、ユーザ固有のアクセス リストで許可された操作だけを許可されます。

（注） アクセス ルールをすでに設定している場合、ユーザごとの上書き設定が、ユーザ固有のアクセス リストによる許可に対して次のような影響を与えることに注意してください（「高度なアクセス ルール設定」（1-7 ページ）を参照）。

• ユーザごとの上書き設定を使用しない場合、ユーザ セッションのトラフィックは、インターフェイス アクセス リストとユーザ固有のアクセス リストの両方によって許可される必要があります。

• ユーザごとの上書き設定を使用した場合、許可される内容は、ユーザ固有のアクセス リストによって決定されます。

この項では、Cisco Secure Access Control Server（ACS）およびサードパーティ RADIUS サーバを設定する方法について説明します。次の項目を取り上げます。

• 「ダウンロード可能なアクセス リストの機能と Cisco Secure ACS について」

• 「ダウンロード可能なアクセス リストに関する Cisco Secure ACS の設定」

• 「ダウンロード可能なアクセス リストに関する任意の RADIUS サーバの設定」

• 「ダウンロード可能なアクセス リスト内のワイルドカード ネットマスク表現の変換」

ダウンロード可能なアクセス リストの機能と Cisco Secure ACS について

ダウンロード可能なアクセス リストは、Cisco Secure ACS を使用して各サーバに適切なアクセス リストを提供する場合に最もスケーラブルな方法です。次の機能があります。

• 無制限のアクセス リスト サイズ：ダウンロード可能なアクセス リストは、完全なアクセス リストを Cisco Secure ACS からセキュリティ アプライアンスに転送するために必要な数の RADIUS パケットを使用して送信されます。

• アクセス リスト管理の簡素化および集中化：ダウンロード可能なアクセス リストにより、一度記述したアクセス リスト セットを多数のユーザ プロファイルまたはグループ プロファイルに適用することや、多数のセキュリティ アプライアンスに配布することができます。

この方法は、複数の Cisco Secure ACS ユーザまたはグループに適用する非常に大きいアクセス リスト セットがある場合に最適ですが、Cisco Secure ACS ユーザおよびグループの管理を簡素化できることから、アクセス リストのサイズを問わず有用です。

セキュリティ アプライアンスは、ダウンロード可能なアクセス リストを Cisco Secure ACS から次のプロセスで受信します。

1. セキュリティ アプライアンスがユーザ セッションのための RADIUS 認証要求パケットを送信します。

2. Cisco Secure ACS がそのユーザを正常に認証した場合、Cisco Secure ACS は、該当するダウンロード可能なアクセス リストの内部名が含まれた RADIUS access-accept メッセージを返します。Cisco IOS cisco-av-pair RADIUS VSA（ベンダー 9、属性 1）には、ダウンロード可能なアクセス リスト セットを特定する次の AV のペアが含まれています。

acl-set-name はダウンロード可能なアクセス リストの内部名です。この名前は、Cisco Secure ACS 管理者がアクセス リストに割り当てた名前とアクセス リストが最後に変更された日時の組み合わせです。

3. セキュリティ アプライアンスはダウンロード可能なアクセス リストの名前を検査し、以前にその名前のダウンロード可能なアクセス リストを受信したことがあるかどうかを判別します。

– セキュリティ アプライアンスが以前にその名前のダウンロード可能なアクセス リストを受信したことがある場合は、Cisco Secure ACS との通信は完了し、セキュリティ アプライアンスはアクセス リストをユーザ セッションに適用します。ダウンロード可能なアクセス リストの名前には最後に変更された日時が含まれているため、Cisco Secure ACS から送信された名前と、以前にダウンロードしたアクセス リストの名前が一致するということは、セキュリティ アプライアンスはダウンロード可能なアクセス リストの最新バージョンを持っていることになります。

– セキュリティ アプライアンスが以前にその名前のダウンロード可能なアクセス リストを受信したことがない場合は、そのアクセス リストの古いバージョンを持っているか、そのアクセス リストのどのバージョンもダウンロードしたことがないことになります。いずれの場合でも、セキュリティ アプライアンスは、ダウンロード可能なアクセス リスト名を RADIUS 要求内のユーザ名として使用し、ヌル パスワード属性とともに RADIUS 認証要求を発行します。cisco-av-pair RADIUS VSA では、この要求に次の属性と値のペアも含まれます。

これに加えて、セキュリティ アプライアンスは Message-Authenticator 属性（IETF RADIUS 属性 80）で要求に署名します。

4. ダウンロード可能なアクセス リストの名前が含まれているユーザ名属性を持つ RADIUS 認証要求を受信すると、Cisco Secure ACS は Message-Authenticator 属性をチェックして要求を認証します。Message-Authenticator 属性がない場合、または正しくない場合、Cisco Secure ACS はその要求を無視します。Message-Authenticator 属性の存在により、ダウンロード可能なアクセス リスト名がネットワーク アクセスの不正取得に悪用されることが防止されます。Message-Authenticator 属性とその使用方法は、RFC 2869「RADIUS Extensions」で定義されています。この文書は、 http://www.ietf.org で入手できます。

5. 要求されたアクセス リストの長さが約 4 KB 未満の場合、Cisco Secure ACS はそのアクセス リストを含めた access-accept メッセージで応答します。メッセージには他の必須属性を含める必要があるので、1 つの access-accept メッセージに収まるアクセス リストの最大サイズは 4 KB よりわずかに小さくなります。

Cisco Secure ACS はダウンロード可能なアクセス リストを cisco-av-pair RADIUS VSA で送信します。アクセス リストは、一連の属性と値のペアという形式をとります。各ペアには ACE が 1 つ含まれ、シリアル番号が付けられます。

属性と値のペアの例を次に示します。

6. 要求されたアクセス リストの長さが約 4 KB を超える場合、Cisco Secure ACS は、上記の形式のアクセス リストの一部が含まれた access-challenge メッセージで応答します。メッセージには、State 属性（IETF RADIUS 属性 24）も含まれています。State 属性には、Cisco Secure ACS がダウンロードの進捗を追跡するために使用する制御データが含まれています。Cisco Secure ACS は、RADIUS メッセージの最大サイズ以内で可能な限り多数の完全な属性と値のペアを cisco-av-pair RADIUS VSA に含めます。

セキュリティ アプライアンスはアクセス リストの一部を受信すると、それを保存し、新しい access-request メッセージで応答します。これには、ダウンロード可能なアクセス リストを求める最初の要求と同じ属性と、access-challenge メッセージで受信した State 属性のコピーが含まれています。

これは、Cisco Secure ACS がアクセス リストの最後の部分を access-accept メッセージで送信するまで続行されます。

ダウンロード可能なアクセス リストに関する Cisco Secure ACS の設定

Cisco Secure ACS 上のダウンロード可能なアクセス リストを共有プロファイル コンポーネントとして設定し、そのアクセス リストをグループまたは個々のユーザに割り当てることができます。

アクセス リストの定義には、拡張 access-list コマンドと同様の 1 つまたは複数の セキュリティ アプライアンス コマンドを設定します。ただし、次のプレフィックスは不要です。

Cisco Secure ACS バージョン 3.3 上のダウンロード可能なアクセス リスト定義の例を次に示します。

ダウンロード可能なアクセス リストを作成する方法、およびそれらをユーザと関連付ける方法の詳細については、ご使用のバージョンの Cisco Secure ACS のガイドを参照してください。

セキュリティ アプライアンス上では、ダウンロードされたアクセス リストの名前は次のようになります。

acl_name 引数は Cisco Secure ACS で定義された名前（上記の例では acs_ten_acl）、 number は Cisco Secure ACS が生成した固有のバージョン ID です。

セキュリティ アプライアンス上にダウンロードされたアクセス リストは、次の行で構成されます。

ダウンロード可能なアクセス リストに関する任意の RADIUS サーバの設定

ユーザ固有のアクセス リストを Cisco IOS RADIUS cisco-av-pair VSA（ベンダー 9、属性 1）でセキュリティ アプライアンスに送信するように、Cisco IOS RADIUS VSA をサポートする任意の RADIUS サーバを設定できます。

cisco-av-pair VSA では、 access-list extended コマンドと同様の 1 つまたは複数の ACE を設定してください。ただし、次のコマンド プレフィックスは、

次のテキストに置き換えます。

nnn 引数は、0 ～ 999999999 の番号で、セキュリティ アプライアンス上に設定するコマンド文の順序を指定します。このパラメータを省略すると、順番は 0 となり、cisco-av-pair RADIUS VSA 内部の ACE の順序が使用されます。

RADIUS サーバ上の cisco-av-pair VSA に対して設定されている必要のあるアクセス リスト定義の例を次に示します。

cisco-av-pair 属性で送信されるアクセス リストをユーザごとに固有にする方法については、ご使用の RADIUS サーバのマニュアルを参照してください。

セキュリティ アプライアンス上では、ダウンロードされたアクセス リストの名前は次のようになります。

username 引数は、認証を受けるユーザの名前です。

セキュリティ アプライアンス上にダウンロードされたアクセス リストは、次の行で構成されます。RADIUS サーバ上で指定された番号に基づいた順序になっています。

ダウンロードされたアクセス リストの「access-list」という単語と名前の間には、2 個のスペースがあります。これらのスペースにより、ダウンロードされたアクセス リストとローカルのアクセス リストが区別されます。この例では、「79AD4A08」はセキュリティ アプライアンスによって作成されたハッシュ値で、RADIUS サーバ上でアクセス リスト定義がいつ変更されたかを判別するために役立ちます。

ダウンロード可能なアクセス リスト内のワイルドカード ネットマスク表現の変換

RADIUS サーバを使用して、ダウンロード可能なアクセス リストを Cisco VPN 3000 Series Concentrator およびセキュリティ アプライアンスに提供する場合は、ワイルドカード ネットマスク表現を標準のネットマスク表現に変換するようにセキュリティ アプライアンスを設定しなければならない場合があります。これは、Cisco VPN 3000 Series Concentrator はワイルドカード ネットマスク表現をサポートしますが、セキュリティ アプライアンスは標準のネットマスク表現しかサポートしないためです。これらの違いは、RADIUS サーバ上のダウンロード可能なアクセス リストを設定する方法に影響しますが、ワイルドカード ネットマスク表現を変換するようにセキュリティ アプライアンスを設定することで、その影響を最小限に抑えることができます。ワイルドカード ネットマスク表現の変換により、RADIUS サーバ上のダウンロード可能なアクセス リストのコンフィギュレーションを変更することなく、Cisco VPN 3000 Series Concentrator 用に記述されたダウンロード可能なアクセス リストをセキュリティ アプライアンスで使用できます。

[Configuration] > [Device Management] > [Users/AAA] > [AAA Server Groups] > [Add/Edit AAA Server] ダイアログボックスで使用可能な [ACL Netmask Convert] オプションを使用して、アクセス リスト ネットマスク変換をサーバごとに設定します。RADIUS サーバの設定方法の詳細については、「AAA サーバおよびユーザ アカウントの設定」を参照してください。

HTTPS を使用した HTTP 認証のクレデンシャルの交換

セキュリティ アプライアンス は、安全に HTTP 認証を行う方法を提供します。HTTP 認証を保護しないと、クライアントからセキュリティ アプライアンスに送信されるユーザ名およびパスワードは、クリア テキストとして渡されます。Secure HTTP 機能を使用すると、Web クライアントとセキュリティ アプライアンスとの間で HTTPS を使用したユーザ名とパスワードの交換がイネーブルになります。

この機能をイネーブルにすると、ユーザが HTTP の使用時に認証を必要とする場合は、セキュリティ アプライアンスが HTTP ユーザを HTTPS プロンプトにリダイレクトします。正常に認証されると、ユーザはセキュリティ アプライアンスにより元の HTTP URL にリダイレクトされます。

セキュアな Web クライアント認証では、次の制限事項があります。

• 同時に行うことができる HTTPS 認証セッションは、最大 16 個です。16 個の HTTPS 認証プロセスがすべて実行されている場合、認証を必要とする新しい接続は失敗します。

• 認証の絶対タイムアウト値を 0 に設定すると（「グローバル タイムアウトの設定」の [Authentication absolute] オプションを参照）、HTTPS 認証が機能しない場合があります。HTTPS 認証を受けた後、ブラウザが複数の TCP 接続を開始して Web ページのロードを試みると、最初の接続はそのまま許可されますが、後続の接続に対しては認証が発生します。その結果、ユーザが認証ページに正しいユーザ名とパスワードを毎回入力しても、繰り返し認証ページが表示されます。これを回避するには、認証の絶対タイムアウトを 1 秒に設定します。ただし、この回避策では、同じ送信元 IP アドレスからアクセスした認証されていないユーザがファイアウォールを通過できる期間が 1 秒間発生します。

• HTTPS 認証は SSL ポート 443 上で実行されるため、HTTP クライアントから HTTP サーバへのトラフィックをポート 443 でブロックするというアクセス ルールは設定しないようにしてください。また、ポート 80 上の Web トラフィックに対してスタティック PAT を設定する場合は、SSL ポートに対してもスタティック PAT を設定する必要があります。

Web クライアントのセキュアな認証をイネーブルにする手順は、次のとおりです。

ステップ 1 [Configuration] > [Firewall] > [AAA Rules] ペインから、ペインの下部にある [Advanced] ボタンをクリックします。

[AAA Rules Advanced Options] ダイアログボックスが表示されます。

ステップ 2 [Enable Secure HTTP] をオンにします。

ステップ 3 [OK] をクリックします。

インタラクティブ認証ルールの追加

HTTP のデフォルトでは、セキュリティ アプライアンスは基本 HTTP 認証を使用します。HTTPS の場合、セキュリティ アプライアンスは同様のカスタム ログイン画面を生成します。[Configuration] > [Security Policy] > [AAA Rules] > [Advanced AAA Configuration] > [Add Interactive Authentication] ダイアログボックスを使用して、ユーザがユーザ名とパスワードを入力できる内部 Web ページにセキュリティ アプライアンスがユーザをリダイレクトするように設定できます。

HTTP および HTTPS 認証のリダイレクト方式をイネーブルにした場合、セキュリティ アプライアンスでの直接認証も自動的にイネーブルになります。HTTP、HTTPS、Telnet、または FTP によるセキュリティ アプライアンスの通過は許可しないが他のタイプのトラフィックは認証する場合は、直接認証が役立ちます。他のトラフィックが許可される前に、ユーザは HTTP または HTTPS を使用するセキュリティ アプライアンスを直接認証できます。通過トラフィックに基本 HTTP 認証を引き続き使用する場合は、直接認証を独立して設定できます。直接認証のログイン ページにアクセスするには、次の URL のいずれかを入力します。

リダイレクションは、基本方式を強化したものです。これは、認証時に向上したユーザ エクスペリエンスが提供されると同時に、Easy VPN でもファイアウォール モードでも、HTTP および HTTPS と同じユーザ エクスペリエンスが提供されるためです。また、セキュリティ アプライアンスでの直接認証もサポートしています。

基本 HTTP 認証を使用し続けた方がよい場合もあります。セキュリティ アプライアンスでリスニング ポートを開く必要がない場合や、ルータ上の NAT を使用しているため、セキュリティ アプライアンスで提供される Web ページの変換ルールを作成する必要がない場合、あるいは基本 HTTP 認証の方がネットワークで効果的に機能する場合です。たとえば、電子メールに URL が埋め込まれている場合などのように、ブラウザ以外のアプリケーションでは基本認証の方が適していることがあります。

インタラクティブ認証ルールを設定するには、次の手順を実行します。

ステップ 1 [Configuration] > [Firewall] > [AAA Rules] ペインから、ペインの下部にある [Advanced] ボタンをクリックします。

[AAA Rules Advanced Options] ダイアログボックスが表示されます。

ステップ 2 [Interactive Authentication] 領域で、[Add] をクリックします。

ステップ 3 [Protocol] メニューから、[HTTP] または [HTTPS] を選択します。

HTTP と HTTPS の両方のリスナーをイネーブルにするには、2 つの別のルールを作成する必要があります。

ステップ 4 [Interface] メニューから、リスナーをイネーブルにするインターフェイスを選択します。

ステップ 5 [Port] メニューで、共通ポートを選択するか、またはリスンするポート番号を入力します。

HTTP のデフォルトは 80、HTTPS のデフォルトは 443 です。

ステップ 6 通過トラフィックを認証用のリスニング ポートにリダイレクトするには、[Redirect network users for authentication requests] チェックボックスをオンにします。

このチェックボックスをオンにしない場合、直接認証だけがイネーブルになります。

ステップ 7 [OK] をクリックします。

Telnet による直接認証のイネーブル化

任意のプロトコルまたはサービスのネットワーク アクセス認証を設定できますが（ aaa authentication match コマンドまたは aaa authentication include コマンドを参照）、HTTP、Telnet、または FTP のみで直接認証することもできます。ユーザはまずこれらのサービスのいずれかで認証を行ってから、認証を要求する他のトラフィックの通過を許可する必要があります。HTTP、Telnet、または FTP のセキュリティ アプライアンスの通過を許可せず、その他のタイプのトラフィックを認証する場合は、セキュリティ アプライアンス上で設定された所定の IP アドレスにユーザが Telnet で接続し、セキュリティ アプライアンスによって Telnet プロンプトが表示されるように、仮想 Telnet を設定できます。

仮想 Telnet アドレスへの Telnet アクセスの認証を、AAA 認証ルールを使用して認証するその他のサービスに対する認証と同様に設定する必要があります（「ネットワーク アクセス認証の設定」を参照）。

認証が済んでいないユーザが仮想 Telnet IP アドレスに接続すると、ユーザはユーザ名とパスワードを求められ、その後 AAA サーバにより認証されます。認証されると、ユーザには「Authentication Successful.」というメッセージが表示されます。それ以降、ユーザは認証を必要とする他のサービスに正常にアクセスできます。

着信ユーザ（セキュリティの低い方から高い方へ向かう）については、送信元インターフェイスに適用されるアクセス ルールに、宛先インターフェイスとして仮想 Telnet アドレスを追加する必要もあります。さらに、NAT が必要ない場合であっても、仮想 Telnet IP アドレスに対するスタティック NAT ルールを追加する必要があります。通常は、アイデンティティ NAT ルールが使用されます（アドレスをそれ自身に変換）。

発信ユーザについては、トラフィックに明示的な許可がありますが、内部インターフェイスにアクセス ルールを適用する場合は、必ず仮想 Telnet アドレスへのアクセスを許可する必要があります。スタティック NAT ルールは必要ありません。

セキュリティ アプライアンスからログアウトするには、仮想 Telnet IP アドレスに再接続します。ログアウトするように求められます。

仮想 Telnet サーバを設定するには、次の手順を実行します。

ステップ 1 [Configuration] > [Firewall] > [Advanced] > [Virtual Access] ペインで、[Enable Telnet Server] をオンにします。

ステップ 2 [Virtual Telnet Server] フィールドで、Telnet 接続する対象の IP アドレスを入力します。

このアドレスは必ず、セキュリティ アプライアンスにルーティングされる未使用のアドレスにしてください。たとえば、外部にアクセスするときに内部アドレス用の NAT を実行し、仮想 Telnet サーバへの外部アクセスを提供する場合、仮想 Telnet サーバ アドレスにグローバル NAT アドレスのいずれかを使用できます。

ステップ 3 [OK] をクリックします。

仮想 HTTP の設定

セキュリティ アプライアンスで HTTP 認証を使用する場合（「ネットワーク アクセス認証の設定」を参照）、セキュリティ アプライアンスでは、基本 HTTP 認証がデフォルトで使用されます。この認証方式を、セキュリティ アプライアンスが HTTP 接続をセキュリティ アプライアンス自身が生成した Web ページにリダイレクトするように変更できます（「インタラクティブ認証ルールの追加」を参照）。

ただし、基本 HTTP 認証を引き続き使用する場合、HTTP 認証をカスケードするには仮想 HTTP サーバが必要になることがあります。

セキュリティ アプライアンスに加えて宛先 HTTP サーバで認証が必要な場合は、virtual http コマンドを使用すると、セキュリティ アプライアンス（AAA サーバ経由）の認証と HTTP サーバの認証を個別に行うことができます。仮想 HTTP を使用しない場合は、セキュリティ アプライアンスに対する認証で使用したものと同じユーザ名とパスワードが HTTP サーバに送信されます。HTTP サーバのユーザ名とパスワードを別に入力するように求められることはありません。AAA サーバと HTTP サーバでユーザ名とパスワードが異なる場合、HTTP 認証は失敗します。

この機能を使用すると、AAA 認証を必要とする HTTP 接続がすべて、セキュリティ アプライアンス上の仮想 HTTP サーバにリダイレクトされます。セキュリティ アプライアンスにより、AAA サーバのユーザ名とパスワードの入力を求めるプロンプトが表示されます。AAA サーバがユーザを認証すると、セキュリティ アプライアンスは HTTP 接続を元のサーバにリダイレクトして戻しますが、AAA サーバのユーザ名とパスワードは含めません。HTTP パケットにユーザ名とパスワードが含まれていないため、HTTP サーバによりユーザに HTTP サーバのユーザ名とパスワードの入力を求めるプロンプトが別途表示されます。

着信ユーザ（セキュリティの低い方から高い方へ向かう）については、送信元インターフェイスに適用されるアクセス ルールに、宛先インターフェイスとして仮想 HTTP アドレスを追加する必要もあります。さらに、NAT が必要ない場合であっても、仮想 HTTP IP アドレスに対するスタティック NAT ルールを追加する必要があります。通常は、アイデンティティ NAT ルールが使用されます（アドレスをそれ自身に変換）。

発信ユーザについては、トラフィックに明示的な許可がありますが、内部インターフェイスにアクセス ルールを適用する場合は、必ず仮想 HTTP アドレスへのアクセスを許可する必要があります。スタティック NAT ルールは必要ありません。

仮想 HTTP サーバを設定するには、次の手順を実行します。

ステップ 1 [Configuration] > [Firewall] > [Advanced] > [Virtual Access] ペインで、[Enable HTTP Server] をオンにします。

ステップ 2 [Virtual HTTP Server] フィールドで、仮想 HTTP サーバの IP アドレスを入力します。

このアドレスは必ず、セキュリティ アプライアンスにルーティングされる未使用のアドレスにしてください。たとえば、外部にアクセスするときに内部アドレスに NAT を実行し、仮想 HTTP サーバに外部からアクセスする場合は、仮想 HTTP サーバ アドレスにグローバル NAT アドレスを 1 つ使用します。

ステップ 3 （任意）ユーザに HTTP 接続をセキュリティ アプライアンスにリダイレクトする必要があることを通知するには、[Display redirection warning] をオンにします。

このオプションは、リダイレクトが自動的に行われないテキストベースのブラウザにのみ適用されます。

ステップ 4 [OK] をクリックします。