- 概要
- 前提条件
- Cisco Talos Intelligenceコンテンツ/URL フィルタリング仕組み
- URL パターンロジック
- HTTP 通信の場合
- HTTPS 通信の場合
- トラブルシュートステップ
- デモンストレーション
- 特定のURL が予期しないコンテンツのカテゴリに分類された場合
- 追加リソース
- Meraki Learning Hub
概要
この記事は、ファームウェアMX17+ 以降のCisco Talos Intelligence コンテンツ/URL フィルタリングのトラブルシュートについて記載しています。
MX17+ 以降から2025/5/26 現行バージョンのファームウェアでは、Cisco Talos Intelligence に置き換わっており、以前までのBright Cloud を用いたコンテンツ/URL フィルタリングは廃止されております。
この詳細に関しては、こちらの記事 をご参照ください。
前提条件
- ファームウェア: バージョンMX17 以降
- モード: ルーテッドモード ※パススルー/コンセントレータモードとして構成された MX では、コンテンツ フィルタリングは推奨されません。
- MX のアップストリームのファイアウォールでTCP ポート 443 とともに以下が許可されていることを確認する。(SSL インスペクションなども対象外とすることが推奨)
ドメイン：
- *.talos.cisco.com
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
- HTTP or HTTPS の通信であるか。
仕様上、上記いずれかのトラフィックでない場合、ブロックすることができません。
例えば、Google のサービスやブラウザで広く利用されるQUIC プロトコルはブロックの対象にすることができません。
これは、パケットのペイロードが保護されているため、MX がトラフィックを分析することができないためです。
Cisco Talos Intelligence コンテンツ/URL フィルタリング仕組み
Cisco Talos Intelligence では、MX のコンテンツフィルタリングはカテゴリリストをあらかじめ読み込んでおくことをしなくなりました。
代わりに、MX はCisco Talos のインテリジェンスサービスからURL のカテゴリを直接クエリします。
その後、クエリされたURL とそれぞれのカテゴリは、MX のローカルにキャッシュされます。
こちらのコミュニティ記事の図を参考にいただくとイメージしやすいです。
また、MX は URL を一致させるために同じURL パターンロジックを使用します。
このパターンロジックについて詳しく解説します。
URL パターンロジック
まず、勘違いしやすい点が「*」 （アスタリスク）記号の利用方法についてです。
「*」 は単独で使用される場合は、すべての可能なエントリ を表す包括的なワイルドカードとなります。
つまり、以下の利用の場合、明示的に許可リストに指定されたものを除き、すべての URL パターンがブロックされる動作となります。
以下のような記載の方法は、「*」 がURL の一部として扱われることになるため、多くの通信を制御することができません。
しかし、ルールを書く時にすべてのURL を絶対パスで記載しなくてはならないわけではありません。
ここからが、具体的なURL パターンロジックの仕組みとなります。
HTTP 通信の場合
以下の例では、「wikipedia.org」をブロックとしています。
以下のURL 宛の通信が発生した時には、内部で段階的にURL が短縮されルールに合致するか確認されます。
http://en.wikipedia.org/wiki/Cisco_Meraki#Access_Points_(MR)
※wikipedia はHTTPS の通信ですが、HTTP の想定で考えた場合の例となります。
例では、①～⑤の流れで短縮され、合致することが確認されるためブロックの動作となります。
以下例では、ホワイトリストに登録した絶対パスは許可されますが、それ以外のfoo.bar.com ドメインへのアクセスはすべてブロックされることになります。
HTTPS 通信の場合
HTTPS リクエストもブロックできますが、HTTPS リクエスト内の URL は暗号化されているため、次の順序でドメイン URL チェックのみが実行されます。
- www.foo.bar.com
- foo.bar.com
- bar.com
- .com
- * (キャッチオール URL の特殊文字)
以下設定例の場合、3つのURL へのアクセスに対してドメインURL チェックが段階的に行われ、合致するためブロックされます。
https://ja.wikipedia.org/wiki/
https://en.wikipedia.org/wiki/Cisco_Meraki
https://ja.wikipedia.org/wiki/メインページ
トラブルシュートステップ
設定した通信が想定通りにならない場合、以下の点をもとに調査を行う。
1. 想定通りにならないのは特定端末か、全体的に発生するのか。
2. コンテンツフィルタリングルールの優先度 に基づいた観点で確認を行う。(例: 拒否する通信がグループポリシーで許可されてるなど)
3. ダッシュボード上で、制御したいURL のコンテンツと脅威のカテゴリを確認し、対象のカテゴリが設定に含まれていること。
4. Client のMAC アドレスを控える。
5. 端末側の問題に左右されないようにブラウザのプライベートウィンドウなどを用いて接続確認を行う。
6. 通信再現時にMX のLAN 側でパケットキャプチャを行う。
デモンストレーション
以下の設定をもとにデモンストレーションを実施します。
まずは、MX 配下にクライアント端末を接続し、端末上でパケットキャプチャを開始します。
これは、ダッシュボードツールを用いてMX のLAN を指定しパケットキャプチャを開始しても問題ありません。
その後、クライアント端末から"https://ja.wikipedia.org/wiki/シスコシステムズ" の通信を行います。
取得したパケットキャプチャを開き、以下のフィルタを用いて、対象のクライアントからの通信を確認します。
| eth.addr == クライアントMAC and tls.handshake.extensions_server_name contains "wiki" |
※ デモでは、クライアント端末上のパケットキャプチャのため、eth.addr は割愛していますが、ダッシュボードツールの場合、推奨されます。
以下の例のようにHTTPS の通信の場合、ブラウザ上で接続がリセットされたことが表示されます。
※ブラウザによって表示の差異がある場合があります。
さらにこの時に宛先のIP アドレスが確認できます。
特定した宛先のIP アドレスでフィルタリングを実施すると、クライアント端末からのTLS ハンドシェイクに対してMX からRST パケットが送信されていることが確認できます。
| ip.addr == 宛先IP アドレス |
この結果、期待通りに動作することが確認できました。
これは、以下のようにEvent log やSummary report からも確認することできます。
Event log
Summary report
想定通りに機能しない場合、MX のLAN 側でこれらのパケットフローが確認できること、
QUIC などのプロトコルで通信が実施されていないかを確認する必要があります。
特定のURL が予期しないコンテンツのカテゴリに分類された場合
URL が予期しないコンテンツのカテゴリに分類された場合、異議申し立てはTalos のレピュテーションサポートページから直接提出することが可能となります。
詳細は以下のドキュメントをご参照ください。
脅威カテゴリに関する申し立てに関しては、Meraki サポートまでご連絡いただき、ご依頼の提出を代行させていただきます。
追加リソース
Content_Filtering_Troubleshooting
Content_Filtering_Powered_By_Cisco_Talos
Meraki Learning Hub
