送信ドメイン認証技術「DMARC」によるなりすましメール対策とDMARCレポートの活用

東京農工大学大学院
工学研究院 助教
北川 直哉 氏

 本稿は、2018年12月4日に行われた第49回ICTセミナー(主催:日本データ通信協会)における東京農工大学助教の北川直哉氏の講演内容を事務局においてとりまとめたものである。ネット空間における詐欺が悪質化の一途をたどっており、その端緒となる「なりすましメール」への対応は、すべてのネット利用者にとって重要な課題である。この分野に精通する北川氏に、なりすましメール対策に効果を発揮する認証技術「DMARC」の概要を解きほぐして頂いた。

はじめに

 私は東京農工大学に勤務し、電子メールのセキュリティ、DNSやドメイン名など、大学院の頃からインターネット技術に関する広い分野でセキュリティ技術の研究を行っている。以前は、通信のセッション自体を監視して、攻撃者特有の振る舞いを検出するところにフォーカスを当てていたが、最近は、迷惑メールの特徴が変わり、需要が変わってきたこともあり、データ解析から攻撃の特性を見つけるという方向に少しスイッチしている。
 本日は、「なりすましメール」とはどういうものなのかから始めて、送信認証技術DMARCと、それに付随するSPFやDKIMを解説したい。大学で大規模な通信ログに対して解析を試みた結果についてご紹介をしたい。

「なりすましメール」とは

 「迷惑メール」と「なりすましメール」とでは、そもそも概念が異なる。最近は、スパムや迷惑メールは以前ほど問題視されなくなっている。実際に日本国内の電子メール通信でスパムメール、迷惑メールがどれくらいの割合で存在するかを見ると、5年ほど前には通常のメールに比べて圧倒的にスパムメールの方が多く、ピーク時にはおよそ80%がスパムメールで、スパムではないメールは2割から3割にすぎないという時期が続いた。

 ところが最近は、スパムメールは30%台で、正当なメールの方が数は多い。しかし、一方で被害額は増大する傾向にある。たくさんばらまくのではなく、人がだまされやすいメール、本物と間違って見られやすいメールを送るという傾向が顕著になっている。

 本日テーマにしている「なりすましメール」は、従来の「迷惑メール」とは異なることをまずご理解頂きたい。最近のニュースで「標的型攻撃」という言葉をよく聞くが、公共機関や電力会社、水道局などのインフラ事業者、ネットバンキングやネット証券などを装って送信をされるメールが「なりすましメール」である。標的型攻撃、フィッシングサイトへの誘導、ウイルスへの感染などへの入り口として利用される。

「送信ドメイン認証」とは

 なりすましの方法としては、代表的な考え方として3つの種別がある。最初が、表示名(ディスプレイネーム)を詐称するもの。スマートフォンでメールをチェックされる方だと、そもそもメールアドレスは見ることがない場合が多い。例えば、Gmailを使うと「○×銀行」と実在する銀行名をディスプレイネームとして自由に記述できる。これは誰にでもできる装い方で、検出が難しいものでもないが、アドレスが表示されないようなiPadやスマートフォンの環境に対して正しく送っているので、全てのスパムフィルターを通過してしまう。そのため、防御の可否は受け手のリテラシーだけにかかってくる。シンプルなように見えて、なりすましが成功しやすい方法の一つである。

 二つ目は、もう少し攻撃者にとっては手間がかかるものだ。通常はディスプレイネームと併用して行われるが、例えば、「example.com」という正しいドメイン名がある場合、その「l」を「1」にするなどして、誤認しやすいドメイン名を作る。これをディスプレイネームと併用し、アドレスもしっかりチェックするリテラシーが少し高い人もだますような手段である。
 最近は、国際化ドメイン名(IDN)が採用されるようになり、キリル文字などが扱えるようになったために、人間には容易に識別できないが内部処理的には異なるといった文字列が増えている。これはメールばかりではなく、ウェブの世界でも、かなり大きい脅威になっている。

 三つ目が、本物の送信者のメールアドレスを装って送ってくるケースである。「送信ドメイン認証」は、こうしたケースで、それは偽物の人から送ったであるとか、どこかで改ざんをしたであるとか、通信系路上、あるいは転送先に偽者が挟まっているのを検出するものだ。この技術がないと、本物と全く同じドメイン名から攻撃者が送信可能になってしまう。

 この送信ドメイン認証が、どういう相手に対して有効なのかを、まず整理したい。この時、この技術が、最初の2つのなりすましの手口に対しては万能薬としては働かないことを、まずご承知おきお願いたい。

最も普及している認証技術、「SPF」

 最もシンプルで、かなり普及している認証技術に「SPF(Sender Policy Framework)」がある。これは、あるドメイン名を名乗って送ってくるメールについて、送ってくる可能性のある送信メールサーバーのIPアドレスを指定するという技術である。送信側が受信側のサーバーにメールを送ろうとする際に、すぐにそれを受けとってしまうのではなく、一度その「SPFレコード」の検証を行う。送信側のDNSサーバーに「SPFレコード」を問い合わせ、そのテキストレコードを参照する。図表1の例だと「192.0.2.0/24」である。帰ってきたこのアドレスを見ると、可能性のあるアドレスが「192.0.2.0/24」のアドレスのゾーンに含まれているので検証が成功するという仕組みである。逆に、これに含まれていない場合は、誰かが偽物のメールサーバーから本人を装って送っていると判断して、検証に失敗する(図表1)。

図表1

 同時に 、SPFは正しい配送なのに失敗してしまう場合があるという弱点も持っている。送信が転送された場合である。複数のメールアドレスを使っている方が、どこか1つのメールアドレスに集約させたいために自動転送をかけるという使い方はしばしばなされていると思うが、そのイメージで考えていただくとわかりやすい。中継サーバーが間にはさまって受信側に届く。この場合、最後の受信側でSPF検証を行いSPFレコードを得るわけだが、間に別のサーバーが入っているため、送信サーバーのアドレスゾーンに含まれない。しかも、送信側には、中継サーバーが関わるのは見えないので対処ができず、正しい配送なのに誤検出をしてしまう。

SPFの弱点を克服した「DKIM」

 こうした弱点を克服した別の方式に「DKIM(Domainkeys Identified Mail)」がある。「ディーキム」と読むが、これは電子鍵で署名をし、秘密鍵と公開鍵を使って検証する方式である。あらかじめ、送信側のDNSサーバーに署名に使う公開鍵を公開する。この状態で送信側からメールが送られるが、このときにメールヘッダーに電子署名を付加して送る。電子署名のなかには「DKIM Signature」というヘッダーがあり、そのなかにDKIMの検証用公開鍵の置き場所に関する情報が含まれている。受信側が、それを参照してDNSサーバーに訊きにいくと、再度テキストレコードで公開鍵を送ってくるが、その取得した公開鍵と実際に届いたメールとを比較して、照合で合格すれば検証に合格するという仕組みである(図表2)。

図表2

 これだと、メールヘッダーで公開鍵の置き場所を送信側が指定できるので、転送サーバーが間に入っていたとしても先程のような問題は生じない。しかし、DKIMが万能なのかと言えば、そうとも言えない。

DKIMでも見破れない場合がある

 そもそも DKIMを 導入しなければ、当たり前だが、検証のしようがない。この場合、なりすましの仕方には二つあり、DKIMに対応した高い信頼性の配送をし、しかもDKIMに検査に合格するようなメールを送る場合もあるし、そもそもDKIMに対応していないのだから、DKIMに対応していないようななりすましをして送ればいいという方法も採ることができる。
 実際に観測したある銀行の例では、このDKIMに対応していないドメインに対して、攻撃者がわざと鍵を入れてDKIM検証に合格するようなメールを送っている。

 DKIMが検証をできない二つ目の例として、例えば、私の勤務する東京農工大学は「cc.tuat.ac.jp」というドメイン名を用いているが、大学がマイクロソフトの「Office365」を使っているため、メールは本来のドメインとは関連のないドメインに行っている。先程と反対の話になるのだが、「DKIM Signature」がなければ、そこに検証に来ないという仕組みを使って「DKIM Signature」をつけずに送ってしまい、DKIM検証をさせないというなりすましのしかたがある。

 差出人のアドレスと「DKIM Signature」のドメイン名が異なっているケースは普通に存在しており、私の観測では80%ほどのDKIM対応ドメインが第三者のドメイン名で署名をしている。第三者に署名を依頼し、鍵を自らは管理しないという運用がかなり広がっている。この二者間の関係は本人以外には正解が分からない。三つ目の例として、それを利用し、正しくないドメイン名に誘導をして、そこで検証をかけさせ、成功させようという攻撃のやり方がある。こうしたなりすましができてしまうため、DKIMも全く万能な技術ではない。

発想の転換で登場した「DMARC」

 そこで登場したのが「DMARC」である。DMARCは、SPFとDKIMを合わせて活用する技術で、送信ドメイン認証関連の技術とレポーティングという機能がある。
 なりすましメールの対策は、通常、受信側でどのようにそれらを見つけられるかという考え方をする。DMARCの考え方はそれとは全く逆で、そうしたメールを送られたときに、「捨ててください」であるとか、「隔離してください」などといったことを、“送信側”が指定できる仕組みである。処理の仕方には3種類あり、「何もしない(none)」、「隔離をする(quarantine)」「受信拒否をする(reject)」という対応ができる。受信側では、“送信側”が指定しているポリシーに基づいて取り扱いを決定する。

レポーティング機能は、認証とは直接関係ないサービスだが、SPFとかDKIMではできなかった統計的な分析を可能にする。エラー情報の「ruf」と統計情報の「rua」の2種類のレポート情報がある。
 「ruf」は「failure report」の略で、認証に失敗したメールについて、それを通知する機能である。「rua」は、「aggregate report」の略で、ある程度の期間分をまとめた統計情報である。こういうメールが、これだけSPFに合格してるとか、DKIMに失敗してなどという点に関し詳細な情報レポートが届けられる。

DMARC検証とレポート送信の流れ

 DMARC検証とレポート送信がどういう流れになっているかを説明したい(図表3)。送信側からメールを送信すると、受信側ではSPFとDKIMの送信ドメイン認証を行う。両方に対応する必要はなく、いずれかに対応していればDMARCも導入することができる。両方に対応している場合には、両方にフェイルした場合が「フェイル」という扱いになって、いずれかにパスした場合が「パス」扱いになる。「パス」すれば、そのままユーザーに届き、通常の受信処理が行われる。

 「フェイル」したものに対し、先ほど申しあげた3種類のDMARCポリシーに基づいて「none(処理方法を指定しない)」「quarantine(隔離する)」「reject(拒否する)」のいずれかの取り扱いを決定する。

 レポートは、まず認証結果の統計情報を示した「ruaレポート」がDMARCの機能として送られる。さらに「フェイル」したメールについては、「rufレポート」が「ruaレポート」とは別に配送される。

図表3

 DMARCの重要な機能として、第三者署名の不許可がある。DKIMでは、例えば農工大ドメインとマイクロソフトのドメインには何も関係ない。そしてDKIMでは、それが正しい組み合わせであることを知るすべがないと話したが、その対応がDMARCでとられている。SPFでもDKIMでも、送信元のドメイン名と検証に使うドメイン名は無関係でよく、検証用ドメインが第三者のものでもよい。DMARCではこれを許可しない。例えば、送信元のドメインが「cc.tuat.ac.jp」であれば、全く同じ「cc.tuat.ac.jp」で署名しなければならない。サブドメインは異なるものも認められるが、親ドメインは共通でなくてはならない。第三者署名の偽署名が使えないという点で、かなり強固な送信ドメイン認証になっている。

DMARCレポート(rua)の構造

 DMARCレポート(rua)はメールでXML形式のファイルが送られてくる。大きく分けて4つの部分に分かれている。「レポートのメタデータ(Report generator metadata)」、「DMARC ポリシー(DMARC policy)」、「評価結果(DKIM and SPF results)」、「ドメイン認証結果(All the authentication results)」である(図表4)。


 「レポートのメタデータ」には、例えば組織名やメールアドレス、レポートのID、集約データの期間などを示している。「DMARC policy」は、宣言の内容を表しており、例えば、そのドメイン名は何なのか、3種類のポリシーの何が適用されたのか、DMARCを通した割合であるレート、アラインメントなどを示している。「評価結果」は、おそらく見る項目としては一番重要だが、ドメイン名、IPアドレス、評価の内容、処理の理由などが書いてある。四つ目の「ドメイン認証結果」では、認証結果のもう少し細かい話、認証ドメインや鍵のセレクターなどの情報を得ることができる。


図表4

DMARCレポートから分かること

 DMARCレポート(rua)について、実際にデータを得て統計分析をしてみた。およそ14カ月分を分析している。ここでは、DMARCのポリシーは、受信拒否や隔離をせずに、そのまま受信する「none」を宣言している。概ね右肩上がりに推移しており、2018年10月25日現在で、1日あたり2億メール、1,800万レポートほどもある、かなり大規模な組織の例である(図表5)。

図表5

 この組織にDMARCレポートを送ってきてくれるレポーターの数は、2018年10月末現在で、1日当たり1,143が観測されており、増加傾向が顕著である。レポーターの組織の所属国を見ると、ずばぬけているのが米国で、日本は10番目である。レポート数のランキングを見ると、さらに米国が際立つことになる。総務省が半年に1度ほど公開している情報によれば、JPドメイン名は現在150万程度あり、このうちMXレコードを持っているドメイン、つまりメールサーバーを持っているものは120万少々あるが、これらの中でDMARCレコードを有するドメインは約9,000に過ぎない。MXレコードを持っているドメイン数の1%にも満たない、先進国ではかなり低い水準になっている。

図表6

 DMARCレポートをよく見ると、DMARCの処理に矛盾が生じているようなレポーターがいる。例えば、送信側が宣言しているポリシーと実際にされている処理が異なるケースが見つかる。また、「reject(拒否する)」を宣言しているレポートについて調査してみると、ホワイトリストにそのサーバーが含まれているからであるとか、転送サーバーのリストを自前で用意しているなど様々な理由で、「quarantine(隔離する)」や「reject(拒否する)」と書かれていても、受信側の考えで受信処理をする場合がよく見られる。この反対、つまり「none(処理方法を指定しない)」と書いてあるのに、勝手に「reject(拒否する)」になるとか、「quarantine(隔離する)」と書いてるのに「reject(拒否する)」にされるなどという変更が行われると問題だが、幸いそうした例は1件も観測していない。

 レポートは、自分のドメイン名を詐称したようなメールが、どこにどれだけ送られているのかが容易に分かり、自らのドメイン認証の効き目や、その設定の正確性などを確認できる。また、データ解析をすることによって検出率を上げるなどといった利用の仕方がある。

 私も製作に携わっている「なりすまし対策ポータルサイト」があるので、ご興味のある方は、ぜひこちらも見ていただけたらと思う。

 ■「なりすまし対策ポータル ナリタイ」  (https://www.naritai.jp/index.html)

(文責:「日本データ通信」編集部)