東京農工大学 大学院工学研究院 助教
北川 直哉
１．はじめに
標的型攻撃による機密情報の漏洩や、フィッシング詐欺による被害がメディア等でもさかんに取り上げられているが、これらの攻撃の入り口として電子メールが最も頻繁に悪用されている。例えば標的型攻撃では、攻撃者が取引先企業の人物や職場の同僚などになりすまして電子メールを送信し、そのメールの添付ファイルを開封した受信者をマルウェアに感染させる手口がよく知られている。また、フィッシング詐欺では、ショッピングサイトやオンラインバンクなどになりすまして、パスワードの変更を促すなどの内容で受信者にフィッシングサイトに誘導し、個人情報や金銭の奪取を試みる手口が典型的である。
なりすましメールを送信する攻撃者は、本来の送信者に関する情報を様々な手段でなりすまして送信する。その代表的な手口として、以下の3つの方法が挙げられる。
- 表示名（ディスプレイネーム）を詐称する
- 本物の送信者のドメイン名と類似したドメイン名を使用する
- 本物の送信者のドメイン名を詐称する
1．のディスプレイネームの詐称は、受信者のメールソフト上で表示される送信者の表示名（個人名や法人名など）を偽って記述する手口であり、最も容易に詐称が可能な方法である。この手口は、攻撃者はフリーメール（GmailやYahoo!メールなど）のアカウントを取得して送信される場合や、攻撃者が独自に取得した無関係なドメイン名（大量に自動生成したランダムな文字列の羅列であることが多い）を用いて送信する場合が多いが、以降で解説する2.や3.の手口においても、ディスプレイネームも合わせて詐称する場合が多い。
2．の本物の送信者のドメイン名と類似したドメイン名（ホモグラフドメインやカズンドメインなどと呼ばれる）を使用したなりすまし方法では、人間が文字列の違いを見分けるのが難しいドメイン名（例：（正）example.com（誤）examp1e.comなど）や、本物とはトップレベルドメインが異なるドメイン名（例：（正）example.com（誤）example.netなど）などをあらかじめ取得し、そのドメイン名で生成したメールアドレスからなりすましメールを送信する手口である。
3．の本物の送信者のドメイン名を詐称して送信されるなりすましは、本物とは異なるホストから本物の送信者のドメイン名を偽って送信する手口である。この記事で解説するDMARC （Domain-based MessageAuthentication, Reporting & Conformance） と、これに深く関係するSPF（Sender Policy Framework）およびDKIM（Domainkeys Identified Mail）の2つの送信ドメイン認証は、いずれもこの手口に対して有効な認証技術であり、1．や2．の手口を用いたなりすましを防ぐものではないことに注意されたい。
２．送信ドメイン認証技術
DMARCは、現在広く利用されているSPF（SenderPolicy Framework） とDKIM（Domainkeys IdentifiedMail）のどちらの認証にも失敗したメールに対して、受信サーバがどのように処理するべきかを、送信側ドメインの管理者が指定することができる仕組みである。まず、DMARCで利用されるSPFとDKIMの2つの送信ドメイン認証技術について説明する。
2.1 SPF
SPF（Sender Policy Framework）は、メール送信側ドメイン名の正当性を検証する機構として広く利用されている。送信側の管理者は、あらかじめ自ドメインのDNS権威サーバでSPFレコードを公開しておく必要がある。SPFレコードでは、レコードを公開しているドメインからメールを送信するSMTP（Simple Mail TransferProtocol）サーバのIPアドレスのリストを宣言する。
図1に、受信サーバがsender@example.comからのメールを受信した場合のSPFによる送信ドメイン認証の流れを示す。
この例では、送信側は「example.comというドメインからのメールは192.0.2.0/24のアドレスブロックに含まれるIPアドレスを持つホストから送信する」旨を宣言していることを示す。受信側では、example.comからのメールを受信すると、当該ドメイン名のDNS権威サーバにSPFレコードを問い合わせて情報を取得し、その送信サーバのIPアドレスと比較する。図1の例では、このメールを送信したSMTPサーバのIPアドレスは「192.0.2.1」であり、SPFレコードで宣言された「192.0.2.0/24」のアドレスブロックに含まれているため、SPF検証は成功する。
SPFはこのような流れで正当な送信サーバの検証を行うしくみとして広く利用されているが、図2に示すようにメールが転送された場合に、なりすましメールではない配送であるにも関わらず検証に失敗してしまう弱点を持っている。
図2の例では、IPアドレスが192.0.2.1であるSMTPサーバから送信されたメールは、IPアドレスが198.51.100.1であるサーバに転送された後に受信者に送信されている。この場合、送信者のアドレス（Envelope-Fromアドレス）は変化しないが、受信サーバから見た送信サーバのIPアドレスは198.51.100.1となり、SPFレコードで示されたIPアドレスブロックに含まれないことから、SPF検証は失敗となる。
2.2 DKIM
DKIM（Domainkeys Identified Mail）は、電子署名を用いた送信ドメイン認証の機構であり、多くのメールサービスで利用されている。DKIMによる検証では、送信側ではメッセージのヘッダと本文から生成した電子署名をメールヘッダに付加して送信し、受信側でその電子署名を照合することによって送信ドメイン認証を行う。このためDKIMはSPFとは異なり、中継するMTA（メール転送エージェント）で電子メールのデータが変更されない限り、転送メールであっても転送先で正しく認証することができる。
DKIMによる検証の流れを図3に示す。
送信側はあらかじめ、署名に使用する秘密鍵と対になる公開鍵をDNS権威サーバで公開しておく（図3－①）。
送信側がメールを送信する際には、メールの本文とヘッダを元に作成した電子署名を付与して送信する（図3－②）。受信側のメールサーバでメールを受信すると、メールヘッダ中の「DKIM-Signature」内の「ｄ=タグ」で指定されたドメイン名のDNS権威サーバに対して公開鍵を問い合わせる（図3－③）。ただし、送信側がｄ=タグで指定するドメイン名はメール送信サーバと同一でなくてもよく、第三者のドメイン名を指定することが可能である。例えば、送信者のドメイン名がexample.comの場合でも、ｄ=タグではexample.net等、任意のドメイン名を指定することができる。次に、受信側は公開鍵を取得すると（図3－④）、その公開鍵を用いて電子署名を照合し、DKIM検証を実施する（図3－⑤）。
３．DMARC
DMARC（Domain-based Message Authentication,Reporting & Conformance）は、2節で解説した2つの送信ドメイン認証（SPF・DKIM）を用いたレポーティングおよびポリシ制御の仕組みで、欧米を中心に近年急速に普及が広がっている技術である。DMARCは、SPFやDKIMのような直接的な認証技術とは異なり、SPFとDKIMを利用して、どちらの検証にも失敗したメールに対して、受信側がどのように取り扱うかの方針を送信ドメイン管理者側が宣言するための機構である。このため、DMARCは受信側におけるなりすましメール受信対策ではなく、送信側のドメイン管理者が自ドメインを詐称したなりすましメールを送信されにくくすることで、自ドメインのブランドを保護するための技術であると言える。
DMARCには、このような送信ドメイン認証失敗時の制御ポリシに従ったメール配送制御の方法を宣言する機能に加えて、レポーティング機能がある。レポーティング機能では、自ドメイン名を名乗って送信されたメールの傾向の集約レポートや送信ドメイン認証の失敗レポートを受信することで、管理者は自ドメイン名の送信ドメイン認証の効果の状況や、自ドメインを騙って送信されたなりすましメールの状況を把握することができる。
DMARCを利用するには、送信側と受信側でそれぞれ次のように対応する必要がある。まず送信側では、SPFおよびDKIMの両方、あるいはいずれか一方に対応する必要がある。これに加えて、送信側では自ドメイン名の先頭に「_dmarc.」を負荷したドメイン名（図6の例では_dmarc.example.com） のTXTレコードとしてDMARCレコードを公開する。DMARCレコード内の「ｐ=タグ」で送信ドメイン認証（SPF・DKIM）に失敗したメールに対する受信側の処理ポリシを宣言することができる。宣言可能な処理ポリシは次の3種類がある。
- none（処理方法を指定しない）
- quarantine（隔離する）
- reject（受信拒否する）
これらの処理ポリシはあくまで送信側が宣言するものであるため、受信側での実際の処理は運用方針によってさまざまである。例えば処理ポリシがquarantineの場合、受信側では迷惑メールボックスに隔離する運用が考えられる。また、処理ポリシがnoneの場合、受信者は通常通りに受信することになるためDMARC導入による受信拒否効果はないが、送信側ではレポーティング機能を活用して集約情報や認証失敗情報を得ることができる。
DMARC検証の流れを図4に示す。
受信側のメールサーバでメールを受信すると、まず送信ドメイン認証（SPF・DKIM）を実施する。これらの送信ドメイン認証の両方に失敗した場合、送信側が公開しているDMARCポリシ（図4ではreject）が適用される。また、送信ドメイン認証に失敗した場合には、失敗レポートが「rufタグ」で指定されたメールアドレス（図4ではrufreport@example.com）に対して送信され、送信ドメイン認証の集約レポートは「ruaタグ」で指定されたメールアドレス（図4ではruareport@example.com）に対して送信される。
また、2節で述べたように、DKIMではメール送信者のドメインとは無関係な第三者ドメインによる署名が可能であるが、その署名ドメインが正当であるかどうかを判断するのは極めて困難であるのが現状である。この問題に対して、DMARCではアラインメントと呼ばれる考え方が存在し、第三者署名を禁止している。すなわち、第三者署名によってDKIMに対応しているドメインの配送では、DKIM検証では認証成功となる場合でも、DMARCでは認証失敗となる。
４．DMARCレコードの詳細
DMARCレコードは、図4のDMARCレコードの記述例に示した通り、各パラメータの間をセミコロンで区切って記述する。図4の例では、バージョン情報（ｖ）、認証失敗時の動作ポリシ（ｐ）、集約レポートの送信先（rua）、失敗レポートの送信先（ruf）のパラメータを記述したDMARCレコードの例を示したが、これ以外にも様々なパラメータが存在し、詳細な設定が可能である。
これらの概要を表1に示す。
adkimおよびaspfパラメータは、いずれもDKIMおよびSPF認証におけるアラインメントモードを示し、relaxed mode（r）かstrict mode（s）のいずれかの値を設定する。relaxed modeは、DKIMまたはSPFで認証したドメインとヘッダFromドメインの組織が同じであれば良いことを意味し、組織ドメイン名が同一であればサブドメインでも許可する設定である。一方、strictmodeでは、完全にドメイン名が一致している必要があることを意味する。すなわち、いずれの場合でもDKIMとは異なり、組織ドメイン名が異なる署名は認められない。
foパラメータは、失敗レポートを送信する条件を詳細に指定するものである。pctパラメータでは、DMARCポリシを適用する割合（％）を指定する。rfパラメータでは失敗レポートのフォーマットを指定するが、現在のところafrf（Authentication Failure Reporting Format）のみが指定可能である。riパラメータでは、集約レポート送信の最大間隔時間（秒）を指定する。spパラメータでは、全てのサブドメインに対するDMARCポリシを指定する。設定可能な値は、ｐパラメータと同様に、none, quarantine, rejectの3種類である。
まとめ
DMARCは従来の送信ドメイン認証とは異なり、送信側のドメイン管理者が受信者に対して受信ポリシを指定できる仕組みである。海外では大手メールサービスを中心に、DMARCポリシを最も強い宣言であるrejectに設定している例が多く見られるが、特に国内ではほとんどのドメインでnoneを設定しており、導入に関して慎重な姿勢が見受けられる。実際に、筆者が行なった調査では、DMARCポリシを公開しているドメインのうち、およそ80%のドメインが処理ポリシをnoneとして公開していることを確認している。これは、DMARCポリシをrejectやquarantineに設定した際に発生する誤判定（False Positive）を防ぐために慎重な設定としていることが多いのが現状であると言えるが、今後の動向の変化にも注目していく必要がある。
また、DMARC導入の重要なメリットとして、DMARCレポートの分析によって、これまで得られなかった自ドメインでの送信ドメイン認証の状況やなりすましの状況の把握ができ、より効果的ななりすまし対策を講じることが可能となることが挙げられる。なりすましメール対策は今後さらに重要視されていくことが予想されることから、DMARCは今後さらに普及していくと考えられる。
【プロフィール】
北川 直哉（きたがわ なおや）氏
東京農工大学 大学院工学研究院 助教。博士（情報工学）。
情報処理学会IOT 研究会藤村記念ベストプラクティス賞（2017/06）、IOTS2016 シスコシステムズ賞（2016/12）、ICT-ISPC2016 Best Paper Award（2016/05）、IOTS2015 優秀論文賞（ 2015/12）等を受賞。
論文に「A Client Based DNSSEC Validation System with Adaptive Alert Mechanism Considering Minimal Client Timeout」（IEICE Transactions ; 2017 年8 月）、「A spoofed E-mail CountermeasureMethod by Scoring the Reliability of DKIM Signature Using Communication Data」（Proc. of IEEE 41st Annual Computer Software and Applications（COMPSAC 2017）; 2017 年7 月）、「Design and Implementation of a DMARC Verification Result Notification System」（Proc. of the 13th APAN esearch Workshop ; 2016 年8 月）など多数。