# パケット盗聴（Sniffing）の脅威と防御【2026】— Wireshark で理解し TLS everywhere で無害化する

> パケット盗聴の脅威を、Wireshark を使った『自分の通信の可視化』から理解し、TLS による無害化まで体系的に解説。なぜ平文プロトコル（HTTP・FTP・Telnet）が危険なのか、スイッチング環境でもなぜ盗聴が成立するのか（MITM 連携）を示し、TLS everywhere・mTLS・HSTS・前方秘匿性という防御を、型安全なコードと運用の観点で解説します。Wireshark は青チーム（防御）の必須スキルとして、自分の資産の通信解析に使います。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: セキュリティ, ネットワーク, TCP/IP, 脆弱性診断, 可観測性, 倫理的ハッキング
- URL: https://tomodahinata.com/blog/packet-sniffing-wireshark-tls-encryption-defense-guide
- カテゴリ: 実践ネットワーク攻撃と防御
- 総合ガイド: https://tomodahinata.com/blog/network-penetration-testing-methodology-attack-defense-guide

## 要点

- パケット盗聴は経路上を流れる通信を傍受する受動的攻撃。平文（HTTP/FTP/Telnet/SMTP）なら認証情報も個人情報もそのまま読める。受動的ゆえ痕跡が残りにくく検知が難しい
- スイッチング環境では本来ユニキャストは他者に届かないが、ARPスプーフィングで経路を奪えば（MITM）盗聴は成立する。盗聴は単独でなく MITM の『成果を読む』フェーズとして現れる
- Wireshark は攻撃ツールであると同時に、青チーム（防御）の必須ツール。自分の通信・自社の通信を解析し『平文が残っていないか』『誰と何を話しているか』を可視化する正当な用途が中心
- 防御の本命は TLS everywhere。経路を奪われ盗聴されても、TLS で暗号化されていれば読めるのは暗号文だけ。HTTP→HTTPS の格上げを HSTS で強制し、SSL ストリップを封じる
- さらに前方秘匿性（PFS, TLS 1.3 標準）で『将来鍵が漏れても過去の通信は復号できない』を担保し、内部通信は mTLS で相互認証する。盗聴を構造的に無意味化するのがゴール

---

ネットワーク攻撃の多くは、最終的に**「通信を読む」**ことに行き着きます。[ARPスプーフィングで経路を奪い](/blog/arp-spoofing-mitm-attack-detection-defense-guide)、[DNSを乗っ取り](/blog/dns-spoofing-cache-poisoning-dnssec-defense-guide)、[セッションに割り込む](/blog/tcp-session-hijacking-rst-injection-ip-spoofing-defense-guide)——そのすべての目的は、流れる情報を盗み見る・書き換えることにあります。本記事は、その**「読む」フェーズ＝パケット盗聴（Sniffing）**を扱い、[ネットワークペンテストクラスタ](/blog/network-penetration-testing-methodology-attack-defense-guide)を締めくくります。

ただし盗聴ツールの代表 **Wireshark** は、攻撃ツールであると同時に**青チーム（防御側）の必須ツール**でもあります。「自社の通信に平文が残っていないか」「このアプリは誰と何を話しているか」を可視化する——これは防御の出発点です。本記事は **Wireshark を防御の道具として使い、TLS で盗聴を無害化する**視点で進めます。

> **安全地帯の徹底**：Wireshark で他者の通信を傍受するのは**通信の秘密の侵害**です。本記事のキャプチャは、すべて**自分のマシンの通信**、または[隔離ラボ](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide)の自分のVM間通信、書面で許可されたスコープに限ります。公衆Wi-Fiや社内LANで「他人のパケット」を覗くことは、不正アクセス禁止法・電気通信事業法に明確に違反します。[法律の記事](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide)を必ず先に。

---

## 1. なぜ盗聴が成立するのか — 平文という無防備

ネットワークを流れるデータは、暗号化されていなければ**そのまま読めます**。問題は、いまだに平文のプロトコルが現役で残っていることです。

| プロトコル | 平文版（危険） | 暗号化版（安全） | 漏れるもの |
|---|---|---|---|
| Web | HTTP | **HTTPS（TLS）** | Cookie・トークン・入力内容 |
| ファイル転送 | FTP / Telnet | **SFTP / SSH** | 認証情報そのもの |
| メール | SMTP / POP3 / IMAP | **+STARTTLS / SMTPS** | 認証情報・本文 |
| 名前解決 | DNS | **[DoH/DoT](/blog/dns-spoofing-cache-poisoning-dnssec-defense-guide)** | 閲覧先の履歴 |

平文プロトコルでは、経路上の盗聴者が**ログイン情報・セッショントークン・個人情報を労せず取得**できます。しかも盗聴は**受動的（パケットをコピーして読むだけ）**なので、送受信者には痕跡が残らず、**検知が極めて難しい**のが厄介な点です。

### 1.1 「スイッチだから安全」ではない

「スイッチング環境ではユニキャストは宛先にしか届かないから盗聴できない」——これは半分しか正しくありません。[ARPスプーフィング](/blog/arp-spoofing-mitm-attack-detection-defense-guide)で経路を自分に捻じ曲げれば、スイッチ環境でも通信は攻撃者を通過します。**盗聴は単独で完結せず、MITM の「成果を読む」フェーズ**として現れるのです。だから盗聴対策は MITM 対策と一体で考えます。

---

## 2. Wireshark を「防御の目」として使う

Wireshark は、自分の通信を解析する正当な用途でこそ真価を発揮します。**自社のアプリが平文を漏らしていないか**を、自分の目で確かめましょう。

### 2.1 自分の資産で「平文が残っていないか」を監査する

```bash
# 自分のホストのインターフェースで、平文 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 ストリップ](/blog/arp-spoofing-mitm-attack-detection-defense-guide)で狙われます。**HSTS（HTTP Strict Transport Security）**で「このサイトは常に HTTPS」をブラウザに強制し、平文での接続自体を起こさせません。

```ts
// 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 の担保**になります。

```ts
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 記事](/blog/arp-spoofing-mitm-attack-detection-defense-guide)で述べたゼロトラストの核心——**「ネットワーク位置を信頼の根拠にしない」**——の実装です。

---

## 4. 防御の運用チェックリスト

- [ ] **自社の全通信が TLS に乗っている**か（Wireshark で `tcp.port == 80` に機密が流れないことを確認）。
- [ ] **HSTS（preload 推奨）**を設定し、平文接続を起こさせないか。
- [ ] サーバーの **TLS 最低バージョンが 1.3（最低でも 1.2）**で、弱い暗号スイートを排除しているか。
- [ ] **内部・サービス間通信を mTLS** で暗号化・相互認証しているか。
- [ ] [DNS も DoH/DoT](/blog/dns-spoofing-cache-poisoning-dnssec-defense-guide) で暗号化し、閲覧履歴の漏洩を防いでいるか。
- [ ] 証明書の**自動更新・失効監視**を運用しているか（期限切れTLSは平文への退行を招く）。
- [ ] **TLS 証明書検証を無効化していない**か（`rejectUnauthorized: false` の混入をCIで検出）。

---

## 5. まとめ — そしてクラスタ全体の結論

- **パケット盗聴は受動的で痕跡が残りにくい**。平文プロトコル（HTTP/FTP/Telnet）は認証情報・個人情報を素通しにする。
- **スイッチ環境でも MITM 経由で盗聴は成立**する。盗聴は「読む」フェーズとして他の攻撃と連鎖する。
- **Wireshark は防御の目**：自分の資産で「平文が残っていないか」を監査する正当な必須スキル。
- **防御の本命は TLS everywhere**：暗号化（読めない）＋ HSTS（平文に退行させない）＋ PFS/TLS 1.3（将来も守る）＋ mTLS（内部も信頼しない）。

そして、本[ネットワークペンテストクラスタ](/blog/network-penetration-testing-methodology-attack-defense-guide)全体を貫く結論はこれです——**攻撃手法は L2 から L4 まで多様でも、効く防御は驚くほど少数の原則（暗号化・暗号学的検証・ゼロトラスト・最小化）に収束する**。攻撃者の手口を一つずつ理解した者だけが、設計段階でこの少数の原則を正しい場所に置けます。**攻めの理解は、守りの設計に直結する**——これが、攻撃技法を学ぶ本当の理由です。

---

私（友田 陽大）は、本番システムの TLS everywhere 化（HSTS・TLS 1.3・証明書自動更新）、サービス間 mTLS、平文通信の棚卸しと根絶を実装してきました。「社内に平文通信が残っていないか診断したい」「mTLS でゼロトラストを実装したい」「TLS 設定が古くないか棚卸ししたい」——こうした“盗聴を無意味化する”設計を、攻撃者の視点で診断し、暗号化と検証の両輪で根治します。お気軽にご相談ください。