DMARCの対応って進んでますか？ - エムスリーテックブログ

こんにちは。エムスリーでSREやセキュリティに従事している山本です。

以前に、「Gmailのメール認証規制強化への対応って終わってますか？」という記事を書かせていただいておりますが、そこでちょい出しだけしたDMARCについて書かせていただきたいと思います。

www.m3tech.blog

Gmailへの対応を実施するだけならば、「とりあえずよくわかんないけど入れておけばOK」なのですが、そもそもDMARCは何のために存在していてどのように活用にするのかというところに触れていきたいと思います。

DMARCとは
DMARCレポート
まとめ
We are hiring!

DMARCとは

DMARCの日本における普及は進んでいないと言われることがあります。それ以前に「何のために存在するのか」「どのような動きをするのか」というところから知られていない部分もあります。

SPF/DKIM

前回の記事で触れたSPF/DKIMについておさらいします。

SPF : メール送信元のIPを自ドメインのDNSに登録しておくことで、そのドメイン権利者からの送信であることを担保する
DKIM : メールに署名を付与し、その署名をした秘密鍵と対になる公開鍵を自ドメインのDNSに登録しておくことで、そのドメイン権利者からの送信であることを担保する

つまりどちらも目的は 自社のメールが自社から送られたことを保証するものです。

これはもちろん正しいことであり、ブログでもその方法について書いてきました。しかしそれは「なりすましで自社ドメインからメールを送る人たち」に対する直接的な防御策にはなりません。

DMARC登場

DMARCはSPF/DKIMを使った技術ですが、少し毛色が異なります。SPFやDKIMをアラインメントを含めて正しく設定すればDMARCはPASSするのですが、目的とするところに違いがあります。

SPF/DKIM → 自社のメールが自社から送られたことを保証する
DMARC → なりすました自社ドメインのメール(DMARCをPASSしないメール)について拒否/隔離するように指示ができる

自社のメールでDMARCをPASSさせる努力というのは、裏を返せばDMARCにPASSしないメールは偽物だ、と言い切るための努力です。実際に有名な大手企業を名乗る迷惑メールも存在いたします。迷惑メールでなく、実際の企業名を偽る詐欺師かもしれません。そのようなメールを可能な限り削減するためにできる対策なのです。

DMARCで実施できるポリシー三種

DMARCのDNSレコードではポリシーの指定が実施されます。以下の三種です。

p=none : DMARCにPASSしなくても特に何もしない(メールサーバの基準に沿って迷惑メール扱いなどをすることを妨げるわけではない)
p=quarantine : DMARCにPASSしないなら隔離する(迷惑メールフォルダなど)
p=reject : DMARCにPASSしないメールは拒否する

実際に各社を見てみましょう。我らがエムスリーは none、Googleは reject、Appleは quarantineです。

$ dig +short txt _dmarc.m3.com
"v=DMARC1;p=none;rua=mailto:dmarc@m3.com;ruf=mailto:dmarc@m3.com;rf=afrf;pct=1"

$ dig +short txt _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

$ dig +short txt _dmarc.apple.com
"v=DMARC1; p=quarantine; sp=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

ポリシーの強化

今回、Gmailでのメール認証で大量送信にはDMARCが必須となりましたが、「とりあえず入れとけ」については p=noneもありです。しかし、本来は none よりも強いポリシーの方が効果的です。

自社のDMARCポリシーを仮に reject や quarantine にすれば、少なくとも対応したメールサーバにおいて、明確になりすましメールを判別できるようになります。それは、例えば XXXX@m3.com を名乗ってフィッシングサイトに誘導するようなスパムメールを排除できるわけですし、社員を名乗る詐欺師が @m3.com を騙ったメールを出す事も困難となります。

これがメールセキュリティの現状での目的地です。

強化できるか

自社のメールでDMARCをPASSさせる努力というのは、裏を返せばDMARCにPASSしないメールは偽物だ、と言い切るための努力です。

上でこのように書きましたが、Gmailの規制強化に伴って自社のメールサービスが完璧にSPF/DKIMに対応できれば、確実に「DMARCにPASSしないメールは偽物」と言い切れるはずです。それならば p=none と日和ってないでさっさと p=rejectなどにすればよいはずです。

それができないのは、必ずしも全ての正しいメールがSPF/DKIMに対応できていないかもしれないので自信がないという事です。メールを送信する側は勝手に送信していますが、相手のメールボックスで迷惑メールフォルダに入ってしまっているとすれば、それは検知できません。だから「自信がない」ので断行できません。エムスリーに限らずグローバルに展開している場合には、m3.com を使っているのが国内に限らなかったりしますので、全体的な影響が出てきます。

ちなみに、デフォルトではDMARCのポリシーはサブドメインに継承されます。usa.m3.com などといったドメインについても m3.com のポリシーがそのまま継承されますが、もしもそれが困る場合にはポリシーを上書きするような設定も可能です。ですので、サブドメインごとに分割した運用がなされている場合は影響度を小さくしながら進行させる事も可能です。

DMARCレポート

影響するかもしれないから断行できないといっているといつまでたっても実施できないのですが、そのためにDMARCレポートと呼ばれるものが用意されています。

RUA/RUFの二種のレポート

$ dig +short txt _dmarc.m3.com
"v=DMARC1;p=none;rua=mailto:dmarc@m3.com;ruf=mailto:dmarc@m3.com;rf=afrf;pct=1"

DMARCの指定の中で ruf や rua というものがあります。この f の方が失敗メール、 a の方が集約情報のメールです。DMARCに対応したメールサーバが日々、 @m3.com からのメールをチェックしてレポートとして送信してくれるのです。このレポートをチェックいたします。多くのメールを送信している場合とても大量に受信することになりますので、受信先のメールアドレスは注意してください。

念のためですが、RUAレポートのXMLには個人情報や機密情報は一切含まれていません。(メールを送信した先のドメイン名などは含まれます。) RUFレポートにも基本的には含まれませんが、もう少し詳細な情報があります。

このレポートを使って次の確認ができます。

自社から送信したメールでSPF/DKIM/DMARCで失敗しているものはないか？
なりすましその他が横行して怪しいメールが飛び交っていないか？

DMARCレポートの確認ツール

XMLなので、そのまま目で眺めてもちょっと意味がわかりません。

以下はMicrosoftから送信されてきたRUAレポートのごく一部です。

<?xml version="1.0"?>
<feedback xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <version>1.0</version>
  <report_metadata>
    <org_name>Enterprise Outlook</org_name>
    <email>dmarcreport@microsoft.com</email>
    <report_id>b64757d736234cc382af6df3d7049a5b</report_id>
    <date_range>
      <begin>1700956800</begin>
      <end>1701043200</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>m3.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>1</pct>
    <fo>0</fo>
  </policy_published>
  <record>
    <row>
      <source_ip>35.76.16.148</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_to>XXXX.co.jp</envelope_to>
      <envelope_from>bounce.m3.com</envelope_from>
      <header_from>m3.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>m3.com</domain>
        <selector>awsmail-20180830</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.m3.com</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
...

よく見るとなんとなく意味はわかりますが、非常に大量なので全てをチェックするわけにはいきません。これを解決するためにはDMARCのレポート解析ツールを使うことになります。受信したレポートメールを自動的にツールに流し込んで…、ということです。有償のツールが多いと思いますがちょっと手動で見てみるレベルならば以下のものでも良いと思います。どちらもアメリカの企業の提供するものです。

では実際に、Microsoftから来たRUAレポートを後者のサイト(dmarcian)で処理してみます。このサイトではレポートをきれいに可視化してくれます。ただし、10MBが上限ですので多すぎる場合は適当に区切ってください。複数のレポートファイルをアップロードできます。

念のためXMLの要素のうちenvelope-toをsalt+hash化して隠して<envelope_to>b94fdc2eac3669a489d7ff566c40c4ee6729d8dc.com</envelope_to> のような形にしてからアップロードしました。実際にアップロードされたのはヘッダFromドメイン、envelope-from、送信元IP、DKIMドメイン、DKIMセレクタあたりです。送信先はMicrosoftメールを使っているとはいえ、多種多様のドメインとなります。ここを隠しておきました。レポートURLが生成されますのでそれはシェア可能ですが広く公開されます。確認が終わったら消しておくと良いでしょう。

この場合はThreat/Unknownのタブ(赤いところ)を選択して中身をよく見てみます。

これは、SPF/DKIMが Pass かつ fail-unaligned です。簡単に言えば、次の状態です。

ヘッダFromは m3.com(元々m3.comのレポートですのでそうなります)
envelope-fromとして willap.jpを使っていて、willap.jpのSPFに合致します(つまり、WiLL Mailです)
dkim1._domainkey.willap.jp というDKIMのセレクタに対応する鍵で署名を実施されています

SPF/DKIMともに問題ありませんが、ヘッダドメインと不一致です。(つまり、アラインメントチェックで失敗しています。)

どう判断するか

そのようなメールがレポートされていたとして、次のどちらかです。

誰か悪い人が m3.com を名乗って WiLL Mailで送信している
M3で設定してWiLL Mailで送信しているが、DKIMの設定を作成者署名にしていない

WiLL Mailはenvelope-fromが bounce@willap.jp となりますが、DKIMは変更可能です。おそらくはこの変更もれなのでどこの部署がこのメールを送信しているのかを探すということになってくるのです。

もしも仮に前者だとしたら、それはそれで問題ですが、送信できる以上は直接的には手出しできません。しかし m3.com から送信しているメールから撲滅した時に DMARC設定を変更して reject などにすることでDMARCに対応したメールサーバで拒否させることができるというわけです。

メール転送

他にもレポートに検出された怪しいメールがいくつかあります。

例えば同じようなWiLL Mailからのメール送信でも、これは我々の管理しないIP(その逆引きは XXXX.go.jp) からの送信となっており、envelope-fromである willap.jpとは一致しません。

断言はできませんが、おそらくは XXXX.go.jp で受けたメールをMicrosoftに転送したのでしょうか。そのために送信IPが変化してしまったと。SPFは転送に弱いのでこのようなことが発生します。DKIMについても転送でヘッダ等が変化した際に、電子署名とずれてしまうことがあります。(DKIMはヘッダやボディの中身に署名しますので、そこが書き換えられると改ざんと判断されます。)

このようなものはそれなりに散見されますが、直接的には手出しできませんので今回は静観しています。