ポリシー管理

ここでは、Firepower Management Center でさまざまなポリシーを管理する方法について説明します。

ポリシー管理の要件と前提条件

モデルのサポート

任意

サポートされるドメイン

任意

ユーザの役割

  • 管理者

  • ネットワーク管理者

  • セキュリティ承認者

ポリシーの導入


注意    

FTD で直接終端する VPN トンネル経由で FMC 展開をプッシュしないでください。FMC 展開をプッシュすると、トンネルが非アクティブ化され、FMCFTD が切断される可能性があります。

この状況からデバイスを回復すると、中断時間が長くなり、ディザスタリカバリ手順の実行が必要になる場合があります。この手順では、マネージャを FMC からローカルに変更し、デバイスを最初から設定することで、FTD を工場出荷時のデフォルト設定にリセットします。詳細については、VPN トンネルを介した FMC ポリシー構成の展開を参照してください。


導入を設定した後、およびその設定を変更したときは、影響を受けるデバイスにその変更を導入する必要があります。導入のステータスは、メッセージ センターで確認できます。

導入を行うと、以下のコンポーネントが更新されます。

  • デバイスとインターフェイスの設定

  • デバイス関連ポリシー:NAT、VPN、QoS、プラットフォーム設定

  • アクセス コントロールおよび関連するポリシー:DNS、ファイル、アイデンティティ、侵入、ネットワーク分析、プレフィルタ、SSL

  • ネットワーク検出ポリシー

  • 侵入ルールの更新

  • これらの要素のいずれかに関連付けられている設定とオブジェクト

システムにポリシーを自動的に導入させるには、導入タスクをスケジュールするか、あるいは侵入ルールの更新をインポートする際に導入するようにシステムを設定します。特に、侵入ポリシーの更新によって侵入およびネットワーク分析に関するシステム定義の基本ポリシーを変更できるようにしている場合は、ポリシーの導入を自動化すると役立ちます。侵入ルール更新によって、アクセス コントロール ポリシーの前処理およびパフォーマンスの詳細設定オプションのデフォルト値が変更されることもあります。

マルチドメイン展開では、ユーザ アカウントが属するいずれのドメインにも変更を導入できます。

  • 導入先を先祖ドメインに切り替えると、変更がすべてのサブドメインに同時に導入されます。

  • 導入先をリーフ ドメインに切り替えると、変更はそのドメインだけに導入されます。

設定変更を展開するためのベストプラクティス

次に、設定変更の展開に関するガイドラインを示します。

VPN トンネルを介した FMC ポリシー構成の展開

VPN トンネルを介した FMC ポリシー構成の展開は、展開がそのトンネルを終端しないデバイス向けである場合にのみ実行できます。FMC から FTD への管理トラフィックは独自のセキュアなトランスポート SF トンネルを通り、接続のために S2S VPN トンネルを経由する必要はありません。

ポリシーベースの VPN トンネルの場合は、両側で保護されたネットワークを選択して、FMC から FTDへの管理トラフィックを除外します。ルートベースの VPN トンネルの場合、VTI インターフェイスに対する FMC から FTD への管理トラフィックを除外するようにルーティングを設定します。

管理トラフィックもトンネルを通過するように VPN トンネルを介して FMC 展開をプッシュする場合、VPN の構成に誤りがあると、トンネルが非アクティブになり、FMCFTD が切断されます。

トンネル構成を再インスタンス化するには、次のいずれかを実行します。

  • FTD および FMC からセンサーを削除し(その結果、すべての構成が失われます)、センサーを FMC に再度追加します。

    または

  • Cisco TAC に連絡してください。


    (注)  

    トンネル構成を再インスタンス化するには、システムのオーバーホールが必要です。


インライン展開とパッシブ展開の比較

インライン設定をパッシブに展開されたデバイスに適用しないでください。またその逆も同様です。

展開時間とメモリの制限

展開に要する時間は、次のような複数の要因によって異なります(ただし、これに限られません)。

  • デバイスに送信する設定。たとえば、ブロックするセキュリティ インテリジェンス エントリの数を大幅に増やすと、展開にかかる時間が長くなることがあります。

  • デバイスのモデルとメモリ。低メモリ デバイスでは、展開にかかる時間が長くなることがあります。

デバイスの機能を超えないように注意してください。ターゲットデバイスでサポートされるルールまたはポリシーの最大数を超えると、システムが警告を表示します。最大数は多くの要因に依存し、メモリとデバイス上のプロセッサ数だけでなく、ポリシーとルールの複雑さにも依存します。ポリシーとルールの最適化の詳細については、アクセス制御ルールのベストプラクティスを参照してください。

展開中のトラフィックフローとインスペクションの中断

展開する際にリソースを要求すると、いくつかのパケットがインスペクションなしでドロップされることがあります。また、一部のコンフィギュレーションを展開すると、トラフィックのインスペクションを中断する Snort プロセスが再開します。この中断中にトラフィックがドロップされるか、それ以上インスペクションが行われずに受け渡されるかは、ターゲット デバイスがトラフィックを処理する方法に応じて異なります。Snort® の再起動によるトラフィックの動作および展開またはアクティブ化された際に Snort プロセスを再起動する設定を参照してください。

FTD デバイスの場合、[Deploy] ダイアログの [Inspect Interruption] 列に、展開するとトラフィックフローまたは検査が中断する可能性があることについての警告が表示されます。展開を続行、キャンセル、または延期できます。詳細については、FTD デバイスの再起動の警告を参照してください。


注意    

メンテナンスウィンドウまたは中断の影響が最小限になる時間に展開することを強くお勧めします。

アプリケーションディテクタの自動有効化

アプリケーション制御の実行時に必要なディテクタが無効になっている場合、システムは、ポリシーの展開時にシステムによって提供される適切なディテクタを自動的に有効にします。存在しない場合、システムはそのアプリケーション対応で最近変更されたユーザ定義のディテクタを有効にします。

ネットワーク検出ポリシーの変更によるアセットの再検出

ネットワーク検出ポリシーに変更を展開する場合、システムは、監視対象ネットワーク内のホストのネットワーク マップから MAC アドレス、TTL、およびホップ情報を削除してから、再検出を行います。また、影響を受ける管理対象デバイスは、まだ FMC に送信されていない検出データを破棄します。

FTD デバイスの再起動の警告

展開時、展開ダイアログの [Inspect Interruption] 列に、構成を展開したときに FTD デバイスで Snort プロセスが再起動するかどうかが表示されます。Snort プロセスと呼ばれるトラフィック インスペクション エンジンが再起動すると、プロセスが再開されるまでインスペクションが中断されます。トラフィックが中断されるか中断中にインスペクションなしで受け渡されるかどうかは、デバイスがトラフィックを処理する方法によって変わります。展開の続行、展開のキャンセル、および設定の変更を実行できます。または、展開によるネットワークへの影響が最小となる時間まで展開を遅らせることができます。

[インスペクションの中断(Inspect Interruption)] 列に [あり(Yes)] と表示されているときにデバイス設定リストを展開すると、Snort プロセスを再起動する特定の設定タイプは、[再起動(Restart)] アイコンと共に赤色で強調表示されます。これらの設定にマウス ポインタを合わせると、設定を展開したときにトラフィックが中断される可能性があるというメッセージが表示されます。

次の表に、展開ダイアログでインスペクション中断の警告が表示される方法を示します。

表 1. インスペクション中断のインジケータ

タイプ

インスペクションの中断

説明

FTD

インスペクションの中断([インスペクションの中断(inspect interruption)] アイコン [インスペクションの中断(inspect interruption)] アイコン)はい(Yes)

少なくとも 1 つの設定は、展開するとデバイスでインスペクションが中断します。また、デバイスがトラフィックを処理する方法によって、トラフィックが中断されることがあります。デバイス設定リストを展開して、詳細を確認できます。

非対応

展開されている設定は、デバイスのトラフィックを中断しません。

不明

展開された設定がデバイス上のトラフィックを中断する可能性があるかどうかをシステムは判断できず、デバイスの横にデバイス警告アイコンが表示されます。

最初の展開の前の、ソフトウェア アップグレードの後に、または場合によってはサポート コール中に、不明ステータスが表示されます。

エラー([エラー(error)] アイコン [エラー(error)] アイコン)

内部エラーにより、システムはステータスを特定できません。

操作をキャンセルして再度 [展開(Deploy)] をクリックすると、システムは [インスペクションの中断(Inspect Interruption)] ステータスを特定しなおすことができます。問題が解決しない場合は、サポートにご連絡ください。

センサー

--

センサーとして識別されるデバイスは FTD デバイスではありません。システムは、構成を展開するとこのデバイスのトラフィックが中断されるかどうかを特定しません。

すべてのデバイスタイプの Snort プロセスを再起動する全設定の詳細については、展開またはアクティブ化された際に Snort プロセスを再起動する設定 を参照してください。

設定変更の展開


注意    

FTD で直接終端する VPN トンネル経由で FMC 展開をプッシュしないでください。FMC 展開をプッシュすると、トンネルが非アクティブ化され、FMCFTD が切断される可能性があります。

この状況からデバイスを回復すると、中断時間が長くなり、ディザスタリカバリ手順の実行が必要になる場合があります。この手順では、マネージャを FMC からローカルに変更し、デバイスを最初から設定することで、FTD を工場出荷時のデフォルト設定にリセットします。詳細については、VPN トンネルを介した FMC ポリシー構成の展開を参照してください。


設定を変更した後に、影響を受けるデバイスに展開します。メンテナンスの時間帯か、またはトラフィックフローとインスペクションに対する中断の影響が最小限になる時間に展開することを強くお勧めします。


注意    

展開する際にリソースを要求すると、いくつかのパケットがインスペクションなしでドロップされることがあります。また、一部のコンフィギュレーションを展開すると、トラフィックのインスペクションを中断する Snort プロセスが再開します。この中断中にトラフィックがドロップされるか、それ以上インスペクションが行われずに受け渡されるかは、ターゲット デバイスがトラフィックを処理する方法に応じて異なります。Snort® の再起動によるトラフィックの動作および展開またはアクティブ化された際に Snort プロセスを再起動する設定を参照してください。

始める前に

  • 設定変更を展開するためのベストプラクティスで説明されているガイドラインを確認してください。

  • すべての管理対象デバイスが同じバージョンのセキュリティ ゾーン オブジェクトを使用していることを確認してください。セキュリティ ゾーン オブジェクトを編集している場合:同期させるすべてのデバイスでインターフェイスのゾーン設定を編集するまでは、デバイスに設定変更を展開しないでください。すべての管理対象デバイスに同時に展開する必要があります。セキュリティ ゾーン オブジェクトのリビジョンの同期を参照してください。)


(注)  

展開時にセンサー設定がシステムによって読み取られている場合、ポリシー展開プロセスは失敗します。センサー CLI から show running-config などのコマンドを実行すると、展開が中断され、展開エラーが発生します。

手順


ステップ 1

FMC メニュー バーで、[展開(Deploy)] をクリックします。

[ポリシーの展開(Deploy Policies)] ダイアログに、設定の期限が切れているデバイスがリストされます。ダイアログの上部の [バージョン(Version)] は、最後に設定変更を行った時期を示します。

ステップ 2

設定変更を展開するデバイスを特定して選択します。

  • [ソート(Sort)]:列ヘッダーをクリックすることで、デバイスリストをソートします。

    FTD デバイスへの展開時にトラフィックのインスペクションを中断させたり、トラフィック自体を中断させる可能性のある設定の特定に役立つ列の詳細については、FTD デバイスの再起動の警告 を参照してください。

    すべてのデバイスへの展開時にトラフィック検査を中断させたりトラフィック自体を中断させる可能性のある設定については、展開またはアクティブ化された際に Snort プロセスを再起動する設定を参照してください。

  • [展開(Expand)]:デバイスリストを展開して、展開される設定変更を表示するには、プラス記号をクリックします。システムは、期限切れのポリシーをインデックスでマーキングします。

    [Inspect Interruption] 列の状態が [Yes] の場合、その展開によって FTD デバイスのインスペクションとおそらくはトラフィックが中断されることを示しています。展開された一覧では、中断を発生させる構成が赤色で強調表示されます。

  • [フィルタ(Filter)]:デバイスリストをフィルタリングします。列ヘッダーの右隅にある矢印をクリックします。
    • [検査中断(Inspect Interruption)] 列:[フィルタ(Filters)] ドロップダウンメニューで、目的のフィルタオプションを確認します。複数のオプションを選択できます。

      再起動に関する警告の詳細については、FTD デバイスの再起動の警告を参照してください。

    • その他のすべての列:[フィルタ(Filters)] テキストボックスにテキストを入力し、Enter を押します。

    [フィルタ(Filters)] チェックボックスをオンまたはオフにして、フィルタをアクティブまたは非アクティブにします。
  • [変更(Modify)]:右上の をクリックして、[列(Columns)] ドロップダウンリストから表示する列のチェックボックスをオンまたはオフにします。
  • 調整:マウスカーソルを列ヘッダーの上に移動し、列をドラッグアンドドロップして希望の順序にします。
ステップ 3

[Deploy] をクリックします。

ステップ 4

展開する変更に関するエラーや警告がシステムによって識別された場合は、[要求された展開のエラーと警告(Errors and Warnings for Requested Deployment)] ウィンドウにその内容が表示されます。完全な詳細を表示するには、[詳細(Details)] 列の [クリックしてすべての詳細を表示(Click to view all details)] リンクをクリックします。

次の選択肢があります。

  • [続行(Proceed)]:警告状態を解決せずに展開を続行します。システムがエラーを確認した場合は続行できません。
  • [キャンセル(Cancel)]:展開せずに終了します。エラーおよび警告状態を解決し、設定の再展開を試行します。

次のタスク

  • (オプション)展開ステータスをモニタします。展開メッセージの表示を参照してください。

  • 展開が失敗した場合は、設定変更を展開するためのベストプラクティスを参照してください。

  • 展開中に何らかの理由で展開が失敗した場合、その障害がトラフィックに影響を与える可能性があります。ただし、特定の条件によって異なります。展開に特定の設定変更がある場合、展開の失敗によってトラフィックが中断されることがあります。展開が失敗したときにトラフィックの中断を引き起こす可能性がある設定変更については、次の表を参照してください。

    設定の変更

    存在するか

    トラフィックへの影響

    アクセス コントロール ポリシーでの Threat Defense サービスの変更

    対応

    対応

    VRF

    対応

    対応

    Interface

    対応

    対応

    QoS

    対応

    対応


    (注)  

    展開中にトラフィックを中断する設定変更は、FMCFTD の両方がバージョン 6.2.3 以降である場合にのみ有効です。


デバイスへの既存の設定の再展開

既存(変更なし)の設定を単一の管理対象デバイスに強制展開できます。メンテナンス ウィンドウで、またはトラフィック フローとインスペクションに対する中断の影響が最小限になる時間に、展開することを強くお勧めします。


注意    

展開する際にリソースを要求すると、いくつかのパケットがインスペクションなしでドロップされることがあります。また、一部のコンフィギュレーションを展開すると、トラフィックのインスペクションを中断する Snort プロセスが再開します。この中断中にトラフィックがドロップされるか、それ以上インスペクションが行われずに受け渡されるかは、ターゲット デバイスがトラフィックを処理する方法に応じて異なります。Snort® の再起動によるトラフィックの動作および展開またはアクティブ化された際に Snort プロセスを再起動する設定を参照してください。

始める前に

設定変更を展開するためのベストプラクティスで説明されているガイドラインを確認してください。

手順


ステップ 1

[デバイス(Devices)] > [デバイス管理(Device Management)]を選択します。

ステップ 2

強制導入するデバイスの横にある をクリックします。

マルチドメイン展開では、リーフドメインにいない場合、システムによって切り替えるように求められます。

ステップ 3

[デバイス(Device)] をクリックします。

ステップ 4

[全般(General)] セクション見出しの横にある をクリックします。

ステップ 5

展開を強制[展開を強制(force deploy)] アイコン をクリックします。

(注)   

強制導入は、FTD に導入されるポリシールールの完全な生成をともなうため、通常の導入よりも時間がかかります。

ステップ 6

[展開(Deploy)] をクリックします。

システムでは、展開中の設定で発生したエラーや警告が識別されます。[続行(Proceed)] をクリックすると、警告状態を解決せずに続行できます。ただし、システムがエラーを示している場合は、続行できません。


次のタスク

Snort® の再起動シナリオ

管理対象デバイス上の Snort プロセスと呼ばれるトラフィック インスペクション エンジンが再起動すると、プロセスが再開されるまでインスペクションが中断されます。 この中断中にトラフィックがドロップされるか、それ以上インスペクションが行われずに受け渡されるかは、ターゲット デバイスがトラフィックを処理する方法に応じて異なります。詳細はSnort® の再起動によるトラフィックの動作を参照してください。 また、Snort プロセスが再起動するかどうかに関係なく、展開時にリソース需要が高まった結果、いくつかのパケットがインスペクションを実行せずにドロップされることがあります。

次の表に示すいずれかのシナリオでは、Snort プロセスが再起動されます。

表 2. Snort 再起動のシナリオ

再起動のシナリオ

詳細情報

Snort プロセスの再起動が必要な特定の設定を展開した場合。

展開またはアクティブ化された際に Snort プロセスを再起動する設定

Snort プロセスを直ちに再起動するように設定を変更した場合。

変更により Snort プロセスがただちに再起動する場合

現在展開されている自動アプリケーション バイパス(AAB)設定のトラフィックをアクティブにした場合。

自動アプリケーションバイパスの設定

ポリシー適用中のトラフィックの検査

[ポリシー適用時にトラフィックを検査(Inspect traffic during policy apply)] は、管理対象デバイスが設定変更の展開時にトラフィックを検査できるようにするための詳細アクセス コントロール ポリシーの一般設定です。これは、展開する設定で Snort プロセスの再起動が不要な場合に限ります。このオプションは、次のように設定できます。

  • [有効(Enabled)]:特定の設定で Snort 処理を再起動する必要な場合を除き、トラフィックは展開時に検査されます。

    展開する設定に Snort の再起動が必要でなければ、システムは現在展開されているアクセス コントロール ポリシーを使用してトラフィックを検査し、導入中に、展開しているアクセス コントロール ポリシーに切り替えます。

  • [無効(Disabled)]:展開時にトラフィックは検査されません。Snort プロセスは展開時に必ず再起動されます。

次の図に、[ポリシー適用時にトラフィックを検査(Inspect traffic during policy apply)] を有効にした場合と無効にした場合の Snort の再起動の仕組みを示します。


注意    

展開する際にリソースを要求すると、いくつかのパケットがインスペクションなしでドロップされることがあります。また、一部のコンフィギュレーションを展開すると、トラフィックのインスペクションを中断する Snort プロセスが再開します。この中断中にトラフィックがドロップされるか、それ以上インスペクションが行われずに受け渡されるかは、ターゲット デバイスがトラフィックを処理する方法に応じて異なります。Snort® の再起動によるトラフィックの動作および展開またはアクティブ化された際に Snort プロセスを再起動する設定を参照してください。


Snort® の再起動によるトラフィックの動作

次の表に、Snort プロセスが再起動した場合のさまざまなデバイスのトラフィックの処理方法を示します。

表 3. FTD および FTDv の再起動によるトラフィックへの影響

インターフェイスの設定

再起動によるトラフィックの動作

inline: Snort Fail Open: Down: disabled

ドロップされる

inline: Snort Fail Open: Down: enabled

検査なしで受け渡される

Snort がダウンしていることをシステムが認識するまでに、一部のパケットがバッファ内で数秒間遅延することがあります。この遅延は、負荷分散によって異なります。ただし、バッファされたパケットは最終的に渡されます。

ルーテッド、トランスペアレント(EtherChannel、冗長、サブインターフェイスを含む):preserve-connection は enabled(configure snort preserve-connection enable 、デフォルト)

詳細については、Cisco Firepower Threat Defense コマンド リファレンスを参照してください。

既存の TCP/UDP フロー:Snort がダウンしている間、1 つでもパケットが着信すると、検査なしで渡されます。

新規 TCP/UDP フローとすべての非 TCP/UDP フロー:ドロップされる

preserve-connection が有効になっている場合でも、次のトラフィックはドロップされることに注意してください。

  • プレーンテキスト、パススルー プレフィルタ トンネル トラフィック ( Analyze ルール アクションまたはAnalyze all tunnel traffic デフォルト ポリシー アクション と一致)

  • アクセスコントロールルールと一致せず、デフォルトアクションによって代わりに処理される接続。

  • 復号化された TLS/SSL トラフィック

  • セーフ サーチ フロー

  • キャプティブ ポータル フロー

ルーテッド、トランスペアレント(EtherChannel、冗長、サブインターフェイスを含む):preserve-connection は disabled(configure snort preserve-connection disable

ドロップされる

inline: tap mode

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

パッシブ

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

表 4. NGIPSv 再起動トラフィックの影響

インターフェイスの設定

再起動によるトラフィックの動作

inline: Failsafe enabled または disabled

インスペクションなしで受け渡される

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

inline: tap mode

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

パッシブ

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

表 5. ASA FirePOWER Restart トラフィックの影響

インターフェイスの設定

再起動によるトラフィックの動作

フェール オープンを伴うルーテッドまたはトランスペアレント

インスペクションなしで受け渡される

フェール クローズを伴うルーテッドまたはトランスペアレント

ドロップされる


(注)  

再起動中に Snort プロセスがダウンした場合のトラフィック処理に加え、フェールセーフ オプション(インライン セット を参照)または Snort フェールオープンの [ビジー(Busy)] オプション(インラインセットを設定します。 を参照)の設定に応じて、トラフィックをインスペクションなしで通過させたり、または Snort プロセスがビジーのときにトラフィックをドロップしたりすることもできます。デバイスは、フェールセーフ オプションまたは Snort フェールオープン オプションの両方ではなくいずれかをサポートします。

警告

Snort ルールの更新中は、システムを再起動しないでください。

Snort が十分な速度でパケットを処理できない場合、Snort ビジードロップが発生します。処理の遅延が原因で Snort がビジー状態にあるかどうか、またはコールブロッキングが原因でスタックしているかどうかは、Lina で認識されません。伝送キューがいっぱいになると、Snort ビージードロップが発生します。送信キューの使用率に基づいて、Lina はキューがスムーズに処理されている場合にアクセスを試みます。


(注)  

設定の導入時に Snort プロセスがビジーになったが、ダウンしなかった場合、CPU の合計負荷が 60 % を超えると一部のパケットがルーテッド、スイッチド、またはトランスペアレント インターフェイスでドロップする場合があります。

展開またはアクティブ化された際に Snort プロセスを再起動する設定

AAB 以外の構成を展開すると、Snort プロセスが再起動されます。AAB の展開自体には再起動が伴いませんが、パケットの遅延が大きすぎると、現在展開されている AAB 設定がアクティブになり、Snort プロセスが部分的に再起動されます。

アクセス コントロール ポリシーの詳細設定
  • [ポリシー適用時にトラフィックのインスペクションを実行する(Inspect traffic during policy apply)] が無効な場合に展開します。

  • SSL ポリシーを追加または削除します。

ファイルポリシー(File Policy)

次のいずれかの構成の最初または最後を展開します。これらのファイル ポリシー構成を展開しても再起動は発生しませんが、非ファイル ポリシー構成を展開すると再起動が発生する可能性があることに注意してください。

  • 次のいずれかの操作を行います。

    • 展開されたアクセス コントロール ポリシーに 1 つ以上のファイル ポリシーが含まれている場合は、[アーカイブを検査する(Inspect Archives)] を有効または無効にします。

    • [アーカイブを検査する(Inspect Archives)] が有効になっている場合は、最初のファイルポリシールールを追加するか、または最後のファイルポリシー ルールを削除します([アーカイブを検査する(Inspect Archives)] が有意味であるためには 1 つ以上のルールが必要であることに注意してください)。

  • [ファイルを検出(Detect Files)] または [ファイルをブロック(Block Files)] ルールで、[ストア ファイル(Store files)] を有効または無効にします。

  • [マルウェアクラウドのルックアップ(Malware Cloud Lookup)] または [マルウェアをブロック(Block Malware)] ルールアクションと、分析オプション([Spero 分析または MSEXE(Spero Analysis or MSEXE)]、[ダイナミック分析(Dynamic Analysis)] または [ローカルマルウェア分析(Local Malware Analysis)])またはストアファイルオプション([マルウェア(Malware)]、[不明(Unknown)]、[クリーン(Clean)] または [カスタム(Custom)])を組み合わせた最初のアクティブファイルルールを追加するか、または最後のアクティブ ファイル ルールを削除します。

これらのファイルポリシー構成をセキュリティゾーンまたはトンネルゾーンに展開するアクセス コントロール ルールによって再起動が発生するのは、構成が次の条件を満たす場合だけであることに注意してください。

  • アクセス コントロール ルールに含まれる送信元または宛先セキュリティゾーンは、ターゲットデバイス上のインターフェイスに関連付けられたセキュリティゾーンと一致する必要があります。

  • アクセス コントロール ルールに含まれる宛先ゾーンが [任意(any)] でないかぎり、ルールに含まれる送信元トンネルゾーンは、プレフィルタポリシーに含まれるトンネルルールに割り当てられているトンネルゾーンと一致する必要があります。

ID ポリシー
  • SSL 復号化が無効になっている場合(つまり、アクセス コントロール ポリシーに SSL ポリシーが含まれていない場合)は、最初のアクティブ認証ルールを追加するか、または最後のルールを削除します。

    アクティブな認証ルールに [アクティブ認証(Active Authentication)] ルールアクションが含まれるか、[パッシブ/VPNアイデンティティを確立できない場合にアクティブ認証を使用(Use active authentication if passive or VPN identity cannot be established)] が選択された [パッシブ認証(Passive Authentication)] ルールアクションが含まれます。

ネットワーク検出(Network Discovery)
  • ネットワーク検出ポリシーを使用して、HTTP、FTP、または MDNS プロトコル経由で権限のないトラフィックベースのユーザ検出を有効または無効にします。

デバイス管理
  • MTU:デバイス上のすべての非管理インターフェイスの中で最大の MTU 値を変更します。

  • 自動アプリケーションバイパス(AAB):現在展開されている AAB 構成は、Snort プロセスの誤動作またはデバイスの誤設定により、単一のパケットが過度の処理時間を使用した場合にアクティブになります。その結果、Snort プロセスが部分的に再起動され、非常に大きい遅延が緩和されるか、または完全なトラフィックの停止が防止されます。この部分的な再起動により、デバイスがトラフィックをどのように処理するかに応じて、いくつかのパケットがインスペクションなしで通過するか、またはドロップされます。

変更点
  • システムアップデート:新しいバージョンの Snort バイナリまたはデータ収集ライブラリ(DAQ)を含むソフトウェアアップデートの後に初めて構成を展開します。

  • VDB:管理対象デバイスに適用可能な変更を含む、脆弱性データベース(VDB)更新のインストール後に初めて構成を展開すると、検出エンジンの再起動が必要になるため、一時的にトラフィックが中断する可能性があります。そのため、インストールを開始するために FMC を選択すると、警告メッセージが表示されます。展開ダイアログは、VDB 変更が保留中の場合、FTD デバイスに関する追加の警告を表示します。FMC にのみ適用される VDB の更新では検出エンジンの再起動が行われないため、更新を展開できません。

変更により Snort プロセスがただちに再起動する場合

以下の変更を行うと、展開プロセスを経ることなく Snort プロセスが直ちに再起動されます。 再起動がトラフィックにどのような影響を与えるかは、ターゲット デバイスがトラフィックを処理する方法によって異なります。詳細はSnort® の再起動によるトラフィックの動作を参照してください。

  • アプリケーションまたはアプリケーション ディテクタに関する次の操作のいずれかを実行します。

    • システムまたはカスタム アプリケーション ディテクタを有効または無効にします。

    • アクティブ化されたカスタム ディテクタを削除します。

    • アクティブ化されたカスタム ディテクタを保存して再アクティブ化します。

    • ユーザ定義のアプリケーションを作成します。

    この操作を続けると管理対象のすべてのデバイスで Snort プロセスが再起動するという警告メッセージが表示され、キャンセルが可能になります。再起動は、現在のドメインまたはその子ドメインのいずれかの管理対象デバイスで発生します。

  • Firepower Threat Defense ハイ アベイラビリティ ペアの作成または解除:ハイ アベイラビリティ ペアの作成を続行すると、プライマリ デバイスとセカンダリ デバイスで Snort プロセスが再起動するという警告メッセージが表示され、キャンセルが可能になります。

ポリシーの比較

変更後のポリシーが組織の標準に準拠することを確かめたり、システム パフォーマンスを最適化したりする目的で、2 つのファイル ポリシーの間の違いや、保存済みポリシーと実行中のポリシーの間の違いを調べることができます。

比較できるポリシーのタイプは次のとおりです。

  • DNS

  • ファイル

  • ヘルス

  • アイデンティティ

  • 侵入(Snort 2 ポリシーのみ)

  • ネットワーク分析

  • SSL

比較ビューには、両方のポリシーが並べて表示されます。2 つのポリシー間の差異は、次のように強調表示されます。

  • 青色は強調表示された設定が 2 つのポリシーで異なることを示し、差異は赤色で示されます。

  • 緑色は強調表示された設定が一方のポリシーには存在するが、他方には存在しないことを示します。

ポリシーの比較

特定のポリシーに対するアクセス権と必要なライセンスがあり、ポリシーを設定するための正しいドメインにいる場合にのみ、ポリシーを比較できます。

手順


ステップ 1

比較するポリシーの管理ページにアクセスします。

  • [DNS]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [DNS]
  • [ファイル(File)]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [マルウェアとファイル(Malware & File)]
  • [状況(Health)]:[システム(System)] > [ヘルス(Health)] > [ポリシー(Policy)]
  • [ID(Identity)]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [ID(Identity)]
  • [侵入(Intrusion)]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [侵入(Intrusion)]
    (注)   

    Snort 2 ポリシーのみを比較できます。

  • [ネットワーク分析(Network Analysis)]:[ポリシー(Policies)] > [アクセス制御(Access Control)]、次に [ネットワーク分析ポリシー(Network Analysis Policies)] または [Policies] > [Access Control] > [Intrusion]、次に [Network Analysis Policies]
    (注)   

    カスタムユーザロールに、ここにリストされている最初のパスへのアクセス制限がある場合は、2 番目のパスを使用してポリシーにアクセスします。

  • [SSL]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [SSL]
ステップ 2

[ポリシーの比較(Compare Policies)] をクリックします。

ステップ 3

[比較対象(Compare Against)] ドロップダウンリストから、比較するタイプを次のように選択します。

  • 異なる 2 つのポリシーを比較するには、[他のポリシー(Other Policy)] を選択します。
  • 同じポリシーの 2 つのリビジョンを比較するには、[その他のリビジョン(Other Revision)] を選択します。
  • 現在のアクティブポリシーを他のポリシーに対して比較するには、[実行中の設定(Running Configuration)] を選択します。
ステップ 4

選択した比較タイプに応じて、次のような選択肢があります。

  • 2 つの異なるポリシーを比較する場合、[ポリシーA(Policy A)] ドロップダウンリストと [ポリシーB(Policy B)] ドロップダウンリストから比較するポリシーを選択します。
  • 実行中の設定を別のポリシーと比較する場合、[ポリシーB(Policy B)] ドロップダウンリストから 2 番目のポリシーを選択します。
ステップ 5

[OK] をクリックします。

ステップ 6

比較の結果を確認します。

  • [比較ビューア(Comparison Viewer)]:比較ビューアを使用して、ポリシーの違いを個別に検索するには、タイトルバーの上にある [前へ(Previous)] または [次へ(Next)] をクリックします。
  • [比較レポート(Comparison Report)]:2 つのポリシーの違いを示す PDF レポートを生成するには、[比較レポート(Comparison Report)] をクリックします。


ポリシー レポート

ほとんどのポリシーには、2 種類のレポートを生成することができます。単一のポリシーに関するレポートには、現在保存されているポリシー設定の詳細が記載されます。一方、比較レポートには、2 つのポリシー間の違いだけがリストされます。単一ポリシー レポートは、ヘルス ポリシーを除くすべてのポリシー タイプについて生成できます。


(注)  

侵入ポリシー レポートには基本ポリシーの設定とポリシー階層の設定が結合され、どちらが基本ポリシーまたはポリシー レイヤのどちらに基づく設定であるかは区別されません。


現在のポリシー レポートの生成

特定のポリシーに対するアクセス権と必要なライセンスがあり、ポリシーを設定するための正しいドメインにいる場合にのみ、ポリシーレポートを生成できます。

手順


ステップ 1

レポートを生成するポリシーの管理ページにアクセスします。

  • アクセス制御—[ポリシー(Policies)] > [アクセス制御(Access Control)]
  • [DNS]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [DNS]
  • [ファイル(File)]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [マルウェアとファイル(Malware & File)]
  • [状況(Health)]:[システム(System)] > [ヘルス(Health)] > [ポリシー(Policy)]
  • [ID(Identity)]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [ID(Identity)]
  • [侵入(Intrusion)]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [侵入(Intrusion)]
  • [ネットワーク分析(Network Analysis)]:[ポリシー(Policies)] > [アクセス制御(Access Control)]、次に [ネットワーク分析ポリシー(Network Analysis Policies)] または [Policies] > [Access Control] > [Intrusion]、次に [Network Analysis Policies]
    (注)   

    カスタムユーザロールに、ここにリストされている最初のパスへのアクセス制限がある場合は、2 番目のパスを使用してポリシーにアクセスします。

  • [SSL]:[ポリシー(Policies)] > [アクセス制御(Access Control)] > [SSL]
ステップ 2

レポートの生成対象とするポリシーの横にある をクリックします。


失効ポリシー

Firepower システムは、失効したポリシーに赤色のステータス テキストでマークを付けます。このテキストには、ポリシーの更新を必要とするターゲット デバイスの数が示されます。失効ステータスをクリアするには、ポリシーをデバイスに再展開する必要があります。

ポリシーの再展開が必要な設定変更には次のものがあります。

  • アクセス コントロール ポリシー自体の変更:アクセス コントロール ルール、デフォルト アクション、ポリシー ターゲット、セキュリティ インテリジェンス フィルタリング、前処理などの詳細オプションの変更。

  • アクセス コントロール ポリシーが呼び出すポリシーの変更:SSL ポリシー、ネットワーク分析ポリシー、侵入ポリシー、ファイル ポリシー、アイデンティティ ポリシー、または DNS ポリシー。

  • 呼び出されるアクセス コントロール ポリシーで使用される再利用可能オブジェクトまたは設定の変更:

    • ネットワーク、ポート、VLAN タグ、URL、地理位置情報オブジェクト

    • セキュリティ インテリジェンス リストおよびフィード

    • アプリケーション フィルタまたはディテクタ

    • 侵入ポリシーの変数セット

    • ファイル リスト

    • 復号関連のオブジェクトとセキュリティ ゾーン

  • システム ソフトウェア、侵入ルール、または脆弱性データベース(VDB)の更新。

Web インターフェイスの複数の場所からこれらの設定の一部を変更できることに留意してください。たとえば、オブジェクト マネージャ([オブジェクト(Objects)] > [オブジェクト管理(Object Management)])を使用してセキュリティ ゾーンを変更できますが、デバイスの設定([デバイス(Devices)] > [デバイス管理(Device Management)])でインターフェイスのタイプを変更すると、ゾーンも変更され、ポリシーの再展開が必要になります。

次の更新では、ポリシーの再展開は必要ありません

  • セキュリティ インテリジェンス フィードへの自動更新およびコンテキストメニューを使用したセキュリティ インテリジェンスのグローバルのブロックリストまたはブロックしないリストへの追加

  • URL フィルタリング データへの自動更新

  • スケジュールされた位置情報データベース(GeoDB)の更新

限定的な導入のパフォーマンスに関する考慮事項

システムはホスト、アプリケーション、ユーザ検出データを使用することで、ネットワークの完全な最新プロファイルを作成できます。また、システムが侵入検知および防御システム(IPS)として機能して、ネットワーク トラフィックを分析して侵入およびエクスプロイトを検出し、オプションで問題のあるパケットをドロップすることもできます。

検出と IPS を組み合わせることで、ネットワーク アクティビティにコンテンツが提供され、次のような多くの機能を利用することができます。

  • 侵害の影響フラグと表示。これによって、どのホストが特定のエクスプロイト、攻撃、またはマルウェアに対して脆弱であるかが示されます。

  • アダプティブ プロファイルの更新と Firepower の推奨事項。これによって、宛先ホストに応じてトラフィックを個別に検査できます。

  • 相関。これによって、影響を受けるホストに応じて別々に侵入(およびその他のイベント)に応答できます。

ただし、組織が IPS または検出のみを実行することを目的としている場合は、システムのパフォーマンスを最適化できる設定がいくつかあります。

侵入防御のない検出

検出機能では、ネットワーク トラフィックをモニタして、ネットワーク上のホストの数とタイプ(ネットワーク デバイスを含む)だけでなく、それらのホスト上のオペレーティング システム、アクティブなアプリケーション、およびオープン ポートを判断できます。管理対象デバイスをネットワークのユーザ アクティビティをモニタするように設定することもできます。検出データを使用して、トラフィック プロファイリングを実行し、ネットワーク コンプライアンスを評価し、ポリシー違反に応答できます。

基本的な展開(検出と単純なネットワークベースのアクセス制御のみ)では、アクセス コントロール ポリシーの設定時にいくつかの重要なガイドラインに従うことで、デバイスのパフォーマンスを向上させることができます。


(注)  

それが単にすべてのトラフィックを許可する場合であっても、アクセス コントロール ポリシーを使用する必要があります。ネットワーク検出ポリシーが実行できるのは、アクセス コントロール ポリシーが通過を許可したトラフィックを検査することのみです。


最初に、アクセス コントロール ポリシーは複雑な処理を必要とせず、単純なネットワークベースの基準のみを使用してネットワーク トラフィックを処理することを確認します。次のすべてのガイドラインを実装する必要があります。これらのオプションのいずれかを誤って設定すると、パフォーマンス上の利点がなくなります。

  • セキュリティ インテリジェンス機能を使用しないでください。入力されたグローバルのブロックリストまたはブロックしないリストをポリシーのセキュリティ インテリジェンスの設定から削除します。

  • モニター アクションまたはインタラクティブ ブロック アクションに、アクセス コントロール ルールを含めないでください。許可、信頼、およびブロック ルールのみを使用します。許可されたトラフィックは検出によって検査できますが、信頼されたトラフィックとブロックされたトラフィックは検査できないことに留意してください。

  • アプリケーション、ユーザ、URL、ISE 属性、または位置情報ベースのネットワーク条件にアクセス コントロール ルールを含めないでください。単純なネットワークベースの条件(ゾーン、IP アドレス、VLAN タグ、およびポート)のみを使用します。

  • ファイル、マルウェア、または侵入インスペクションを実行するアクセス コントロール ルールを含めないでください。つまり、ファイル ポリシーまたは侵入ポリシーをアクセス コントロール ルールに関連付けないでください。

  • アクセス コントロール ポリシーの詳細設定で、[アクセスコントロールルールが決定される前に使用される侵入ポリシー(Intrusion Policy used before Access Control rule is determined)] が [アクティブなルールなし(No Rules Active)] に設定されていることを確認します。

  • ポリシーのデフォルト アクションとして [ネットワーク検出のみ(Network Discovery Only)] を選択します。侵入インスペクションを実行するポリシーのデフォルト アクションを選択しないでください。

アクセス コントロール ポリシーと組み合わせて、ネットワーク検出ポリシーを設定して適用できます。このポリシーは、システムが検出データについて検査をするネットワーク セグメント、ポート、およびゾーンを指定し、ホスト、アプリケーション、およびユーザーがセグメント、ポート、およびゾーンで検出されるかどうかを指定します。

ディスカバリのない侵入防御

必要がない場合(たとえば、IPS のみの展開など)に検出を無効にするとパフォーマンスが向上する可能性があります。検出を無効にするには、次のすべての変更を実装する必要があります。

  • ネットワーク検出ポリシーからすべてのルールを削除します。

  • 単純なネットワークベースの条件(ゾーン、IP アドレス、VLAN タグ、およびポート)のみを使用してアクセス制御を実行します。

    どんな種類のセキュリティ インテリジェンス、アプリケーション、ユーザー、URL、または地理位置情報の制御も行わないでください。検出データの保存を無効にできても、システムではそれらの機能を実装するためにデータを収集して検査する必要があります。

  • デフォルトのグローバルリストなど、アクセス コントロール ポリシーのセキュリティ インテリジェンス設定からすべてのブロックリストとブロックしないリストを削除することで、ネットワークと URL ベースのセキュリティ インテリジェンスを無効にします。

  • DNS のデフォルトのグローバルブロックしないリストや DNS ルールのグローバルブロックリストなど、関連付けられている DNS ポリシー内のすべてのルールを削除または無効にすることで、DNS ベースのセキュリティ インテリジェンスを無効にします。

展開後、新たな検出はターゲット デバイス上で停止します。タイムアウトの設定に応じて、システムはネットワーク マップ内の情報を段階的に削除していきます。または、すべての検出データを即座に消去できます。