URL フィルタリングに関する次のガイドラインと制限事項に注意してください。

カテゴリとレピュテーションによるフィルタリング

その場合は、カテゴリとレピュテーションを使用した URL フィルタリングの設定方法の手順に従ってください。

URL を識別する前に通過する必要があるパケットを検査するポリシーの設定

システムは以下の動作の前に URL をフィルタリングできません。

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

• システムによりセッションで DNS、HTTP または HTTPS アプリケーションが識別される。

• 要求されたドメインまたは URL がシステムにより識別される（暗号化されるセッションの場合、暗号化されていないドメイン名、ClientHello メッセージまたはサーバー証明書から）。

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

重要システムが調べなければ通過するこれらの初期パケットをシステムが確実に調べるようにするには、トラフィック識別の前に通過するパケットのインスペクションおよびサブトピックを参照してください。

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

脅威カテゴリのブロック

ポリシーが既知の悪意のあるサイトを識別する脅威カテゴリに明確に対応していることを確認してください。レピュテーションの低いサイトをブロックすることに加えて、これを行います。

たとえば、悪意のあるサイトからネットワークを保護するには、すべての脅威カテゴリをブロックする必要があります。さらに、Talos は、カテゴリが「悪い」（Poor）のサイトのみをブロックすることを推奨しています。セキュリティ態勢が「アグレッシブ」（Aggressive）の場合は、レピュテーションが「疑わしい」（Questionable）のサイトをブロックできますが、それにより、誤検出が多くなる可能性があります。

詳細については、URL カテゴリとレピュテーションの説明の URL にある [脅威カテゴリ（Threat Categories）] を参照してください。

URL 条件とルールの順序

• ヒットする必要のある他のすべてのルールの後に URL ルールを配置します。

• URL は複数のカテゴリに属することができます。Web サイトの 1 つのカテゴリを許可し、別のカテゴリをブロックすることができます（明示的に行うか、デフォルト アクションに依存して）。この場合、許可またはブロックが優先されるかどうかに応じて、適切な効果が得られるように URL ルールを作成して順序付けしてください。

ルールに関するその他のガイドラインについては、アクセス制御ルールのベストプラクティス を参照してください。

未分類またはレピュテーションのない URL

URL ルールを作成するときは、まず一致させるカテゴリを選択します。[未分類（Uncategorized）] URL を明示的に選択した場合は、レピュテーションによりさらに制約を追加することはできません。

信頼できないレピュテーションの未分類 URL は、[悪意のあるサイト（Malicious Sites）] カテゴリによって処理されます。他のレピュテーション レベル（疑わしいなど）を使用する未分類サイトをブロックする場合は、すべての未分類サイトをブロックする必要があります。

カテゴリとレピュテーションレベルを選択した後に、必要に応じて [不明なレピュテーションに適用（Apply to unknown reputation）] を選択できます。たとえば、レピュテーションが信頼できない、疑わしい、および不明なサイトに適用されるルールを作成できます。

カテゴリとレピュテーションを URL に手動で割り当てることはできませんが、アクセス コントロール ポリシーと QoS ポリシーでは、特定の URL を手動でブロックできます。手動 URL フィルタリングを参照してください。URL カテゴリとレピュテーションの異議申し立ても参照してください。

暗号化された Web トラフィックの URL フィルタリング

暗号化された Web トラフィックに対して URL フィルタリングを実行すると、システムは次のように動作します。

• （DNS フィルタリングが有効になっている場合）システムが送信元ドメインを認識済みかどうか、またはドメインがローカル レピュテーション データベースに存在するかどうかを確認します。この状態を確認できた場合は、ドメインのレピュテーションとカテゴリに基づいてアクションを実行します。確認できない場合、アクセス コントロール ポリシーの詳細設定で [Retry URL cache miss lookup] が有効になっていても、システムは暗号化トラフィック向けの設定に基づいてトラフィックを処理します。

• 暗号化プロトコルを無視します。ルールに URL 条件はあるがプロトコルを指定するアプリケーション条件がない場合、ルールは HTTPS および HTTP 両方のトラフィックを照合します。

• URL リストを使用しません。代わりに、URL オブジェクトとグループを使用する必要があります。

• トラフィックの暗号化に使用された公開キー証明書のサブジェクト共通名に基づいて HTTPS トラフィックを照合します。また、トランザクション中のどの時点で提示される他の URL（復号後の HTTP URL など）のレピュテーションも評価します。

• サブジェクト共通名内のサブドメインを無視します。

• アクセス制御ルール（または、その他の設定）によってブロックされている暗号化された接続の場合は HTTP 応答ページを表示しません。HTTP 応答ページの制限 を参照してください。

URL フィルタリングと TLS サーバーアイデンティティ検出

RFC 8446 で定義されている最新バージョンの Transport Layer Security（TLS）プロトコル 1.3 は、セキュアな通信を提供するために多くの Web サーバーで採用されているプロトコルです。TLS 1.3 プロトコルが、セキュリティを強化するためにサーバーの証明書を暗号化する一方で、証明書が、アクセスコントロールルールのアプリケーションおよび URL フィルタリング基準に適合する必要があるため、Firepower システムは、パケット全体を復号せずにサーバー証明書を抽出する方法を提供します。

アクセス コントロール ポリシーの詳細設定には、[TLS Server Identity Discovery] に [Early application detection and URL categorization] オプションがあり、アプリケーション検出と URL 分類が早期に実行されます。

この機能は、アプリケーションまたは URL の基準に適合させたいトラフィックに関して、特にそのトラフィックの詳細な検査を実行する必要がある場合に、有効にすることを強くお勧めします。サーバー証明書を抽出するプロセスでトラフィックが復号されないため、復号ポリシー は必要ありません。

（注）

証明書は復号されているため、ハードウェア プラットフォームによっては、TLS サーバーアイデンティティ検出によってパフォーマンスが低下する場合があります。 TLS サーバーアイデンティティ検出は、インラインタップモードまたはパッシブモードの展開ではサポートされません。 TLS サーバーアイデンティティ検出の有効化は、AWS に展開された Secure Firewall Threat Defense Virtual ではサポートされていません。Secure Firewall Management Center で管理されているそのような管理対象デバイスがある場合、接続イベント PROBE_FLOW_DROP_BYPASS_PROXY は、デバイスがサーバー証明書の抽出を試みるたびに増加します。 TLS サーバーアイデンティティ検出は、TLS 1.2 セッションでも動作します。

詳細については、「アクセス コントロール ポリシーの詳細設定」を参照してください。

HTTP/2

システムは、TLS 証明書から HTTP/2 URL を抽出できますが、ペイロードから抽出することはできません。

手動 URL フィルタリング

• カスタム セキュリティ インテリジェンス リストまたはフィードオブジェクトを使用して URL を指定します。URL オブジェクトを使用したり、ルールに URL を直接入力したりしないでください。詳細は、手動 URL フィルタリングオプションを参照してください。

• URL オブジェクトの使用やルールへの URL の直接入力によって、特定の URL を手動でフィルタリングする場合は、影響を受ける可能性のある他のトラフィックを慎重に考慮してください。ネットワーク トラフィックが URL 条件に一致するかどうか判別するために、システムは単純な部分文字列マッチングを実行します。要求された URL が文字列の任意の部分に一致する場合、URL は一致するとみなされます。

• 手動の URL フィルタリングを使用して他のルールの例外を作成する場合は、例外を含む特定のルールを、それらが適用されない場合に適用される一般的なルールの上に配置します。

URL での検索クエリ パラメータ

システムでは、URL 条件の照合に URL 内の検索クエリ パラメータを使用しません。たとえば、すべてのショッピング トラフィックをブロックする場合を考えます。amazon.com を探すために Web 検索を使用してもブロックされませんが、amazon.com を閲覧しようとするとブロックされます。

高可用性展開での URL フィルタリング

高可用性での Firepower Management Center を使用した URL フィルタリングのガイドラインについては、Cisco Secure Firewall Management Center アドミニストレーション ガイドの「URL Filtering and Security Intelligence」を参照してください。

選択したデバイス モデルのメモリ制限

• メモリが不足しているデバイスモデルでは、ローカルで格納される URL データが減少します。したがって、システムはクラウドをより頻繁にチェックして、ローカルデータベースにないサイトのカテゴリとレピュテーションを判断します。

  低メモリ デバイスには、次のデバイスが含まれます。

  • Firepower 1010

  • 8 GB の RAM を搭載したThreat Defense Virtual

Threat Defense での TLS セッション再開のための URL 照合

次の条件で Snort 2 による URL 照合を使用します。

• TLS セッションの再開がなく、SSL ポリシーが有効になっているか、Client Hello メッセージに Server Name Indication（SNI）拡張が含まれている場合。

• TLS セッションの再開があり、SSL ポリシーが有効になっていないか、Client Hello メッセージに SNI 拡張が含まれていない場合。

Threat Defense ライセンス

• カテゴリとレピュテーション フィルタリング：URL フィルタリング

• 手動フィルタリング：追加のライセンスはありません。

従来のライセンス

• カテゴリとレピュテーション フィルタリング：URL フィルタリング

• 手動フィルタリング：追加のライセンスはありません。

Threat Defense デバイス用の URL フィルタリングライセンス

Cisco Secure Firewall Management Center アドミニストレーション ガイド [英語] の「Licenses」章の「URL Licenses」を参照してください。

モデルのサポート

任意（Any）

サポートされるドメイン

任意

ユーザの役割

• 管理者

• アクセス管理者

• ネットワーク管理者

次のヘルス ポリシーは、システムに URL カテゴリとレピュテーション データを取得または更新に問題がある場合は通知します。

• URL フィルタリング モニター

• デバイスでの脅威データの更新

これらが希望どおりに構成されていることを確認するには、Cisco Secure Firewall Management Center アドミニストレーション ガイドの「ヘルスモジュール」と「ヘルスモニタリングの構成」を参照してください。

予想される URL カテゴリが [カテゴリ（Categories）] リストにない

URL フィルタリング機能は、セキュリティ インテリジェンス機能とは異なる一連のカテゴリを使用します。表示されると予想されるカテゴリは、セキュリティ インテリジェンス カテゴリである可能性があります。これらのカテゴリを表示するには、アクセス コントロール ポリシーの [セキュリティインテリジェンス（Security Intelligence）] タブにある [URL（URLs）] タブを調べます。

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

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

DNS フィルタリング：DNS ルックアップ中の URL レピュテーションとカテゴリの識別（ベータ版）も参照してください。

ヘルス アラート：「URL フィルタリングの登録に失敗しました（URL Filtering registration failure）」

Management Center とプロキシが Cisco Cloud に接続できることを確認します。次のトピックの URL フィルタリングおよび URL カテゴリに関する情報が必要な場合：Cisco Secure Firewall Management Center アドミニストレーション ガイドの「Internet Access Requirements」および「Communication Port Requirements」。

特定の URL のカテゴリとレピュテーションはどのようにしたら確認できますか。

手動ルックアップを実行します。Cisco Secure Firewall Management Center アドミニストレーション ガイドの「Finding URL Category and Reputation」を参照してください。

手動ルックアップ試行時のエラー：「<URL> のクラウド ルックアップに失敗しました（Cloud Lookup Failure for <URL>）」

機能が適切に有効になっていることを確認します。Cisco Secure Firewall Management Center アドミニストレーション ガイドの「Finding URL Category and Reputation」の前提条件を参照してください。

URL はその URL カテゴリとレピュテーションに基づいて誤って処理されたように見えます。

問題： システムは URL カテゴリとレピュテーションに基づいて URL を正しく処理しません。

対処方法:

• URL カテゴリと URL に関連付けられているレピュテーションが想定どおりであることを確認します。Cisco Secure Firewall Management Center アドミニストレーション ガイドの「Finding URL Category and Reputation」を参照してください。

• 次の問題は、カテゴリとレピュテーションを使用した URL フィルタリングの有効化を使用してアクセスできる、URL フィルタリング オプションで説明した設定で対処できる場合があります。

  • URL キャッシュに古い情報が保存されている可能性があります。URL フィルタリング オプションの [キャッシュされたURLの期限切れ（Cached URLs Expire）] 設定に関する情報を参照してください。

  • クラウドからの最新情報でローカルのデータ セットが更新されていない可能性があります。URL フィルタリング オプションの [自動更新を有効にする（Enable Automatic Updates）] 設定に関する情報を参照してください。

  • 最新のデータに関してクラウドを確認しないようにシステムが設定されている可能性があります。URL フィルタリング オプションの [不明URLをCisco Cloudに問い合わせる（Query Cisco cloud for unknown URLs）] 設定に関する情報を参照してください。

• クラウドを確認せずに URL にトラフィックを渡すようにアクセス コントロール ポリシーが設定されている可能性があります。アクセス コントロール ポリシーの詳細設定 で、[URL キャッシュ ミス ルックアップを再試行する（Retry URL cache miss lookup）] 設定に関する情報を参照してください。

• URL フィルタリングのベスト プラクティスも参照してください。

• SSL ルールを使用して URL を処理した場合は、復号ルール の注意事項と制限事項およびSSL ルールの順序を参照してください。

• URL を処理している思われるアクセス制御ルールを使用して URL が処理されていることを確認し、アクセス制御ルールが想定どおりに機能していることを確認します。ルールの順序を考慮します。

• Management Center のローカル URL カテゴリおよびレピュテーション データベースがクラウドから正常に更新されており、管理対象デバイスが Management Center から正常に更新されていることを確認します。

  これらのプロセスのステータスは、[URL フィルタリング モニタ（URL Filtering Monitor）] モジュールおよび [デバイスでの脅威データの更新（Threat Data Updates on Devices）] モジュールのヘルス モニタでレポートされます。詳細については、Cisco Secure Firewall Management Center アドミニストレーション ガイドの「Health」 を参照してください。

ローカル URL カテゴリおよびレピュテーション データベースを即座に更新する場合、[統合（Integration）] > [その他の統合（Other Integrations）] に移動し、クラウド サービス（Cloud Services） をクリックしてから [今すぐアップデート（Update Now）] をクリックします。詳細については、URL フィルタリング オプションを参照してください。

URL カテゴリまたはレピュテーションが正しくありません。

アクセス コントロールまたは QoS ルールの場合：ルールの順序に細心の注意を払って、手動フィルタリングを使用します。手動 URL フィルタリングおよびURL 条件の設定を参照してください。

SSL ルールの場合：手動フィルタリングはサポートされていません。代わりに識別名条件を使用します。

URL カテゴリとレピュテーションの異議申し立ても参照してください。

Web ページのロードに時間がかかる

セキュリティとパフォーマンスのトレードオフがあります。いくつかのオプションを次に示します。

• [キャッシュされたURLの期限切れ（Cached URLs Expire）] 設定の変更を検討します。[統合（Integration）] > [その他の統合（Other Integrations）] をクリックし、クラウド サービス（Cloud Services） を選択します。詳細については、URL フィルタリング オプションを参照してください。

• アクセス コントロール ポリシーの詳細設定の [URL キャッシュのミス検索の再試行（Retry URL cache miss lookup）] 設定の選択解除を検討します。

イベントに URL カテゴリおよびレピュテーションは含まれていません

• アクセス コントロール ポリシーに適用可能な URL ルールが含まれていること、ルールがアクティブになっていること、およびポリシーが関連するデバイスに展開されていることを確認します。

• URL ルールと一致する前に接続が処理される場合、URL カテゴリとレピュテーションはイベントに表示されません。

• 接続を処理するルールでは、URL カテゴリとレピュテーションを構成する必要があります。

• SSL ルールの [カテゴリ（Categories）] タブで URL カテゴリを設定した場合でも、アクセス コントロール ポリシーのルールで [URL（URLs）] タブを設定する必要があります。

DNS フィルタリングが機能していない

ドメインルックアップ中に URL を識別するための DNS フィルタリングの有効化に説明されているすべての前提条件とステップを満たしていることを確認します。

エンドユーザーがブロックされた URL にアクセスしようとすると、ページがスピンしてタイムアウトする

DNS フィルタリングが有効になっていて、エンドユーザーがブロックされている URL にアクセスすると、ページはスピンしますが読み込まれません。エンドユーザーには、ページがブロックされたことが通知されません。これは現在、DNS フィルタリングが有効になっている場合の制限です。

DNS フィルタリングの制限事項を参照してください。

イベントに [URLカテゴリ（URL Category）] と [レピュテーション（Reputation）] が含まれるが、[URL] フィールドが空白

[DNSクエリ（DNS Query）] フィールドに値が入力されていて、[URL] フィールドが空の場合、これは DNS フィルタリング機能が有効になっているときに予想されるものです。

DNS フィルタリングとイベントを参照してください。

1 つのトランザクションに対して複数のイベントが生成される

1 つの Web トランザクションが 2 つの接続イベントを生成することがあります。1 つは DNS フィルタリング用で、もう 1 つは URL フィルタリング用です。これは、DNS フィルタリングが有効になっていて、次の場合に予想されるものです。

• トラフィックのアクセス コントロール ルール アクションが [許可（Allow）] または [信頼（Trust）] である。

• システムが URL を初めて検出した。

DNS フィルタリングとイベント を参照してください。