DNSおよびARPトラフィックトリアージラボ

Arch Linuxワークステーション上で実施された、教育用パケット解析とリゾルバ強化演習です。

Scope: このリポジトリは学習プロジェクトです。含まれているキャプチャはDNSおよびARPインスペクションの練習に有用ですが、それ自体がアクティブなキャッシュポイズニング攻撃、悪意のあるハードウェア、特定のCVEの悪用、またはNetworkManagerルーティングメトリックへの因果関係を証明するものではありません。

このプロジェクトを改訂した理由

最初の文書では、いくつかの観測を確定した原因として扱っていました。それは過剰でした。839バイトのDNSフレームは自動的に不正形式や悪意があるわけではなく、DNS-over-TLSは設定されたアップストリームリゾルバへのDNSトラフィックを保護しますが、ARPスプーフィングやすべてのレイヤ2/3攻撃を止めるわけではありません。

改訂版では、ラボの有用な部分を維持しつつ、以下を分離しています:

1. 提供されたデータが示すもの;
2. 私が当初疑っていたもの;
3. さらに証拠が必要となるもの;
4. リゾルバ構成が実際に変更するもの。

その区別は、適切なインシデント対応の一部です。証拠が支持する以上を主張するよりも、結論を絞り込む方がよいです。

ラボの目標

• Wiresharkおよびtsharkを使用してDNSおよびARPトラフィックを検査する。
• 平文DNSを暗号化として誤ってラベル付けせずに、ローカルリゾルバの結果を既知の公開リゾルバと比較する。
• 認証されたTLSを介してアップストリームDNSクエリを転送するようにUnboundを構成する。
• 制限と代替説明を文書化する。
• 他の人が再現可能な手順を作成する。

環境

• Arch Linuxワークステーション
• Wireshark / tshark
• BIND dig
• Unboundローカルリゾルバ
• TCP/853上のCloudflareおよびQuad9アップストリームリゾルバ

ラボを再実行する際には、正確なパッケージバージョンを記録する必要があります。現在のリポジトリには、トラフィックを製品の脆弱性に帰属させるのに十分なバージョンメタデータが含まれていません。

提供された証拠

レビューの再現

1. ファイル整合性の記録

sha256sum evidence/incident_triage_snippet.pcap
capinfos evidence/incident_triage_snippet.pcap

ハッシュとキャプチャメタデータをノートとともに保存します。キャプチャを「完全なインシデント証拠」と呼んではいけません。それはスニペットです。

2. ARPトラフィックのレビュー

tshark -r evidence/incident_triage_snippet.pcap -Y arp \
  -T fields -e frame.number -e frame.time_relative \
  -e arp.opcode -e arp.src.proto_ipv4 -e arp.src.hw_mac \
  -e arp.dst.proto_ipv4 -e arp.dst.hw_mac

繰り返し発生する、または競合するIP-to-MACの主張を探します。競合は調査すべき手がかりであり、攻撃者の自動的な証明ではありません。アドレスが合成ラボ値であるか、デバイスが正当に変更されたか、タイミングが仮説を支持するかを確認します。

3. DNSトラフィックのレビュー

tshark -r evidence/incident_triage_snippet.pcap -Y dns \
  -T fields -e frame.number -e frame.time_relative \
  -e ip.src -e ip.dst -e udp.srcport -e udp.dstport \
  -e dns.id -e dns.flags.response -e dns.qry.name \
  -e dns.count.answers -e frame.len

有用なフォローアップフィルター:

dns && frame.len == 839
dns.flags.response == 1
dns.qry.name == "."
arp.duplicate-address-detected || arp.duplicate-address-frame

パケットサイズだけでは判断できません。DNS応答サイズは、レコード数、EDNS、DNSSEC、トランスポート動作によって異なる場合があります。デコードされたレコードを検査し、既知の良好なベースラインと比較します。

4. リゾルバの比較

chmod +x scripts/checkdns.sh
./scripts/checkdns.sh example.com

このスクリプトは、dig @1.1.1.1 の直接クエリをポート53上の平文DNSとして正しくラベル付けします。kdig が利用可能な場合、別途TLSテストも実行します。

5. Unbound転送の検証

configs/unbound.confを確認し、証明書パスをローカルシステムに適応させ、使用前に検証します:

sudo unbound-checkconf configs/unbound.conf
sudo ss -tnp | grep ':853'
dig @127.0.0.1 example.com

成功したクエリとTCP/853への確立された接続は、UnboundがTLSを介して設定されたアップストリームに転送しているという、より狭い結論を支持します。無関係なARPやルーティングの問題が排除されたことを証明するものではありません。

発見と制限

• キャプチャはDNSおよびARPフレームを識別し、構造化レビューを練習するために使用できます。
• 839バイトのDNSフレームは観測であり、それ自体が侵害の指標ではありません。
• 現在の証拠は脆弱なBIND 9リゾルバや影響を受けるバージョンを特定していないため、CVE-2025-40778はインシデント属性ではなく背景研究です。
• 認証されたDNS-over-TLSは、このリゾルバとそのアップストリーム間の機密性と完全性を向上させます。ローカルネットワーク全体を保護するわけではありません。
• 強力な属性付けには、完全なキャプチャの出所、デバイスインベントリ、リゾルバ/バージョンの証拠、パケット番号参照、タイムスタンプ、再現可能な前後テストが必要です。

参考文献

• RFC 7858 — DNS over TLS
• RFC 8310 — DNS Privacy Usage Profiles
• ISC advisory for CVE-2025-40778
• Wireshark display-filter reference

法的およびプライバシーに関する注意

パケットキャプチャおよびネットワークテストツールは、所有しているかテストを許可されているシステムとネットワークでのみ使用してください。公開する前に、キャプチャ内のプライベートアドレス、ホスト名、トークン、認証情報、個人情報を確認してください。