アップグレードガイドライン

このドキュメントには、バージョン 7.0 の重要なリリース固有のアップグレードガイドラインが記載されています。

アップグレードの計画

誤りを避けるには、注意深い計画と準備が役立ちます。この表はアップグレードの計画プロセスを要約したものです。詳細なチェックリストと手順については、該当するアップグレードガイドとコンフィギュレーション ガイド(https://cisco.com/go/threatdefense-70-docs)を参照してください。

表 1. アップグレードの計画フェーズ

計画フェーズ

次を含む

計画と実現可能性

展開を評価します。

アップグレードパスを計画します。

すべてのアップグレードガイドラインを読み、設定の変更を計画します。

アプライアンスへのアクセスを確認します。

帯域幅を確認します。

メンテナンス時間帯をスケジュールします。

バックアップ

設定およびイベントをバックアップします。

Firepower 4100/9300 の FXOS をバックアップします。

ASA FirePOWER 用 ASA をバックアップします。

アップグレードパッケージ

アップグレードパッケージをシスコからダウンロードします。

システムにアップグレードパッケージをアップロードします。

関連するアップグレード

仮想展開内で仮想ホスティングをアップグレードします。

Firepower 4100/9300 のファームウェアをアップグレードします。

Firepower 4100/9300 の FXOS をアップグレードします。

ASA FirePOWER 用 ASA をアップグレードします。

最終チェック

設定を確認します。

NTP 同期を確認します。

設定を展開します。

準備状況チェックを実行します。

ディスク容量を確認します。

実行中のタスクを確認します。

展開の正常性と通信を確認します。

アップグレードする最小バージョン

アップグレードする最小バージョン

次のように、メンテナンスリリースを含む バージョン 7.0 に直接アップグレードできます。

表 2. バージョン 7.0 にアップグレードするための最小バージョン

プラットフォーム

最小バージョン

FMC

6.4

FTD

6.4

Firepower 4100/9300 には FXOS 2.10.1.331 が必要です。ほとんどの場合、各メジャーバージョンで最新の FXOS ビルドを使用することを推奨します。判断のヒントについては、Cisco Firepower 4100/9300 FXOS Release Notes, 2.10(1)を参照してください。

ASA with FirePOWER サービス

6.4

モデルの ASA 要件については、デバイスプラットフォームを参照してください。ASA と ASA FirePOWER のバージョン間には広い互換性がありますが、アップグレードすることで、新機能と解決された問題を活用できます。判断のヒントについては、Cisco Secure Firewall ASA リリースノートを参照してください。

NGIPSv

6.4

パッチを適用する最小バージョン

パッチは 4 桁目のみを変更します。以前のメジャーリリースまたはメンテナンスリリースからパッチに直接アップグレードすることはできません。

バージョン 7.0 のアップグレードガイドライン

以下のチェックリストでは、該当する可能性のある新規アップグレードガイドラインや以前に公開されたアップグレードガイドラインを提供します。

表 3. を使用した Firewall Threat Defense のアップグレードガイドラインバージョン 7.0

ガイドライン

プラットフォーム

アップグレード元

直接アップグレード先

常にチェック

アップグレードする最小バージョン

任意(Any)

任意(Any)

任意(Any)

Cisco Secure Firewall Management Center の新機能(リリース別):アップグレードに影響を与える新機能および廃止された機能が記載されています。現在のバージョンと対象バージョンの間にあるすべてのバージョンを確認してください。

任意(Any)

任意(Any)

任意(Any)

バグ:アップグレードに影響を与えるバグが記載されています。現在のバージョンと対象バージョン間にあるすべてのバージョンのリリースノートを確認してください。

任意(Any)

任意(Any)

任意(Any)

クラウド提供型 Firewall Management Center のアップグレードガイドライン

Firewall Threat Defense

任意(Any)

任意(Any)

Firepower 4100/9300 シャーシのアップグレードガイドライン

Firepower 4100/9300

任意(Any)

任意(Any)

特定の展開に対するその他のガイドライン

アップグレード禁止:バージョン 7.0.4 以降から バージョン 7.1.0

任意(Any)

7.0.4 以降

7.1.0 のみ

End of Support for Cisco Secure Firewall Threat Defense 7.0.x with Cloud-delivered Firewall Management Center

任意(Any)

7.0.3 ~ 7.0.x

任意

高可用性 の Cisco Threat Grid に再接続する

6.4.0 〜 6.7.x

7.0 以上

アップグレードの失敗:Firepower 1010 スイッチポートでの無効な VLAN ID

Firepower 1010

6.4.0 〜 6.6.x

6.7 以降

Firewall Management Center Virtual には 28 GB の RAM が必要

FMCv

6.2.3 ~ 6.5.0.x

6.6 以降

Firepower 1000 シリーズ デバイスではアップグレード後に電源の再投入が必要

Firepower 1000 シリーズ

6.4.0

6.5 以降

新しい URL カテゴリとレピュテーション

いずれか

6.2.3 ~ 6.4.0.x

6.5 以降

表 4. Firewall Device Manager を使用した Firewall Threat Defense のアップグレードガイドラインバージョン 7.0

ガイドライン

プラットフォーム

アップグレード元

直接アップグレード先

常にチェック

アップグレードする最小バージョン

任意(Any)

任意(Any)

任意(Any)

Cisco Secure Firewall デバイスマネージャの新機能(リリース別):アップグレードに影響を与える新機能および廃止された機能が記載されています。現在のバージョンと対象バージョンの間にあるすべてのバージョンを確認してください。

任意(Any)

任意(Any)

任意(Any)

バグ:アップグレードに影響を与えるバグが記載されています。現在のバージョンと対象バージョン間にあるすべてのバージョンのリリースノートを確認してください。

任意(Any)

任意(Any)

任意(Any)

Firepower 4100/9300 シャーシのアップグレードガイドライン

Firepower 4100/9300

任意(Any)

任意(Any)

特定の展開に対するその他のガイドライン

アップグレード禁止:バージョン 7.0.4 以降から バージョン 7.1.0

任意(Any)

7.0.4 以降

7.1.0 のみ

アップグレードの失敗:Firepower 1010 スイッチポートでの無効な VLAN ID

Firepower 1010

6.4.0 〜 6.6.x

6.7 以降

Firepower 1000 シリーズ デバイスではアップグレード後に電源の再投入が必要

Firepower 1000 シリーズ

6.4.0

6.5 以降

Firewall Device Manager を使用した Firewall Threat Defense のアップグレード時に削除される履歴データ

いずれか

6.2.3 ~ 6.4.0.x

6.5 以降

新しい URL カテゴリとレピュテーション

いずれか

6.2.3 ~ 6.4.0.x

6.5 以降

アップグレード禁止:バージョン 7.0.4 以降から バージョン 7.1.0

展開:すべて

アップグレード元:バージョン 7.0.4 以降のメンテナンスリリース

直接アップグレード先:バージョン 7.1.0 のみ

データストアの非互換性のため、 をバージョン 7.0.4 以降からバージョン 7.1.0 にアップグレードすることができません。バージョン 7.2 以降に直接アップグレードすることをお勧めします。

高可用性 の Cisco Threat Grid に再接続する

展開:動的分析のためにファイルを送信する高可用性/AMP for Networks(マルウェア検出)展開

アップグレード元:バージョン 6.4.0 ~ 6.7.x

直接アップグレード先:バージョン 7.0.0 以降

関連するバグ: CSCvu35704

バージョン 7.0.0 では、フェールオーバー後にシステムが動的分析用のファイルの送信を停止する高可用性の問題が修正されています。修正を有効にするには、Cisco Threat Grid パブリッククラウドに再度関連付ける必要があります。

高可用性ペアをアップグレードした後、プライマリ で次の手順を実行します。

  1. [AMP] > [ダイナミック分析接続(Dynamic Analysis Connections)]を選択します。

  2. パブリッククラウドに対応するテーブル行で、 [関連付け(Associate)] をクリックします。

    ポータルウィンドウが開きます。サインインする必要はありません。再関連付けは、数分以内にバックグラウンドで行われます。

アップグレードの失敗:Firepower 1010 スイッチポートでの無効な VLAN ID

展開:Firepower 1010

アップグレード元:バージョン 6.4 ~ 6.6

直接アップグレード先:バージョン 6.7 以降

Firepower 1010 では、VLAN ID を 3968 〜 4047 の範囲にしてスイッチポートを設定した場合、Firewall Threat Defense のバージョン 6.7 以降へのアップグレードは失敗します。これらの ID は内部使用専用です。

Firewall Management Center Virtual には 28 GB の RAM が必要

展開:Firewall Management Center Virtual

アップグレード元:バージョン 6.2.3 ~ 6.5

直接アップグレード先:バージョン 6.6 以降

すべての Firewall Management Center Virtual 実装には同じ RAM 要件が適用され、32 GB が推奨、28 GB が必須となりました(FMCv 300 の場合は 64 GB)。仮想アプライアンスに割り当てられたメモリが 28 GB 未満の場合、バージョン 6.6 以降へのアップグレードは失敗します。アップグレード後、メモリ割り当てを引き下げると、正常性モニターがアラートを発行します。

これらの新しいメモリ要件は、すべての仮想環境にわたって一貫した要件を適用し、パフォーマンスを向上させ、新しい機能を利用できるようにします。デフォルト設定を引き下げないことをお勧めします。使用可能なリソースによっては、パフォーマンスを向上させるために仮想アプライアンスのメモリと CPU の数を増やすことができます。詳細については、Cisco Secure Firewall Management Center Virtual 入門ガイドを参照してください。


(注)  


バージョン 6.6.0 リリースの時点で、クラウドベースの Firewall Management Center Virtual の展開(AWS、Azure)でのメモリ不足インスタンスのタイプが完全に廃止されました。以前のバージョンであっても、これらを使用して新しいインスタンスを作成することはできません。既存のインスタンスは引き続き実行できます。


次の表に、メモリが不足している展開のアップグレード前の要件を示します。

表 5. バージョン 6.6 以降 にアップグレードする場合の Firewall Management Center Virtual のメモリ要件

プラットフォーム

アップグレード前のアクション

詳細

VMware

28 GB 以上(推奨 32 GB)を割り当てます。

最初に仮想マシンの電源をオフにします。

手順については、VMware のマニュアルを参照してください。

KVM

28 GB 以上(推奨 32 GB)を割り当てます。

手順については、ご使用の KVM 環境のマニュアルを参照してください。

AWS

インスタンスのサイズを変更します。

  • c3.xlarge から c3.4xlarge

  • c3.2.xlarge から c3.4xlarge

  • c4.xlarge から c4.4xlarge

  • c4.2xlarge から c4.4xlarge

また、新規展開用に c5.4xlarge インスタンスも用意しています。

サイズを変更する前にインスタンスを停止します。これを行うと、インスタンスストアのボリューム上のデータが失われるため、最初にインスタンスストアによってバックアップされたインスタンスを最初に移行してください。さらに、管理インターフェイスに復元力のある IP アドレスがない場合は、そのパブリック IP アドレスが解放されます。

手順については、Linux インスタンスの AWS ユーザーガイドのインスタンスタイプの変更に関するマニュアルを参照してください。

Azure

インスタンスのサイズを変更します。

  • Standard_D3_v2 から Standard_D4_v2

Azure ポータルまたは PowerShell を使用します。サイズを変更する前にインスタンスを停止する必要はありませんが、停止すると追加のサイズが表示される場合があります。サイズ変更により、実行中の仮想マシンが再起動されます。

手順については、Windows VM のサイズ変更に関する Azure のマニュアルを参照してください。

Firepower 1000 シリーズ デバイスではアップグレード後に電源の再投入が必要

展開:Firepower 1000 シリーズ デバイス

アップグレード元:バージョン 6.4.0.x

直接アップグレード先:バージョン 6.5.0+

バージョン 6.5.0 では、Firepower 1000/2100 および Firepower 4100/9300 シリーズ デバイス向けの FXOS CLI の「安全に消去する」機能が導入されています。

Firepower 1000 シリーズ デバイスでは、この機能を適切に動作させるには、バージョン 6.5.0+ にアップグレードした後にデバイスの電源を再投入する必要があります。自動リブートでは十分ではありません。サポートされているその他のデバイスでは、電源の再投入は必要ありません。

Firewall Device Manager を使用した Firewall Threat Defense のアップグレード時に削除される履歴データ

展開:Firewall Threat DefenseFirewall Device Manager を使用)

アップグレード元:バージョン 6.2.3 ~ 6.4.0.x

直接アップグレード先:バージョン 6.5.0 以降

データベース スキーマの変更により、すべての履歴レポート データがアップグレード中に削除されます。アップグレード後、履歴データをクエリしたり、履歴データをダッシュボードに表示したりすることはできません。

新しい URL カテゴリとレピュテーション

展開:すべて

アップグレード元:バージョン 6.2.3 ~ 6.4.0.x

直接アップグレード先:バージョン 6.5.0+

Talos インテリジェンスグループ は、URL の分類およびフィルタ処理のために、新しいカテゴリを導入し、レピュテーションの名前を変更しました。カテゴリの変更に関する詳細なリストについては、『Cisco Firepower Release Notes, Version 6.5.0』を参照してください。新しい URL カテゴリの説明については、Talos の「Intelligence Categories」サイトを参照してください。

また、ルール設定オプションは同じままですが、未分類およびレピュテーションのない URL の概念が新しくなっています。

  • 未分類の URL は、疑わしい(Questionable)、ニュートラル(Neutral)、好ましい(Favorable)、信頼されている(Trusted)というレピュテーションのいずれかになります。

    [未分類(Uncategorized)] の URL はフィルタ処理できますが、レピュテーションによりさらに制約を追加することはできません。これらのルールは、レピュテーションに関係なく、すべての未分類 URL と一致します。

    カテゴリのない信頼されていない(Untrusted)ルールのような設定は存在しないことに注意してください。それ以外の場合、信頼されていない(Untrusted)レピュテーションの未分類 URL は、「悪意のあるサイト(Malicious Sites)」という新しい脅威カテゴリに自動的に割り当てられます。

  • レピュテーションのない URL は任意のカテゴリに属することができます。

    レピュテーションのない URL をフィルタ処理することはできません。「レピュテーションなし」に対応するオプションはルールエディタにありません。ただし、レピュテーションに [すべて(Any)] を指定して URL をフィルタ処理することは可能で、その場合はレピュテーションのない URL が含まれます。これらの URL もカテゴリで制約する必要があります。Any/Any ルールに対するユーティリティはありません。

次の表に、アップグレードでの変更点の概要を示します。これらの変更は、ほとんどのお客様にとって最小限の影響で済むように設計されており、アップグレード後の展開を妨げることもありませんが、これらのリリースノートおよび現在の URL フィルタリングの設定を確認することを強くお勧めします。慎重な計画と準備は、誤った手順を回避することに加えて、アップグレード後のトラブルシューティングにかかる時間を短縮するのに役立ちます。

表 6. アップグレード時の展開の変更

変更内容

詳細

URL ルールのカテゴリが変更されます。

アップグレードにより、次のポリシーで、新しいカテゴリセットのほぼ同等のルールが使用されるように URL ルールが変更されます。

  • アクセス コントロール

  • SSL

  • QoS(FMC のみ)

  • 相関(FMC のみ)

これらの変更により、余分なルールや無効になったルールが生じ、パフォーマンスが低下する可能性があります。マージされたカテゴリが設定に含まれている場合、許可またはブロックされる URL が若干変更されることがあります。

URL ルールのレピュテーションの名前が変更されます。

アップグレードにより、新しいレピュテーション名を使用するように URL ルールが変更されます。

  1. 信頼されていない(「高リスク」だった)

  2. 疑わしい(「疑わしいサイト」だった)

  3. ニュートラル(「セキュリティ リスクのある無害なサイト」だった)

  4. 好ましい(「無害なサイト」だった)

  5. 信頼されている(「十分に既知」だった)

URL キャッシュをクリアします。

アップグレードによって URL キャッシュがクリアされます。このキャッシュには、システムが以前にクラウドで検索した結果が含まれています。ローカル データ セットに含まれていない URL については、アクセス時間が一時的に少し長くなることがあります。

「レガシー」イベントにラベルを付けます。

すでにログに記録されているイベントの場合、アップグレードにより、関連する URL のカテゴリおよびレピュテーション情報が「レガシー」としてラベル付けされます。これらのレガシー イベントは時間の経過とともにデータベースからエージ アウトします。

URL カテゴリおよびレピュテーションのアップグレード前のアクション

アップグレードする前に、次のアクションを実行します。

表 7. アップグレード前のアクション

アクション

詳細

アプライアンスが Talos のリソースにアクセスできることを確認します。

アップグレード後、システムは次のシスコのリソースと通信できる必要があります。

  • https://regsvc.sco.cisco.com/ - 登録

  • https://est.sco.cisco.com/ - セキュア通信のための証明書を取得

  • https://updates-talos.sco.cisco.com/ - クライアント/サーバーマニフェストを取得

  • http://updates.ironport.com/ - データベースのダウンロード(注:ポート 80 を使用)

  • https://v3.sds.cisco.com/ ー クラウドクエリ

クラウドクエリサービスは、次の IP アドレスブロックも使用します。

  • IPv4 クラウドクエリ:

    • 146.112.62.0/24

    • 146.112.63.0/24

    • 146.112.255.0/24

    • 146.112.59.0/24

  • IPv6 クラウドクエリ:

    • 2a04:e4c7:ffff::/48

    • 2a04: e4c7: fffe::/48

潜在的なルールの問題を特定します。

今後の変更点を理解します。現在の URL フィルタリング設定を調べて、アップグレード後に実行する必要があるアクションを特定します(次の項を参照)。

(注)  

 

廃止されたカテゴリを使用する URL ルールをこの時点で変更することができます。そうしない場合、それらを使用するルールによってアップグレード後の展開が妨げられます。

FMC 展開では、アクセスコントロールのルールや下位ポリシー(SSL など)のルールを含む、ポリシーの現在の保存されている設定に関する詳細情報を提供する、アクセスコントロール ポリシー レポートを生成することを推奨します。URL ルールごとに、現在のカテゴリ、レピュテーション、関連付けられているルール アクションが表示されます。FMC で[ポリシー(Policies)] > [アクセス制御(Access Control)]を選択し、該当するポリシーの横にあるレポートアイコン()をクリックします。

URL カテゴリおよびレピュテーションのアップグレード後のアクション

アップグレード後に URL フィルタリング設定を再確認し、できるだけ早く次のアクションを実行する必要があります。展開のタイプとアップグレードによって行われた変更に応じて、一部(すべてではない)の問題が GUI でマークされることがあります。たとえば、FMC/FDM のアクセス コントロール ポリシーでは、[警告の表示(Show Warnings)](FMC)または [問題ルールの表示(Show Problem Rules)] (FDM) をクリックできます。

表 8. アップグレード後の操作

アクション

詳細

廃止されたカテゴリをルールから削除します。必須。

アップグレードでは、廃止されたカテゴリを使用する URL ルールは変更されません。これらを使用するルールは展開を阻止します。

FMC では、これらのルールがマークされます。

新しいカテゴリを含めるルールを作成または変更します。

ほとんどの新しいカテゴリは脅威を特定します。これらのカテゴリを使用することを強くお勧めします。

FMC では、この新しいカテゴリはこのアップグレード後にマークされませんが、今後、Talos によってカテゴリが追加される場合があります。この場合は新しいカテゴリがマークされます。

マージされたカテゴリの結果として変更されたルールを評価します。

影響を受けたカテゴリのいずれかが含まれている各ルールに影響を受けたすべてのルールが含まれるようになります。元のカテゴリが異なるレピュテーションに関連付けられていた場合、新しいルールはさらに広い、より包含的なレピュテーションに関連付けられます。以前と同様に URL をフィルタリングするには、いくつかの設定を変更する必要があります。「マージされた URL カテゴリを持つルールのガイドライン」を参照してください。

変更内容とプラットフォームがルールの警告を処理する方法に応じて、変更がマークされることがあります。たとえば、FMC は完全に冗長および完全にプリエンプション処理されたルールをマークしますが、部分的に重複したルールはマークしません。

分割されたカテゴリの結果として変更されたルールを評価します。

アップグレードにより、URL ルール内の古い単一のカテゴリが新しいカテゴリすべてに置き換えられ、新しいカテゴリは古いカテゴリにマッピングされます。これにより URL のフィルタリング方法は変更されませんが、影響を受けるルールを変更して、新しい精度を活用することができます。

これらの変更はマークされません。

名前が変更されたカテゴリまたは変更されていないカテゴリを把握します。

特に対処の必要はありませんが、これらの変更に注意する必要があります。

これらの変更はマークされません。

未分類およびレピュテーションのない URL の処理方法を評価します。

未分類の URL とレピュテーションのない URL を使用できるようになりましたが、未分類の URL をレピュテーションでフィルタ処理することも、レピュテーションのない URL をフィルタ処理することもできません。

[未分類(Uncategorized)] カテゴリまたは [すべて(Any)] のレピュテーションでフィルタ処理されるルールが、期待どおりに動作することを確認してください。

マージされた URL カテゴリを持つルールのガイドライン

アップグレード前に URL フィルタリング設定を確認する場合は、次のシナリオとガイドラインのどちらが適用されるかを決定します。これにより、アップグレード後の設定が予想どおりに実行され、問題を解決するためのクイックアクションを実行できるようになります。

表 9. マージされた URL カテゴリを持つルールのガイドライン

ガイドライン

詳細

ルールの順序によってトラフィックに一致するルールを決定

同じカテゴリを含むルールを検討する場合は、トラフィックが、その条件を含むリスト内の最初のルールと一致することに注意してください。

同じルール内のカテゴリと異なるルール内のカテゴリ

単一のルール内でカテゴリをマージすると、ルール内の単一のカテゴリにマージされます。たとえば、カテゴリ A とカテゴリ B がマージされてカテゴリ AB になり、カテゴリ A とカテゴリ B を持つルールがある場合、マージ後にルールは単一のカテゴリ AB を保持します。

異なるルールのカテゴリをマージすると、マージ後に各ルールで同じカテゴリを持つルールが個別に生成されます。たとえば、カテゴリ A とカテゴリ B がマージされてカテゴリ AB になり、カテゴリ A を持つルール 1 とカテゴリ B を持つルール 2 がある場合、マージ後にルール 1 とルール 2 にはカテゴリ AB がそれぞれ含まれます。この状況を解決する方法は、ルールの順序、ルールに関連付けられたアクションとレピュテーションレベル、ルールに含まれる他の URL カテゴリ、およびルールに含まれる非 URL 条件によって異なります。

関連付けられたアクション

異なるルールのマージされたカテゴリが異なるアクションに関連付けられている場合、マージ後に、同じカテゴリに対して異なるアクションを持つ 2 つ以上のルールが生成される場合があります。

関連付けられているレピュテーションレベル

マージの前に異なるレピュテーションレベルに関連付けられたカテゴリが単一のルールに含まれている場合、マージされたカテゴリは、より包括的なレピュテーションレベルに関連付けられます。たとえば、カテゴリ A が特定のルールで [すべてのレピュテーション(Any reputation)] に関連付けられており、カテゴリ B が同じルールでレピュテーションレベル [3 - セキュリティリスクのある無害なサイト(3 - Benign sites with security risks)] に関連付けられている場合、マージ後に、そのルール内のカテゴリ AB は [すべてのレピュテーション(Any reputation)] に関連付けられます。

重複および冗長カテゴリとルール

マージ後、異なるルールには、異なるアクションとレピュテーションレベルに関連付けられている同じカテゴリが含まれる場合があります。

冗長ルールは完全に重複しているとは限りませんが、ルール順序が前にある別のルールが一致する場合、トラフィックに一致しなくなる可能性があります。たとえば、ルール 1 とカテゴリ A([すべてのレピュテーション(Any Reputation)] に適用される)を事前マージし、ルール 2 とカテゴリ B(レピュテーション 1-3 のみに適用される)を事前マージする場合、マージ後に、ルール 1 とルール 2 の両方にカテゴリ AB が含まれるようになるが、ルール順序でルール 1 の順序が前にあると、ルール 2 が一致することはありません。

FMC において、同一のカテゴリとレピュテーションを持つルールでは警告が表示されます。ただし、これらの警告は、含まれているカテゴリが同じですが、レピュテーションが異なるルールを示すことはありません。

注意:重複または冗長カテゴリを解決する方法を決定する際には、ルールのすべての条件を考慮してください。

ルール内の他の URL カテゴリ

マージされた URL を含むルールには、他の URL カテゴリも含まれている場合があります。したがって、マージ後に特定のカテゴリが複製された場合は、これらのルールを削除するのではなく、変更する必要があることがあります。

ルール内の非 URL 条件

マージされた URL カテゴリを含むルールには、アプリケーション条件などの他のルール条件も含まれている場合があります。したがって、マージ後に特定のカテゴリが複製された場合は、これらのルールを削除するのではなく、変更する必要があることがあります。

次の表の例ではカテゴリ A とカテゴリ B を使用しています。現在はカテゴリ AB にマージされています。2 つのルールの例では、ルール 1 はルール 2 よりも前に表示されます。

表 10. マージされた URL カテゴリを持つルールの例

シナリオ

アップグレード前

アップグレード後

同じルール内のマージされたカテゴリ

ルール 1 にはカテゴリ A とカテゴリ B が含まれる。

ルール 1 にはカテゴリ AB が含まれる。

異なるルール内でマージされたカテゴリ

ルール 1 にはカテゴリ A が含まれる。

ルール 2 にはカテゴリ B が含まれる。

ルール 1 にはカテゴリ AB が含まれる。

ルール 2 にはカテゴリ AB が含まれる。

具体的な結果は、リスト内のルールの順序、レピュテーションレベル、および関連付けられたアクションによって異なります。また、冗長性を解決する方法を決定する際に、ルール内の他のすべての条件も考慮する必要があります。

異なるルール内でマージされたカテゴリには異なるアクションが含まれる

(レピュテーションは同じ)

ルール 1 には [許可(Allow)] に設定されたカテゴリ A が含まれる。

ルール 2 には [ブロック(Block)] に設定されたカテゴリ B が含まれる。

(レピュテーションは同じ)

ルール 1 には [許可(Allow)] に設定されたカテゴリ AB が含まれる。

ルール 2 には [ブロック(Block)] に設定されたカテゴリ AB が含まれる。

ルール 1 は、このカテゴリのすべてのトラフィックに一致します。

ルール 2 がトラフィックに一致することはなく、カテゴリとレピュテーションの両方が同じであるため、マージ後に警告を表示した場合は、警告インジケータが表示されます。

同じルール内でマージされたカテゴリには異なるレピュテーションレベルが含まれる

ルール 1 には次が含まれます。

レピュテーション Any のカテゴリ A

レピュテーション 1-3 のカテゴリ B

ルール 1 にはレピュテーション Any のカテゴリ AB が含まれる。

異なるルール内でマージされたカテゴリには異なるレピュテーションレベルが含まれる

ルール 1 にはレピュテーション Any のカテゴリ A が含まれる。

ルール 2 にはレピュテーション 1-3 のカテゴリ B が含まれる。

ルール 1 にはレピュテーション Any のカテゴリ AB が含まれる。

ルール 2 にはレピュテーション 1-3 のカテゴリ AB が含まれる。

ルール 1 は、このカテゴリのすべてのトラフィックに一致します。

ルール 2 がトラフィックに一致することはありませんが、レピュテーションが同一でないため、警告インジケータは表示されません。

クラウド提供型 Firewall Management Center のアップグレードガイドライン

クラウド提供型 Firewall Management Center はアップグレード対象外です。機能の更新はシスコが行います。クラウド提供型 Firewall Management Center を使用して Firewall Threat Defense をアップグレードするには、クラウド提供型 Firewall Management Center 向け Cisco Secure Firewall Threat Defense アップグレードガイドを参照してください。

Firepower 4100/9300 シャーシのアップグレードガイドライン

Firepower 4100/9300 の場合、Firewall Threat Defense のメジャーアップグレードにはシャーシのアップグレード(FXOS とファームウェア)も必要です。メンテナンスリリースとパッチでアップグレードが必要になることはほとんどありませんが、最新のビルドにアップグレードして、解決済みの問題を活用することもできます。

表 11. Firepower 4100/9300 シャーシのアップグレードガイドライン

ガイドライン

詳細

FXOS のアップグレード。

Firepower 4100/9300 で Threat Defense バージョン 7.0 を実行するには、FXOS 2.10.1.331 以降が必要です。

FXOS 2.2.2 から、それ以降の任意の FXOS バージョンにアップグレードできます。重要なリリース固有のアップグレードガイドライン、新機能および廃止された機能、未解決のバグおよび解決済みのバグについては、Firepower 4100/9300 FXOS リリース ノート を参照してください。

ファームウェアのアップグレード。

FXOS 2.14.1 以降のアップグレードにはファームウェアが含まれます。以前の FXOS バージョンにアップグレードする場合は、Cisco Firepower 4100/9300 FXOS ファームウェア アップグレード ガイドを参照してください。

アップグレードの時間。

シャーシのアップグレードには最長 45 分かかり、トラフィックフローやインスペクションに影響を与える場合があります。詳細については、シャーシのアップグレードでのトラフィックフローとインスペクションを参照してください。

応答しないアップグレード

アップグレード中は、設定の変更の実施または展開を行わないでください。システムが非アクティブに見えても、アップグレード中は手動で再起動またはシャットダウンしないでください。システムが使用できない状態になり、再イメージ化が必要になる場合があります。

応答しない または従来のデバイスのアップグレード

進行中のアップグレードは再開しないでください。アップグレードに失敗する、アプライアンスが応答しないなど、アップグレードで問題が発生した場合にはCisco TACにお問い合わせください。

応答しない Firewall Threat Defense のアップグレード

メジャーアップグレードやメンテナンスアップグレードでは、失敗したアップグレードまたは進行中のアップグレードを手動でキャンセルし、失敗したアップグレードを再試行できます。

  • :[デバイス管理(Device Management)] ページの [アップグレード(Upgrade)] タブ、およびメッセージセンターからアクセスできる [アップグレードステータス(Upgrade Status)] ポップアップを使用します。

  • Firewall Device Manager:[システムアップグレード(System Upgrade)] パネルを使用します。

Firewall Threat Defense CLI を使用することもできます。


(注)  


デフォルトでは、Firewall Threat Defense はアップグレードが失敗すると自動的にアップグレード前の状態に復元されます(「自動キャンセル」)。失敗したアップグレードを手動でキャンセルまたは再試行できるようにするには、アップグレードを開始するときに自動キャンセルオプションを無効にします。パッチの自動キャンセルはサポートされていません。高可用性または拡張性の展開では、自動キャンセルは各デバイスに個別に適用されます。つまり、1 つのデバイスでアップグレードが失敗した場合、そのデバイスだけが元に戻ります。

この機能は、パッチまたはバージョン 6.6 以前からのアップグレードではサポートされていません。


アップグレードを元に戻すまたはアンインストールする

アップグレードに成功したにもかかわらず、システムが期待どおりに機能しない場合は、復元またはアンインストールが可能な場合があります。

  • FDM を使用したメジャーおよびメンテナンスアップグレードの FTD への復元がサポートされています。

    FDM 構成ガイドの「System Management」を参照してください。

  • FMC および ASDM 展開ではほとんどのパッチのアンインストールがサポートされています。

    FMC アップグレードガイドの「Uninstall a Patch」またはこれらのリリースノートの「ASDM による ASA FirePOWER パッチのアンインストール」を参照してください。

これが機能せず、以前のバージョンに戻す必要がある場合、イメージを再作成する必要があります。

アンインストールに対応するパッチ

特定のパッチをアンインストールすると、アンインストールが成功した場合でも、問題が発生する可能性があります。次のような問題があります。

  • アンインストール後に設定変更を展開できない

  • オペレーティングシステムと ソフトウェアの間に互換性がなくなる

  • セキュリティ認定コンプライアンスが有効な状態(CC/UCAPL モード)でそのパッチが適用されていた場合、アプライアンスの再起動時に FSIC(ファイル システム整合性チェック)が失敗する


注意    


セキュリティ認定の遵守が有効な場合に FSIC が失敗すると、ソフトウェアは起動せず、リモート SSH アクセスが無効になるため、ローカルコンソールを介してのみアプライアンスにアクセスできます。この問題が発生した場合は、Cisco TACにお問い合わせください。


アンインストールに対応したバージョン 7.0 のパッチ

この表は、バージョン 7.0 のパッチでサポートされているアンインストールのシナリオを示しています。アンインストールすると、アップグレード前のパッチレベルに戻ります。アンインストールによってサポートされているよりも前に戻る場合は、イメージを再作成してから、目的のパッチレベルにアップグレードすることをお勧めします。

表 12. アンインストールに対応したバージョン 7.0 のパッチ

現在のバージョン

アンインストールすべき最も古いバージョン

FTD/FTDv

ASA FirePOWER

NGIPSv

FMC/FMCv

7.0.6.2 以降

7.0.6

7.0.6.1

7.0.6.1

7.0.6.1

7.0.6

アンインストールに対応したバージョン 6.7 のパッチ

現在、すべてのバージョン 6.7 パッチがアンインストールに対応しています。

アンインストールに対応したバージョン 6.6 のパッチ

現在、すべてのバージョン 6.6 パッチがアンインストールに対応しています。

アンインストールに対応したバージョン 6.5 のパッチ

この表は、バージョン 6.5 のパッチでサポートされているアンインストールのシナリオを示しています。アンインストールすると、アップグレード前のパッチレベルに戻ります。アンインストールによってサポートされているよりも前に戻る場合は、イメージを再作成してから、目的のパッチレベルにアップグレードすることをお勧めします。

表 13. アンインストールに対応したバージョン 6.5.0 のパッチ

現在のバージョン

アンインストールすべき最も古いバージョン

FTD/FTDv

ASA FirePOWER

NGIPSv

FMC/FMCv

6.5.0.2 以降

6.5.0

6.5.0

6.5.0.1

6.5.0.1

6.5.0

6.5.0

アンインストールに対応したバージョン 6.4 のパッチ

この表は、バージョン 6.4 のパッチでサポートされているアンインストールのシナリオを示しています。アンインストールすると、アップグレード前のパッチレベルに戻ります。アンインストールによってサポートされているよりも前に戻る場合は、イメージを再作成してから、目的のパッチレベルにアップグレードすることをお勧めします。

表 14. アンインストールに対応したバージョン 6.4.0 のパッチ

現在のバージョン

アンインストールすべき最も古いバージョン

FTD/FTDv

Firepower 7000/8000

ASA FirePOWER

NGIPSv

FMC/FMCv

6.4.0.5 以降

6.4.0.4

6.4.0.4

6.4.0.4

6.4.0.4

6.4.0.3

6.4.0

6.4.0.2

6.4.0

6.4.0.1

6.4.0

6.4.0

6.4.0

ASDM による ASA FirePOWER パッチのアンインストール

Linux シェル(エキスパートモード)を使用してデバイスパッチをアンインストールします。デバイスの admin ユーザーとして、または CLI 設定アクセス権を持つ別のローカル ユーザーとして、デバイス シェルにアクセスできる必要があります。シェルアクセスを無効にした場合は、 ロックダウンを元に戻すために Cisco TAC にご連絡ください。

ASA フェールオーバーペアおよびクラスタの場合、一度に 1 つのアプライアンスからアンインストールすることにより、中断を最小限に抑えます。次に移る前に、パッチが 1 つのユニットから完全にアンインストールされるまで待ちます。

表 15. ASA フェールオーバーペア/クラスタ内の ASA with FirePOWER Services のアンインストール順序

設定

アンインストール順序

ASA FirePOWER が有効な ASA アクティブ/スタンバイ フェールオーバー ペア

常にスタンバイからアンインストールします。

  1. スタンバイ ASA デバイスの ASA FirePOWER モジュールからアンインストールします。

  2. フェールオーバーします。

  3. 新しいスタンバイ ASA デバイスの ASA FirePOWER モジュールからアンインストールします。

ASA FirePOWER が有効な ASA アクティブ/アクティブ フェールオーバー ペア

アンインストールしないユニットの両方のフェールオーバー グループをアクティブにします。

  1. プライマリ ASA デバイスの両方のフェールオーバー グループをアクティブにします。

  2. セカンダリ ASA デバイスの ASA FirePOWER モジュールからアンインストールします。

  3. セカンダリ ASA デバイスの両方のフェールオーバー グループをアクティブにします。

  4. プライマリ ASA デバイスの ASA FirePOWER モジュールからアンインストールします。

ASA FirePOWER が有効な ASA クラスタ

アンインストールの前に、各ユニットでクラスタリングを無効にします。一度に 1 つのユニットからアンインストールし、制御ユニットを最後に残します。

  1. データユニットでクラスタリングを無効にします。

  2. そのユニットの ASA FirePOWER モジュールからアンインストールします。

  3. クラスタリングを再び有効にします。ユニットが再びクラスタに参加するのを待ちます。

  4. 各データユニットに対して手順を繰り返します。

  5. 制御ユニットでクラスタリングを無効にします。新しい制御ユニットが引き継ぐまで待ちます。

  6. 以前の制御ユニットの ASA FirePOWER モジュールからアンインストールします。

  7. クラスタリングを再び有効にします。


注意    


アンインストール中に設定の変更を行ったり、展開したりしないでください。システムが非アクティブに見えても、進行中のアンインストールを手動で再起動、シャットダウン、または再起動しないでください。システムが使用できない状態になり、再イメージ化が必要になる場合があります。アンインストールに失敗した、アプライアンスが応答しないなど、アンインストールで問題が発生した場合は、Cisco TAC にお問い合わせください。


始める前に

  • ASA のフェールオーバーやクラスタの展開では、正しいデバイスからアンインストールしようとしていることを確認してください。

  • 正常に展開され、通信が確立されていることを確認します。

手順


ステップ 1

デバイスの設定が古い場合は、この時点で ASDM から展開します。

アンインストールする前に展開すると、失敗する可能性が減少します。展開とその他の必須のタスクが完了していることを確認してください。アンインストールの開始時に実行中だったタスクは停止され、失敗したタスクとなって再開できなくなります。後で失敗ステータス メッセージを手動で削除できます。

ステップ 2

ASA FirePOWER モジュールの Firepower CLI にアクセスします。admin として、または設定アクセス権を持つ別の Firepower CLI ユーザーとしてログインします。

モジュールの管理インターフェイスに SSH 接続するか(ホスト名または IP アドレス)、コンソールを使用できます。コンソールポートはデフォルトで ASA CLI に設定されており、Firepower CLI にアクセスするには session sfr コマンドを使用する必要があることにご注意ください。

ステップ 3

expert コマンドを使用して Linux シェルにアクセスします。

ステップ 4

アップグレードディレクトリにアンインストールパッケージがあることを確認します。

ls /var/sf/updates

パッチのアンインストーラには、アップグレードパッケージと同様に名前が付けられていますが、ファイル名には Patch ではなく Patch_Uninstaller が含まれています。デバイスにパッチを適用すると、そのパッチ用のアンインストーラがアップグレードディレクトリに自動的に作成されます。アンインストーラがない場合は、Cisco TAC までお問い合わせください。

ステップ 5

uninstall コマンドを実行し、プロンプトが表示されたらパスワードを入力します。

sudo install_update.pl --detach /var/sf/updates/uninstaller_name

注意    

 

確認を求められることはありません。このコマンドを入力すると、デバイスの再起動を含むアンインストールが開始されます。アンインストール時のトラフィック フローとインスペクションの中断は、アップグレード時に発生する中断と同じです。準備が整っていることを確認してください。--detach オプションを使用すると、SSH セッションがタイムアウトした場合にアンインストールプロセスが強制終了されなくなり、デバイスが不安定な状態になる可能性があることに注意してください。

ステップ 6

ログアウトするまでアンインストールを監視します。

個別のアンインストールの場合は、tailtailf を使用してログを表示します。

tail /ngfw/var/log/sf/update.status

それ以外の場合は、コンソールか端末で進行状況を監視します。

ステップ 7

アンインストールが成功したことを確認します。

アンインストールが完了したら、モジュールのソフトウェアバージョンが正しいことを確認します。[設定(Configuration)] > [ASA FirePOWERの設定(ASA FirePOWER Configuration)] > [デバイス管理(Device Management)] > [デバイス(Device)] の順に選択します。

ステップ 8

構成を再展開します。


次のタスク

ASA のフェールオーバーやクラスタの展開では、各ユニットに対して計画した順序でこの手順を繰り返します。

トラフィック フローとインスペクション

デバイスのアップグレード(ソフトウェアおよびオペレーティングシステム)により、トラフィックフローとインスペクションが影響を受けます。影響が最も少ない時間帯にメンテナンス期間をスケジュールします。

シャーシのアップグレードでのトラフィックフローとインスペクション

FXOS をアップグレードするとシャーシが再起動します。ファームウェアのアップグレードを含むバージョン 2.14.1 以降への FXOS アップグレードの場合、デバイスは 2 回リブートします。1 回は FXOS 用、1 回はファームウェア用です。

高可用性またはクラスタ展開の場合でも、各シャーシの FXOS を個別にアップグレードします。中断を最小限に抑えるには、1 つずつシャーシをアップグレードします。

表 16. トラフィックフローとインスペクション:FXOS のアップグレード

Firewall Threat Defense の導入

トラフィックの挙動

メソッド

スタンドアロン

廃棄。

高可用性

影響なし。

ベストプラクティス:スタンバイで FXOS を更新し、アクティブピアを切り替えて新しいスタンバイをアップグレードします。

1 つのピアがオンラインになるまでドロップされる。

スタンバイでアップグレードが終了する前に、アクティブ ピアで FXOS をアップグレードします。

シャーシ間クラスタ

影響なし。

ベストプラクティス:少なくとも 1 つのモジュールを常にオンラインにするため、一度に 1 つのシャーシをアップグレードします。

少なくとも 1 つのモジュールがオンラインになるまでドロップされる。

ある時点ですべてのモジュールを停止するため、シャーシを同時にアップグレードします。

シャーシ内クラスタ(FirePOWER 9300 のみ)

検査なしで受け渡される。

ハードウェアバイパス有効:[Bypass: Standby] または [Bypass‑Force]。

少なくとも 1 つのモジュールがオンラインになるまでドロップされる。

ハードウェアバイパス無効:[Bypass: Disabled]。

少なくとも 1 つのモジュールがオンラインになるまでドロップされる。

ハードウェア バイパス モジュールなし。

を使用した Firewall Threat Defense アップグレードのトラフィックフローとインスペクション

スタンドアロンデバイスでのソフトウェアのアップグレード

アップグレード中、デバイスはメンテナンス モードで稼働します。アップグレードの開始時にメンテナンスモードを開始すると、トラフィック インスペクションが 2 〜 3 秒中断します。インターフェイスの構成により、その時点とアップグレード中の両方のスタンドアロンデバイスによるトラフィックの処理方法が決定されます。

表 17. トラフィックフローとインスペクション:スタンドアロンデバイスでのソフトウェアのアップグレード

インターフェイス コンフィギュレーション

トラフィックの挙動

ファイアウォール インターフェイス

EtherChannel、冗長、サブインターフェイスを含むルーテッドまたはスイッチド。

スイッチドインターフェイスは、ブリッジグループまたはトランスペアレント インターフェイスとしても知られています。

廃棄。

ISA 3000 のブリッジ グループ インターフェイスの場合に限り、FlexConfig ポリシーを使用して、停電時のハードウェアバイパスを設定できます。これにより、ソフトウェアのアップグレード中にトラフィックのドロップが発生しますが、デバイスがアップグレード後の再起動中、インスペクションなしでトラフィックが通過します。

IPS のみのインターフェイス

インラインセット、ハードウェアバイパス強制が有効:[バイパス(Bypass)]:[強制(Force)]

ハードウェアバイパスを無効にするか、スタンバイモードに戻すまで、インスペクションなしで合格。

インラインセット、ハードウェアバイパスがスタンバイモード:[バイパス(Bypass)]:[スタンバイ(Standby)]

デバイスがメンテナンスモードの場合、アップグレード中にドロップされます。その後、デバイスがアップグレード後の再起動を完了する間、インスペクションなしで合格します。

インラインセット、ハードウェアバイパスが無効:[バイパス(Bypass)]:[無効(Disabled)]

廃棄。

インラインセット、ハードウェア バイパス モジュールなし。

廃棄。

インラインセット、タップモード。

パケットをただちに出力、コピーへのインスペクションなし。

パッシブ、ERSPAN パッシブ。

中断なし、インスペクションなし。

高可用性および拡張性に関するソフトウェアのアップグレード

高可用性デバイスやクラスタ化されたデバイスのアップグレード中に、トラフィックフローや検査が中断されることはありません。高可用性ペアの場合、スタンバイデバイスが最初にアップグレードされます。デバイスの役割が切り替わり、新しくスタンバイになったデバイスがアップグレードされます。

クラスタの場合、データ セキュリティ モジュールを最初にアップグレードして、その後コントロールモジュールをアップグレードします。コントロール セキュリティ モジュールをアップグレードする間、通常トラフィック インスペクションと処理は続行しますが、システムはロギングイベントを停止します。ロギングダウンタイム中に処理されるトラフィックのイベントは、アップグレードが完了した後、非同期のタイムスタンプ付きで表示されます。ただし、ロギングダウンタイムが大きい場合、システムはログ記録する前に最も古いイベントをプルーニングすることがあります。

ソフトウェアのアンインストール(パッチ)

スタンドアロンデバイスの場合、パッチのアンインストール中のトラフィックフローと検査の中断は、アップグレードの場合と同じになります。高可用性および拡張性の展開では、中断を最小限に抑えるために、アンインストールの順序を明確に計画する必要があります。これは、ユニットとしてアップグレードしたデバイスであっても、デバイスから個別にパッチをアンインストールするためです。

設定変更の導入

Snort プロセスを再起動すると、高可用性/拡張性を備えた構成になっているものを含め、すべてのデバイスでトラフィックフローとインスペクションが一時的に中断されます。インターフェイス設定により、中断中にインスペクションせずにトラフィックをドロップするか受け渡すかが決定されます。Snort を再起動せずに展開すると、リソース要求時にいくつかのパケットが検査なしでドロップされることがあります。

Snort は、通常、アップグレード直後の最初の展開時に再起動されます。展開の前に、特定のポリシーまたはデバイス設定を変更しない限り、それ以外の展開時に再起動されることはありません。

表 18. トラフィックフローとインスペクション:設定変更の展開

インターフェイス コンフィギュレーション

トラフィックの挙動

ファイアウォール インターフェイス

EtherChannel、冗長、サブインターフェイスを含むルーテッドまたはスイッチド。

スイッチドインターフェイスは、ブリッジグループまたはトランスペアレント インターフェイスとしても知られています。

廃棄。

IPS のみのインターフェイス

インラインセット、[フェールセーフ(Failsafe)] が有効または無効。

検査なしで受け渡される。

[フェールセーフ(Failsafe)] が無効で、Snort がビジーでもダウンしていない場合、いくつかのパケットがドロップすることがあります。

インラインセット、[Snortフェール オープン:ダウン(Snort Fail Open: Down)]:無効

廃棄。

インライン、[Snortフェールオープン:ダウン(Snort Fail Open: Down)]:有効

検査なしで受け渡される。

インラインセット、タップモード。

パケットをただちに出力、コピーへのインスペクションなし。

パッシブ、ERSPAN パッシブ。

中断なし、インスペクションなし。

Firewall Device Manager を使用した Firewall Threat Defense アップグレードのトラフィックフローとインスペクション

ソフトウェアのアップグレード

アップグレード中にトラフィックがドロップされます。高可用性の展開では、デバイスを 1 つずつアップグレードすることで、中断を最小限に抑えることができます。

ISA 3000 の場合にのみ、電源障害に対するハードウェアバイパスを設定すると、トラフィックはアップグレード中にドロップされますが、デバイスのアップグレード後の再起動中に検査なしでトラフィックが渡されます。

ソフトウェアの復元(メジャーおよびメンテナンスリリース)

復元中にトラフィックがドロップされます。高可用性の展開では、両方のユニットを同時に復元すると、復元が成功する可能性が高くなります。最初のユニットがオンラインに戻ると、トラフィックフローとインスペクションが再開されます。

設定変更の導入

Snort プロセスを再起動すると、高可用性を備えた構成になっているものを含め、すべてのデバイスでトラフィックフローとインスペクションが一時的に中断されます。Snort を再起動せずに展開すると、リソース要求時にいくつかのパケットが検査なしでドロップされることがあります。

Snort は、通常、アップグレード直後の最初の展開時に再起動されます。展開の前に、特定のポリシーまたはデバイス設定を変更しない限り、それ以外の展開時に再起動されることはありません。

ASA FirePOWER のアップグレードでのトラフィックフローとインスペクション

ソフトウェアのアップグレード

ASA FirePOWER モジュールへのトラフィックリダイレクトに関する ASA サービスポリシーによって、モジュールがソフトウェアアップグレード中にトラフィックを処理する方法が決定されます。

表 19. トラフィックフローとインスペクション:ASA FirePOWER のアップグレード

トラフィック リダイレクト ポリシー

トラフィックの挙動

フェール オープン(sfr fail-open

インスペクションなしで転送

フェール クローズ(sfr fail-close

ドロップされる

モニターのみ(sfr {fail-close}|{fail-open} monitor-only

パケットをただちに出力、コピーへのインスペクションなし

ソフトウェアのアンインストール(パッチ)

パッチのアンインストール中のトラフィックフローと検査の中断は、アップグレードの場合と同じになります。ASA フェールオーバーおよびクラスタの展開では、中断を最小限に抑えるために、アンインストールの順序を明確に計画する必要があります。これは、ユニットとしてアップグレードしたデバイスであっても、デバイスから個別にパッチをアンインストールするためです。

設定変更の導入

Snort プロセスを再開すると、一時的にトラフィックフローと検査が中断されます。Snort プロセスが再起動している間のトラフィックの挙動は、ASA FirePOWER をアップグレードする場合と同じです。Snort を再起動せずに展開すると、リソース要求時にいくつかのパケットが検査なしでドロップされることがあります。

Snort は、通常、アップグレード直後の最初の展開時に再起動されます。展開の前に、特定のポリシーまたはデバイス設定を変更しない限り、それ以外の展開時に再起動されることはありません。

FMC を使用した NGIPSv のアップグレードでのトラフィックフローとインスペクション

ソフトウェアのアップグレード

インターフェイスの設定により、アップグレード中に NGIPSv がトラフィックを処理する方法が決定されます。

表 20. トラフィックフローとインスペクション:NGIPSv のアップグレード

インターフェイス コンフィギュレーション

トラフィックの挙動

インライン

廃棄。

インライン、タップ モード

パケットをただちに出力、コピーへのインスペクションなし。

パッシブ

中断なし、インスペクションなし。

ソフトウェアのアンインストール(パッチ)

パッチのアンインストール中のトラフィックフローと検査の中断は、アップグレードの場合と同じになります。

設定変更の導入

Snort プロセスを再開すると、一時的にトラフィックフローと検査が中断されます。インターフェイス設定により、中断中にインスペクションせずにトラフィックをドロップするか受け渡すかが決定されます。Snort を再起動せずに展開すると、リソース要求時にいくつかのパケットが検査なしでドロップされることがあります。

Snort は、通常、アップグレード直後の最初の展開時に再起動されます。展開の前に、特定のポリシーまたはデバイス設定を変更しない限り、それ以外の展開時に再起動されることはありません。

表 21. トラフィックフローとインスペクション:設定変更の展開

インターフェイス コンフィギュレーション

トラフィックの挙動

インライン、[フェールセーフ(Failsafe)] が有効または無効

検査なしで受け渡される。

[フェールセーフ(Failsafe)] が無効で、Snort がビジーでもダウンしていない場合、いくつかのパケットがドロップすることがあります。

インライン、タップ モード

すぐにパケットを出力し、バイパス Snort をコピーする

パッシブ

中断なし、インスペクションなし。

設定展開時のトラフィックフローとインスペクション

Snort は、通常、アップグレード直後の最初の展開時に再起動されます。つまり、 のアップグレードの場合、すべての管理対象デバイスで Snort が再起動する可能性があります。後続の展開後は、展開の前に特定のポリシーまたはデバイス設定を変更しない限り、Snort は再起動しません。

Snort プロセスを再起動すると、高可用性/拡張性を備えた構成になっているものを含め、すべてのデバイスでトラフィックフローとインスペクションが一時的に中断されます。インターフェイス設定により、中断中にインスペクションせずにトラフィックをドロップするか受け渡すかが決定されます。Snort を再起動せずに展開すると、リソース要求時にいくつかのパケットが検査なしでドロップされることがあります。

表 22. トラフィックフローとインスペクション:設定変更の展開

インターフェイス コンフィギュレーション

トラフィックの挙動

ファイアウォール インターフェイス

EtherChannel、冗長、サブインターフェイスを含むルーテッドまたはスイッチド。

スイッチドインターフェイスは、ブリッジグループまたはトランスペアレント インターフェイスとしても知られています。

廃棄。

IPS のみのインターフェイス

インラインセット、[フェールセーフ(Failsafe)] が有効または無効。

検査なしで受け渡される。

[フェールセーフ(Failsafe)] が無効で、Snort がビジーでもダウンしていない場合、いくつかのパケットがドロップすることがあります。

インラインセット、[Snortフェール オープン:ダウン(Snort Fail Open: Down)]:無効

廃棄。

インライン、[Snortフェールオープン:ダウン(Snort Fail Open: Down)]:有効

検査なしで受け渡される。

インラインセット、タップモード。

パケットをただちに出力、コピーへのインスペクションなし。

パッシブ、ERSPAN パッシブ。

中断なし、インスペクションなし。

Snort プロセスを再起動すると、高可用性を備えた構成になっているものを含め、すべてのデバイスでトラフィックフローとインスペクションが一時的に中断されます。Snort を再起動せずに展開すると、リソース要求時にいくつかのパケットが検査なしでドロップされることがあります。

Snort は、通常、アップグレード直後の最初の展開時に再起動されます。展開の前に、特定のポリシーまたはデバイス設定を変更しない限り、それ以外の展開時に再起動されることはありません。

時間とディスク容量

アップグレードまでの時間

将来のベンチマークとして使用できるように、独自のアップグレード時間を追跡および記録することをお勧めします。次の表に、アップグレード時間に影響を与える可能性のあるいくつかの事項を示します。


注意    


アップグレード中は、設定を変更または展開しないでください。システムが非アクティブに見えても、手動で再起動またはシャットダウンしないでください。ほとんどの場合、進行中のアップグレードを再開しないでください。システムが使用できない状態になり、再イメージ化が必要になる場合があります。アップグレードに失敗する、アプライアンスが応答しないなど、アップグレードで問題が発生した場合には、アップグレードガイド(https://www.cisco.com/go/ftd-upgrade)でトラブルシューティング情報を見つけることができます。問題が解消されない場合は、Cisco TAC にお問い合わせください。


表 23. アップグレード時間の考慮事項

考慮事項

詳細

バージョン

アップグレードでバージョンがスキップされると、通常、アップグレード時間は長くなります。

モデル

通常、ローエンドモデルではアップグレード時間が長くなります。

仮想アプライアンス

仮想展開でのアップグレード時間はハードウェアに大きく依存します。

高可用性とクラスタリング

高可用性の構成またはクラスタ化された構成では、動作の継続性を保持するため、複数のデバイスは 1 つずつアップグレードされます。アップグレード中は、各デバイスはメンテナンスモードで動作します。そのため、デバイスペアまたはクラスタ全体のアップグレードには、スタンドアロンデバイスのアップグレードよりも長い時間がかかります。

設定

アップグレード時間は、構成の複雑さ、イベントデータベースのサイズ、それらがアップグレードから影響を受けるかどうか、どのような影響を受けるかによって長くなります。たとえば、多くのアクセス制御ルールを使用している場合、アップグレードではそれらのルールの格納方法をバックエンドで変更する必要があるため、さらに長い時間がかかります。

コンポーネント

オペレーティングシステムまたは仮想ホスティングのアップグレード、アップグレードパッケージの転送、準備状況チェック、VDB と侵入ルール(SRU/LSP)の更新、設定の展開、およびその他の関連タスクを実行するために、追加の時間が必要になる場合があります。

アップグレードするディスク容量

アップグレードするには、アップグレードパッケージがアプライアンスにある必要があります。デバイスアップグレードの場合は、(/Volume または /var のいずれか)にもデバイス アップグレード パッケージ用の十分な容量が必要です。または、内部サーバーを使用して保存することもできます。準備状況チェックでは、アップグレードを実行するのに十分なディスク容量があるかどうかが示されます。空きディスク容量が十分でない場合、アップグレードは失敗します。

表 24. ディスク容量の確認

プラットフォーム

コマンド

[システム(System)]システム歯車アイコン > [モニタリング(Monitoring)] > [統計(Statistics)] を選択し、 を選択します。

[ディスク使用率(Disk Usage)] で、[By Partition] の詳細を展開します。

Firewall Threat Defense with

[システム(System)]システム歯車アイコン > [モニタリング(Monitoring)] > [統計(Statistics)] を選択し、確認するデバイスを選択します。

[ディスク使用率(Disk Usage)] で、[By Partition] の詳細を展開します。

Firewall Threat Defense with Firewall Device Manager

show disk CLI コマンドを使用します。