当社は本日、メールのスプーフィングやフィッシングに対抗し、メールの到達性を向上させる新たな対策ツールを発表します。新しい_Email Security DNS Wizard_を使って、お客様のドメインに代わって他者が悪意あるメールを送信するのを防ぐDNSレコードを作成できます。この新しい機能は、ドメイン上のセキュアではないDNS設定についてユーザーに警告し、その解決方法についてアドバイスも提供します。この機能はまずFreeプランのユーザーを対象に展開され、今後数週間でProプラン、Businessプラン、Enterpriseプランのお客様にもご利用いただけるようになります。
このWizardの機能について詳しくご紹介する前に、少し戻ってメールのスプーフィングとフィッシングの問題についてみていきましょう。
メールスプーフィング・フィッシングとは？
スプーフィングは他の誰かになりすますことで、何らかの不法利益を得るために行われる場合があります。例としてドメインスプーフィングがあり、mycoolwebpaqe.xyzのようなWebサイトをホストして、 mycoolwebpage.xyzのユーザーをだまし、機密情報を提供させ、気づかぬうちに偽のWebサイトにアクセスさせます。ブラウザでアドレスバーを横に並べてみても、違いをみつけることがとても難しくなっています。
また、メールスプーフィングもあります。この仕組みを理解するために、筆者のメールアドレスで受信したCloudflare製品更新のメールを見てみましょう。ほとんどのメールプロバイダーでは、いくつかのヘッダーとメール本文を含むメールのソース全体を見ることができます。
上記の例では、メールに4つのヘッダーがあることがわかります。メールの受信日時（Date）、送信元（From）、返信先（Reply-to）、筆者のメールアドレス（To）です。Fromヘッダーの値は、メールプログラムでメールの送信者を表示するために使われています。
Date: Thu, 23 Sep 2021 10:30:02 -0500 (CDT)
From: Cloudflare <product-updates@cloudflare.com>
Reply-To: product-updates@cloudflare.com
To: <my_personal_email_address>上記のメールを受信すると、Cloudflareから送信されたメールだと思うのが自然です。しかし、改変したFromヘッダーつきのメールを他のメールサーバーから送信しようとする者がいれば、それを止めることはできません。メールプロバイダーが的確なチェックを行っていなければ（このブログの後半でも取り上げます）、本当はそうではないのに騙されて、Cloudflareから送信されたメールだと信じてしまう可能性があるのです。
続いて、2つ目の攻撃タイプがフィッシングです。たとえば、悪意のある行為者がメールスプーフィングによって、お客様の企業サービスメールからのメールと見せかけてお客様の顧客へのメール送信に成功したとしましょう。メールの内容は、同じ様式とフォーマットを使用しているので、お客様からの正規のメールとまったく同じようにみえます。メール本文は、緊急性の高いメッセージを装いアカウント情報の更新を求めるもので、偽のWebポータルへのハイパーリンクを含むこともあります。ユーザーのメール受信サーバーがこのメールをスパムまたは安全ではないオリジンから送信されたものとしてフラグ付けしなければ、ユーザーはリンクをクリックしてしまい、悪意のあるコードが実行されたり、スプーフィングされたドメインに誘導され、機密情報を提供するように求められる可能性があります。
FBIが2020年に発行したInternet Crime Report（インターネット犯罪レポート）によれば、2020年に最も頻発したサイバー攻撃はフィッシングでした。24万人以上が被害に遭い、被害総額は5000万ドルを超えています。被害者の数は2019年と比べて2倍以上になっており、2018年と比較すると10倍近くなっています。
フィッシング攻撃がたいていどのように実行されるかを理解するために、2020年版のVerizonのデータ漏えい調査レポートをみてみましょう。フィッシングは、すべての「ソーシャルアクション」（別名、ソーシャルエンジニアリング攻撃）の80%に達しており、最も典型的な攻撃タイプとなっています。同レポートではさらに、ソーシャルアクションの96%がメール経由で送信され、わずか3%がWebサイト経由、1%が電話またはテキストで送信されると報告しています。
このことから、メールフィッシングが深刻な問題であり、インターネットユーザーの大きな頭痛の種であることがわかります。それでは、悪意のある行為者がドメインを不正利用してメールフィッシングするのを防止するために、ドメインオーナーができることについてみていきましょう。
DNSがフィッシング防止にどのように役立つか？
幸運なことに、3つのスプーフィング防止メカニズムが既にDomain Name Systemに組み込まれています。
Sender Policy Framework（SPF）
DomainKeys Identified Mail（DKIM）
Domain-based Message Authentication Reporting and Conformance（DMARC）
しかし、これらを正確に設定するのは、特に経験の少ない方にとっては容易なことではありません。設定が厳しすぎると、正当なメールがドロップされたり、スパムとしてマークされたりします。設定が緩すぎると、ドメインがメールスプーフィングに不正利用されてしまうかもしれません。
Sender Policy Framework（SPF）
SPFは、お客さまのドメインに代わってどのIP アドレスとドメインがメール送信を許可されているかを指定するのに使用されます。SPFポリシーはお客様のドメインのTXTレコードとして発行され、DNS経由で誰でもアクセスできます。cloudflare.comのTXTレコードをみてみましょう。
SPF TXT レコードは、常にv=spf1から始まる必要があります。このレコードには通常、IP4機構またはIP6機構を使うメール送信サーバーのIPアドレスのリストが含まれています。includeという機構は、別のドメインにある別のSPFレコードを参照するのに使います。通常は、Cloudflareの代わりにメールを送信する必要がある他のプロバイダーに依存している場合に使います。上記のcloudflare.comのSPFレコードでいくつかの例を確認できます。当社では、カスタマーサポートソフトウェアとしてZendeskを使用しており、マーケティングや取引のメールではMandrillを使用しています。
cloudflare.com TXT "v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"最後に、キャッチオールの機構-allがあります。これは、受信する詳細不明のメールすべての扱いについて指定します。このキャッチオールの機構は、頭に+（Allow：許可）、~ (Softfail：ソフトフェイル) または -（Fail：失敗）のいずれかの記号が付きます。Allowの限定子の使用はお勧めできません。基本的に、お客様のドメインの代わりにメールを送信することをすべてのIPアドレスとドメインに許すこととなり、SPFレコードの用をなさないからです。 Softfailはメールの受信サーバーによって解釈が異なり、メールがスパム（安全ではない）かどうかの判断はサーバー次第になります。 Failは、詳細不明のソースから送信されたメールを受け取らないようにサーバーに伝えます。
上図は、受信メールがSPFに準拠するものであることを確認するステップを示しています。
メールは、IPアドレス203.0.113.10から送信され、Fromヘッダーと、hannes@mycoolwebpage.xyzという値が含まれています。
このメールを受信した後、受信者はmycoolwebpage.xyzについてSPFレコードに問い合わせ、このドメインのSPFポリシーを取得します。
受信者は、送信IP アドレスの203.0.113.10がSPFレコードに記載されているかどうか確認します。記載されていれば、メールはSPFチェック合格です。不記載の場合は、all機構の限定子が結果を左右します。
すべての機構を網羅したリストとSPFの詳細については、RFC7208をご参照ください。
DomainKeys Identified Mail（DKIM）
SPFで、許可されたIPアドレスとドメインのみがcloudflare.comに代わってメールを送信できるようにしましたが、あるIPがオーナーを変更し、Cloudflareがそれに気づかずSPFレコードを更新しなかった場合はどうなるでしょう。あるいは、同じIPでGoogleのメールサーバーを使用している別の誰かが、cloudflare.comになりすましてメールを送信しようとしたらどうなるでしょう。
こんなときに役立つのがDKIMです。DKIMは、公開鍵暗号方式でメールの一部分（通常は本文や特定のヘッダー）に暗号化署名するメカニズムを提供します。この仕組みについて説明する前に、cloudflare.comでDKIMレコードが使われている例についてみていきましょう。
DKIMは._domainkey.という構成になっており、セレクターはメールプロバイダーから提供されます。 DKIM TXT レコードの内容は必ずv=DKIM1から始まり、公開鍵がこれに続きます。kタグで参照されるのが公開鍵のタイプで、pタグの後に公開鍵本体が続きます。
google._domainkey.cloudflare.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMxbNxA2V84XMpZgzMgHHey3TQFvHkwlPF2a11Ex6PGD71Sp8elVMMCdZhPYqDlzbehg9aWVwPz0+n3oRD73o+JXoSswgUXPV82O8s8dGny/BAJklo0+y+Bh2Op4YPGhClT6mRO2i5Qiqo4vPCuc6GB34Fyx7yhreDNKY9BNMUtQIDAQAB"下記は、署名とDKIM確認の仕組みについての流れを簡略化したものです。
メールの送信サーバーが、メール内容からハッシュを作成する。
メールの送信サーバーが、このハッシュをDKIM秘密鍵を使って暗号化する。
暗号化されたハッシュを含むメールが送信される。
メールの受信サーバーが、メールドメイン上で発行されたDKIM TXTレコードから公開鍵を取得する。
メールの受信サーバーが、DKIM公開鍵を使ってハッシュを復号化する。
メールの受信サーバーがメール内容からハッシュを生成する。
復号化されたハッシュと生成されたハッシュが一致する場合、メールが正規のものであることが証明されます。そうでない場合、DKIMチェックは不合格となります。
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
t=1632416903; s=m1; d=cloudflare.com; i=@cloudflare.com;
h=Content-Type:MIME-Version:Subject:To:From:Date;
bh=uMixy0BsCqhbru4fqPZQdeZY5Pq865sNAnOAxNgUS0s=;
b=LiIvJeRyqMo0gngiCygwpiKphJjYezb5kXBKCNj8DqRVcCk7obK6OUg4o+EufEbB
tRYQfQhgIkx5m70IqA6dP+DBZUcsJyS9C+vm2xRK7qyHi2hUFpYS5pkeiNVoQk/Wk4w
ZG4tu/g+OA49mS7VX+64FXr79MPwOMRRmJ3lNwJU=DKIMの仕様の全容については、RFC4871とRFC5672をご参照ください。
Domain-based Message Authentication Reporting and Conformance（DMARC）
Domain-based Message Authentication Reporting and Conformanceは、とても長い用語ですが、次の2つの単語に焦点を当ててみましょう：_Reporting（レポート）_と_Conformance（適合性）_です。DMARCはまさにこの2つを提供するものです。定期レポートでは、不適合のメールやスプーフィングされている可能性のあるメールの数をメール送信者に知らせます。Conformanceは、メールの受信者に不適合メールの取り扱いについて明確なシグナルを送る手助けをします。メール受信者は、DMARCレコードがなくても、SPFやDKIMチェックに不合格だったメールに関する独自のポリシーを適用する場合があります。しかし、DMARCレコードで設定されているポリシーはメール送信者の明示的指示であるため、メール受信者が不適合メールの取り扱いについて自信をもって行えるようになります。
The DMARC TXT レコードは、常にメールドメインの_dmarcサブドメインにセットされています（SPF、DKIMと同様）。 内容は必ずv=DMARC1で始まらなければなりません。さらに、3つの追加のタグを確認できます：
ポリシータグ（p）は、SPFやDKIMのチェックで不合格だったメールについて、メール受信者がとるべき処理方法について教示します。可能性のある値は、none（無し）、 reject（拒否）、quarantine（隔離）です。noneポリシーは、「監視のみ」とも呼ばれ、チェックで不合格だったメールの受け取りを許可します。 quarantine（隔離）では、メール受信者はSPFやDKIMに一致しないメールをスパムフォルダーに入れます。reject（拒否）では、SPFやDKIMのチェックで不合格だったメールはドロップされ、届けられることはありません。
パーセンテージタグ（pct）は、指定されたポリシーを受信メールのサブセットに適用する際に使用できます。PCTは、DMARCの利用を開始しようとしていて、サブセットをテストすることで、すべての設定が正しく行われていることを確認したい場合に役に立ちます。
レコードにある最後のタグは、レポート送信先URI（rua）です。不適合メールについて集約したレポート（通常は毎日）を受信するメールアドレスを指定します。
_dmarc.cloudflare.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:rua@cloudflare.com"上は、DMARCの機能を手順を追って説明した図です。
メールは、hannes@mycoolwebpage.xyzを含むFromヘッダーを付けて送信されます。
メール受信者がドメインmycoolwebpage.xyzからSPF、DKIM、DMARCレコードを問い合わせ、必要なポリシーとDKIM公開鍵を取得します。
メール受信者が先ほど概説したようにSPFおよびDKIMチェックを実行します。両方に合格すればメールは受理され、受信箱に送信されます。SPFまたはDKIMチェックのいずれかで不合格となった場合は、DMARCポリシーに基づいて、それでもメールを受理するか、ドロップするか、スパムフォルダーに送信するかを決定します。
最後にメール受信者が集約レポートを送り返します。このレポートは、rua タグで指定されたメールアドレス次第で、そのアドレスを管轄する別のメールサーバーにも送信できます。
他のオプションのタグとDMARCの仕様の詳細は、RFC7489でご確認いただけます。
数字で見る現時点の普及状況
ここまで、問題点や、SPF、DKIM、DMARCを使ってそれを解消する方法について学んできましたので、ここからは、これらがどの程度広く採用されているのかについてみていきます。
Dmarc.orgはドメインのDMARCレコードの採用状況を、代表的なデータセットで発表しています。それによれば、2020年末時点でDMARCレコードを有するドメインは依然50%未満に留まっています。DMARCレコードがなければ、SPFおよびDKIMチェックを適切に実行できません。さらにこの調査では、DMARCレコードを有するドメインのうち65%以上が監視のみのポリシー（p=none）を適用しており、採用率引き上げの余地が大いにあることがわかっています。それらのドメインがメールの送信側なのか受信側なのかについての言及はありませんが、いずれにせよ、セキュアな設定にはDMARCレコードが含まれるべきです。（この点に関しては後で詳しくみていきます）。
2021年8月1日付の別のレポートでも、銀行セクターの事業体のドメインに関して同様の状況を報告しています。米国にある2,881の銀行事業体のうち、ドメインでDMARCレコードを発行しているのは44%に過ぎません。DMARCレコードを有するドメインでも、だいたい5件中2件はDMARCポリシーを「None」に設定していて、8%は「Misconfigured」（不適切な設定）とみなされています。デンマークでは銀行セクターのドメインのDMARC採用率が94%ときわめて高く、日本はそれとは対照的に、DMARCを使用しているドメインはわずか13%に留まります。SPFの採用は平均するとDMARCよりも有意に高くなっています。これは、SPF標準がはじめて実験的なRFCとして導入されたのが2006年で、DMARCが標準になったのが2015年だったことに関連しているかもしれません。
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:12px;overflow:hidden;padding:10px 10px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:12px;font-weight:normal;overflow:hidden;padding:10px 10px;word-break:normal;} .tg .tg-2bn0{font-size:22px;text-align:center;vertical-align:top} .tg .tg-auka{font-size:22px;text-align:left;vertical-align:top} .tg .tg-ozhh{font-size:22px;font-weight:bold;text-align:center;vertical-align:top}
国
事業体の数
SPF採用済み
| Country | Number of entities | SPF present | DMARC present |
|---|---|---|---|
| Denmark | 53 | 91% | 94% |
| UK | 83 | 88% | 76% |
| Canada | 24 | 96% | 67% |
| USA | 2,881 | 91% | 44% |
| Germany | 39 | 74% | 36% |
| Japan | 90 | 82% | 13% |
DMARC採用済み
デンマーク
53
91%
94%
英国
83
88%
76%
カナダ
example.com TXT "v=spf1 -all"
*._domainkey.example.com. TXT "v=DKIM1; p="
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;"24
96%
67%
米国
2,881
91%
44%
ドイツ
39
74%
36%
日本
90
82%
13%
この表から、改善の余地がかなりあることがわかります。
Email Security DNS Wizardの登場
では、SPF、DKIM、DMARCの採用率を上げ、メールのスプーフィングやフィッシングに対抗するためにCloudflareは何をしているのでしょうか？ その答えは、新しく登場したCloudflare _Email Security DNS Wizard_です。
本日より、Cloudflareダッシュボードの DNS タブで、2つの新しい機能をご利用いただけるようになりました。
「メールのセキュリティ」という新セクション
セキュアでない設定に関する新たな警告
_Email Security DNS Wizard_を使い始めるには、警告にあるリンクを直接クリックしてWizardの関連セクションにアクセスするか、新しいEmail Security セクションにあるConfigure（設定） をクリックします。後者の方法では、下記のオプションが利用可能です。
シナリオは2つ。ドメインを使用してメールを送信している場合と、していない場合です。ドメインを使用してメールを送信している場合、いくつかの簡単なステップに従えばSPF、DKIM、DMARCのレコードを設定することができます。SPFのステップは次のとおりです。
ドメインがメールを送信していない場合であれば、たった1回のクリックでこれら3つのレコードすべてを簡単に設定できる方法があります。
Submitをクリックすると、すべてのメールがチェックで不合格となり、メールの受信サーバーが拒否するよう、3つのレコードすべてを設定します。
メールのスプーフィングやフィッシングに対する対策
さあ、ドメインがメールのスプーフィングやフィッシングに対して安全であることを確認しましょう。CloudflareダッシュボードのDNSタブにアクセスするか、Cloudflare DNSをまだご利用でない場合はcloudflare.comでサインアップしてください。サインアップは無料で、所要時間はわずか数分です。
SPF、DKIM、DMARCについての詳細は、新しいラーニングページにDNS レコードに関連したメールのついての説明がありますので、こちらをご参照ください。