ナレッジドキュメント

DNSシンクホール機能の動作を確認する方法

開始者 hshirai ‎01-12-2017 12:01 AM (4,204 閲覧回数)

※この記事は以下の記事の日本語訳です。

How to Verify DNS Sinkhole Function is Working

https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Verify-DNS-Sinkhole-Function-is-Work...

 

 

詳細

この資料では、DNSシンクホール機能がPAを経由して正しく動作しているかどうか確認する方法について説明します。

以下の2つのシナリオに対応しています:

  • クライアントが外部DNSサーバーを使用している
  • クライアントが内部DNSサーバーを使用している

 

DNSシンクホールのコンフィグレーション

DNSシンクホールの設定方法についてはこちらを参照して下さい。
How to Configure DNS Sinkhole

 

また、DNSシンクホールの設定方法について、ビデオでのチュートリアルが以下に公開されています。
Video Tutorial: How to Configure DNS Sinkhole

 

クライアントが外部DNSサーバーを使用している

注:DNSシンクホールのIPアドレスは、ファイアウォールとクライアントの経路上にある必要があります。それにより、ログを見ることができます。例えば、Palo Alto Networksファイアウォールは感染したクライアントとデータ センターの間に位置していますが、インターネットへ向かうトラフィックはファイアウォールを通過しない環境だとします。そのシナリオでは、DNSシンクホールがインターネットのIPアドレスで設定されている場合、ファイアウォールは、感染したクライアントがC&C(コマンド&コントロール)サーバーに接続しようとしているのを見ることは出来ません。

 

DNSシンクホールの機能がPalo Alto Networksファイアウォールで設定されており、クライアント システムが外部DNSサーバーを使用している時、クライアントからのDNSクエリは、Palo Alto Networksファイアウォールを通って、外部DNSサーバーに向かいます (クライアントとDNSサーバーは異なるサブネットに属しています)。期待したとおりに、ユーザーは送信元としてのクライアントのIPアドレスを含む脅威ログを見ることができます。

 

  1. ユーザーは感染したウェブサイトにアクセスしようとしています。クライアント システムは、感染したウェブサイトのIPアドレスを取得するために、DNSクエリを外部DNSサーバーへ送ります。ファイアウォールは、クライアント システムから直接DNSクエリを受け取ります。
  2. ファイアウォールはDNSクエリを乗っ取り、DNSシンクホール IPアドレスがクライアントに渡されることで、送信元としてのIPアドレスを含む脅威ログを見ることができます。External+DNS.png

 

クライアントのTCP/IPプロパティの設定

以下の設定例をご覧ください。

IP+config+external.JPG

 

脅威ログ

外部DNSサーバーを使用している際、脅威ログでは、感染したウェブサイトにアクセスしようとしているクライアントのIPアドレス "10.50.240.131" を送信元として表示しています。

DNS+sinkhole3.JPG

 

外部DNSサーバーを使用している時のクライアントの出力

 DNS+with+external.JPG

上記のスクリーンショットは、ホスト マシン "10.50.240.131" が "sp-storage.spccint.com(疑わしいURL)" に対してDNSリクエストをしていることを示しており、それが "1.1.1.1" であることを表示しています。このように、DNSシンクホールは期待した通りに動作していることを示しています。

 

クライアントが内部DNSサーバーを使用している

クライアント システムが内部DNSサーバーを使用している場合(クライアントとDNSサーバーは同じサブネットに所属しています)、クライアントからのDNSクエリは内部DNSサーバーに向かいます。内部DNSサーバーがこのクエリを外部DNSサーバーに転送することで、送信元としての内部DNSサーバーのIPアドレスを含む脅威ログを見ることができます。

 

現在、Palo Alto Networksファイアウォールでは、脅威ログを利用したとしても、どのエンドのクライアントが感染したウェブサイトにアクセスしようとしているのかを特定することはできません。なぜなら、すべての脅威ログは送信元として、内部DNSサーバーのIPアドレスが表示されるためです。しかしながら、ファイアウォールはトラフィック ログを利用することでエンドのクライアントのIPアドレスを特定することができます。

 

以下の例は、ユーザーが感染したウェブサイトにアクセスしようとしているところです。クライアント システムは、感染したウェブサイトのIPアドレスを取得するために、DNSクエリを内部DNSサーバーに送ります。そして、内部DNSサーバーは、そのDNSクエリを外部DNSサーバーに転送します。ファイアウォールは、外部DNSサーバーからDNSクエリを受け取ります。

 

ファイアウォールはDNSクエリを乗っ取り、内部DNSサーバーにDNSシンクホールのIPアドレスを渡します。内部DNSサーバーがクライアント システムに返答を転送することで、送信元としての内部DNSサーバーのIPアドレスを含む脅威ログを見ることができます。しかし以下のスクリーンショットのように、クライアントがDNSシンクホールのIPアドレスを使ってウェブサイトにアクセスしようとするため、Palo Alto Networksファイアウォールは、トラフィック ログにおいてクライアントのIPアドレスを見ることができます。

Internal+DNS+server.png

 

クライアントのTCP/IPプロパティの設定

IP+config+internal.JPG

 

脅威ログ

脅威ログでは、ファイアウォールは、送信元として "10.50.240.101" という内部DNSサーバーのIPアドレスだけを表示しています。なぜなら、クライアント システムが内部DNSサーバーのIPアドレスを使用しているからです。そのため、ファイアウォールはどのエンドのクライアントがウェブサイトにアクセスしようとしているのかを特定することができません。

DNS+snikhole2.JPG

 

トラフィック ログ

しかし、クライアントがDNSサーバーからIPアドレスを取得するとすぐに、DNSシンクホールのIPアドレスに対してトラフィックを生成します。そのため、ファイアウォールは、以下に表示されているように、トラフィック ログの中でエンドのクライアントのIPアドレス "10.50.240.131" を表示することになります。

DNS+traffic2.JPG

 

内部DNSサーバーを使用している時のクライアントの出力

DNS+cap.PNG

上記のスクリーンショットは、ホスト マシン "10.50.240.131" が "sp-storage.spccint.com(疑わしいURL)" に対してDNSリクエストを実行していることを示しており、それが "1.1.1.1" であることを表示しています。このことから、DNSシンクホールが期待通りに動いていることが確認できます。

 

参照

How to Configure DNS Sinkhole

Video Tutorial: How to Configure DNS Sinkhole

 

 

著者:sbabu