Cisco ASA 5500 シリーズ/Cisco PIX 500 シリーズ Cisco セキュリティ アプライアンス コマンド ライン コンフィギュレーション ガイド Version 7.1(1)
ネットワーク アクセスへの AAA の 適用
ネットワーク アクセスへの AAA の適用
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 6MB) | フィードバック

目次

ネットワーク アクセスへの AAA の適用

AAA パフォーマンス

ネットワーク アクセス認証の設定

認証の概要

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

Web クライアントのセキュアな認証のイネーブル化

ネットワーク アクセス認可の設定

TACACS+ 認可の設定

RADIUS 認可の設定

ダウンロード可能な ACL を送信するための RADIUS サーバの設定

ユーザごとの ACL 名をダウンロードするための RADIUS サーバの設定

ネットワーク アクセスのアカウンティングの設定

MAC アドレスによるトラフィックの認証と認可の免除

ネットワーク アクセスへの AAA の適用

この章では、ネットワーク アクセスに対して AAA(トリプル エー)をイネーブルにする方法について説明します。

管理アクセスの AAA については、「システム管理者の AAA」を参照してください。

ここでは、次の項目を取り上げます。

「AAA パフォーマンス」

「ネットワーク アクセス認証の設定」

「ネットワーク アクセス認可の設定」

「ネットワーク アクセスのアカウンティングの設定」

「MAC アドレスによるトラフィックの認証と認可の免除」

AAA パフォーマンス

セキュリティ アプライアンスは「カットスルー プロキシ」を使用します。これにより、従来のプロキシ サーバと比較して、パフォーマンスが大幅に向上します。従来のプロキシ サーバは、OSI モデルのアプリケーション レイヤですべてのパケットを分析するため、プロキシ サーバのパフォーマンスに負担がかかります。セキュリティ アプライアンス カットスルー プロキシは、アプリケーション レイヤで最初にユーザ確認を行い、標準 RADIUS、TACACS+、またはローカル データベースで認証します。セキュリティ アプライアンスはユーザを認証した後、セッション フローをシフトするため、セッション ステート情報を維持したまま、すべてのトラフィックが送信元と宛先の間で直接かつ迅速に流れます。

ネットワーク アクセス認証の設定

ここでは、次の項目について説明します。

「認証の概要」

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

「Web クライアントのセキュアな認証のイネーブル化」

認証の概要

セキュリティ アプライアンスでは、AAA サーバを使用するネットワーク アクセス認証を設定できます。

所定の IP アドレスのユーザは、認証セッションが期限切れになるまで、すべての規則およびタイプに対して一度だけ認証を受ける必要があります(タイムアウトの値については、『 Cisco Security Appliance Command Reference 』で timeout uauth コマンドを参照してください)。たとえば、Telnet および FTP を認証するようにセキュリティ アプライアンスが設定されていて、ユーザが正常に Telnet 認証を受けた場合、認証セッションが継続している限り、ユーザは FTP 認証を受ける必要はありません。

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

HTTP(S)、Telnet、または FTP がセキュリティ アプライアンスを通過することを許可せずに、他のタイプのトラフィックを認証する場合は、仮想 Telnet を設定できます。仮想 Telnet では、セキュリティ アプライアンス上に設定された所定の IP アドレスにユーザが Telnet 接続すると、セキュリティ アプライアンスは Telnet プロンプトを表示します。 virtual telnet コマンドの詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。

Telnet、HTTP(S)、および FTP の場合、セキュリティ アプライアンスは認証プロンプトを生成します。宛先サーバにも独自の認証がある場合、ユーザは別のユーザ名とパスワードを入力します。

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

たとえば、外部 TCP ポート 889 はポート 80(www)に変換され、すべての関連 ACL はトラフィックを許可するものとします。

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 www netmask 255.255.255.255
 

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

次の例のように、ローカル ポートがポート 80 ではないとします。

static (inside,outside) tcp 10.48.66.155 889 192.168.123.10 111 netmask 255.255.255.255
 

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


aaa authentication secure-http-client コマンドを使用しないで HTTP 認証を使用した場合、AAA サーバだけでなく、宛先 Web サーバにもユーザ名とパスワードがクリア テキストで送信されます。たとえば、外部 Web サーバにアクセスする内部ユーザを認証した場合、外部の誰もが有効なユーザ名とパスワードを知ることができます。HTTP 認証をイネーブルにするときは必ず
aaa authentication secure-http-client コマンドを使用することをお勧めします。aaa authentication secure-http-client コマンドの詳細については、「Web クライアントのセキュアな認証のイネーブル化」を参照してください。


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

name> jamiec@jchrichton
password> letmein@he110
 

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

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

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


ステップ 1 aaa-server コマンドを使用して、AAA サーバを指定します。すでに AAA サーバを指定してある場合は、次の手順に進みます。

AAA サーバの指定方法の詳細については、「AAA サーバ グループおよびサーバの識別」を参照してください。

ステップ 2 access-list コマンドを使用して、認証するトラフィックの送信元アドレスと宛先アドレスを指定する ACL を作成します。手順については、「拡張アクセスリストの追加」を参照してください。

許可 ACE は、一致したトラフィックを認証するようにマークします。一方、 拒否 エントリは、一致したトラフィックを認証から除外します。HTTP、Telnet、または FTP のいずれかの宛先ポートを ACL に必ず含めます。これは、ユーザがこれらのサービスのいずれかの認証を受けないと、他のサービスがセキュリティ アプライアンスの通過を許可されないためです。

ステップ 3 認証を設定するには、次のコマンドを入力します。

hostname/contexta(config)# aaa authentication match acl_name interface_name server_group
 

acl_nameステップ 2 で作成した ACL の名前、 interface_name nameif コマンドで指定したインターフェイスの名前、 server_groupステップ 1 で作成した AAA サーバ グループです。


) もう 1 つの方法として、aaa authentication include コマンド(コマンド内でトラフィックを指定するコマンド)を使用することもできます。ただし、同一コンフィギュレーション内で両方の方法を使用することはできません。詳細については、『Cisco Security Appliance Command Reference』を参照してください。


ステップ 4 (オプション)ネットワーク アクセス認証にローカル データベースを使用していて、セキュリティ アプライアンスが所定のユーザ アカウントに対して許可する連続失敗ログイン試行の回数を制限する場合は、 aaa local authentication attempts max-fail コマンドを使用します。次の例を参考にしてください。

hostname/contexta(config)# aaa local authentication attempts max-fail 7
 

ヒント 特定のユーザまたはすべてのユーザのロックアウト ステータスを解除するには、clear aaa local user lockout コマンドを使用します。



 

たとえば、次のコマンドは、すべての内部 HTTP トラフィックおよび SMTP トラフィックを認証します。

hostname/contexta(config)# aaa-server AuthOutbound protocol tacacs+
hostname/contexta(config-aaa-server-group)# exit
hostname/contexta(config)# aaa-server AuthOutbound (inside) host 10.1.1.1
hostname/contexta(config-aaa-server-host)# key TACPlusUauthKey
hostname/contexta(config-aaa-server-host)# exit
hostname/contexta(config)# access-list MAIL_AUTH extended permit tcp any any eq smtp
hostname/contexta(config)# access-list MAIL_AUTH extended permit tcp any any eq www
hostname/contexta(config)# aaa authentication match MAIL_AUTH inside AuthOutbound
 

次のコマンドは、外部インターフェイスから特定のサーバ(209.165.201.5)への Telnet トラフィックを認証します。

hostname/contexta(config)# aaa-server AuthInbound protocol tacacs+
hostname/contexta(config-aaa-server-group)# exit
hostname/contexta(config)# aaa-server AuthInbound (inside) host 10.1.1.1
hostname/contexta(config-aaa-server-host)# key TACPlusUauthKey
hostname/contexta(config-aaa-server-host)# exit
hostname/contexta(config)# access-list TELNET_AUTH extended permit tcp any host 209.165.201.5 eq telnet
hostname/contexta(config)# aaa authentication match TELNET_AUTH outside AuthInbound
 

Web クライアントのセキュアな認証のイネーブル化

セキュリティ アプライアンスでは、HTTP 認証を保護する方法が提供されます。HTTP 認証を保護しないと、セキュリティ アプライアンスに対して入力されたユーザ名とパスワードは、宛先 Web サーバに渡されます。 aaa authentication secure-http-client コマンドを使用することにより、Web クライアントとセキュリティ アプライアンスの間の HTTPS によるユーザ名とパスワードの交換をイネーブルにできます。HTTPS は伝送を暗号化し、ユーザ名とパスワードが HTTP で外部 Web サーバに渡されるのを防ぎます。

この機能をイネーブルにすると、認証を必要とする Web ページにユーザがアクセスする場合、セキュリティ アプライアンスによって、図 16-1 に示す Authentication Proxy Login ページが表示されます。

図 16-1 Authentication Proxy Login ページ

 


) この例で表示されている Cisco Systems テキスト フィールドは、auth-prompt コマンドを使用してカスタマイズされています。このコマンドのシンタックスの詳細については、『Cisco Security Appliance Command Reference』を参照してください。auth-prompt コマンドを使用して文字列を入力しない場合、このフィールドは空白になります。


ユーザが有効なユーザ名とパスワードを入力すると、「Authentication Successful」ページが自動的に表示され閉じられます。ユーザが有効なユーザ名とパスワードの入力に失敗すると、「Authentication Failed」ページが表示されます。

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

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

uauth timeout 0 が設定されている( uauth timeout が 0 に設定されている)場合は、HTTPS 認証が機能しないことがあります。HTTPS 認証を受けた後、ブラウザが複数の TCP 接続を開始して Web ページのロードを試みると、最初の接続はそのまま許可されますが、後続の接続に対しては認証が発生します。その結果、ユーザが認証ページに正しいユーザ名とパスワードを毎回入力しても、繰り返し認証ページが表示されます。この現象を回避するには、 timeout uauth 0:0:1 コマンドを使用して、 uauth timeout を 1 秒に設定します。ただし、この回避策ではウィンドウが 1 秒間開かれるため、このウィンドウを利用して、同じ送信元 IP アドレスからアクセスしてくる未認証のユーザがファイアウォールを通過する可能性があります。

HTTPS 認証は SSL ポート 443 で発生するため、HTTP クライアントから HTTP サーバに向かうポート 443 上のトラフィックをブロックするように access-list コマンド文を設定しないでください。また、ポート 80 上の Web トラフィックに対してスタティック PAT を設定する場合は、SSL ポートに対してもスタティック PAT を設定する必要があります。次の例では、1 行目で Web トラフィックに対してスタティック PAT を設定しているため、2 行目を追加して、HTTPS 認証コンフィギュレーションをサポートする必要があります。

static (inside,outside) tcp 10.132.16.200 www 10.130.16.10 www
static (inside,outside) tcp 10.132.16.200 443 10.130.16.10 443
 

aaa authentication secure-http-client が設定されていない場合、HTTP ユーザには、ブラウザ自身によって生成されたポップアップ ウィンドウが表示されます。
aaa authentication secure-http-client が設定されている場合、ユーザ名とパスワードを収集するためのフォームがブラウザにロードされます。どちらの場合でも、ユーザの入力したパスワードが誤っている場合は、ユーザは再入力を求められます。Web サーバと認証サーバがそれぞれ別ホスト上にある場合、正常な認証処理を実行するには virtual コマンドを使用します。

Web クライアントのセキュアな認証をイネーブルにするには、次の手順を実行します。


ステップ 1 HTTP 認証をイネーブルにします。認証をイネーブルにする方法の詳細については、「ネットワーク アクセス認証のイネーブル化」を参照してください。

ステップ 2 次のコマンドを入力して、Web クライアントのセキュアな認証をイネーブルにします。

aaa authentication secure-http-client

aaa authentication secure-http-client コマンドは、HTTP 認証をイネーブルにする前でもイネーブルにした後でも使用できます。必要に応じて、HTTP 認証をイネーブルにする前にこのコマンドを入力することで、HTTP 認証をイネーブルにした時点でユーザ名とパスワードがセキュアな Web クライアント認証で保護されているようにすることができます。



 

ネットワーク アクセス認可の設定

ユーザが所定の接続のための認証を受けると、セキュリティ アプライアンスは認可を使用して、ユーザからのトラフィックをさらに制御できます。

ここでは、次の項目について説明します。

「TACACS+ 認可の設定」

「RADIUS 認可の設定」

TACACS+ 認可の設定

TACACS+ でネットワーク アクセス認可を実行するように、セキュリティ アプライアンスを設定できます。認可規則が一致する必要のある ACL を指定することにより、認可するトラフィックを指定します。または、認可規則自体で直接、トラフィックを指定することもできます。


ヒント ACL を使用して認可するトラフィックを指定すると、入力する必要のある認可コマンドの数を大幅に少なくすることができます。これは、入力した各認可規則では、送信元と宛先のサブネットとサービスを 1 つだけ指定できるのに対して、ACL には多数のエントリを含めることができるためです。


認証文と認可文は互いに依存しませんが、認可文で一致した未認証トラフィックはすべて拒否されます。認可が成功するためには、ユーザは最初にセキュリティ アプライアンスで認証を受ける必要があります。所定の IP アドレスのユーザは、すべての規則およびタイプに対して一度だけ認証を受ければよいため、認証セッションが期限切れになっていなければ、トラフィックが認証文で一致した場合でも、認可が発生することがあります。

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

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

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


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

ステップ 2 access-list コマンドを使用して、認可するトラフィックの送信元アドレスと宛先アドレスを指定する ACL を作成します。手順については、「拡張アクセスリストの追加」を参照してください。

許可 ACE は、一致したトラフィックを認可するようにマークします。一方、 拒否 エントリは、一致したトラフィックを認可から除外します。認可の照合に使用する ACL には、認証の照合に使用する ACL の規則と同じ規則またはその一部が含まれている必要があります。


) 認証を設定済みで、なおかつ認証されたトラフィックをすべて認可する場合、
aaa authentication match コマンドで使用するために作成した ACL と同じ ACL を使用できます。


ステップ 3 認可をイネーブルにするには、次のコマンドを入力します。

hostname/contexta(config)# aaa authorization match acl_name interface_name server_group
 

acl_nameステップ 2 で作成した ACL の名前、 interface_name nameif コマンドまたはデフォルトで指定したインターフェイスの名前、 server_group は認証をイネーブルにしたときに作成した AAA サーバ グループです。


) もう 1 つの方法として、aaa authorization include コマンド(コマンド内でトラフィックを指定するコマンド)を使用することもできます。ただし、同一コンフィギュレーション内で両方の方法を使用することはできません。詳細については、Cisco Security Appliance Command Referenceを参照してください。



 

次のコマンドは、内部 Telnet トラフィックを認証し、認可します。209.165.201.5 以外のサーバに向かう Telnet トラフィックは認証だけを受けますが、209.165.201.5 に向かうトラフィックには認可が必要です。

hostname/contexta(config)# access-list TELNET_AUTH extended permit tcp any any eq telnet
hostname/contexta(config)# access-list SERVER_AUTH extended permit tcp any host 209.165.201.5 eq telnet
hostname/contexta(config)# aaa-server AuthOutbound protocol tacacs+
hostname/contexta(config-aaa-server-group)# exit
hostname/contexta(config)# aaa-server AuthOutbound (inside) host 10.1.1.1
hostname/contexta(config-aaa-server-host)# key TACPlusUauthKey
hostname/contexta(config-aaa-server-host)# exit
hostname/contexta(config)# aaa authentication match TELNET_AUTH inside AuthOutbound
hostname/contexta(config)# aaa authorization match SERVER_AUTH inside AuthOutbound
 

RADIUS 認可の設定

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

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

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


access-group コマンドを使用して ACL をインターフェイスに適用した場合は、per-user-override キーワードが、ユーザ固有の ACL による認可に対して次のように影響を与えることに注意してください。

per-user-override キーワードを使用しない場合、ユーザ セッションのトラフィックは、インターフェイス ACL とユーザ固有の ACL の両方によって許可される必要があります。

per-user-override キーワードを使用した場合、ユーザ固有の ACL によって許可される内容が決定されます。

詳細については、『 Cisco Security Appliance Command Reference 』の access-group コマンドの項を参照してください。


 

ここでは、次の項目について説明します。

「ダウンロード可能な ACL を送信するための RADIUS サーバの設定」

「ユーザごとの ACL 名をダウンロードするための RADIUS サーバの設定」

ダウンロード可能な ACL を送信するための RADIUS サーバの設定

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

「ダウンロード可能な ACL の機能と Cisco Secure ACS について」

「ダウンロード可能な ACL に関する Cisco Secure ACS の設定」

「ダウンロード可能な ACL に関する任意の RADIUS サーバの設定」

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

ダウンロード可能な ACL の機能と Cisco Secure ACS について

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

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

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

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

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

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

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

ACS:CiscoSecure-Defined-ACL=acl-set-name
 

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

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

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

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

AAA:service=ip-admission
AAA:event=acl-download
 

これに加えて、セキュリティ アプライアンスは Message-Authenticator アトリビュート(IETF RADIUS アトリビュート 80)で要求に署名します。

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

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

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

ip:inacl#1=ACE-1
ip:inacl#2=ACE-2
.
.
.
ip:inacl#n=ACE-n
 

AV のペアの例を次に示します。

ip:inacl#1=permit tcp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
 

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

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

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

ダウンロード可能な ACL に関する Cisco Secure ACS の設定

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

ACL 定義は、次のプレフィックスがない点を除いて拡張 access-list コマンド(「拡張アクセスリストの追加」を参照)に類似する 1 つまたは複数のセキュリティ アプライアンス コマンドで構成されます。

access-list acl_name extended
 

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

+--------------------------------------------+
| Shared profile Components |
| |
| Downloadable IP ACLs Content |
| |
| Name: acs_ten_acl |
| |
| ACL Definitions |
| |
| permit tcp any host 10.0.0.254 |
| permit udp any host 10.0.0.254 |
| permit icmp any host 10.0.0.254 |
| permit tcp any host 10.0.0.253 |
| permit udp any host 10.0.0.253 |
| permit icmp any host 10.0.0.253 |
| permit tcp any host 10.0.0.252 |
| permit udp any host 10.0.0.252 |
| permit icmp any host 10.0.0.252 |
| permit ip any any |
+--------------------------------------------+
 

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

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

#ACSACL#-ip-acl_name-number
 

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

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

access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit tcp any host 10.0.0.254
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit udp any host 10.0.0.254
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit icmp any host 10.0.0.254
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit tcp any host 10.0.0.253
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit udp any host 10.0.0.253
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit icmp any host 10.0.0.253
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit tcp any host 10.0.0.252
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit udp any host 10.0.0.252
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit icmp any host 10.0.0.252
access-list #ACSACL#-ip-asa-acs_ten_acl-3b5385f7 permit ip any any
 

ダウンロード可能な ACL に関する任意の RADIUS サーバの設定

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

cisco-av-pair VSA で、 access-list extended コマンド(「拡張アクセスリストの追加」を参照)と類似する 1 つまたは複数の ACE を設定します。ただし、次のコマンド プレフィックスを置き換える必要があります。

access-list acl_name extended
 

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

ip:inacl#nnn=
 

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

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

ip:inacl#1=permit tcp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
ip:inacl#99=deny tcp any any
ip:inacl#2=permit udp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
ip:inacl#100=deny udp any any
ip:inacl#3=permit icmp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
 

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

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

AAA-user-username
 

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

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

access-list AAA-user-bcham34-79AD4A08 permit tcp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
access-list AAA-user-bcham34-79AD4A08 permit udp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
access-list AAA-user-bcham34-79AD4A08 permit icmp 10.1.0.0 255.0.0.0 10.0.0.0 255.0.0.0
access-list AAA-user-bcham34-79AD4A08 deny tcp any any
access-list AAA-user-bcham34-79AD4A08 deny udp any any
 

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

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

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

ACL ネットマスク変換は、 acl-netmask-convert コマンドを使用してサーバごとに設定できます。このコマンドは AAA サーバ コンフィギュレーション モードで使用できます。RADIUS サーバの設定方法の詳細については、「AAA サーバ グループおよびサーバの識別」を参照してください。 acl-netmask-convert コマンドの詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。

ユーザごとの ACL 名をダウンロードするための RADIUS サーバの設定

ユーザ認証時に、セキュリティ アプライアンスで作成済みの ACL の名前を RADIUS サーバからダウンロードするには、IETF RADIUS filter-id アトリビュート(アトリビュート番号 11)を次のように設定します。

filter-id=acl_name
 

) Cisco Secure ACS では、filter-id アトリビュートの値は、HTML インターフェイスのボックスで、filter-id= を省略し、acl_name だけを入力して指定します。


filter-id アトリビュートの値をユーザごとに一意にする方法については、ご使用の RADIUS サーバのマニュアルを参照してください。

セキュリティ アプライアンス上に ACL を作成する方法については、「拡張アクセスリストの追加」を参照してください。

ネットワーク アクセスのアカウンティングの設定

セキュリティ アプライアンスは、セキュリティ アプライアンスを通過する任意の TCP トラフィックまたは UDP トラフィックについてのアカウンティング情報を RADIUS サーバまたは TACACS+ サーバに送信できます。そのトラフィックも認証されている場合、AAA サーバはユーザ名でアカウンティング情報を保持できます。そのトラフィックが認証されていない場合、AAA サーバは IP アドレスでアカウンティング情報を保持できます。アカウンティング情報には、セッションの開始時刻と終了時刻、ユーザ名、そのセッションでセキュリティ アプライアンスを経由したバイト数、使用されたサービス、セッションの継続時間が含まれます。

アカウンティングを設定するには、次の手順を実行します。


ステップ 1 ユーザごとのアカウンティング データを提供するようにセキュリティ アプライアンスを設定する場合は、認証をイネーブルにする必要があります。詳細については、「ネットワーク アクセス認証のイネーブル化」を参照してください。IP アドレスごとのアカウンティング データを提供するようにセキュリティ アプライアンスを設定する場合は、認証をイネーブルにする必要はありません。次のステップに進みます。

ステップ 2 access-list コマンドを使用して、アカウンティング対象のトラフィックの送信元アドレスと宛先アドレスを指定する ACL を作成します。手順については、「拡張アクセスリストの追加」を参照してください。

許可 ACE は、一致したトラフィックを認可するようにマークします。一方、 拒否 エントリは、一致したトラフィックを認可から除外します。


) 認証が設定済みで、なおかつ認証されたすべてのトラフィックのアカウンティング データが必要な場合、aaa authentication match コマンドで使用するために作成した ACL と同じ ACL を使用できます。


ステップ 3 アカウンティングをイネーブルにするには、次のコマンドを入力します。

hostname/contexta(config)# aaa accounting match acl_name interface_name server_group
 

) もう 1 つの方法として、aaa accounting include コマンド(コマンド内でトラフィックを指定するコマンド)を使用することもできます。ただし、同一コンフィギュレーション内で両方の方法を使用することはできません。詳細については、『Cisco Security Appliance Command Reference』を参照してください。



 

次のコマンドは、内部 Telnet トラフィックを認証、認可、アカウンティングします。209.165.201.5 以外のサーバに向かう Telnet トラフィックは認証だけを受けますが、209.165.201.5 に向かうトラフィックには認可およびアカウンティングが必要です。

hostname/contexta(config)# aaa-server AuthOutbound protocol tacacs+
hostname/contexta(config-aaa-server-group)# exit
hostname/contexta(config)# aaa-server AuthOutbound (inside) host 10.1.1.1
hostname/contexta(config-aaa-server-host)# key TACPlusUauthKey
hostname/contexta(config-aaa-server-host)# exit
hostname/contexta(config)# access-list TELNET_AUTH extended permit tcp any any eq telnet
hostname/contexta(config)# access-list SERVER_AUTH extended permit tcp any host 209.165.201.5 eq telnet
hostname/contexta(config)# aaa authentication match TELNET_AUTH inside AuthOutbound
hostname/contexta(config)# aaa authorization match SERVER_AUTH inside AuthOutbound
hostname/contexta(config)# aaa accounting match SERVER_AUTH inside AuthOutbound
 

MAC アドレスによるトラフィックの認証と認可の免除

セキュリティ アプライアンスは、特定の MAC アドレスからのトラフィックの認証および認可を免除できます。

たとえば、特定のネットワーク上で発信された TCP トラフィックを認証するようにセキュリティ アプライアンスが設定された状態で、特定のサーバからの未認証 TCP 接続を許可するには、まず、 mac-list コマンドを使用して、そのサーバの MAC アドレスからのトラフィックを許可する規則を作成します。次に、 aaa mac-exempt コマンドを使用して、その MAC リストで指定したサーバからのすべてのトラフィックの認証および認可を免除します。

これとは逆に、特定のコンピュータからのトラフィックを認証にかかわらず常に許可しない場合は、その MAC アドレスからのトラフィックを拒否する mac-list コマンドで、このコンピュータの MAC アドレスを使用できます。このシナリオで使用している aaa mac-exempt コマンドにより、これ以外の場合であれば認証規則で許可されるトラフィックでも、このコンピュータからのトラフィックは拒否されます。

MAC アドレスを使用してトラフィックの認証および認可を免除するには、次の手順を実行します。


ステップ 1 MAC リストを設定するには、次のコマンドを入力します。

hostname/contexta(config)# mac-list id {deny | permit} mac macmask
 

id は MAC リストに割り当てる 16 進数値、 mac はトラフィックを許可または拒否するコンピュータの MAC アドレス、 macmask は MAC アドレス マスクです。 mac-list コマンドの詳細については、『 Cisco Security Appliance Command Reference 』を参照してください。

ステップ 2 特定の MAC リストで指定されている MAC アドレスのトラフィックに対して免除するには、次のコマンドを入力します。

hostname/contexta(config)# aaa mac-exempt match id
 

id は、認証および認可を免除するトラフィックの MAC アドレスが含まれている MAC リストを指定する文字列です。


 

次のコマンドは、2 つの MAC リストを作成します。各リストには、1 つの MAC アドレスが含まれています。1 つのリストは、リストにある MAC アドレスからのトラフィックを許可し、もう 1 つのリストは、リストにある MAC アドレスからのトラフィックを拒否します。最後の 2 つのコマンドは、2 つのリストにある MAC アドレスから発信されたすべてのトラフィックの認証および認可を免除するようにセキュリティ アプライアンスを設定します。

hostname/contexta(config)# mac-list adc permit 00a0.cp5d.0282 ffff.ffff.ffff
hostname/contexta(config)# mac-list ac deny 0061.54ff.b440 ffff.ffff.ffff
hostname/contexta(config)# aaa mac-exempt match adc
hostname/contexta(config)# aaa mac-exempt match ac