プロキシ環境でも危ないDNSという経路とその対策

はじめに

SaaSやPaaSなど、さまざまなパブリッククラウドの利活用が進んでいます。そこにコロナ禍が重なって、純粋なプロキシ環境は以前よりは減ってきたように思います。

その一方で、オンプレミス環境の利用も続いていますし、IPAが高度標的型攻撃に向けたシステム設計ガイドでその利用を推奨^[1]していることもあり、こうしたプロキシ環境がそう簡単になくなることはないでしょう。

今月は、プロキシで隔離した環境でも抜け穴となりがちな、DNSの話を実例を交えつつお伝えします。またその対策に弊社のソリューションがどのように役立つのかを見ていきましょう。

「プロキシ環境だから安全」という油断

以下の図1は、よくあるプロキシ環境で「www.paloaltonetworks.com」に対して Pingを実行したようすです。プロキシ環境下の端末がお手元にあれば実際に試してみてください。

見たところ、通信は期待するとおり失敗しているように見えます。ただしそこで問題になるのが「誰に対してPingを実行した結果タイムアウトしたのか」です。

この図からは、「23.208.232.94にICMPパケットを送信した結果失敗した」ということがわかります。ではなぜ、23.208.232.94にICMPパケットを送信しているのでしょうか。

よくある企業ネットワークでPingを実行した場合、どのような通信が発生するのかを下の図2に示します。

実際の通信で発生することになるARPや複数の権威サーバーの参照などの通信はここでは省略していますが、Pingがブロックされるまでにはおおよそこのような通信が発生しています。

すでにお気づきかと思いますが、Pingは期待どおり失敗しているものの、その前にDNSプロトコルによる外部との通信と名前解決が成立しています。今回はPingで試していますが、後につづくプロトコルが何であっても、FQDNでアクセスを試みればDNSによる名前解決の通信が発生します。

プロキシが介在し、エンドポイントが直接外部に通信できなくてもこの状況は変わりません。その場合はプロキシサーバーが名前解決を試みるので、間接的であっても組織外にDNSクエリは送られます。

名前解決が成立するとどんなことができるのか

DNSのクエリやレスポンスに含まれるホスト名やサブドメインに情報を埋め込むと、エンドポイントで動作するマルウェアとC2サーバーとが通信できます。こうした通信手法を「DNSトンネリング」と呼びます。

先ほどの図に当てはめると以下のようなフローになります。

上の図3はHTTPアクセスを装ったDNSトンネリングによるC2サーバーからのコマンド受信フローを示したものです。

1. マルウェアに感染したエンドポイントが、攻撃者が用意した外部C2サーバーに対し、DNSクエリーに指示の要求を含めて送る。
2. C2サーバーがDNS応答に指示を含めて送る。
3. エンドポイントはC2サーバーからの指示に従い、コマンドを実行する。

このフローをエンドポイントやファイアウォールから見れば、通常のアプリケーションがWebにアクセスしようとしているようにしか見えません。

もうひとつのシナリオは、マルウェアからC2サーバーに情報をアップロードするフローです。

DNSクエリのサイズは小さいので、内部情報を持ち出す場合は時間を空けて複数に分割して送信することが多いようです。また、攻撃者からすれば、クエリ送信の時点で目的は達成していますが、あえてそれらしいDNS応答を返すことで、応答のないクエリがログのなかで目立たないようにするケースもあります。

これらの通信が厄介なのは、後に続くプロトコルがHTTPでも、その手前で発生するDNSクエリを情報の送受信に使うので、プロキシを含むWebフィルタリングソリューションを導入していても見逃されやすいという点です。
一般に、Webフィルタリングサービスが防御対象に含むのはHTTPリクエストであって、プロトコルの異なるDNSは防御対象外です。この部分は弊社の製品でも同様で、URL Filteringサブスクリプションの検査対象はHTTP/HTTPSプロトコルのみです。

DNS Securityで抜け穴を塞ぐ

攻撃者から見れば、セキュリティ強度が高いところを敢えて狙う必要はありません。彼らは複数の攻撃手法から最も効率的に使える経路で通信を試みます。どのようなプロトコルでアクセスする場合でも、その前に名前解決が行われる可能性が高く、常時通信が発生しているので正常な通信に紛れ込ませやすく、独自ツールを使わなくてもOS標準で実装されていることから、DNSに特化した対策がないかぎり、正規の通信か不正な通信かは極めて見分けにくいのです。

弊社の次世代ファイアウォールは、DNSトンネリングを含むDNS関連攻撃から組織を保護するため、DNS SecurityというDNSに特化したサブスクリプションサービスを提供しています。

弊社のSASEソリューションであるPrisma SASEには一部のエディションを除き^[2]、標準でこのDNS Securityサブスクリプションが含まれています。

上図5はDNS Securityの概要図です。ここに示したとおり、これは単にデータベースに多数悪性ドメインを含めておき、クエリと突き合わせするだけのサービスではありません。昨今は非常に簡単にドメイン名を取得できるので、既知の悪性ドメイン名をデータベース化しただけでは、あっという間に古くなり攻撃に太刀打ちできません。DNS Securityの場合、未知のドメイン名であっても機械学習で予測判定する機能があります。

おわりに

過去にキャッシュサーバーないしコンテンツフィルタとしてプロキシを導入し、それがそのままURLフィルタリング対策として利用されている、という組織は多いでしょう。その場合はぜひ、DNS対策に抜け穴がないかお手元のプロキシ環境を確認してみてください。そこでDNSに対する対策が必要だと判断されるようであれば、ぜひ弊社営業担当窓口 infojapan@paloaltonetworks.com までご相談ください。

参考文献

1. 独立行政法人情報処理推進機構. "「高度標的型攻撃」対策に向けたシステム設計ガイド". 2014. https://warp.ndl.go.jp/info:ndljp/pid/12446699/www.ipa.go.jp/files/000046236.pdf. (参照 2023-12-05).
2. パロアルトネットワークス. "Prisma Access のライセンス ガイド". 2022. https://www.paloaltonetworks.jp/resources/datasheets/prisma-access-licensing-guide (参照 2023-12-06)