ネットワークセキュリティ基礎 — TCP/IP・DNS の脆さと HTTPS の防壁

ネットワークプロトコルの「性善説」という脆弱性

私たちが毎日使っているインターネットの基幹プロトコル群（TCP/IP、DNS、BGPなど）は、1970〜80年代の研究者コミュニティ向けに設計されました。当時の前提は「利用者はすべて信頼できる」という性善説であり、認証も暗号化もデフォルトでは組み込まれていません。

その結果、ネットワーク上には常に「傍受」「改ざん」「なりすまし」の脅威が潜んでいます。現代の防御者はプロトコルごとの「構造的な弱点」を理解した上で、後付けされたセキュリティ層（TLSやIPsecなど）を正しく設計・デプロイしなければなりません。

「なぜHTTPSが必要なのか」を本当に理解するには、「HTTPがどれほど危険か」を知る必要があります。

OSI参照モデルに見る攻撃サーフェス

ネットワーク通信を7階層に分けたOSIモデルは、攻撃者がどのレイヤーを狙っているかを整理するのに非常に役立ちます。ペネトレーションテストを実施するとき、テスターは必ずこのレイヤーを意識して攻撃経路を探ります。

TCP/IPに対する典型的な攻撃

TCPの3ウェイハンドシェイクと枯渇攻撃

TCP通信は、信頼性を担保するために通信開始時に「3ウェイハンドシェイク」を行います。

クライアント → SYN       → サーバー （ポート開けて！）
クライアント ← SYN-ACK  ← サーバー （開けたよ、そっちは？）
クライアント → ACK       → サーバー （OK、通信開始！）

**SYNフラッド攻撃（SYN Flood）**は、この「律儀な仕組み」を逆手に取ります。攻撃者は大量の「SYN」パケットを送り続け、サーバーから「SYN-ACK」が返ってきても無視します。サーバーは仕様上、一定時間だけ返事を「待ち状態」としてメモリ（コネクション・テーブル）に保持するため、テーブルが瞬く間に埋まり、正規ユーザーがアクセスできなくなります。これがDoS攻撃の典型例です。

ポイントは「攻撃者がプロトコルの仕様そのものを武器にしている」という点です。バグを突いているのではなく、設計思想の「性善説」を利用しています。

防御策: SYN Cookie の有効化や、エッジネットワーク（CloudflareやAWS Shieldなど）でのレイヤー4 DDoSプロテクションの導入が有効です。

DNSの脆弱性と最新の保護技術

DNS（Domain Name System）はドメイン名（例: cyber-security-lens.com）をIPアドレスに解決する「インターネットの電話帳」ですが、デフォルトでは通信が平文（UDPポート53）であり、応答の真正性を検証する仕組みがありません。

この脆弱性は、攻撃者にとって非常に魅力的です。DNSを汚染できれば、ユーザーが正しいURLを入力しても、攻撃者が用意したサイトへ誘導できるからです。

DNSキャッシュポイズニング

攻撃者がDNSリゾルバ（キャッシュサーバー）に対して、本物の権威サーバーより「一瞬早く」偽のIPアドレスを応答させることで、キャッシュサーバー自体を汚染する手法です。一度キャッシュが汚染されると、そのリゾルバを使う全ユーザーが被害を受けます。

現代の防御策:

• DNSSEC: DNS応答レコードに「デジタル署名」を付与し、応答の完全性と発行元の真正性を暗号学的に担保する技術です。
• DoH (DNS over HTTPS) / DoT (DNS over TLS): 従来の平文DNS通信を暗号化トンネル内に収容します。ISPや公衆Wi-Fiにおける経路上の「DNSトラフィックの盗聴・改ざん」を防ぐ、現代のエンドポイントセキュリティの標準的な対策です。

HTTPからHTTPSへ：インフラとしての暗号化

通信内容を保護しない平文通信（HTTP）は、パスワードやセッショントークンを空中に垂れ流しているのと同じです。同一ネットワーク上でパケットキャプチャツール（Wiresharkなど）を実行するだけで、誰でも内容を読み取れます。これを防ぐのが、HTTPの下層にTLSを組み合わせた HTTPS です。

TLS 1.3 のパラダイムシフト

2018年に標準化されたTLS 1.3は、セキュリティとパフォーマンスの両面で大きく進化しました。旧バージョン（TLS 1.2）ではハンドシェイクに2回の往復（2-RTT）が必要でしたが、TLS 1.3では1回（1-RTT）に削減されています。

sequenceDiagram
  participant C as クライアント (ブラウザ)
  participant S as サーバー

  C->>S: ① ClientHello (対応する暗号化方式 + 鍵交換のパラメータ[Key Share])
  S->>C: ② ServerHello + 証明書 + 鍵交換の応答 + Finished (※ここから既に暗号化)

  Note over C: CA証明書の検証 (ドメイン・有効期限)

  C->>S: ③ Finished (暗号化通信の準備完了)

  Note over C,S: 🔒 セキュアなアプリケーションデータの送受信開始

TLS 1.3では、旧来の脆弱な暗号スイート（RC4や古いハッシュ）が完全に廃止されました。さらに「前方秘匿性（Forward Secrecy）」が強制されるようになっています。これは「万が一、将来サーバーの秘密鍵が漏洩しても、過去の通信データは復号できない」という重要な特性です。過去の通信ログを収集している攻撃者にとって、この特性は大きな障壁になります。

防御境界の進化：ファイアウォールから「ゼロトラスト」へ

ネットワーク防御の要であったファイアウォール（FW）も、時代に合わせて進化しています。

現代のアーキテクチャ：Zero Trust Network Access (ZTNA)

社内ネットワークの境界にNGFWを置くアプローチは現在も有効ですが、「社内に入れば安全」という前提を突く攻撃（ランサムウェアの横展開など）には根本的に無力です。

最先端のエンタープライズは現在、ファイアウォールによる「場所ベースの制御」から、全ユーザー・全デバイスを都度認証して権限を動的に付与する ZTNA（ゼロトラスト・ネットワーク・アクセス） へと軸足を移しています。場所ではなくアイデンティティを信頼の基準にする——これがゼロトラストの本質です。