セキュリティコンフィギュレーションガイド：ユーザサービスのセキュリティ保護

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。

マニュアルのコンテンツ

このマニュアル内で検索

ご利用いただける言語

Download Options

Book Title

セキュリティコンフィギュレーションガイド：ユーザサービスのセキュリティ保護

Chapter Title

認証プロキシの設定

PDF - Complete Book (7.08 MB) PDF - This Chapter (734.0 KB)
View with Adobe Reader on a variety of devices

検索結果

Updated:: 2017年6月6日

章のタイトル：認証プロキシの設定

機能情報の確認
この章の構成
認証プロキシを設定するための前提条件
認証プロキシを設定するための制約事項
認証プロキシの設定に関する情報
認証プロキシの設定方法
認証プロキシのモニタおよびメンテナンス
- ダイナミック ACL エントリの表示
- 認証プロキシのキャッシュエントリの削除
認証プロキシの設定例
その他の参考資料
認証プロキシの機能情報

認証プロキシの設定

Cisco IOS Firewall 認証プロキシ機能では、動的かつユーザごとの認証と認可、業界標準の TACACS+ および RADIUS 認証プロトコルを使用したユーザの認証が可能です。ユーザによる接続の認証と認可により、ネットワーク攻撃に対するより強力な保護が可能になります。

機能情報の確認

ご使用のソフトウェアリリースでは、このモジュールで説明されるすべての機能がサポートされているとは限りません。最新の機能情報と注意事項については、ご使用のプラットフォームとソフトウェアリリースに対応したリリースノートを参照してください。この章に記載されている機能の詳細、および各機能がサポートされているリリースのリストについては、「認証プロキシの機能情報」を参照してください。

プラットフォームサポートと Cisco IOS および Catalyst OS ソフトウェアイメージサポートに関する情報を入手するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator には、 http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp からアクセスできます。Cisco.com のアカウントは必要ありません。

この章の構成

• 「認証プロキシを設定するための前提条件」

• 「認証プロキシを設定するための制約事項」

• 「認証プロキシの設定に関する情報」

• 「認証プロキシの設定方法」

• 「認証プロキシのモニタおよびメンテナンス」

• 「認証プロキシの設定例」

• 「その他の参考資料」

• 「認証プロキシの機能情報」

認証プロキシを設定するための前提条件

認証プロキシを設定する前に、次のことを確認してください。

• 認証プロキシが正しく機能するためには、クライアントホストで次のブラウザソフトウェアが動作している必要があります。

– Microsoft Internet Explorer 3.0 以降

– Netscape Navigator 3.0 以降

• 認証プロキシには、標準のアクセスリストを使用するオプションがあります。認証プロキシを設定する前に、アクセスリストを使用してトラフィックをフィルタする方法について確実に理解する必要があります。アクセスリストを Cisco IOS Firewall とともに使用する方法の概要については、「Access Control Lists: Overview and Guidelines」の章を参照してください。

• 認証プロキシは、シスコの Authentication, Authorization, and Accounting（AAA; 認証、認可、アカウンティング）の枠組みで実装されているユーザ認証と認可を使用します。認証プロキシを設定する前に、AAA ユーザ認証、認可、およびアカウンティングの設定方法について理解する必要があります。ユーザ認証、認可、およびアカウンティングについては、「Authentication, Authorization, and Accounting (AAA)」の章を参照してください。

• Cisco IOS Firewall とともに認証プロキシを正常に実行するには、ファイアウォール上で CBAC を設定します。CBAC 機能の詳細については、「 Configuring Context-Based Access Control 」の章を参照してください。

認証プロキシを設定するための制約事項

• 認証プロキシは、HTTP 接続だけを開始します。

• HTTP サービスは、標準的な（ウェルノウン）ポートで動作している必要があります。HTTP の場合はポート 80 です。

• セキュアな認証のために、クライアントブラウザで JavaScript がイネーブルになっている必要があります。

• 認証プロキシアクセスリストは、ルータを通過するトラフィックに適用されます。ルータ宛のトラフィックは、Cisco IOS ソフトウェアで提供される既存の認証方式によって認証されます。

• 認証プロキシでは、同時使用がサポートされていません。つまり、2 人のユーザが同じホストから同時にログインしようとした場合、認証と認可は、最初に有効なユーザ名とパスワードを送信したユーザだけに適用されます。

• 複数の AAA サーバまたは異なる AAA サーバを使用したロードバランシングはサポートされていません。

認証プロキシの設定に関する情報

Cisco IOS Firewall 認証プロキシ機能を使用すると、ネットワーク管理者は、詳細なセキュリティポリシーをユーザごとに適用できます。以前は、ユーザの身元と関連する認可済みアクセスをユーザの IP アドレスに関連付けるか、1 つのセキュリティポリシーをユーザグループまたはサブネットワーク全体に適用する必要がありました。現在では、ユーザごとのポリシーに基づいてユーザを特定し認可することができます。複数のユーザに一般的なポリシーを適用するのではなく、個人に対してアクセス権を調整できます。

認証プロキシ機能を使用すると、ユーザは、ネットワークにログインしたり、HTTP 経由でインターネットにアクセスでき、ユーザ固有のアクセスプロファイルが、CiscoSecure ACS または他の RADIUS または TACACS+ 認証サーバから自動的に取得されて適用されます。ユーザプロファイルは、認証されたユーザからのアクティブトラフィックが存在するときにのみ、アクティブになります。

認証プロキシは、Network Address Translation（NAT; ネットワークアドレス変換）、Context-based Access Control（CBAC; コンテキストベースアクセスコントロール）、IP Security（IPSec）暗号化、Cisco Secure VPN Client（VPN クライアント）ソフトウェアなど、他の Cisco IOS セキュリティ機能と互換性があります。

ここでは、次の各手順について説明します。

• 「ワンタイムパスワード（OTP）を使用した動作」

• 「他のセキュリティ機能との互換性」

• 「AAA アカウンティングとの互換性」

• 「DoS 攻撃（サービス拒絶攻撃）からの保護」

• 「認証プロキシでのスプーフィングの危険性」

• 「Lock-and-Key 機能との比較」

認証プロキシの仕組み

ユーザがファイアウォールを通じて HTTP セッションを開始すると、認証プロキシが起動されます。認証プロキシは、まずユーザが認証済みかどうかを確認します。ユーザの有効な認証エントリが存在する場合、認証プロキシによるそれ以上の介入なしに接続が完了します。エントリが存在しない場合、認証プロキシは HTTP 接続要求に対し、ユーザ名とパスワードの入力をユーザに求める応答を返します。

図 1 に、認証プロキシの HTML ログインページを示します。

図 1 認証プロキシの HTML ログインページ

ユーザは、有効なユーザ名とパスワードを入力することで、認証サーバで正常に認証される必要があります。

認証が成功すると、ユーザの認可プロファイルが AAA サーバから取得されます。認証プロキシは、このプロファイル内の情報を使用して、動的な Access Control Entry（ACE; アクセスコントロールエントリ）を作成し、入力インターフェイスのインバウンド（入力）Access Control List（ACL; アクセスコントロールリスト）と、出力インターフェイスのアウトバウンド（出力）ACL に追加します（出力 ACL がインターフェイスに存在する場合）。この処理により、ファイアウォールは、認証済みユーザに、認可プロファイルで許可されたネットワークへのアクセスを許可します。たとえば、Telnet がユーザのプロファイルで許可されている場合、ユーザはファイアウォールを通じた Telnet 接続を開始できます。

認証が失敗した場合、認証プロキシは、ユーザに失敗したことを報告し、何度か再試行するかどうかを訪ねます。5 回続けて認証に失敗した場合、2 分間待ってから、認証プロキシを起動するために別の HTTP セッションを開始する必要があります。

ログインページは、ユーザが Web サーバの情報にアクセスするための要求を行うたびに更新されます。

認証プロキシは、ダウンロードしたアクセスリスト中の送信元 IP アドレスを認証済みホストの送信元 IP アドレスで置き換えることで、ユーザプロファイルの各アクセスリストエントリをカスタマイズします。

認証プロキシは、動的な ACE をインターフェイス設定に追加するのと同時に、ログインが成功したことを確認するメッセージをユーザに送信します。図 2 に、HTML ページのログインステータスを示します。

図 2 認証プロキシのログインステータスメッセージ

認証プロキシは、各ユーザプロファイルに対し非アクティビティ（アイドル）タイマーを設定します。ファイアウォール経由のアクティビティがある限り、ユーザのホストから送信された新しいトラフィックによって認証プロキシは起動されず、認可済みのユーザトラフィックに対してファイアウォールを通じたアクセスが許可されます。

アイドルタイマーが満了した場合、認証プロキシはユーザのプロファイル情報と動的なアクセスリストエントリを削除します。この処理が実行されると、クライアントからのトラフィックはブロックされます。ユーザは、別の HTTP 接続を開始し、認証プロキシを起動する必要があります。

セキュアな認証

認証プロキシでは、JavaScript を使用して、クライアントブラウザを使用したセキュアな認証が実現されます。セキュアな認証は、クライアントが、誤って認証プロキシルータ以外のネットワーク Web サーバにユーザ名とパスワードを送ることを防ぎます。

ここでは、次の各手順について説明します。

• 「JavaScript を使用した操作」

• 「JavaScript を使用しない場合の操作」

JavaScript を使用した操作

ユーザは、HTTP 接続を開始する前に、ブラウザ上で JavaScript をイネーブルにする必要があります。ブラウザで JavaScript がイネーブルになっている状態で、セキュアな認証が自動的に実行され、図 2 に示す認証メッセージが表示されます。ユーザの HTTP 接続は自動的に完了します。

JavaScript を使用しない場合の操作

クライアントブラウザが JavaScript をサポートしていない場合や、サイトのセキュリティポリシーでユーザが JavaScript をイネーブルにすることが禁止されている場合、ログインしようとするとポップアップウィンドウに手動で接続を完了するための手順が表示されます。図 3 に、ブラウザで JavaScript がディセーブルになっている場合の認証プロキシのログインステータスメッセージを示します。

図 3 JavaScript がディセーブルになっている場合の認証プロキシのログインステータスメッセージ

このウィンドウを閉じるには、ブラウザの [File] メニューの [Close] をクリックします。

ポップアップウィンドウを閉じた後、認証ログインページが表示されているブラウザウィンドウの [Reload]（Internet Explorer の場合は [Refresh]）をクリックする必要があります。ユーザの最後の認証の試みが成功した場合、[Reload] をクリックすると、ユーザが取得しようとしている Web ページが表示されます。ユーザの最後の試みが失敗した場合、[Reload] をクリックすると、認証プロキシがクライアントの HTTP トラフィックを再度代行受信し、ユーザ名とパスワードの入力を求める別のログインページが表示されます。

JavaScript がイネーブルになっていない場合、サイト管理者は、「JavaScript を使用しないユーザ接続の確立」で説明するように、ポップアップウィンドウを閉じるための正しい手順を実行するよう、ユーザに忠告することを推奨します。

認証プロキシの使用

ユーザに対して透過的に動作する Cisco IOS Firewall のいくつかの機能と異なり、認証プロキシ機能では、クライアントホスト上でいくつかの対話が必要です。表 1 で、認証プロキシとクライアントホストの対話について説明します。

表 1 認証プロキシとクライアントホストの対話
認証プロキシのクライアントとの動作	説明
HTTP 接続の開始	ユーザが現在ファイアウォールルータで認証済みでない場合、ユーザが HTTP 接続を開始すると認証プロキシが起動されます。ユーザがすでに認証済みの場合、認証プロキシはユーザに対して透過的です。
ログインページを使用したログイン	認証プロキシを起動すると、HTML ベースのログインページが生成されます。ユーザは、AAA サーバで認証されるために、ユーザ名とパスワードを入力する必要があります。図 1 に、認証プロキシのログインページを示します。
クライアントでのユーザの認証	ログインの試行の後の認証プロキシの動作は、ブラウザで JavaScript がイネーブルになっているかどうかで変わります。JavaScript がイネーブルになっており、認証が成功した場合、認証プロキシは、図 2 に示すように、認証のステータスを示すメッセージを表示します。認証ステータスが表示された後、プロキシは自動的に HTTP 接続を完了します。 JavaScript がディセーブルになっており、認証が成功した場合、認証プロキシは、接続を完了するための追加の手順を表示したポップアップウィンドウを生成します。図 3 を参照してください。いずれの場合も、認証が成功しなかった場合は、ユーザはログインページから再度ログインする必要があります。

認証プロキシを使用すべき場合

認証プロキシを使用するのが望ましい状況は次のとおりです。

• ホストの IP アドレスやグローバルアクセスポリシーに基づいてアクセスコントロールを設定するのではなく、認証サーバによって提供されているサービスを使用して、個人ごと（ユーザごと）にアクセス権を管理する場合。任意のホスト IP アドレスからのユーザを認証および認可することにより、ネットワーク管理者は、DHCP を使用してホスト IP アドレスを設定できるようにもなります。

• ファイアウォールを通じたイントラネットやインターネットサービスまたはホストへのアクセスを許可する前に、ローカルユーザを認証および認可する場合。

• ファイアウォールを通じたローカルサービスまたはホストへのアクセスを許可する前に、リモートユーザを認証および認可する場合。

• 特定のエクストラネットユーザに対するアクセスを制御する場合。たとえば、企業パートナーの財務責任者を、あるアクセス権のセットを使用して認証および認可し、同じパートナーの技術責任者を、別のアクセス権のセットを使用するように認可することができます。

• 認証プロキシを VPN クライアントソフトウェアとともに使用して、ユーザを検証し、特定のアクセス権を割り当てる場合。

• 認証プロキシを AAA アカウンティングとともに使用して、課金、セキュリティ、またはリソース割り当てのために使用可能な「開始」および「停止」アカウンティングレコードを生成することで、ユーザが認証済みホストからのトラフィックを追跡できるようにする場合。

認証プロキシの適用

認証プロキシは、ユーザごとの認証と認可を行うルータの任意のインターフェイスで、インバウンド方向に適用します。認証プロキシをインターフェイスでインバウンド方向に適用することで、ユーザの初期接続要求は、ファイアウォールによる他の処理に渡される前に、認証プロキシによって代行受信されます。ユーザが AAA サーバによる認証に失敗すると、接続要求はドロップされます。

認証プロキシの適用方法は、セキュリティポリシーに依存します。たとえば、インターフェイスを通過するすべてのトラフィックをブロックし、認証プロキシ機能をイネーブルにして、ユーザが開始したすべての HTTP 接続に対して認証と認可を義務付けることができます。ユーザは、AAA サーバで正常に認証されない限り、サービスの利用が認可されません。

認証プロキシ機能では、標準のアクセスリストを使用し、どのホストまたはホストグループからの初期 HTTP トラフィックに対してプロキシを起動するかを指定できます。

図 4 に示す認証プロキシは、LAN インターフェイスに適用されており、すべてのネットワークユーザは、初期接続時に認証される必要があります（すべてのトラフィックは各インターフェイスでブロックされます）。

図 4 ローカルインターフェイスでの認証プロキシの適用

図 5 に示す認証プロキシは、ダイヤルインインターフェイスに適用され、すべてのネットワークトラフィックが各インターフェイスでブロックされます。

図 5 外部インターフェイスでの認証プロキシの適用

ワンタイムパスワード（OTP）を使用した動作

One-Time Password（OTP; ワンタイムパスワード）を使用する場合、ユーザはユーザ名とワンタイムパスワードを HTML のログインページに通常どおり入力します。

ユーザは、最初の 3 回の試行の間に正しいトークンパスワードを入力する必要があります。入力を 3 回間違えた場合、2 つの有効なトークンパスワードを続けて入力しないと、AAA サーバでの認証が許可されません。

他のセキュリティ機能との互換性

この認証プロキシは、次に示す Cisco IOS ソフトウェアおよび Cisco IOS のセキュリティ機能と互換性があります。

• Cisco IOS Firewall Intrusion Detection System（IDS）

• NAT

• CBAC

• IPSec 暗号化

• VPN クライアントソフトウェア

認証プロキシは、Cisco IOS Firewall IDS および IPSec 暗号化機能と透過的に連動します。次のセクションでは、NAT、CBAC、および VPN クライアントソフトウェアの各機能と認証プロキシの関係について説明します。

• 「NAT の互換性」

• 「CBAC との互換性」

• 「VPN クライアントの互換性」

NAT の互換性

認証プロキシ機能は、ACL と認証が NAT 変換の前に完了している場合にだけ、NAT と互換性があります。NAT は認証プロキシ機能と互換性がありますが、認証プロキシを使用するうえで NAT は必須ではありません。

CBAC との互換性

認証プロキシは、CBAC セキュリティ機能と互換性がありますが、認証プロキシ機能を使用するために CBAC は必須ではありません。

認証プロキシの認可は、手動で作成された ACL の先頭に動的に追加されるアクセスコントロールエントリ（ACE）を返します。それ以降、ACL を「保護された側」のインバウンドインターフェイスに適用し、認可されたユーザの送信元 IP アドレスのリモートネットワークへのアクセスを許可または禁止します。

VPN クライアントの互換性

ネットワーク管理者は、認証プロキシを使用して、VPN クライアントトラフィックに対し、追加のセキュリティレイヤとアクセスコントロールを適用できます。VPN クライアントが HTTP 接続を開始した場合、認証プロキシはまず既存のクライアント認証を確認します。クライアントが認証済みの場合、認可されたトラフィックは許可されます。クライアントが認証済みでない場合、HTTP 要求によって認証プロキシが起動され、ユーザに対しユーザ名とパスワードの入力が求められます。

ユーザ認証が成功した場合、認証プロキシは AAA サーバからユーザプロファイルを取得します。ユーザプロファイルエントリ内の送信元アドレスは、復号化されたパケット内の、認証済み VPN クライアントの IP アドレスで置き換えられます。

AAA アカウンティングとの互換性

認証プロキシを使用して、課金やセキュリティ監査で使用するために十分な情報を含む「開始」および「停止」アカウンティングレコードを生成できます。そうすることで、認証プロキシサービスを使用する認証済みホストの動作をモニタできます。

認証プロキシのキャッシュと関連付けられている動的アクセスコントロールリストが作成されると、認証プロキシは認証済みホストからのトラフィックの追跡を開始します。アカウンティングでは、このイベントに関するデータが、他のユーザのデータとともにデータ構造に保存されます。アカウンティング開始オプションがイネーブルになっている場合、この時点でアカウンティングレコード（「開始」レコード）を生成できます。認証済みホストからの以降のトラフィックは、認証プロキシによって作成された動的な ACL がパケットを受信すると記録されます。

認証プロキシのキャッシュが満了して削除されると、経過時間などの追加のデータがアカウンティング情報に追加され、「停止」レコードがサーバに送信されます。この時点で、情報がデータ構造から削除されます。

認証プロキシユーザセッションに対するアカウンティングレコードは、キャッシュおよび動的 ACL の使用に関連付けられます。

（注）アカウンティングレコードは、RADIUS と TACACS+ の両方に対し、RADIUS アトリビュート 42、46、および 47 を含んでいる必要があります。

RADIUS アトリビュートの詳細については、付録「RADIUS アトリビュート」を参照してください。

DoS 攻撃（サービス拒絶攻撃）からの保護

認証プロキシは、受信 HTTP 要求のレベルをモニタします。各要求に対し、認証プロキシはユーザのログインクレデンシャルの入力を求めます。オープン要求が多い場合、ルータが DoS 攻撃を受けていることを示している可能性があります。認証プロキシは、オープン要求のレベルを制限し、オープン要求の数が 40 未満になるまで、追加の要求をドロップします。

ファイアウォールが、認証が必要な大量の接続要求を受信している場合、正規のネットワークユーザが接続を行うときに遅延が発生したり、接続が拒否されて接続の再試行が必要になることがあります。

認証プロキシでのスプーフィングの危険性

認証プロキシが起動されると、ユーザアクセス権を持つインターフェイスを一時的に再設定することで、ファイアウォール中に動的な開口が作成されます。この開口が存在する間に、別のホストが認証済みユーザのアドレスを偽装し、ファイアウォールの背後へのアクセスを獲得する可能性があります。認証プロキシは、アドレススプーフィングの問題を起こしません。この問題は、ユーザの関心事としてここに明記しています。スプーフィングは、すべてのアクセスリストにつきまとう問題であり、認証プロキシは特にこの問題に対処していません。

Lock-and-Key 機能との比較

Lock-and-Key は、認証とダイナミックアクセスリストを使用して、ファイアウォールを通じたユーザアクセスを可能にする、Cisco IOS Firewall のもう 1 つの機能です。表 2 に、認証プロキシと Lock-and-Key 機能の比較を示します。

表 2 認証プロキシ機能と Lock-and-Key 機能の比較
Lock-and-Key	認証プロキシ
Telnet 接続要求により起動	HTTP 接続要求により起動
TACACS+、RADIUS、またはローカル認証	TACACS+ または RADIUS 認証および認可
アクセスリストはルータだけで設定	アクセスリストは必ず AAA サーバから取得
アクセス権は、ユーザのホスト IP アドレスに基づいて許可	アクセス権は、ユーザごとおよびホスト IP アドレスごとに許可
アクセスリストは、各ホスト IP アドレスに対し 1 つに制限	アクセスリストは、AAA サーバ上のユーザプロファイルによって定義された複数のエントリを持つことが可能
固定の IP アドレスを特定のユーザに関連付け。ユーザは、その IP アドレスを持つホストからログインする必要あり。	DHCP ベースのホストの AP アドレスを許可。つまり、ユーザは、任意のホストからログインし、認証と認可を受けることが可能。

認証プロキシは、ユーザごとのセキュリティポリシーを提供する任意のネットワーク環境で使用します。Lock-and-Key は、ローカル認証と、ホストアドレスに基づく限定的な数のルータベースのアクセスコントロールポリシーの恩恵を受けるネットワーク環境で使用します。Lock-and-Key は、Cisco Secure Integrated Software を使用しない環境で使用します。

認証プロキシの設定方法

認証プロキシ機能を設定するには、次の手順を実行します。

• 「AAA の設定」（必須）

• 「認証プロキシ用の HTTP サーバの設定」（必須）

• 「認証プロキシの設定」（必須）

• 「認証プロキシの確認」（任意）

この章に示すコマンドを使用した認証プロキシの設定例については、この章の最後にある「認証プロキシの設定例」のセクションを参照してください。

AAA の設定

AAA サービス用に認証プロキシを設定する必要があります。認可をイネーブルにし認可方式を定義するには、次のコマンドをグローバルコンフィギュレーションモードで使用します。

コマンド	目的
ステップ 1	router(config)# aaa new-model	ルータで AAA 機能をイネーブルにします。
ステップ 2	router(config)# aaa authentication login default TACACS+ RADIUS	ログイン時の認証方式リストを定義します。
ステップ 3	router(config)# aaa authorization auth-proxy default [ method1 [ method2 ...]]	auth-proxy キーワードを使用して、AAA 方式に対する認証プロキシをイネーブルにします。
ステップ 4	router(config)# aaa accounting auth-proxy default start-stop group tacacs+	auth-proxy キーワードを使用して、認可ポリシーを、ダウンロード可能なダイナミック ACL として設定します。このコマンドは、認証プロキシのアカウンティングをアクティブ化します。
ステップ 5	router(config)# tacacs-server host hostname	AAA サーバを指定します。RADIUS サーバの場合は、 radius server host コマンドを使用します。
ステップ 6	router(config)# tacacs-server key key	ルータと AAA サーバとの間の通信用の認証および暗号化キーを設定します。RADIUS サーバの場合、 radius server key コマンドを使用します。
ステップ 7	router(config)# access-list access-list-number permit tcp host source eq tacacs host destination	AAA サーバがトラフィックをファイアウォールに返すのを許可する ACL エントリを作成します。送信元アドレスは AAA サーバの IP アドレスで、宛先は AAA サーバが存在するルータインターフェイスの IP アドレスです。

認証プロキシでは、ファイアウォールルータで AAA を設定するのに加えて、ユーザごとのアクセスプロファイル設定が AAA サーバ上に必要です。認証プロキシをサポートするために、ここに示す概要に従い、AAA 認可サービス auth-proxy を AAA サーバ上で設定します。

• auth-proxy キーワードに対する個別の認可セクションを定義して、ダウンロード可能なユーザプロファイルを指定します。このキーワードは、EXEC などの他の種類のサービスと干渉しません。次に、TACACS サーバ上のユーザプロファイルの例を示します。

default authorization = permit

key = cisco

user = newuser1 {

service = auth-proxy

{

priv-lvl=15

proxyacl#1="permit tcp any any eq 26"

proxyacl#2="permit icmp any host 60.0.0.2"

proxyacl#3="permit tcp any any eq ftp"

proxyacl#4="permit tcp any any eq ftp-data"

proxyacl#5="permit tcp any any eq smtp"

proxyacl#6="permit tcp any any eq telnet"

}

• AAA サーバのユーザ設定でサポートされる唯一のアトリビュートは、 proxyacl#n です。 プロファイル中のアクセスリストを設定する際には、 proxyacl#n アトリビュートを使用します。アトリビュート proxyacl#n は、RADIUS と TACACS+ の両方の attribute-value（AV）のペア用です。

• すべてのユーザの特権レベルは 15 に設定する必要があります。

• AAA サーバ上のユーザプロファイル内のアクセスリストには、 permit キーワードだけを含むアクセスコマンドが必要です。

• 各ユーザプロファイルアクセスリストエントリの any キーワードに、送信元アドレスを設定します。ユーザプロファイルがファイアウォールにダウンロードされるとき、アクセスリスト中の送信元アドレスは、認証プロキシ要求を行うホストの送信元アドレスで置き換えられます。

• サポートされる AAA サーバは次のとおりです。

– CiscoSecure ACS 2.1.x for Windows NT

– CiscoSecure ACS 2.3 for Windows NT

– CiscoSecure ACS 2.2.4 for UNIX

– CiscoSecure ACS 2.3 for UNIX

– TACACS+ サーバ（vF4.02.alpha）

– Ascend RADIUS サーバ radius-980618（必須のアトリビュートと値のペアのパッチ）

– Livingston RADIUS サーバ（v1.16）

AAA サーバの設定例については、「AAA サーバのユーザプロファイル例」のセクションを参照してください。

認証プロキシ用の HTTP サーバの設定

この作業は、ファイアウォール上で HTTP サーバをイネーブルにし、認証プロキシ用に HTTP サーバの AAA 認証方式を設定するために使用します。

手順の概要

1. enable

2. configure terminal

3. ip http server

4. ip http access-class access-list-number