NHN Cloud Meetup 編集部
NHN Cloudの技術ナレッジやお得なイベント情報を発信していきます
Emailのセキュリティ強化機能（SPF）の紹介
2020.07.27
1,007
はじめに
TOAST Emailは、電子メールのセキュリティを強化するさまざまな機能を提供しています。今回は、メールのセキュリティを強化する方法の1つであるSPF（Sender Policy Framework）について紹介します。
予備知識
SPF（Sender Policy Framework）の機能を紹介する前に、SPFが理解しやすいように関連する内容を説明します。
メールアドレスの構造
メールアドレスは、ローカルパートと@(at)、ドメインで構成されます。たとえば、以下のとおりです。今回の記事で紹介する機能は、ドメイン部分が多くを占めます。
メールアドレス: [example@toast.com](mailto:example@toast.com) ローカルパート: example ドメイン: toast.com
SMTP（Simple Mail Transfer Protocol）の構造
以下は、メール送信SMTPサーバー（以下、送信サーバー）とメール受信SMTPサーバー（以下、受信サーバー）間のSMTP通信例です。SMTPはテキスト基盤のプロトコル（Protocol）で、シンプルな構造のため簡単に読み取ることができます。下記の通信例では送信サーバーは「C」、受信サーバーは「S」です。
C: telnet www.example.com 25 S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.com S: 250 smtp.example.com, I am glad to meet you C: MAIL FROM:<bob@example.com> <-- (1) S: 250 Ok C: RCPT TO:<alice@example.com> S: 250 Ok C: DATA <-- (2) S: 354 End data with <CR><LF>.<CR><LF> C: from: "Bob Example" <bob@example.com> <-- (3) C: To: Alice Example <alice@example.com> C: Data: Tue, 15 January 2008 16:02:43 -0500 C: Subject: Test message C: C: Hello Alice. C: This is a test message with 5 header friends and 4 lines in the message body. C: Your friend, C: Bob C: . S: 250 Ok: queued as 12345 C: QUIT <-- (4) S: 221 Bye
- 私たちが便箋（メッセージ）を封筒（エンベロープ）に入れて送るのと同じように、封筒と便箋で構成されます。上記のSMTP通信例では（1）から（2）までが封筒、（3）から（4）までが便箋の部分に該当します。
- 封筒の部分は、便箋のメッセージを読む受信者（Alice）には伝達されません。したがって、受信者は封筒の内容を確認することができません。
- 上記の送信者アドレスは2回登場します。送信者の2つのアドレスは、受信サーバーでそれぞれ異なって使用されます。
- 最初の送信者アドレスのMAIL FROMは、SPF認証時に使用されます。一般的にメール部分のヘッダであるReturn-Pathアドレスに追加され、返信メールを受信するアドレスとして使用されます。MAIL FROMは、Fromと区別するため、5321.From、MFrom、エンベロープFromと呼ばれることがあります。
- 2番目の送信者アドレスのFromは、受信者がメールを読むときに表示されるアドレスでDKIM認証に使用されます。Fromは5322.From、ヘッダーFromと呼ばれることがあります。
- MAIL FROMとFromは、場合によっては完全に同一でなくても構いません。たとえば、実際の送信者アドレスとは異なる返信メールのみを受信するメールアドレスをMAIL FROMに設定し、すべての返信メールを1つのメールで収集し処理することができます。
メールのなりすまし
なりすまし（Spoofing）
他人のふりをして活動するすべての攻撃を意味します。被害者が信頼する人物や、ウェブサイト、IPアドレス、メールアドレスなどに偽装するものです。
C: telnet www.example.com 25 S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.com S: 250 smtp.example.com, I am glad to meet you C: MAIL FROM:<bob@trust.com> <-- 実際には'spoofing.com'ではなく、'trust.com'として受信サーバーを騙す S: 250 Ok C: RCPT TO:<alice@example.com> S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: from: "Bob Example" <bob@trust.com> <-- このような方法で受信者を騙す C: To: Alice Example <alice@example.com> …
メール送信元（エンベロープFrom）の偽装
MAIL FROM（5321.From、エンベロープFrom）に、実際とは異なる信頼できる送信者アドレスを入力し、メールを受信するSMTPサーバーを騙す攻撃方法です。受信サーバーが改ざんされたメールを受信者（Alice）に伝達した場合、受信者がフィッシング、ファーミングの被害を受けたり、ウイルスに感染することがあります。これらはSPFで予防できますが完璧ではないため、DKIMとDMARCまで適用することをおすすめします。（DKIMとDMARCは、別の機会にご紹介します）
送信者アドレス（ヘッダーFrom）の偽装
From（5322.From、ヘッダーFrom）に、実際とは異なる受信者（Alice）が信頼できる送信者アドレスを入力して受信者を欺く攻撃方法です。「送信サーバーの改ざん」のように、受信者が騙されると被害を受ける可能性があります。SPFでは防ぐことができず、DKIMとDMARCまで適用する必要があります。
メールセキュリティ強化機能
SPF（Sender Policy Framework）
SPFレコードと呼ばれる送信サーバーの情報を、メール送信ドメイン（DNS Domain Name Service）に登録し、受信サーバーがDNSで公開されている情報と実際にメールを送信するSMTPサーバーの情報が一致しているかを確認する認証技術です。SPFレコードが登録されていなければ、攻撃者はスプーフィング攻撃が可能となり、受信サーバーは送信サーバーを信頼できないため、送信したメールがスパムとして処理される可能性が高くなります。
下図は、TOAST EmailからGmailにメールを送信したときの、SPFの登録および認証フローを表したシーケンス図です。
SPFレコードの構造
以下は、SPFレコード例です。
"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spfblocka.toast.com -all"
SPFレコードは、バージョン（Version）、1つ以上の修飾子（Qualifier）、メカニズム（Mechanisms）の組み合わせで構成されます。
| 区分 | 値 | 説明 |
|---|---|---|
| バージョン | v=spf1 | SPFレコードのバージョン。現在1つのみ存在する。 |
| 修飾子 | +, ?, ~, – | メカニズムと一緒に使用でき、SPF認証を通過または失敗したメールをどのように処理するか定義する。 |
| メカニズム | all, a, ip4, ip6, mx, ptr, exists, include | 送信サーバーのマッチング方式を定義する。メカニズムによって値がなかったり、IPやドメインを有する。 |
修飾子の詳細は、次のとおりです。
| 修飾子 | 説明 |
|---|---|
| + | 通過（PASS） 一般的に省略されることがある。（例: +includeとincludeは同じ意味である） |
| ？ | 中立（NEUTRAL） |
| ~ | 弱い認証失敗（SOFTFAIL） 失敗ではあるが受信されることを望み、受信サーバーでは疑わしいメールとして処理されることがある。（例: ~all） |
| – | 失敗（FAIL） 重大な障害（HARDFAIL）とも呼ばれる。SPFレコードに登録されていないサーバーから送信されたすべてのメールは、受信拒否されることがある。（例: -all） |
メカニズムの詳細は、次のとおりです。
| メカニズム | 説明 |
|---|---|
| all | すべての場合が該当する。一般的に最後に位置して前を通過していないものを処理するために使用される。 |
| a | AまたはAAAAレコードに送信サーバーがある場合に通過する。 |
| ip4 | 送信サーバーがIPv4領域に含まれる場合に通過する。 |
| ip6 | 送信サーバーがIPv6領域に含まれる場合に通過する。 |
| mx | MXレコードに送信サーバーが含まれる場合に通過する。 |
| ptr | PTRレコードを利用したマッチング方法。使用を推奨しない。 |
| exists | 値部分のドメインアドレスが確認された場合に通過する。頻繁には使用されていない。 |
| include | 他のドメインを参照する。参照したドメインに従って送信サーバーを認証する。 |
修飾子、メカニズム、値の組み合わせ例
${修飾子}${メカニズム}
値がない場合の例
${修飾子}${メカニズム}:${値}
- 値がある場合
(例) ‘ip4:192.0.2.0/24’, ‘include:_spfblocka.toast.com’
最初の部分のSPFレコード例を解析すると、次のようになります。
"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spfblocka.toast.com -all"
- IPv4アドレスが「192.0.2.0/24」の領域であったり、「198.51.100.123」またはドメイン「_spfblocka.toast.com」のSPFレコードに登録された送信サーバーであれば通過します。残りは失敗処理され、受信が拒否されます。
もう1つ例をあげてみましょう。
"v=spf1 include:_spfblocka.toast.com ~all"
- ドメイン「_spfblocka.toast.com」のSPFレコードに含まれる送信サーバーは通過します。通過できなかった残りの部分は失敗しますが、受信される場合があります。
SPFレコード作成時の注意事項
SPFレコードを直接作成する場合は、次の点に注意が必要です。
1. DNSルックアップ（Lookup）回数制限
ドメインを値として使うメカニズムを使用した場合、受信サーバーはDNSルックアップを続行します。一般的に、DNSルックアップが10回以上繰り返されると、受信サーバーでSPF認証が失敗処理される可能性があります。SPFレコードを作成する際は、最大限に単純な構造にしてDNSルックアップの回数を減らす必要があります。
2. TXTレコードの最大数
DNS TXTレコードの最大数は255文字です。SPFレコードを作成する際、送信サーバーIPをIP領域に束ねるか、includeを利用して長さを短くする必要があります。
3.単一SPFレコードの登録
次のように、複数のSPFレコードを登録すると、SPF認証を通過できません。
example.com text = "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 ~all" example.com text = "v=spf1 include:example.com ~all"
次のように1つにまとめて、単一のSPFレコードに登録する必要があります。
example.com text = "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:example.com ~all"
SPFレコードの登録
送信ドメインDNSにSPFレコードを登録する方法を説明します。
次の値を送信ドメインDNSのTXTレコードに登録します。詳しい登録方法は、送信ドメインDNS管理者や管理メーカーにお問い合わせください。
v=spf1 include:_spfblocka.toast.com ~all
SPFの登録作業が完了しても、DNS変更の完全な伝播には少なくとも10分から最長で24時間かかることがあります。安定した送信を行うため、SPF登録後、十分に時間が経ってからメールを送信してください。
SPFレコードの登録確認
メールのセキュリティチェックサイトを利用したり、Linux、Windowsなどの環境でコマンドを使って確認できます。「nslookup」「dig」は、DNSに質疑してドメイン情報を照会するコマンドです。
メールのセキュリティチェックサイトを利用
[https://dmarcian.com/spf-survey/?domain=${送信_ドメイン]}
Linux
nslookup -q=TXT ${送信_ドメイン}
dig -t TXT ${送信_ドメイン}
Windows
nslookup -q=TXT ${送信_ドメイン}
例
nslookup -q=TXT toast.com toast.com text = "v=spf1 include:nhnent.com ~all"
まとめ
送信サーバーのなりすまし防止
SPFレコードを登録すると、受信サーバーが送信サーバーのスプーフィング攻撃を防ぐことができます。Gmail、Yahoo!メールなど、ほとんどのメールサービスはメール受信時にSPFレコードを確認します。したがって、送信ドメインがスプーフィング攻撃に使用されたり、送信したメールがスパム処理されることを防ぐため、SPFレコードを登録することをおすすめします。TOAST Emailは、SPFが登録されていないドメインのプロジェクトメンバーに対して、SPF登録案内メールを送信する機能を提供しており、SPFレコードの登録を推奨しています。
SPF認証の限界
SPFによって送信サーバーのスプーフィング攻撃を防止できます。 しかし、攻撃者がSPFレコードに登録されたドメインでMAIL FROMを改ざんした場合、受信サーバーはSPFレコードを確認し、送信サーバーを信頼することになります。このような攻撃を防ぐため、MAIL FROMとFromを比較してメールの内容が改ざんされていないかを確認する認証方法が必要です。 これらの認証方法には、DKIM(Domain Keys Identified Mail)とDMARC(Domain-based Message Authentication, Reporting and Conformance)があり、次の機会に紹介したいと思います。
参考
- 簡易メール転送プロトコル、SMTP通信例: https://ja.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
- Sender Poliy Framework: https://en.wikipedia.org/wiki/Sender_Policy_Framework
- Simple Mail Transfer Protocol RFC: https://tools.ietf.org/html/rfc5321
- Sender Policy Framework（SPF）RFC: https://tools.ietf.org/html/rfc7208
