メールスプーフィングと送信ドメイン認証
はじめに
登録セキスペの受験を通してSPF・DKIM・DMARCなどのドメイン認証技術を学んだものの、実際にどのような組み合わせで設定するとどのような攻撃への対策となるのかはあやふやであったため、改めて調べてまとめることで理解を整理しておくことにした。
今回はDNSサーバの送信ドメイン認証技術とメールスプーフィングの関連についてまとめるため、DNSキャッシュポイズニングなどの別の攻撃による影響は簡単のために考えないこととした。
エンベロープFROMとヘッダFROM
メールデータはエンベロープ部とメッセージ部に分けられる。送信元ドメインはエンベロープ部とメッセージ部のヘッダのそれぞれに記載される。以後、それぞれエンベロープFROMとヘッダFROMと呼ぶことにする。メールクライアント等で差出人として表示されるメールアドレスはヘッダFROMになる。エンベロープFROMはメールサーバが参照する配達用の情報という位置付けになっていて、一般のメールの受信者はこれを意識しない。
メールスプーフィング（ドメインスプーフィング）
スプーフィングは「騙す」という意味で、メールスプーフィングはヘッダFROMを詐称することで受信者に送信者を誤認させる手口である。
こうすることで、実際には違うドメインのメールサーバから送信されていても、受信者は気づかずにexample.comからの真正なメールだと誤認してしまう。なぜなら、メールクライアント上の差出人には「sender@example.com」と表示されているからだ。
送信ドメイン認証
送信ドメイン認証技術は単体では効果が限定的であり、組み合わせることでセキュリティを強化する必要がある。特にSPFとDKIMは単体ではメールスプーフィングで簡単に突破されてしまうため、DMARCと組み合わせて用いる必要がある。ここでは、それぞれの認証の概略とメールスプーフィングとの関係についてまとめる。
SPF（Sender Policy Framework）
概略
SPFでは、メールの送信元のIPアドレスを認証する。
送信者側は事前に自身の権威DNSサーバにSPFレコード形式で送信を許可するIPアドレスの一覧を登録しておく。受信者は、メールを受信するとメールの送信元ドメインの権威DNSサーバにSPFレコードの有無を問い合わせる。SPFレコードがあれば送信元IPアドレスを検証する。
example.com IN TXT "v=spf1 +ipv4:a.b.c.10 +ipv4:a.b.c.20 -all"
この例では、example.comのドメインからメールを送信するのはa.b.c.10とa.b.c.20しか存在せず、それ以外は認証を失敗させてハードフェイル（強めの拒否）をするという設定になっている。また、他社のサービスのメールサービスを利用する場合は、別のドメインのSPF設定を借りるような書き方をすることもできる（include:mail.service.com）。
メールスプーフィングとの関係
SPFを設定することで、送信元IPアドレスが異なるような攻撃者のメールサーバから送られるメールは認証に引っかかるようになるはずである。ただし、SPFレコードの問い合わせ先はエンベロープFROMのドメインを参照するということに気をつけなければいけない。
攻撃者が正当な手段で取得したドメインを利用し、エンベロープFromにそのドメイン名が記載されている場合は、当然ながら参照されるポリシーは攻撃者の設定したものとなる。そのため、攻撃者のメールはそのままSPF認証をすり抜けて送信ドメイン認証済みのメールとして届いてしまう。
SPFはあくまでもエンベロープFromの詐称を検知するためのものである。したがって、攻撃者が攻撃者のメールサーバから送ったメールのエンベロープFromを詐称せずに正直に送信すれば認証を通過する。
DKIM（DomainKeys Identified Mail）
概略
DKIMでは、メールに電子署名を導入することでメールの完全性と送信者の真正性を検証する。
送信者側は事前に電子署名に用いる鍵ペア（秘密鍵・公開鍵）を生成し、自身の権威DNSサーバにDKIMレコード形式で公開鍵を登録しておく。送信者はメール送信時にメールに秘密鍵で電子署名を付与する。受信者は、DKIM署名が付与されたメールを受信すると、署名に記載されたドメインの権威DNSサーバへDKIMレコードを問い合わせ、公開鍵を取得する。受信者は、公開鍵で署名を検証する。
hoge._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=<公開鍵>"
メールスプーフィングとの関係
DKIMを設定することで、送信元が設定した秘密鍵を持たない攻撃者は電子署名を偽造できないため、認証に引っかかるはずである。ただし、DKIMレコードの問い合わせ先はDKIM署名に記載されたドメインであるということに気をつけなければいけない。
SPFと同様に、攻撃者が正当な手段で取得したドメインを利用し、DKIM署名にそのドメイン名が記載されている場合は、当然ながら参照されるポリシーは攻撃者の設定したものとなる。そのため、攻撃者のメールはそのままDKIM認証をすり抜けて送信ドメイン認証済みのメールとして届いてしまう。
また、DKIM認証はメールにDKIM署名が付与されている時に認証を行うため、攻撃者がDKIM署名を付与しなければそもそも認証が行われない。このケースは、そもそもDKIM認証を行わないようなメールは全て拒否するといった受信側の工夫も問われる。
DMARC（Domain-based Message Authentication Reporting and Conformance）
概略
DMARCでは、SPFやDKIMの認証が行われていることを前提に、認証成功時の追加の認証事項や認証失敗時の対応を定めることができる。
送信者側は自身の権威DNSサーバにDMARCレコードを登録しておく。受信側はメールを受信するとヘッダFromを参照し、権威DNSサーバにDMARCレコードを問い合わせる。DMARCレコードがあれば、DMARCの設定内容に応じてSPF・DKIM認証の追加の処理を行う。
_dmarc.example.com IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com;"
追加の処理としては以下のようなオプションがある。
-
p=[none,reject,quarantine]: SPF・DKIM認証に失敗した場合の処理を追加 -
aspf=[r,s]: エンベロープFromドメインとヘッダFromドメインの一致を追加で検証するかどうか -
adkim=[r,s]: DKIM署名のドメインとヘッダFromドメインの一致を追加で検証するかどうか -
rua=mailto:rua@example.com: 集計レポートの通知先アドレス -
ruf=mailto:ruf@example.com: 失敗レポートの通知先アドレス
メールスプーフィングとの関係
SPF・DKIMの問題点は、ポリシの参照先ドメインが詐称可能であり、ポリシのすり替えが可能であったことである。一方で、DMARCはメールのヘッダFromを参照してDMARCレコードを取得する。メールスプーフィングの特性上、メールクライアントの差出人であるヘッダFromは詐称されるはずである。したがって、自社のドメインを詐称したメールに関しては、自社のDMARCポリシを参照させることを強制できる。
SPF・DKIM認証に加えて、DMARC検証ではaspfとadkimのオプションを用いて、成功した認証の正当性を確認することで、SPF・DKIM認証のポリシが誤魔化されていないかを検証する。
SPF認証を誤魔化すためにヘッダFromを詐称し、エンベロープFromには攻撃者のドメインが入っている場合、DMARCをaspf=sで設定しているとエンベロープFromとヘッダFromが一致しないため認証は失敗する。
また、DKIM認証を誤魔化すためにヘッダFromを詐称し、DKIM署名のドメインには攻撃者のドメインが入っている場合、DMARCをadkim=sで設定しているとDKIM署名のドメインとヘッダFromが一致しないため認証は失敗する。
まとめ
DMARCはメールスプーフィングの特性上誤魔化せないヘッダFromを参照するという特性がある。そのため、SPF・DKIM認証の正当性の検証を行うために追加しておくと、メールスプーフィングの対策になる。
調べながらまとめていったため、間違っている箇所もあるかもしれません。間違いのご指摘は歓迎ですので、コメントからよろしくお願いします。
Discussion