ネットワーク攻撃の多くは、最終的に**「通信を読む」ことに行き着きます。ARPスプーフィングで経路を奪い、DNSを乗っ取り、セッションに割り込む——そのすべての目的は、流れる情報を盗み見る・書き換えることにあります。本記事は、その「読む」フェーズ＝パケット盗聴（Sniffing）**を扱い、ネットワークペンテストクラスタを締めくくります。
ただし盗聴ツールの代表 Wireshark は、攻撃ツールであると同時に青チーム（防御側）の必須ツールでもあります。「自社の通信に平文が残っていないか」「このアプリは誰と何を話しているか」を可視化する——これは防御の出発点です。本記事は Wireshark を防御の道具として使い、TLS で盗聴を無害化する視点で進めます。
安全地帯の徹底：Wireshark で他者の通信を傍受するのは通信の秘密の侵害です。本記事のキャプチャは、すべて自分のマシンの通信、または隔離ラボの自分のVM間通信、書面で許可されたスコープに限ります。公衆Wi-Fiや社内LANで「他人のパケット」を覗くことは、不正アクセス禁止法・電気通信事業法に明確に違反します。法律の記事を必ず先に。
1. なぜ盗聴が成立するのか — 平文という無防備
ネットワークを流れるデータは、暗号化されていなければそのまま読めます。問題は、いまだに平文のプロトコルが現役で残っていることです。
| プロトコル | 平文版（危険） | 暗号化版（安全） | 漏れるもの |
|---|---|---|---|
| Web | HTTP | HTTPS（TLS） | Cookie・トークン・入力内容 |
| ファイル転送 | FTP / Telnet | SFTP / SSH | 認証情報そのもの |
| メール | SMTP / POP3 / IMAP | +STARTTLS / SMTPS | 認証情報・本文 |
| 名前解決 | DNS | DoH/DoT | 閲覧先の履歴 |
平文プロトコルでは、経路上の盗聴者がログイン情報・セッショントークン・個人情報を労せず取得できます。しかも盗聴は**受動的（パケットをコピーして読むだけ）**なので、送受信者には痕跡が残らず、検知が極めて難しいのが厄介な点です。
1.1 「スイッチだから安全」ではない
「スイッチング環境ではユニキャストは宛先にしか届かないから盗聴できない」——これは半分しか正しくありません。ARPスプーフィングで経路を自分に捻じ曲げれば、スイッチ環境でも通信は攻撃者を通過します。盗聴は単独で完結せず、MITM の「成果を読む」フェーズとして現れるのです。だから盗聴対策は MITM 対策と一体で考えます。
2. Wireshark を「防御の目」として使う
Wireshark は、自分の通信を解析する正当な用途でこそ真価を発揮します。自社のアプリが平文を漏らしていないかを、自分の目で確かめましょう。
2.1 自分の資産で「平文が残っていないか」を監査する
# 自分のホストのインターフェースで、平文 HTTP（443でなく80）が流れていないか確認
# ※自分の通信のみ。フィルタは Wireshark の表示フィルタにも使える
# tcp.port == 80 ← 平文 HTTP が残っていれば赤信号
# http.authorization ← 平文の認証ヘッダが見えたら重大
# ftp || telnet ← そもそも使っていないか
Wireshark の表示フィルタで http.request を見て、自社サービスへの通信がすべて 443（TLS）に乗っているかを確認します。もし tcp.port == 80 に認証情報やトークンが見えたら、それは設計の欠陥です。「平文の棚卸し」は、Wireshark を使う防御側の最も価値ある作業です。
2.2 TLS の中身は（正しく設定されていれば）読めない
同じ通信を TLS で行うと、Wireshark で見えるのは TLS ハンドシェイク（どのサーバーと、どの暗号スイートで）までで、アプリケーションデータは暗号文です。これが盗聴への根本的な答えです。
注意：Wireshark は、自分が鍵を持っている場合（
SSLKEYLOGFILEで自分のブラウザ/アプリの鍵をエクスポートした自分の通信）は TLS を復号して中身を見られます。これは自分の通信のデバッグのための機能であり、他者の TLS を復号できるわけではありません。
3. 防御の本命：TLS everywhere
盗聴への答えは、突き詰めれば一つ——すべての通信を暗号化する（TLS everywhere）。経路を奪われても、読めるのが暗号文だけなら盗聴は無意味になります。
3.1 HTTP→HTTPS の格上げを「強制」する — HSTS
TLS を入れても、最初のアクセスが HTTP だと、その一手を SSL ストリップで狙われます。**HSTS（HTTP Strict Transport Security）**で「このサイトは常に HTTPS」をブラウザに強制し、平文での接続自体を起こさせません。
// Next.js / Node：HSTS で HTTPS を強制（preload まで行うと初回から HTTPS 固定）
// 値の意味：2年間・サブドメイン含め・preload リストに登録可能
const SECURITY_HEADERS = {
"Strict-Transport-Security": "max-age=63072000; includeSubDomains; preload",
} as const;
// Next.js の next.config.ts なら headers() で全レスポンスに付与する
export const headers = async () => [
{ source: "/(.*)", headers: Object.entries(SECURITY_HEADERS).map(([key, value]) => ({ key, value })) },
];
3.2 前方秘匿性（PFS）— 「将来鍵が漏れても過去は守る」
盗聴者が暗号文を保存しておき、将来サーバーの秘密鍵を入手したら遡って復号する——この「いま盗んで後で読む（harvest now, decrypt later）」攻撃に備えるのが**前方秘匿性（Perfect Forward Secrecy）**です。セッションごとに使い捨ての鍵を交換するため、長期鍵が漏れても過去のセッションは復号できません。TLS 1.3 は PFS を標準とし、PFS のない鍵交換を廃止しました。TLS 1.3 を使うこと自体が PFS の担保になります。
import tls from "node:tls";
// サーバー側：TLS 1.3 を最低バージョンに（PFS 標準・古い脆弱な暗号スイートを排除）
const server = tls.createServer({
minVersion: "TLSv1.3", // 1.2 以下の既知の弱点と非PFS鍵交換を構造的に排除
// cert/key は環境変数や Secrets Manager 経由で注入（ハードコード厳禁）
});
server.on("error", (e) => console.error("tls server error:", e.message));
3.3 内部通信も暗号化する — mTLS とゼロトラスト
「外向きは HTTPS、社内は平文」——これは最も多い盲点です。MITM は社内ネットワークでこそ成立しやすい。サービス間通信を相互TLS（mTLS）で暗号化・相互認証すれば、内部に侵入されても盗聴は無意味になります。これはARP 記事で述べたゼロトラストの核心——「ネットワーク位置を信頼の根拠にしない」——の実装です。
4. 防御の運用チェックリスト
- 自社の全通信が TLS に乗っているか（Wireshark で
tcp.port == 80に機密が流れないことを確認）。 - **HSTS（preload 推奨）**を設定し、平文接続を起こさせないか。
- サーバーの **TLS 最低バージョンが 1.3（最低でも 1.2）**で、弱い暗号スイートを排除しているか。
- 内部・サービス間通信を mTLS で暗号化・相互認証しているか。
- DNS も DoH/DoT で暗号化し、閲覧履歴の漏洩を防いでいるか。
- 証明書の自動更新・失効監視を運用しているか（期限切れTLSは平文への退行を招く）。
- TLS 証明書検証を無効化していないか（
rejectUnauthorized: falseの混入をCIで検出）。
5. まとめ — そしてクラスタ全体の結論
- パケット盗聴は受動的で痕跡が残りにくい。平文プロトコル（HTTP/FTP/Telnet）は認証情報・個人情報を素通しにする。
- スイッチ環境でも MITM 経由で盗聴は成立する。盗聴は「読む」フェーズとして他の攻撃と連鎖する。
- Wireshark は防御の目：自分の資産で「平文が残っていないか」を監査する正当な必須スキル。
- 防御の本命は TLS everywhere：暗号化（読めない）＋ HSTS（平文に退行させない）＋ PFS/TLS 1.3（将来も守る）＋ mTLS（内部も信頼しない）。
そして、本ネットワークペンテストクラスタ全体を貫く結論はこれです——攻撃手法は L2 から L4 まで多様でも、効く防御は驚くほど少数の原則（暗号化・暗号学的検証・ゼロトラスト・最小化）に収束する。攻撃者の手口を一つずつ理解した者だけが、設計段階でこの少数の原則を正しい場所に置けます。攻めの理解は、守りの設計に直結する——これが、攻撃技法を学ぶ本当の理由です。
私（友田 陽大）は、本番システムの TLS everywhere 化（HSTS・TLS 1.3・証明書自動更新）、サービス間 mTLS、平文通信の棚卸しと根絶を実装してきました。「社内に平文通信が残っていないか診断したい」「mTLS でゼロトラストを実装したい」「TLS 設定が古くないか棚卸ししたい」——こうした“盗聴を無意味化する”設計を、攻撃者の視点で診断し、暗号化と検証の両輪で根治します。お気軽にご相談ください。