弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコムがエンジニア・デザイナーのサービス開発事例やデザイン活動を発信する公式ブログです。

メール送信ドメイン認証を回避する、ドメイン名に見えるもの

セキュリティ

楽天証券のユーザーを狙ったフィッシングメールが話題になっています。楽天証券の公式 X アカウントから注意喚起が行われているほか、NHK ニュースでも報道されました。

【⚠️重要】楽天証券を装う不審な電子メールにご注意ください

楽天証券 偽メールで個人情報抜き取り被害相次ぐ 注意呼びかけ www3.nhk.or.jp

この注意喚起を見ると、興味深い点があります。送信元のメールアドレスとして、「自治体名を含む」ドメインが利用されているというのです。実際に、sendonly@shiga.jp というメールアドレスが使われているほか、kagoshima.jp などを含むメールアドレスが利用されていると報告されています。

この記事では、この shiga.jp や kagoshima.jp の正体と、メール送信ドメイン認証との兼ね合いについて述べます。

shiga.jp とは何なのか

この送信元には sendonly@shiga.jp というメールアドレスが使われているといいます。これを見たとき、以下のようなことを思われた方も多いのではないかと思います。

  • shiga.jp はJPドメインだろう
  • 攻撃者がこのドメインを持っているわけではなく、勝手に使われただけだろう
  • おそらく滋賀県（地方公共団体としての滋賀県、滋賀県庁）が持っているドメインだろう

実際にはどうでしょうか。JPRSのWhoisサービスで調べると、以下のような情報が得られます。

Domain Information: [ドメイン情報]
a. [ドメイン名]                 SHIGA.JP
f. [組織名]                    滋賀ドメイン
g. [Organization]             Shiga Domain
p. [ネームサーバ]               a.dns.jp
p. [ネームサーバ]               b.dns.jp
p. [ネームサーバ]               c.dns.jp
p. [ネームサーバ]               d.dns.jp
p. [ネームサーバ]               e.dns.jp
p. [ネームサーバ]               f.dns.jp
p. [ネームサーバ]               g.dns.jp
p. [ネームサーバ]               h.dns.jp
[状態]                         Reserved
[最終更新]                     2005/03/30 17:37:52 (JST)

組織名の箇所には「滋賀ドメイン」とありますが、これは滋賀県がこのドメインを持っているという意味ではありません。実際に滋賀県が持っている pref.shiga.lg.jp では、以下のようになります。

Domain Information: [ドメイン情報]
a. [ドメイン名]                 PREF.SHIGA.LG.JP
e. [そしきめい]                 しがけん
f. [組織名]                     滋賀県
g. [Organization]               SHIGA prefecture
k. [組織種別]                   地方公共団体
l. [Organization Type]          Local Government
m. [登録担当者]                 PC1000032JP
n. [技術連絡担当者]             PC1000031JP
p. [ネームサーバ]               ns1.shigasc.jp
p. [ネームサーバ]               ns2.shigasc.jp
[状態]                          Registered (2025/11/30)
[登録年月日]                    2002/11/06
[最終更新]                      2024/12/01 00:10:01 (JST)

ここではきちんと「滋賀県」と表記されており、滋賀県がこのドメインを持っていることがわかります。

では、先ほど出てきた「滋賀ドメイン」とは何でしょうか。答えを言ってしまうと、これは都道府県型JPドメイン名のドメイン名空間です。JPRSの「都道府県型JPドメイン名について」では、以下のように説明されています。

2.都道府県型JPドメイン名とは

都道府県型JPドメイン名は、「○○○.hokkaido.jp」、「○○○.tokyo.jp」、「○○○.nagasaki.jp」のように、その構造に全国47都道府県の名称を含むドメイン名空間です。 原則としてサービス内容、各種規則は「汎用JPドメイン名」に準じます。

shiga.jp も都道府県型JPドメイン名の空間のひとつであり、実際のドメインは「○○○.shiga.jp」のような形になります。「○○○」の部分は好きな文字で取得できますが、「○○○」部分のない shiga.jp 単独ではドメイン名として取得できません。これはあくまで、ドメイン名の空間なのです1。

xxx@shiga.jpというメールアドレスは、いうならば、「○○○.co.jp」の「co.jp」部分だけをドメイン名として使おうとしているようなものであり、xxx@co.jp というメールアドレスを使っているようなものなのです。

なぜ都道府県型JPドメイン名の空間が使われたのか

では、なぜ攻撃者はこのようなメールアドレスを使ったのでしょうか。実際のところは攻撃者に直接聞いてみないとわかりませんが、いくつか推測できることはあります。

本物のドメインを騙れない理由

楽天証券を攻撃するのであれば、楽天証券のメールアドレスを騙るのが最も有効なはずです。楽天証券から送信されるメールのアドレスは公開されており、メール送信者情報についてというページで見ることができます。これによると、どのメールでも、送信元のメールアドレスには rakuten-sec.co.jp というドメインが使われているようです。となると、そのドメインを利用したメールアドレスを騙ればよさそうに思えます。

しかし、それではうまくいきません。なぜなら、楽天証券はメール送信ドメイン認証に対応しているからです。まず、rakuten-sec.co.jp では SPF の設定が行われており、以下のような TXT レコードがあります。

rakuten-sec.co.jp.    3600    IN  TXT "spf2.0/mfrom ip4:124.215.210.0/25 ip4:125.29.56.75/32 ip4:202.144.241.0/24 ip4:202.131.202.80/29 ~all"

DMARC の設定もあり、しっかりと p=reject が設定されています。

_dmarc.rakuten-sec.co.jp. 3600   IN  TXT "v=DMARC1; p=reject; rua=mailto:dmarc-report-a@rx.rakuten.co.jp"

送信メールアドレスに rakuten-sec.co.jp ドメインが設定されたメールを受信すると、受信側のシステムはこれらの設定を参照し、SPF や DMARC のチェックを行います。攻撃者のメールはこのチェックをパスできないため、DMARC の設定に従って受信拒否されてしまいます (なお、DMARCについては過去にDMARC をなめるなという記事を書いていますので、よろしければそちらもご覧ください)。

つまり、本物のドメインである rakuten-sec.co.jp を騙って偽メールを送っても、メール送信ドメイン認証の仕組みによって受信拒否されてしまうのです。このため、攻撃者は本物のドメインを採用することができません。

無関係なドメインを利用するケース

このようにメール送信ドメイン認証が利用されており、DMARC が厳しく設定されている場合、攻撃者は本物とは無関係なドメインを利用することになります。紛らわしいドメインを自ら取得して利用するケースや、他人が持っているドメインを勝手に騙るようなケースもあります。

ただしこの場合、攻撃者にはリスクがあります。

ドメインを自ら取得した場合、単純にブロックするだけで対策されてしまいます。攻撃者が不正な目的で取得したドメインからは、受信できないと困るようなメールは送られてきません。受信側はそのドメインを、サブドメインごとすべてブロックしてしまえば問題ないわけです。

他人のドメインを騙る場合、受信側の対応は少し複雑になります。単純にそのドメインをブロックすると、正規のドメイン所有者からのメールもブロックすることになるためです。この場合、正規のドメイン所有者には対応の手段があります。メール送信ドメイン認証を導入し、厳しい設定を行えば良いのです2。正規のドメイン所有者がそのような対応をすれば、攻撃者のメールは届かなくなってしまいます。

取得されていないドメインとして都合の良いドメイン名空間

そこで攻撃者が取り得るもう一つの選択肢が、取得されていないドメインを利用するということです。取得されていないドメインには、通常、メール送信ドメイン認証は設定されていません。そのため、メールはそのまま届く可能性が高くなります。

ただし、単に全く存在しないドメインを利用しても、受信側は単純にブロックするだけで対応できてしまいます。そこで攻撃者が利用したのが、shiga.jp のようなドメイン名空間だと考えられます。これは実際のドメインではないため、メール送信ドメイン認証が設定されていることはまずありません。 誰かに取得され、あとから設定が行われることもほぼありません3。そして、単純に丸ごとブロックすることも難しくなっています。shiga.jp を丸ごとブロックすると、正規に利用されているかもしれない xxx@○○○.shiga.jp からのメールもブロックしてしまうおそれがあるためです。

利用するドメイン名空間によっては、そのドメインが実際には存在しないことが丸わかりになることもあります。たとえば、xxx@co.jp のようなメールアドレスを利用しても、そのようなドメインがないことはすぐにわかるでしょうし、異常であることは判断しやすいでしょう。その点、shiga.jp はいかにも実在しそうなドメインであり、受信者を騙しやすくなります。

このような理由から、shiga.jp のような都道府県型JPドメイン名の空間は、攻撃者にとって都合が良かったのではないかと考えています。

対策

それでは、都道府県型JPドメイン名の空間を利用される攻撃に対して、考えられる対策はあるでしょうか。

受信側の対策

受信側でもっともわかりやすいのは、ドメイン名であるのか、ドメイン名空間であるのかを受信側で見分けて対処するという方法です。○○○.shiga.jpは存在する可能性がありますが、shiga.jpは存在しないわけですから、そこを見分けて対処すれば良いのです。

つまり、47都道府県名のローマ字表記がついた.jpドメインに気をつければ良い……と言いたいところですが、実はこれだけではありません。都道府県型JPドメイン名は日本語ドメインにも対応しており、○○○.滋賀.jpも登録できるのです。これで倍になります。

そして残念なお知らせですが、実はもっと深刻な状況があります。

過去に登録されていた「地域型JPドメイン名」というものが存在するのです。たとえば、otsu.shiga.jpはドメイン名空間であり、○○○.otsu.shiga.jpというドメイン名が登録されている可能性があります。現在では地域型JPドメイン名は新規登録できなくなっていますが、過去に登録されたドメインが使われているケースもあり得るため、無視できません。

このようなケースも見ていくと、キリがありません。

Public Suffix List で対応できるか?

実は、都道府県型JPドメイン名や地域型JPドメイン名の空間は リスト化されています。 そのリストは Public Suffix List と呼ばれており、https://publicsuffix.org/ から見ることができます。GitHub にもデータがあり、こちらのほうが見やすいかもしれません。このリストの 1933 行目から 3731 行目までが .jp ドメインに関するものとなっています。コメントも含まれていますが、控えめに見積もっても優に 1000 件を超える項目が存在することになります4。

このリストと照らし合わせることで、都道府県型JPドメイン名や地域型JPドメイン名の空間については見分けることが可能になります。

ただし、このリストを利用して一律にメールをフィルタする、という方策を単純に採用することはできません。Public Suffix List は主に Web での Cookie の制御に使われることを想定したもので、ドメインとして使われないことが保証されているわけではないためです。Public Suffix List には github.io、appspot.com、herokuapp.com、azurewebsites.net といったプライベートエントリも含まれており、中には単独で機能するものもあります。

たとえば、github.io には Aレコードが設定されています。

github.io.       935 IN  A   185.199.111.153
github.io.      935 IN  A   185.199.108.153
github.io.      935 IN  A   185.199.109.153
github.io.      935 IN  A   185.199.110.153

ですので、github.io ドメインに対してメールを送信することは、形式上は可能です (実際にはおそらくSMTP系のポートは開いていないでしょうけれども) 5。Public Suffix List にあるからメール送受信には使われない、とは一概に言い切れないのです。

送信側の対策

メール送信側としては、自分と無関係なドメインやドメイン名空間を悪用された場合、技術的には手出しができません。ユーザーへの告知をすることが主な対策になるでしょう。普段から使うメールアドレスのドメインを統一しておくと、ユーザーはメールを見分けやすくなります。この点、楽天証券はよくできていると思います。

技術面では、引き続きメール送信ドメイン認証を設定することが重要になります。楽天証券のケースでは設定しているのに攻撃されているわけですが、この設定があることによって、本物のメールアドレスが騙られることは防げています。これによって、攻撃側がやりにくくなっていることは間違いありません。

まとめ

ここまで述べてきたことを簡単にまとめます。

  • フィッシングメールの送信元に ○○○@shiga.jp が利用されるケースが報道されている
    • shiga.jp は一見すると汎用JPドメインのように見えるが、実際には都道府県型JPドメイン名の空間である
    • ドメイン名の空間にはメール送信ドメイン認証が設定されていないので、攻撃者には利点がある
  • 都道府県型JPドメイン名、地域型JPドメイン名は 1000 件以上存在するが、Public Suffix List を利用すれば識別可能
    • ただし Public Suffix List を使ってメールをブロックすることは適切ではない
  • ともあれメール送信ドメイン認証を設定することは重要である

今回の記事を書くために楽天証券のメールドメイン認証の設定を調べたのですが、当然というべきか、問題なく設定されていました。メール送信元のドメインを統一し、明示するなど、フィッシングへの対策にかなり気を遣っている様子も伺えました。また冒頭で紹介した通り、利用者に対する注意喚起も行っています。

しかし攻撃者も諦めておらず、対策を迂回して受信者を騙してやろうという強い意思 が感じられます。フィッシングは古くからある攻撃で、防ぐためのさまざまな技術も生まれてきましたが、それでも限界があります。電子メールを利用する文化が続く限り、攻撃のトレンドに応じた注意喚起をし続けなければならないのだろうと思います。

  1. 技術文書では eTLD (effective top-level domain) という言い方をすることもあります。↩
  2. もっとも、メール送信ドメイン認証を厳しく設定した場合、正規のメールが届かなくなるリスクもあります。特に、受信側がメールを転送していたりメーリングリストを利用している場合、受信側システムが ARC に対応していないと、認証に失敗してしまうことがあります。↩
  3. _dmarc.shiga.jp というドメインを取得して無理やり DMARC を設定するようなことはできません。ドメイン名ラベルに _ を含むドメインは登録できないためです。逆に、実際のドメインとの重複を避けるために、DMARC レコードの先頭に _ がついているともいえます。↩
  4. かつて高木浩光さんが「都道府県型JPドメイン名新設に係る公開質問」という文書を公開し、「Public Suffix Listをどのように修正すれば新設される都道府県型JPドメイン名に対応できるのか」と述べていましたが、その答えがこれです。↩
  5. MX レコードはありませんが、MX がなくても A があれば A に対してメールを送る挙動になります。歴史的に、インターネットの最初期 (1986年以前) にはMX レコード自体がまだ存在しておらず、単純にホスト名を解決した先にメールを送っていました。その動作との互換性のために、MX がないときは A に送るというフォールバックがあります。↩

© Bengo4.com, Inc. 2005