Cato クラウドでは、通信先の FQDN をベースとしたトラフィック制御やアクセス制御を行うことができます。一方で、FQDN の根幹を成す DNS はアプリケーションレイヤの技術であり、ネットワークやトランスポートのレイヤからは直接扱えない技術でもあります。
そうしたレイヤの違いから Cato クラウドが通信先の FQDN をどのように識別しているのか気になりましたので、深掘りして調査検証し、いくつか浮かび上がってきた課題をここで説明します。
通信における FQDN の利用
まず、実際の通信において FQDN がどう利用されるか整理します。
クライアントがIPアドレスではなく FQDN を指定して通信を開始しようとしたとき、その通信に先立ってクライアントは FQDN の名前解決を行います。名前解決には DNS や mDNS、あるいはマシン上の hosts ファイルなどを利用し、通信相手のIPアドレスを把握します。その後、そのIPアドレスに対してパケットを送信します。
IP ヘッダや TCP/UDP ヘッダには FQDN を格納する領域がないため、クライアントが送信するパケットには通常は FQDN に関する情報は含まれていません。ただし、上位レイヤのプロトコルによっては、各プロトコルにおける必要性からデータ部 (TCP/UDP ペイロード部) に FQDN を含むものがあります。
よく利用されるプロトコルの中では、HTTP や TLS (HTTPS を含む) では次の箇所に FQDN を含められるようになっています。
- HTTP の場合：HTTP リクエストの Host ヘッダまたは :authority 疑似ヘッダ
- TLS (HTTPS を含む) の場合：ハンドシェイク開始時に送信される ClientHello メッセージの server_name 拡張
- SNI (Server Name Indication) と呼ばれる仕組み
- プロトコル仕様：https://www.rfc-editor.org/rfc/rfc6066.html#section-3
他にも FQDN をデータとして含むプロトコルもあると思いますが、FQDN を含まないプロトコルのほうが多いです。また、HTTP や TLS であっても FQDN を必ず含むとは限りません。
Cato クラウドによる FQDN 識別の仕組み
さて、Cato クラウドはどのようにして通信先の FQDN を把握し、トラフィック制御やアクセス制御を行っているのでしょうか。
この疑問に対する回答の一部は、Knowledge Base の以下のページに記載されています。
上記ページによると、PoP に存在する DNS サーバは通信に先立って行われる名前解決の結果（FQDN とIPアドレスの組）をキャッシュして覚えておき、その後に行われる通信のIPアドレスを見て FQDN を識別しているようです。Internet Firewall や WAN Firewall などで通信をイベントログに出力するようにしていれば、各イベントログの “Domain Name” フィールドに識別された FQDN が格納されています。
しかし実際に検証してみると、それだけではなく HTTP 通信や TLS 通信に含まれる FQDN も参照して識別していることがわかりました。複数のパターンで試した結果、次のようになっていました。
- TLS (HTTPS 含む) 通信の場合で、ClientHello メッセージに server_name 拡張が含まれている場合、server_name 拡張の値
- HTTP (非暗号化) 通信の場合で、HTTP リクエストに Host ヘッダが含まれている場合、Host ヘッダの値
- 上記以外の場合で、PoP の DNS サーバに名前解決結果のキャッシュがある場合、キャッシュされた FQDN の値
- 上記以外の場合、FQDN は識別されない (“Domain Name” フィールドが存在しない)
FQDN が識別されなかった場合、FQDN を指定して行う各制御機能が正常に働かない (例：Cato PoP からインターネットに出る際のIPアドレスを固定にできない、ブロックさせたい通信がブロックされない）ということにも繋がります。そういったことを避けるためにも、DNS Settings の Primary DNS の設定値を Cato の推奨通り デフォルト値 (10.254.254.1) のままとし、Socket 配下に位置するマシンや Cato Client で接続したマシンに PoP の DNS サーバを参照させることで、FQDN の識別が必ず行われるようにしましょう。
FQDN ベースの制御の課題
Cato クラウドによる FQDN 識別の仕組みがわかると、FQDN ベースの制御における課題、あるいは技術的な制約も見えてきましたので、ここでは4点挙げてみます。
異なる FQDN が同じIPアドレスを共有する場合に誤識別が起きる
インターネット上では、1つのIPアドレスで複数の異なる FQDN のサービスを提供するといったことが一般的に行われています。これはクラウドサービスや共有のレンタルサーバ・ホスティングサービスなど、様々な場所で行われています。そうしたとき、異なる FQDN が同じIPアドレスとして名前解決されると、PoP の DNS サーバの名前解決結果のキャッシュ状況によっては、FQDN を識別する際に誤識別が生じる可能性があります。
実際、インターネットで名前解決可能な2つの FQDN を用意し、そのAレコードを同一のIPアドレスとし、その FQDN に対して Cato クラウド経由でアクセスして試してみました。名前解決結果のキャッシュによって FQDN を識別させるために、TLS や HTTP 以外の通信を行うアプリケーションで試しました。
FQDN① にアクセスした際、手元のマシンは PoP の DNS サーバに対して名前解決の問い合わせを行い、アプリケーションの通信は期待通り FQDN① として識別されました。その後、FQDN② にアクセスした際も同様に名前解決が行われ、期待通り FQDN② として識別されました。
その後改めて FQDN① にアクセスすると、手元のマシンには FQDN① の名前解決結果のキャッシュがあるため、PoP の DNS サーバに対して問い合わせを行わず、アプリケーションの通信が行われました。PoP の DNS サーバではIPアドレスに対して FQDN② を紐づけるキャッシュが残っているようであり、アプリケーションの通信は FQDN② として識別されてしまいました。何度か試した結果、後から名前解決を行った FQDN がそのIPアドレスに紐づけられるようでした。
インターネットにおける通信の仕組み上、こういった誤判定を Cato クラウドが技術的に解消することは不可能だろうと思います。そのため、Cato クラウドの機能で通信を明確に制御したい場合は、FQDN ではなくIPアドレスやポート番号によって制御するしかありません。ただし、TLS や HTTP 通信を行うアプリケーションではこの誤判定は生じないため、実際に課題として顕在化してIPアドレスやポート番号による制御を行う必要があるケースは稀かもしれません。
Cato PoP 側の機能のみ FQDN ベースの制御を行える
通信の FQDN を識別するにはパケットの中身を解析したり、DNS サーバの名前解決キャッシュと突き合せたりする必要があるため、現状では Cato PoP で FQDN の識別が行われています。そのため、Cato Client で接続した SDP ユーザの Split Tunnel 機能や、Socket の Bypass 機能などでは、FQDN ベースの制御は行えません。
将来的に Cato Client や Socket で FQDN を識別することで制御を行えるようになる可能性はありますが、パケット処理の負荷が高い内容でもあるため、ユーザのマシンに求められるスペックが高まったり、高価で高スペックな Socket が必要になったりするはずです。
現状では Cato PoP 側で行われる機能のみ FQDN ベースの制御を行えるのだとご理解ください。
悪意あるユーザは各種制御を回避できる
TLS の server_name 拡張や HTTP の Host ヘッダの値は、ある程度知識があれば書き換えたり削除したりできます。そのようなことが行われたパケットをインターネット上のサーバが受信したときに、書き換え・削除が行われていないパケットを受信したときと同様の動作を行うようになっていると、悪意あるユーザは Cato クラウド上で行った FQDN ベースの各種制御を回避できてしまいます。
また、TLS や HTTP 以外の通信を行う場合にも、手元のマシンから Cato PoP の DNS サーバに名前解決の問い合わせを行わないようにしておけば、同様に各種制御を回避できてしまいます。
実際、server_name 拡張や Host ヘッダを適当な値に書き換えて通信すると、FQDN がその適当な値に識別されることを確認しました。また、Cato PoP の DNS サーバで名前解決を行わないようにしたうえで、server_name 拡張や Host ヘッダを削除して通信すると、FQDN が識別されないことも確認しました。
FQDN による制御を回避できてしまうこと自体は、やはりインターネットにおける通信の仕組み上、Cato クラウドとしてはどうすることもできないように思います。悪意がなければ各種制御が回避されることはないため気にしすぎる必要はないと思いますが、厳格に制御する必要がある場合はIPアドレスやポート番号によって制御すべきですね。
Encrypted Client Hello によって通信できなくなる
2018年頃より、Encrypted Client Hello (ECH) という TLS に関する新しい技術仕様が IETF にて議論されています。TLS 通信開始時に送信される ClientHello メッセージは鍵交換前であるため暗号化されていませんが、この ECH という技術仕様では ClientHello メッセージの一部を暗号化し、とりわけ server_name を秘匿しようとされています。
ECH の詳細はここでは説明せず Cloudflare のブログ や APNIC のブログ にお任せするのですが、端的に言うと、ClientHello メッセージの server_name 拡張の部分にはユーザのアクセス先の FQDN とは異なる値が入り、本当の FQDN は暗号化されて ClientHello メッセージに格納されるようになります。Cato クラウドやその他セキュリティソリューションなどは暗号化された部分を復号できないため、本当の FQDN を知ることができなくなります。
ECH に対応した通信を行うにはクライアントとサーバの両者がそれに対応している必要がありますが、Google Chrome や Microsoft Edge といったブラウザでは既に ECH がデフォルトで有効となっており、Cloudflare のような CDN では ECH を有効にするオプションも用意されています。そのため、今後普及することが予想され、気付かないうちに広まっているかもしれません。
一方で、クライアントが ECH に対応した通信を開始した場合、Cato クラウド側で TLS Inspection を行うようになっていると正常に通信できなくなる可能性があります。実際、日本の通信事業者のセキュリティサービスにおいても ECH により通信が行えなくなったというアナウンス もありました。TLS Inspection をバイパスすれば通信できるはずですが、CASB の各種機能は働かなくなってしまいますし、Cato クラウドが server_name 拡張の値をもとに FQDN を識別するのであれば誤識別も発生してしまいます。
ただし、Cato Client をインストールした Windows マシンを用いて ECH のテストサイトで試したところ、Cato Client 非接続時は ECH が使われたものの、Cato Client 接続時は ECH を使わずに通信していました（HTTPS レコードの問い合わせが行われていませんでした）。ECH が使われなかった理由は不明ですが、そうなるように Cato Client が Windows のレジストリを操作している可能性があります。もしそうであれば、通信できなくなる問題は起きなくて済むので良いのですが、正確な仕様は把握できておりません。
所感
Cato クラウドが通信の FQDN を識別する仕組みについて調査検証し、技術的に行えることはきちんと行う仕組みになっていると感じました。ほとんどの場合は正常に機能しますので、FQDN ベースによる制御も正しく行えるものと思います。
一方で、インターネットにおける通信の仕組み上、誤識別や悪意者が回避できるといった課題が残ってしまっています。これ自体は避けることはできませんが、将来のトラブルシューティング時にもしかしたら役立つかもしれませんので、頭の片隅に残しておきたいと思います。
Encrypted Client Hello という技術仕様については、IETF で議論されている最中でありインターネット標準となっているわけではないため、将来どうなるかはまだわかりません。CASB の各種機能を活かすには ECH を無効にせざるを得ないですが、無効にする設定をマシンに1ずつ導入していかなければならない事態はどうにか避けたいので、Cato クラウド側で何らかの対応（Cato PoP の DNS サーバが HTTPS レコードの問い合わせに応答しないようにする対応）が欲しいですね。