ルール管理:共通の特性

以下のトピックでは、Firepower Management Center でさまざまなポリシーのルールの共通特性を管理する方法について説明します。

ルール管理の要件と前提条件

モデルのサポート

任意

サポートされるドメイン

任意

ユーザの役割

  • 管理者

  • アクセス管理者

  • ネットワーク管理者

ルールの概要

さまざまなポリシー内のルールで、ネットワーク トラフィックをきめ細かく制御できます。システムは最初の一致のアルゴリズムを使用して、指定した順番でルールに照らし合わせてトラフィックを評価します。

これらのルールはポリシー全体で一貫していない他の設定を含んでいる場合もありますが、次のような多くの基本的な特性や設定メカニズムは共通です。

  • 条件:ルールの条件は各ルールが処理するトラフィックを指定します。複数の条件により各ルールを設定できます。トラフィックは、ルールに一致するすべての条件に適合する必要があります。

  • アクション:ルールのアクションによって、一致するトラフィックの処理方法が決まります。選択できる [アクション(Action)] リストがルールにない場合でも、ルールには関連付けられたアクションが 1 つある点に注意してください。たとえば、カスタム ネットワーク分析ルールはそのルールの「アクション」としてネットワーク分析ポリシーを使用します。 別の例としては、QoS ルールの場合、どの QoS ルールでもトラフィックのレート制限という同じ動作をするため、明示的なアクションはありません。

  • 位置:ルールの位置は評価の順番を決定します。ポリシーを使ってトラフィックを評価すると、システムは指定した順序でトラフィックとルールを照合します。通常は、システムによるトラフィックの処理は、すべてのルールの条件がトラフィックに一致する最初のルールに従って行われます(追跡とログ記録を行うように設計されたモニタールールは例外です)。適切なルールの順序を指定することで、ネットワーク トラフィックの処理に必要なリソースが削減され、ルールのプリエンプションを回避できます。

  • カテゴリ:いくつかのルール タイプを整理するために、各親ポリシーでカスタムのルール カテゴリを作成できます。

  • ロギング:多くのルールでは、ルールが処理する接続をシステムがロギングするかどうか、およびロギングの処理方法は、ロギングの設定によって制御されます。一部のルール(ID ルールやネットワーク分析ルールなど)にはロギング設定は含まれません。これは、ルールが接続の最終的な性質を決定するわけではなく、またそのルールが接続をロギングするために特別に設計されているわけではないためです。 別の例としては、QoS ルールにはロギングの設定は含まれていません。これは、レート制限されているというだけの理由で接続をロギングすることはできないためです。

  • コメント:一部のルール タイプでは、変更を保存するたびにコメントを追加できます。たとえば、他のユーザーのために設定全体を要約したり、ルールの変更時期と変更理由を記載することができます。


ヒント

多くのポリシーエディタでは、右クリック メニューで編集、削除、移動、有効化、無効化など、数多くのルール管理オプションへのショートカットを提供しています。

共通の特性を持つルール

この章では、以下のルールや設定に見られる多くの共通の側面について説明しています。共通していない設定の情報については、以下を参照してください。

共通の特性のないルール

次のルールの設定は、この章では説明していません。

ルール条件タイプ

次の表は、この章に記述している一般的なルールの条件について説明し、使用設定を列挙します。

条件

トラフィック制御方法

対応しているルール/設定

インターフェイス条件

送信元インターフェイスと宛先インターフェイス、対応している場合にはトンネル ゾーン

アクセス コントロール ルール

トンネル ルール

プレフィルタ ルール

SSL ルール

DNS ルール

アイデンティティ ルール

ネットワーク分析ルール

QoS ルール

ネットワーク条件

送信元 IP アドレスと宛先 IP アドレス、対応している場合には地理的な場所や発信側のクライアント

アクセス コントロール ルール

プレフィルタ ルール

SSL ルール

DNS ルール

アイデンティティ ルール

ネットワーク分析ルール

QoS ルール

トンネル エンドポイント条件

プレーン テキスト用、送信元のトンネル エンドポインと宛先のトンネル エンドポイント、パススルー トンネル

トンネル ルール

VLAN 条件

VLAN タグ

アクセス コントロール ルール

(注)   

アクセスルールの VLAN タグは、インラインセットにのみに適用されます。このタグは、ファイアウォール インターフェイスに適用されるアクセスルールには使用できません。

トンネル ルール

プレフィルタ ルール

SSL ルール

DNS ルール

アイデンティティ ルール

ネットワーク分析ルール

ポートおよび ICMP コードの条件

送信元ポート、宛先ポート、プロトコル、ICMP コード

アクセス コントロール ルール

プレフィルタ ルール

SSL ルール

アイデンティティ ルール

QoS ルール

カプセル化の条件

カプセル化プロトコル(非暗号化)

トンネル ルール

アプリケーション条件(アプリケーション制御)

アプリケーションまたはアプリケーション特性(タイプ、リスク、ビジネスの関連性、カテゴリ、タグ)

アクセス コントロール ルール

SSL ルール

アイデンティティ ルール

QoS ルール

アプリケーション フィルタ

インテリジェント アプリケーション バイパス(IAB)

URL 条件(URL フィルタリング)

URL、対応している場合には、URL の特性(カテゴリおよびレピュテーション)

アクセス コントロール ルール

SSL ルール

QoS ルール

ユーザー条件、レルム条件、および ISE 属性条件(ユーザー制御)

ホストのログイン権限のあるユーザまたはそのユーザのレルム、グループ、または ISE 属性

アクセス コントロール ルール

SSL ルール(ISE 属性なし)

QoS ルール

カスタム SGT 条件

カスタム セキュリティ グループ タグ(SGT)

アクセス コントロール ルール

QoS ルール

ルール条件の仕組み

ルール条件では、各ルールで処理するトラフィックを指定します。各ルールに複数の条件を設定し、トラフィックがルールに一致するにはすべての条件を満たす必要があります。使用可能な条件タイプは、ルール タイプによって異なります。

ルール エディタには、条件タイプごとに独自のタブ ページがあります。一致させるトラフィック特性を選択して条件を作成します。一般に、左側の使用可能な項目のリスト(1 つまたは 2 つ)から基準を選択し、それらの基準を右側の選択済み項目のリスト(1 つまたは 2 つ)に追加します。たとえば、アクセス コントロール ルールの URL 条件では、URL カテゴリとレピュテーション基準を組み合わせて、ブロックする Web サイトのグループを 1 つ作成できます。

条件を作成しやすくするために、レルム、ISE 属性、さまざまなタイプのオブジェクトやオブジェクト グループなど、さまざまなシステム提供の構成やカスタム構成を使用して、トラフィックを照合できます。多くの場合、ルール基準は手動で指定できます。

可能な場合は常に、一致基準を空のままにします(特にセキュリティ ゾーン、ネットワーク オブジェクト、およびポート オブジェクトの場合)。基準を複数指定すると、指定した条件の内容についてすべての組み合わせと照合する必要があります。


注意    

アクセス コントロール ルールを適切に設定しないと、ブロックする必要があるトラフィックを含め、予期しない結果が発生する可能性があります。一般的に、アプリケーション制御ルールは、たとえば IP アドレスに基づくルールよりも照合に時間がかかるため、アクセス コントロール リスト内の順位を低くする必要があります。

特定の条件 (ネットワークや IP アドレスなど) を使用するアクセス コントロール ルールは、一般的な条件 (アプリケーションなど) を使用するルールの前にオーダーする必要があります。オープン システム相互接続(OSI)モデルに精通している場合は、考え方として同様の順位付けを使用してください。レイヤ1、2、および 3 (物理、データリンク、およびネットワーク) の条件を持つルールは、アクセス コントロール ルールで最初に注文する必要があります。レイヤ5、6、および 7 (セッション、プレゼンテーション、およびアプリケーション) の条件は、アクセス コントロール ルールの後で順序付けする必要があります。OSI モデルの詳細については、こちらの Wikipedia の記事を参照してください。


送信元と宛先の基準

ルールに送信元と宛先の基準(ゾーン、ネットワーク、ポート)が含まれる場合、通常は一方または両方の基準を制約として使用できます。両方を使用する場合、一致するトラフィックの発信元は、指定した送信元のゾーン、ネットワーク、またはポートのいずれかであり、宛先のゾーン、ネットワーク、またはポートのいずれかから送出される必要があります。

条件ごとの項目

最大 50 個の項目を各条件に追加できます。送信元と宛先の基準を含むルールでは、それぞれ最大 50 個使用できます。選択した項目のいずれかに一致するトラフィックが条件に一致します。

単純なルールの仕組み

ルール エディタには、次の一般的な選択肢があります。条件の作成の詳細な手順については、各条件タイプのトピックを参照してください。

  • 項目の選択(Choose Item):項目をクリックするか、そのチェックボックスにマークを付けます。多くの場合、Ctrl または Shift キーを使用して複数の項目を選択するか、右クリックして [すべて選択(Select All)] を選択できます。

  • 検索(Search):検索フィールドに基準を入力します。入力するとリストが更新されます。項目名が検索され、オブジェクトとオブジェクト グループについては、その値が検索されます。検索をクリアするには、リロード[リロード(reload)] アイコン または をクリックします。

  • 事前定義された項目の追加(Add Predefined Item):1 つ以上の使用可能な項目を選択し、[追加(Add)] ボタンをクリックするか、ドラッグアンドドロップします。無効な項目(重複、無効な組み合わせなど)は追加できません。

  • 手動項目の追加(Add Manual Item):[選択済み(Selected)] 項目リストの下のフィールドをクリックし、有効な値を入力して [追加(Add)] をクリックします。ポートを追加すると、ドロップダウン リストからプロトコルも選択できます。

  • オブジェクトの作成(Create Object): をクリックし、作成する条件ですぐに使用できる新しい再利用可能オブジェクトを作成し、オブジェクトマネージャで管理できます。この方法を使用してアプリケーション フィルタをその場で追加した場合、別のユーザー作成フィルタが含まれるフィルタを保存することはできません。

  • 削除(Delete):項目の をクリックするか、1 つ以上の項目を選択し、右クリックして [選択項目の削除(Delete Selected)] を選択します。

インターフェイス条件

インターフェイス ルールの条件は送信元インターフェイスと宛先インターフェイスによってトラフィックを制御します。

ルールタイプと導入環境でのデバイスにより、セキュリティゾーンインターフェイスグループと呼ばれる定義済みのインターフェイス オブジェクトを使用してインターフェイス条件を構築できます。インターフェイス オブジェクトはネットワークをセグメント化して複数のデバイス間でインターフェイスをグループ化することによってトラフィック フローを制御し、分類しやすくします。インターフェイス オブジェクト:インターフェイスグループとセキュリティ ゾーンを参照してください。


ヒント

インターフェイスによってルールを制約するのは、システム パフォーマンスを改善するための最適な方法の 1 つです。ルールがデバイスのすべてのインターフェイスを除外する場合、そのルールはそのデバイスのパフォーマンスに影響しません。


インターフェイス オブジェクト内のすべてのインターフェイスが同じタイプ(すべてインライン、パッシブ、スイッチド、ルーテッド、または ASA FirePOWER)である必要があるのと同様に、インターフェイス条件で使用されているすべてのインターフェイス オブジェクトは同じタイプである必要があります。パッシブに展開されたデバイスはトラフィックを送信しないため、パッシブ展開では宛先インターフェイスでルールを制約することはできません。

トンネルゾーンとセキュリティ ゾーン

一部の設定では、セキュリティ ゾーンの代わりにトンネルゾーンを使用してインターフェイス条件を制約できます。トンネル ゾーンではプレフィルタを使用して、カプセル化された接続の特定のタイプに合わせて後続のトラフィック処理を調整できます。


(注)  

トンネルゾーンの制約がサポートされる設定の場合、再区分された接続、つまり割り当てられたトンネルゾーンを持つ接続はセキュリティ ゾーンの制約と一致しません。詳細については、トンネル ゾーンおよびプレフィルタリングを参照してください。


インターフェイス条件を持つルール

ルール タイプ

セキュリティ ゾーンのサポート

トンネルゾーンのサポート

インターフェイス グループのサポート

アクセス コントロール

はい

はい

いいえ

トンネルとプレフィルタ

はい

該当なし。プレフィルタ ポリシー内でトンネルゾーンを割り当てます

はい

SSL

はい

いいえ

いいえ

DNS(送信元のみ)

はい

いいえ

いいえ

ID(Identity)

はい

いいえ

いいえ

ネットワーク分析

はい

いいえ

いいえ

QoS(ルーテッドのみ、必須)

はい

いいえ

はい

例:セキュリティ ゾーンを使用したアクセス制御

たとえば、ホストがインターネットに無制限でアクセスできるような導入にする一方、着信トラフィックで侵入およびマルウェアの有無を検査することでホストを保護したいとします。

それにはまず、内部ゾーンと外部ゾーンという 2 つのセキュリティ ゾーンを作成します。次に、これらのゾーンに 1 つ以上のデバイス上のインターフェイス ペアを割り当て、各ペアの一方のインターフェイスを内部ゾーンに割り当て、もう一方のインターフェイスを外部ゾーンに割り当てます。内部側のネットワークに接続されたホストは、保護されている資産を表します。


(注)  

内部(または外部)のすべてのインターフェイスを 1 つのゾーンにグループ化する必要はありません。導入ポリシーおよびセキュリティ ポリシーが意味をなすグループ化を選択します。


次に、宛先ゾーン条件を内部に設定したアクセス コントロール ルールを構成します。この単純なルールでは、内部ゾーンのいずれかのインターフェイスでデバイスから出力されるトラフィックが照合されます。一致するトラフィックを侵入やマルウェアについて検査するには、ルール アクションとして [許可(Allow)] を選択し、そのルールを侵入ポリシーとファイル ポリシーに関連付けます。

インターフェイス条件の設定

始める前に
  • (アクセス コントロールのみ)セキュリティ ゾーンではなくトンネル ゾーンによってトラフィックを制約する場合は、関連付けられたプレフィルタ ポリシーがそれらのゾーンを割り当てるようにします。アクセス制御への他のポリシーの関連付けを参照してください。

手順

ステップ 1

ルールエディタで、インターフェイス条件に関して次をクリックします。

  • インターフェイスグループおよびセキュリティゾーン(トンネル、プレフィルタ、QoS):[インターフェイス オブジェクト(Interface Objects)] をクリックします。
  • セキュリティゾーン(アクセスコントロール、SSL、DNS、アイデンティティ、ネットワーク分析):[ゾーン(Zones)] をクリックします。
  • トンネルゾーン(アクセスコントロール):[ゾーン(Zones)] をクリックします。
ステップ 2

[使用可能なインターフェイス オブジェクト(Available Interface Objects)] または [利用可能なゾーン(Available Zones)] リストから追加するインターフェイスを見つけて選択します。

(アクセス コントロールのみ)再ゾーン分割されたトンネルでの接続を一致させるには、セキュリティ ゾーンではなくトンネル ゾーンを選択します。同じルールでトンネル ゾーンとセキュリティ ゾーンを使用することはできません。詳細については、トンネル ゾーンおよびプレフィルタリングを参照してください。

ステップ 3

[送信元に追加(Add to Source)] または [宛先に追加(Add to Destination)] をクリックするか、またはドラッグ アンド ドロップします。

ステップ 4

ルールを保存するか、編集を続けます。


次のタスク
  • (アクセス コントロールのみ)プレフィルタ中にトンネルを再ゾーン分割した場合、完全なカバレッジを確保する必要がある場合は追加のルールを設定します。再ゾーン分割されたトンネルでの接続は、セキュリティ ゾーン制約があるルールに一致しません。詳細については、トンネル ゾーンの使用を参照してください。

  • 設定変更を展開します。設定変更の展開を参照してください。

ネットワーク条件

ネットワーク ルールの条件では、内部ヘッダーを使用して、送信元と宛先の IP アドレスを基準にトラフィックを制御します。外部ヘッダーを使用するトンネル ルールでは、ネットワーク条件の代わりにトンネル エンドポイント条件を使用します。

事前定義されたオブジェクトを使用してネットワーク条件を作成することも、個々の IP アドレスまたはアドレス ブロックを手動で指定することもできます。


(注)  

システムは、各リーフドメインに個別のネットワークマップを作成します。マルチドメイン展開では、実際の IP アドレスを使用してこの設定を抑制すると、予期しない結果になる可能性があります。 上書き対応オブジェクトを使用すると、子孫ドメインの管理者は、グローバル コンフィギュレーションを自分のローカル環境に調整できます。

可能な場合は常に、一致基準を空のままにします(特にセキュリティ ゾーン、ネットワーク オブジェクト、およびポート オブジェクトの場合)。基準を複数指定すると、指定した条件の内容についてすべての組み合わせと照合する必要があります。

ネットワーク条件での地理位置情報

ルールによっては、送信元または宛先の地理的位置を使用してトラフィックを照合することもできます。ルールのタイプが地理位置情報をサポートするものであれば、ネットワーク条件と地理位置情報条件を混在させることができます。トラフィックのフィルタリングに最新の地理位置情報データが使用されるよう、地理位置情報データベース(GeoDB)を定期的に更新することを強くお勧めします。

ネットワーク条件での元のクライアント(プロキシ トラフィックのフィルタリング)

一部のルールでは、発信元クライアントに基づいてプロキシ トラフィックを処理できます。送信元ネットワーク条件を使用してプロキシ サーバを指定し、次に元のクライアント制約を追加して元のクライアント IP アドレスを指定します。システムはパケットの X-Forwarded-For(XFF)、True-Client-IP、またはカスタム定義 HTTP ヘッダー フィールドを使用して、元のクライアント IP を判別します。

プロキシの IP アドレスがルールの送信元ネットワークの制約と一致する場合、トラフィックはルールに一致し、さらに元のクライアントの IP アドレスは、ルールの元のクライアント制約に一致します。たとえば、特定の元のクライアント アドレスからのトラフィックを許可するものの、それが特定のプロキシを使用している場合のみに限定するには、以下の 3 つのアクセス コントロール ルールを作成します。

アクセス コントロール ルール 1:特定の IP アドレス(209.165.201.1)からの非プロキシ トラフィックをブロックします。

  • 送信元ネットワーク:209.165.201.1
  • 元のクライアントのネットワーク:なし または any
  • アクション:ブロック

アクセス コントロール ルール 2:同じ IP アドレスからのプロキシ トラフィックを許可します。ただし、そのトラフィックのプロキシ サーバが、選択したもの(209.165.200.225 または 209.165.200.238)である場合に限ります。

  • 送信元ネットワーク:209.165.200.225 および 209.165.200.238
  • 元のクライアントのネットワーク:209.165.201.1
  • アクション:許可

アクセス コントロール ルール 3:同じ IP アドレスからのプロキシ トラフィックを、それが他のプロキシ サーバを使用する場合はブロックします。

  • 送信元ネットワーク:any
  • 元のクライアントのネットワーク:209.165.201.1
  • アクション:ブロック

ネットワーク条件を使用したルール

ルール タイプ

地理位置情報による制約のサポート

元のクライアントによる制約のサポート

アクセス コントロール

はい

はい

プレフィルタ

いいえ

いいえ

SSL

はい

いいえ

DNS(送信元ネットワークのみ)

いいえ

いいえ

ID(Identity)

はい

いいえ

ネットワーク分析

いいえ

いいえ

QoS

はい

はい

ネットワーク条件の設定

手順

ステップ 1

ルールエディタで、[ネットワーク(Networks)] をクリックします。

ステップ 2

[利用可能なネットワーク(Available Networks)] リストから追加する定義済みネットワークを見つけて選択します。

ルールが地理位置情報をサポートしている場合は、ネットワークと地理位置情報の基準を同じルールに混在させることができます。

  • [ネットワーク(Networks)]:[ネットワーク(Networks)] をクリックして、ネットワークを選択します。
  • [地理位置情報(Geolocation)]:[地理位置情報(Geolocation)] をクリックして、地理位置情報オブジェクトを選択します。
ステップ 3

(オプション)ルールが元のクライアント制約をサポートしている場合は、[送信元ネットワーク(Source Networks)] で、プロキシされたトラフィックを元のクライアントに基づいて処理するようにルールを設定します。

  • [送信元/プロキシ(Source/Proxy)]:[送信元(Source)] をクリックして、プロキシサーバーを指定します。
  • [元のクライアント(Original Client)]:[元のクライアント(Original Client)] をクリックして、ネットワークを元のクライアント制約として追加します。プロキシ接続では、元のクライアントの IP アドレスは、ルールに一致するネットワークの 1 つと一致する必要があります。
ステップ 4

[送信元に追加(Add to Source)]、[元のクライアントに追加(Add to Original Client)]、または [宛先に追加(Add to Destination)] をクリックするか、またはドラッグ アンド ドロップします。

ステップ 5

手動で指定するネットワークを追加します。送信元、元のクライアント、または宛先 IP アドレスかアドレス ブロックを入力し、[追加(Add)] をクリックします。

(注)   

システムは、各リーフドメインに個別のネットワークマップを作成します。マルチドメイン展開では、実際の IP アドレスを使用してこの設定を抑制すると、予期しない結果になる可能性があります。 上書き対応オブジェクトを使用すると、子孫ドメインの管理者は、グローバル コンフィギュレーションを自分のローカル環境に調整できます。

ステップ 6

ルールを保存するか、編集を続けます。


例:アクセス コントロール ルールのネットワーク条件

次の図は、内部ネットワークから発生し、北朝鮮または 93.184.216.119(example.com)のリソースにアクセスしようとする接続をブロックするアクセス コントロール ルールのネットワーク条件を示しています。

サンプルネットワーク条件のスクリーンショット

この例で、「Private Networks」と呼ばれるネットワーク オブジェクト グループ(図に示されていない IPv4 および IPv6 プライベート ネットワークのネットワーク オブジェクトから構成されます)は、内部ネットワークを表します。また、example.com の IP アドレスを手動で指定し、システムが提供する北朝鮮の位置情報オブジェクトを使用して北朝鮮の IP アドレスを表しています。

次のタスク

トンネル エンドポイント条件

トンネル エンドポイント条件は、トンネル ルールに固有のものです。この条件は、他のルール タイプのネットワーク条件と似ています。

トンネル エンドポイント条件は、特定のタイプのプレーン テキスト、パススルー トンネル(カプセル化の条件を参照)を制御します。この制御は、それらの送信元と宛先の IP アドレスによって、外側のカプセル化ヘッダーを使用して行います。これらは、トンネル エンドポイントの IP アドレス、つまり、トンネルのいずれかの側のネットワーク デバイスのルーテッド インターフェイスです。

トンネル ルールはデフォルトでは双方向で、送信元エンドポイントのいずれかと宛先エンドポイントのいずれかとの間の一致するすべてのトンネルを処理します。ただし、送信元から宛先へのトラフィックのみに一致する単方向トンネル ルールを設定できます。トンネルとプレフィルタ ルールのコンポーネントを参照してください。

事前定義済みのネットワーク オブジェクトを使用してトンネル エンドポイント条件を作成したり、個々の IP アドレスまたはアドレス ブロックを手動で指定したりできます。


(注)  

システムは、各リーフドメインに個別のネットワークマップを作成します。マルチドメイン展開では、実際の IP アドレスを使用してこの設定を抑制すると、予期しない結果になる可能性があります。 上書き対応オブジェクトを使用すると、子孫ドメインの管理者は、グローバル コンフィギュレーションを自分のローカル環境に調整できます。

トンネル エンドポイント条件の設定

トンネルエンドポイントの条件は、Firepower Threat Defense デバイスにのみ適用されます。

手順

ステップ 1

ルールエディタで、[トンネルエンドポイント(Tunnel Endpoints)] をクリックします。

ステップ 2

[利用可能なトンネル エンドポイント(Available Tunnel Endpoints)] リストから追加する定義済みネットワークを見つけて選択します。

トンネル エンドポイントは、トンネルの両側にあるネットワーク デバイスのルーテッド インターフェイスの IP アドレスであるため、ネットワーク オブジェクトを使用してトンネル エンドポイント条件を作成できます。

ステップ 3

[送信元に追加(Add to Source)] または [宛先に追加(Add to Destination)] をクリックするか、またはドラッグ アンド ドロップします。

トンネル ルールはデフォルトでは双方向であるため、2 つのエンドポイント間のすべてのトラフィックを処理できます。ただし、送信元からのトンネルのみを照合するよう選択した場合、トンネル ルールは、送信元から宛先へのトラフィックのみに一致します。

ステップ 4

手動で指定するエンドポイントを追加します。送信元か宛先の IP アドレス、またはアドレス ブロックを入力し、[追加(Add)] をクリックします。

(注)   

システムは、各リーフドメインに個別のネットワークマップを作成します。マルチドメイン展開では、実際の IP アドレスを使用してこの設定を抑制すると、予期しない結果になる可能性があります。 上書き対応オブジェクトを使用すると、子孫ドメインの管理者は、グローバル コンフィギュレーションを自分のローカル環境に調整できます。

ステップ 5

ルールを保存するか、編集を続けます。


次のタスク

VLAN 条件

VLAN ルール条件によって、Q-in-Q(スタック VLAN)など、VLAN タグ付きトラフィックが制御されます。システムでは、プレフィルタ ポリシー(そのルールで最も外側の VLAN タグを使用する)を除き、最も内側の VLAN タグを使用して VLAN トラフィックをフィルタ処理します。

次の Q-in-Q サポートに注意してください。

  • NGIPSv:すべてのインターフェイスタイプについて Q-in-Q をサポートします。

  • ASA FirePOWER モジュール:Q-in-Q をサポートしません(1 つの VLAN タグのみをサポート)。

  • Firepower 4100/9300 上の FTD:Q-in-Q をサポートしません(1 つの VLAN タグのみをサポート)。

  • 他のすべてのモデル上の FTD:

    • インラインセットおよびパッシブインターフェイス:Q-in-Q をサポートします(最大 2 つの VLAN タグをサポート)。

    • ファイアウォール インターフェイス:Q-in-Q をサポートしません(1 つの VLAN タグのみをサポート)。

事前定義のオブジェクトを使用して VLAN 条件を作成でき、また 14094 の VLAN タグを手動で入力することもできます。VLAN タグの範囲を指定するには、ハイフンを使用します。

最大 50 個の VLAN 条件を指定できます。


(注)  

システムは、各リーフドメインに個別のネットワークマップを作成します。マルチドメイン展開では、実際の VLAN タグを使用してこの設定を抑制すると、予期しない結果になる可能性があります。 上書き対応オブジェクトを使用すると、子孫ドメインの管理者は、グローバル コンフィギュレーションを自分のローカル環境に調整できます。

VLAN 条件が含まれたルール

次のルール タイプでは、VLAN 条件がサポートされます。

  • アクセス コントロール


    (注)  

    アクセスルールの VLAN タグは、インラインセットにのみに適用されます。このタグは、ファイアウォール インターフェイスに適用されるアクセスルールには使用できません。


  • トンネルとプレフィルタ(最も外側の VLAN タグを使用)

  • SSL

  • DNS

  • アイデンティティ

  • ネットワーク分析

ポートおよび ICMP コードの条件

ポート条件を使用することで、トラフィックの送信元および宛先のポートに応じてそのトラフィックを制御できます。ルールのタイプによって、「ポート」は次のいずれかを表します。

  • TCP と UDP:TCP および UDP トラフィックは、トランスポート層プロトコルに基づいて制御できます。システムは、カッコ内に記載されたプロトコル番号 + オプションの関連ポートまたはポート範囲を使用してこの設定を表します。例:TCP(6)/22。

  • ICMP:ICMP および ICMPv6(IPv6 ICMP)トラフィックは、そのインターネット層プロトコルと、オプションでタイプおよびコードに基づいて制御できます。例:ICMP(1):3:3

  • ポートなし:ポートを使用しない他のプロトコルを使用してトラフィックを制御できます。

可能な場合は常に、一致基準を空のままにします(特にセキュリティ ゾーン、ネットワーク オブジェクト、およびポート オブジェクトの場合)。基準を複数指定すると、指定した条件の内容についてすべての組み合わせと照合する必要があります。

ポートベースのルールのベストプラクティス

ポートの指定は、アプリケーションをターゲット指定するための従来の方法です。ただし、アプリケーションは、固有のポートを使用してアクセス コントロール ブロックをバイパスするように設定することが可能です。そのため、可能な場合は常に、ポート基準ではなくアプリケーション フィルタリング基準を使用してトラフィックをターゲット指定します。

アプリケーション フィルタリングは、制御フローとデータフローのために個別のチャネルを動的に開くアプリケーション(FTD など)にも推奨されます。ポートベースのアクセス コントロール ルールを使用すると、これらの種類のアプリケーションが正しく動作しなくなり、望ましい接続がブロックされる可能性があります。

送信元と宛先ポートの制約の使用

送信元ポートと宛先ポートの両方を制約に追加する場合、単一のトランスポート プロトコル(TCP または UDP)を共有するポートのみを追加できます。たとえば、送信元ポートとして DNS over TCP を追加する場合は、宛先ポートとして Yahoo Messenger Voice Chat(TCP)を追加できますが、Yahoo Messenger Voice Chat(UDP)は追加できません。

送信元ポートのみ、あるいは宛先ポートのみを追加する場合は、異なるトランスポート プロトコルを使用するポートを追加できます。たとえば、DNS over TCP および DNS over UDP の両方を 1 つのアクセス コントロール ルールの送信元ポート条件として追加できます。

ポート条件を使用した非 TCP トラフィックの照合

非 TCP トラフィックを照合するためのポート条件を設定することはできますが、いくつかの制約事項があります。

  • アクセス コントロール ルール:クラシック デバイスの場合、GRE でカプセル化されたトラフィックをアクセス コントロール ルールに照合するには、宛先ポート条件として GRE(47)プロトコルを使用します。GRE 制約ルールには、ネットワーク ベースの条件(ゾーン、IP アドレス、ポート、VLAN タグ)のみを追加できます。また、GRE 制約ルールが設定されたアクセス コントロール ポリシーでは、システムが外側のヘッダーを使用してすべてのトラフィックを照合します。Firepower Threat Defense デバイスの場合、GRE でカプセル化されたトラフィックを制御するには、プレフィルタ ポリシーでトンネル ルールを使用します。

  • SSL ルール:SSL ルールは TCP ポート条件のみをサポートします。


  • 注意    

    SSL 復号が無効の場合(つまりアクセス コントロール ポリシーに SSL ポリシーが含まれない場合)に、アクティブな最初の認証ルールを追加するか、アクティブな最後の認証ルールを削除すると 設定の変更を展開する際に Snort プロセスが再起動され、一時的にトラフィックのインスペクションが中断されます。この中断中にトラフィックがドロップされるか、それ以上インスペクションが行われずに受け渡されるかは、ターゲット デバイスがトラフィックを処理する方法に応じて異なります。詳細はSnort® の再起動によるトラフィックの動作を参照してください。

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


  • IMCP エコー:タイプ 0 が設定された宛先 ICMP ポート、またはタイプ 129 が設定された宛先 ICMPv6 ポートは、要求されていないエコー応答だけと照合されます。ICMP エコー要求への応答として送信される ICMP エコー応答は無視されます。ルールですべての ICMP エコーに一致させるには、ICMP タイプ 8 または ICMPv6 タイプ 128 を使用してください。

ポート条件を使用したルール

次のルールは、ポート条件をサポートします。

  • アクセス コントロール

  • プレフィルタ

  • SSL(TCP トラフィックのみをサポート)

  • アイデンティティ(アクティブ認証は TCP トラフィックのみをサポート)

  • QoS

ポート条件の設定

手順

ステップ 1

ルールエディタで、[ポート(Ports)] をクリックします。

ステップ 2

[利用可能なポート(Available Ports)] リストから追加する定義済みポートを見つけて選択します。

ステップ 3

[送信元に追加(Add to Source)] または [宛先に追加(Add to Destination)] をクリックするか、またはドラッグ アンド ドロップします。

ステップ 4

手動で指定する送信元ポートまたは宛先ポートを追加します。

  • 送信元:[プロトコル(Protocol)] を選択し、単一ポートを 0 から 65535 の範囲で入力し、[追加(Add)] をクリックします。
  • [宛先(ICMP 以外)(Destination (non-ICMP))]:プロトコルを選択または入力します。プロトコルを指定したくない場合、あるいは [TCP] または [UDP] を選択した場合、単一ポートを 0 から 65535 の範囲で入力します。[追加(Add)] をクリックします。
  • [宛先(ICMP)(Destination (ICMP))]:[プロトコル(Protocol)] ドロップダウン リストから [ICMP] または [IPv6-ICMP] を選択し、表示されるポップアップ ウィンドウでタイプおよび関連するコードを選択します。ICMP タイプとコードの詳細については、Internet Assigned Numbers Authority(IANA)の Web サイトを参照してください。
ステップ 5

ルールを保存するか、編集を続けます。


次のタスク

カプセル化の条件

カプセル化の条件は、トンネル ルールに固有です。

この条件では、カプセル化プロトコルによって特定のタイプのプレーン テキスト、パススルー トンネルを制御します。ルールを保存する前に、一致するプロトコルを 1 つ以上選択する必要があります。次のオプションを選択できます。

  • GRE(47)

  • IP-in-IP(4)

  • IPv6-in-IP(41)

  • Teredo(UDP(17)/3455)

アプリケーション条件(アプリケーション制御)

システムは IP トラフィックを分析する際、ネットワークで一般的に使用されているアプリケーションを識別および分類できます。このディスカバリベースのアプリケーション認識は、アプリケーション制御、つまりアプリケーション トラフィック制御機能の基本です。

システム提供のアプリケーション フィルタは、アプリケーションの基本特性(タイプ、リスク、ビジネスとの関連性、カテゴリ、およびタグ)にしたがってアプリケーションを整理することで、アプリケーション制御に役立ちます。システム提供のフィルタの組み合わせやアプリケーションの任意の組み合わせをもとに、ユーザー定義の再利用可能フィルタを作成できます。

ポリシーのアプリケーション ルール条件ごとに、少なくとも 1 つのディテクタが有効にされている必要があります。有効になっているディテクタがないアプリケーションについては、システム提供のすべてのディテクタが自動的に有効になります。ディテクタが存在しない場合は、そのアプリケーションについて最後に変更されたユーザー定義ディテクタが有効になります。アプリケーション ディテクタの詳細については、アプリケーション ディテクタの基本を参照してください。

アプリケーション フィルタと個別に指定されたアプリケーションの両方を使用することで、完全なカバレッジを確保できます。ただし、アクセス コントロール ルールの順序を指定する前に、次の注意事項を確認してください。

アプリケーション制御の一部として、コンテンツ規制を適用するアクセス コントロール ルール(セーフ サーチや YouTube EDU など)を使用することもできます。


注意    

アクセス コントロール ルールを適切に設定しないと、ブロックする必要があるトラフィックを含め、予期しない結果が発生する可能性があります。一般的に、アプリケーション制御ルールは、たとえば IP アドレスに基づくルールよりも照合に時間がかかるため、アクセス コントロール リスト内の順位を低くする必要があります。

特定の条件 (ネットワークや IP アドレスなど) を使用するアクセス コントロール ルールは、一般的な条件 (アプリケーションなど) を使用するルールの前にオーダーする必要があります。オープン システム相互接続(OSI)モデルに精通している場合は、考え方として同様の順位付けを使用してください。レイヤ1、2、および 3 (物理、データリンク、およびネットワーク) の条件を持つルールは、アクセス コントロール ルールで最初に注文する必要があります。レイヤ5、6、および 7 (セッション、プレゼンテーション、およびアプリケーション) の条件は、アクセス コントロール ルールの後で順序付けする必要があります。OSI モデルの詳細については、こちらの Wikipedia の記事を参照してください。


アプリケーション フィルタの利点

アプリケーション フィルタにより、迅速にアプリケーション制御を設定できます。たとえば、システム提供のフィルタを使って、リスクが高く、ビジネスとの関連性が低いアプリケーションをすべて認識してブロックするアクセス コントロール ルールを簡単に作成できます。ユーザがそれらのアプリケーションの 1 つを使用しようとすると、システムがセッションをブロックします。

アプリケーション フィルタを使用することで、ポリシーの作成と管理は簡単になります。この方法によりアプリケーション トラフィックが期待どおりに制御されます。シスコは、システムと脆弱性データベース(VDB)の更新を通して、頻繁にアプリケーション ディテクタを更新しています。このため、アプリケーション トラフィックは常に最新のディテクタによってモニタされます。また、独自のディテクタを作成し、どのような特性のアプリケーションを検出するかを割り当て、既存のフィルタを自動的に追加することもできます。

アプリケーション条件の設定

次の表に示す設定を行い、アプリケーション制御を実行します。この表には、設定する内容により、アプリケーション制御にどのような制約を設けることができるかも示します。

設定

タイプ、リスク、関連性、カテゴリ

タグ

ユーザ定義のフィルタ

コンテンツ規制

アクセス コントロール ルール

はい

はい

はい

はい

SSL ルール

はい

No:SSL プロトコル タグによって、自動的に暗号化アプリケーション トラフィックに制約される

いいえ

いいえ

ID ルール(アクティブ認証からアプリケーションを免除)

はい

No:ユーザ エージェント除外タグによって、自動的に制約される

いいえ

いいえ

QoS ルール

はい

はい

はい

いいえ

オブジェクト マネージャ内のユーザ定義のアプリケーション フィルタ

はい

はい

No:ユーザ定義のフィルタのネストは不可

いいえ

インテリジェント アプリケーション バイパス(IAB)

はい

はい

はい

いいえ

アプリケーション条件とフィルタの設定

アプリケーションの条件またはフィルタを作成するには、使用可能なアプリケーションのリストから、トラフィックを制御するアプリケーションを選択します。オプションとして(推奨)、フィルタを使用して使用可能なアプリケーションを抑制します。フィルタと個別に指定されたアプリケーションを同じ条件で使用できます。

始める前に
  • アクセス コントロール ルールでアプリケーション制御を実行するためには、適応型プロファイルの設定 で説明されているように、アダプティブ プロファイルを有効(デフォルト状態)にする必要があります

  • 従来型デバイスモデルの場合、これらの条件を設定するには、制御ライセンスが必要です。

手順

ステップ 1

ルール エディタまたは設定エディタを起動します。

  • アクセスコントロール、SSL、QoS ルール条件:ルールエディタで [アプリケーション(Applications)] をクリックします。
  • アイデンティティルール条件:ルールエディタで [レルムおよび設定(Realms & Settings)] をクリックし、アクティブ認証を有効にします。アイデンティティ ルールの作成を参照してください。
  • アプリケーション フィルタ:オブジェクト マネージャの [アプリケーション フィルタ(Application Filters)] ページで、アプリケーション フィルタを追加または編集します。フィルタの一意の名前を指定します。
  • インテリジェント アプリケーション バイパス(IAB):アクセス コントロール ポリシー エディタで [詳細(Advanced)] をクリックし、IAB の設定を編集して、[バイパス可能なアプリケーションおよびフィルタ(Bypassable Applications and Filters)] をクリックします。
ステップ 2

(オプション)安全検索([安全検索(safe search)] アイコン [安全検索(safe search)] アイコン) または のグレー表示のオプションおよび設定関連のオプションをクリックして、アクセスコントロールルールのコンテンツ制限機能を有効にします。

その他の設定要件については、アクセス コントロール ルールを使用したコンテンツ制限の実施を参照してください。

たいていの場合、コンテンツ制限を有効にすると、条件の [選択されたアプリケーションおよびフィルタ(Selected Applications and Filters)] リストに適切な値が入力されます。コンテンツ制限を有効にするときに、コンテンツ制限に関係するアプリケーションまたはフィルタがすでにリスト内に存在している場合には、システムはリストに自動的に値を入力することはしません。

アプリケーションを絞り込んで選択内容をフィルタする手順を続行するか、またはスキップしてルールの保存に進みます。

ステップ 3

[使用可能なアプリケーション(Available Applications)] リストから追加するアプリケーションを見つけて選択します。

[使用可能なアプリケーション(Available Applications)] に表示されるアプリケーションを抑制するには、1 つ以上のアプリケーション フィルタを選択するか、個別のアプリケーションを検索します。

ヒント 

サマリー情報とインターネットの検索リンクを表示するには、アプリケーションの横の [情報(Information)](情報アイコン をクリックします。ロック解除 は、システムが復号されたトラフィックでのみ識別できるアプリケーションを示します。

フィルタを単独または組み合わせて選択すると、[使用可能なアプリケーション(Available Applications)] リストが更新され、条件を満たすアプリケーションのみが表示されます。システムによって提供されるフィルタは組み合わせて選択できますが、ユーザ定義フィルタはできません。

  • 同じ特性(リスク、ビジネス関連性など)の複数のフィルタ:アプリケーション トラフィックは 1 つのフィルタのみに一致する必要があります。たとえば、中リスク フィルタと高リスク フィルタの両方を選択すると、[使用可能なアプリケーション(Available Applications)] リストにすべての中リスク アプリケーションと高リスク アプリケーションが表示されます。

  • 異なるアプリケーション特性のフィルタ:アプリケーション トラフィックは、両方のフィルタ タイプに一致する必要があります。たとえば、高リスク フィルタとビジネスとの関連性が低いフィルタの両方を選択すると、[使用可能なアプリケーション(Available Applications)] リストに両方の条件を満たすアプリケーションのみが表示されます。

ステップ 4

[ルールに追加(Add to Rule)] をクリックするか、ドラッグ アンド ドロップします。

ヒント 

フィルタとアプリケーションをさらに追加する前に、[フィルタのクリア(Clear Filters)] をクリックして現在の選択をクリアします。

Web インターフェイスでは、条件に追加されたフィルタは上部にリストされ、個別に追加されたアプリケーションとは分けられます。
ステップ 5

ルールまたは設定を保存するか、編集を続けます。


例:アクセス コントロール ルールのアプリケーション条件

次の図は、MyCompany のユーザー定義アプリケーション フィルタ、リスクが高くビジネスとの関連性が低いすべてのアプリケーション、ゲーム アプリケーション、および個々に選択されたいくつかのアプリケーションをブロックするアクセス コントロール ルールのアプリケーション条件を示しています。

サンプル アプリケーション条件のスクリーンショット

次のタスク

アプリケーションの特性

システムは、次の表に示す基準を使用して、検出された各アプリケーションの特性を判別します。これらの特性をアプリケーション フィルタとして使用します。

表 1. アプリケーションの特性

特性

説明

タイプ

アプリケーション プロトコルは、ホスト間の通信を意味します。

クライアントは、ホスト上で動作しているソフトウェアを意味します。

Web アプリケーションは、HTTP トラフィックの内容または要求された URL を意味します。

HTTP と SSH はアプリケーション プロトコルです。

Web ブラウザと電子メール クライアントはクライアントです。

MPEG ビデオと Facebook は Web アプリケーションです。

リスク(Risk)

アプリケーションが組織のセキュリティ ポリシーに違反することがある目的で使用される可能性。

ピアツーピア アプリケーションはリスクが極めて高いと見なされます。

ビジネスとの関連性(Business Relevance)

アプリケーションが、娯楽目的ではなく、組織のビジネス活動の範囲内で使用される可能性。

ゲーム アプリケーションはビジネスとの関連性が極めて低いと見なされます。

カテゴリ(Category)

アプリケーションの最も不可欠な機能を表す一般的な分類。各アプリケーションは、少なくとも 1 つのカテゴリに属します。

Facebook はソーシャル ネットワーキングのカテゴリに含まれます。

タグ

アプリケーションに関する追加情報。アプリケーションには任意の数のタグを付けることができます(タグなしも可能)。

ビデオ ストリーミング Web アプリケーションには、ほとんどの場合、high bandwidthdisplays ads というタグが付けられます。

アプリケーション制御のベストプラクティス

アプリケーション制御に関する次の注意事項と制約事項に注意してください。

アダプティブ プロファイルが有効になっていることの確認

アダプティブ プロファイルが無効な場合(デフォルト状態)、アクセス制御ルールは、アプリケーション制御を実行できません。

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

ディテクタが検出対象のアプリケーションに対して有効でない場合、システムは、そのアプリケーションに対応するシステム提供のすべてのディテクタを自動的に有効にします。存在しない場合、システムはそのアプリケーション対応で最近変更されたユーザー定義のディテクタを有効にします。

アプリケーションを識別する前に通過する必要のあるパケットを調べるためのポリシーの設定

システムは、次の両方の条件が満たされるまで、インテリジェント アプリケーション バイパス(IAB)およびレート制限を含むアプリケーション制御を実行できません。

  • モニター対象の接続がクライアントとサーバーの間で確立される。

  • システムがセッションでアプリケーションを識別する

この識別は 3 ~ 5 パケット以内で、またはトラフィックが暗号化されている場合は、SSL ハンドシェイクのサーバー証明書交換の後に行われる必要があります。

重要これらの初期パケットをシステムが確実に調べるようにするには、トラフィック識別の前に通過するパケットを処理するためのポリシーの指定を参照してください。

早期のトラフィックがその他のすべての基準に一致するが、アプリケーション識別が不完全な場合、システムは、パケットの受け渡しと接続の確立(または、SSL ハンドシェイクの完了)を許可します。システムは識別を完了した後、残りのセッション トラフィックに適切なアクションを適用します。

URL とアプリケーションのフィルタリング用の個別のルールの作成

アプリケーションと URL の基準を組み合わせることで、予期しない結果が生じることがある(特に暗号化されたトラフィックの場合)ため、可能な限り、URL とアプリケーションのフィルタリング用に個別のルールを作成します。

アプリケーションと URL の基準の両方を含むルールは、より一般的なアプリケーションのみまたは URL のみのルールの例外として機能している場合を除き、アプリケーションのみまたは URL のみのルールの後に来る必要があります。

アプリケーションや他のルールより前に配置される URL ルール

URL マッチングを最も効果的に行うには、URL 条件を含むルールを他のルールより前に配置します。特に、URL ルールがブロック ルールで、他のルールが次の条件を両方とも満たす場合には、URL 条件を含むルールを前に配置します。

  • その他のルールがアプリケーション条件を含んでいる。

  • 検査対象のトラフィックが暗号化されている。

暗号化および復号トラフィックのアプリケーション制御

システムは暗号化トラフィックと復号トラフィックを識別し、フィルタ処理することができます。

  • 暗号化トラフィック:システムは、SMTPS、POPS、FTPS、TelnetS、IMAPS を含む StartTLS で暗号化されたアプリケーション トラフィックを検出できます。さらに、TLS ClientHello メッセージの Server Name Indication、またはサーバー証明書のサブジェクト識別名の値に基づいて、特定の暗号化されたアプリケーションを識別できます。これらのアプリケーションに SSL Protocol タグが付けられます。SSL ルールでは、これらのアプリケーションのみを選択できます。このタグがないアプリケーションは、暗号化されていないまたは復号されたトラフィックでのみ検出できます。

  • 復号トラフィック:システムは、復号されたトラフィック(暗号化されたまたは暗号化されていないトラフィックではなく)のみで検出を行うことができるアプリケーションに decrypted traffic タグを割り当てます。

アプリケーションのアクティブ認証の免除

アイデンティティ ポリシーでは、特定のアプリケーションのアクティブ認証を免除し、トラフィックにアクセス コントロールの続行を許可できます。これらのアプリケーションには、User-Agent Exclusion タグが付けられます。アイデンティティ ルールでは、これらのアプリケーションのみを選択できます。

ペイロードのないアプリケーション トラフィック パケットの処理

アクセス コントロールを実行している場合、システムは、アプリケーションが識別された接続内にペイロードがないパケットに対してデフォルト ポリシー アクションを適用します。

参照されるアプリケーション トラフィックの処理

アドバタイズメント トラフィックなどの Web サーバーによって参照されるトラフィックを処理するには、参照しているアプリケーションではなく、参照されるアプリケーションを照合します。

複数のプロトコルを使用するアプリケーション トラフィックの制御(Skype、Zoho)

一部のアプリケーションは、複数のプロトコルを使用します。このようなアプリケーションのトラフィックを制御するには、関連するすべてのオプションがアクセス コントロール ポリシーの対象となっていることを確認します。次に例を示します。

  • Skype:Skype のトラフィックを制御するには、個々のアプリケーションを選択するのではなく、[アプリケーションフィルタ(Application Filters)] リストから [Skype] タグを選択します。これにより、システムは同じ方法で Skype のすべてのトラフィックを検出して制御できるようになります。

  • Zoho:Zoho メールを制御するには、[使用可能なアプリケーション(Available Application)] リストから [Zoho] と [Zohoメール(Zoho mail)] の両方を選択します。

コンテンツ制限機能用にサポートされる検索エンジン

システムは、特定の検索エンジンの場合のみ、セーフ サーチ フィルタリングをサポートします。システムは、これらの検索エンジンからのアプリケーション トラフィックに safesearch supported タグを割り当てます。

回避的アプリケーション トラフィックの制御

用途別の注意事項と制限事項を参照してください。

アプリケーション制御のルールの順位付けに関するその他のガイドライン

アプリケーション コントロール ルールの順位付けに関するガイドラインについては、アプリケーション制御の設定のベストプラクティスを参照してください。

アプリケーション制御の設定のベストプラクティス

アプリケーションによるネットワークへのアクセスを次のように制御することをお勧めします。

  • 安全性の低いネットワークからより安全なネットワークへのアプリケーションアクセスを許可またはブロックするには、アクセス コントロール ルールでポート(選択された宛先ポート) 条件を使用します。

    たとえば、インターネット(安全性が低い)から内部ネットワーク(安全性が高い)への ICMP トラフィックを許可します。

  • ユーザーグループによってアクセスされるアプリケーションを許可またはブロックするには、アクセス コントロール ルールでアプリケーション条件を使用します。

    たとえば、契約業者グループのメンバーによる Facebook へのアクセスをブロックします。


注意    

アクセス コントロール ルールを適切に設定しないと、ブロックする必要があるトラフィックを含め、予期しない結果が発生する可能性があります。一般的に、アプリケーション制御ルールは、たとえば IP アドレスに基づくルールよりも照合に時間がかかるため、アクセス コントロール リスト内の順位を低くする必要があります。

特定の条件 (ネットワークや IP アドレスなど) を使用するアクセス コントロール ルールは、一般的な条件 (アプリケーションなど) を使用するルールの前にオーダーする必要があります。オープン システム相互接続(OSI)モデルに精通している場合は、考え方として同様の順位付けを使用してください。レイヤ1、2、および 3 (物理、データリンク、およびネットワーク) の条件を持つルールは、アクセス コントロール ルールで最初に注文する必要があります。レイヤ5、6、および 7 (セッション、プレゼンテーション、およびアプリケーション) の条件は、アクセス コントロール ルールの後で順序付けする必要があります。OSI モデルの詳細については、こちらの Wikipedia の記事を参照してください。


次の表に、アクセス コントロール ルールを設定する方法の例を示します。

コントロールの種類

操作

ゾーン、ネットワーク、VLAN タグ

ユーザ

アプリケーション

ポート

URL

SGT/ISE 属性

インスペクション、ロギング、コメント

アプリケーションがポート(SSH など)を使用する場合の、安全性の高いネットワークから安全性の低いネットワークへのアプリケーション

お客様の選択(この例では [許可(Allow)])

外部インターフェイスを使用する宛先ゾーンまたはネットワーク

任意

設定しない

使用可能なポート:SSH

[選択した宛先ポート(Selected Destination Port)] に追加

任意

ISE/ISE-PIC でのみ使用。

任意

アプリケーションがポートを使用していない場合の(ICMP など)、安全性の高いネットワークから安全性の低いネットワークへのアプリケーション

お客様の選択(この例では [許可(Allow)])

外部インターフェイスを使用する宛先ゾーンまたはネットワーク

任意

設定しない

選択された宛先ポート プロトコル:ICMP

タイプAny

設定しない

ISE/ISE-PIC でのみ使用。

任意

ユーザー グループによるアプリケーション アクセス

お客様の選択(この例では [ブロック(Block)])

お客様の選択

ユーザー グループ(この例では契約業者グループ)を選択。

アプリケーションの名前(この例では [Facebook])を選択。

設定しない

設定しない

ISE/ISE-PIC でのみ使用。

お客様の選択

用途別の注意事項と制限事項

  • Office 365 管理者用ポータル:

    制限:アクセス ポリシーのロギングが最初と最後で有効になっている場合、最初のパケットは Office 365 として検出され、接続の終了は Office 365 管理者用ポータルとして検出されます。これがブロッキングに影響を与えないようにする必要があります。

  • Skype:

    アプリケーション制御のベストプラクティスを参照してください

  • GoToMeeting

    GoToMeeting を完全に検出するには、ルールに次のすべてのアプリケーションが含まれている必要があります。

    • GoToMeeting

    • Citrix Online

    • Citrix GoToMeeting プラットフォーム

    • LogMeIn

    • STUN

  • Zoho:

    アプリケーション制御のベストプラクティスを参照してください

  • Bittorrent、Tor、Psiphon、および Ultrasurf などの回避的なアプリケーションの場合:

    回避的なアプリケーションの場合、デフォルトでは、信頼性の高いシナリオのみが検出されます。このトラフィックに対するアクション(ブロックや QoS の実装など)を実行する必要がある場合、より効果の高い、さらに積極的な検出の設定が必要なことがあります。これを実行する場合、設定の変更によって誤検出が発生する可能性がありますので、TAC に問い合わせて設定を確認してください 。

  • WeChat:

    WeChat を許可する場合、WeChat のメディアを選択的にブロックすることはできません。

アプリケーション制御ルールのトラブルシューティング

アプリケーション コントロール ルールが予想どおりに機能しない場合は、このセクションで説明されているガイドラインを確認してください。

アプリケーションによるネットワークへのアクセスを次のように制御することをお勧めします。

  • 安全性の低いネットワークからより安全なネットワークへのアプリケーションアクセスを許可またはブロックするには、アクセス コントロール ルールでポート(選択された宛先ポート) 条件を使用します。

    たとえば、インターネット(安全性が低い)から内部ネットワーク(安全性が高い)への ICMP トラフィックを許可します。

  • ユーザーグループによってアクセスされるアプリケーションを許可またはブロックするには、アクセス コントロール ルールでアプリケーション条件を使用します。

    たとえば、契約業者グループのメンバーによる Facebook へのアクセスをブロックします。


注意    

アクセス コントロール ルールを適切に設定しないと、ブロックする必要があるトラフィックを含め、予期しない結果が発生する可能性があります。一般的に、アプリケーション制御ルールは、たとえば IP アドレスに基づくルールよりも照合に時間がかかるため、アクセス コントロール リスト内の順位を低くする必要があります。

特定の条件 (ネットワークや IP アドレスなど) を使用するアクセス コントロール ルールは、一般的な条件 (アプリケーションなど) を使用するルールの前にオーダーする必要があります。オープン システム相互接続(OSI)モデルに精通している場合は、考え方として同様の順位付けを使用してください。レイヤ1、2、および 3 (物理、データリンク、およびネットワーク) の条件を持つルールは、アクセス コントロール ルールで最初に注文する必要があります。レイヤ5、6、および 7 (セッション、プレゼンテーション、およびアプリケーション) の条件は、アクセス コントロール ルールの後で順序付けする必要があります。OSI モデルの詳細については、こちらの Wikipedia の記事を参照してください。


次の表に、アクセス コントロール ルールを設定する方法の例を示します。

コントロールの種類

操作

ゾーン、ネットワーク、VLAN タグ

ユーザ

アプリケーション

ポート

URL

SGT/ISE 属性

インスペクション、ロギング、コメント

アプリケーションがポート(SSH など)を使用する場合の、安全性の高いネットワークから安全性の低いネットワークへのアプリケーション

お客様の選択(この例では [許可(Allow)])

外部インターフェイスを使用する宛先ゾーンまたはネットワーク

任意

設定しない

使用可能なポート:SSH

[選択した宛先ポート(Selected Destination Port)] に追加

任意

ISE/ISE-PIC でのみ使用。

任意

アプリケーションがポートを使用していない場合の(ICMP など)、安全性の高いネットワークから安全性の低いネットワークへのアプリケーション

お客様の選択(この例では [許可(Allow)])

外部インターフェイスを使用する宛先ゾーンまたはネットワーク

任意

設定しない

選択された宛先ポート プロトコル:ICMP

タイプAny

設定しない

ISE/ISE-PIC でのみ使用。

任意

ユーザー グループによるアプリケーション アクセス

お客様の選択(この例では [ブロック(Block)])

お客様の選択

ユーザー グループ(この例では契約業者グループ)を選択。

アプリケーションの名前(この例では [Facebook])を選択。

設定しない

設定しない

ISE/ISE-PIC でのみ使用。

お客様の選択

初期パケットが検査されずに渡される

トラフィック識別の前に通過するパケットのインスペクション」およびサブトピックを参照してください。

URL 条件(URL フィルタリング)

URL 条件を使用してネットワークのユーザーがアクセスできる Web サイトを制御します。

詳細については、URL フィルタリングを参照してください。

ユーザー条件、レルム条件、および ISE 属性条件(ユーザー制御)

Firepower システムによって収集された権限のあるユーザ アイデンティティ データを使用してユーザ制御を実行することができます。

アイデンティティ ソースはユーザがログインまたはログアウトする際、または Microsoft Active Directory(AD)または LDAP のクレデンシャルを使用して認証する際にユーザをモニタします。次に、この収集されたアイデンティティ データを使用して、モニタ対象ホストに関連付けられているログインしている権限のあるユーザに基づいてトラフィックを処理するルールを設定できます。ユーザは、そのユーザがログオフする(アイデンティティ ソースによって報告される)か、レルムがセッションをタイムアウトするか、システムのデータベースからそのユーザ データが削除されるまで、ホストに関連付けられたままになります。

Firepower システムのご使用のバージョンでサポートされる権限のあるユーザ アイデンティティ ソースについては、ユーザー アイデンティティ ソースについてを参照してください。

ユーザ制御を実行するために、次のルール条件を使用できます。

  • ユーザ条件およびレルム条件:ホストのログインしている権限のあるユーザに基づいてトラフィックを照合します。トラフィックは、レルム、個々のユーザ、またはそれらのユーザが属しているグループに基づいて制御できます。

  • ISE 属性条件:ユーザの、ISE が割り当てたセキュリティ グループ タグ(SGT)、デバイス タイプ(エンドポイント プロファイルとも呼ばれる)、またはロケーション IP(エンドポイント ロケーションとも呼ばれる)に基づいてトラフィックを照合します。ISE をアイデンティティ ソースとして設定する必要があります。


    (注)  

    ISE-PIC アイデンティティ ソースでは、ISE 属性データを提供しません。



(注)  

一部のルールでは、カスタム SGT 条件が ISE によって割り当てられなかった SGT 属性にタグ付けされたトラフィックを照合できます。これはユーザ制御とはみなされず、ISE をアイデンティティ ソースとして使用していない場合にのみ機能します。カスタム SGT 条件を参照してください。

ユーザ条件を持つルール

ルール タイプ

ユーザ条件およびレルム条件のサポート

ISE 属性条件のサポート

アクセス コントロール

はい

はい

SSL

はい

いいえ

QoS

はい

はい

SGT 照合は送信元の一致基準としてのみサポートされ、宛先の一致基準としてはサポートされません

ユーザー制御の前提条件

アイデンティティ ソース/認証方式の設定

実行する認証タイプのアイデンティティ ソースを設定します。詳細については、ユーザー アイデンティティ ソースについてを参照してください。

ISE/ISE-PIC 、ユーザーエージェント、または TS エージェントデバイスのモニター対象に多くのユーザーグループを設定した場合、またはネットワークでホストにマップされるユーザー数が非常に多い場合、Firepower Management Center のユーザー制限が原因で、システムがグループに基づいてユーザーマッピングをドロップすることがあります。その結果、レルム、ユーザー、またはユーザー グループの条件のルールが、一致することが想定されているトラフィックと一致しなくなる可能性があります。

レルムの設定

監視対象の各 AD または LDAP サーバー(ISE/ISE-PIC、ユーザーエージェント、および TS エージェントサーバーを含む)のレルムを設定し、ユーザーのダウンロードを実行します。詳細については、レルムおよびレルムディレクトリの作成を参照してください。


(注)  

ISE SGT 属性ルール条件を設定する場合、レルムの設定は任意です。ISE SGT 属性ルール条件は、アイデンティティ ポリシー(レルムの呼び出し元)が関連付けられているかどうかにかかわらず、ポリシー内で設定できます。


レルムを設定するときには、アクティビティを監視するユーザおよびユーザ・グループを指定します。ユーザ グループを含めると、自動的に、すべてのセカンダリ グループのメンバーを含む、そのグループのすべてのメンバーが含まれます。ただし、セカンダリ グループをルール条件として使用する場合は、セカンダリ グループをレルム構成に明示的に含める必要があります。

レルムごとに、ユーザ データの自動ダウンロードを有効にすると、ユーザおよびユーザ グループの信頼できるデータを更新することができます。

アイデンティティ ポリシーの作成

レルムを認証方式に関連付けるアイデンティティ ポリシーを作成し、そのポリシーをアクセス制御に関連付けます。詳細については、アイデンティティ ポリシーの作成を参照してください。

デバイスのユーザ制御(アクセス制御、SSL、QoS)を実行するポリシーは、アイデンティティ ポリシーを共有します。そのアイデンティティ ポリシーによって、それらのデバイス上のトラフィックに影響するルールで使用できるレルム、ユーザ、およびグループが決まります。

QoS ルールでユーザー条件を設定する前に、QoS ポリシーの対象となるデバイスが、デバイスに適用されたアクセス制御ポリシーで定義されている正しいアイデンティティ ポリシーを使用していることを確認する必要があります。同じデバイスに適用された QoS ポリシーとアクセス制御ポリシーは明示的にリンクされていないため、QoS ルール エディタで無効なレルム、ユーザ、およびグループを選択することが可能です。これらの無効な要素は、Firepower Management Center に存在するが、QoS 対象のデバイスには適用されないアイデンティティ ポリシーから取得された要素です。これらの要素を使用すると、実際に適用されるまで、無効な選択をしたことが判別されません。

ユーザーおよびレルム条件の設定

レルム、またはそのレルム内のユーザとユーザ グループでルールを制約できます。

始める前に
手順

ステップ 1

ルールエディタで、[ユーザー(Users)] をクリックします。

ステップ 2

(オプション)[利用可能なレルム(Available Realms)] リストから使用するレルムを見つけて選択します。

ステップ 3

(オプション)[有効なユーザ(Available Users)] リストからユーザとグループを選択して、ルールをさらに制約します。

ステップ 4

[ルールに追加(Add to Rule)] をクリックするか、ドラッグ アンド ドロップします。

ステップ 5

ルールを保存するか、編集を続けます。


次のタスク

ISE 属性条件の設定

始める前に
手順

ステップ 1

ルールエディタで、ISE 属性条件に関して次をクリックします。

  • アクセスコントロール:[SGT/ISE 属性(SGT/ISE Attributes)] をクリックします。

ISE 属性条件を制約するために、ISE 割り当てセキュリティ グループ タグ(SGT)を使用できます。アクセス コントロール ルールでカスタム SGT を使用するには、カスタム SGT 条件を参照してください。

ステップ 2

[使用可能な属性(Available Attributes)] リストから、使用する ISE 属性を見つけて選択します。

  • [セキュリティ グループ タグ(SGT)(Security Group Tag (SGT))]

  • [デバイス タイプ(Device Type)](エンドポイント プロファイルとも呼ばれます)

  • QoS:[ISE 属性(ISE Attributes)] をクリックします。
  • [ロケーション IP(Location IP)](エンドポイント ロケーションとも呼ばれます)

ステップ 3

[使用可能な ISE メタデータ(AvailableISE Metadata)] [使用可能なメタデータ(Available Metadata)] リストから属性メタデータを選択して、さらにルールを制約します。または、デフォルトの [すべて(any)] のままにします:

ステップ 4

[ルールに追加(Add to Rule)] をクリックするか、ドラッグ アンド ドロップします。

ステップ 5

(オプション)[ロケーション IP アドレスの追加(Add a Location IP Address)] フィールドで、IP アドレスによりルールを制約し、[追加(Add)] をクリックします。

システムは、各リーフドメインに個別のネットワークマップを作成します。マルチドメイン展開では、実際の IP アドレスを使用してこの設定を抑制すると、予期しない結果になる可能性があります。

ステップ 6

ルールを保存するか、編集を続けます。


次のタスク

ユーザー制御のトラブルシューティング

ユーザー ルールの予期しない動作に気付いたら、ルール、アイデンティティ ソース、またはレルムの設定を調整することを検討してください。その他の関連するトラブルシューティング情報については、以下を参照してください。

レルム、ユーザー、またはユーザー グループを対象とするルールがトラフィックと一致しない

TS エージェント、ユーザーエージェント、または ISE/ISE-PIC デバイスのモニター対象に多くのユーザーグループを設定した場合、またはネットワークでホストにマップされるユーザー数が非常に多い場合、Firepower Management Center のユーザー制限が原因で、システムがユーザーレコードをドロップすることがあります。その結果、ユーザー条件のルールが、一致することが想定されているトラフィックと一致しない可能性があります。

ユーザ グループまたはユーザ グループ内のユーザを対象とするルールが、一致することが想定されているトラフィックと一致しない

ユーザ グループ条件を含むルールを設定する場合は、LDAP または Active Directory サーバでユーザ グループを設定している必要があります。サーバが基本的なオブジェクト階層でユーザを整理している場合、システムはユーザ グループ制御を実行できません。

セカンダリ グループ内のユーザを対象とするルールが、一致することが想定されているトラフィックと一致しない

Active Directory サーバのセカンダリ グループのメンバーであるユーザを含めるか除外するユーザ グループ条件を含むルールを設定する場合、サーバは報告するユーザの数を制限していることがあります。

デフォルトでは、Active Directory サーバはセカンダリ グループから報告するユーザの数を制限します。この制限は、セカンダリ グループ内のすべてのユーザが Firepower Management Center に報告され、ユーザ条件を含むルールでの使用に適するようにカスタマイズする必要があります。

ルールが、初めて表示されたユーザと一致しない

システムは、以前に表示されていないユーザからのアクティビティを検出すると、サーバからそれらのユーザに関する情報を取得します。システムがこの情報を正常に取得するまで、このユーザに表示されるアクティビティは、一致するルールによって処理されません。代わりに、ユーザー セッションが、一致する次のルール(または該当する場合はポリシーのデフォルト アクション)によって処理されます。

たとえば、次のような状況が考えられます。

  • ユーザー グループのメンバーであるユーザーが、ユーザー グループ条件を含むルールに一致しない。

  • ユーザーデータの取得に使用されたサーバーが Active Directory サーバーである場合、TS エージェント、ユーザーエージェント、または ISE/ISE-PIC デバイスによって報告されたユーザーがルールと一致しない。

これにより、システムがユーザー データをイベント ビューおよび分析ツールに表示するのが遅れる可能性があることに注意してください。

ルールがすべての ISE ユーザーと一致しない

これは想定されている動作です。Active Directory ドメイン コントローラで認証された ISE ユーザに対してユーザ制御を実行することができます。LDAP、RADIUS、または RSA ドメイン コントローラで認証された ISE ユーザに対するユーザ制御は実行できません。

ルールがすべての ISE/ISE-PIC ユーザと一致しない

これは想定されている動作です。Active Directory ドメイン コントローラで認証された ISE/ISE-PIC ユーザに対してユーザ制御を実行することができます。LDAP、RADIUS、または RSA ドメイン コントローラで認証された ISE/ISE-PIC ユーザーに対するユーザー制御は実行できません。

ユーザーとグループによる大量のメモリの使用

ユーザーとグループの処理によって大量のメモリが使用されている場合、/var/log/messages に次のようなメッセージが表示されます。

UserGroup [WARN] User/Group mem usage is above 80 percent

別のメッセージには、ユーザーとグループによって使用されているメモリのパーセンテージが表示されます。

こうしたメッセージの表示が続く場合には、次のオプションのいずれかを実行できます。

  • アクセス コントロール ポリシーによって処理されるユーザを制限します。

  • 管理対象デバイスをメモリが大きなモデルにアップグレードします。

カスタム SGT 条件

ID ソースとして ISE/ISE-PIC を設定しない場合、ISE によって指定されていないセキュリティ グループ タグ(SGT)使用してトラフィックを制御できます。SGT は、信頼ネットワーク内での、トラフィックの送信元の権限を指定します。

カスタム SGT ルールの条件では、システムが ISE サーバとの接続によって取得した ISE SGT ではなく、手動で作成された SGT オブジェクトを使ってトラフィックをフィルタ処理します。この手動で作成された SGT オブジェクトは、制御するトラフィックの SGT 属性に対応します。カスタム SGT を使用したトラフィック制御は、ユーザ制御とは見なされません。

カスタム SGT 条件を持つルール

次のルールがカスタム SGT 条件をサポートしています。

  • アクセス コントロール

  • QoS

ISE SGT とカスタム SGT ルール条件との比較

ルールの中には、割り当てられた SGT に基づいてトラフィックを制御するために使用できるものがあります。ルールのタイプ、およびアイデンティティ ソースの設定によって、ISE 割り当ての SGT またはカスタム SGT のいずれかを使用して、トラフィックを割り当て済み SGT 属性と照合することができます。


(注)  

ISE SGT を使用してトラフィックを照合する場合、パケットに SGT 属性が割り当てられていないとしても、パケットの送信元 IP アドレスが ISE 内で既知であれば、そのパケットは ISE SGT ルールと照合されます。

条件タイプ

要件

ルール エディタにリストされている SGT

ISE SGT

ISE アイデンティティ ソース

ISE サーバをクエリして取得され、メタデータが自動的に更新される SGT

カスタム SGT

ISE/ISE-PIC アイデンティティ ソースなし

ユーザーが作成するスタティック SGT オブジェクト

カスタム セキュリティ グループ タグ(SGT)から ISE セキュリティ グループ タグ(SGT)への自動遷移

カスタム SGT に一致するルールを作成し、ISE/ISE-PIC を ID ソースに設定すると、システムは次の動作をします。

  • オブジェクト マネージャの [セキュリティ グループ タグ(Security Group Tag)] オプションを無効にします。システムは既存の SGT オブジェクトをそのまま保持しますが、それらの変更や、新しいオブジェクトの追加はできません。

  • カスタム SGT 条件の既存のルールを保持します。ただし、これらのルールはトラフィックの照合を行いません。また、既存のルールにカスタム SGT 基準を追加することや、カスタム SGT 条件を含む新しいルールを作成することはできません。

ISE を設定する場合は、カスタム SGT 条件を含む既存のルールは削除するか、無効にすることを推奨します。SGT 属性を持つトラフィックを照合するには、代わりに ISE 属性条件を使用します。

カスタム SGT 条件の設定

次の手順では、ISE によって割り当てられていない SGT 属性がタグ付けされたトラフィックをフィルタ処理する方法を説明します。これはユーザー制御とみなされず、アイデンティティ ソースとして ISE/ISE-PIC を使用しない場合にのみ機能します。ISE SGT とカスタム SGT ルール条件との比較を参照してください。

始める前に
  • ISE/ISE-PIC 接続を無効にします。カスタム SGT の照合は、アイデンティティ ソースとして ISE/ISE-PIC を使用する場合、機能しません。

  • 一致させる SGT に対応するセキュリティ グループ タグ オブジェクトを設定します。セキュリティ グループ タグ オブジェクトの作成を参照してください。

  • 従来型デバイスモデルの場合、これらの条件を設定するには、制御ライセンスが必要です。

手順

ステップ 1

ルールエディタで、[SGT/ISE属性(SGT/ISE Attributes)] をクリックします。

ステップ 2

[使用可能な属性(Available Attributes)] リストから [セキュリティ グループ タグ(Security Group Tag)] を選択します。

ステップ 3

[使用可能なメタデータ(Available Metadata)] リストで、カスタム SGT オブジェクトを見つけて選択します。

[すべて(Any)] を選択すると、ルールは SGT 属性があるすべてのトラフィックと一致します。たとえば、この値は、TrustSec 向けに構成されていないホストからのトラフィックをブロックするアクセス コントロール ルールが必要な場合に選択できます。

ステップ 4

[ルールに追加(Add to Rule)] をクリックするか、ドラッグ アンド ドロップします。

ステップ 5

ルールを保存するか、編集を続けます。


次のタスク

カスタム SGT 条件のトラブルシューティング

予期しないルールの動作に気付いたら、カスタム SGT オブジェクトの設定を調整することを検討してください。

使用不可のセキュリティ グループ タグ オブジェクト

カスタム SGT オブジェクトは、ISE/ISE-PIC をアイデンティティ ソースとして設定していない場合にのみ使用できます。詳細については、カスタム セキュリティ グループ タグ(SGT)から ISE セキュリティ グループ タグ(SGT)への自動遷移を参照してください。

ルールの検索

多くのポリシーでは、ルールとルール内の検索が可能です。システムは、入力内容をルールの名前および条件値と照合します。これには、オブジェクトとオブジェクト グループが含まれます。

セキュリティ インテリジェンスまたは URL のリストまたはフィードに含まれる値は検索できません。

手順


ステップ 1

ポリシーエディタで、[ルール(Rules)] をクリックします。

ステップ 2

[ルールの検索(Search Rules)] をクリックし、完全なまたは部分的な検索文字列を入力して、Enter キーを押します。

照合ルールごとに、一致する値が強調表示されます。ステータス メッセージには、現行の一致および合計一致数が表示されます。
ステップ 3

目的のルールを表示します。

照合ルールの間を移動するには、[次の一致(Next-Match)] または [前の一致(Previous-Match)] をクリックします。

(アクセスコントロールルールのみ)一致するルールのみのリスト、または一致するルールが強調表示されているすべてのルールのリストを表示するには、次をクリックします: 検索ルール ([検索ルール(search rules)] アイコン )


次のタスク

  • 新しい検索を開始する前に、 をクリックして、検索と強調表示をクリアします。

デバイス別のフィルタリング ルール

一部のポリシー エディタでは、該当デバイスによってルールの表示をフィルタ処理することができます。

デバイス別のフィルタは、ゾーンまたはインターフェイスグループを使用するルールに対してのみ機能します(それ以外の場合、ルールはすべてのデバイスに適用されます)。

システムは、ルールがそのデバイスに影響するかどうかを判断するために、ルールのインターフェイス制約を使用します。インターフェイス(セキュリティ ゾーンまたはインターフェイス グループの条件)でルールを制約すると、インターフェイスが置かれている場所のデバイスがそのルールの影響を受けます。インターフェイス制約のないルールは、すべてのインターフェイスに適用されるので、すべてのデバイスに適用されることになります。

QoS ルールは、常にインターフェイスで制約されます。

手順


ステップ 1

ポリシーエディタで、[ルール(Rules)] をクリックし、[デバイスでフィルタ処理(Filter by Device)] をクリックします。

ターゲット デバイスとデバイス グループのリストが表示されます。
ステップ 2

1 つまたは複数のチェック ボックスをオンにして、これらのデバイスまたはグループに適用されるルールだけを表示します。または、[すべて(All)] をオンにしてリセットし、すべてのルールを表示します。

ヒント 

ポインタをルール基準に合わせると、その値が表示されます。基準がデバイス特有のオーバーライドを持つオブジェクトを表し、そのデバイスだけでルール リストをフィルタ処理する場合、システムはオーバーライド値を表示します。基準がドメイン特有のオーバーライドを持つオブジェクトを表し、そのドメインのデバイスでルール リストをフィルタ処理する場合、システムはオーバーライド値を表示します。

ステップ 3

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


ルールの問題を特定

展開を防ぐルール(赤色のアイコンでマーく)か、または別のルールがルールの順序で上にあるためにトラフィックが一致することがないルール(黄色のアイコンでマーク)のそれぞれに、システムはフラグを設定します。


重要

他のルールに部分的に一致するルールにはフラグが付けられないため、後続の一部のルールが一致しない場合もあります。


手順


ステップ 1

[ポリシー(Policies)] > [アクセス制御(Access Control)] > [アクセス制御(Access Control)] を選択します。

ステップ 2

ポリシー名をクリックします。

ステップ 3

次のいずれかまたは両方を実行します。

  • ウィンドウの上部近くで [警告の表示(Show Warnings)] を探します。

    システムで問題が特定されていない場合、このボタンは表示されません。

    問題がある場合は、このボタンをクリックして問題があるすべてのルールのリストを開きます。

    すべての問題を表示するには、両方のタブ ([ルール エラー(Rule Errors)] と[ルールの警告(Rule Warnings)]) をクリックします。

    下にあるルールのテーブル内からルールを見つけるには、[エラー(Error)] または [警告(Warning)] リストでルール名をクリックします。

  • [ルール競合の表示(Show Rule Conflicts)] チェックボックスをオンにします。

    これにより、リスト内で問題があるルールがエラー(赤色)または警告(黄色)で示されます。

    必要に応じて、ポリシー内のすべてのルールを確認するまで下にスクロールします。

ステップ 4

問題の詳細を表示するには、アイコンの上にポインタを置きます。

ステップ 5

部分一致のみであるためフラグが付けられていない重複を検索して対処します。

ステップ 6

変更した場合は、[保存(Save)] をクリックするか、または [ルール競合の表示(Show Rule Conflicts)] をいったんオフにしてからもう一度オンにし、変更したルールに競合がないかを評価します。


次のタスク

  • 問題があるルールを削除または変更し、問題に対処します。

  • SSL ポリシーおよび QoS ポリシーで同様のエラーや警告を調べ、問題に対処しあす。

ルールとその他のポリシーの警告

ポリシーおよびルール エディタでは、トラフィックの分析やフローに悪影響を与える可能性のある設定をアイコンで示します。問題に応じて、システムはユーザがそのようなポリシーを展開しようとするときに警告するか、導入を完全に阻止します。


ヒント

警告、エラー、または情報のテキストを確認するには、マウスのポインタをアイコンの上に置きます。


表 2. ポリシーのエラー アイコン

アイコン

説明

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

error

ルールまたは設定にエラーがある場合、影響を受けるルールを無効にしても、問題を修正するまではポリシーを展開できません。

カテゴリおよびレピュテーション ベースの URL フィルタリングを実行するルールは、URL フィルタリング ライセンスのないデバイスをターゲットにする時点まで有効です。その時点で、ルールの横にエラー アイコンが表示され、ポリシーを展開できなくなります。ポリシーを展開するには、このルールを編集または削除するか、ポリシーのターゲットを変更するか、URL フィルタリング ライセンスを有効にする必要があります。

警告

ルールに関する警告またはその他の警告が表示されていても、ポリシーを展開することはできます。しかし、警告でマークされている誤った設定は有効になりません。

警告が出されているルールを無効にすると、警告アイコンが消えます。潜在する問題を修正せずにルールを有効にすると、警告アイコンが再表示されます。

プリエンプトされるルール、または誤った設定によりトラフィックを照合できないルールは有効になりません。誤った設定には、空のオブジェクト グループ、一致するアプリケーションがないアプリケーション フィルタ、除外された LDAP ユーザ、無効なポートなどを使用した条件が含まれます。

一方、警告アイコンがライセンス エラーまたはモデルの不一致を示している場合は、問題を修正するまでそのポリシーを展開することはできません。

[情報(Information)](情報アイコン

情報

情報アイコンは、トラフィックのフローに影響する可能性がある設定に関する有用な情報を表示します。これらの問題によってポリシーの展開が阻止されることはありません。

アプリケーション制御が適用されている場合、システムは接続でアプリケーション トラフィックまたは Web トラフィックを識別するまで、その接続の最初の数パケットと一部のルールとの照合をスキップすることがあります。これにより、アプリケーションと HTTP 要求が識別されるように接続が確立されます。

ルール管理の履歴:共通の特性

機能

バージョン

詳細

URL の条件に関する情報を新しい「URL フィルタリング」の章に移動

6.3

URL フィルタリングに関する情報を、URL の条件に関する専用トピックを含めてURL フィルタリングに移動。