🐙

メールセキュリティについてまとめてみた

2024/11/21に公開

はじめに

メールセキュリティについて勉強してみましたので、理解を深めるためアウトプットしてみようと思います。

メールの仕組み

メールセキュリティについて触れる前に、そもそものメールの仕組みを整理します。
以下の画像はメールサービスの構成例です。

端末側とメールサーバ側で動作するソフトウェアに分けて、上記図について説明します。

端末で動作するソフトウェア

・MUA(Mail User Agent)
ユーザが直接触れるインターフェース

メールサーバで動作するソフトウェア

・MSA(Message Submission Agent)
MUAから受け取ったメールを検証し、MTAに転送する
・MTA(Mail Transfer Agent)
メールの配送を担当する
DNSのMXレコードを参照して、配送先を決定する
・MDA(Mail Delivery Agent)
受信したメールをユーザのメールボックスに転送する
・MRA(Mail Retrival Agent)
メールサーバからメールを受信するためのプログラム

メール送信の流れ

①送信者がOutlookなどを起動させ、MUAとMSAあるいはMTA間でTCPコネクションを確立する
➁MUAから、SMTPを用いてMSAあるいはMTAにメールを転送する
③送信側のメールサーバと受信側のメールサーバでTCPコネクションを確立する
④送信側のメールサーバからSMTPで受信側のメールサーバにメールを転送する
⑤MDAが受信者ごとのメールボックスにメールを保存する
⑥受信者がMUAを起動し、受信側のメールサーバとTCPコネクションを確立する
⑦POP3あるいはIMAP4を利用して、MRAとMUAが通信を行いメールを受信する

後続のセキュリティに関する説明では、MTAが重要な役割を果たしますので、深堀します。
MTAは下記のメールヘッダの例に記載されている情報に基づいて、メールの転送処理を行います。
※メールヘッダとは、電子メールの「封筒」のような役割を果たす情報で、メール本文の前に付加される。情報です

Received: from mail.sender.com (mail.sender.com [203.0.113.1])
    by mx1.receiver.org (Postfix) with ESMTP id 5678
    for <user@receiver.org>; Mon, 19 Nov 2024 10:00:02 +0900
Received: from client-pc [B.B.B.B])
    by mail.sender.com (Postfix) with ESMTP id 1234
    for <user@receiver.org>; Mon, 19 Nov 2024 10:00:01 +0900
From: sender@sender.com
To: user@receiver.org
Subject: テストメール
Date: Mon, 19 Nov 2024 10:00:00 +0900
フィールド名 説明
Received メール転送元の情報でMTAを経由するたびに、MTAが追記します。
from:転送元サーバ
by:受信サーバ
with:転送プロトコル
id:メールの識別子
for:宛先
From メール差出人
To メールの宛先
Subject メールの件名
Date メールの送信日時

踏み台攻撃の仕組み

では、今までの前提知識を踏まえて踏み台攻撃について説明します。
通常、メールサーバ(MTA)は以下の場合メールを転送し、それ以外は拒否します。
・送信元メールアドレスが自ドメイン
・宛先メールアドレスが自ドメイン

上記のような設定がされていないと、以下のようなシナリオで誤設定されたMTAを経由して大量にスパムメールなどが送信できてしまいます。
なお、このような脆弱性をオープンリレーといいます。

登場人物
  1. 攻撃者側:
  • 送信元: attack.com
  • 攻撃者のメール: spammer@attack.com
  1. 誤設定のMTA(オープンリレー状態のメールサーバ):
  • ドメイン: openrelay.example.com
  • IP: [2.2.2.2]
  1. 被害者側:
  • ドメイン: target.com(victim1宛)
  • ドメイン: different.com(victim2宛)
  • ドメイン: another.com(victim3宛)
1. 攻撃者 [1.1.1.1] → 誤設定のMTA [2.2.2.2]
   SMTP: MAIL FROM: <spammer@attack.com>
   SMTP: RCPT TO: <victim1@target.com>
   
2. 誤設定のMTA [2.2.2.2] → 被害者のメールサーバー
   Received: from attack.com [1.1.1.1]
   by openrelay.example.com [2.2.2.2]
   for <victim1@target.com>

3. 攻撃者は同じMTAを使って大量送信
   → victim2@different.com
   → victim3@another.com...(数千〜数万通)

次の項目からは具体的なセキュリティ対策について説明します。

メールセキュリティ

メールセキュリティは
・送信側のメールサーバが送信者を認証
 POP before SMTP,SMTP-AUTHなど

・受信者が送信者を認証
 S/MIME,PGPなど

・受信側のメールサーバが送信側のメールサーバを認証
 SPF,DKIMなど
の3つに分類することができます。

POP before SMTP
SMTPプロトコルに先立って、ユーザ名とパスワードで認証する方法です。
しかし、以下の観点から多くのメールサーバで利用が廃止されています。
・パスワードが平文で送信されるため、パスワードが窃取される可能性がある
・POP許可をした送信元IPアドレスによって、SMTPセッションを許可するため
送信元IPアドレスの偽装によって認証をする抜ける可能性がある

SMTP-AUTH
SMTPの拡張仕様を用いてユーザ認証をする方法です。
パスワードは平文もしくはチャレンジレスポンス方式を通じて送信されます。
認証方式にかかわらずメール本文は暗号化されないため、SMTPSとSMTP-AUTHを組み合わせる方式など検討する必要があります。

S/MIINE
S/MINEは受信者が送信者を検証する仕組みです。
以下の図は一例ですが、
①RSA暗号での共通鍵の共有
➁デジタル署名での送信者の検証
を実施しています。
※送信者の公開鍵は認証局によって検証されています。

PGP(Pretty Good Privacy)
PGPもS/MIMEと同じように送信者の検証をデジタル署名による検証を行います。
違いは、デジタル証明書の種類です。
S/MIMEは、認証局によって発行された証明書を使用しますが、PGPではPGP証明書と呼ばれるデジタル証明書を使用します。
こちらは、本人の自己署名に加えて、本人を信頼する別の署名者が署名しています。

SPF(Sender Policy Framework)
SPFは受信側のメールサーバが、送信側のメールサーバを検証する仕組みです。
以下のようなDNSレコードを送信者ドメインの権威DNSに登録します。
受信側のメールサーバは、メールヘッダのFROMフィールドに含まれているドメイン名をキャッシュDNSもしくは権威DNSに問い合わせます。
応答されたレコードに基づいて、受信したメールの認証を行います。

# example.co.jpSPFレコード例
example.co.jp.    IN    TXT    "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 mx a:mail.example.co.jp include:_spf.google.com -all"

# レコードの詳細説明
v=spf1              # SPFバージョン1を使用することを宣言
ip4:192.0.2.0/24    # 送信元として許可するIPv4アドレス範囲
ip4:198.51.100.123  # 単一のIPv4アドレスを許可
mx                  # MXレコードに登録されているメールサーバーを許可
a:mail.example.co.jp # 指定したホスト名のAレコードを許可
include:_spf.google.com # Google WorkspaceなどのSPFレコードを含める
-all                # 上記以外のすべての送信元を拒否

# 一般的な修飾子(Qualifier)の説明
+  許可(デフォルト)
-  拒否
~  ソフトフェイル(受け入れるが、マークする)
?  ニュートラル(判定なし)

DKIM(Domain key Identified Mail)
送信元ドメインの権威サーバに、公開鍵を登録しておくことで、
送信側メールサーバを検証する仕組みです。

# DNSゾーンファイルのDKIMレコード例
mail._domainkey.example.com. IN TXT (
    "v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEF9EyCM9hgRZ+Zi"
    "4PKAw6Lt4Obx4HpXOD8Xx+6t6XhNH5UJ9CYeMF8UC9qZ2ROM6fZ4buvRUkU9qPB+CnhwgZV6"
    "15C3JtWxVj3eMbLK2/KXuHrqnvBHE4TtgPJL0y/xg8VUX0oPlyk58Qk2VqbGXnLDFAiM45kR"
    "1DwD2zEB2QIDAQAB"
)

送信側メールサーバは、DKIM-Sigunatureというフィールドに検証に必要なデジタル署名を記録します。

# メールヘッダーの例
From: sender@example.com
To: recipient@example.net
Subject: テストメール
Date: Thu, 21 Nov 2024 10:00:00 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=mail;
    t=1700532000;
    h=from:to:subject:date;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=dSaXR8iQy0CxzqX4KbDJ9Fd+0xp7nyzJ5vZ5B8zL3qF6n8kX4EJ2p0hY
      tB7Qm5YmKvqX1g3dN8T5JgKj5YxRq8f9L2k5vN3QxM2Z7n6pL8wY9tR
      H+2XNj5kQy0CxzqX4KbDJ9Fd+0xp7nyzJ5vZ5B8zL3qF6n8kX4EJ2p0
      hYtB7Qm5YmKvqX1g3dN8T5JgKj5YxRq8f9L2k5vN3QxM2Z7n6pL8wY9

# DKIM-Signature フィールドの説明
v バージョン
a 署名生成に使用するアルゴリズム(RSAで署名し、SHA-256でハッシュ化する)
c 正規表現指定
d 送信元ドメイン名
s セレクタ(DNSの公開鍵レコードを特定するための識別子でこの場合は”mail._domainkey.example.com”を参照する)
t タイムスタンプ
h 署名対象メールヘッダ
bh 本文ハッシュ
b 署名

セレクタをもとに公開鍵を判断し、権威サーバに登録された公開鍵を用いて、
bに含まれている署名を検証します。

セレクタとは
同じドメインで複数のDKIM公開鍵を管理するための識別子です。

# 基本的な構造
[セレクタ名]._domainkey.[ドメイン名]

# 例
mail._domainkey.example.com    # mailというセレクタ
news._domainkey.example.com    # newsというセレクタ

# DNSゾーンファイルの例
marketing._domainkey.example.com IN TXT (
    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
)
support._domainkey.example.com IN TXT (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAA..."
)

# メールヘッダーでの使用例
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=marketing;     # マーケティングメール用の鍵を使用
    ...

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=support;       # サポート用の鍵を使用
    ...

おわりに

メールセキュリティについては、
「誰が」「何を」認証するのを整理できると、理解が促進されてよいなと思いました。

参考書籍

セキュリティ技術の教科書 第3版

Discussion