DNS セキュリティ機能（TPサブスクリプション）

PAシリーズのクラウドと連携したDNS セキュリティ機能をフルで利用する場合、Threat Prevention(TP) サブスクリプションとDNSセキュリティ サブスクリプションの2つのサブスクリプションが必要になります。

• Advanced Threat Prevention
• Advanced DNS Security

このDNSセキュリティですが、シグネチャベースのDNS機能であればTPサブスクリプションだけで利用可能なことをご存知でしょうか？今回は、TPサブスクリプションのみを利用したDNS セキュリティ機能について紹介します。

PAシリーズのDNSセキュリティは、FWを通過するDNS通信を検出します。既存のDNSサーバの権威サーバの設定変更などは必要ありません。そのため、PAシリーズが導入されている環境であればいつでも有効化できます。

DNS セキュリティの動作（TPサブスクリプション）

TPサブスクリプションのみが有効なPAシリーズでのDNS セキュリティの動作について説明します。

1. 感染端末がC&Cサーバへアクセスするために、C&Cサーバのドメイン(xxxx.badsite.com)の名前解決を行うためにDNS通信を送信する。（昨今のC&CはIP直ではなくドメインで管理されています。）一般企業では、このDNS通信は通常、内部DNSサーバに送信されます。
2. 内部NDSサーバはこのC&Cサーバのドメインを管理していませんので、このドメインについて上位DNSサーバに問い合わせ（DNS通信）を行います。
3. PAシリーズは、このDNS通信が通過する際に、このドメイン(xxxx.badsite.com)が悪意のあるドメインかどうかを確認します。（TPサブスクリプションを使用している場合、アンチウィルスシグネチャに含まれるDNSシグネチャが利用されます）

悪意のあるドメインに対するDNS通信を検出した場合のPAシリーズのアクションは以下の4つです。

• Allow　　：通信を許可（ログは記録されない）
• Alert　　：通信を許可（ログを記録）
• Block　　：通信をブロック
• Shinkhole：DNS シンクホール応答を行う

DNS シンクホール について

内部DNSサーバを設置している環境において、インターネットゲートウェイに設置したPAシリーズが検出するのは内部DNSサーバが送信したDNS通信です。そのため、DNSセキュリティで検出したログを確認しても送信元IPはすべて内部DNSサーバになり、感染端末を特定することができません。この場合、感染端末を特定するためには、内部DNSサーバの膨大なログを検索することになります。

そこで利用するのが、DNS シンクホール応答です。DNSシンクホールとは、悪意のあるドメインを検出した場合に通信をブロックするのではなく、あらかじめ設定した嘘のIPアドレスをDNSレスポンスとして返す（シンクホール応答）と言う機能です。この機能には2つのメリットがあります。

• クライアントPCは嘘のIPに誘導されるためC&Cサーバとは通信できない。
• 嘘のIPにアクセスした端末をチェックすることで、感染端末を簡単に見つけることができる。

4. PAシリーズは悪意のあるDNS通信を検出した際に、あらかじめ設定しておいた嘘のIPアドレス（シンクホール応答）を内部DNSサーバに対して返します。（例として10.10.10.10）
5. 内部DNSサーバはその応答を感染端末に返します。
6. 感染端末は、「C&CサーバのIPは10.10.10.10」と勘違いして10.10.10.10に対してSSHやHTTPSなどの何かしらの通信を開始します。

このシンクホールIPは嘘のIPアドレスなので、感染端末はC&Cサーバに到達することはできません。また、シンクホールIPにアクセスした端末をTrafficログやカスタムレポートで抽出すると、感染端末を効率的に検出することができます。（シンクホールIPにアクセスした端末→PAシリーズによるDNSシンクホールの影響を受けた端末→悪意のあるドメインの名前解決を行なった端末→感染等の危険性の高い端末。と言うロジック）

ハニーポットサーバなどを準備してもいいですが、このシンクホールIP（10.10.10.10）がPAシリーズを通過するようなNW構成にしておくと良いと思います。

DNS セキュリティの設定方法

PAシリーズでの DNSセキュリティの設定方法について記載します。FWとしての基本設定は完了しており、TPサブスクリプションで利用可能なシグネチャ（アプリケーションおよび脅威、アンチウィルス）がインストールされている前提で説明を行います。

• 【DNS ポリシータブ】に移動します。
• 【DNS ポリシー】の「Palo Alto Networks コンテンツ」部分が、TPサブスクリプションで利用可能なポリシーです。
• 【ポリシー アクション】 を指定します。先ほど説明した4つのアクションから選択してください。新規に作成したアンチスパイウェア プロファイルのデフォルトは「sinkhole」です。
• 【DNS シンクホール設定】で、シンクホールIPを指定します。デフォルトでは、「sinkhole.paloaltonetworks.com」が設定されていますので、シンクホールIPとして利用したいIPを設定します。（今回は「10.10.10.10」に変更します。）
• 【OK】をクリックして設定を保存します。
• このプロファイルを、利用したいセキュリティポリシーに適用してください。
• 画面右上の【コミット】をクリックして設定を完了してください。設定は以上です。

（参考）
PAN-OSのバージョンによって異なる可能性はありますが、PAN-OS 11.1においては、デフォルトのアンチスパイウェア プロファイルである「default」プロファイル以外は、sinkhole がデフォルト設定になっていますので、アンチスパイウェアの設定を行なった時点でDNSセキュリティも動作します。
ただし、デフォルト設定では上述の通り、sinkhole.paloaltonetworks.comが設定されているためシンクホール応答もAレコード(IPアドレス)ではなく、CNAMEになります。このCNAMEを端末側で再起問い合わせしない場合は名前解決に失敗したことになりますので、通信のブロックはできますが、環境によっては端末の特定はできない場合がありますので、シンクホールIPを指定した方が良いかもしれません。

DNS セキュリティの動作確認

それでは、実際に動作を確認してみます。今回は以下のような単純な構成で確認を行います。

まず、”試験用の悪意のあるドメイン”を確認します。TPサブスクリプションでのDNSセキュリティで利用するのはアンチウィルス シグネチャで、DNSに関する情報もリリースノートに記載されています。

• 【DEVICEタブ】→【ダイナミック更新】→【アンチウィルス】で、インストール済みのシグネチャの【リリースノート】をクリックします。
• New Spyware DNS C2 Signatures で検索をかけます。
• 以下のように、最近登録された悪意のあるドメインが表示されていますので、これを利用して試験を行います。

• 今回は、「0-lx[.]7846232[.]xyz」 を利用して試験を行います。

nslookup コマンドでの確認

• 試験端末で、コマンドプロンプトを開き、nslookup コマンドで上記のドメインの名前解決を行います。
• このDNSリクエストに対して、シンクホールIP（10.10.10.10）が帰ってきています。

• 脅威ログには以下のように、spyware タイプとしてログが出力されます。

ブラウザ でアクセスしてみる

• 同様に、このドメインに対してブラウザ経由でHTTPアクセスすると以下のように失敗します。これは、シンクホールIPである10.10.10.10は存在しないIPとしているためです。

• 脅威ログには、先ほど同様のログが出力されます。
• ここでトラフィックログを確認してみます。シンクホールIPである10.10.10.10でフィルタをかけてみると、このシンクホールIPに対して、ポート80番でアクセスしようとしていることが分かります。
• 今回は、内部DNSサーバを設置していない単純な構成であるため、脅威ログ(DNSセキュリティログ)とトラフィックログで送信元IPは同じになりますが、DNSシンクホール機能を利用することで、このように端末をあぶり出すことができます。

PAシリーズを購入している大多数の方々はTPサブスクリプションを購入していると思いますので、追加コストが発生しないDNSセキュリティは必ず設定することをお勧めします。