悪意ある攻撃者が送ってくるなりすましメールや SMSフィッシングなどをいかに防ぎ、受信者が被害に遭わないようにするかという観点からさまざまな技術や対策が検討される。だが、同時に、業務上必要なメールが過検知によってフィルタリングされてしまったり、ユーザーに「怪しいメール」と疑われて破棄されないようにするにはどうしたらよいかという、通信事業者やメール送信事業者側にも切実な悩みがある。
JPAAWG 5th General Meeting（2022 年 11 月）における毎年恒例パネル系 3 つの目玉プログラム、フィッシングハンター 4 名による「フィッシングサイトを落とさナイト」、運用現場関係者による「現場発！メールサービスを支える運用者の集い」、イベント参加者自身が議論する「Open Round Table」をレポートする。
●ユーザー側に「見分けさせない」ために、事業者側が心がけるべきポイントとは？
以前の記事（レポート-1、2、3）でも紹介したとおり、メールサービスを提供する事業者やモバイルキャリア、官公庁など多くの関係者が、さまざまな側面から「フィッシングメール」「なりすましメール」への対策に取り組んでいるが、エンドユーザーにできる対策とは何だろうか。
過去の対策としては主に、「怪しいメールは開かない」、「疑わしいリンクはクリックしない」といった注意が呼びかけられてきた。だが、Twitter上などでフィッシング詐欺に関する情報を発信し、フィッシングサイトのテイクダウンなどに取り組んできた「フィッシングハンター」たちは、それでは被害を避けられないと呼びかけている。
「フィッシングサイトを落とさナイト 2022秋」と題するセッションで、にゃん☆たく氏は、「基本的に、フィッシングメールは『見分けようとしない』のが原則です」と述べた。
理由は 3 つある。まず、いくら URL の文字列を見ても、ほとんど本物と偽物の区別が付けられないことだ。0（ゼロ）と o（オー）、m と rn といった手口はもちろん、他の言語を用いて本物そっくりに表示するケースまである。その上、パソコンではなくスマートフォンを用いている場合、表示エリアが限られて前半部分しか目視できないことは珍しくない。
また、かつては「https から始まるサイトは安全で、http は危険」と言われることもあった。しかし「基本的に今のフィッシングサイトは、9 割以上が HTTPS化されている」とにゃん☆たく氏は述べ、この点だけで見分けようとしないでほしいとした。
トップレベルドメイン（TLD）に基づく判断に頼るのも危険だ。たまに、「.jp は大丈夫」、「.com だから大丈夫」と聞くこともあるが、一概にそうとは言い切れず、フィッシングハンターたちは実際に、.jp のドメインを使ったフィッシングサイトも確認しているという。
こうした状況を説明した上でにゃん☆たく氏は、「見分けてくださいといっても、たとえば自分の母のように詳しい知見を持たない人間には絶対に見分けられません。ですので、『フィッシングサイトを見分けようとするな』と繰り返しお伝えしています」と強調した。
ならば、ユーザーはどうすればいいのだろうか。基本的にはメールに記された URL にアクセスするのではなく、ブックマークや公式アプリからアクセスすべきだという。
それには、注意喚起を呼びかける企業側にも配慮が必要だ。
「多くの企業は『お気に入り』からアクセスしてくださいと注意喚起していますが、では、いったいどの URL をお気に入りに登録すればいいか、利用者にわからないこともあります。つい先日には、検索エンジンでトップに表示されたサイトがフィッシングサイトだった、というケースもありました。こういった手口に引っかからないためにも、『実際に登録すべきURLはどれか』を注意喚起に記載してほしいと思います」（にゃん☆たく氏）
逆に、「URL が正しいかどうか確認してください」と、見分けることをユーザー側に求めるのは厳禁だ。同様にメールアドレスについても、「正しい送信元はこれです」と説明し、見分けることをユーザーに求めるのは意味がないという。JPAAWG General Meeting でもたびたび指摘されているとおり、メールアドレスは容易に偽装できるからだ。
また、注意喚起に記す URL は、閲覧者がうっかりクリックしてジャンプしないよう「無害化」した上で記載することも大事なポイントだとした。「もし面倒な場合は、画像として掲載してもいいでしょう」（にゃん☆たく氏）
セッションでは続けて、au や au pay をかたるフィッシングの増加、国税庁をかたるフィッシング・スミッシングの増加といった 2022 年秋までのトレンドと、その背後にある犯人側の分業化の進展などが解説された。そして、2023 年も残念ながらフィッシング詐欺は減少しないと見込まれるものの、認証手段の強化といった技術的な対策の実施、さらにともに戦うフィッシングハンターを増やしていくといった活動を通して、少しずつでも確実に対策を進めていくべきだといった意見が交わされた。
●なりすまし対策と表裏一体、事業者を悩ませる「偽陽性・誤検知」について真剣に討論
なりすまし対策と常に表裏一体で議論になるのが「いかに偽陽性・誤検知をなくすか」だ。特にメールの場合は、本来送られるべきメールが経路の途中でフィルタリングされたり、ユーザーの手元で迷惑メールと判定されてゴミ箱行きになって読まれないと、思わぬ不利益が生じる恐れもある。
Open Round Table の A会場では、まさにこの「偽陽性」をテーマに、モバイルキャリアや ISP はもちろん、送信側、受信側、そしてセキュリティベンダーなどさまざまな立場の参加者が、「スパムメール判定（偽陽性）されないためには？」について活発に意見を交わした。
不正なメール、なりすましメールが手元に届いてしまい、マルウェアに感染したり、フィッシングサイトに誘導されて ID やパスワード情報を抜き取られるといったリスクは想像しやすい。だからといってフィルタリング設定を厳しくすると、届くべきメールが届かなくなる。
セッションオーナーを務めたエンバーポイントの田澤 響 氏は、「送信側からすると、キャンペーンメールが届かないと売り上げの低下につながると同時に、受信側はそのキャンペーンを利用できず、双方にデメリットが生じるという話がありました。さらに、チケットや防災メールのように緊急性の高いメールが届かなくなってしまうとさらに深刻だという意見も出ました」と議論を振り返った。
防災メールはその性質上、同時に大量のメールを送信することになる。しかし受け取る ISP側からすると、一気に大量のメールが来ると負荷が急増してしまうため、一時的にブロックしてシステムやユーザーを守る必要がある。緊急性が求められる中で、「正規に送られたものか、それとも送信者のシステムが乗っ取られているか」の判定は非常に難しいという。
このラウンドテーブルではさらに、偽陽性が発生する要因についても議論が交わされた。迷惑メールと思われるような大量配信をしてしまう場合はもちろんだが、送信ドメイン認証に対応していなかったり、メール転送によってレピュテーションが下がることも一因ではないかといった意見が出された。そもそも RFC に準拠していない方式で送信する場合も問題だという。
これに関連して興味深い指摘もあった。とある参加者からは、「レピュテーションの観点からは、送信元のドメインだけでなく、メール本文に記されたドメインも重要だ」とコメントがあったという。
たとえば、何かキャンペーンを展開するたびに新たなドメインを作成して使っていると、そのドメインは歴史が浅く信頼性のないものであるためレピュテーションが下がってしまう。その点、歴史のある自社ドメインを使う方がレピュテーションは高い。キャンペーン終了後に乗っ取られないようにするという意味も含め、「メール本文という観点でもドメインを見直し、レピュテーションを上げていく取り組みが必要だという話がありました」（田澤氏）
偽陽性に対し、なかなか「これ」という回答を見出すのは難しいが、まずは、JPAAWG の母体であるグローバル組織 M3AAWG が公開している「ベストセンダープラクティス」や、キャリア、ISP が提供するベストプラクティスを踏まえ、それに準拠した形で送信することが送信側として最低限のマナーと言えそうだ。
さらに、送信速度や IPウォームアップなどによってドメインや IPアドレスの信頼性・レピュテーションを高めた上で大量配信を始める、送信ドメイン認証をはじめとする技術的な対応を実施する、といった工夫が必要だろうといった意見が交わされた。
送信側だけでなく受信者側でも偽陽性は問題だと捉えており、もし間違えてブロックやフィルタリングされてしまった場合には、検体を受け取って確認を行ってくれる事業者もあるという。
ラウンドテーブルは最終的に、今後も偽陽性をなくすためのベストプラクティスを整理し、ポイントを整理していくことが必要だという意見でまとまった。そして「双方が困っているので、お互いに手を差し伸べ合って議論できるところが多々あると思いました」と田澤氏は振り返った。
●自社IPアドレスのブロックリストへの「巻き込まれ」、どう対策する？
フィルタリングやブロックへの「巻き込まれ」「偽陽性」は、カンファレンスの最後に行われた「現場発！メールサービスを支える運用者の集い 2022秋」でも何人かのスピーカーがテーマにしていた。
たとえばフリービットの三浦 敏孝 氏は、サードパーティが提供するブロックリストに自社の IPアドレスが掲載されてしまった場合の対処について発表した。
同社で今回問題となったのは IPv6 の場合だ。老舗のブロックリストである spamhaus では IPv6 のアドレスを /64 単位でブロックしているが、フリービットではアドレスを /127 で細かく切り出して提供している。このため、一部にスパマーがいた場合、一蓮托生でメールサービスが丸ごとブロックされてしまう事態が生じるという。顧客により大きなアドレス空間を割り当てるなどの対処策も検討しているが、「本質的にはモグラ叩き」だともやもやを感じているという三浦氏。たとえば IPv6 に対応したより精度の高いブロックリストを作成し、Dockerファイルで配布すればいいかもしれない、というアイデアはありながらも、悩みは尽きないそうだ。
三浦氏の講演資料「IPv6 BlockList で困った話」
KDDI の昼田 裕 氏も、「スパム送信者と通常のお客様が、同じ送信サーバを使っている場合、IPアドレスがブロックリストに載ってしまうとブロックされてしまう」という同じ悩みを抱いていた。予備の IPアドレスを保有して、ブロックリストに掲載された段階でどんどん切り替えていくという手段も取ったが、なかなかスピード感に追いつけず効果が薄れていたという。
そこで昼田氏が取り組んだのが、メールを送信するタイミングでスパムチェックのエンジンを回す、という手段だ。スパム判定されたものとそうでないものとを別の IPアドレスに振り分け、違う送信元から送信することで、疎通性を確保していった。この結果、通常のメールがブロックリストに登録されるケースはほぼなくなり、疎通不全に関する問い合わせも激減したという。
ただ、この結果、同社からの送信メールの 30 ％がスパムメールであることもわかった。「我々の送信系からもかなりスパムメールが出ていることがわかり、喜んでいいのか、悪いのかという気持ちです」（昼田氏）
NTTドコモで ISPぷららの運用に携わる辻 浩紀 氏も同様の悩みに直面した。自社の IPアドレスがブロックリストに掲載されてしまう事態に悩まされ、日々対応に追われていたが、KDDI の昼田氏と同様に、送信メールに対するレピュテーションチェックを強化し、その結果に基づいて送信IPアドレスを振り分ける対策に取り組んだ。
「お行儀の悪いレピュテーションの悪いキューと、お行儀のいいキューに分けることで、スパマーと正規ユーザーとを分け、多少楽になるかなと思ってやってみました。結果は大成功で、大分楽になりました」（辻氏）。仮にスパムが多いと判定され、ブロックリストに搭載されても影響を受けるのは「お行儀の悪い」ユーザーが使う IPアドレスだけになり、レピュテーションのよい送信アドレスがブロックリストに掲載されるケースは大幅に減った。
さらに、この情報を活用することで、スパムメールの対策を先回りして実施できるようになるという想定外のメリットも生まれ、スクリプト化・自動化もやりやすくなったという。「これを『スパマーホイホイ』と呼んでおり、長年苦労させられてきたスパマーに恨みを晴らせたかなと思っています」（辻氏）
送信レピュテーション強化→MTAの送信IPを出し分け→送信IP毎にQueueサーバーを構築
●「今動いているもの」には手が付けにくい？新たな暗号化プロトコルへの移行を阻む壁
Open Round Table のもう一つの B会場では、「StartTLS や MTA-STS を日本で普及させるためにはどうしたらいいか」というテーマでディスカッションが行われ、セッションオーナーを務めた楽天グループの中里 啓応 氏が概要を紹介した。
エンドツーエンドでの暗号化によってセキュアな通信を実現する STARTTLS や MTA-STS だが、普及はまだまだという状況だ。その理由としていくつかの意見が会場からは挙がったという。
たとえば、10 年以上前の MTA は CPU の性能が低く、TLS処理の負荷が大きかったため導入していないという仮説の他、かつて POP before SMTP が導入されたときとは異なり、皆がそれほど困っておらず、「とりあえず今は普通に動いているから」と、新たな技術を積極的に取り入れるモチベーションが少ないといった意見があった。さらに、証明書の更新などに要するコストや、メールサーバや DNS、Webサーバーなどの設定の手間がハードルになっているという意見もあったという。
うなずかされたのは、インフラであるだけに、今問題なく動いているものに対する移行は一気に進めにくいという指摘だ。「特に大手の事業者ほどさまざまな顧客があり、一気にえい！っと対応を進めると苦情が来てしまうことも想定されるため、フレキシブルに対応を進めることができない、というコメントもありました」（中里氏）
こうした状況を変える手段についても議論があった。1 つは、キャッチーな話題である「PPAP」の廃止に向け、代替策として有効であるといったメリットを訴求することだ。また MTA-STS はなりすまし防止に有効であることを伝えるのも普及の後押しになるのではというコメントがあった。
さらに、Google が公開している透明性レポートのように、目に見えない技術である「暗号化」を可視化し、インターネット全体でどの程度 TLS が浸透しているかを示したり、暗号化されたメールに鍵マークを付けるといった具合にクライアント側でも可視化するなど、目に見えやすくしていくのも一つの策ではないかという意見もあったという。ドメインごとに DNSSEC や SPF、DKIM、DMARC といったセキュリティ対策状況を一目で把握できるサイトがあれば、これを材料にして内部を説得するきっかけになるのでは、という意見も寄せられた。
まとめると、一般に対してはセキュリティや送信ドメイン認証に関する知識の普及啓蒙を進めるとともに、暗号化や対策の状況を可視化する。一方ビジネスサイドでは、これらの技術を学び、どのように活用していくかを自分たちで考えることが重要だ。特にエンジニアサイドは新たなメール技術を積極的に勉強し、メールセキュリティをデフォルトで提供できるソリューションを採用するのも一助になるだろう。さらに、政府・官公庁で採用が進むとともに、何らかのガイドラインが策定されれば普及の後押しになるだろう——という形で議論は進んだ。
ただ、なかなか「現に動いているもの」からの移行は難しいことが、「現場発！メールサービスを支える運用者の集い 2022秋」におけるビッグローブの加藤 理人 氏の発表からも伺える。
同社ではシステムのリニューアルに合わせて STARTTLS を採用し、SSL 3 および TLS 1 のサポートをようやく終えたそうだ。だがそこに「メールが届かない」という複数問い合わせが寄せられた。つまり、いまだに SSL 3 を利用する MTA を使っている顧客がいたということだ。
セキュリティ対策として暗号化をするのはいいが、適切なアルゴリズム、適切なバージョンでなければ意味がない。加藤氏はこうした顧客と何度もやりとりし、「セキュリティ上必要なことである」ことを伝え、ようやく「メールが届かない問題」は解消した。
加藤氏は、「もう使っている人はいないだろう」と決めつけて、えいや！で移行を進めたことには反省すべきところもあるとし、「絶滅危惧種」を見つけることができたのは結果としてプラスになったと振り返った。そして、2022 年度下期内に予定している TLS 1.1 の廃止でこうした「さざなみ」が立たないことを期待していると述べ、セッションを終えた。
JPAAWGでは、「JPAAWG 5th General Meeting」の講演資料を公開しています。
本レポートと併せてご覧ください。
JPAAWG 5th General Meetingについて
・メールに悩む今だからこそ、一堂に会してよりよい対策の議論を
・ガラパゴス的な対策から脱却し、技術的に正しい対策を推進するヒントを得る機会に
