15
フィッシングメールの対策 2020.01.23 Japan Anti-Abuse Working Group (JPAAWG) Internet Initative Japan Inc. (IIJ) 櫻庭 秀次

フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

フィッシングメールの対策

2020.01.23Japan Anti-Abuse Working Group (JPAAWG)

Internet Initative Japan Inc. (IIJ)櫻庭 秀次

Page 2: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

JPAAWG について• Japan Anti-Abuse Working Group

• グローバルなセキュリティ組織 M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) と連携した国内唯⼀の組織

• メッセージングセキュリティを中⼼に関連技術も含めた対策を検討するWorking Group

• 2018.03 の pre-meeting を経て 2019.05 正式発⾜ (現在 12社のメンバ)• General Meeting

• 第1回 JPAAWG General Meeting (IAjapan 第18回迷惑メール対策カンファレンスと併催)• 2018.11.08 @ ⾚坂インターシティ,来場者数 411名

• 第2回 JPAAWG General Meeting (IAjapan 第19回迷惑メール対策カンファレンスと併催)• 2019.11.14-15 (⼆⽇間) @ ベルサール飯⽥橋ファースト, 来場者数 436名

Page 3: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

フィッシング対策の課題• メール送信側

• ISPs 等のメールサーバの悪⽤ (感染元 PC や搾取した認証ID/Password の悪⽤) → 踏み台送信

• 固定 IP やクラウドサービス (ホスト) の悪⽤ → 対応までの時間で⼤量送信

• ⾼速化 (通信環境) し便利 (ホスト利⽤環境) になるインフラの悪⽤• メール受信側

• 巧妙化する送信⼿法,コンテンツ,添付ファイル• 法的な制限 (いわゆる通信の秘密)

• フィルタ等を後から導⼊するのが難しい (同意を後付けでとることの難しさ)• 緊急避難ではなく恒久対策が必要 (正当業務⾏為としての導⼊)

Page 4: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

事業者として考えられる対応メール送信側• 踏み台送信問題対策

• SMTP AUTH により個々の送信者を特定• 報告があればログ等から調査し該当アカウントを利⽤停⽌• 利⽤者のパスワード変更やウイルスチェック等の実施を依頼

• 海外からのメール投稿を原則禁⽌する施策導⼊の検討• 海外からの投稿か可能にするインタフェース (Web) を提供し個別に opt-out• 包括同意により実施するためには,法的整理が必要という認識• 海外からの投稿ができなくなっても国内からに代わるだけという指摘

• まずは送信元が⾝元を明らかにする• 送信するメールの送信ドメインは事業者側のドメインに限定

• これまでの利⽤規約との関係整理,検知や対応の仕組みの導⼊,サポート体制の検討等が必要• 送信ドメイン認証技術 (SPF, DKIM, DMARC) を導⼊

• 不正な送信ドメインの利⽤を禁⽌• 事業者のドメインを利⽤したなりすましメールを抑制する• DMARC および DMARC レポートの利⽤

Page 5: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

事業者として考えられる対応メール受信側• 迷惑メールフィルタの提供

• フィッシングメールが迷惑メールフィルタで検知されることを期待• URL フィルタリングの導⼊

• コンテンツ (本⽂,添付ファイル) 中の URL を精査し判定する URL フィルタリングの導⼊ (URL の形式等も含め)• コンテンツ中の URL ドメインに対する評価の導⼊

• 送信ドメイン認証の導⼊• なりすましメールに対しては送信ドメイン認証で検知

→ No Auth, No Entry• 独⾃ドメイン等による認証が通るメール (なりすまさないメール)

• 認証したドメインに対するドメインレピュテーション (評価) の導⼊• White List としての利⽤が進む可能性あり

• 受信フィルタをより強化,その⼀⽅で必要なメールを受け取るための仕組みとして• 踏み台利⽤された場合は送信側に通知する仕組み (フィードバックループ) を検討

• メールの盗聴対策• 特に BEC (Business Email Compromise) では,送信側あるいは受信側のメールを事前に把握して

いた可能性があると⾔われている• メール作成時 (Web メール等) やメール配送時あるいはメールスプールに対する盗聴対策が必要• メール利⽤者の利⽤環境 (PC等) に不正なものが含まれていないか等 (事業者としては対象外かもしれないが)

Page 6: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

メールの安全性を⾼める技術メール配送の暗号化

• 課題• TLS downgrade 問題• MitM 等による内部情報搾取 → より⾼度なフィッシング (BEC 等) への発展• 証明書の信頼性への不安

• DNS を利⽤した配送の暗号化通信• DANE (DNS-based Authentication of Named Entities, RFC6698) の利⽤

• DNSSEC を利⽤し DNS の信頼性を⾼める• 既存 CA (Certificate Authority) を使わない暗号化通信

• MTA-STS (SMTP MTA Strict Transport Security, RFC8461) の利⽤• 事前に TLS (STARTTLS) の対応状況や TLS 接続ポリシーを受信側が表明• これにより TLS downgrade 問題への対応を期待

• TLSRPT (SMTP TLS Reporting, RFC8460) の利⽤• TLS (DANE 含む) 接続状況に関する情報共有の仕組み ← TLS 版 DMARC レポート

Page 7: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

メールの安全性を⾼める技術利⽤者の利便性向上

• BIMI• Brand Indicators for Message Identification• 送信ドメイン認証 (DMARC) されたメールに対して,Brand Indicators (アイ

コン等) を受信者に提⽰する仕組み• 受信側で認証されたドメインを適切に評価し Brand Indicators を提⽰できれ

ば,メール利⽤者にとって視覚的に安全なメールであることが判断可能• これにより DMARC の導⼊ (より強いポリシーでの) が進むことも期待され

• 類似の仕組み• Yahoo! メールでのブランドアイコンの表⽰• 利⽤する送信ドメイン認証技術は DKIM• 表⽰する送信者 の選択は Yahoo! Japan

参照: https://about.yahoo.co.jp/pr/release/2018/10/30b/

Page 8: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

送信ドメイン認証技術等の導⼊状況• メールサービスからみた調査

• 受信メール対する各認証結果

• JP ドメイン名の調査• JPRS と⽇本データ通信協会との共同研究契約に基づく JP ドメイン名

の調査 (総務省の web site* で定期的に公開)• 独⾃調査のドメイン名(地⽅⾃治体) 調査• SPF, DMARC, MTA-STS の各レコードの設定状況を調査

* https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.html#toukei

Page 9: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

JP ドメイン名の DMARC 普及率2020.01.18

JP ドメイン名全体に対するMX レコードの宣言割合: 81.1%MX設定ドメイン名に対する SPF レコード宣言割合: 63.9%MX設定ドメイン名に対する DMARC レコード宣言割合: 1.06%

登録型 MX (%) SPF (%) DMARC (%)AD 81.9% 70.6% 3.9%AC 94.4% 70.5% 1.5%CO 94.0% 73.3% 0.9%GO 72.2% 93.1% 4.6%OR 93.8% 71.5% 0.6%NE 81.6% 60.3% 1.7%GR 89.3% 61.2% 0.9%ED 93.0% 68.2% 0.9%LG 73.6% 79.8% 0.3%

地域型*1 61.4% 56.5% 0.8%汎⽤ 75.5% 58.8% 1.2%

*1 地域型は新規受付停⽌数値は都道府県型を含む

Page 10: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

2018/3/6

2018/4/6

2018/5/6

2018/6/6

2018/7/6

2018/8/6

2018/9/6

2018/10/6

2018/11/6

2018/12/6

2019/1/6

2019/2/6

2019/3/6

2019/4/6

2019/5/6

2019/6/6

2019/7/6

2019/8/6

2019/9/6

2019/10/6

2019/11/6

2019/12/6

2020/1/6

ad ac co go or ne gr ed lg geo gen average

JP ドメイン名の DMARC 普及率の推移2018.03.06 〜 2020.01.18

Page 11: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

⾃治体の SPF / DMARC 普及率2020.01.19

SPF(%)

DMARC(%)

北海道72.2

(130/180)1.7

(3/180)

東北85.4

(199/233)0.4

(1/233)

関東86.7

(280/323)1.6

(5/323)

中部79.4

(258/325)0.3

(1/325)

SPF(%)

DMARC(%)

近畿88.0

(206/234)0.4

(1/234)

中国79.5

(89/112)0.0

(0/112)

四国82.8

(82/99)1.0

(1/99)

九州沖縄85.5

(241/282)0.4

(1/282)

全国での SPF レコード宣言率: 83.1% (1485 / 1788)全国での DMARC レコード宣言率: 0.7% (13 / 1788)

注: 全ての対象ドメインに MX レコードが設定されていることを確認済み

Page 12: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

メール受信での送信ドメイン認証技術普及率2019.12

pass75.2%

neutral0.5%

softfail7.0%

hardfail2.1%

temperror0.0%permerror

1.3%none13.8%

SPF DKIM

pass41.5%

neutral0.6%fail

1.1%temperror0.0%

none56.9%

Page 13: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

メール受信での DMARC 普及率2019.12

pass18.8% fail

3.6%temperror

0.1%permerror

0.1%

none77.5%

reject7.2% quarantine

7.1%

none85.7%

error0.0%

DMARC Results DMARC Domain Policies

Page 14: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

メール受信での DMARC 普及率推移2016.01〜2019.12

8.6%8.2%8.1%8.3%7.5%8.0%7.5%7.2%7.1%8.2%8.4%8.5%9.8%9.7%9.6%9.3%10.2%9.9%10.4%9.8%9.3%9.4%9.6%11.0%8.7%11.2%12.1%12.2%12.8%13.3%13.0%13.3%14.1%13.4%13.6%13.8%13.6%14.0%15.0%15.2%16.0%

16.5%16.4%18.1%18.5%18.3%18.4%18.8%3.8%4.1%5.6%4.4%5.9%4.5%4.7%4.5%5.3%5.6%3.0%2.8%2.4%2.0%2.4%2.9%2.6%3.3%

3.5%6.0%9.0%5.5%5.0%5.6%7.7%5.2%4.9%7.0%5.2%4.3%3.8%4.0%4.3%5.9%6.3%

7.1%8.8%7.8%7.6%7.7%8.8%11.7%12.0%6.4%7.3%4.0%3.6%3.6%

0.1%0.2%0.0%0.2%0.2%0.1%0.1%0.2%0.2%0.2%0.2%0.2%0.1%0.1%0.1%0.1%0.0%0.1%0.1%0.1%

0.1%0.1%0.0%0.1%0.2%0.2%

0.1%0.1%0.1%0.0%0.1%0.2%0.2%

0.2%0.2%0.1%0.1%0.1%0.1%0.1%

0.1%0.1%0.0%

0.1%0.1%0.1%0.1%0.1%

0.0%0.0%0.2%0.0%0.0%0.0%0.0%0.0%0.0%0.0%0.0%0.0%0.0%0.0%0.0%0.0%0.1%0.0%0.0%0.0%

0.0%0.1%0.1%0.1%0.0%0.1%

0.0%0.1%0.0%0.1%0.0%0.0%0.1%

0.0%0.1%0.0%0.1%0.1%0.1%0.1%

0.1%0.1%0.1%

0.1%0.1%0.1%0.1%0.1%

87.5%87.5%86.0%87.1%86.4%87.3%87.6%88.1%87.4%86.0%88.4%88.6%87.7%88.2%87.9%87.7%87.1%86.7%85.9%84.1%81.5%84.9%85.2%83.3%83.3%83.4%83.0%

80.7%81.8%82.2%83.1%82.5%81.4%80.5%80.0%78.9%77.4%78.0%77.3%76.9%75.1%

71.7%71.5%75.4%74.1%77.5%77.9%77.5%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

2016.01

2016.02

2016.03

2016.04

2016.05

2016.06

2016.07

2016.08

2016.09

2016.10

2016.11

2016.12

2017.01

2017.02

2017.03

2017.04

2017.05

2017.06

2017.07

2017.08

2017.09

2017.10

2017.11

2017.12

2018.01

2018.02

2018.03

2018.04

2018.05

2018.06

2018.07

2018.08

2018.09

2018.10

2018.11

2018.12

2019.01

2019.02

2019.03

2019.04

2019.05

2019.06

2019.07

2019.08

2019.09

2019.10

2019.11

2019.12

pass fail temperror permerror none

Page 15: フィッシングメールの対策 - JANOGフィッシング対策の課題 •メール送信側 •ISPs 等のメールサーバの悪 (感染元PC や搾取した認証 ID/Password

議論のポイント• 技術的な対策や仕組みが⽇本であまり進んでいない

• 送信ドメイン認証技術やそれらの応⽤技術 (ドメインレピュテーション,フィードバックループ等を含む) が欧⽶に⽐べて導⼊が遅れている原因は

• これらの技術が正しく理解され,その効果を⽰すにはどうすれば良いか

• 法的な制限 (通信の秘密) が技術の普及を阻害しているのか

• メール利⽤者を守るために必要なこと• 既に情報漏洩や⾦銭的被害等が発⽣している状況で,メールサービス事業者

はどう対応していくべきか

• 既に利⽤されているメールサービスに対し,新しい技術対策を導⼊する際には個別同意が必要だがそうした状況をどう考えるか

→ あるいはこれまでの法的整理のやり⽅を⾒直すべきか等