どれくらい自社ドメインがなりすまされているか、ご存知ですか?

2019年07月03日 水曜日


【この記事を書いた人】
古賀 勇

IIJ ネットワーク本部アプリケーションサービス部所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。

「どれくらい自社ドメインがなりすまされているか、ご存知ですか?」のイメージ
こちらもご覧ください

企業の情報システム部門でメールを担当されているみなさん、この問いに答えられる方は、どれくらいいらっしゃるでしょうか。

「そんなこと、気にしたこともない」という方も少なくないかもしれません。それもそのはず、これまで送信ドメイン認証を代表する SPF、DKIM は、送信者側が受信者側でどのように評価されたか知る術がありませんでした。ましてや、第三者の何者かが自社ドメインを勝手に使って誰かにメールを送っている、なんて知ることは不可能でした。

しかし、DMARC(RFC 7489;「ディーマーク」と発音します) の登場によって状況は一変しました。DMARC にはメール受信時点での送信ドメイン認証の結果を、差出人へレポートできる仕組みが備わっています。この DMARC の仕組みを利用し、またIIJセキュアMXサービスを利用することで、以下のようにグラフィカルに統計データを見ることが可能になりました。

どのような仕組みでこれを実現しているのでしょう?
今回は、この「DMARC レポート」の中身を詳しく見ていきたいと思います。

DMARC レポートを受信しよう

DMARC レポートを受け取るには、まず DMARC レコードの公開と、受け取るためのメールアドレスが必要です。例えば IIJ では以下のように設定しています。

_dmarc.iij.ad.jp. IN TXT "v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc-rua@dmarc.iij.ad.jp"

レポートを受け取るために必要な記述は rua= の部分です。rua は Reporting URL(s) for aggregate data の略で、通称「集約レポート」と呼ばれ、「SPF, DKIM の認証結果の集計を dmarc-rua@dmarc.iij.ad.jp に送ってほしい」という意味になります。宛先メールアドレスは複数設定することもできます。

DMARC レコードを宣言してから、Google (@gmail.com) や AOL (@aol.com) といった、DMARC レポートの送付に対応している事業者宛にメールを送信すると、だいたい一日くらいしてレポートが届くようになります。実物を見たい方は、ここで一旦読むのをやめて、明日以降、実際に届いた DMARC レポートを見てから、もう一度お越しください。

DMARC レポート大解剖

DMARC レポートは XML フォーマットで 1日 1通、GZIP 形式で圧縮された添付ファイルで送られてきます。(※1)(※2)
圧縮ファイルを展開すると、XML ファイルが出てきます。以下は Google から送られてきたもののサンプルの一部です。

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1551916800</begin>
      <end>1552003199</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.jp</domain>
    <adkim>s</adkim>
    <aspf>s</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.jp</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.jp</domain>
        <result>pass</result>
        <selector>key1</selector>
      </dkim>
      <spf>
        <domain>example.jp</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

簡単な説明は以下の通りです。

report_metadata DMARC レポートのメタデータを格納します。レポートを送ってくれた事業者の名前や、問い合わせ・リファレンス先の情報が入っていることがあります。
policy_published どの DMARC レコードのポリシーを参照したかが記述されます。
最も重要なのは、DMARC の認証に失敗したときに、そのメールをどう扱って欲しいかを明示する p タグです(必須)。
そのほか、adkim は DKIM のアライメント一致のモード(サンプルでは s = strict)、aspf は SPF のアライメント一致のモード(サンプルでは s = strict)、sp はサブドメインに対するポリシーです。pct はポリシーを適用して欲しい割合です。(※3)
record/row ここから送信ドメイン認証の結果のレポートが入ります。IP アドレス(source_ip)ごとにレポートされるため、自社で多くの送信メールサーバを持っている場合や、たくさんの詐称されたメールが観測された場合は、このセクションが非常に長くなります。通数(count)や、SPF、DKIM の評価結果が確認できます。
record/identifiers DMARC の評価ドメインです。DMARC は、みなさんがメーラーやアプリで見ている、ヘッダ From (RFC5322.From)ドメインを見て、DMARC ポリシーの参照を行います。
record/auth_results SPF と DKIM の評価結果が入ります。また、SPF はエンベロープ From (RFC5321.From)ドメイン、DKIM はヘッダ From ドメインと DKIM 鍵のセレクタ名が記録されます。

いかがでしょうか。
送信したメールが、受信者側でどのように評価されたのか、ちょっとメールの流れが見えてきましたよね? (※4)

DMARC レポートを活用しよう

こんな貴重なデータが無料で手に入るのなら、活用しない手はありません! 早速設定しましょう。
DMARC レポートを受け取るのに必要な最低限の DNS 設定は、以下の通り。3分でできます。(※5)

(例) example.jp ドメインに設定する場合:

_dmarc.example.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.jp"

レコードの意味は以下の通りです。

v=DMARC1 DMARC レコードの宣言 (必ず先頭に書いてください)
p=none DMARC の認証に失敗したときは何もしなくて良い
rua=mailto:dmarc-rua@example.jp DMARC レポートは dmarc-rua@example.jp に送ってほしい

もし、受け取ったレポートを見て、送信ドメイン認証の検証結果が fail となっている場合は、以下のようなケースが考えられます。

優先度
考えられるケース
対応指針
spammer がドメインを騙って送付している
  • あなたのドメインを spammer が利用(悪用)し、騙って送っていることを観測しているケースです。
  • 受信者は、なりすまされたメールを受信し、被害が出ている可能性があるため、早急に対処が必要でしょう。
  • DMARC のポリシーを p=reject(DMARC の認証に失敗したときは受信拒否して欲しい)に変更するなどして、なりすまされたメールは受け取られないように宣言することも検討してください。
管理外のメールサーバからメールが送信されている
  • 単純にあずかり知らぬ場所からメールが出ているケースです。
  • 社員が勝手にメールサーバを建ててメールを出してしまっていたり、SPF の登録漏れであるケースもあります。
  • また、4月に新入社員が配属された企業様も多いかと思いますが、E メールに対する理解不足から、仕事熱心な若者が管理の行き届かない場所から仕事をしてメールを送信してしまっているかもしれません。
  • DMARC レポートでは、こうした事案も早期に察知する手段の一つになりえますが、優しく E メールの知識についても教えてあげてください。
転送メールが出ている
  • 通常、転送メールはエンベロープ From を変更せずに転送先のメールアドレスへ送信するため、SPF の認証が失敗するケースです。
  • 社内ポリシーで許可していない場合は、ポリシー違反の可能性があるため、調査を進める必要があるかもしれません。
  • 幸い DMARC レポートには IP アドレスが掲載されていますので、対象サーバの特定は比較的容易です。
メーリングリストを経由している
  • 少し厄介なケースです。通常メーリングリストは、システムの都合上、エンベロープ From を書き換えて配送します。
  • さらにメーリングリストによっては、件名にメーリングリストの名前や番号を挿入し、本文を書き換えることがあります。
  • この場合、メールは元の状態ではなくなるため DKIM の検証ができず、エンベロープ From は元の差出人が記載されたヘッダ From とも異なってしまい、DMARC のアライメント(後述)が一致しないため、DMARC の検証に失敗します。
  • DMARC 認証を成功(pass)とするために、メーリングリストサーバ側でヘッダ From を書き換えるようにしたり、メーリングリストのドメインを分離するといった回避策の検討が必要かもしれません。

どのケースに該当しているかは、個々の事情により判断が異なりますので、参考情報として捉えてください。
(でも DMARC がなかったら、このような情報すら手に入らなかったので、とても有益なはずです!)

DMARC レポートをしばらく眺めていると、月初・月末に出現する傾向や、自社ドメインを詐称して送られる spammer の存在に気付くことがあります。また、正規な出口メールサーバなのに SPF レコードに含まれていなかったり、DKIM 署名がいつの間にか壊れていた、といった異常に気付くこともできますので、メールフローの透明化に役立てることもできます。

DMARC レポートの可視化

上記で取り上げた DMARC レポートのサンプルは、適度にインデントされて改行が入っているので、それなりに目でも読み解くことができますが、DMARC レポートを送付してくれる事業者によっては、インデントや改行が全く入っていないケースもありました。それもそのはず、DMARC レポートは人が毎日目で見て確認するのではなく、ある程度機械的に処理され、自動化されたシステムに組み込むことを想定して作られています。

そこで IIJ は、この DMARC レポートを自動で可視化するツールを開発し、2019年 3月より、IIJセキュアMXサービスで提供を始めました。
冒頭でお見せしたスクリーンショットは、IIJセキュアMXで提供中の DMARC レポート統計画面のサンプルです。

あの読みにくかった XML ファイルが、一気に可視化されましたね!

また、DMARC レポートは、それぞれの宛先の組織から届きますので、1日の傾向を把握するには全てのレポートを統合して集計する必要がありますが、これも自動で行ってくれます。大企業なら複数のドメインを管理していることも多くありますが、これも DMARC レポートの送付先をIIJセキュアMXサービスにするだけでできちゃいます!

IIJセキュアMXサービスをご契約のお客様は、上記で紹介した DMARC レポート解析機能を無料でご利用いただけます!
本機能をリリースしてから利用者も順調に増えており、お客様からも好評いただいております。ぜひ、ご活用ください。

(参考) IIJ、「IIJセキュアMXサービス」の機能を拡充し、DMARCレポート統計機能を提供開始

なお、DMARC レポートの XML スキーマは、RFC 7489 の Appendix C に記述があります。自力で解析システムを構築される場合は、参考にしてみてください。

「アライメント(Alignment)」という概念

最後に DMARC には「アライメント」という新しい概念があります。少し難しいのですが、メール担当者なら必ず理解して欲しいポイントです。用語を用語で説明してしまいますが、まず、SPF に要求されるアライメントは、以下の通りです。そういうものだと思ってください。

strict モード(aspf=s) エンベロープ From ドメイン = ヘッダ From ドメイン 完全に一致
relaxed モード(aspf=r) エンベロープ From の組織ドメイン = ヘッダ From の組織ドメイン 一致

ここで「組織ドメイン」という、また新しい用語が出てきてしまいました。

端的に言うと、組織ドメインとは iij.ad.jp のような、「みんなのものではないもの」です。
一方で、.com、.co.jp、.jp、.tokyo.jp などは、「みんなのもの」です。なぜなら、(誰も取得していなければ)その下のレベルのドメインを取得できるからです。

ここで言う「みんなのドメイン」は、Public suffix と言ってインターネット上で公開されており、時々アップデートされています。
https://publicsuffix.org/list/public_suffix_list.dat
そして、「組織ドメイン」「アライメント」には、以下のような関係が成り立ちます。

(例) 組織ドメインが iij.ad.jp のとき

  • 上図で例示したサブドメイン ml.iij.ad.jp、bounce.ml.iij.ad.jp、us.iij.ad.jp のいずれも、組織ドメインは iij.ad.jp です。
  • bounce.ml.iij.ad.jp の組織ドメインは、ml.iij.ad.jp ではないことに注意してください。

 

次に DKIM に要求されるアライメントは、以下の通りです。

strict(adkim=s) 署名ドメイン(d=) = ヘッダ From ドメイン 完全に一致
relaxed(adkim=r) 署名ドメイン(d=)の組織ドメイン = ヘッダ From の組織ドメイン 一致

そして、DMARC の認証が成功(dmarc=pass)となるには、

  • SPF の認証成功(spf=pass) & アライメント一致
    または
  • DKIM の認証成功(dkim=pass) & アライメント一致

であることが必要です。

つまり、spf=pass & dkim=pass でも、アライメントの不一致で DMARC の認証失敗(dmarc=fail)となるケースがあることに注意が必要です。

これは例えば、メールの配信を第三者の送信事業者に委託していて、ヘッダ From ドメインと、DKIM の署名ドメインが異なっている場合に該当することがあります。

DMARC がこのようになっているのは、差出人(ヘッダ From)ドメインと、DKIM の署名をしたドメインが異なると、その関係性が不明で、ヘッダ From のドメインがなりすまされていないことを証明できないからです。(spammer が適当なドメインを取得して、そのドメインで DKIM 署名し、ヘッダ From ドメインをなりすましたい組織のドメインにすることを想像してください。これを俗に DKIM の第三者署名といいます。)

大きな組織では、サブドメインを子会社や関連会社に委譲していたり、部署や機能ごとにサブドメインとして分けていることがあります。
SPF や DKIM は、ドメイン単位で対応する必要がありましたが、DMARC では「組織ドメイン」を DMARC 対応すれば、自動的に全サブドメインを DMARC 対応とすることもできる強力なフレームワークです。内部統制を進め、ポリシーコントロールをしたい企業様にとっても DMARC はとても有効なのです。

フィッシングメールの本当の影響

フィッシングメールを代表とする迷惑メールは、次から次へ新手のものが出てきて、正直終わりのない戦いです。しかし、送信ドメイン認証は、事前に対策ができます。

私が担当しているIIJセキュアMXサービスの配送状況をモニタリングしていると、明らかに送信ドメイン認証が不十分なドメインを差出人にしたフィッシングメールを観測しています。つまり、spammer は対策が手薄なドメインを攻撃用として使い、渡り歩き、フィッシングの成功率をあげようとしているのです。

フィッシングメールの存在は、ただ迷惑なだけでなく、なりすまされたドメインのブランド信用度の低下、広報窓口への無関係な問い合わせの増加といった、企業活動に無視できない影響を及ぼしますので、喫緊の課題として対策を進める必要があります。

脚注

  1. RFC の規定(RFC7489 Section 7.2)では、UTC の 00:00 を 1日の境界として集計し、送付することを推奨していますが、実際はそうなっていない事業者もあります。[↑]
  2. RFC の規定(RFC7489 Section 7.2.1.1)では、GZIP 形式で圧縮して送付することが望ましい(SHOULD)とされていますが、一部の事業者(Google など)は ZIP 形式の圧縮で送付されてくるもあります。[↑]
  3. pct の動きは少し厄介で、何パーセントの割合で p で宣言したポリシーを適用して欲しいか、という意味になります。可用性を考慮したシステムであれば、通常複数の受信メールサーバ郡で構成されますが、M3AAWG で DMARC の RFC を執筆された方に伺ったところ、システム全体の流量ではなく、個々のサーバで弾き出した割合を適用するべきと説明してくださりました。DMARC 対応を進めていく上でのスロースタートを考慮した設計ですが、実際にテストをしようとするとポリシーが適用されたりされなかったりして、とても分かりにくい動きをしますので、極力 pct タグは書かないことをオススメします。無指定の場合、pct=100 として扱われます。[↑]
  4. 日本語の文献として「なりすまし対策ポータル ナリタイ」や、送信ドメイン認証全般について IIJ 鈴木が Internet Week で公演した資料「キャッチアップ!2020に向けたメール運用 送信ドメイン認証導入指南2018」にも詳しい説明がありますので、よろしければご覧ください。[↑]
  5. DMARC レポートには、上記のようにメールに関する様々な情報が見えるようになります。特に企業・団体のドメインを管理している場合は、どのような情報が見えるようになるのか、事前によく関係者に話を通しておく必要があります。[↑]

古賀 勇

2019年07月03日 水曜日

IIJ ネットワーク本部アプリケーションサービス部所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。

Related
関連記事