Jamf Protect - Network Threat Prevention で「特定ドメインのバイパス」が効かないときは CNAME を確認しろ

pirox

「自分がハマったことは他の誰かもハマってしまうかもしれない」ということで、Jamf Protect の Network Threat Prevention  機能において「特定ドメインのバイパス」が効かない場合の解決方法の一例を残します。 


TL;DR

  • Network Threat Prevention の「特定ドメインのバイパス」が効かない場合は対象ドメインの DNS レコードをチェック

  • 対象のドメイン、CNAME が設定されていない？

  • CNAME の値 (ドメイン) もバイパス対象に登録すると問題が解消する可能性があるよ (Chrome, Firefox の場合)


Network Threat Prevention とは ??

Network Threat Prevention (NTP) は「高リスクと判定されたドメインへのアクセスをブロックする」Jamf Protect の機能です。いわゆる Web フィルタリング、コンテンツフィルタリングです。

Web サービス等にアクセスする際に

  1. Mac が Jamf の DNS サーバに名前解決をリクエスト

  2. Jamf の DNS サーバが対象ドメインのリスクを評価

  3. 評価結果に応じてレスポンス

    • 問題なし: 対象ドメインの IP アドレスを返す

    • 問題あり: ブロックページ用の IP アドレスを返す

という処理をします。


以前書いた note でも触れました。


NTP とVPN の併用時の問題 -> 「特定ドメインのバイパス」で対応

特定のグローバル IP アドレスからのみアクセスを許可する仕組み (以下、IP 制限) をもつ Web サービスを使うために、VPN を活用することがあります。VPN サーバに割り当てた固定グローバル IP アドレスから対象の Web サービスにアクセスすることで、「オフィスに出社しなきゃ」なロケーションの制約を解決します。

すべての通信を VPN 経由にするとコストが爆発するため、特定ドメイン (IP 制限をかけた Web サービス)との通信のみを VPN 経由にしたくなります。実現方法はいろいろあるようですが、そのうちの一つに自組織用の DNS サーバを準備して対象ドメインの通信のみを VPN ゲートウェイに向かわせる構成があります。

  • Mac の DNS リゾルバとして自組織の DNS サーバを指定する

  • プライベート IP アドレスへの通信は VPN ゲートウェイに向かうよう、OS のルートテーブルを変更する

  • IP 制限をかけた Web サービスを VPN 経由でアクセスさせるために、名前解決で返す IP アドレスをプライベート IP アドレスにする

  • VPN 側での NAT により、アクセス先を本来のグローバル IP アドレス(パブリックに公開された DNS レコードの値)に変換する

split tunneling で調べると詳しい情報がでてきます。


上記の仕組みが、NTP の「すべての名前解決を Jamf の DNS サーバに問い合わせるよう強制する」仕組みとバッティングしてしまいます。

Jamf の DNS サーバがパブリックに公開されている IP アドレスを返してしまうと、ルートテーブルのデフォルトゲートウェイに通信が向いてしまい、 通常のインターネットアクセスと同様のアクセス経路を辿ります。結果、ISP のグローバル IP アドレスがアクセス元となってしまい IP 制限でブロックされます。


この問題に対処するため NTP には「特定ドメインのバイパス」機能があります。「任意のドメインを NTP 側で名前解決しないようパイバスできるよ」というものです。

特定ドメインのバイパス
"split-brain" DNS が存在するネットワーク環境、つまり、特定のドメインに属しているホスト名が (内部の) プライベート DNS ネームサーバによってのみ解決できるネットワーク環境では、多くの場合、ネットワーク脅威防御の構成からそれらのドメインをバイパスする必要があります。そうしなければ、これらのプライベート/内部ホスト名のルックアップは Jamf に送信され、そこでパブリックソリューションが試行され、ほとんどの場合失敗します。
これは、VPN が使用されているところでは、またはデバイスが、オーガニゼーションのローカルネットワーク (Wi-Fi やイーサネット経由など) に直接接続されているときにのみ特定のサービスを解決して接続できる必要がある状況では、非常に一般的です。 
このシナリオでは、エンドポイントでネットワーク脅威防御を無効にするソリューションとは異なり、特定のオーガニゼーション所有のドメインをバイパス (無視) するためではなく、デバイスをネットワーク脅威から保護するために、ネットワーク脅威防御をアクティブのままにしておくことが望ましい場合があります。
これを行うには、DNS 設定プロファイルのオンデマンドルールのセクションで、EvaluateConnection ルールを定義します。DNS 設定は、これらのルールのいくつかが既に構成された状態で RADAR から出荷されるため、既存の EvaluateConnection ディクショナリに独自のエントリを追加できます。

https://learn.jamf.com/ja-JP/bundle/jamf-protect-documentation/page/Configuring_Network_Threat_Prevention.html


これでひとまず安心ですね。と思っていた時期が私にもありました。


バイパス設定が効かないケース

IP 制限をかけた Web サービスが出るたびにせっせとバイパス登録していたのですが、バイパス設定が効かずにアクセスがブロックされるケースが出てきました。

説明用に、対象システムの情報を以下とします。

  • ドメイン: hoge.com

  • 公開されている DNS の IP アドレス: X.X.X.X (グローバル IP アドレス)

  • 自組織で運用している DNS サーバが返す IP アドレス: Z.Z.Z.Z (プライベート IP アドレス)

hoge.com へのアクセスは VPN を経由させるために、プライベートな IP アドレス (Z.Z.Z.Z) を返すよう構成しています。
OS のルートテーブルには「Z.Z.Z.Z 宛ての通信のゲートウェイは VPN サーバ」と設定しています。(netstat -rn コマンドの出力情報を見るとイメージしやすいかと思います。)


原因調査の経緯

Terminal を起動して dig で DNS をひいてみます。(下記の結果は説明上のダミー情報です。)

% dig hoge.com      

~
;; ANSWER SECTION:
hoge.com.	6	IN	CNAME	hoge.com.edgekey.net.
hoge.com.edgekey.net. 16 IN CNAME	a1234.a.akamaiedge.net.
a1234.a.akamaiedge.net.	16	IN	A	Z.Z.Z.Z

~

A レコードの IP アドレスは Z.Z.Z.Z が返りました。
バイパス設定により、Jamf の DNS サーバではなく自前 の DNS サーバで名前解決していると判断できます。

次に Chrome から hoge.com へアクセスすると IP 制限でブロックされてしまいます。試しに DNS キャッシュを削除しても結果は変わらずでした。


別ブラウザでの挙動を確認したところ

  • Safari -> アクセス成功

  • Firefox -> アクセス失敗

という結果でした。Safari だと VPN 経由でアクセスできるため、原因は Web ブラウザにあるようです。


Chrome 内部での名前解決の結果を明確に確認するため、dig ではなく net-internals (chrome://net-internals/#dns) を使います。(Chrome の DevTool / Network でも確認できます。)

chrome://net-internals/#dns での確認結果

hoge.com の IP アドレスをひくと X.X.X.X が返りました。
やはり Chrome でのアクセス時には自前の DNS サーバで名前解決できていないようです。


先の dig の結果に CNAME レコードがあったなと思い出し、試しに hoge.com.edgekey.net, a1234.a.akamaiedge.net もバイパス対象に追加したところ、Chrome でも Z.Z.Z.Z の IP アドレスが返るようになり、Web サービス hoge.com に VPN 経由でアクセスできるようになりました。Firefox でのアクセスも同様に解決しました。

(再掲)

% dig hoge.com      

~
;; ANSWER SECTION:
hoge.com.	6	IN	CNAME	hoge.com.edgekey.net.
hoge.com.edgekey.net. 16 IN CNAME	a1234.a.akamaiedge.net.
a1234.a.akamaiedge.net.	16	IN	A	Z.Z.Z.Z

~



(参考情報) Chrome の BuiltInDnsClientEnabled ポリシー

NTP を有効化するための構成プロファイルには、各 Web ブラウザの DNS の挙動をコントロールする設定が含まれています。

Chrome の場合 BuiltInDnsClientEnabled ポリシーの設定により、Chrome 独自の DNS クライアントを無効化して Jamf の DNS サーバでの名前解決を強制しているようです。

Jamf Trust Bootstrap - Application & Custom Settings

このポリシーでは、DNS サーバーとの通信にオペレーティング システムの DNS クライアントと Google Chrome の組み込みの DNS クライアントのどちらのソフトウェア スタックを使用するかを管理できます。

https://chromeenterprise.google/intl/ja_jp/policies/#BuiltInDnsClientEnabled


同ポリシーが適用されているため「Terminal (dig) と Chrome での名前解決の結果に差は無いはず」という思い込みがあり、問題解決に時間がかかってしまいました。やはり一つ一つ事実確認を積み重ねるのが大事ですね。



おわりに

記載例の Web サービスでは、CDN を利用するための CNAME レコードが登録されているようでした。
Akamai, Amazon CloudFront といった大手 CDN サービスのドメインであれば、(ドメインが手放されないうちは)ワイルドカードでサブドメイン全体をバイパスする運用が現実的だと思います。
前段のオリジナルのドメイン名によって、NTP によるリスク評価はなされます。

Mac, Web ブラウザ、VPN, Jamf Protect (NTP), IP 制限をかけている Web サービス、と複数のコンポーネントが組み合わさって起きた問題で、こういうときは解決まで持っていくのが大変です。全体を把握している人(情シス担当)の頑張りにかかっています。一つ一つ原因の可能性を潰していきましょう。

いただいたサポートは記事を書くためのエネルギー(珈琲、甘いもの)に変えさせていただきます！