![見出し画像](https://assets.st-note.com/production/uploads/images/88115606/rectangle_large_type_2_fde411214a4c5aaa1e9e30208d5640e8.png?width=1200)
【図解】メール認証とDNS
メールの送信元認証を、DNSの観点から学習し、図解してみました。
送信元メールアドレスを偽装することは比較的簡単で、なりすまし・標的型攻撃によく使われます。私のYahooメールにも、偽Amazonから「アカウント停止するぞ」メールが頻繁に来ています。登録情報が不完全だからって、天下のAmazon様が末端ユーザのアカウントを停止するなんて、特にメリットがないと思うんですけどね。
偽装メール対策として、メールの送信元が正しいかを認証する仕組みがあります。今回は、以下の3種類の技術について調べてみました。
SPF(Sender Policy Framework):送信元IPアドレスの認証
DKIM(DomainKeys Identified Mail):電子署名による認証
DMARC(Domain-based Message Authentication, Reporting, and Conformance):認証失敗時の動作定義
これらの技術は、DNSのTXTレコードを使っている点で共通しています。TXTレコードを使って、決められた文字列をやりとりすることで、送信元の認証や認証失敗時の動作定義をしています。
下図が、メール認証とDNSの全体像です。業界スタンダード?の、Alice(example.com)からBob(example.net)にメールを送るシチュエーションですね。図の左上部がAliceが送るメールの情報です。
![](https://assets.st-note.com/img/1664687607777-FJJgCx5DTe.png?width=1200)
Aliceからのメールを受け取ったexample.netのメールサーバは、送信元メールアドレスであるexample.comのDNSサーバに問い合わせを行います。
SPF認証では、メール送信元のIPアドレスと、SPFのTXTレコードに記載されているIPアドレスを比較して検証します。送信元の住所として記載されたものが合っているか、Alice本人に電話して確認するようなイメージですね。
TXTレコードには、送信元として許可されたIPアドレス(FQDNでも可)と、認証結果の処理内容が記載されます。ただし、認証結果の処理内容はゆるい定義でしかなく、最終的には受信側の設定に依存します。
DKIM認証では、秘密鍵と公開鍵の仕組みを使って送信元を検証します。メール送信元が秘密鍵を使って電子署名を行い、メール受信者が公開鍵を使って電子署名を検証します。Aliceが特殊な印鑑を押して、Bobがその印影を確認するイメージですね。
TXTレコードには、電子署名の公開鍵が記載されます。また、TXTレコードのホスト名として、[セレクタ名]._domainkeyが使われます。
DMARCは、認証失敗時の動作を定義する仕組みです。SPF認証やDKIM認証だけでは、認証失敗したメール(なりすましメール)が受信側でどう処理されたか、送信側は把握できません。DMARCを使うことで、認証失敗時の動作ポリシーを送信側が公開し、受信側の動作をコントロールしたり、受信側からレポートを上げさせたりすることができます。
TXTレコードには、認証失敗時のポリシー(none、reject、quarantineなど)や、レポートの送付先を指定できます。また、TXTレコードのホスト名として、_dmarcが使われます。
上図では、SPF認証・DKIM認証ともに問題ないので、DMARCの記載は無視して、Bobはメールを受信します。
※DKIM認証の値は一致しませんが、イメージで…
次に、AliceになりすましたMalloryが、Bobにメールを送るシチュエーションで考えてみましょう。
![](https://assets.st-note.com/img/1664687585149-Q3t99TX9Y9.png?width=1200)
送信元のMalloryは、送信元メールアドレスをAliceのものに偽装し、電子署名を付与して、Bobにメールを送信しました。受信側のBobは、送信元メールアドレスexample.comのDNSサーバに問い合わせて検証を行います。
SPF認証では、メールのIPアドレス198.51.100.1と、SPFレコードを比較します。+で許可された192.0.2.1/32とは合致しないため、~allに該当することになります。~は、不正メールとして処理されるが、配信もされる識別子です。よって、この時点では、SPF認証はNGだがメール受信はする、という状態です。
DKIM認証では、DKIMレコードからAliceの公開鍵を取得し、メールに付与された電子署名と検証します。検証の結果、Aliceの秘密鍵で作成された電子署名ではないことがわかりました。DKIM認証はNGですが、DKIMは受信側の動作には干渉しないので、メール自体は受信する状態です。
DMARCでは、DMARCレコードの記載に沿って、認証失敗時の受信動作を確認します。Aliceの属するexample.comのDMARCレコードには、認証失敗時は受信しない(p=reject)、と定義されています。今回はSPF・DKIMともに認証失敗しているので、受信側のexample.netは、送信側のDMARCレコードの動作定義に従い、このメールを削除します。よって、Bobがこのメールを目にすることはありません。また、DMARCレコードに記載されたdmarc@example.comに対して、集計レポート・認証失敗レポートが送信されます。
以上、メール送信元認証の仕組みを、DNSの観点から見てきました。
他のレコードと比較して、TXTレコードは記載の自由度が高く、何に使われているかがわかりにくいものでした。メール送信元認証を通じて、使われ方の一例を知ることができました。
SPF・DKIMでは検知だけを行い、透過or削除の動作定義はDMARCで行う、という点が特徴的だと感じました。ネットワークにおけるIDSとIPSに似ていますが、検知と防御を兼ねるIPSに対して、DMARCは防御専門ですね。
また、記載を間違えれば動作しなかったり、意図しない動作になったりします。~allと-all(チルダとハイフン)とか、紛らわしいです… DNSに限らず、事前の動作検証が大切だと思いました。
実際の運用では、認証失敗したら即削除、みたいなハードな設定は少なそうです。上記の例のようにDMARCの動作をrejectにするのは、結構勇気がいりますね。
#図解 #最近の学び #メール #認証 #メール認証 #DNS #DNSレコード #TXTレコード #SPF #DKIM #DMARC #エンジニア #ネットワーク
この記事が参加している募集
いつも図書館で本を借りているので、たまには本屋で新刊を買ってインプット・アウトプットします。