DNSトンネリングとは？C2通信に悪用される仕組みと検知・遮断の実践ガイド

DNSはほぼすべてのファイアウォールで許可されているプロトコルです。その「誰でも通れる抜け穴」を悪用して、マルウェアが外部の攻撃者サーバーと密かに通信する手口がDNSトンネリングです。

ファイアウォールのログにHTTPS通信の痕跡がなくても、外部への大量のDNSクエリが記録されていたら要注意です。実際、エンドポイントに感染したマルウェアが数ヶ月にわたってDNSトンネリングで社内情報を抜き続けていた、という国内企業のインシデントも報告されています。

この記事では、DNSトンネリングの仕組み・C2通信への悪用手口・検知ポイント・遮断手順を、現場のインフラエンジニア・情シス担当者が今日から使えるレベルで解説します。

DNSトンネリングとは？なぜ今注目されるのか

DNSトンネリングとは、DNS（ドメインネームシステム）プロトコルを本来の名前解決以外の目的に転用し、データ通信のトンネルとして利用する技術です。もともとはネットワーク制限を迂回するための研究用途でしたが、現在は攻撃者がマルウェアのC2（コマンド＆コントロール）通信やデータ窃取に積極的に使っています。

DNSが悪用される理由は明快です。

・ポート53が常に開いている: 企業ネットワークでDNSを完全にブロックすると、業務システムそのものが止まります。攻撃者はこの「絶対に塞げないポート」を狙います。
・平文で大量のクエリが流れる: 通常業務でも毎秒何十件ものDNSクエリが発生するため、悪意あるクエリが埋もれやすい状態です。
・多くのファイアウォールがDNSを精査しない: HTTPSは復号インスペクションを挟む企業も増えましたが、DNSの中身まで精査している組織はまだ少数です。

IPAの「情報セキュリティ10大脅威 2026」でも標的型攻撃・サプライチェーン攻撃が上位を占めており、その長期潜伏を支える手口としてDNSトンネリングが確認されています。

攻撃の仕組み：DNSクエリにデータを隠す

攻撃者がDNSトンネリングを使ってC2通信を確立する流れを見ていきましょう。

1. 攻撃者が悪意あるDNSサーバーを用意する

攻撃者はまず、自分が管理するドメイン（例: evil-domain.example）の権威DNSサーバーをインターネット上に設置します。このサーバーが「C2サーバー」の役割を果たします。

2. マルウェアがDNSクエリにデータを埋め込む

感染端末にインストールされたマルウェアは、送信したいデータ（例: 盗んだファイルの断片）をBase64やBase32でエンコードし、サブドメイン部分に埋め込んでDNSクエリを送信します。

# 通常のDNSクエリ
www.google.com → 正常なドメイン解決

# DNSトンネリングのクエリ例（データを埋め込んだサブドメイン）
aGVsbG8gd29ybGQ.evil-domain.example → Base64エンコードされたデータ
dGhpcyBpcyBhIHNlY3JldA.evil-domain.example → C2へのデータ送信

企業のリカーシブリゾルバ（再帰的DNSサーバー）はこのクエリを正規のDNS解決として転送し、攻撃者の権威DNSサーバーが受信します。

3. レスポンスにコマンドが返ってくる

攻撃者のDNSサーバーは、TXTレコードやCNAMEレコードのレスポンスにコマンドを埋め込んで返します。マルウェアはそのレスポンスを復号してコマンドを実行します。この繰り返しで、見かけ上はDNS通信だけで双方向のC2セッションが確立します。

DNSトンネリングの主な悪用目的

・C2通信の確立: マルウェアへのコマンド送信と実行結果の受信
・データ窃取（DNS Exfiltration）: 機密ファイルをDNSクエリに分割して外部送信
・ファイアウォール迂回: HTTPS通信を完全にブロックされた環境でも通信を維持
・長期潜伏: 通常のDNSトラフィックに紛れて検知を回避しながら長期間活動

なお、DNSトンネリングのツールは複数存在することが研究論文・セキュリティカンファレンスで公開されており、攻撃者が自由に入手できる状況です。悪用目的での使用は不正アクセス禁止法・電子計算機使用詐欺罪等に抵触します。法的な詳細は専門家にご確認ください。

DNSトンネリングの検知：ログから異常を見つける

DNSトンネリングは「隠すのが目的」の通信です。しかし特有のパターンがあり、ログを正しく収集・分析すれば検知できます。

1. DNSクエリログを収集する

まずDNSクエリを記録する環境を整えます。多くの企業では内部のリカーシブリゾルバ（BIND、Unbound、dnsmasq等）を使っています。

# BINDでクエリログを有効化（named.conf の options セクションに追記）
# デフォルトはオフのため明示的に有効にする
logging {
    channel query_log {
        file "/var/log/named/query.log" versions 7 size 20m;
        severity dynamic;
        print-time yes;
    };
    category queries { query_log; };
};

# ログ出力例
; Aug 17 10:23:41.123 queries: client 192.168.1.50#54321: query: aGVsbG8.evil-domain.example IN A

Windowsの場合はDNSサーバーロールの「デバッグログ」またはイベントIDで収集できます。SaaS環境ではCloudflare Gateway等のDNSリゾルバがクエリログをダッシュボードで提供しています。

2. 異常の特徴を把握する

DNSトンネリングのクエリには通常の名前解決と異なる特徴があります。

特にサブドメインのエントロピー（文字のランダム性）は有効な指標です。「aGVsbG8.evil-domain.example」のようなクエリは、通常業務では発生しません。

3. Suricataでシグネチャ検知を設定する

ネットワーク型IDS/IDSであるSuricataは、DNSトンネリングの検知ルールを自前で追加できます。

# /etc/suricata/rules/local.rules に追加
# TXTレコードへの大量問い合わせを検知（DNSトンネリングの疑い）
alert dns any any -> any 53 (msg:"DNS Tunneling TXT Record Anomaly"; dns.query; content:"."; pcre:"/^[a-zA-Z0-9+\/]{40,}\./"; classtype:policy-violation; sid:9000001; rev:1;)

# 同一ドメインへの高頻度クエリ検知（閾値は環境に合わせて調整）
alert dns any any -> any 53 (msg:"DNS High Frequency Query Possible Tunneling"; threshold:type threshold, track by_src, count 30, seconds 10; classtype:policy-violation; sid:9000002; rev:1;)

Suricataのルールは定期的に更新されるEmergingThreatsプロファイルにもDNSトンネリング関連シグネチャが含まれています。まずは既存の有効なルールセットを確認してください。

4. SIEMでアラートを集約する

SIEM（セキュリティ情報イベント管理）にDNSクエリログを取り込み、エントロピーが高いクエリ・TXTレコードの大量問い合わせ・特定の外部DNSサーバーへの集中を相関ルールで検知する構成が理想です。中小規模ではWazuhのようなオープンソースSIEMでも対応できます。

DNSトンネリングの遮断と防御

1. DNSフィルタリングで悪意あるドメインを遮断

DNSフィルタリングは、既知の悪意あるドメインへの名前解決をブロックする最も即効性のある対策です。Cloudflare GatewayやCisco Umbrellaは脅威インテリジェンスと連携し、DNSトンネリングに悪用されているドメインをリアルタイムでブロックします。

DNSフィルタリングのポイントはすべての端末のDNS問い合わせ先を管理下のリゾルバに向けることです。端末が任意の外部DNSサーバー（8.8.8.8等）に直接クエリを送れる状態では、DNSフィルタリングを迂回されます。

# ファイアウォールで外部への直接DNS通信を制限（firewalldの例）
# 内部DNSサーバー(192.168.1.1)以外からのポート53アウトバウンドを拒否
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 \
  -p udp --dport 53 ! -d 192.168.1.1 -j DROP
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 \
  -p tcp --dport 53 ! -d 192.168.1.1 -j DROP
firewall-cmd --reload

2. 再帰リゾルバを内部に限定する

外部の任意の権威DNSサーバーへの直接アクセスを制限します。社内のリカーシブリゾルバ経由でのみ名前解決を許可し、端末から外部ポート53への直接通信をファイアウォールでブロックすることで、C2サーバーへの直接クエリを防ぎます。

3. DNS over HTTPS（DoH）・DNS over TLS（DoT）を活用する

DNS over HTTPS（DoH）やDNS over TLS（DoT）は、DNSクエリを暗号化してプロバイダ・攻撃者による盗聴を防ぎます。一方で、企業として管理するDNSゲートウェイ経由でDoH/DoTを集約することで、暗号化しながらもフィルタリングとログ収集を維持できます。

社内全端末のDoH先をCloudflare Gateway等のフィルタリング付きDNSに統一するのが現実的な構成です。

4. ボットネット・C2通信の全体像を把握する

DNSトンネリングは単体で使われることは少なく、ボットネットのC2インフラの一部として組み込まれているケースが多いです。DNSトンネリングを検知したら、その端末が他のC2通信（HTTPSビーコン等）を行っていないか横断的に調査してください。

中小企業でも今日からできること

専用のDNS分析ツールや高額なSIEMがなくても、以下の対策から始められます。

・DNSクエリログを有効化する: BINDやdnsmasqのクエリログは設定変更だけで有効になります。まずログを「取る」環境を整えてください。
・外部への直接DNS通信をブロックする: ファイアウォールでポート53アウトバウンドを社内リゾルバ経由に制限するだけで、多くのDNSトンネリングツールを無効化できます。
・無料のDNSフィルタリングを導入する: Cloudflare Gatewayの無料プランや、Quad9（9.9.9.9）はマルウェアドメインのフィルタリング機能を提供しています。
・週次でDNSログの外れ値を確認する: 同一ドメインへの問い合わせ件数ランキングを週次でざっと眺めるだけで、異常なドメインへの大量クエリを発見できることがあります。
・姉妹サイトのLinuxサーバー設定を参考にする: DNSサーバーをLinuxで運用している場合は、姉妹サイトLinuxMaster.JPのログ管理・ファイアウォール設定記事も参考になります。

よくある誤解と注意点

「ウイルス対策ソフトがあれば検知できる」は誤り
エンドポイント保護（EPP）はファイルベースのマルウェアが主な対象です。DNSトンネリングを行うマルウェアは、正規プロセスを乗っ取るファイルレス型や、難読化コードを使うケースも多く、シグネチャベースのウイルス対策だけでは検知しきれません。DNSログの監視・ネットワーク型IDSと組み合わせた多層防御が必要です。

「HTTPSをブロックすればDNSトンネリングも防げる」は誤り
DNSトンネリングはHTTPSと独立したチャネルです。HTTPS通信を完全にブロックしても、ポート53（UDP/TCP）が開いている限りDNSトンネリングは機能します。

「DNSトンネリングは検知不可能」は誤り
完全に隠ぺいするのは困難で、クエリの長さ・頻度・エントロピーという特徴が残ります。ログを取る環境さえ整えれば、異常な通信パターンを見つけることは十分に可能です。

「社内のみで完結しているから安全」は誤り
DNSトンネリングはインターネット側の権威DNSサーバーとの通信が必要です。社内リカーシブリゾルバ経由であっても、外部ドメインへの問い合わせが攻撃者サーバーに届きます。外向きのDNSフィルタリングは必須です。

本記事のまとめ

DNSトンネリングは「誰でも通れる」DNSプロトコルを悪用した高度な回避技術ですが、適切なログ収集と分析で検知・遮断が可能です。

「DNSは信頼できる」という思い込みを捨て、DNSログを日常の監視対象に加えることが、ステルスC2通信に対する最初の一手です。