遠隔操作ウィルスへの対策

DNSを使用した遠隔操作ウィルスへの対策

はじめに

2016年2月1日、株式会社ラック社からDNS通信を使用したウィルスによる遠隔制御に関する注意喚起が発表されました。

この方法はDNSトンネリング呼ばれ、データの通信経路としてDNS通信をトランスレイヤで利用して他のプロトコルをトンネリングさせる方法で、攻撃ではなく企業情報を盗むための通信手段としてDNSを利用する方法として知られていました。中から外に対するDNS通信はその特性上、ゲートウェイ機器で安易に止めることができないことを上手く利用しています。

このトピックでは背景となるDNSの仕組み、それを利用した攻撃方法及び、その対策方法についてご紹介します。

本ページの要約

今回の注意喚起で発表されたDNSを利用した遠隔操作ウィルスへの具体的な対策について本トピックページを要約してご紹介します。

対策として実施すべき3つのこと

  1. DNSのレコードタイプがTXTである通信を抽出する
  2. かつ、DNS NAMEのうちホスト部分がランダマイズされたDNSクエリを抽出する
  3. 1.と2.で判明した不正なドメインへのクエリをDNSサーバでブロックする

実際に対策する上で一番の課題となるのは、膨大なDNS通信の中からランダマイズされたDNSクエリを抽出することです。

 

この課題に対し、当社は、ランダマイズされたFQDNを抽出し、DNSブラックリストを生成する仕組みをご提供しています。

momentum DNS viewerとmomentum
ProbeというDNSパケットデータからGUIで簡単に不正なドメインを抽出できる画期的なソリューションです。

詳細はこちらをご覧ください。



DNSとは?

今回のトピックではクライアントに代わって名前解決をを行っている内部DNSサーバが主役です。
内部DNSは企業内から外部のサービスを利用するほぼすべての通信において利用されています。
最も代表的な者としては社内ユーザのWeb利用です。

利用イメージ

一般的なDNSアーキテクチャ

名前 場所 役割
G/W Security Node(s)

ネットワーク内外の境界で出入りする通信を監視・制御するためのセキュリティに特化した機器。

代表的なファイアウォールをはじめ、IPSやAPT製品など、ゲートウェイ型に分類されるものも含む。

DNSの通信は内部Cache DNSからのDNSクエリとその応答と、Master DNSとContents DNSのゾーン転送のみを許可。

Contents DNS DMZ

DMZに配置された、自ドメインのスレーブサーバ。
マスターサーバから受け取った複製情報をもとに、外部からの自ドメインの名前解決要求に対してサービスを提供する。

外部へサービスを提供するため、攻撃の対象に成り得るが、再帰的問い合わせ (Recursion)の機能を無効にすることで攻撃を限定することが出来る。

Slow Drip DNS Attackのような、キャッシュDNSを介した攻撃を受ける可能性はある。

Cache DNS Internal

社内の様々なクライアントの名前解決を請負うキャッシュサーバ。
WEB閲覧など、インターネットのコンテンツを利用するシーンでは欠かすことが出来ない重要なシステムの一つで通常は冗長化されている。

通常、強固なセキュリティシステムで守られたエリア(Internal Zone)に置かれているため、外部からの攻撃に対しては安全が保たれているが、昨今ではDNSプロトコルを経由したデータの流出をはかるマルウェアなどが出現し、情報セキュリティの観点から対策の再考が求められている。

Master DNS Internal

自社で所有(管理)するドメインのリソースレコードのマスターデータを管理する唯一の権威サーバ。

重要な役割を担うため、当該サーバへのアクセスは厳しく管理(制限・記録)され、サーバの存在自体も隠ぺいされる。

マスターの権威サーバとして適確に管理されている限り、セキュリティのリスクにさらされることは少ない。

上記のとおり、一言でDNSと言っても役割やセキュリティポリシーに従って、DNSのシステムは複数のDNSサーバで構成されています。

利用されるDNS

DNS通信を使った盗取と遠隔操作

マルウェアは全く同じ仕組みを使って情報を盗取したりリモート操作をおこうなことが確認されています。

利用イメージ

ボットネットはDNSがお気に入り

悪意のあるのプログラムはC&Cとのやり取りや、機密情報を盗取するための手段としてDNS通信を利用します。

ボットネット

対策

株式会社ラック社は2016年2月1日、遠隔操作ウイルスに対する指令の伝達手段として、DNSプロトコルを悪用する事例を確認したとして注意喚起を行いました。

同社は注意喚起の中で5つの対応例を紹介しています。

  1. 現在のDNSサーバへのアクセス状況を確認する
    1.1 内部DNSのアクセスログから不正なリクエストを発見する
    1.2 ネットワークパケットを収集し不正なリクエストを発見する
  2. 指令サーバとして稼動しているDNS通信(UDP/53,TCP/53)を拒否する
  3. DNSアクセスの制限と、プロキシサーバの活用
  4. 不正なパケットを送出しているクライアントを特定する
  5. 遠隔操作ウイルスの隔離

調査対象

前述したとおり、一言にDNSと言っても多くの場合、DNSのシステムは複数のDNSサーバで構成、運用されています。
では、今回の調査は対象はどのDNSサーバになるのでしょうか?

調査対象

赤丸で囲んだCache DNSサーバのDNS通信が調査の対象です。

アクセスログから不正な通信を調査

アクセスログをもとに調査を行う場合にはCache DNS(赤丸)のクエリーログを調査してください。

パケットから不正な通信を調査

キャプチャポイントは3つあります。※キャッシュDNSが複数ある場合には3×DNS台数

調査対象

場所 説明
1.DNSサーバ自身でキャプチャ DNSサーバ上で通信をキャプチャ。
2.DNSサーバと外との通信 DNSサーバと外部(インターネット側)との間の通信をキャプチャ。
3.DNSサーバ自身でキャプチャ DNSサーバとクライアント(達)との間の通信をキャプチャ。

1はDNSサービスに影響を与えるためお薦めできません。
2は一見良さそうですが、Cache DNSサーバは名前の通りDNSのやり取りをキャッシュします。キャッシュがヒットした場合、2のポイントではクライアントの通信は取得できません。

  • 今回の場合はキャッシュが効いてしまうとC&Cとコミュニケーションを行うのに具合が悪いため、キャッシュが効かない工夫が施されていることが想像できます。

3はクライアント(達)からの通信を全てキャプチャできます。

note:
セキュリティを強化するために内部外部間のDNS通信はF/W等で制約してください。
これは前述した対策の"3.DNSアクセスの制限と、プロキシサーバの活用"の具体的な対処方法です。

  • クライアントの参照先DNSサーバは全てChache DNSへ限定する。
  • F/WはChacheDNSサーバからのDNSクエリとその応答と、Master DNSとContents DNS間のゾーン転送だけを許可する。これで仮に悪意のあるプログラムが任意の外部DNSを直接参照するケースでもセキュリティデバイス(F/W)が通信を遮断することが可能になります。

手段

クエリーログを調査する

キャッシュDNSとしてBINDを利用している場合、デバッグレベルの設定によってログで出力する情報量を調整できます。キャッシュDNSサーバのマシンリソースに余裕があり、サービスがログ出力の負荷に影響をされないか軽微な場合にはこの方法利用して通信を記録できます。デバッグレベルの調整はnamedの起動オプションかrndcのコマンドを使って行います。

rndcを使ったデバッグログの設定

クエリログを有効/無効

rndc querylogというコマンドを使います。rndc querylogはトグル仕様になっていますので、実施にはステータスを確認してクエリログの有効/無効状態を確認してください。

rndc querylog 1回目

[root@bind9 ~]# rndc querylog

ステータスを確認
[root@bind9 ~]# rndc status |grep "query logging"
query logging is ON

rndc querylog 2回目

[root@bind9 ~]# rndc querylog

ステータスを確認
[root@bind9 ~]# rndc status |grep "query logging"
query logging is OFF

デバッグレベルの変更はrndc traceで行います。
rndc traceだけを実行するとレベルが1づつ増加します。

rndc trace

・最初
[root@bind9 ~]# rndc status |grep "debug level"
debug level: 1

* rndc trace
・1回目
[root@bind9 ~]# rndc trace
[root@bind9 ~]# rndc status |grep "debug level"
debug level: 2

・2回目
[root@bind9 ~]# rndc trace
[root@bind9 ~]# rndc status |grep "debug level"
debug level: 3
[root@bind9 ~]#

rndc traceに0-99の任意の数字を引数で与えると引数に応じたレベルが設定されます。

rndc trace n ※n=[0-99]

[root@bind9 ~]# rndc trace 10
[root@bind9 ~]# rndc status |grep "debug level"
debug level: 10
[root@bind9 ~]#

クエリログを使った具体的な調査方法については本稿では扱いません。
別の機会で紹介させていただきます。

パケット調査

キャッシュDNSサーバのマシンリソースにログ出力させることによって名前解決の性能に影響が出る可能性がある場合、あるいは何らかの理由によりデバッグオプションを起動したくない場合は、DNS通信のパケットをキャプチャし、ここから必要なクエリ関連情報を抽出する方法が有効です。

パケットキャプチャを利用する場合の基本構成は、調査対象の「パケットから不正な通信を調査」の項を参照してください。

Wiresharkを利用したパケットの絞り込み

大量の通信データから調査対象の通信を絞り込む」の項で説明されているように、パケットを用いた分析では一番最初の最初の抽出条件は以下のとおりです。

プロトコル:UDP,TCP
ポート番号:53
DNSヘッダーのQRフラグ:0 (0=クエリ、1=応答)

これをWiresharkのGUI上で検索絞り込みするためには、表示フィルターウィンドウで次のような条件を指定します。

”( udp.port 53 || tcp.port 53 ) && dns.flags.response 0 && dns.qry.type 16”

各条件の意味は以下の通りです。

条件文 意味
udp.port 53 UDPポート53番を使用した通信(すなわち一般的なDNS通信)
tcp.port 53 TCPポート53番を使用した通信(すなわちTCPを用いたDNS通信)
(複数の条件式) かっこ内の条件を優先して評価する
条件A || 条件B 条件Aと条件BをORで利用する
条件X && 条件Y 条件Xと条件YをANDで利用する
dns.flags.response 0 クエリ種別がリクエストである
dns.qry.type 16 クエリタイプがTXTである

このように条件指定してパケット検索すると、以下の例のように

プロトコル:UDP,TCP
ポート番号:53
DNSヘッダーのQRフラグ:0

の条件を満たすパケットだけが表示されるようになります。

パケット表示

※ 例として表示しているPCAPファイルは http://malware-traffic-analysis.netからダウンロードして使用しました。

この例では、下の図のようにクエリの長さが84バイトと、それほど大きくありませんし、ホスト名もランダマイズされているというより単純なシーケンスでつけられた名前に見えます。
この点から判断すれば、このトラフィックは本アタックには該当しないと推測できます。

パケット表示

不正なクエリを評価する方法

大量の通信データから調査対象の通信を絞り込む

手法が特定されている場合には、注意喚起の内容に従って対象の通信を特定して調査対象を絞り込むことが重要です。
今回のケースでは以下の特徴が記されています。

  • レコードタイプはTXTである。
  • クエリのDNS NAMEのうちホスト部分が利用されている。

パケットを用いた分析では一番最初の抽出条件は以下のとおりです。

プロトコル:UDP,TCP
ポート番号:53
DNSヘッダーのQRフラグ:0 (0=クエリ、1=応答)

上記抽出条件をもとに大量の通信データから調査対象を絞り込むことで以降の調査効率は格段に向上します。

評価方法

不正な通信を特定する汎用的な方法はありません。
評価方法はインシデントの内容によって異なりますが、アプローチの方法は二つに大別することができます。

  1. リストを用いた評価
  2. 統計的な分析

今回の注意喚起では以下のような特徴があります。

  • クエリのDNS NAMEのうちホスト部分が利用されている。
    ホスト部分とはFQDNの左端に位置するラベルの値を意味します。
    hostname.example.com <<この場合のホストの値は"hostname"です。

通常ホストの値は人間が識別できる値であるのに対して不正利用の場合には機械的に作成されたランダムな値がセットされているのが特徴です。

また、ホスト部分を使って外部と情報をやり取りする場合、一度に送る情報量を多くするために通常では考えられない長さになることが多いとされています。

例え

MRZGS3T・・FEBXXMYLMORUW4ZI.t.example.com

上記特徴にマッチした通信を特定することが重要です。

リストを用いた評価

セキュリティフィードサービスを利用している場合には、抽出したFQDNとフィードで提供されているリストの照合を実施してください。一般に公開されているThreat intelligence databaseなどを用いる方法もあります。

統計的な分析

抽出したデータが少数の場合にはWiresharkなどのデコード&可視化ツールを利用して分析者自身で確認する方法が最も確実な場合もあります。

抽出したデータが大量で目視確認の負担が大きい場合には、WiresharkのCLI機能(Tshark)やスクリプトなどを駆使して自動化する方法を検討してください。

前述の例の場合、評価対象はホスト部に限定されますので自身でスクリプトを作成して分析するのが良いと思います。
参考までにスクリプトで行う判定基準は以下のようなものが考えられます。

  • ホスト名の文字数が30文字以上
  • ホスト名を除くドメイン毎のFQDNのユニーク数

前述したとおり、内部のマルウェアは外部と通信を行うためには、通信を仲介するキャッシュDNSのキャッシュにヒットしないような工夫が必要です。

キャッシュで返されるとマルウェアは外と通知が出来ません。
キャッシュを避けるためには前回とは異なるFQDNを使うのが最も有効です。
結果として対象のドメインに対するクエリーのランダム率は上がります。
よって、調査する際にはホスト名を除く各ドメイン毎のFQDNのユニーク数を調べることでランダム度合いを確認できます。

余談ですが、ホスト名に格納される情報は隠ぺいする必要があるため暗号化されます。
するとホスト名はランダムとなりその結果キャッシュにはヒットしない、解読されない、一石二鳥です。

  • FilterPOINT:
    スクリプトの判断基準にポート番号やレコードタイプが含まれていないのは、最初の抽出で対象のデータが特定されているからです。
    調査対象を効率的に絞り込むポイント
    • 多層的にフィルターをセットする
    • 一つのフィルターの評価基準は名出来るだけシンプルにする
    • より多くの情報を排除することが出来るフィルターを前段に配置するファネルの理論です。

 

BINDを用いた対策

不正な通信を止める方法はいくつかありますが、本稿ではDNSを用いた方法をご紹介します。
DNSを用いたブロッキングの手法には大きく2つあります。

ゾーンのオーバーライド方式
  • named.confにブロックしたいドメインをゾーンとして定義
  • 権威サーバとして応答することでブロッキングを実現
  • 共通ゾーンファイルを利用
  • リアクションはnamed.confで調整可能
Response Policy Zone(RPZ)方式
  • BIND9.8以降で実装されたDNSブロッキングを目的とした機能
  • 設定されたルールに基づき、DNS応答を書き換え、リゾルバへDNS応答することでブロッキングを実現
  • RPZ用のZone Fileを利用
  • リアクションはゾーンファイルのエントリごとに調整可能

ゾーンのオーバーライド方式について

Cache Serverに特定のドメインの権威を持たせてしまうことで応答をコントロールする方法です。ここで言う特定のドメインとは正にブロックしたいドメイン名を意味します。ソーンオーバライド方式はBINDのバージョンに依存していないため、多くの管理者に以前から利用されています。

鵜飼状態

Configuration

設定

ブロッキングゾーンの名前解決が無効化されるまでの流れは以下のとおりです。

  1. ブロッキング対象のゾーンに関するクエリ"www.victim.domain"をCache Serverが受け取ります。
  2. named.confで定義されたとおり、ブロッキング対象ゾーンの名前解決ではCache Serverは権威サーバとして動作します。
    しかし、このCache Serverが保持するゾーンファイル"blacklist.zone.db"には、このドメインに関するレコードが記述されていません。
  3. 従って、Cache Serverはブロッキング対象のドメインに関して名前を解決できません。
  4. DNSクライアントにレコードを参照できなかったことを示すREFUSEDを返します。

note:
"victim.domain"の権威サーバは別に存在します。

通常であればCache Serverは本来の役割として再帰問合せをクライアントから肩代わりし、名前解決を行います。ゾーンをオーバライドするという事の意味は、本来、自身で管理していないゾーンを自身が管理しているように見せかけるように上書きするという事です。

自ら答え(=否)を出してしまうのです。

ゾーンのオーバーライド方式のメリット、デメリット

  • メリット
    BINDバージョンを問いません。
    もっと言うと、DNSサーバのアプリを問いません。
    前述した通り、利用実績も豊富です。
  • デメリット
    この方式では、サービスの挙動を定義するコンフィグファイルを都度修正する必要があります。
    また、変更内容をサービスに適用するためにはサービスのリスタートも必要です。
    最も困ったことに、対象のキャッシュサーバが複数ある場合にはそれぞれに設定しなければならないことです。
    設定の変更管理方法についてはいくつか上手いやり方も考えれますが、使い勝手の良い方法があるのであれば、あえてこの方法を採用する理由は見当たりません。

例 あれ?どれいじったっけ?

メンテナンスが大変

RPZ(Response Policy Zone)の方式について

フルネームはResponse Policy Zoneです。BINDのバージョン 9.8以降から実装されました。RPZを実装したリスト配信サーバ(BIND)を用意して、Slaveサーバへブロッキングゾーンの設定を配布できます。

  • 転送にはゾーン転送(AXFR / IXFR)を使用します。 配信サーバ上でブロッキングリストの一元管理、リスト配信サーバから複数台のキャッシュサーバへリストの一括配信が可能な点がゾーンのオーバーライド方式との最も大きな違いです。

この点について言えば、ゾーンのオーバーライド方式に比べて実に上手いやり方です。

RPZ Blocking Overview

RPZ概要

Configuration on Distribution Master

設定

項目 説明
response-policy適用対象のゾーン RPZを宣言して、対象となるゾーンファイルを指定します。
response-policyで指定したゾーンの定義

基本的な設定内容はnamed.confのゾーン定義と同様です。
RPZによりブロックしたいドメイン名がリストされているゾーンファイルの参照先を指定します。
ゾーン転送に関するパラメータを定義します。
type:ブロックしたいゾーンのオリジナルデータを管理する場合は、"master"です。
file:オリジナルのゾーンファイルの場所を指定します。
also-notify:自身がmasterの場合にはNotifyの送信先を指定します。
also-transfer:許可するSlave Serverのアドレスを定義します。

※Slaveサーバのアドレスを複数指定する場合はセミコロン「;」を区切り文字にしてSlaveサーバのアドレスを併記してください。

基本的にはゾーンファイルの設定方法に倣います。
RPZで指定したゾーンファイル
レコードごとにルールをリアクションのポリシーを設定できます。
*. :NODATA
. :NXDOMAIN
FQDN :REDIRECT

Slaveの設定例

Configuration on Slave server

設定例

項目 説明
response-policy適用対象のゾーン RPZ(Response Policy Zone)を宣言して、対象となるゾーンファイルを指定します。
response-policyで指定したゾーンの定義 ゾーン転送の設定を定義しています。
type:対象のゾーン情報をDistribution Masterからコピーする場合には"Slave"です。
masters:Distribution Masterのアドレスを記入します。
file:コピーするゾーンファイルの保存名称を定義します。
also-transfer:基本的には"none"です。

ブロッキングゾーンの名前解決が無効化される仕組み

  1. ブロッキング対象のゾーンに関するクエリ"www.victim.domain"をCache Serverが受け取ります。
  2. Cache Serverはblacklist.zoneを参照し、ブロッキング対象ゾーンであることが判明しました。
  3. DNSクライアントにはresponse-policyに基づき、ドメインごとに定義されたリアクションを返します。
    "www.victim.domain"には "."(ピリオド)が設定されていますので、NXDOMAINが返されました。

RPZの方式のメリット、デメリット

これは便利

メリット

メリットデメリット

  • メリット
    ゾーンファイルのメンテナンスは、影響範囲も大きくリスクを伴います。
    RPZ方式の場合、複数のCache Serverが対象であってもディストリビューション・マスタに対してだけメンテナンスすれば良いため、非常に効率的です。
    また、RPZゾーンのみリロードでサービスに対して設定を反映できるため、サービス全体への影響を限定できます。
  • デメリット
    BIND9.8以降から実装されたため、実環境におけるプラクティスがあまり多くありません。[1]
    1 9.8.2以降が推奨されています。

[1] 9.8.2以降が推奨されています。

具体的な対策方法

今回のケースの場合、RPZを使った対策方法がシンプルです。
RPZのマスターを管理しているDNSへ調査によって明らかになった不正なドメインを追加してください。

「効果的な対策」の難しさ

悩ましいオーバブロッキング

DNSによるブロッキングには、必要以上にブロックしてしまう「オーバーブロッキング」の問題があります。
たとえば、「ドメイン名へのクエリを全てブロックする」と設定したとき、そのドメインから移譲されたサブドメインを使用している事業者へのクエリをまでブロックしてしまうという状況が発生します。

結局のところ、DNSブロッキングの仕組は提供されていますが「何をブロックすべきか」に関しての情報は範疇外とされており、管理者が独自に情報を収集し、解析し、最後に判断する必要があります。言うは易し、行うは難しとは正にこの事です。

DNSの障害は自社のシステムにとどまらずインターネット全体に波及するリスクを含んでいるため、管理者が担う責任とそれにかかる精神的な負担は尋常ではありません。

また数多く指摘されている通り、不正に利用されるドメインの試用期間は短く頻繁に更新されます。
Block(Black)リストを一人の管理者で管理するのは、非常に難しくリスクが高い作業と言えます。

過去の影響調査

注意喚起された後、その内容に基づいて監視方法を見直し改善することは重要ですが、喚起以前の遡及調査はそれと同じくらい重要です。恒常的な情報の収集と過去の情報を蓄積する仕組みがなければ、意味のある遡及調査や有事の際の影響が調査できず、本当に求められるリスク分析は行えません。

膨大なデータ

実際に通信データを目前にしたとき、その膨大な量と無秩序さに呆然とします。
とは言え予め弄した施策は大抵の場合有効ではありません。
問題の通信を特定する汎用的な方法はなく、インシデントによってその調査内容は異なります。

「管理者を」支援する仕組みの重要性

DNS通信を悪用した情報漏えいを防止するための対策を管理者だけに委ねるにはその対象となるデータはあまりに膨大でインシデントの発生頻度は尋常ではありません。
情報管理の観点からみて真に意義のある対策を実施するためには管理者を支援する仕組みが求められます。

  • DNSの通信をもれなく継続的に保全する仕組み
  • 膨大なデータを統計処理する仕組み(可視化できれば尚可)
  • インシデントの内容をもとにビンポイントで特定情報を抽出する仕組み(統計情報からドリルダウンできれば尚可)

フィードサービスなどを導入し、リストを用いたスクリーニングを実現できれば管理者の負担(精神的にも肉体的にも)は大幅に軽減されます。また、スクリーニングした情報を動的にBlock(Black)リストへ反映する仕組みを加えれば、人的ミスを防止できます。

結局のところ、「管理者を」支援する仕組みという表現は間違いです。
悪意のある者から情報を守るインフラを確立して「管理者」はそれを支援する、そのような仕組みづくりが必要です。

弊社の問題解決に対する基本的な考え方

弊社がパケットキャプチャ・ソリューション「momentum」シリーズを開発し、お客様にご提供する中で、一貫して考え続けているのは、

「分析のアプローチを明確にし、いかにスムーズでシームレスにこれらの各段階を提供するか」

ということです。この考え方を実現することにより、インシデント・レスポンスの短縮を図り、リスクを低減することが可能になるのです。

必要要件

弊社の製品・ソリューションに関するご質問・お問い合わせは momentum@terilogy.com までご連絡ください。

Terilogy HOME > momentum TOP > トピック:DNSを使用した遠隔操作ウィルスへの対策

デモ
momentum
オンラインデモ予約

「説明を聞きながら時間をかけずに理解したい」という方には、オンラインデモをご用意しています。日本全国どこでも、ご覧いただけますので、お気軽にお申込みください。

デモを予約する
デモ
momentum DNS viewer
今すぐ体験する

「自分で操作してみたい」という方には、セルフデモをご用意しています。今すぐDNS viewerを体験してください。

今すぐ体験する
資料請求
資料請求

momentumのカタログを
お届けします。

資料を請求する
テリロジーに相談
お問い合わせ

ご不明な点がありましたら、
お気軽にご連絡ください。
お急ぎの方は 03-3237-3291 へお電話ください。

ウェブからお問い合せ

トップへ