【実務・中級編】 DNSトンネリング検知におけるTXTレコードおよびNULLレコードのパケット長・エントロピー解析 – サイバーセキュリティとプライバシー保護実践ガイド

境界防御の盲点「DNSトンネリング」を暴く:エントロピー解析が導く真実

ネットワークエンジニアとして現場を歩いていると、「ファイアウォールでブロックしているはずなのに、なぜか不審な通信が漏れ出している」という悪夢のような相談を受けることがあります。その黒幕の多くが、OSI参照モデルの深層、あるいは「通信のインフラ」であるDNSを利用したトンネリングです。

今日は、DNSを悪用してC2(Command and Control)サーバーと通信するマルウェアを、パケットの「行儀の悪さ」から見破るための技術的アプローチについて解説します。

—

なぜDNSなのか?:パケットに隠された「密書」

DNSは、本来名前解決のためのプロトコルです。しかし、そのクエリやレスポンスには、TXTレコードやNULLレコードといった、本来の目的以外にもデータを詰め込める「遊び」があります。攻撃者はここにBase64などでエンコードしたコマンドや窃取データを忍ばせ、再帰リゾルバーを介して社外の管理サーバーへ送り込みます。

ファイアウォールは「ポート53を通る通信」を許可しているため、この「密書」は平然とゲートを通り抜けていきます。これを防ぐには、パケットの「中身」を統計的に解析するセンサーが必要です。

—

センサーの目:エントロピーとパケット長

DNSトンネリングを検知するための鍵は、二つの指標にあります。

1. パケット長: 通常のDNSクエリは非常に短く、定型的です。しかし、トンネリングでは最大容量までデータを詰め込むため、パケット長が異常に大きくなります。
2. シャノンエントロピー: 「ランダム性」の指標です。人間が書いたドメイン名(google.comなど)は特定の言語規則に従いますが、暗号化や圧縮されたデータは極めて高いエントロピー(乱雑さ)を示します。

検知ロジックの概念コード(Python)

センサーを自作する際、まずはエントロピー計算の基礎を押さえておくべきです。以下のコードは、ペイロードがどれだけ「不自然」かを算出するスニペットです。

import math
from collections import Counter

def calculate_entropy(data):
    """
    データのシャノンエントロピーを算出。
    値が8に近いほど、完全にランダム(暗号化/圧縮データ)であることを示す。
    """
    if not data:
        return 0
    
    counts = Counter(data)
    length = len(data)
    entropy = 0
    
    for count in counts.values():
        p = count / length
        entropy -= p * math.log2(p)
        
    return entropy

# 検証用:通常のドメイン vs トンネリングされたTXTレコードデータ
normal_query = "google.com"
tunnel_payload = "aGk0ODlqZm5zZGZqbnMyMjhqZm5zZGpma25zZGpma25zZGZqazIzODk0"

print(f"Normal Entropy: {calculate_entropy(normal_query):.2f}")
print(f"Tunnel Entropy: {calculate_entropy(tunnel_payload):.2f}")

—

現場で役立つ確認コマンド

もしあなたが「社内の端末から不審なDNSリクエストが出ていないか」を調査するなら、まずは tshark や tcpdump でパケットをキャプチャし、統計を取るのが定石です。

# 特定のクライアントIPからのDNSトラフィックを抽出し、TXTレコードの長さを確認する
sudo tshark -i eth0 -f "udp port 53" -Y "dns.qry.type == 16" -T fields -e dns.qry.name -e frame.len

上記のコマンドで、frame.len が極端に大きいものや、dns.qry.name が [ランダム文字列].example.com のような形式になっていないかをスクリーニングします。

—

実務上のTips:誤検知を減らすために

ただ単に「エントロピーが高いからブロック」と設定すると、CDNや最新のセキュリティソリューションのDNS通信まで巻き込んで業務を止めることになります。運用において重要なのは、以下の3点です。

  • ホワイトリスト運用: _dmarc や _domainkey など、正当な理由で長いTXTレコードを使用するドメインは明示的に除外する。
  • 閾値の動的調整: ネットワークのトラフィック特性に合わせて、エントロピーのしきい値を自動調整するアルゴリズムを導入する。
  • 通信頻度の相関: 単一のパケットを見るのではなく、短時間に同じドメインへの問い合わせが異常に繰り返されていないか(Time-Series Analysis)を併用する。

—

最後に:ネットワークは「嘘をつかない」

DNSトンネリングは、攻撃者にとっての「最後の隠れ家」です。しかし、パケットを流す以上、必ず物理的な痕跡を残します。

「便利さ」のために空けているポート53が、実は企業の全財産を外へ運び出すトンネルになっていないか。インフラエンジニアの皆さんは、ぜひ今日の帰りにでも、自身のネットワークのDNSログを眺めてみてください。そこには、教科書には載っていない「通信のリアル」が刻まれています。

何かあれば、またいつでも質問してください。エンジニアの現場は、今日も戦場ですからね。

コメント

タイトルとURLをコピーしました