Internet Infrastructure Review（IIR）Vol.63
2024年6月

1. 定期観測レポート

日々高度化するサイバー攻撃からお客様を保護するための取り組み

1.1 電子メールが新たな時代へ

前回の報告^（注1）から1年、2023年は電子メール関連業界が大きく動いた年となりました。

本稿の前半では、IIJが観測している最新の攻撃手法について報告し、新しく取り組み始めた対策内容を紹介します。後半では、この1年間で観測している送信ドメイン認証技術DMARC対応率の劇的変化について報告します。

電子メールは組織内外のコミュニケーション手段として重要なインフラでありながら、一度構築するとなかなか変更されないものです。しかし、世の中の攻撃手法やセキュリティ動向は絶えず変化しており、常に対策を講じ続けていく必要があります。この機会に電子メールインフラを見直してはいかがでしょうか。

1.2 お客様を脅威から保護する取り組み

1.2.1 abuse対応とは

メールサービスを悪用され、フィッシング（詐欺）メールを送信されるケースが後を絶ちません。

多くのISP（インターネットサービスプロバイダ）やホスティングメールサービスでは、電子メールを送信するとき、メールアカウントのユーザIDとパスワードの組み合わせ（クレデンシャル）を用いてSMTP認証し、認証に成功した場合のみ電子メールを送信できるのが一般的です。これは認証することで利用者を識別することと、第三者によるメールサービスの不正利用から守ることが目的です。

しかし、悪意のある者によって利用者のクレデンシャルが何らかの方法で盗まれ、メールサービスを用いてフィッシングメールの送信に利用される（アカウントの乗っ取り）行為が日常的に発生しています^（注2）。これはIIJに限らず、他ISPや他社サービスでも発生しており、このようなインターネット上での迷惑行為や不正行為をまとめて、一般的に「abuse（アビューズ）行為」と呼びます。

1.2.2 abuse行為が行われると

悪意のある者によってメールサービスがフィッシングメールの送信に不正利用されると、どのようなことが起こるでしょうか。

近年は、単に迷惑な広告メールを送信するのではなく、攻撃対象となる宛先のユーザが利用しているWebサービス・アプリなどのIDやパスワードを盗み出す手段としてフィッシングメールを送信しています。彼らの最終目的はフィッシングメールで騙したユーザからIDやパスワードを盗み出し、銀行口座やクレジットカード番号を盗むことで、金銭的な利益を得ることです。近年はクラウドサービスの利用も進み、この動きがますます加速しています。

当然ながら、このようなフィッシングメールを送信する行為は多くのメールサービスの利用規約や約款で禁止されています。彼らは規約違反としてメールの送信が制限される前の、極めて短時間のうちに大量のフィッシングメールを送信することで、攻撃の成功率を上げようとしているのです。まさに「数打てば当たる」状況となっています。

1.2.3 abuse行為の問題点

このような状況を放置すると、攻撃対象となったユーザへの被害のみならず、メールサービスでも次のような悪影響が発生します。

• 悪意のある者によって、メールサービスから大量にフィッシングメールが送信されることで設備が過負荷になり、サービス障害の発生や、可用性の低下につながる（図-1（1）、（2））。
• フィッシングメールを送信されてしまった結果、宛先メールサーバやセキュリティベンダーなどで、メールサービスがフィッシングメールの送信元として登録され、他の正当な利用者のメールが宛先で迷惑メール判定され、受信拒否などされる（図-1（3）、（4））。
• あるセキュリティベンダーが、別のセキュリティベンダーの脅威情報を参照していることがあり、一度登録された脅威情報の解除までには時間が掛かるため、この影響が長引く（図-1（5）、（6）、（7））。

拡大する

図-1 abuse行為が与えるメールサービスへの悪影響

従って、IIJのメールサービス「IIJセキュアMXサービス」では、サービスの安定稼働や、他のお客様への悪影響回避のため、abuse行為が発生した場合は即座に調査し、メールサービス利用者のクレデンシャルを強制変更したり、該当の通信を遮断したりするなど、日夜設備の保護に努めています。

1.2.4 abuseと通信の秘密

日本では、電気通信事業者が取り扱う電気通信について知得などの行為をすることは、電気通信事業法第4条によって禁止されています^{（注3）（注4）}。しかし、abuse行為の発生が明示的に認知されており、これを放置するとサービス利用者が他人の権利を侵害する不法行為に加担してしまったり、自身が被害に遭ったりする強い蓋然性がいぜんせいがある場合に、それらの事態を回避するために電気通信に関与することは、緊急避難や正当業務行為として違法性が阻却され得ると整理されています。

また、IIJと利用者間の契約において、abuse行為に相当する行為は禁止されており、契約違反が明らかであるときは、IIJとしても契約当事者としての諸措置をもって対処することができます。

1.2.5 不正利用の準備行為の発見

ここ数年、前触れもなくフィッシングメールを送るのではなく、フィッシングメールが送られる数日前に数通、無害と思われるメールを送信する「お試し送信」を日々の運用業務の中で複数回発見しています。例えば、メールの件名に次のような情報が記載されています。

拡大する

このようなメールの宛先には、探索行為の結果を収集していると考えられるメールアドレスが記載されており、数日すると実際にフィッシングメールの送信が行われるという因果関係が明らかになってきました（図-2）。

拡大する

図-2 特定期間中の探索行為から、
実際にabuse行為が行われるまでの日数

しかし、このような準備段階の時点では他人の権利を侵害している、または権利侵害の強い蓋然性がいぜんせいがあるとは言い難く、必ずしもabuse行為とは言えません。そのため、このような準備段階を察知しつつも、実際にabuse行為が行われるまで、私たちは具体的な対処を行う根拠がない状況でした。サービスの品質を維持し、お客様を保護するための設備を運用する立場としては、とても歯がゆい状況です。

1.2.6 IIJの新しい取り組み

このままではお客様を保護できず、指をくわえて見ていることしかできません。そこで新しい枠組みを整備する必要があると考えました。IIJのサポート部門、法務部門を巻き込み、こうした不正利用のための準備行為を察知した場合、実際にフィッシングメールが送信される前に、必要な範囲で通信を制限する枠組みの設計に取り掛かりました。

フィッシングメールが送信される前に対策できれば、表-1のようなメリットがあります。

拡大する

表-1 対策によるメリット

関係者と議論を重ねた結果、次の手順をもって契約上の行為として導入することとなりました。

• すべてのお客様に対して、事前に新たに取り組む内容を具体的に説明する。
• IIJセキュアMXサービスの約款にも具体的な規定を設ける変更を行うことで、お客様に十分に認知していただく。

既存のお客様については運用管理担当者様宛へお知らせがメールで送付されていますのでご確認ください。該当の約款は2024年5月1日の改訂で盛り込まれています。IIJセキュアMXサービス個別規程第12条（不正利用などのおそれへの対処）をご参照ください。

ちなみに、実際に行われた迷惑行為の事後対処を「abuse対応」と呼ぶのに対して、不正利用の準備行為を事前に察知してお客様を保護するこの取り組みについて、社内では「ディフェンス対応」と名付けました。

1.2.7 IIJのディフェンス対応

従来は日々の運用業務の中で発見していた探索行為ですが、人力での実施には限界があります。そこで大規模なログの分析基盤として社内でも活用している「illumino^（注5）」を用いて、不正利用の準備行為と思われる事象を、機械学習を用いて検出しています（図-3）^（注6）。

拡大する

図-3 ディフェンス対応用Splunkダッシュボード

実は最初からディフェンス対応のためにSplunkを活用していたのではなく、もともとはabuse対応を効率化するための調査用として利用を検討していました。ところが調査を進めていく段階で、こうした不正利用の準備行為を発見し、この検出にも機械学習が適用できるのではないかと考え精度を高めていった結果、かなり高い確率でこの準備行為を発見することに成功しました。

1.2.8 まとめ

他人の通信を媒介している電気通信事業者は、当該の法令によって事業遂行を厳しく規律されていることは、一般消費者にはあまり知られていません。しかし、インターネットは世界中と繋がっています。私たちが悪意のある者からお客様を保護するとき、その行為は常に「通信の秘密」の保護とも隣合わせであり、双方のバランスについて留意しながら日々業務にあたっています。

IIJでは、日々高度化するサイバー攻撃から、お客様を保護するための取り組みを続けてまいります。

1.3 送信ドメイン認証に対する大きな動き

1.3.1 金融業界でのDMARC対応要請とその動向

2023年2月、総務省・警察庁・経済産業省から、クレジットカード会社など金融機関に対して、なりすましメール対策としてDMARCポリシーの導入の要請がありました^（注7）。

従前より、各クレジットカード会社などに対してはなりすましメールによる被害が増加しており、対策の必要性が叫ばれていましたが、この要請を機に、本格的な対策が始まったようです。図-5の金融業界ドメインのDMARC対応率の増加を見てもその様子が良く分かります^（注8）。

DMARCポリシーを記載しているドメインは、2023年1月には20％程度しかありませんでしたが、1年後の2024年1月頃には、全体の80%まで増加する結果となりました。ただ、DMARCポリシーを導入したが、いまだにp=noneのままであるドメインも多く存在します。DMARCの効果を正しく得るためには、p=quarantine、p=rejectに変更が必要です。金融業界では2023年にこのような大きな動きがありましたが、日本のドメイン全体に目を向けると、まだまだ対応していない企業が多くある様子が窺えます（図-4）^（注9）。

拡大する

図-4 日本の金融機関ドメインのDMARC対応の様子

金融業界に続いて、その他の業界でもDMARC対応が進むよう、今後も動向に注目していきたいと思います。

1.3.2 GoogleとYahoo!（米国）の送信ドメイン認証非対応メール受信拒否ポリシー声明発表

2023年10月、GoogleとYahoo!（米国）が2024年2月より、送信ドメイン認証に対応していないメールは受信拒否する、という発表をしました。GoogleとYahoo!の両社は、日頃からかなりの量のspamやbulk mailに悩まされており、それらを受信拒否するために送信ドメイン認証していないメールを一律拒否することにしたということです。

送信ドメイン認証技術は、2006年にSPFがRFC 4408、2007年にDKIMがRFC 4871、2014年にDMARCがRFC 7208としてそれぞれ公開されています。DMARCは2014年の公開から、9年経過した2023年でもなかなか普及しない状況が続いていました（図-5）^{（注10）（注11）}。

拡大する

図-5 日本のドメインのDMARCの様子

そのような状況下での、最大級のメール受信量を誇る世界最大手のGoogleとYahoo!の受信拒否ポリシー適用声明は、日本に限らず世界中に衝撃を与えました。メールの到達率が重要なサービス指標となるメール送信事業者は早急なDMARCへの対応を求められる形となりました。

発表の直後、2023年10月に開催されたグローバルな迷惑メール対策団体「M³AAWG」の会議では、GoogleとYahoo!の担当者を招いて本アナウンスに対する質問会が緊急開催されました。各国から参加しているメール送信事業者を中心に、どの程度のコミットメントが求められるのか、本当に対応しないとメールを受信してもらえないのかなど、白熱した質問会となりました。

その後、2023年11月に開催された、日本でインターネットのセキュリティについて議論するワーキンググループ「JPAAWG」の会議では、日本国内でメール事業を展開している各事業者を中心に本件に関する議論もなされました。メール送信事業者に限らず、ドメインオーナーである各企業やメールボックス事業者ももちろん対応が必要であり、IIJでも法人、個人それぞれに展開している各サービスで対応を進めていました。

IIJの法人向けサービスでは既に各送信ドメイン認証（SPF、DKIM、DMARC）に対応する仕組みを準備していましたが、各機能の利用は利用者であるお客様による設定の変更や準備が必要であったため、お客様からの送信ドメイン認証に関する問い合わせの量は2023年末から激増する形となっていました。

こうして各事業者や各企業、組織が対応した結果、IIJセキュアMXで受信しているメールの各送信ドメイン認証の対応率が激変しました（図-6）。

拡大する

図-6 セキュアMXにおける受信メールに対する送信ドメイン認証対応割合（2023年・2024年比較）

DKIM署名の割合が15%強増加し、DMARCレコードを記載した送信元ドメインの割合（DMARCパイチャートにおけるnone以外の割合）が42%から75%に30%以上増加しました。2022年には32%であったことを振り返ると、2023年はやはり、前述した事項を理由として、DMARCレコード対応をした事業者や企業が増えたと考えられます。

ただ、これらはあくまでも"DMARCレコードが存在していること"までしか確認しておらず、DMARCポリシーがp=none、quarantine、rejectのいずれかまでは見ていません。Googleは、今後も各ドメインオーナーには、DMARC集計レポートを確認しながらp=noneからquarantine、rejectに変更していく対応が求められると考えられます。

1.3.3 送信ドメイン認証技術が抱える問題点

近年、クラウドサービスの利活用が進み、企業がオンプレミス設備から直接インターネットへメールを送信すること自体が減少傾向にあります。そのような状況から一部では、SPFレコードの評価のみではそのメールの信頼性を担保するには値しないのではないか、という議論が出始めています。

また、複数のクラウドサービスからメールを送信するために、SPFレコードのDNSルックアップの上限である10回を超えてしまい、SPFレコード自体がerrorとなるドメインも、一部で確認されています。

これを回避するために、一部の事業者ではCNAMEレコードを用いてincludeされているレコードを1レコードに展開するようなサービスを提供している状況です。本来SPFレコードのincludeに制限がある理由は、includeが多いSPFレコードがDNS lookup amplifierとなり得る可能性を鑑みて制限されているものです^（注12）。

クラウドサービスの中には、膨大な数のIPアドレスレンジが設定されているSPFレコードが指定されているものもあり、そのようなクラウドサービスから自身のドメイン名を用いたメールを送信する際は、DKIM署名を実施することで、SPFによる規格の制限を回避し、送信ドメイン認証のDKIMでpassさせることができます。

一方で、DKIMも万能ではなく、DKIM replay attackの対策や、DKIM署名鍵の有効期限を適切に管理することが必要です^（注13）。

DMARCについても、転送メールやメーリングリストなど、DKIM署名後にヘッダ情報が書き換わってしまう従来からあるメールの仕組みが原因で、DKIM署名の検証に失敗する事象への対応が各事業者間で根深く残っています。

このDKIMの検証に失敗する状況を回避するためにヘッダ情報などが書き換わったあとで再署名するARCという仕組みがありますが、DKIM同様、どの署名ドメインを信頼するべきかは、受信側の判断に委ねられています。

送信ドメイン認証に関する課題はまだ多くありますが、IIJとして情報収集や発信ならびにIETF規格策定への参加等、尽力していく所存です^（注14）。今回、GoogleとYahoo!（米国）の発表を発端としたSPF、DKIM、DMARCへ対応するというのはあくまでもスタートであり、それぞれ継続的な対応が求められるということに気をつけなければなりません。

1. （注1）IIR Vol.59（https://www.iij.ad.jp/dev/report/iir/059.html）。
2. （注2）ひと昔前はクレデンシャルの総当たり攻撃によってパスワードを発見されるケースもありましたが、この行為自体がabuse行為であり効率の悪い手法です。昨今は事前の認証試行をされることなく、1回目からフィッシングメールの送信に成功しているケースがほとんどですので、悪意のある者が何らかの方法で事前にクレデンシャルを入手していると考えるのが自然です。
3. （注3）この「通信の秘密」の概念は、もともと郵便物（信書）の通信を指すものでした。いつ、誰が、どの相手と、どのような内容のやりとりをしているかといった情報を第三者に知られない権利です。日本国内ではインターネットにおいても適用されますが、そのように整理される国は世界でも少数派で、諸外国では検閲が合法な国が圧倒的多数とされています。「ネットを監視も干渉もしない国は、日本を含むたった4カ国だけ」（谷脇康彦著「教養としてのインターネット論」（日経BP, 2023年））。米国NPO調査（https://freedomhouse.org/sites/default/files/2022-10/FOTN2022Digital.pdf）。
4. （注4）郵便局員がはがきの表面を見て宛先のポストに投函することと同様に、インターネットではIPパケットのヘッダ、電子メールではSMTPプロトコルの通信内容を見なければ、相手に届けることができません。そのため、このような行為は「通信の秘密を侵害するが、正当業務行為である」と整理されます。
5. （注5）社内情報分析基盤「illumino」：Internet Infrastructure Review Vol.57（https://www.iij.ad.jp/dev/report/iir/057/03.html）。
6. （注6）Splunkの活用事例 本レポートのVol.48（https://www.iij.ad.jp/dev/report/iir/048/03.html）「フォーカス・リサーチ（2）Splunkによる⽇本語⽂章解析処理」。
7. （注7）総務省、「クレジットカード会社等に対するフィッシング対策強化の要請」（https://www.soumu.go.jp/menu_news/s-news/01kiban18_01000184.html）。
8. （注8）日本の金融機関のドメイン名 - DMARC（https://stats.dnsops.jp/chart/jp-bank/dmarc）。
9. （注9）日本のDNSSEC/SPF/DMARC 対応状況 - DMARC（https://stats.dnsops.jp/chart/all/dmarc）。
10. （注10）日本のDNSSEC/SPF/DMARC 対応状況 - DKIM（https://stats.dnsops.jp/chart/all/dkim）。
11. （注11）日本のDNSSEC/SPF/DMARC 対応状況 - DMARC（https://stats.dnsops.jp/chart/all/dmarc）。
12. （注12）Datatracker IETF、11. Security Considerations, 11.1. Processing Limits（https://datatracker.ietf.org/doc/html/rfc7208#section-11.1）。
13. （注13）IETF、DKIM Replay Problem Statement（https://www.ietf.org/archive/id/draft-ietf-dkim-replay-problem-00.html）。
14. （注14）Datatracker IETF、The Authenticated Received Chain (ARC) Protocol（https://datatracker.ietf.org/doc/html/rfc8617）。

1. 定期観測レポート 日々高度化するサイバー攻撃からお客様を保護するための取り組み

• 1.1 電子メールが新たな時代へ
• 1.2 お客様を脅威から保護する取り組み
• 1.3 送信ドメイン認証に対する大きな動き