ソフトウェア更新の実行
ライセンス:任意
FireSIGHT システムの展開を更新するには、いくつかの基本的な手順があります。最初に、リリース ノートを参照し、必要な更新前のタスクを完了するなど、更新の準備をする必要があります。これで更新を開始することができます。まず防御センターを更新し、次にこれらが管理するデバイスを更新します。更新が完了し、更新が正常に終了したことを確認するまで、更新の進捗状況を監視する必要があります。最後に、更新後の必要な手順を完了させます。
詳細については、次の項を参照してください。
• 「更新の計画」
• 「更新プロセスについて」
• 「防御センターの更新」
• 「管理対象デバイスの更新」
• 「メジャーな更新のステータスの監視」
更新の計画
ライセンス:任意
更新を開始する前に、リリース ノートをよく読んで理解する必要があります。リリース ノートはサポート サイトからダウンロードすることができます。リリース ノートには、サポートされているプラットフォーム、新しい機能、既知および解決済みの問題、製品の互換性について記載されています。また、リリース ノートには前提条件、警告、および特別なのインストールおよびアンインストールの手順についての重要な情報が含まれています。
以降の項では、更新の計画で検討しなければならない要素の概要を提供します。
FireSIGHT システムのバージョンの要件
アプライアンス(ソフトウェアベースのデバイスを含む)が、FireSIGHT システムの正しいバージョンを実行していることを確認する必要があります。リリース ノートには必要なバージョンが示されています。古いバージョンを実行している場合は、サポート サイトから更新を取得することができます。
オペレーティング システム要件
ソフトウェアベースのデバイスをインストールしたコンピュータが、オペレーティング システムの正しいバージョンを実行していることを確認します。リリース ノートには必要なバージョンが示されています。仮想デバイスでサポートされるオペレーティング システムの詳細については、『 FireSIGHT System Virtual Installation Guide 』を参照してください。Sourcefire Software for X-Series でサポートされるオペレーティング システムの詳細については、『 Sourcefire Software for X-Series Installation Guide 』を参照してください。
時間とディスク領域の要件
十分な空きディスク領域があることを確認し、更新のために十分な時間を確保しておく必要があります。管理対象デバイスを更新する場合には、防御センターで追加のディスク領域が必要になります。リリース ノートには、領域と時間の要件が示されています。
設定およびイベント バックアップのガイドライン
シスコでは、メジャーの更新を開始する前に、外部の場所へコピーした後にアプライアンス上に残っているバックアップをすべて削除することを推奨しています。更新のタイプに関係なく、現行のイベントおよび設定データを外部の場所にバックアップしておく必要もあります。イベント データは、更新プロセスの一部としてバックアップされ ません 。
防御センターを使用して、それ自身、および管理対象のイベントと設定データをバックアップすることができます。「バックアップと復元の使用」を参照してください。
更新を実行するタイミング
更新プロセスはトラフィックの調査、トラフィック フロー、およびリンク ステートに影響を与えることがあること、および更新を行っている間は Data Correlator が無効になっていることにより、シスコでは、保守を行っている間、または中断が展開に及ぼす影響が最も少ない時間に更新を行うことを推奨しています。
更新プロセスについて
ライセンス:任意
次の図は、更新プロセスの概要を示しています。
更新の順序
管理対象のデバイスを更新するには、その前に、防御センターを更新 する必要があります 。
防御センターを使用した更新の実行
シスコは、防御センターの Web インターフェイスを使用して、それ自身だけでなく、管理対象のデバイスも更新することを推奨しています。仮想デバイスや Sourcefire Software for X-Series など、Web インターフェイスを持たない管理対象デバイスを更新するには、防御センター を使用する 必要があります 。Sourcefire Software for X-Series に対するメジャーな更新では、前のバージョンをアンインストールして新しいバージョンをインストールしなければならないことがあります。詳細については、『 Sourcefire Software for X-Series Installation Guide 』を参照してください。
[Product Updates] ページ([System] > [Updates])には、それぞれの更新のバージョン、およびその更新が生成された日時が表示されます。また、更新の一環としてリブートが必要かどうかも示されます。
サポートから取得した更新をアプライアンスへアップロードすると、更新がページに示されます。パッチ機能および機能の更新のアンインストーラも表示されます。「ソフトウェア更新のアンインストール」を参照してください。防御センターで、ページに VDB 更新を表示できます。
ヒント パッチおよび機能の更新では、自動更新機能を利用することができます。「ソフトウェア更新の自動化」を参照してください。
ペアの防御センターの更新
高可用性ペアの 1 つの防御センターの更新を開始すると、防御センターのペアの一方が(まだプライマリになっていない場合は)プライマリになります。また、ペアの防御センターが設定情報の共有を停止すると、ペアの防御センターは、通常の同期プロセスの一環としてのソフトウェア更新は受信しません。
操作の継続性を保証するには、ペアの防御センターを同時に更新 しないでください 。まず、セカンダリ防御センターの更新手順を完了してからプライマリを更新してください。
クラスタ デバイスの更新
クラスタ デバイスまたはクラスタ スタック上で更新をインストールすると、システムは、複数のデバイスまたはスタック上で同時に更新を実行します。更新を開始すると、システムは最初にバックアップ デバイスまたはスタックに更新を適用し、必要なプロセスが再開され、デバイスまたはスタックがトラフィックを再処理するまでメンテナンス モードになります。システムは、アクティブなデバイスまたはスタックに更新を適用し、同じプロセスを行います。
クラスタ スタックのデバイスを更新するには、クラスタのすべてのメンバ上で同時に、管理している防御センターから更新を実行する必要があります。デバイスから直接更新を実行することはできません。
スタック デバイスの更新
スタック デバイスに更新をインストールすると、システムは更新を同時に実行します。各デバイスは、更新が完了すると通常の動作を再開します。次の点に注意してください。
• すべてのセカンダリ デバイスの更新が完了する 前に プライマリ デバイスが更新を完了した場合、すべてのデバイスが更新を完了するまでスタックは、バージョンが混在した制限付きの状態で作動します。
• すべてのセカンダリ デバイスの更新が完了した 後で プライマリ デバイスの更新が完了した場合は、プライマリ デバイスで更新が完了したときに、スタックは通常の動作を再開します。
トラフィック フローとインスペクション
管理対象デバイスから更新をインストールまたはアンインストールすると、次の機能に影響を及ぼすことがあります。
• トラフィックのインスペクション(アプリケーションおよびユーザの認識とコントロール、URL フィルタリング、セキュリティ インテリジェンス フィルタリング、侵入検出と防御、接続のロギングなど)
• トラフィック フロー(スイッチング、ルーティング、関連する機能など)
• リンク ステート
Data Correlator は、システムの更新中は動作しません。更新が完了すると再開します。
ネットワーク トラフィックの中断の方法と期間は、更新が影響を及ぼす FireSIGHT システムのコンポーネント、デバイスがどのように設定および展開されているか、更新によりデバイスがリブートされるかどうか、によって異なります。特定の更新に対してネットワーク トラフィックがいつ、どのように影響を受けるかについての情報は、リリース ノートを参照してください。
ヒント クラスタ デバイスを更新する場合、システムは、トラフィックの中断を回避するために、一度に 1 つずつ更新を実行します。
更新中の Web インターフェイスの使用
更新のタイプに関係なく、更新中のアプライアンスの Web インターフェイスを使用して、更新の監視以外のタスクを実行 しないで ください。
メジャーな更新中にユーザがアプライアンスを使用しないようにし、メジャーな更新の進捗をユーザが簡単に監視できるようにするために、アプライアンスの Web インターフェイスが合理化されています。タスク キュー([System] > [Monitoring] > [Task Status])でマイナーな更新の進捗を監視することができます。マイナーな更新中に Web インターフェイスを使用することは禁止されていませんが、シスコでは推奨していません。
ヒント 管理対象デバイスの更新を監視するには、防御センターでタスク キューを使用します。
マイナーな更新であっても、更新プロセス中は、更新しているアプライアンスの Web インターフェイスは使用できないか、またはアプライアンスでユーザがログアウトされることがあります。これは想定されている動作です。この場合は、もう一度ログインしタスク キューを表示します。まだ更新が実行中の場合は、更新が完了するまで Web インターフェイスを使用 しないで ください。更新中は、管理対象デバイスが 2 回リブートされることがありますが、これは予想される動作です。
注意 (Web インターフェイスに更新が失敗したことが示されている、タスク キューの手動更新または [Update Status] ページに進捗が表示されないなど)更新で問題が発生した場合には、更新を再開
しないでください。代わりに、サポートへ連絡してください。
更新後
リリース ノートに記載されている更新後のすべてのタスクを完了し、展開が正常に実行されていることを確認する 必要があります 。
更新後のタスクで最も重要なことは、防御センターを更新した後と、管理対象デバイスを更新した後の両方で、アクセス コントロール ポリシーを再適用することです。アクセス コントロール ポリシーを適用すると、トラフィック フローと処理が一時的に停止することがあります。また、いくつかのパケットが検査されない場合があります。「アクセス コントロール ポリシーの適用」を参照してください。
また、次の作業を実行する必要があります。
• 更新が正常に終了したことを確認する
• 展開のすべてのアプライアンスが正常に通信していることを確認する
• 必要に応じて侵入ルール、VDB、および GeoDB を更新する
• リリース ノートの情報に基づいて、必要な設定変更を行う
• リリース ノートに記載されている、更新後の追加タスクを実行する
防御センターの更新
ライセンス:任意
更新のタイプ、および防御センターがインターネットへアクセスできるかどうかによって、防御センターを次のいずれかの方法で更新します。
• 防御センターがインターネットにアクセスできる場合は、防御センターを使用して、サポート サイトから直接更新を取得します。このオプションは、メジャーな更新ではサポート されていません 。
• サポート サイトから更新を手動でダウンロードして、防御センターへアップロードすることもできます。防御センターがインターネットへアクセスできない場合、またはメジャーな更新を実行している場合は、このオプションを選択します。
メジャーな更新の場合は、防御センターを更新すると、以前の更新のアンインストーラが削除されます。
防御センター を更新する方法:
アクセス:Admin
ステップ 1 リリース ノートを読んで、更新前の必要なタスクを完了します。
更新前のタスクには、防御センターがシスコ ソフトウェアの正しいバージョンを実行している、更新を実行するための十分な空きディスク領域がある、更新を実行するために十分な時間を確保している、イベントおよび設定データをバックアップした、などの確認が含まれています。
ステップ 2 更新を防御センターへアップロードします。ここで、更新のタイプによって、および防御センターがインターネットにアクセスできるかどうかによって、2 つのオプションがあります。
• メジャーな更新を除くすべての更新で、防御センターがインターネットにアクセスできる場合は、[System] > [Updates] を選択し、[Download Updates] をクリックして、次のいずれかのサポート サイトで最新の更新をチェックします。
–Sourcefire: (https://support.sourcefire.com/)
–シスコ: (http://www.cisco.com/cisco/web/support/index.html)
• メジャーな更新の場合、または防御センターがインターネットにアクセスできない場合は、最初に次のいずれかのサポート サイトから更新を手動でダウンロードする必要があります。
–Sourcefire: (https://support.sourcefire.com/)
–シスコ: (http://www.cisco.com/cisco/web/support/index.html)
• [System] > [Updates] を選択して [Upload Update] をクリックします。更新を参照して、[Upload] をクリックします。
注 サポート サイトから、手動でまたは [Product Updates] タブで [Download Updates] をクリックして、更新を直接ダウンロードします。電子メールで更新ファイルを転送すると、ファイルが破損することがあります。
更新が防御センターへアップロードされます。
ステップ 3 展開内でアプライアンスが正常に通信していること、およびヘルス モニタによって問題が報告されていないことを確認します。
ステップ 4 [System] > [Monitoring] > [Task Status] を選択してタスク キューを表示し、進行中のジョブがないことを確認します。
更新を開始したときに実行されているタスクは停止され、再開できません。更新が完了した後で、タスク キューから手動で削除する必要があります。タスク キューは 10 秒ごとに自動的にリフレッシュされます。更新を始める前に、長時間実行しているタスクが完了するまで待機する必要があります。
ステップ 5 [System] > [Updates] を選択します。
[Product Updates] ページが表示されます。
ステップ 6 ユーザがアップロードする更新の隣にあるインストール アイコンをクリックします。
[Install Update] ページが表示されます。
ステップ 7 防御センターを選択し、[Install] をクリックします。プロンプトが表示されたら、更新をインストールすることを確認して防御センターをリブートします。
更新プロセスが開始されます。更新を監視する方法は、更新がメジャーかマイナーかによって異なります。更新のタイプを判断するには、 「FireSIGHT システム更新のタイプ」 の表およびリリース ノートを参照してください。
• マイナーな更新については、タスク キュー([System] > [Monitoring] > [Task Status])で更新の進捗を監視することができます。
• メジャーな更新については、タスク キューで更新の進捗の監視を開始できます。ただし、防御センターが更新前の必要なチェックを完了したら、ユーザはログアウトされます。もう一度ログインすると、[Upgrade Status] ページが表示されます。詳細については、「メジャーな更新のステータスの監視」を参照してください。
注意 更新のタイプに関係なく、更新が完了するまで、更新の監視以外のタスクを実行するために Web インターフェイスを使用
しないでください。必要な場合は、防御センターをリブートします。詳細については、
「更新中の Web インターフェイスの使用」を参照してください。
ステップ 8 更新が完了したら、必要に応じて防御センターにログインします。
メジャーな更新の後に最初にログインするユーザには、エンド ユーザ ライセンス契約(EULA)が表示されることがあります。EULA を確認して承認し、処理を続行します。
ステップ 9 ブラウザのキャッシュを消去し、ブラウザを強制的にリロードします。このようにしない場合は、ユーザ インターフェイスが予期せぬ動作をすることがあります。
ステップ 10 [Help] > [About] を選択し、ソフトウェアのバージョンが正しく示されていることを確認します。また、防御センターでルール更新および VDB のバージョンをメモしておいてください。この情報は後で必要になります。
ステップ 11 すべての管理対象デバイスが、防御センターと正常に通信していることを確認します。
ステップ 12 サポート サイトで利用できるルール更新が、自身の防御センター上のルールよりも新しい場合は、新しいルールをインポートします。
詳細については、「ルールの更新とローカル ルール ファイルのインポート」を参照してください。
ステップ 13 アクセス コントロール ポリシーを再適用します。
アクセス コントロール ポリシーを適用すると、トラフィック フローと処理が一時的に停止することがあります。また、いくつかのパケットが検査されない場合があります。詳細については、「アクセス コントロール ポリシーの適用」を参照してください。
ステップ 14 サポート サイトで入手できる VDB が、自身の防御センター上の VDB よりも新しい場合は、最新の VDB をインポートします。
VDB の更新をインストールすると、トラフィック フローと処理が一時的に停止することがあります。また、いくつかのパケットが検査されない場合があります。詳細については、「脆弱性データベースの更新」を参照してください。
ステップ 15 次の項、 管理対象デバイスの更新へ進んで、防御センターが管理するデバイス上でシスコ ソフトウェアを更新します。
管理対象デバイスの更新
ライセンス:任意
シスコでは、防御センターの更新が終わったあとでこれを使用して、管理対象のデバイスを更新することを推奨しています。仮想デバイスや Sourcefire Software for X-Series など、Web インターフェイスを持たない管理対象デバイスを更新するには、防御センターを使用する 必要があります 。Sourcefire Software for X-Series に対するメジャーな更新では、前のバージョンをアンインストールして新しいバージョンをインストールしなければならないことがあります。
管理対象デバイスの更新は、次の 2 段階のプロセスです。最初に、以下のいずれかのサポート サイトから更新をダウンロードし、それを管理元の 防御センター へアップロードします。
• Sourcefire: (https://support.sourcefire.com/)
• シスコ: (http://www.cisco.com/cisco/web/support/index.html)
次に、ソフトウェアをインストールします。
注 トラフィックのインスペクション、トラフィック フロー、およびリンク状態は、デバイスがどのように設定および展開されているか、更新がどのコンポーネントに影響を及ぼすか、更新によってデバイスがリブートされるかどうかよって、更新中に影響を受けることがあります。特定の更新に対してネットワーク トラフィックがいつ、どのように影響を受けるかについての具体的な情報は、対象の更新のリリース ノートを参照してください。
管理対象デバイスを更新する方法:
アクセス:Admin
ステップ 1 リリース ノートを読んで、更新前の必要なタスクを完了します。
更新前のタスクには、管理元の防御センターを更新する、イベントおよび設定データをバックアップする、およびデバイスがシスコ ソフトウェアの正しいバージョンを実行していること、ソフトウェアベースのデバイスをインストールしたコンピュータがオペレーティング システムの正しいバージョンを実行していること、更新を実行するのに十分な空きディスク領域があること、更新を実行するのに十分な時間を確保していることを確認する、といったことが含まれています。
ステップ 2 デバイスを管理している防御センター上で FireSIGHT システム ソフトウェアを更新します。「防御センターの更新」を参照してください。
ステップ 3 次のサポート サイトのいずれかから更新をダウンロードします。
• Sourcefire: (https://support.sourcefire.com/)
• シスコ: (http://www.cisco.com/cisco/web/support/index.html)
デバイス モデルごとに異なる更新を使用できます。ダウンロードできる更新については、リリース ノートを参照してください。
注 サポート サイトから更新を直接ダウンロードします。電子メールで更新ファイルを転送すると、ファイルが破損することがあります。
ステップ 4 展開内でアプライアンスが正常に通信していること、およびヘルス モニタによって問題が報告されていないことを確認します。
ステップ 5 管理元の防御センターで、[System] > [Update] を選択します。
[Product Updates] ページが表示されます。
ステップ 6 [Upload Update] をクリックして、ダウンロードした更新を参照し、[Upload] をクリックします。
更新が 防御センター へアップロードされます。[Product Updates] タブに、アップロードした更新のタイプ、バージョン番号、および生成された日付と時刻が示されます。このページには、更新の一環としてリブートが必要かどうかも示されます。
ステップ 7 ユーザがインストールする更新の隣にあるインストール アイコンをクリックします。
[Install Update] ページが表示されます。
ステップ 8 更新をインストールするデバイスを選択して [Install] をクリックします。同じ更新を使用する場合は、複数のデバイスを一度に更新できます。プロンプトが表示されたら、更新をインストールすることを確認してデバイスをリブートします。
更新プロセスが開始されます。ファイルのサイズによっては、すべてのデバイスで更新をインストールするのに時間がかかることがあります。防御センターのタスク キュー([System] > [Monitoring] > [Task Status])で更新の進捗を監視することができます。更新中に、管理対象デバイスが 2 回リブートされることがありますが、これは正常な動作です。
注意 (タスク キューに更新が失敗したことが示されている、またはタスク キューの手動更新で進捗が表示されないなど)更新で問題が発生した場合には、更新を再開
しないでください。代わりに、サポートへ連絡してください。
ステップ 9 オプションとして、メジャーな更新の後でデバイスのローカル Web インターフェイスにログインします。
メジャーな更新の後に最初にログインするユーザには、エンド ユーザ ライセンス契約(EULA)が表示されることがあります。EULA を確認して承認し、処理を続行します。Web インターフェイスではなくコマンドライン インターフェイスを介して最初にログインした場合も EULA が表示されるので、必ず承認してください。
ステップ 10 防御センターで、[Devices] > [Device Management] を選択し、更新したデバイスのバージョンが記載されている正しいものであることを確認します。
ステップ 11 更新したデバイスが、防御センターと正常に通信していることを確認します。
ステップ 12 アクセス コントロール ポリシーを再適用します。
アクセス コントロール ポリシーを適用すると、トラフィック フローと処理が一時的に停止することがあります。また、いくつかのパケットが検査されない場合があります。詳細については、「アクセス コントロール ポリシーの適用」を参照してください。
メジャーな更新のステータスの監視
ライセンス:任意
メジャーな更新では、FireSIGHT システムは、更新プロセスを簡単に監視できるような、簡潔な Web インターフェイスを提供します。インターフェイスが簡潔であるため、更新の監視以外のタスクを実行するために Web インターフェイスが使用されることもなくなります。
タスク キュー([System] > [Monitoring] > [Task Queue])で更新の進捗の監視を開始できます。ただし、アプライアンスが更新前の必要なチェックを完了したら、自分を含めたすべてのユーザが Web インターフェイスからログアウトされます。Administrator または Maintenance User 以外の場合は、更新が完了するまでログインし直すことはできません。
Administrator の場合は、ログインし直すと、簡潔な更新ページが表示されます。
防御センターを使用して管理対象デバイスを更新する場合、シスコでは、防御センターのタスク キューから更新の進捗を監視することを推奨しています。ただし、アプライアンスが更新前のチェックを終了した後で、ユーザがデバイスのローカル Web インターフェイスにログインしようとすると、簡潔な更新ページが表示され、これを使用して更新の進捗を監視することができます。
このページには、更新前の FireSIGHT システムのバージョン、更新後のバージョン、および更新を開始してからの経過時間が表示されます。また進捗バーが表示され、実行中のスクリプトに関する詳細が示されます。
ヒント 更新ログを表示するには、[show log for current script] をクリックします。ログをもう一度非表示にするには、[hide log for current script] をクリックします。
何らかの理由で更新が失敗すると、ページにはエラー メッセージが表示され、失敗した日時、更新が失敗したときに実行していたスクリプト、およびサポートへ連絡するための方法が示されます。更新を再開 しないで ください。
注意 更新で他の問題(ページの手動更新で長時間経過しても進捗が表示されない、など)が生じた場合も、更新を再開
しないでください。代わりに、サポートへ連絡してください。
更新が完了すると、アプライアンスで正常終了のメッセージが表示され、リブートが行われます。アプライアンスのリブートが完了した後で、ページを更新してログインし、更新後の必要な手順を完了します。
ソフトウェア更新のアンインストール
ライセンス:任意
シスコ アプライアンスへパッチまたは機能の更新を適用すると、更新プロセスによってアンインストーラが作成されます。これにより、Web インターフェイスを使用してアプライアンスから更新を削除することができます。
更新をアンインストールした場合、結果として保持されるシスコ ソフトウェアのバージョンは、アプライアンスをどのような経路で更新したかによって異なります。たとえば、アプライアンスをバージョン 5.0 からバージョン 5.0.0.2 へ直接更新した場合のシナリオについて考えてみます。バージョン 5.0.0.2 のパッチをアンインストールすると、バージョン 5.0.0.1 の更新をインストールしたことがなくても、バージョン 5.0.0.1 を実行するアプライアンスが結果として生成されます。更新をアンインストールしたときに結果として生成されるシスコ ソフトウェアのバージョンの詳細については、リリース ノートを参照してください。
注 メジャーな更新では、Web インターフェイスからのアンインストールはサポートされていません。アプライアンスを FireSIGHT システムの新しいメジャー バージョンに更新して、古いバージョンに戻す必要がある場合は、サポートに連絡してください。
アンインストールの順序
インストールした順序と逆の順序で更新をアンインストールします。つまり、最初に管理対象デバイスから更新をアンインストールし、次に防御センターからアンインストールします。
ローカル Web インターフェイスを使用した更新のアンインストール
更新をアンインストールするにはローカル Web インターフェイスを使用する必要があります。防御センターを使用して、管理対象デバイスから更新をアンインストールすることはできません。ローカル Web インターフェイスを持たないデバイス(仮想デバイスや Sourcefire Software for X-Series など)からパッチをアンインストールする場合の詳細については、リリース ノートを参照してください。
このプロセスを使用して、Sourcefire Software for X-Series のマイナーな更新をアンインストールできますが、このプロセスを使用して、X-Series プラットフォームから Sourcefire Software for X-Series アプリケーションをアンインストールすることはできないことに注意してください。詳細は、『 Sourcefire Software for X-Series Installation Guide 』を参照してください。
クラスタまたはペア アプリケーションからの更新のアンインストール
クラスタ デバイスと高可用性ペアの防御センターは、FireSIGHT システムの同じバージョンを実行する必要があります。アンインストール プロセスによりフェールオーバーが自動でトリガーされますが、非対応のペアまたはクラスタ内のアプライアンスは設定情報を共有しません。また、同期の一環としては更新をインストールまたはアンインストールすることもありません。冗長なアプライアンスから更新をアンインストールしなければならない場合は、アンインストールを連続して実行するよう計画します。
アンインストールによって、これらのデバイスが、クラスタ スタックがサポートされないバージョンに戻される場合は、クラスタ スタックのデバイスから更新をアンインストールできません。
運用の継続性を保証するために、クラスタ デバイスおよびペアの防御センターから一度に 1 つずつ更新をアンインストールします。最初に、セカンダリ アプライアンスから更新をアンインストールします。アンインストールのプロセスが完了するまで待機して、プライマリ アプライアンスからすぐに更新をアンインストールします。
注意 クラスタ デバイスまたはペアの防御センターでのアンインストール プロセスが失敗した場合は、アンインストールを再開したり、ピアの設定を変更したり
しないでください。代わりに、サポートへ連絡してください。
スタック デバイスからの更新のアンインストール
スタック内のすべてのデバイスは、FireSIGHT システムの同じバージョンを実行する必要があります。いずれかのスタック デバイスから更新をアンインストールすると、そのスタック内のデバイスは、バージョンが混在した制限付きの状態になります。
展開における影響を最小限にするために、シスコでは、スタック デバイスから更新を同時にアンインストールすることを推奨しています。スタック内のすべてのデバイスで更新が完了すると、スタックは通常の動作を再開します。
アンインストールによって、これらのデバイスが、クラスタ スタックがサポートされないバージョンに戻される場合は、クラスタ スタックのデバイスから更新をアンインストールできません。
トラフィック フローとインスペクション
管理対象デバイスから更新をアンインストールすると、トラフィックのインスペクション、トラフィック フロー、およびリンク ステートに影響を及ぼすことがあります。特定の更新に対してネットワーク トラフィックがいつ、どのように影響を受けるかについての情報は、リリース ノートを参照してください。
アンインストール後
更新をアンインストールした後で、展開が正しく機能していることを確認するために、いくつかの手順を実行する必要があります。これらの手順には、アンインストールが正常に終了したことの確認、および展開内のすべてのアプライアンスが正常に通信していることの確認が含まれます。それぞれの更新に特定の情報については、リリース ノートを参照してください。
ローカル Web インターフェイスを使用してパッチまたは機能の更新をアンインストールする方法:
アクセス:Admin
ステップ 1 [System] > [Updates] を選択します。
[Product Updates] ページが表示されます。
ステップ 2 削除する更新のアンインストーラの隣にあるインストール アイコンをクリックします。
• 防御センターで、[Install Update] ページが表示されます。防御センターを選択し、[Install] をクリックします。
• 管理対象デバイスには、操作のページがありません。
いずれの場合も、プロンプトが表示されたら、更新をアンインストールすることを確認してアプライアンスをリブートします。
アンインストール プロセスが開始されます。タスク キュー([System] > [Monitoring] > [Task Status])で進捗を監視することができます。
注意 アンインストールが完了するまで、更新の監視以外のタスクを実行するために Web インターフェイスを使用
しないでください。必要に応じて、アプライアンスをリブートします。詳細については、
「更新中の Web インターフェイスの使用」を参照してください。
ステップ 3 アンインストールが完了したら、必要に応じてアプライアンスにログインします。
ステップ 4 ブラウザのキャッシュを消去し、ブラウザを強制的にリロードします。このようにしない場合は、ユーザ インターフェイスが予期せぬ動作をすることがあります。
ステップ 5 [Help] > [About] を選択し、ソフトウェアのバージョンが正しく示されていることを確認します。
ステップ 6 パッチをアンインストールしたアプライアンスが正常に管理対象デバイスと通信していること(防御センターの場合)、または管理元の防御センターと通信していること(管理対象デバイスの場合)を確認します。
脆弱性データベースの更新
ライセンス:任意
シスコ脆弱性データベース(VDB)は、オペレーティング システム、クライアント、およびアプリケーションのフィンガープリントだけでなく、ホストが影響を受ける可能性のある既知の脆弱性のデータベースです。FireSIGHT システムはフィンガープリントと脆弱性を関連付けて、特定のホストがネットワークの侵害のリスクを増大させているかどうかを判断するのをサポートします。シスコ脆弱性調査チーム(VRT)は、VDB を定期的に更新します。
VDB を更新するには、防御センターで [Product Updates] ページを使用します。サポートから取得した VDB の更新をアプライアンスへアップロードすると、このページに、アップロードした更新と FireSIGHT システムの更新およびそのアンインストーラの更新が示されます。
脆弱性のマッピングを更新するのにかかる時間は、ネットワーク マップ内のホストの数によって異なります。システムのダウンタイムの影響を最小にするために、システムの使用率が低い時間帯に更新をスケジュールすることをお勧めします。一般的に、更新の実行にかかるおおよその時間(分)を判断するには、ネットワーク上のホストの数を 1000 で割ります。
注 アプリケーション ディテクタまたはオペレーティング システム フィンガープリントに対する変更とともに VDB の更新をインストールする場合、シスコでは、いずれかの管理対象デバイスが有効期限を経過していないか、および再適用が必要でないかをチェックすることを推奨しています。検出の更新とともに VDB の更新をインストールすると、管理対象デバイス上でトラフィック フローと処理が一時的に停止することがあります。また、いくつかのパケットが検査されない場合があります。
この項では、手動による VDB 更新を計画および実行する方法について説明します。自動更新機能を利用して VDB の更新をスケジュールすることもできます。「脆弱性データベースの更新の自動化」を参照してください。
脆弱性データベースを更新する方法:
アクセス:Admin
ステップ 1 更新用の VDB 更新アドバイザリ テキストを読みます。
このアドバイザリ テキストには、更新で作成された VDB に対する変更、および製品の互換性情報が含まれています。
ステップ 2 [System] > [Updates] を選択します。
[Product Updates] ページが表示されます。
ステップ 3 防御センターへ更新をアップロードします。
• 防御センターがインターネットにアクセスできる場合は、[Download Updates] をクリックして、次のいずれかのサポート サイトで最新の更新を確認します。
–Sourcefire: (https://support.sourcefire.com/)
–シスコ: (http://www.cisco.com/cisco/web/support/index.html)
• 防御センターがインターネットにアクセスできない場合は、次のいずれかのサポート サイトから更新を手動でダウンロードして [Upload Update] をクリックします。更新を参照して、[Upload] をクリックします。
–Sourcefire: (https://support.sourcefire.com/)
–シスコ: (http://www.cisco.com/cisco/web/support/index.html)
注 サポート サイトから、手動でまたは [Download Updates] をクリックして、更新を直接ダウンロードします。電子メールで更新ファイルを転送すると、ファイルが破損することがあります。
更新が防御センターへアップロードされます。
ステップ 4 VDB 更新の隣にあるインストール アイコンをクリックします。
[Install Update] ページが表示されます。
ステップ 5 防御センターを選択し、[Install] をクリックします。
更新プロセスが開始されます。ネットワーク マップ内のホストの数によっては、更新のインストールに時間がかかることがあります。タスク キュー([System] > [Monitoring] > [Task Status])で更新の進捗を監視することができます。
注意 更新が完了するまで、マップされた脆弱性に関連するタスクを実行するために Web インターフェイスを使用
しないでください。(タスク キューに更新が失敗したことが示されている、またはタスク キューの手動更新で進捗が表示されないなど)更新で問題が発生した場合には、更新を再開
しないでください。代わりに、サポートへ連絡してください。
ステップ 6 更新が終了したら、[Help] > [About] を選択して、VDB のビルド番号が、インストールした更新と一致していることを確認します。
ルールの更新とローカル ルール ファイルのインポート
ライセンス:任意
新しい脆弱性が見つかると、シスコ脆弱性調査チーム(VRT)はルールの更新をリリースします。ルールの更新では、新しいおよび更新された侵入ルールおよびプリプロッセサ ルール、既存のルールの変更された状態、および変更されたデフォルトの侵入ポリシーの設定が提供されます。ルールの更新では、ルールが削除されたり、新しいルール カテゴリとデフォルトの変数が提供されたりすることもあります。
注 ルールの更新には、新しいバイナリが含まれることがあります。ルールの更新をダウンロードおよびインストールするプロセスが、セキュリティ ポリシーに適合していることを確認します。また、ルールの更新は大規模になることがあるため、ネットワークの使用率が低いときにルールをインポートするようにします。
次に、ルールをインポートするときに考慮すべき重要なポイントを示します。
• ルールの更新での新しいルールについては、ルールの状態がそれぞれのデフォルト ポリシーで異なる場合があります。たとえば、Security over Connectivity のデフォルト ポリシーでは新しいルールが有効になっており、Connectivity over Security のデフォルト ポリシーでは無効になっていることがあります。詳細については、「デフォルト侵入ポリシーの使用」を参照してください。
ルールの更新では、既存のルールのデフォルト状態が変更されることもあります。ルールの更新で、作成する侵入ポリシーにおける既存ルールのデフォルト状態を変更できるようにするかどうかの選択については、「ルール更新による基本ポリシーの変更の許可」を参照してください。
• ルールの更新は累積的であるため、最新のルールの更新には、それまでのすべての更新の侵入ルールが含まれています。現在インストールされているルールのバージョンに一致するルール更新、またはそれより前のバージョンのルール更新をインポートすることはできません。
• シスコにより提供されるデフォルト ポリシーをベース ポリシーとして使用する場合は、ルールの更新でベース ポリシーを変更して、侵入ルール、プリプロセッサ ルール、および詳細な設定の変更を可能にするかどうかを選択することができます。詳細については、「基本ポリシーについて」および「ルール更新による基本ポリシーの変更の許可」を参照してください。
• ルールの更新には、新しいデフォルト変数、および既存のデフォルト変数の変更された値が含まれることがあります。新しい変数は常にシステムに追加されます。既存の変数値は、変更されていない場合にのみ更新されます。詳細については、「変数セットの操作」を参照してください。
• ルールの更新には、新しいルール カテゴリが含まれることがあります。ルールの更新の新しいルール カテゴリは常にシステムに追加されます。詳細については、「ルール カテゴリについて」を参照してください。
• [Rule Updates] ページには、侵入ポリシーとキャッシュされた変更、および変更を行ったユーザが表示されます。ルールの更新をインポートすると、キャッシュされていた変更がすべて廃棄されます。詳細については、「侵入ポリシー変更のコミット」を参照してください。
• ルールの更新に共有オブジェクト ルールが含まれている場合に、ルールのインポートの後でアクセス コントロール ポリシーを初めて適用すると、トラフィック フローと処理が一時的に停止し、いくつかのパケットが検査されなくなる場合があります。
• FireSIGHT システムの展開に、高可用性ペアとして 2 つの 防御センター が設定されている場合は、一方の 防御センター でルールを更新するだけで済みます。2 番目の防御センターは、通常の同期プロセスの一環としてルールの更新を受け取ります。
• オプションで、インポートが完了したときに、ルールの更新をインポートしたアプライアンスが所有している侵入ポリシーを自動的に再適用できます。
詳細については、次の項を参照してください。
• 「ワンタイム ルール更新の使用」では、サポート サイトから 1 つのルール更新をインポートする方法について説明しています。
• 「再帰的なルール更新の使用」では、Web インターフェイスで自動機能を使用して、サポート サイトからルールの更新をダウンロードおよびインストールする方法について説明しています。
• 「ローカル ルール ファイルのインポート」では、ローカル マシンで作成した標準テキスト ルール ファイルのコピーをインポートする方法について説明しています。
• 「ルール更新ログの表示」では、ルール更新のログについて説明しています。
ワンタイム ルール更新の使用
ライセンス:任意
ワンタイム ルール更新では次の 2 つの方法を使用することができます。
• 「手動によるワンタイム ルール更新の使用」では、サポート サイトからローカル マシンへ手動でルール更新をダウンロードし、それを手動でインストールする方法について説明しています。
• 「自動のワンタイム ルール更新の使用」では、Web インターフェイスで自動機能を使用し、サポート サイトで新しいルール更新を検索し、それをアップロードする方法について説明しています。
手動によるワンタイム ルール更新の使用
ライセンス:任意
次の手順では、新しいルール更新を手動でインポートする方法について説明します。この手順は、防御センターがインターネットにアクセスできない場合に特に有用です。
手動でルール更新をインポートする方法:
アクセス:Admin
ステップ 1 インターネットにアクセスできるコンピュータから、次のサポート サイトのいずれかへアクセスします。
• Sourcefire: (https://support.sourcefire.com/)
• シスコ: (http://www.cisco.com/cisco/web/support/index.html)
ステップ 2 [Download] をクリックし、[Rules] をクリックします。
ステップ 3 最新のルール更新へ移動します。
ヒント ルールの更新は累積的であるため、最新のルールの更新には、それまでのすべてのルール更新の侵入ルールおよび新しい機能が含まれています。現在インストールされている更新のバージョンよりも低いバージョン番号のルール更新をインポートすることはできません。
ステップ 4 ダウンロードするルール更新ファイルをクリックし、そのファイルをコンピュータに保存します。
ステップ 5 アプライアンスの Web インターフェイスにログインします。
ステップ 6 [System] > [Updates] を選択し、[Rule Updates] タブを選択します。
[Rule Updates] ページが表示されます。
ヒント または [Rule Editor] ページで [Import Rules] をクリックします。ここには、[Policies] > [Intrusion] > [Rule Editor] を選択してアクセスすることができます。
ステップ 7 オプションで [Delete All Local Rules] をクリックし、[OK] をクリックして、作成した、または削除されたフォルダにインポートしたすべてのユーザ定義ルールを移動します。詳細については、「カスタム ルールの削除」を参照してください。
ステップ 8 [Rule Update or text rule file to upload and install] を選択し、[Browse] をクリックしてナビゲートし、ルール更新ファイルを選択します。
ステップ 9 オプションで [Reapply intrusion policies after the Rule Update import completes] を選択し、ルール更新のインポートが完了したときに、適用されている侵入ポリシーをこのアプライアンスから自動的に再適用します。
FireSIGHT システムの複数のバージョンを実行しているスタック デバイスに対しては(デバイスの 1 つがアップグレードに失敗した場合など)、アクセス コントロール ポリシーを適用できないことに注意してください。詳細については、「スタックに含まれるデバイスの管理」を参照してください。
ステップ 10 [Import] をクリックします。
ルールの更新がインストールされ、[Rule Update Log] 詳細ビューが表示されます。詳細については、「[Rule Update Import Log] 詳細ビューについて」を参照してください。
手順 9 で [Reapply intrusion policies after the Rule Update import completes] を選択すると、システムは、現在適用されているアクセス コントロール ポリシーの侵入ポリシーのみを適用し、アクセス コントロール ポリシーは適用しません。詳細については、「アクセス コントロール ポリシーの適用」を参照してください。
[Reapply intrusion policies after the Rule Update import completes] を選択しない場合は、影響を受ける侵入ポリシーを次に適用するまで、ルール更新の変更点は有効になりません。詳細については、「侵入ポリシーの再適用」を参照してください。
注 ルール更新のインストール中にエラー メッセージが表示された場合は、サポートに連絡してください。
自動のワンタイム ルール更新の使用
ライセンス:任意
次の手順では、サポート サイトに自動で接続して、新しいルール更新をインポートする方法について説明します。この手順は、アプライアンスがインターネットにアクセスできる場合のみ使用できます。
自動でルール更新をインポートする方法:
アクセス:Admin
ステップ 1 [System] > [Updates] を選択し、[Rule Updates] タブを選択します。
[Rule Updates] ページが表示されます。
ヒント または [Rule Editor] ページで [Import Rules] をクリックします。ここには、[Policies] > [Intrusion] > [Rule Editor] を選択してアクセスすることができます。
ステップ 2 オプションで [Delete All Local Rules] をクリックし、[OK] をクリックして、作成した、または削除されたフォルダにインポートしたすべてのユーザ定義ルールを移動します。詳細については、「カスタム ルールの削除」を参照してください。
ステップ 3 [Download new Rule Update from the Support Site] を選択します。
ステップ 4 オプションで [Reapply intrusion policies after the Rule Update import completes] を選択し、ルール更新が完了したときに、適用されている侵入ポリシーをこのアプライアンスから自動的に再適用します。
FireSIGHT システムの複数のバージョンを実行しているスタック デバイスに対しては(デバイスの 1 つがアップグレードに失敗した場合など)、侵入ポリシーを適用できないことに注意してください。詳細については、「スタックに含まれるデバイスの管理」および「侵入ポリシーの再適用」を参照してください。
ステップ 5 [Import] をクリックします。
ルールの更新がインストールされ、[Rule Update Log] 詳細ビューのワークフローが表示されます。詳細については、「[Rule Update Import Log] 詳細ビューのフィールド」を参照してください。
手順 4 で [Reapply intrusion policies after the Rule Update import completes] を選択すると、システムは、現在適用されているアクセス コントロール ポリシーの侵入ポリシーのみを適用し、アクセス コントロール ポリシーは適用しません。詳細については、「アクセス コントロール ポリシーの適用」を参照してください。
[Reapply intrusion policies after the Rule Update import completes] を選択しない場合は、影響を受ける侵入ポリシーを次に適用するまで、ルール更新の変更点は有効になりません。詳細については、「侵入ポリシーの再適用」を参照してください。
注 ルール更新のインストール中にエラー メッセージが表示された場合は、サポートに連絡してください。
再帰的なルール更新の使用
ライセンス:任意
[Rule Updates] ページを使用して、ルール更新を日次、週次、または月次ベースでインポートすることができます。FireSIGHT システムの展開に、高可用性ペアとして 2 つの防御センターが設定されている場合は、一方の防御センターでルールを更新するだけで済みます。2 番目の防御センターは、通常の同期プロセスの一環としてルールの更新を受け取ります。
再帰的なルール更新をスケジュールする方法:
アクセス:Admin
ステップ 1 [System] > [Updates] を選択し、[Rule Updates] タブを選択します。
[Rule Updates] ページが表示されます。
ヒント または [Rule Editor] ページで [Import Rules] をクリックします。ここには、[Policies] > [Intrusion] > [Rule Editor] を選択してアクセスすることができます。
ステップ 2 オプションで [Delete All Local Rules] をクリックし、[OK] をクリックして、作成した、または削除されたフォルダにインポートしたすべてのユーザ定義ルールを移動します。詳細については、「カスタム ルールの削除」を参照してください。
ステップ 3 [Enable Recurring Rule Update Imports] を選択します。
ページが拡張され、再帰的なインポートを設定するためのオプションが表示されます。
[Recurring Rule Update Imports] セクション見出しの下に、インポート ステータスのメッセージが表示されます。設定を保存すると、再帰的なインポートが有効になります。
ヒント 再帰的なインポートを無効にするには、[Enable Recurring Rule Update Imports] チェック ボックスをオフにして [Save] をクリックします。
ステップ 4 [Import Frequency] フィールドで、ドロップダウン リストから [Daily]、[Weekly]、または [Monthly] を選択します。
ヒント 選択する内容をクリックするか、または選択する内容の最初の文字または数字を 1 回以上入力して、Enter キーを押すことで、再帰タスクのドロップダウン リストから選択できます。
ステップ 5 [Import Frequency] フィールドで [Weekly] を選択した場合は、表示されるドロップダウン リストを使用して、ルールの更新をインポートする曜日を選択します。
ステップ 6 [Import Frequency] フィールドで [Monthly] を選択した場合は、表示されるドロップダウン リストを使用して、ルールの更新をインポートする月の日を選択します。
ステップ 7 [Import Frequency] フィールドで、再帰的なルール更新のインポートを開始するタイミングを指定します。
ステップ 8 オプションで [Reapply intrusion policies after the Rule Update import completes] を選択し、ルール更新のインポートが完了したときに、適用されている侵入ポリシーをこのアプライアンスから自動的に再適用します。
FireSIGHT システムの複数のバージョンを実行しているスタック デバイスに対しては(デバイスの 1 つがアップグレードに失敗した場合など)、侵入ポリシーを適用できないことに注意してください。詳細については、「スタックに含まれるデバイスの管理」を参照してください。
ステップ 9 [Save] をクリックし、設定を使用した再帰的なルール更新のインポートを有効にします。
[Recurring Rule Update Imports] セクションの見出しの下のステータス メッセージが変わり、ルールの更新がまだ実行されていないことが示されます。
スケジュールされた時間にルールの更新がインストールされ、ルールが更新されます。インポートの前、またはインポート中にログオフすることも、Web インターフェイスを使用して他のタスクを実行することもできます。インポート中にアクセスした場合は、[Rule Update Log] に赤いステータスのアイコン( )が表示されます。詳細については、「ルール更新ログの表示」を参照してください。インポート中に、[Rule Update Log] 詳細ビューに表示されるメッセージを表示することもできます。詳細については、「[Rule Update Import Log] 詳細ビューのフィールド」を参照してください。
注 ルールの更新のサイズと内容によっては、[Rule Update Log] または [Rule Update Log] 詳細ビューにステータス メッセージが表示されるまでに数分かかることがあります。
手順 8 で [Reapply intrusion policies after the Rule Update import completes] を選択すると、システムは、現在適用されているアクセス コントロール ポリシーの侵入ポリシーのみを適用し、アクセス コントロール ポリシーは適用しません。詳細については、「アクセス コントロール ポリシーの適用」を参照してください。
[Reapply intrusion policies after the Rule Update import completes] を選択しない場合は、影響を受ける侵入ポリシーを次に適用するまで、ルール更新の変更点は有効になりません。詳細については、「侵入ポリシーの再適用」を参照してください。
ルール更新のインポートにおける適用可能なサブタスクは、ダウンロード、インストール、ベース ポリシーの更新、およびポリシーの再適用の順序で生じます。1 つのサブタスクが完了すると、次のサブタスクが開始されます。適用できるのは、再帰的なインポートが設定されているアプライアンスで以前に適用されたポリシーのみであることに注意してください。
注 ルール更新のインストール中にエラー メッセージが表示された場合は、サポートに連絡してください。
ローカル ルール ファイルのインポート
ライセンス:任意
ローカル ルールはカスタム標準テキスト ルールで、ユーザがローカル マシンから ASCII テキスト ファイルとしてインポートします。Snort ユーザ マニュアル(http://www.snort.org で入手可能)の指示に従って、ローカル ルールを作成することができます。
ローカル ルールのインポートについて、次の点に注意してください。
• テキスト ファイル名には英数字とスペースを使用できますが、下線( _
)、ピリオド( .
)、ダッシュ( -
)以外の特殊記号は使用できません。
• ジェネレータ ID(GID)を指定する必要はありません。GID を指定する場合は、標準テキスト ルールに対しては GID 1、機密データ ルールに対しては 138 のみ指定できます。
• 初めてルールをインポートするときには、Snort ID(SID)またはリビジョン番号を指定 しないで ください。これにより、削除されたルールを含む、他のルールの SID との競合が回避されます。
システムはルールに対して、1000000 以上の次に使用できるカスタム ルール SID 、およびリビジョン番号 の 1 を自動的に割り当てます。
• 以前にインポートしたローカル ルールの更新バージョンをインポートする場合には、システムによって割り当てられた SID、および現在のリビジョン番号よりも大きいリビジョン番号を 含める必要があります 。
現行のローカル ルールのリビジョン番号を表示するには、[Rule Editor] ページ([Policies] > [Intrusion] > [Rule Editor])を表示し、ローカル ルールのカテゴリをクリックしてフォルダを展開し、ルールの隣にある [Edit] をクリックします。
• システムによって割り当てられた SID、および現行のリビジョン番号よりも大きいリビジョン番号を使用してルールをインポートして削除したローカル ルールは、元に戻すことができます。ローカル ルールを削除すると、システムは自動的にリビジョン番号を増やすことに注意してください。これは、ローカル ルールを元に戻すための方法です。
削除されたローカル ルールのリビジョン番号を表示するには、[Rule Editor] ページ([Policies] > [Intrusion] > [Rule Editor])を表示し、削除されたルール カテゴリをクリックしてフォルダを展開し、ルールの隣にある [Edit] をクリックします。
• 2147483647 よりも大きい SID を持つルールが含まれているルール ファイルはインポートできません。この場合、インポートが失敗します。
• 64 文字を超える送信元または宛先のポートのリストが含まれているルールをインポートすると、そのインポートは失敗します。
• システムは常に、ユーザがインポートするローカル ルールを無効なルール状態に設定します。これらを侵入ポリシーで使用するには、その前に手動でローカル ルールの状態を設定する必要があります。詳細については、「ルール状態の設定」を参照してください。
• ファイル内のルールに、エスケープ文字が含まれていないことを確認する必要があります。
• ルール インポータでは、すべてのカスタム ルールを ASCII または UTF-8 エンコードでインポートする必要があります。
• インポートされたすべてのローカル ルールは、ローカル ルール カテゴリに自動的に保存されます。
• 削除されたすべてのローカル ルールは、ローカル ルール カテゴリから、削除されたルール カテゴリへ移動されます。
• システムは、単一のポンド文字(#)で始まるローカル ルールをインポートします。
• また、二重のポンド文字(##)で始まるローカル ルールは無視し、インポートしません。
• シスコでは、SID の番号付けの問題を回避するために、高可用性ペアのプライマリ防御センターにローカル ルールをインポートすることを強くお勧めしています。
• 侵入ポリシーで、侵入イベントのしきい値機能と組み合わせて非推奨の threshold
キーワードを使用しているローカル ルールをインポートして有効にすると、ポリシーの検証は失敗します。詳細については、「イベントしきい値の設定」を参照してください。
ローカル ルール ファイルをインポートする方法:
アクセス:Admin
ステップ 1 [Policies] > [Intrusion] > [Rule Editor] の順に選択します。
[Rule Editor] ページが表示されます。
ステップ 2 [Import Rules] をクリックします。
[Import Rules] ページが表示されます。
ヒント [System] > [Updates] を選択して、[Rule Updates] タブを選択することもできます。
ステップ 3 [Rule Update or text rule file to upload and install] を選択して [Browse] をクリックすると、ルール ファイルにナビゲートできます。この方法でアップロードされたすべてのルールは、ローカル ルール カテゴリに保存されることに注意してください。
ステップ 4 [Import] をクリックします。
ルール ファイルがインポートされます。侵入ポリシーで、適切なルールが有効になっていることを確認してください。影響を受けるポリシーが次に適用されるまで、ルールはアクティブにはなりません。
注 管理対象デバイスは、侵入ポリシーを適用するまで、インスペクションに対して新しいルール セットを使用しません。手順については、「アクセス コントロール ポリシーの適用」を参照してください。
ルール更新ログの表示
ライセンス:任意
防御センターは、ユーザがインポートする各ルール更新およびローカル ルール ファイルごとに 1 つのレコードを生成します。
各レコードにはタイム スタンプ、ファイルをインポートしたユーザ名、およびインポートが正常に終了したか失敗したかを示すステータス アイコンが含まれています。ユーザは、自分がインポートするすべてのルール更新およびローカル ルール ファイルのリストを管理する、リストからレコードを削除する、インポートしたすべてのルールおよびルール更新のコンポーネントについての詳細レコードにアクセスする、といったことができます。以下の表で、[Rule Update Log] のフィールドについて説明します。
表 53-2 [Rule Update Log] のアクション
|
|
テーブルのカラムの内容について詳しく調べる |
詳細については、「[Rule Update Log] 表について」を参照してください。 |
インポート ログからインポート ファイル レコード(ファイルに含まれているすべてのオブジェクトについて削除されたレコードも含めて)を削除する |
インポート ファイルでファイル名の隣にある削除アイコン( )をクリックします。 (注) ログからファイルを削除しても、インポート ファイルにインポートされているオブジェクトはいずれも削除されませんが、インポート ログ レコードのみは削除されます。 |
ルール更新またはローカル ルール ファイルにインポートされている各オブジェクトの詳細を表示する |
インポート ファイルでファイル名の隣にある表示アイコン( )をクリックします。 |
詳細については、次の項を参照してください。
• 「[Rule Update Log] 表について」では、インポートするルール更新およびローカル ルール ファイルのリスト内のフィールドについて説明します。
• 「[Rule Update Import Log] の詳細の表示」では、ルール更新またはローカル ルール ファイルにインポートされた各オブジェクトの詳細レコードについて説明します。
• 「[Rule Update Import Log] 詳細ビューについて」では、[Rule Update Log] 詳細ビューの各フィールドについて説明します。
• 「[Rule Update Import Log] の検索」では、インポート ログで検索基準と一致する特定のレコード、またはすべてのレコードを検索する方法について説明します。
[Rule Update Log] を表示する方法:
アクセス:Admin
ステップ 1 [System] > [Updates] を選択し、[Rule Updates] タブを選択します。
[Rule Updates] ページが表示されます。
ヒント または [Rule Editor] ページで [Import Rules] をクリックします。ここには、[Policies] > [Intrusion] > [Rule Editor] を選択してアクセスすることができます。
ステップ 2 [Rule Update Log] をクリックします。
[Rule Update Log] ページが表示されます。このページには、インポートされた各ルール更新とローカル ルール ファイルが示されています。
[Rule Update Log] 表について
ライセンス:任意
次の表で、ユーザがインポートするルール更新およびローカル ルール ファイルのリストのフィールドについて説明します。
表 53-3 [Rule Update Log] のフィールド
|
|
Summary |
インポート ファイルの名前。インポートが失敗した場合は、ファイル名の下に、失敗した理由の簡単な説明が表示されます。 |
Time |
インポートが開始された日時。 |
User ID |
インポートをトリガーとして使用したユーザ名。 |
Status |
インポートの状態を表します • 正常終了( ) • 失敗した、または実行中( ) ヒント インポート中には [Rule Update Log] ページで、正常終了しなかった、または完了していないことを示す赤いステータス アイコンが表示され、インポートが正常終了した場合のみこれが緑色のアイコンに変わります。 |
ルール更新またはファイル名の隣にある表示アイコン( )をクリックして、ルール更新またはローカル ルール ファイルの [Rule Update Log] 詳細ページを表示するか、または削除アイコン( )をクリックして、ファイル レコード、およびファイルと一緒にインポートされたすべての詳細オブジェクト レコードを削除します。
ヒント ルール更新のインポートの進行中に示される、インポートの詳細を表示することができます。
[Rule Update Import Log] の詳細の表示
ライセンス:任意
[Rule Update Import Log] 詳細ビューには、ルール更新またはローカル ルール ファイルにインポートされた各オブジェクトの詳細レコードが表示されます。表示されるレコードのうち、自分のニーズに合う情報のみを含むカスタム ワークフローまたはレポートを作成することもできます。
次の表は、[Rule Update Import Log] 詳細ビューのワークフロー ページで実行できる特定のアクションについて説明します。
[Rule Update Import Log] 詳細ビューを表示する方法:
アクセス:Admin
ステップ 1 [System] > [Updates] を選択し、[Rule Updates] タブを選択します。
[Rule Updates] ページが表示されます。
ヒント または [Rule Editor] ページで [Import Rules] をクリックします。ここには、[Policies] > [Intrusion] > [Rule Editor] を選択してアクセスすることができます。
ステップ 2 [Rule Update Log] をクリックします。
[Rule Update Log] ページが表示されます。
ステップ 3 表示する詳細レコードが含まれているファイルの隣にある表示アイコン( )をクリックします。
詳細レコードのテーブル ビューが表示されます。
[Rule Update Import Log] 詳細ビューについて
ライセンス:任意
ルール更新またはローカル ルール ファイルにインポートされた各オブジェクトの詳細レコードを表示することができます。以下の表で、[Rule Update Log] 詳細ビューのフィールドについて説明します。
表 53-5 [Rule Update Import Log] 詳細ビューのフィールド
|
|
Time |
インポートが開始された日時。 |
Name |
インポートされたオブジェクトの名前。ルールの場合はルールの [Message] フィールドに対応した名前で、ルール更新コンポーネントの場合はコンポーネント名です。 |
Type |
インポートされたオブジェクトのタイプで、有効な値は次のいずれかです。 • [rule update component](ルール パックまたはポリシー パックなどの、インポートされたコンポーネント) • [rule](新しいルールまたは更新されたルールの場合。バージョン 5.0.1 では、廃止された [update] 値の代わりにこの値が使用されます)。 • [policy apply](インポートで [Reapply intrusion policies after the Rule Update import completes] オプションが有効だった場合) |
Action |
オブジェクト タイプについて、次のいずれかが発生していることを示します。 • [new](ルールで、このアプライアンスにルールが最初に格納された場合) • [changed](ルール更新コンポーネントまたはルールで、ルール更新コンポーネントが変更された場合、ルールのリビジョン番号が大きく、GID と SID が同じだった場合) • [collision](ルール更新コンポーネントまたはルールで、アプライアンス上の既存のコンポーネントまたはルールとリビジョンの競合によりインポートがスキップされた場合) • [deleted](ルールで、ルール更新からルールが削除された場合) • [enabled](ルール更新の編集で、プリプロセッサ、ルール、または他の機能が、シスコによって提供されるデフォルト ポリシーで有効になっていた場合) • [disabled](ルールで、シスコによって提供されるデフォルト ポリシーでルールが無効になっていた場合) • [drop](ルールで、シスコによって提供されるデフォルト ポリシーで、ルールが [Drop] または [Generate Events] に設定されていた場合) • [error](ルール更新またはローカル ルール ファイルで、インポートが失敗した場合) • [apply](インポートで [Reapply intrusion policies after the Rule Update import completes] オプションが有効だった場合) |
Default Action |
ルールの更新によって定義されているデフォルトのアクション。インポートされたオブジェクトのタイプが [rule] の場合、デフォルトのアクションは [Pass]、[Alert]、または [Drop] になります。インポートされた他のすべてのオブジェクト タイプには、デフォルトのアクションはありません。 |
GID |
ルールのジェネレータ ID。例: 1 (標準テキスト ルール)や 3 (共有オブジェクト ルールなど)。詳細については、 「ジェネレータ ID」 の表を参照してください。 |
SID |
ルールの SID。 |
Rev |
ルールのリビジョン番号。 |
Policy |
インポートされたルールの場合、このフィールドには [All] が表示されます。これは、インポートされたルールがデフォルトのすべての侵入ポリシーに含まれていたことを意味します。インポートされた他のタイプのオブジェクトについては、このフィールドは空白です。 |
Details |
コンポーネントまたはルールに対する一意の文字列。ルール、GID、SID、および変更されたルールの以前のリビジョン番号については、 previously (GID:SID:Rev) のように表示されます。変更されていないルールについては、このフィールドは空白です。 |
Count |
各レコードのカウント( 1 )。テーブルが制限されており、[Rule Update Log] 詳細ビューがデフォルトでルール更新レコードに制限されている場合は、テーブル ビューに [Count] フィールドが表示されます。 |
[Rule Update Import Log] の検索
ライセンス:任意
インポート ログで検索基準と一致する特定のレコード、またはすべてのレコードを検索することができます。カスタマイズされた検索を作成し、後で再利用できるように保存しておくこともできます。
ヒント 1 つのインポート ファイルのレコードのみが表示されている [Rule Update Import Log] 詳細ビューからツールバーの [Search] をクリックして検索を開始した場合でも、[Rule Update Import Log] データベースの全体が検索されます。検索の対象とするすべてのオブジェクトが含まれるように、時間制限が設定されていることを確認します。詳細については、「検索での時間制約の指定」を参照してください。
次の表で、ユーザが使用できる検索条件について説明します。レコード検索では大文字/小文字が区別されないことに注意してください。たとえば、 RULE
または rule
の検索では同じ結果が得られます。
表 53-6 [Rule Update Import Log] の検索基準
|
|
|
Time |
レコードが生成された日時を指定します。時間入力の構文については、「検索での時間制約の指定」を参照してください。 |
> 2006-01-15 13:30:00 のように指定すると、2006 年 1 月 15 日午後 1:30 より後にインポートされたすべてのルール レコードが返されます。 |
Name |
ルールの [Message] フィールドのすべてまたは一部の内容を指定します。このフィールドでは、ワイルドカード文字としてアスタリスク(*)を使用できます。 |
*dhcp* のように指定すると、[Message] フィールドで DHCP という文字列が含まれるすべてのルール レコードが返されます。 |
Type |
レコードのタイプを指定します。[rule update component]、[rule]、または [policy apply] を使用できます。 バージョン 5.0.1 より前にインポートされたルールの検索では、検索で [update] 検索値を使用できることに注意してください。 |
[update] を指定すると、ルール パックやポリシー パックなど、インポートされたルール更新コンポーネントが返されます。[rule] を指定すると、新しいルールも含めてルールの更新が返されます。[policy apply] を指定すると、更新の後に侵入ポリシーが自動的に再適用されたルール更新の情報が、表形式の行で返されます。 |
Action |
表示するオブジェクトに対するアクションを指定します。指定できるアクションについては、 「[Rule Update Import Log] 詳細ビューのフィールド」 の表を参照してください。 |
タイプが [rule]、[new] の場合は、アプライアンスに最初にインポートされたすべてのルールが返されます。 |
GID |
ルールのジェネレータ ID を指定します。 |
3 を指定すると、すべての共有オブジェクト ルールが返されます。 |
SID |
ルールのシグネチャ ID または SID の範囲を指定します。 |
923 と指定すると、SID 923 を持つルールのレコードが返されます。 |
Rev |
ルールのリビジョン番号を指定します。 |
3 を指定すると、リビジョン番号 3 のルールが返されます。 |
Policy |
ルールがインポートされたデフォルト ポリシーを指定します。 |
[All] を指定すると、すべてのデフォルト ポリシーにインポートされたルールが返されます。 |
Rule Update |
Rule Update ファイルの名前を指定します。 |
[filename] と指定すると、指定されたインポート ファイルのすべてのレコードが返されます。 |
Details |
インポートされたオブジェクトの詳細を指定します。 |
previously* と指定すると、変更されたすべてのルールのレコードが返されます。 |
保存されている検索をロードおよび削除する方法など、検索の詳細については、「イベントの検索」を参照してください。
[Rule Update Import Log] を検索する方法:
アクセス:Admin/Intrusion Admin
ステップ 1 [Analysis] > [Search] を選択します。
[Search] ページが表示されます。
ステップ 2 [Table] ドロップダウン リストから、[Rule Update Import Log] を選択します。
ページが適切な制約を使用してリロードされます。
ヒント [Rule Update Log] 詳細ビューで [Search] をクリックすることもできます。「[Rule Update Import Log] の詳細の表示」を参照してください。
ステップ 3 オプションで、検索を保存するには、[Name] フィールドに検索の名前を入力します。
名前を入力しない場合は、検索が保存されるときに Web インターフェイスで自動的に名前が生成されます。
ステップ 4 表 「[Rule Update Import Log] の検索基準」 に記載されているように、該当するフィールドに検索基準を入力します。複数の条件を入力すると、検索によって、すべての基準に一致するレコードが返されます。
ステップ 5 他のユーザがアクセスできるように検索を保存する場合、[Save As Private] チェック ボックスをクリアします。そうしない場合は、検索をプライベートとして保存するために、チェック ボックスを選択したままにします。
検索をカスタム ユーザ ロールのデータ制限として使用する場合は、 必ず プライベート検索として保存してください。
ステップ 6 次の選択肢があります。
• 検索を開始するには、[Search] をクリックします。
デフォルトの [Rule Update Import Log] 詳細ビューのワークフローに検索結果が示されます。カスタム ワークフローなどの別のワークフローを使用するには、[(switch workflows)] をクリックします。別のデフォルト ワークフローの指定方法については、「イベント ビュー設定の設定」を参照してください。
• 既存の検索を変更し、その変更を保存したい場合は、[Save] をクリックします。
• 検索基準を保存する場合は、[Save as New Search] をクリックします。検索が保存され([Save As Private] を選択した場合はユーザ アカウントに関連付けられ)、後で実行できます。
地理情報データベースについて
ライセンス:FireSIGHT
サポート対象防御センター:任意(DC500 を除く)
シスコ Geolocation Database(GeoDB)は、ルート可能な IP アドレスに関連する地理情報データ(国、都市、緯度と経度の座標など)、および接続関係のデータ(インターネット サービス プロバイダ、ドメイン ネーム、接続タイプなど)のデータベースです。システムで、検出された IP アドレスと一致する GeoDB 情報が検出された場合は、その IP アドレスに関連付けられている地理情報を表示することができます。国や大陸以外の地理情報の詳細を表示するには、システムに GeoDB をインストールする必要があります。シスコでは、GeoDB の定期的な更新を提供しています。
GeoDB を更新するには、防御センターで [Geolocation Updates] ページ([System] > [Updates] > [Geolocation Updates])を使用します。サポートまたは自身のアプライアンスから取得した GeoDB の更新をアップロードすると、このページに表示されます。
GeoDB の更新にかかる時間はアプライアンスによって異なります。インストールには通常、30~40 分かかります。GeoDB の更新は他のシステムの機能(実行中の地理情報の収集など)を中断することはありませんが、更新が完了するまでシステムのリソースを消費します。更新を計画する場合には、この点について考慮してください。
この項では、手動による GeoDB 更新を計画および実行する方法について説明します。自動更新機能を利用して GeoDB の更新をスケジュールすることもできます。詳細については、「位置情報データベースの更新の自動化」を参照してください。地理情報の詳細については、「地理情報の使用」を参照してください。
地理情報データベースを更新する方法:
アクセス:Admin
ステップ 1 [System] > [Updates] を選択します。
[Product Updates] ページが表示されます。
ステップ 2 [Geolocation Updates] タブをクリックします。
[Geolocation Updates] ページが表示されます。
ステップ 3 更新を防御センターへアップロードします。
• 防御センターがインターネットにアクセスできる場合は、[Download and install geolocation update from the Support Site] をクリックして、以下のサポート サイトのいずれかで最新の更新を確認します。
–Sourcefire: (https://support.sourcefire.com/)
–シスコ: (http://www.cisco.com/cisco/web/support/index.html)
• 防御センターがインターネットにアクセスできない場合は、以下のサポート サイトのいずれかから更新を手動でダウンロードして、[Upload and install geolocation update] をクリックします。更新を参照して、[Import] をクリックします。
–Sourcefire: (https://support.sourcefire.com/)
–シスコ: (http://www.cisco.com/cisco/web/support/index.html)
注 手動で、または [Geolocation Updates] ページで [Download and install geolocation update from the Support Site] をクリックして、サポート サイトから更新を直接ダウンロードします。 電子メールで更新ファイルを転送すると、ファイルが破損することがあります。
更新プロセスが開始されます。更新のインストールには、平均で 30~40 分かかります。これは、アプライアンスのハードウェアによって異なります。タスク キュー([System] > [Monitoring] > [Task Status])で更新の進捗を監視することができます。
ステップ 4 更新が終了したら、[Geolocation Updates] ページに戻るか、[Help] > [About] を選択して、GeoDB のビルド番号が、インストールした更新と一致していることを確認します。
GeoDB を更新すると、GeoDB の以前のバージョンが上書きされ、すぐに有効になります。GeoDB を更新すると、防御センターにより、管理対象デバイスが自動的に更新されます。展開全体で GeoDB の更新が有効になるには数分かかることがありますが、更新した後にアクセス コントロール ポリシーを再適用する必要はありません。