Cisco Traffic Anomaly Detector Module コンフィギュレーション ガイド (Software Release 5.1)
- Updated:
- 2017年6月16日
章のタイトル： Detector モジュール の設定
Detector モジュールの設定
この章では、Cisco Traffic Anomaly Detector Module（Detector モジュール）のサービスの設定方法について説明します。
•
Cisco Anomaly Guard Module との通信の確立
• 日付と時刻の設定
• SSH 鍵の管理
• ホスト名の変更
Detector モジュールのサービスのアクティブ化
Detector モジュールでアクティブにするサービスを定義することができます。正しい機能をイネーブルにするためには、サービスをイネーブルにして、そのサービスへのアクセスを許可する必要があります。Detector モジュールのサービスのアクティベーションを制御し、特定の IP アドレスに対してアクセス権を付与または拒否することにより、Detector モジュールにアクセスして制御する IP アドレスを制限することができます。
表4-1 で、Detector モジュールのサービスについて説明します。
|
|
|
|---|---|
|
|
ノード間通信サービス。Detector モジュールは、Cisco Anomaly Guard Module との通信チャネルを確立するときにこのサービスを使用します。 詳細については、「Cisco Anomaly Guard Module との通信の確立」を参照してください。 |
|
|
SNMP サーバ サービス。SNMP を使用して Detector モジュールにアクセスすることにより、Riverhead の専用 MIB、MIB2、および UCDavis MIB で定義された情報を取得することができます。 MIB 定義の詳細については、このソフトウェア バージョンでリリースされた MIB ファイルを参照してください。 
（注） Riverhead MIB には、64 ビットのカウンタが含まれています。MIB を読み取るには、SNMP バージョン 2 をサポートするブラウザを使用する必要があります。 |
|
|
SNMP トラップ サービス。snmp-trap サービスをアクティブにすると、Detector モジュールは SNMP トラップを生成します。詳細については、「SNMP トラップのイネーブル化」を参照してください。 |
|
|
Secure Shell（SSH; セキュア シェル）サービス。SSH サービスは常にアクティブです。詳細については、「SSH を使用した Detector モジュールへのアクセス」および「SSH 鍵の管理」を参照してください。 |
|
|
Web-Based Management（WBM）サービス。Web ブラウザを使用して Web から Detector モジュールを制御できます。詳細については、「Web-Based Manager による Detector モジュールの管理」を参照してください。 |
Detector モジュールのサービスをアクティブにするには、次の手順を実行します。
ステップ 1 設定モードで次のコマンドを入力して、Detector モジュールのサービスをイネーブルにします。
Detector モジュールのサービスについては、 表4-1 を参照してください。デフォルトでは、SSH 以外、Detector モジュールのすべてのサービスはディセーブルになっています。
ステップ 2 設定モードで次のコマンドを入力して、Detector モジュールのサービスへのアクセスを許可し、接続をイネーブルにします。
表4-2 に、 permit コマンドの引数を示します。
|
|
|
|---|---|
|
|
アクセスと操作の対象となるサービス。Detector モジュールのサービスについては、 表4-1 を参照してください。 |
|
|
アクセスを許可する IP アドレス。IP アドレスをドット区切り 10 進表記で入力します（たとえば 192.168.10.2）。すべての IP アドレスからのアクセスを許可するには、アスタリスク（*）を使用します。 |
|
|
（オプション）IP サブネット マスク。サブネット マスクをドット区切り 10 進表記で入力します（たとえば 255.255.255.0）。デフォルトのサブネット マスクは、255.255.255.255 です。 |
AAA を使用したアクセス コントロールの設定
認証、認可、アカウンティング（AAA）とは、誰に対して Detector モジュールへのアクセスを許可するか、またアクセス後にどのサービスを許可するかを制御する方式のことです。AAA には次の機能があります。
• 認証：ユーザに対しシステムおよびシステム サービスへのアクセスを許可する前に、そのユーザを識別します。
• 認可：ユーザがシステムへのアクセス権を取得した後で、実行が許可される内容を決定します。このプロセスは、ユーザ認証後に発生します。
• アカウンティング：ユーザが実行中または実行済みの内容を記録します。アカウンティングにより、ユーザがアクセスしているサービスを追跡することができます。
Detector モジュールには、次のシステム ユーザ アカウントがあらかじめ設定されています。
• admin：admin ユーザ アカウントには、Detector モジュールの CLI およびすべての機能にアクセスできる管理アクセス権が設定されています。Detector モジュールの CLI に初めて接続すると、このアカウントに対するパスワードを設定するように要求されます。新しいユーザ アカウントを設定するには admin ユーザ アカウントを使用します。
• riverhead：riverhead ユーザ アカウントには、ダイナミック（dynamic）のアクセス権が設定されています。Detector モジュールはこのユーザ アカウントを使用して、Cisco Anomaly Guard Module との最初の通信チャネルを確立します。Detector モジュール CLI に初めて接続すると、このアカウントに対するパスワードを設定するように要求されます。
ユーザ定義を使用すると、Detector モジュールのユーザ コミュニティをドメインに分割し、安全な管理アクセスのためにパスワードを割り当てることができます。初期設定が完了した後は、ユーザのアクションを監視できるように新しいアカウントを作成し、システム ユーザ アカウントは使用しないことをお勧めします。
次の各項では、アクセス コントロールの設定方法について説明します。
• 認証の設定
• 認可の設定
認証の設定
ユーザが Detector モジュールにログインしようとしたとき、または（ enable コマンドを使用して）上位の特権レベルを要求したときに、Detector モジュールで使用する認証方式を設定することができます。Detector モジュールは、次の認証オプションを提供します。
• ローカル認証：ローカルに設定されたログイン名およびイネーブル パスワードが認証に使用されます。この認証方式がデフォルトです。詳細については、「ローカル認証の設定」を参照してください。
• TACACS+ 認証：1 つの TACACS+ サーバまたは複数の TACACS+ サーバのリストを使用してユーザが認証されます。
ユーザを 1 つの TACACS+ サーバのみに設定する場合、その TACACS+ サーバでユーザに対して認可も設定する必要があります。設定しないと、そのユーザは show コマンドにしかアクセスできません。
シーケンシャルな認証リストを設定することができます。認証リストとは、ユーザ認証に使用する認証方式を定義したもので、1 つ以上の認証方式を指定でき、最初の認証方式が失敗した場合はバックアップが提供されます。
Detector モジュールは、この順次認証リスト上の最初の認証方式を使用してユーザを認証します。認証方式からの応答がない場合は、Detector モジュールはリスト上の 2 番目の認証方式を使用します。認可方式が両方とも成功しなかった場合にのみ、ユーザ認証は失敗します。
分散認証方式を設定し、ユーザを別々の認証データベースに定義することができます。Detector モジュールは、最初の TACACS+ サーバを使用してユーザを認証します。認証で拒否が返された場合、Detector モジュールは TACACS+ サーバ リスト、および、存在する場合は代替の認証方式（ローカル）をスキャンします。リスト上のすべての認証方式が失敗した場合にのみ、認証が失敗します。このオプションは、first-hit オプションを設定していない場合にのみ有効です。
（注） ユーザ データベースが、複数の TACACS+ サーバに分散している、または 1 つの TACACS+ サーバとローカル ユーザ データベースに分散している場合は、no tacacs-server first-hit コマンドを使用してください。これを使用しないと、最初の認証方式から拒否が返された後、認証が失敗します。
• 認証方式の設定
認証方式の設定
Detector モジュールで使用する認証方式を設定するには、次の手順を実行します。
ステップ 1 TACACS+ 認証が必要な場合は、TACACS+ サーバ接続を設定します。詳細については、「TACACS+ サーバ アトリビュートの設定」を参照してください。
ステップ 2 設定モードで次のコマンドを入力し、認証方式を定義します。
表4-3 に、 aaa authentication コマンドのキーワードを示します。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
コンソール セッションから Detector モジュールにアクセスする場合、Detector モジュールは、定義されている認証方式に関係なく、認証にローカル ユーザ データベースを使用します。
次の例は、上位の特権レベルに入る際に認証を行うように設定する方法を示しています。最初の認証方式は TACACS+ に設定され、2 番目の認証方式はローカル ユーザ データベースに設定されています。
ローカル認証の設定
Detector モジュールには、管理者特権を持つユーザ名があらかじめ設定されています。このユーザ名を使用して新しいユーザを作成できます。ユーザ定義を使用すると、Detector モジュールのユーザ コミュニティをドメインに分割し、安全な管理アクセスのためにパスワードを割り当てることができます。
TACACS+ サーバを使用した CLI ユーザの認証をイネーブルにするには、「認証の設定」を参照してください。
• ユーザの追加
ユーザの追加
Detector モジュールのローカル データベースにユーザを追加するには、設定モードで次のコマンドを使用します。
username username {admin | config | dynamic | show} [ password ]
表4-4 に、 username コマンドの引数とキーワードを示します。
|
|
|
|---|---|
ユーザ名。1 ～ 63 文字の英数字の文字列です。大文字と小文字が区別され、先頭は英字である必要があります。この文字列にはスペースを含めることはできませんが、アンダースコアを含めることはできます。 |
|
ユーザの特権レベル。詳細については、 表3-1 を参照してください。 |
|
（オプション）パスワード。6 ～ 24 文字の文字列を入力します。スペースは使用できず、大文字と小文字が区別されます。パスワードを入力しない場合、入力するよう要求されます。 |
次の例は、新しいユーザを設定し、パスワードを設定する方法を示しています。
ユーザはクリア テキストでパスワードを入力しますが、Detector モジュールの設定ファイルでは、パスワードが暗号化されて表示されます。次の例は、Detector モジュールの設定ファイル（running-config）を表示します。
上の例の encrypted キーワードは、パスワードが暗号化されていることを示しています。
Detector モジュール上に設定されているユーザのリストを表示するには、 show running-config コマンドまたは show detector コマンドを使用します。
自分のパスワードの変更
ユーザは、自分自身のパスワードを変更することができます。管理者は、自分自身のパスワードと、他のユーザのパスワードを変更できます（「他のユーザのパスワードの変更」を参照）。
ステップ 1 グローバル モードで次のコマンドを入力します。
ステップ 2 現在のパスワードを入力します。新しいパスワードの入力を求めるプロンプトが表示されます。
パスワードは、スペースを含まない、6 ～ 24 文字の英数字の文字列である必要があります。パスワードでは大文字と小文字が区別されます。新しいパスワードをもう一度入力し、確認するように求めるプロンプトが表示されます。
他のユーザのパスワードの変更
他のユーザのパスワードを変更するには、管理ユーザ特権を持っている必要があります。
特定のユーザのパスワードを変更するには、次の手順を実行します。
ステップ 1 グローバル モードで次のコマンドを入力します。
username-password 引数は、変更対象のパスワードを持つユーザです。
パスワードは、スペースを含まない、6 ～ 24 文字の英数字の文字列である必要があります。パスワードでは大文字と小文字が区別されます。新しいパスワードをもう一度入力し、確認するように求めるプロンプトが表示されます。
次の例では、管理者がユーザ John のパスワードを変更しています。
ローカル ユーザ データベースからのユーザの削除
ローカル ユーザ データベースからユーザを削除すると、そのローカル ユーザ データベースのみを使用して認証を行っている場合、関連付けられているユーザが Detector モジュールにアクセスできなくなります。
Detector モジュールのローカル ユーザ データベースからユーザを削除するには、no username username コマンドを使用します。
次の例は、ローカル ユーザ データベースからユーザを削除する方法を示しています。
認可の設定
ユーザが使用できるサービスを制限することができます。認可をイネーブルにすると、Detector モジュールはユーザ プロファイルを確認します。ユーザ プロファイルは、ローカル ユーザ データベース内または TACACS+ セキュリティ サーバ上にあります。ユーザは、そのユーザのプロファイル内の情報で許可されている場合にのみ、要求したサービスへのアクセスを許可されます。
ユーザがコマンドを実行しようとするときに Detector モジュールで使用する認可方式を設定することができます。Detector モジュールでは、次の認可オプションが提供されています。
• TACACS+ 認可：TACACS+ サーバを使用してユーザが認可されます。後続のサーバが定義されている場合は、1 つのサーバとの通信が失敗した場合にのみ、その後続のサーバへのアクセスが開始されます。
次の 2 種類の TACACS+ 認可がサポートされています。
–EXEC 認可：ユーザが Detector モジュールにログインして認証されたときに、そのユーザの特権レベルを決定します。
–コマンド認可：ユーザがコマンドを入力すると、そのコマンドの許可を取得するために、TACACS+ サーバを調べます。
TACACS+ 認可では、コマンドごとにアクセス権を指定できます。
• ローカル認可：コマンド グループのアクセス コントロールにローカルで設定されたユーザ プロファイルが使用されます。認可は、指定された特権レベルのすべてのコマンドに対して定義されます。この認可方式がデフォルトです。
Detector モジュールのローカル認可は、TACACS+ サーバへの通信に失敗した場合に実行することができます。
ユーザ認証方式を定義する順次認証リストを設定できます。順次認証リストには認証に使用する方式を 1 つ以上指定でき、最初の認証方式への通信が失敗した場合は、バックアップが提供されます。
Detector モジュールは、最初にリストされた方式を使用してユーザを認可します。その方式が応答しない場合、Detector モジュールは 2 番目の認可方式を選択します。認可方式が両方とも成功しなかった場合にのみ、認可は失敗します。
Detector モジュールが認証拒否を最終的なものと見なし、それ以上他の TACACS+ サーバやローカル ユーザ データベースを検索しないように設定するために、TACACS+ サーバ アトリビュートを設定できます。詳細については、「TACACS+ サーバ アトリビュートの設定」を参照してください。
• 認可方式の設定
ローカル認可の設定
Detector のサービスにアクセスできるかどうかは、ユーザの特権レベルによって決まります。システム管理者は、ユーザが使用できるサービスを制限することができます。Detector モジュールは、ユーザのプロファイルをチェックして、ユーザのアクセス権を確認します。認可されると、ユーザは、そのユーザのプロファイル内の情報で許可されている場合にのみ、要求したサービスへのアクセス権を付与されます。ユーザの特権レベルについては、 表3-1 を参照してください。
パスワードを使用した特権レベルの割り当て
管理者は、ユーザの特権レベルへのアクセスを制限するパスワードを設定できます。特権レベルおよびパスワードを指定したら、この特権レベルにアクセスする必要のあるユーザにそのパスワードを付与することができます。他のユーザ特権レベルのパスワードを設定する前に、そのユーザ特権レベルに移動することはできません。
ローカル パスワードを設定して特権レベルへのアクセスを制御するには、設定モードで次のコマンドを使用します。
enable password [ level level] [ password ]
表4-5 に、 enable password コマンドの引数を示します。
|
|
|
|---|---|
（オプション）ユーザの特権レベル。レベルには、admin、config、dynamic、show のいずれかを指定できます。デフォルトのレベルは admin です。詳細については、 表3-1 を参照してください。 |
|
|
|
（オプション）特権レベルのパスワード。パスワードは、スペースを含まない、6 ～ 24 文字の英数字の文字列である必要があります。パスワードでは大文字と小文字が区別されます。パスワードを入力しない場合、入力するよう要求されます。 |
次の例は、ユーザの特権レベル admin にパスワードを割り当てる方法を示しています。
ユーザ特権レベル間の移動
認可されたユーザは、ユーザ特権レベル間を移動することができます。
ステップ 1 グローバル モードで次のコマンドを入力します。
level 引数には、ユーザの特権レベルを指定します。このレベルには、admin、config、dynamic のいずれかを指定できます。デフォルトのレベルは admin です。詳細については、 表3-1 を参照してください。
次の例は、ユーザの特権レベル admin に切り替える方法を示しています。
認可方式の設定
ステップ 1 TACACS+ 認可が必要な場合は、TACACS+ サーバ接続を設定します。詳細については、「TACACS+ サーバ アトリビュートの設定」を参照してください。
ステップ 2 設定モードで次のいずれかのコマンドを入力して、認可方式を定義します。
• aaa authorization exec tacacs+
• aaa authorization commands level { local | tacacs+ } [ local ]
認可方式のシーケンシャルなリストを設定できます。各方式について、 aaa authorization コマンド を入力します。認証方式を削除するには、このコマンドの no 形式を使用します。
表4-6 に、 aaa authorization コマンドの引数とキーワードを示します。
|
|
|
|---|---|
ユーザが EXEC シェルの実行を許可されているかどうかを判別するために認可が実行されます。Detector モジュールは、TACACS+ サーバに確認して、認証されたユーザの特権レベルを判別します。
|
|
指定された特権レベルのすべてのコマンドに対して認可が実行されます。複数の特権レベルの認可を設定するには、認可が必要な特権レベルごとにこのコマンドを使用します。 |
|
指定された特権レベルの認可を定義します。有効なエントリは、show、dynamic、config、および admin です。ユーザの特権レベルについては、 表3-1 を参照してください。 |
|
パフォーマンスに影響する可能性があるため、 show 特権レベルコマンドに対する認可は設定しないことをお勧めします。
（注） コンソール セッションから入力したコマンドには、TACACS+ 認可は実行されません。
次の例は、config 特権レベルを必要とするコマンドの認可を設定する方法を示しています。最初の認可方式は TACACS+ に設定され、2 番目の認可方式はローカル ユーザ データベースに設定されています。
TACACS+ サーバの設定例
TACACS+ サーバのデータベースで、各コマンドの認可を指定することができます。
次の例は、ユーザ Zoe に対して、TACACS+ サーバ上で認可を設定する方法を示しています。
ゾーン名のタブ補完のディセーブル化
ゾーン設定へのアクセスを認可されたユーザのみに制限するには、ゾーン名のタブ補完をディセーブルにします。この設定は、ゾーン名を指定するすべてのコマンドに適用されます。
グローバル モードまたは設定モードで zone コマンド、 no zone コマンド、 show zone コマンド、および deactivate コマンドなどのコマンドを入力しても、Detector モジュールはゾーン名の表示や補完を行わなくなります。ゾーン名を完全に入力する、ゾーン操作モードを変更する、またはゾーン統計情報を表示する必要があります。
ゾーン名のタブ補完をディセーブルにすると、Detector モジュールは
tab-complete zone-list コマンドを TACACS+ サーバに送信します。認可されたユーザに対してゾーン名のタブ補完をイネーブルにするには、 tab-complete zone-list コマンドに対する認可を TACACS+ サーバ上で設定します。
次の例は、すべての zone コマンドでゾーン名のタブ補完をディセーブルにする方法を示しています。
アカウンティングの設定
アカウンティング管理により、ユーザがアクセスしているサービスを追跡し、TACACS+ サーバにアカウンティング情報を保存することができます。課金、レポート、またはセキュリティ目的で、要求されたサービスのアカウンティングをイネーブルにできます。デフォルトでは、Detector モジュールでアカウンティング管理はディセーブルに設定されています。
ステップ 1 TACACS+ サーバ接続を設定します。詳細については、「TACACS+ サーバ アトリビュートの設定」を参照してください。
ステップ 2 アカウンティングが必要な特権ごとに設定モードでこのコマンドを入力して、複数の特権レベルのアカウンティングを設定します。
表4-7 に、 aaa accounting コマンドのキーワードを示します。
|
|
|
|---|---|
指定された特権レベルのアカウンティングを定義します（ユーザの特権レベルについては、 表3-1 を参照）。 |
|
パフォーマンス影響する可能性があるため、アカウンティング管理は config ユーザ特権レベルにのみイネーブルにすることをお勧めします。
特権レベルのアカウンティング管理を削除するには、このコマンドの no 形式を使用します。
次の例は、TACACS+ サーバ上で config 特権レベルを必要とするコマンドのアカウンティングを設定する方法を示しています。
TACACS+ サーバ アトリビュートの設定
TACACS+ サーバで認証、認可、またはアカウンティングをイネーブルにするには、TACACS+ サーバ アトリビュートを設定する必要があります。
TACACS+ サーバのアトリビュートを設定するには、次の手順を実行します。
ステップ 1 tacacs-server host ip-address コマンドを入力して、TACACS+ サーバの IP アドレスを設定します。
詳細については、「TACACS+ サーバの IP アドレスの設定」を参照してください。
ステップ 2 tacacs-server key tacacs-key コマンドを入力して、Detector モジュールが TACACS+ サーバへのアクセスに使用する暗号鍵を設定します。
詳細については、「TACACS+ サーバの暗号鍵の設定」を参照してください。
ステップ 3 （オプション） tacacs-server first-hit コマンドを入力して、Detector モジュールが認証に使用する検索方式を設定します。
詳細については、「TACACS+ 検索方式の設定」を参照してください。
ステップ 4 （オプション） tacacs-server timeout timeout コマンドを入力して、TACACS+ サーバ接続のタイムアウトを設定します。
詳細については、「TACACS+ サーバの接続タイムアウトの設定」を参照してください。
ステップ 5 show tacacs statistics コマンドを入力して、TACACS+ サーバ接続の統計情報を表示します。
詳細については、「TACACS+ サーバの統計情報の表示」を参照してください。
TACACS+ サーバの IP アドレスの設定
Detector モジュールが TACACS+ サーバの一連のリストを認証、認可、およびアカウンティングに使用するように設定できます。Detector モジュールは、リストされた TACACS+ サーバを使用してユーザを認証または認可するか、あるいはアカウンティング イベントを送信します。そのサーバが応答しない場合、Detector モジュールは 2 番目のサーバを選択します。リスト上のすべてのサーバが応答しなかった場合にのみ、認証または認可は失敗します。
または、Detector モジュールがリストの最初の TACACS+ サーバのみを使用してユーザを認証するように設定することもできます（詳細については、「TACACS+ 検索方式の設定」を参照）。
リストには、各 TACACS+ サーバの IP アドレスを定義する必要があります。最大 9 つの TACACS+ サーバを定義できます。
リストに TACACS+ サーバを追加し、IP アドレスを割り当てるには、設定モードで次のコマンドを使用します。
ip-address 引数には、TACACS+ サーバの IP アドレスを指定します。
TACACS+ サーバは、入力した順序でリストに追加されます。リストには、最大 9 つのサーバを追加できます。
次の例は、TACACS+ サーバ リストにサーバを追加する方法を示しています。
-conf# tacacs-server host 192.168.33.45
TACACS+ サーバの暗号鍵の設定
TACACS+ サーバにアクセスするには、暗号鍵を設定する必要があります。暗号鍵は、TACACS+ サーバ上の暗号鍵と一致する必要があります。暗号鍵にスペースを含めることはできません。
サーバの暗号アクセス鍵を設定するには、設定モードで次のコマンドを使用します。
（注） 定義できる暗号鍵は 1 つだけです。複数の TACACS+ サーバを使用する場合、Detector モジュールは、同じ鍵を使用して、すべての TACACS+ サーバとの通信を暗号化します。
次の例は、TACACS+ サーバの暗号鍵を MyKey に設定する方法を示しています。
TACACS+ 検索方式の設定
Detector モジュールが認証拒否を最終的なものと見なし、それ以上他の
TACACS+ サーバやローカル ユーザ データベースを検索しないように設定するには、 tacacs-server first-hit コマンドを使用します。Detector モジュールは、サーバ リストの、最初に応答する TACACS+ サーバだけを使用してユーザ認証を実行します。最初の TACACS+ サーバが応答しない場合、Detector モジュールはリストにある次のサーバを選択します。Detector モジュールは、ユーザ認証に対して最初に受け取る承認または拒否を最終的なものと見なし、他の TACACS+ サーバまたはローカル ユーザ データベースを使用したそのユーザ認証の試行を停止します。
tacacs-server first-hit コマンドを入力して認証拒否を最終的なものと見なすように TACACS+ 検索方式を設定していない場合、Detector モジュールはデフォルトでリスト内のすべての TACACS+ サーバを使用してユーザ認証を試みます。ユーザ認証として first-hit 検索方式をイネーブルにする（ no tacacs-server first-hit コマンドを入力する）と、Detector モジュールは、リストの最初にある TACACS+ サーバを使用してユーザを認証します。最初のサーバが応答しなかった、またはユーザの認証に失敗した場合は、Detector モジュールはリストにある次のサーバを選択します。リストにあるすべての TACACS+ サーバが応答しなかった場合、またはユーザ認証に失敗した場合、ローカルの認証方式が設定されていないと、そのユーザ認証は失敗します。TACACS+ 検索方式は認証のみに適用できるもので、認可やアカウンティングには影響しません。
Detector モジュールがリストの最初の TACACS+ サーバのみを使用してユーザ認証するように設定するには、設定モードで tacacs-server first-hit コマンドを使用します。
first-hit 検索方式をディセーブルにし、Detector モジュールがリスト内のすべての TACACS+ サーバを使用してユーザ認証を試みるようにするには、設定モードで no tacacs-server first-hit コマンドを使用します。
次の例は、Detector モジュールがリスト内の最初の TACACS+ サーバのみを使用してユーザ認証をするように、TACACS+ 検索方式を設定する方法を示しています。
TACACS+ サーバの接続タイムアウトの設定
Detector モジュールが TACACS+ サーバからの応答を待つ時間を設定できます。タイムアウトが終了すると、Detector モジュールは次の TACACS+ サーバ（そのようなサーバが設定されている場合）との接続を確立しようとするか、ローカルの AAA にフォールバックします（フォールバックが設定されている場合）。フォールバックの方式が設定されていない場合、認証と認可は失敗します。
（注） すべての TACACS+ サーバとの通信に同じサーバ タイムアウトが使用されます。
TACACS+ サーバの接続タイムアウトを設定するには、設定モードで次のコマンドを使用します。
timeout 引数には、Detector モジュールが TACACS+ サーバの応答を待つ時間を秒単位で指定します。デフォルトのタイムアウトは 0 です。
次の例は、TACACS+ サーバの接続タイムアウトを 600 秒に設定する方法を示しています。
ヒント ネットワークに問題がある場合や、TACACS+ サーバの応答が遅いためにタイムアウトが繰り返し発生する場合は、タイムアウトの値を大きくすることができます。
TACACS+ サーバの統計情報の表示
TACACS+ サーバの統計情報を表示できます。Detector モジュールは、サーバごとに統計データを提供します。
TACACS+ 関連の統計情報を表示するには、設定モードで show tacacs statistics コマンドを使用します。
TACACS+ の統計情報をクリアするには、設定モードで clear tacacs statistics コマンドを使用します。
表4-8 に、 show tacacs statistics コマンド出力のフィールドを示します。
|
|
|
|---|---|
Cisco Anomaly Guard Module との通信の確立
Detector モジュールと Cisco Anomaly Guard Module（Guard モジュール）との間に安全な通信チャネルを確立して、次のタスクをイネーブルにすることができます。
• Remote activation of zone protection：Detector モジュールはゾーン トラフィックの異常を検出すると、通信チャネルを使用して、Guard モジュールによるゾーン保護をアクティブにします。
• Synchronization of zone configuration information：Detector モジュールと Guard モジュールは、通信チャネルを介してゾーン設定情報を交換します。
Detector モジュールは Guard モジュールとの接続を確立し、通信チャネルの確保に必要な暗号鍵と証明書を交換します。その後 Detector モジュールは接続を閉じ、Guard モジュールをアクティブにする、Guard モジュールとゾーン設定を同期させる、または Guard モジュールにポーリングする必要がある場合に、通信チャネルを確立します。
Detector モジュールは、次の 2 つのタイプの通信チャネルをサポートしています。
• Secure Sockets Layer（SSL）：Remote activation of zone protection および Synchronization of zone configuration information をイネーブルにします。
• セキュア シェル 2（SSH2）：Remote activation of zone protection のみをイネーブルにします。
Detector モジュールは Guard モジュールのリスト（リモート Guard リストと呼ばれる）を保持し、このリスト上の Guard モジュールのゾーン保護をアクティブにしたり、これらの Guard とゾーン設定を同期させたりします。Detector モジュールは、リモート Guard リストに設定されている各 Guard モジュールと通信チャネルを確立します。Guard モジュールとの通信チャネルを確立する前に、リモート Guard リストに Guard モジュールを追加しておく必要があります。詳細については、「ゾーンを保護するためのリモート Guard のアクティブ化」を参照してください。
Detector モジュールは、SSL 通信チャネルを確立する前に各 Guard モジュールと SSH2 通信チャネルを確立します。SSL リモート Guard リストおよび SSH リモート Guard リストを設定する場合は、SSH2 通信チャネルを確立する必要はありません。
SSL 通信チャネルの設定
Guard モジュールと Detector モジュールは、通信チャネルに SSL 接続を使用します。SSL とは、認証とデータの暗号化を組み合せることにより安全な接続を提供するもので、デジタル証明書、秘密と公開の鍵交換ペア、および Diffie-Hellman 鍵合意パラメータによって高度なセキュリティを実現します。SSL は、指定された受信者のみがデータを解読できるようにデータを暗号化します。
各 Guard モジュールおよび各 Detector モジュールは、通信チャネル経由で通信を試みるデバイスに対し、デジタル証明書やそのデバイス固有の情報（デバイスの IP アドレスなど）を使用して認証を行います。
安全な接続を確保するために、Detector モジュールは秘密および公開鍵ペアを生成し、公開鍵をリモート Guard リスト内の Guard モジュールに配布します。
Guard モジュールで通信チャネル サービスをイネーブルにした後で、Detector モジュールから通信チャネルを確立します。Detector モジュールはまず、Guard モジュール上のユーザ riverhead と SSH2 通信チャネルを確立します。次に Detector モジュールは、安全な SSH2 通信チャネルを使用して SSL 接続鍵を交換します。詳細については、「通信チャネルの確立」を参照してください。
SSL 通信チャネルのイネーブル化
SSL 通信チャネルをイネーブルにするには、Detector モジュールおよび Guard モジュールの両方で次の手順を実行します。
Detector モジュールが SSH2 接続を確立できるようにするには、TACACS+ サーバに riverhead ユーザを定義する必要があります。
ステップ 1 設定モードで permit ssh ip-address-general [ ip-mask ] と入力して、Guard モジュールの IP アドレスから Detector モジュール上の SSH サービスへのアクセスを許可します。
引数 ip-address-general および ip-mask で、Detector モジュールへのアクセスを許可する Guard モジュールの IP アドレスを定義します。
（注） SSH サービスはすでにイネーブルになっているので、ここでイネーブルにする必要はありません。
ステップ 2 設定モードで service internode-comm コマンドを入力して、通信チャネル サービスをイネーブルにします。
ステップ 3 設定モードで permit internode-comm ip-address-general [ ip-mask ] コマンドを入力して、Guard モジュールの IP アドレスから通信チャネル サービスへのアクセスを許可します。
引数 ip-address-general および ip-mask で、Detector モジュールへのアクセスを許可する Guard モジュールの IP アドレスを定義します。
（注） SSL 通信チャネルを確立する方法の詳細については、「通信チャネルの確立」を参照してください。
（注） SSL 証明書にある Guard モジュールと Detector モジュールの ID は、IP アドレスに関連付けられます。通信チャネルの片側で Guard モジュールまたは Detector モジュールの IP アドレスを変更する場合は、SSL 証明書を再生成する必要があります。詳細については、「SSL 証明書の再生成」を参照してください。
SSL 証明書の再生成
SSL 証明書で Guard モジュールと Detector モジュールを識別する鍵は、IP アドレスに関連付けられます。
次のような場合、通信チャネルの両側で Guard モジュールと Detector モジュールの新しい SSL 証明書を再生成する必要があります。
新しい SSL 証明書を生成する前に、まず、現在使用している証明書を両方のデバイスで削除する必要があります。
現在使用している SSL 証明書を表示するには、 show internode-comm certs コマンドを使用します。
現在使用している SSL 証明書を再生成するには、次の手順を実行します。
ステップ 1 設定モードで次のコマンドを入力して、Guard モジュールの SSL 証明書を Detector モジュールから削除します。
cert-host-ip 引数には、Guard モジュールの IP アドレスを指定します。すべての Guard モジュールの SSL 証明書を削除するには、アスタリスク（*）を入力します。
ステップ 2 設定モードで次のコマンドを入力して、Detector モジュールの SSL 証明書を Guard モジュールから削除します。
cert-host-ip 引数には、Detector モジュールの IP アドレスを指定します。Guard モジュールとの通信チャネルを確立しているすべての Detector モジュールの SSL 証明書を削除するには、アスタリスク（*）を入力します。
ステップ 3 Guard モジュールを交換する場合は、Detector モジュールから SSH ホスト鍵も削除する必要があります。
設定モードで次のコマンドを使用して、Guard モジュールの SSH ホスト鍵を Detector モジュールから削除します。
ip-address 引数には、リモート デバイスの IP アドレスを指定します。
ステップ 4 新しい SSL 証明書を再生成するには、Guard モジュールと Detector モジュールとの間に新しい SSL 通信チャネルを確立する必要があります。この処理は Detector モジュールから実行する必要があります。詳細については、「通信チャネルの確立」を参照してください。
SSH 通信チャネルの設定
トラフィックの異常を検出すると、Detector モジュールはそのイベントをログに記録するか、SSH 通信チャネルを使用して Guard モジュールによるゾーン保護をアクティブにします。SSH 通信チャネルを使用している場合、Detector モジュールは次のタスクを実行できません。
• Guard モジュールを監視して、ゾーンに対する攻撃が終了したことを確認する。異常検出およびラーニング プロセスをイネーブルにした場合、Detector モジュールはゾーンに対する攻撃が終了したことを確認できず、リモート Guard をアクティブにした後は、ゾーン トラフィックのラーニングを続行しません。
• Guard モジュールとの通信を監視し、リモート処理（Guard モジュールによるゾーン保護のアクティブ化など）が失敗した場合に通知する。
安全な SSH2 通信チャネルを確保するために、Detector モジュールは秘密および公開 SSH 鍵ペアを生成し、公開 SSH 鍵をリモート Guard リストにある Guard モジュールに配布します。
SSH 通信チャネルをイネーブルにしたら、Detector モジュールから SSH 通信チャネルを確立する必要があります。詳細については、「通信チャネルの確立」を参照してください。
SSH2 通信チャネルのイネーブル化
Guard モジュールと Detector モジュールの間の SSH2 通信チャネルをイネーブルにするには、 permit ssh コマンドを入力して、Detector モジュールの IP アドレスからの Guard モジュール上の SSH サービスへのアクセスを許可します。
SSH 通信チャネルをイネーブルにしたら、Detector モジュールから SSH 通信チャネルを確立する必要があります。詳細については、「通信チャネルの確立」を参照してください。
Guard モジュール デバイスを交換（スワップアウト）する場合は、SSH2 通信チャネルを再生成する必要があります。「SSH2 通信チャネル鍵の再生成」を参照してください。
SSH2 通信チャネル鍵の再生成
Guard モジュール デバイスを交換した場合は、次の手順を実行して通信チャネルを再生成します。
ステップ 1 Detector モジュール上で no host-keys ip-address-general 設定モード コマンドを入力して、SSH ホスト鍵を Detector モジュールから削除します。
ip-address 引数には、リモート デバイスの IP アドレスを指定します。
Detector モジュールにリストされているホスト鍵を表示するには、 show host-keys コマンドを使用します。
ステップ 2 次のいずれかの処理を実行して、リモート Guard で SSH 鍵を設定します。
• 新しい SSH2 通信チャネルを Detector モジュールから確立します。
「通信チャネルの確立」を参照してください。
• Detector モジュールの公開鍵をリモート Guard に手動で追加します。Detector モジュールの公開 SSH 鍵をコピーし、Guard モジュールが保持している SSH 鍵のリストにペーストすることができます。
Detector モジュールの公開 SSH 鍵を表示するには、Detector モジュール上で show public-key コマンドを使用します。
Detector モジュールの公開 SSH 鍵を、Guard モジュールが保持している SSH 鍵のリストに追加するには、Guard モジュール上で key add コマンドを使用します。
通信チャネルの確立
Detector モジュールから Guard モジュールに SSH または SSL 通信チャネルを確立して Detector モジュールが Guard モジュールをアクティブにできるようにし、ゾーン設定を Guard モジュールと同期化させ、さらに Guard モジュールにポーリングします。Detector モジュールと Guard モジュールの両方で通信チャネルをイネーブルにしてから、通信チャネルを確立する必要があります。詳細については、「SSL 通信チャネルのイネーブル化」および「SSH2 通信チャネルのイネーブル化」を参照してください。
Detector モジュールは Guard モジュールとの接続を確立し、通信チャネルの確保に必要な暗号鍵と証明書を交換します。その後 Detector モジュールは接続を閉じ、Guard モジュールをアクティブにする、Guard モジュールとゾーン設定を同期させる、または Guard モジュールにポーリングする必要がある場合に、通信チャネルを確立します。
Detector モジュールから Guard モジュールへの通信チャネルを確立するには、Detector モジュール上で次の手順を実行します。
ステップ 1 設定モードで次のコマンドを入力して、SSH2 秘密および公開鍵ペアを生成します。
ステップ 2 SSH2 の鍵ペアがすでに存在している場合は、次のメッセージが表示されます。
次のオプションのいずれかを入力して必要なオプションを指定します。
• y ：Detector モジュールは新しい SSH2 鍵ペアを生成します。
• n ：Detector モジュールは新しい SSH2 鍵ペアを生成しません。
ステップ 3 SSH2 の公開鍵をパブリッシュします。SSL 通信チャネルを確立している場合、Guard は SSL 認証の生成も実行し、リモート Gurad と交換します。
SSH2 公開鍵をパブリッシュして、SSL 認証を生成および交換するには、設定モードで次のいずれかのコマンドを使用します。
• key publish remote-guard-address { ssh | ssl }
表4-9 に、 key publish コマンドの引数とキーワードを示します。
|
|
|
|---|---|
|
|
|
SSH2 公開鍵を remote-guard-address 引数で定義されているリモート Guard にパブリッシュします。 |
|
SSH2 公開鍵をパブリッシュし、SSL 認証を生成して remote-guard-address 引数で定義されているリモート Guard と交換します。 |
|
|
|
SSH2 鍵をパブリッシュして SSL 認証を生成し、リモート Guard リストに設定されているすべての Guard モジュールと SSL 認証を交換します。 Detector モジュールは、SSH リモート Guard リスト内の各 Guard モジュールと SSH 通信チャネルを確立します。各リモート Guard について、ステップ 4 とステップ 5 を繰り返します。 |
ステップ 4 man-in-the-middle アタックを防ぐために、SSH2 ではホスト鍵を使用してリモート ホストの確実性が確認されます。リモート ホストに対して初めて SSH2 通信チャネルを確立したときは、リモート ホストはそのホストの公開鍵を Detector モジュールに送信します。これが Detector モジュールから Guard モジュールに対して開始される最初の接続である場合は、次のメッセージが表示されます。
ステップ 5 Guard モジュールでユーザ riverhead 用に設定されたパスワードを入力します。
次の例で、SSH2 秘密および公開鍵ペアを生成する方法と、Detector モジュールと IP アドレスが 192.168.100.33 のリモート Guard との間で SSH2 通信チャネルを確立する方法について説明します。
次の例では、リモート Guard リストに記載されている Guard モジュールとの通信チャネルを確立する方法について説明します。
Detector モジュール SSH2 公開鍵を表示するには、 show public-key コマンドを使用します。
Detector モジュールにリストされているホスト鍵を表示するには、 show host-keys コマンドを使用します。
日付と時刻の設定
時刻と日付を設定するには、設定モードで次のコマンドを使用します。
表4-10 に、 date コマンドの引数を示します。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
次の例は、日付を 2003 年 10 月 8 日に、時刻を午後 5 時 10 分（1710）17 秒に設定する方法を示しています。
SSH 鍵の管理
Detector モジュールは、安全なリモート ログインのために SSH をサポートしています。SSH 鍵のリストを追加すると、ログインとパスワードを入力しなくても、リモート デバイスから Detector モジュールに安全な通信ができます。
次の各項では、Detector モジュールの SSH 鍵リストの管理方法について説明します。
• SSH 鍵の追加
• SSH 鍵の削除
SSH 鍵の追加
ログイン名とパスワードを入力しない SSH 接続をイネーブルにするには、Detector モジュールの SSH 鍵リストにリモート接続の SSH 公開鍵を追加します。
key add [ user-name ] {ssh-dsa | ssh-rsa} key-string comment
表4-11 に、 key add コマンドの引数とキーワードを示します。
SSH 鍵の削除
リストから SSH 鍵を削除できます。SSH 鍵を削除すると、次に Detector モジュールと SSH セッションを確立するときには認証を受ける必要があります。
Detector モジュールから SSH 鍵を削除するには、設定モードで次のコマンドを使用します。
key remove [ user-name ] key-string
表4-12 に、 key remove コマンドの引数を示します。
|
|
|
|---|---|
| プロンプトに SSH 公開鍵をペーストします。識別フィールド（ssh-rsa または ssh-dsa）は除き、鍵だけをペーストしてください。 |
次の例は、 key remove コマンドにカット アンド ペーストを行えるように、ユーザ鍵を表示する方法を示しています。
SFTP 接続および SCP 接続用の鍵の設定
SSH2 の最上層にあるセキュア FTP（SFTP）、および SSH に依存する Secure Copy（SCP）は、ファイルのコピー方式を提供します。このコピー方式は、安全で信頼できます。SFTP および SCP では、公開鍵による認証と強力なデータ暗号化を使用しています。これにより、ログイン、データ、およびセッションの情報が送信中に傍受されたり変更されたりすることを防止できます。
SFTP 接続および SCP 接続用の鍵を設定するには、次の手順を実行します。
ステップ 1 設定モードで show public-key コマンドを入力して、Detector モジュール上で Detector モジュールの公開鍵を表示します。
鍵が存在する場合は、ステップ 2 を省略してステップ 3 に進みます。
鍵が存在しない場合は、ステップ 2 に進みます。
ステップ 2 設定モードで key generate コマンドを入力して、Detector モジュール上で秘密および公開鍵ペアを生成します。
SSH2 の鍵ペアがすでに存在している場合は、次のメッセージが表示されます。
Detector モジュールが公開および秘密鍵ペアを作成します。Detector モジュールの公開鍵を表示するには、設定モードで show public-key コマンドを使用します。
ステップ 3 公開鍵を Detector モジュールからコピーし、ネットワーク サーバ上の鍵ファイル内にペーストします。
たとえば、Linux オペレーティング システムにインストールされている ネットワーク サーバに username というユーザ アカウントで接続している場合は、Detector モジュールの公開鍵を /home/username/.ssh/authorized_keys2 ファイルに追加します。
鍵は 1 行に収まるようにコピーしてください。鍵が 2 行としてコピーされた場合は、1 行目の末尾にある改行文字を削除します。
（注） 公開鍵をコピーしてネットワーク サーバ上の鍵ファイルにペーストしないと、自動エクスポート機能（export reports コマンドなど）が使用できず、手動でネットワーク サーバに接続するたびに、パスワードを入力する必要があります。
ホスト名の変更
Detector モジュールのホスト名を変更できます。この変更はすぐに反映され、新しいホスト名は自動的に CLI プロンプト ストリングに組み込まれます。
Detector モジュールのホスト名を変更するには、設定モードで次のコマンドを使用します。
次の例は、Detector モジュールのホスト名を変更する方法を示しています。
SNMP トラップのイネーブル化
Detector モジュールが SNMP トラップを送信し、Detector モジュールで発生する重大なイベントを管理者に通知するように設定することができます。また、Detector モジュールの SNMP トラップ ジェネレータのパラメータを設定し、Detector モジュールが報告する SNMP トラップ情報の範囲を定義することもできます。
トラップのログは、Detector モジュールのイベント ログに記録され、トラップ条件が発生すると、SNMP エージェントがトラップを送信するかどうかに関係なく、イベント モニタに表示されます。
Detector モジュールが SNMP トラップを送信するように設定するには、次の手順を実行します。
ステップ 1 設定モードで次のコマンドを入力して、SNMP トラップ ジェネレータ サービスをイネーブルにします。
ステップ 2 次のコマンドを入力して、SNMP トラップ ジェネレータのパラメータ（トラップの宛先 IP アドレスとトラップ情報の範囲）を設定します。
表4-13 に、 snmp trap-dest コマンドの引数を示します。
SNMP トラップ ジェネレータ パラメータを削除するには、 no snmp trap-dest コマンドを使用します。すべての SNMP トラップ宛先パラメータを削除するには、アスタリスク（ * ）を入力します。
次の例は、errors 以上の重大度レベルのトラップが、SNMP コミュニティ ストリング tempo とともに宛先 IP アドレス 192.168.100.52 に送信される例を示しています。
表4-14 に、Detector モジュールが生成する SNMP トラップを示します。
|
|
|
|
|---|---|---|
すべての Detector モジュール ゾーン上で 150,000 個以上の動的フィルタが同時にアクティブになっているため、Detector モジュールは新しい動的フィルタを追加できない。 |
||
ギガビット インターフェイス リンクの使用率（bps1 単位）が 85% を超えている。 |
||
Detector モジュールは SSL 通信チャネルを使用してゾーンを保護するためのリモート Guard のアクティブ化に失敗した。 |
||
Detector モジュールは動的フィルタの追加に失敗した。 • |
||
Detector モジュールに、すべてのゾーン上で同時にアクティブになっている動的フィルタが 135,000 個以上ある。アクティブな動的フィルタの数が 15,000 に到達すると、Detector モジュールは新しい動的フィルタを追加できなくなります。 |
||
Detector モジュールは再起動した。トラップには、MIB2 ウォーム スタート トラップまたは |
||
Detector モジュールはシャットダウンした。トラップには、MIB2 ウォーム スタート トラップまたはコールド スタート トラップと、Detector モジュールがシャットダウンした原因に関する情報が含まれています。 |
||
Detector モジュールは SSL 通信チャネルを使用してゾーンを保護するためのリモート Guard のアクティブ化に失敗している。 |
||
Detector モジュールは、アクティブな動的フィルタが 1000 個以上あるため、削除する動的フィルタのトラップを送信しない。 |
||
SNMP コミュニティ ストリングの設定
Detector モジュールの SNMP サーバにアクセスすることにより、管理情報ベース 2（MIB2）および Cisco Riverhead 専用 MIB で定義された情報を取得することができます。コミュニティ ストリングはパスワードのように機能し、Detector モジュールの SNMP エージェントからの読み取りアクセスを許可します。Detector モジュールの SNMP コミュニティ ストリングを設定して、異なる組織のクライアントがそれぞれ異なるコミュニティ ストリングを使用して SNMP エージェントにアクセスできるようにすることができます。
SNMP コミュニティ ストリングを追加するには、設定モードで次のコマンドを使用します。
snmp community community-string
community-string 引数には、目的の Detector モジュールのコミュニティ ストリングを指定します。1 ～ 15 文字の英数字文字列を入力します。この文字列にスペースを含めることはできません。Detector モジュールのデフォルトのコミュニティ ストリングは riverhead です。コミュニティ名はいくつでも指定できます。コミュニティ ストリングを削除するには、 no community string コマンドを使用します。すべての SNMP コミュニティ ストリングを削除するには、アスタリスク（ *） を入力します。
次の例は、SNMP コミュニティ ストリングを設定する方法を示しています。
ログイン バナーの設定
ログイン バナーとは、SSH セッション、コンソール ポート接続、または Detector モジュールへの WBM セッションを開いたときに、ユーザ認証の前の画面に表示されるテキストのことです。
認可されていないアクセスに対してユーザに警告したり、適切と見なされるシステムの使用法を説明したり、不適切な使用法や不正な活動を検出するためにシステムが監視されていることをユーザに警告したりするように、ログイン バナーを設定できます。
Detector モジュールは、次の場所にログイン バナーを表示します。
• CLI：パスワード ログイン プロンプトの前、またはポップアップとして（使用している SSH クライアントによって異なる）。
• WBM：Detector モジュールのログイン ウィンドウの右側。
CLI からのログイン バナーの設定
login-banner コマンドを使用すると、単一または複数のメッセージ バナーを作成できます。複数のログイン バナーを入力した場合、新しいログイン バナーは、既存のログイン バナーの最後に新しい行として追加されます。
ログイン バナーを設定するには、設定モードで次のコマンドを使用します。
banner-str 引数には、バナーのテキストを指定します。文字列の長さは最大 999 文字です。式にスペースを使用する場合は、式を引用符（" "）で囲みます。
ログイン バナーを表示するには、 show login-banner コマンドを使用します。
次の例は、ログイン バナーを設定して表示する方法を示しています。
Welcome to the Cisco Traffic Anomaly Detector Module
Unauthorized access is prohibited.
Contact sysadmin@corp.com for access.
ログイン バナーのインポート
グローバル モードまたは設定モードで次のいずれかのコマンドを入力して、ネットワーク サーバからテキスト ファイルをインポートし、既存のログイン バナーを差し替えることができます。
• copy ftp login-banner server full-file-name [ login [ password ]]
• copy { sftp | scp } login-banner server full-file-name login
インポートするファイル内の各行の最大長は、999 文字です。
セキュア FTP（SFTP）および Secure Copy（SCP）は安全な通信を SSH に依存しているため、 copy コマンドに sftp または scp オプションを指定して入力する前に、Detector モジュールが使用する鍵を設定していない場合、Detector モジュールからパスワードを入力するよう要求されます。Detector モジュールがセキュアな通信のために使用する鍵を設定する方法の詳細については、「SFTP 接続および SCP 接続用の鍵の設定」を参照してください。
表4-15 に、 copy login-banner コマンドの引数とキーワードを示します。
次の例は、FTP サーバからログイン バナーをインポートする方法を示しています。
ログイン バナーの削除
ユーザ認証の前にメッセージを表示する必要がなくなった場合、ログイン バナーを削除できます。
ログイン バナーを削除するには、設定モードで no login-banner コマンドを使用します。
WBM ロゴの設定
エンドユーザ インターフェイスをカスタマイズするために、企業のロゴ（またはカスタマイズされたロゴ）を WBM Web ページに追加することができます。
• Detector モジュールのログイン ページで、Cisco Systems ロゴの下。
• すべての WBM ページ（Detector モジュールのログイン ページは除く）で、Cisco Systems ロゴの右側。
新しいロゴは GIF 形式である必要があります。新しいロゴのサイズは、幅 = 87 ピクセル、高さ = 41 ピクセルにすることをお勧めします。
WBM ロゴのインポート
ネットワーク サーバから新しいロゴをインポートするには、グローバル モードまたは設定モードで次のコマンドを入力します。
• copy ftp wbm-logo server full-file-name [ login [ password ]]
• copy { sftp | scp } wbm-logo server full-file-name login
セキュア FTP（SFTP）および Secure Copy（SCP）は安全な通信を SSH に依存しているため、 copy コマンドに sftp または scp オプションを指定して入力する前に、Detector モジュールが使用する鍵を設定していない場合、Detector モジュールからパスワードを入力するよう要求されます。Detector モジュールがセキュアな通信のために使用する鍵を設定する方法の詳細については、「SFTP 接続および SCP 接続用の鍵の設定」を参照してください。
表4-16 に、 copy wbm-logo コマンドの引数とキーワードを示します。
次の例は、FTP サーバから WBM ロゴ ファイルをインポートする方法を示しています。
WBM ロゴの削除
WBM ロゴを削除するには、設定モードで no wbm-logo コマンドを使用します。
セッション タイムアウトの設定
セッション タイムアウトとは、アクティビティが何もない状態でセッションがアクティブでいられる時間のことです。設定された時間内に何もアクティビティがなかった場合、タイムアウトが発生し、再びログインする必要があります。セッション タイムアウトは、デフォルトではディセーブルになっています。
セッション タイムアウトは CLI にのみ適用され、WBM には適用されません。
設定モードで次のコマンドを入力して、Detector モジュールがアイドル セッションを自動的に切断するまでの分数を設定できます。
timeout-val 引数には、Detector モジュールが自動的にアイドル セッションを接続するまでの分数を指定します。有効な値は、1 ～ 1,440 分（1 日）です。
次の例は、Detector モジュールが 10 分後にアイドル セッションを切断するように設定する方法を示しています。
Detector モジュールが自動的にアイドル セッションを切断しないようにするには、 no session-timeout コマンドを使用します。
フィードバック