注目キーワード

メタCセキュリティ物語 ～Web・DNS編・通信の盗聴と改ざんを防げ～

セキュリティ資格学習

この記事は、セキュリティ資格学習のために、AI（Claude）と共同で作成したコンテンツです。
※間違った解釈がある可能性があります。

目次

この記事の目的

セキュリティの専門用語は、カタカナや略語が多く、初学者にとって非常に取っつきにくいものです。
そこで、専門家じゃなくてもわかるようにストーリー風に構成してみました。

 

🌐 結城の新たな攻撃計画

結城は、メール攻撃も阻止されたことに焦りを感じていた。

「メールもダメ…でも、まだ方法はある。Web通信を狙えばいい」

結城のモニターには、メタCのログインページが表示されている。

「HTTPSを使ってるけど、最初の接続はHTTP。そこで中間者攻撃を仕掛ければ、通信を盗聴できる。HSTSを設定してないサイトは狙い目だ」

「さらに、DNSを汚染すれば、偽サイトに誘導できる。DNSSECを導入してないドメインなら簡単だ」

結城の唇が不気味に歪んだ。

「慎也と里見のログイン情報を盗んで、二人のアカウントを乗っ取る…完璧な計画だ」

💑 カフェでのひととき

その頃、慎也と里見は、メタC内のカフェワールドでお茶をしていた。

「里見、最近HTTPSって当たり前になったよね。でも、たまに『保護されていない通信』って出ることがあるんだけど…」

「いい質問ね。実は、HTTPSがあっても完璧じゃないの。最初の接続がHTTPだと、そこで攻撃される可能性があるのよ」

「え、HTTPSなのに危ないの？」

「そう。だからHSTSっていう技術が必要なの。それと、DNSも狙われやすいからDNSSECも大事。今日はWeb通信とDNSのセキュリティについて教えるわね」

📖 里見の解説：Web通信のセキュリティ

HTTPとHTTPSの違い

「まず基本から。HTTPとHTTPSの違いは分かる？」

HTTP（HyperText Transfer Protocol）：

  • Webページを表示するための通信プロトコル
  • 平文通信（暗号化なし）
  • 盗聴される危険性
  • ポート80

HTTPS（HTTP Secure）：

  • HTTPをSSL/TLSで暗号化
  • 盗聴・改ざんを防止
  • サーバー証明書で本物のサイトか確認
  • ポート443

身近な例え：

  • HTTP：葉書（誰でも読める）
  • HTTPS：封書（封をして送る）

「なるほど。じゃあHTTPSなら完全に安全？」

「それが、そうでもないの。最初の接続に問題があるのよ」

SSL/TLSストリッピング攻撃

「SSL/TLSストリッピング攻撃っていうのは、HTTPSをHTTPに格下げさせる攻撃よ」

攻撃の流れ：

【正常な接続】
ユーザー → http://example.com（最初）
         → https://example.com（自動リダイレクト）✅

【ストリッピング攻撃】
ユーザー → http://example.com（最初）
         → 中間者（攻撃者）が割り込み
         → http://example.com のまま❌（HTTPSにならない）
         → 通信内容が全部バレる

身近な例え：

「郵便局に『書留で送って』って頼んだのに、途中の人が『いや、普通郵便でいいよ』って勝手に変えちゃうようなもの。封をしないから中身が見えちゃう」

「怖い…じゃあ、どうすればいいの？」

「それがHSTSなの」

HSTS（HTTP Strict Transport Security）

「HSTSは、『このサイトは絶対にHTTPSで接続してね』ってブラウザに命令する仕組みよ」

HSTSの正式名称：

HTTP Strict Transport Security（エイチティーティーピー・ストリクト・トランスポート・セキュリティ）

HSTSの仕組み：

1. 初回アクセス（HTTPSで）
   サーバー → ブラウザ：「今後はHTTPSだけで接続してね」
   （Strict-Transport-Security: max-age=31536000 というヘッダーを送る）

2. 次回以降
   ユーザーが http://example.com と入力しても
   → ブラウザが自動的に https://example.com に変換✅
   → 中間者攻撃を防げる

身近な例え：

「『このお店は、必ず予約してから来てください』っていう決まりみたいなもの。一度そのルールを聞いたら、次からは予約なしで行こうとしても、自分で『あ、予約しなきゃ』って思い出すでしょ？ブラウザも同じで、『このサイトはHTTPSだけ』って覚えてくれるの」

HSTSヘッダーの例：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

パラメータの意味：

  • max-age=31536000：1年間（秒単位）このルールを覚える
  • includeSubDomains：サブドメイン（blog.example.comなど）にも適用
  • preload：ブラウザの「HSTSプリロードリスト」に登録（初回から強制HTTPS）

「preloadって何？」

「HSTSプリロードリストっていうのは、Chrome、Firefox、Safariなどのブラウザが持ってる『最初からHTTPSで接続すべきサイトのリスト』よ。ここに登録されてると、初回アクセスからHTTPSになるの」

HSTSの限界：

  • 初回アクセスはHTTPの可能性（preloadで解決）
  • 証明書エラーがあると接続できない（安全のため）

🌐 DNSのセキュリティ

DNSの復習

「以前、DNSについて説明したけど、覚えてる？」

「うん、ドメイン名をIPアドレスに変換する住所録みたいなものだよね」

「そう。でも、DNSには改ざんされやすいという弱点があるの」

DNS攻撃の例：

  • DNSキャッシュポイズニング：偽の情報をキャッシュに入れる
  • DNSスプーフィング：DNS応答を偽装する
  • 結果 → 偽サイトに誘導される（フィッシング）

身近な例え：

「友達の電話番号を聞いたら、誰かが『こっちの番号だよ』って嘘を教えて、変な人につながっちゃうようなもの」

「怖い…どうやって防ぐの？」

「それがDNSSECなの」

DNSSEC（DNS Security Extensions）

「DNSSECは、DNSの応答に電子署名をつけて、改ざんされてないか確認する技術よ」

DNSSECの正式名称：

DNS Security Extensions（ディーエヌエス・セキュリティ・エクステンションズ）

DNSSECの仕組み：

【通常のDNS（危険）】
ユーザー：「example.comのIPは？」
DNS応答：「192.0.2.1です」
→ 本物か偽物か分からない❌

【DNSSEC（安全）】
ユーザー：「example.comのIPは？」
DNS応答：「192.0.2.1です」+ 電子署名
ユーザー：署名を検証
→ 本物だと確認できる✅

身近な例え：

「卒業証明書に学校の印鑑と校長先生のサインがあるようなもの。偽造したら印鑑とサインが合わないから、本物か分かるでしょ？DNSSECも同じで、署名が本物か確認するの」

DNSSECの4つのレコード：

  1. RRSIG（Resource Record Signature）：電子署名そのもの
  2. DNSKEY：公開鍵（署名を検証するための鍵）
  3. DS（Delegation Signer）：親ゾーンとの信頼の鎖
  4. NSEC/NSEC3：「このドメインは存在しない」という証明

信頼の鎖（Chain of Trust）：

ルートDNS（.）
    ↓ DSレコードで署名
.com DNS
    ↓ DSレコードで署名
example.com DNS
    ↓ RRSIGで署名
www.example.com の IPアドレス

「上から順番に署名を確認していって、全部正しかったら『本物』って分かるの」

身近な例え：

「学校の委任状みたいなもの。校長先生 → 教頭先生 → 担任の先生って順番にサインしていって、全部のサインが本物だったら『この委任状は本物』って分かるでしょ？」

DNSSECの限界：

  • 暗号化はしない（署名だけ）→ 通信内容は見える
  • DoH（DNS over HTTPS）と組み合わせると最強
  • 設定が複雑で導入率が低い

DKIM（DNSとの関係）

「ちなみに、メール編で説明したDKIMも、実はDNSを使ってるのよ」

「え、DKIMってメールの技術じゃないの？」

「そう。でも、公開鍵をDNSに登録してるの」

DKIMとDNSの関係：

1. 送信者：秘密鍵でメールに署名
2. 送信者：公開鍵をDNSに登録
   （例：default._domainkey.example.com）
3. 受信者：DNSから公開鍵を取得
4. 受信者：公開鍵で署名を検証

身近な例え：

「印鑑証明みたいなもの。市役所（DNS）に『この印鑑は本物ですよ』って登録しておいて、受け取った人が市役所で確認できるようにするの」

「なるほど！DNSって、いろんな情報を保存してるんだね」

「そう。だから、DNSが改ざんされると、メールの認証も壊れちゃうの。だからDNSSECが大事なのよ」

CCA（Certificate and CRL Profile）

「最後に、CCAについて説明するわね」

CCAの正式名称：

Certificate and CRL Profile（サーティフィケート・アンド・シーアールエル・プロファイル）

「CCAは、日本政府が定めた電子証明書と失効リストのプロファイル（仕様書）よ」

CCAとは：

  • 政府認証基盤（GPKI）で使われる証明書の標準仕様
  • どんな情報を証明書に入れるか決める
  • 相互運用性を確保（どの役所でも使える）

身近な例え：

「運転免許証のフォーマットみたいなもの。『写真はここ、名前はここ、有効期限はここ』って決まってるから、全国どこでも通用するでしょ？CCAも同じで、『証明書はこの形式で作ってね』って決めてるの」

CCAで決められていること：

  • 証明書の有効期限（最長5年）
  • 鍵の長さ（RSA 2048ビット以上）
  • ハッシュ関数（SHA-256以上）
  • 失効リスト（CRL）の発行間隔

GPKIとの関係：

  • GPKI：政府認証基盤（Government Public Key Infrastructure）
  • CCA：GPKIで使う証明書の仕様書

「ちょっと難しいけど、『政府の電子証明書の標準規格』って覚えておけばOK」

⚠️ 結城の攻撃開始

その時、メタCのログインページに異変が起きていた。

結城は、公共Wi-Fiのネットワークで中間者攻撃を仕掛けていた。

攻撃の流れ：

ステップ1：SSL/TLSストリッピング攻撃

慎也のブラウザ → http://meta-c.com と入力
         ↓
結城（中間者） → https://meta-c.com への自動リダイレクトを遮断
         ↓
慎也のブラウザ → http://meta-c.com のまま表示（偽サイト）
         ↓
慎也が ID/パスワードを入力
         ↓
結城が盗聴成功❌

「よし…慎也のログイン情報が手に入った」

ステップ2：DNSキャッシュポイズニング

結城は、さらにDNSサーバーに偽の情報を送信した。

偽のDNS応答：「meta-c.com = 203.0.113.99（結城の偽サイト）」
         ↓
DNSサーバーのキャッシュが汚染される
         ↓
他のユーザーも偽サイトに誘導される❌

「完璧…これで、大量のユーザーのアカウントを乗っ取れる」

結城の目が不気味に光った。

🔍 異変の検知

メタCのセキュリティ監視室。佐藤が異常なログに気付いた。

「ん…？ログインページへのHTTP接続が急増している…しかもSSL証明書エラーが多発」

[ログ]
2025-01-08 15:30:12 - HTTP接続: 192.168.1.100 → meta-c.com
2025-01-08 15:30:15 - HTTP接続: 192.168.1.105 → meta-c.com
2025-01-08 15:30:18 - SSL証明書エラー: 証明書のドメインが一致しません
...（100件以上）

「これは…SSL/TLSストリッピング攻撃とDNSポイズニングの可能性が高い」

佐藤はすぐに里見に連絡した。

「里見さん、緊急事態です。中間者攻撃とDNS汚染が同時に発生しています」

「送信元IPは？」

「203.0.113.99…また結城です」

「分かったわ。すぐに対応します」

🛡️ 防御と対策

佐藤と里見は、緊急対策を実施した。

即時対応：

  1. 該当IPアドレスのブロック：結城のIPからのアクセスを遮断
  2. DNSキャッシュのクリア：汚染された情報を削除
  3. 影響を受けたユーザーへの通知：パスワード変更を促す
  4. HTTPS強制リダイレクトの確認：すべてのページでHTTPSに転送

「幸い、被害は限定的です。HSTSが設定されていたユーザーは、自動的にHTTPSに接続されていたので無事でした」

「でも、まだ完璧じゃないわね」

恒久対策：

  1. HSTSプリロードリストへの登録： 
    Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
    • https://hstspreload.org/ に申請
    • 初回アクセスから強制HTTPS
  2. DNSSECの導入：
    • DNSゾーンに署名を追加
    • DNS応答の改ざんを検知
    • 信頼の鎖を構築
  3. 証明書の強化：
    • EV証明書（Extended Validation）を導入
    • アドレスバーに組織名を表示
  4. 監視強化：
    • HTTP接続のログ監視
    • DNS応答の異常検知
    • SSL証明書エラーのアラート
  5. ユーザー教育：
    • 「アドレスバーの鍵マークを確認」と周知
    • 「HTTPSでない場合は入力しない」と注意喚起

「これで、今後は同じ攻撃は通用しません」

佐藤と里見の迅速な対応で、メタCのWebセキュリティは大幅に向上した。

💑 安堵のひととき

攻撃が阻止された夜、慎也と里見はメタCのプライベートワールドで話していた。

「里見、今日もありがとう。危うくアカウント乗っ取られるところだった…」

「大丈夫よ、慎也。幸い、HSTSが機能していたから被害は最小限だったわ」

「HSTSって、本当にすごいんだね。最初からHTTPSで接続させるなんて」

「そう。一度設定すれば、ブラウザが自動的に守ってくれるの。ユーザーが意識しなくても安全になるのが良いところ」

里見が優しく微笑んだ。

「じゃあ、クイズ。HSTSとDNSSECの違いは？」

「えっと…HSTSはHTTPS接続を強制する、DNSSECはDNS応答に署名して改ざんを防ぐ！」

「完璧！じゃあ、もう一問。CCAって何？」

「えーと…政府の電子証明書の標準規格！」

「100点満点！よく覚えたわね」

二人は手を繋ぎながら、星空を見上げた。

「ねぇ、里見。もう結城の攻撃も全部防げたよね？」

「そうね…DNS、DHCP、SNMP、メール、Web…ほとんど対策できたわ。でも、油断は禁物よ」

「うん、分かってる。でも、里見と一緒なら大丈夫な気がする」

「ありがとう。じゃあ、次はインシデント対応について勉強しましょうか」

「インシデント対応？」

「攻撃が起きた後、どう証拠を保全して、原因を調査するか。これも大事なのよ」

「うん、楽しみ！」

二人の絆は、試練を乗り越えるたびに深まっていった。

😤 結城の限界

一方、結城は自室で呆然としていた。

「くそっ…HSTSもDNSSECも対策された。もう、どんな手を使っても突破できない…」

画面には、「Connection Blocked」「Access Denied」の文字が並んでいた。

「里見…あなた、本当に完璧ね。DNS、DHCP、SNMP、メール、Web…全部だ」

結城のメールボックスに、警察からの最終通告が届いていた・・・

 

📚 用語まとめ

用語 読み 意味・用途
HTTP エイチティーティーピー HyperText Transfer Protocol。Webページを表示するための通信プロトコル。平文通信（暗号化なし）。ポート80。
HTTPS エイチティーティーピーエス HTTP Secure。HTTPをSSL/TLSで暗号化した安全な通信。ポート443。
SSL/TLS エスエスエル / ティーエルエス 通信を暗号化するプロトコル。TLSがSSLの後継規格。
HSTS エイチエスティーエス HTTP Strict Transport Security。ブラウザに「このサイトは常にHTTPSで接続する」と命令する仕組み。SSL/TLSストリッピング攻撃を防ぐ。
SSL/TLSストリッピング攻撃 エスエスエル/ティーエルエス・ストリッピングこうげき HTTPSをHTTPに格下げさせて、通信を盗聴する中間者攻撃の一種。
HSTSプリロードリスト エイチエスティーエス・プリロードリスト ブラウザが最初から「このサイトはHTTPSのみ」と認識しているリスト。初回アクセスから安全。
DNS ディーエヌエス Domain Name System。ドメイン名をIPアドレスに変換する仕組み。インターネットの住所録。
DNSSEC ディーエヌエスセック DNS Security Extensions。DNSの応答に電子署名をつけて、改ざんを防ぐ技術。
DNSキャッシュポイズニング ディーエヌエス・キャッシュ・ポイズニング DNSキャッシュに偽の情報を注入して、ユーザーを偽サイトに誘導する攻撃。
RRSIG アールアールシグ Resource Record Signature。DNSSECで使う電子署名レコード。
DNSKEY ディーエヌエス・キー DNSSECの公開鍵を格納するレコード。署名の検証に使用。
DS ディーエス Delegation Signer。DNSSECで親ゾーンと子ゾーンをつなぐレコード。信頼の鎖を構築。
信頼の鎖 しんらいのくさり Chain of Trust。ルートDNSから順番に署名を検証していく仕組み。全て正しければ本物。
DKIM ディーキム DomainKeys Identified Mail。メールの電子署名技術。公開鍵をDNSに登録する。
CCA シーシーエー Certificate and CRL Profile。日本政府が定めた電子証明書と失効リストのプロファイル（仕様書）。GPKI（政府認証基盤）で使用。
GPKI ジーピーケーアイ Government Public Key Infrastructure。政府認証基盤。政府機関で使用される公開鍵基盤。
中間者攻撃 ちゅうかんしゃこうげき Man-in-the-Middle Attack（MITM）。通信の途中に割り込んで、盗聴や改ざんを行う攻撃。
EV証明書 イーブイしょうめいしょ Extended Validation Certificate。最も厳格な審査を受けた証明書。アドレスバーに組織名が表示される。

🎯 試験対策ポイント

HSTSの3つのパラメータ（重要！）

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • max-age：ブラウザがこのルールを覚える期間（秒単位）
  • includeSubDomains：サブドメインにも適用
  • preload：HSTSプリロードリストに登録（初回から強制HTTPS）

HSTSが防ぐ攻撃

  • SSL/TLSストリッピング攻撃：HTTPSをHTTPに格下げする攻撃
  • 中間者攻撃（MITM）：通信を盗聴・改ざんする攻撃

DNSSECの4つのレコード

レコード 役割
RRSIG 電子署名そのもの
DNSKEY 公開鍵（署名の検証用）
DS 親ゾーンとの信頼の鎖
NSEC/NSEC3 「存在しない」の証明

信頼の鎖（Chain of Trust）

ルートDNS（.）
    ↓ DSレコードで署名
.com DNS
    ↓ DSレコードで署名
example.com DNS
    ↓ RRSIGで署名
www.example.com の IPアドレス

上から順番に署名を検証して、全て正しければ「本物」と判断。

DNSSECの限界

  • 暗号化はしない：署名だけ（通信内容は見える）
  • DoH/DoTと組み合わせる：DNS over HTTPS/TLSで通信も暗号化

HTTPとHTTPSの違い

項目 HTTP HTTPS
暗号化 ❌ なし（平文） ✅ あり（SSL/TLS）
ポート番号 80 443
証明書 不要 必要
盗聴 🔴 されやすい 🟢 されにくい
改ざん 🔴 されやすい 🟢 検知できる

CCAと関連用語

  • CCA：政府の電子証明書の標準仕様
  • GPKI：政府認証基盤（CCAを使用）
  • CRL：Certificate Revocation List（証明書失効リスト）

🎓 語呂合わせ・暗記法

HSTSの3つのパラメータ

「マックス（max）、イン（include）、プリ（preload）」

  • マックス：max-age
  • イン：includeSubDomains
  • プリ：preload

DNSSECの4つのレコード

「RDDNで安心（あーるでぃーでぃーえぬ）」

  • RRSIG
  • DNSKEY
  • DS
  • NSEC/NSEC3

HTTPSとHSTS

「HTTPSは暗号化、HSTSは強制化」

  • HTTPS：通信を暗号化
  • HSTS：HTTPS接続を強制

CCAの覚え方

「CCAは Certificate（証明書）の CA（認証局）じゃなくて、Certificate and CRL Profile（証明書とCRLのプロファイル）」

🔍 補足：実際の確認方法

HSTSが設定されているか確認

方法1：ブラウザの開発者ツール

  1. F12キーで開発者ツールを開く
  2. Networkタブを選択
  3. サイトにアクセス
  4. Response Headersに「Strict-Transport-Security」があるか確認

方法2：コマンドライン

curl -I https://example.com | grep -i strict

DNSSECが有効か確認

方法1：オンラインツール

https://dnssec-debugger.verisignlabs.com/

方法2：コマンドライン（dig）

dig example.com +dnssec

結果に「ad」フラグがあればDNSSEC検証成功

HTTPSの鍵マークを確認

ブラウザのアドレスバーで確認：

  • 🔒 鍵マーク：HTTPS接続
  • ⚠️ 警告マーク：証明書エラー
  • 🔓 鍵なし：HTTP接続（危険）