迷惑メールの現状とこれまでの対策 第11回 IAjapan 迷惑メール対策カンファレンス

2014.10.08 Shuji SAKURABA

Internet Initiative Japan Inc. (IIJ)

迷惑メールの現状  spam  率の推移  (1)

0.00%  

10.00%  

20.00%  

30.00%  

40.00%  

50.00%  

60.00%  

70.00%  

80.00%  

0  

20,000  

40,000  

60,000  

80,000  

100,000  

120,000  

140,000  

160,000  

180,000  

200,000  

220,000  

01   04   07   10   01   04   07   10   01   04   07   10   01   04   07   10   01   04   07   10   01   04  

legi8mate  mail  

spam  mail  

spam  rate  (right  side  scale)  

(x  10k  messages  /  day)

2013 2012 2011 2010 2009 2014 source:  電気通信事業者13社のデータを総務省がとりまとめ

迷惑メールの現状  spam  率の推移  (2)

20%  

30%  

40%  

50%  

60%  

70%  

80%  

90%  

2008/6/2

2008/6/30

2008/7/28

2008/8/25

2008/9/22

2008/10/20

2008/11/17

2008/12/15

2009/1/12

2009/2/9

2009/3/9

2009/4/6

2009/5/4

2009/6/1

2009/6/29

2009/7/27

2009/8/24

2009/9/21

2009/10/19

2009/11/16

2009/12/14

2010/1/11

2010/2/8

2010/3/8

2010/4/5

2010/5/3

2010/5/31

2010/6/28

2010/7/26

2010/8/23

2010/9/20

2010/10/18

2010/11/15

2010/12/13

2011/1/10

2011/2/7

2011/3/7

2011/4/4

2011/5/2

2011/5/30

2011/6/27

2011/7/25

2011/8/22

2011/9/19

2011/10/17

2011/11/14

2011/12/12

2012/1/9

2012/2/6

2012/3/5

2012/4/2

2012/4/30

2012/5/28

2012/6/25

2012/7/23

2012/8/20

2012/9/17

2012/10/15

2012/11/12

2012/12/10

2013/1/7

2013/2/4

2013/3/4

2013/4/1

2013/4/29

2013/5/27

2013/6/24

2013/7/22

2013/8/19

2013/9/16

2013/10/14

2013/11/11

2013/12/9

2014/1/6

2014/2/3

2014/3/3

2014/3/31

2014/4/28

2014/5/26

2014/6/23

2014/7/21

2014/8/18

2014/9/15

source:  IIJ  IIR  (Internet  Infrastructure  Review)  より

迷惑メールの現状  2014年上半期の被害状況

•  インターネットバンキングに係る不正送金事犯について、平成26年上半期の被害額が昨年の総被害額を上回る  (平成26年9月16日、警察庁広報資料)  –  1,254件,  約18億5,200万円  –  被害が多くの地方銀行や信用金庫、信用組合に拡大す

るとともに、法人名義口座に係る被害が拡大  (都銀その他  14,  地銀  48,  信金信組  11)  

–  コンピュータウイルスの悪質、巧妙化  

被害件数 被害額

平成26年上   1,254件 18億5,200万円

平成25年下 1,098件 11億9,300万円

平成25年上 217件 2億1,300万円

平成24年            64件 4,800万円

平成23年        165件 3億800万円 Source:  hNps://www.npa.go.jp/cyber/pdf/H260904_banking.pdf

迷惑メール対策  送信側の対策

•  ネットワーク的な対策  –  OP25B  (Outbound  Port  25  Blocking)  –  Source  Address  Valida8on  (RFC3704,  BCP84)  

•  Asymmetric  rou8ng  aNack  対策  •  メールサーバによる対策  

–  SMTP-­‐AUTH  (RFC4954)  •  アクセス元地域の限定など  

–  送信数制限  –  SPF  (RFC7208)  –  DKIM  (RFC6376,  STD76)  –  DMARC  (dra`-­‐kucherawy-­‐dmarc-­‐base-­‐04)  –  Contents  Filter  (Outbound  Spam  Filter)  

•  その他  –  Botnet  の  C&C  サーバの  takedown  

迷惑メール対策  Botnet  Takedown

20%  

30%  

40%  

50%  

60%  

70%  

80%  

90%  

2008/6/2

2008/6/30

2008/7/28

2008/8/25

2008/9/22

2008/10/20

2008/11/17

2008/12/15

2009/1/12

2009/2/9

2009/3/9

2009/4/6

2009/5/4

2009/6/1

2009/6/29

2009/7/27

2009/8/24

2009/9/21

2009/10/19

2009/11/16

2009/12/14

2010/1/11

2010/2/8

2010/3/8

2010/4/5

2010/5/3

2010/5/31

2010/6/28

2010/7/26

2010/8/23

2010/9/20

2010/10/18

2010/11/15

2010/12/13

2011/1/10

2011/2/7

2011/3/7

2011/4/4

2011/5/2

2011/5/30

2011/6/27

2011/7/25

2011/8/22

2011/9/19

2011/10/17

2011/11/14

2011/12/12

2012/1/9

2012/2/6

2012/3/5

2012/4/2

2012/4/30

2012/5/28

2012/6/25

2012/7/23

2012/8/20

2012/9/17

2012/10/15

2012/11/12

2012/12/10

2013/1/7

2013/2/4

2013/3/4

2013/4/1

2013/4/29

2013/5/27

2013/6/24

2013/7/22

2013/8/19

2013/9/16

2013/10/14

2013/11/11

2013/12/9

2014/1/6

2014/2/3

2014/3/3

2014/3/31

2014/4/28

2014/5/26

2014/6/23

2014/7/21

2014/8/18

2014/9/15

source:  IIJ  IIR  (Internet  Infrastructure  Review)  より

McColo  Shutdown

Waledac

Rustock

Rove  Digital

迷惑メール対策  受信側の対策

•  ネットワーク的な対策  –  DNSBL  (DNS  Black  List,  IP  address  base)  –  GrayLis8ng  (送信元による一時的な接続拒否)  

•  メールサーバによる対策  –  Contents  Filter  (Signature,  Sandbox,  Heuris8c  Engine,  etc)  

•  An8-­‐Virus  •  An8-­‐Spam  

–  同一送信元からの大量受信制限  (throNling)  –  SPF  (RFC7208)  –  DKIM  (RFC6376,  STD76)  –  DMARC  (dra`-­‐kucherawy-­‐dmarc-­‐base-­‐04)  

ネットワーク的対策

•  DNSBL  (DNS  Black  List)  –  仕組み:  接続元の  IP  アドレスを  DNS  の  query  や  hNp  を利用して Black  List  管理元に問い合

わせて受け取りを判断する  –  長所:  メールを受信する前に判断できるので処理負担は小さい  –  短所1:  Black  List  に登録されただけでメールが届かなくなる  /  受け取れなくなる、解除される

まで継続する  –  短所2:  リスト解除のポリシーが曖昧なものもある  

•  Gray  Lis8ng  –  仕組み:  接続元の善し悪しが判断つかない場合に  temporary  fail  (4xx)  を返答し正常な  MTA  

であれば行われる再配送を期待する方法  –  長所:  拒否するわけではないのでメールが失われることが  (基本的には)  ない  –  短所1:  配送遅延が発生する  –  短所2:  送信  MTA  が  fallback  した場合など  IP  アドレスが変わった場合に再度  temporary  fail  

する可能性がある  (配送遅延が拡大)  •  Source  Address  Valida8on  

–  DNS  や  NTP,  SNMP  など  UDP  通信を悪用した DDoS  攻撃の対策  –  メールに於いても、asymmetric  rou8ng  aNack  (動的  IP  を  source  IP  として固定 IP  網から送信

し、動的  IP  アドレス側で受信を行う)  対策として有効  

Outbound  Port  25  Blocking  (OP25B)

•  導入目的  –  動的  IP  アドレスからの  port  25  へのアクセスを禁止  –  利用者の区別がしづらい個人向け接続サービスを利用した  spam  送信対策  (検知され遮断

されるまで  spam  を大量送信)  –  Malware  等に感染させられた  PC  (Bot)  からの  spam  送信対策  

•  導入手順  –  MSA  での  port  587  での投稿できるよう準備  (SMTP-­‐AUTH  も導入)  –  顧客提供用  IP  アドレスの整理  (動的  IP  と固定  IP  を分離しやすいよう整理)  –  顧客および他 ISP  等への事前周知  –  適切なポイントでの  Router  への  ACL  (Access  Control  List)  を設定  –  サポート窓口での適切な顧客対応の準備  

Outbound  Port  25  Blocking  (効果)

1  

13  

25  

37  

49  

0  

10  

20  

30  

40  

50  

60  

70  

80  

90  

100  

OP25B   Spam  Rank  

JEAG  published  

Recommenda;on

Number  of  ISPs Japan  Spam  Ranking

Spam  Rank:  Based  on  Sophos’s  Dirty  Dozen  report  MIC:  Ministry  of  Internal  Affairs  and  Communica8on  JEAG:  Japan  Email  An8-­‐Abuse  Group  

MIC  clarified  the  legality  of  OP25B

Target  date  of  OP25B  deployment  in  the  JEAG  

Recommenda;on

Outbound  Port  25  Blocking  (現在の状況)

1  

11  

21  

31  

41  

51  

61  0  

20  

40  

60  

80  

100  

120  

140  

160  2005Q1  

2005Q2  

2005Q3  

2005Q4  

2006Q1  

2006Q2  

2006Q3  

2006Q4  

2007Q1  

2007Q2  

2007Q3  

2007Q4  

2008Q1  

2008Q2  

2008Q3  

2008Q4  

2009Q1  

2009Q2  

2009Q3  

2009Q4  

2010Q1  

2010Q2  

2010Q3  

2010Q4  

2011Q1  

2011Q2  

2011Q3  

2011Q4  

2012Q1  

2012Q2  

2012Q3  

2012Q4  

2013Q1  

2013Q2  

2013Q3  

2013Q4  

2014Q1  

OP25B   Spam  Rank  

MSA  での対策  送信者認証

•  SMTP-­‐AUTH  (RFC4954)  –  メール送信時に  ID/password  による認証を行う  

•  SASL  (Simple  Authen8ca8on  and  Security  Layer,  RFC4422)  フレームワークを利用した認証メカニズム  

•  PLAIN,  LOGIN  など暗号化されない認証では  TLS  (or  over  SSL)  を併用すること  

–  認証した  ID  毎に単位時間あたりの通数制限をかける  •  例:  1,000通/日および一時的な大量送信時には送信効率を下げる制

御の実施  (hNps://www.iij4u.or.jp/guide/mail_control/)  •  メルマガなど大量送信を行う場合は専用サービスの利用を推奨  

–  何かあった場合に送信  (認証)  元を判断するために有効  •  その他注意  

–  古い認証の仕組みである  POP  before  SMTP  は送信者の特定困難さ  (通数制限の適用等)  や  NAT  環境下での利用に適していない等のため廃止することが望ましい  

送信ドメイン認証技術  (1)

•  基本的な仕組み  –  送り手は送信元を明確に表明  (ごまかしがきかない情報を利

用)  –  受け手は送信元情報が正しく表明されているか確認  (認証)  –  DNS  を利用することにより外部の認証機関が不要  

送信用サーバ  （SMTP）

DNSサーバ

送信者

メール送信側 送信元ドメインのSPFレコード

を確認（SPF）

メール受信側

受信メールのDNSサーバから公開鍵情

報取得（DKIM）

メールヘッダ・本文を署名し、DKIM-­‐Signatureを付与（DKIM）

SPF:  Sender  Policy  Framework  (RFC7208)  DKIM:  DomainKeys  Iden8fied  Mail  (RFC6376,  STD76)

送信ドメイン認証技術  (2)

•  期待される効果  –  受け取るべき送信者からのメールかを識別  –  巧妙化する不正行為を事前に見破る  

•  有名サイトを騙ったフィッシング  →  偽のサイトへ誘導し  ID  やパスワードを搾取  

•  信頼性が高そうな送信者を騙った不正プログラムの実行  (添付ファイルや不正サイトへの誘導)  →  botnet  の拡散、malware  の混入  

•  情報搾取を目的とした標的型攻撃  →  内部情報の外部への漏洩等  •  etc…  

–  迷惑メールを判定するのではなく送信者情報を認証する技術          

 →  メールに関連する種々の問題を解決するための基盤技術  

SPF  の動向  (1)

•  SPF  の導入状況  –  総務省のとりまとめ  (電気通信事業者7者の協力)  –  94.31%  認証可能メールの割合 (2014.06)  –  86.32%  認証結果が  “pass”  の割合  (2014.06)  

•  全体の迷惑メール割合と比べても高い  (認証可能メールの  91.53%  が  “pass”)  

0%  

10%  

20%  

30%  

40%  

50%  

60%  

70%  

80%  

90%  

100%  

Jul-­‐1

1  

Aug-­‐11  

Sep-­‐11  

Oct-­‐11  

Nov-­‐11  

Dec-­‐11

 

Jan-­‐12  

Feb-­‐12  

Mar-­‐12  

Apr-­‐12  

May-­‐12  

Jun-­‐12  

Jul-­‐1

2  

Aug-­‐12  

Sep-­‐12  

Oct-­‐12  

Nov-­‐12  

Dec-­‐12

 

Jan-­‐13  

Feb-­‐13  

Mar-­‐13  

Apr-­‐13  

May-­‐13  

Jun-­‐13  

Jul-­‐1

3  

Aug-­‐13  

Sep-­‐13  

Oct-­‐13  

Nov-­‐13  

Dec-­‐13

 

Jan-­‐14  

Feb-­‐14  

Mar-­‐14  

Apr-­‐14  

May-­‐14  

Jun-­‐14  

pass  hardfail  so`fail  neutral  permerror  temperror  none  

Source:  MIC  survey    (cooperate  with  7  ISPs)

SPF  の動向  (2)

•  SPF  認証結果割合の推移  –  期間:  2009.08〜2014.03  –  74.59%  認証可能メールの割合  (2014.03)  

0%  

10%  

20%  

30%  

40%  

50%  

60%  

70%  

80%  

90%  

100%  

temperror  

permerror  

neutral  

so`fail  

hardfail  

pass  

none  

Source:  IIJ  IIR  (Internet  Infrastructure  Review)

DKIM  の動向  (1)

•  DKIM  の導入状況  –  総務省のとりまとめ (電気通信事業社4社の協力)  –  39.84%  認証可能メールの割合 (2014.06)  –  36.73%  認証結果が  “pass”  の割合 (2014.06)  

•  92.19%  (認証可能メールの  “pass”  の割合)

0%  

10%  

20%  

30%  

40%  

50%  

60%  

70%  

80%  

90%  

100%  

Jul-­‐1

1  

Aug-­‐11  

Sep-­‐11  

Oct-­‐11  

Nov-­‐11  

Dec-­‐11

 

Jan-­‐12  

Feb-­‐12  

Mar-­‐12  

Apr-­‐12  

May-­‐12  

Jun-­‐12  

Jul-­‐1

2  

Aug-­‐12  

Sep-­‐12  

Oct-­‐12  

Nov-­‐12  

Dec-­‐12

 

Jan-­‐13  

Feb-­‐13  

Mar-­‐13  

Apr-­‐13  

May-­‐13  

Jun-­‐13  

Jul-­‐1

3  

Aug-­‐13  

Sep-­‐13  

Oct-­‐13  

Nov-­‐13  

Dec-­‐13

 

Jan-­‐14  

Feb-­‐14  

Mar-­‐14  

Apr-­‐14  

May-­‐14  

Jun-­‐14  

pass  fail  neutral  permerror  temperror  none  

Source:  MIC  survey    (cooperate  with  4  ISPs)

DKIM  の動向  (2)

•  DKIM  認証結果割合の推移  –  期間:  2009.08〜2014.03  –  11.72%  認証可能メールの割合  (2014.03)  

50  

55  

60  

65  

70  

75  

80  

85  

90  

95  

100  

2009.08.01  

2009.10.01  

2009.12.01  

2010.02.01  

2010.04.01  

2010.06.01  

2010.08.01  

2010.10.01  

2010.12.01  

2011.02.01  

2011.04.01  

2011.06.01  

2011.08.01  

2011.10.01  

2011.12.01  

2012.02.01  

2012.04.01  

2012.06.01  

2012.08.01  

2012.10.01  

2012.12.01  

2013.02.01  

2013.04.01  

2013.06.01  

2013.08.01  

2013.10.01  

2013.12.01  

2014.02.01  

temperror  

neutral  

fail  

pass  

none  

Source:  IIJ  IIR  (Internet  Infrastructure  Review)

DMARC  Domain-­‐based  Message  Authen8ca8on,  Repor8ng  &  

Conformance •  目的  

–  ドメイン詐称を防ぐために既にある個別の仕組みをオープン化  –  認証識別子の標準的な利用方法の確立  –  認証の運用上の各種問題解決に役立てる  –  SPF  &  DKIM  のより広い導入の動機付け  –  より積極的な認証方針  (policy)  への奨励  

•  特徴  –  複数の認証技術  (SPF,  DKIM)  を利用  –  信頼関係を築きより強い方針  (policy)  を導入できるように受信

側から送信側へフィードバックを行う  –  認証の対象は、メールヘッダ上  (From:  ヘッダ)  のドメイン  

DMARC  (2)

•  動機と経緯  –  eBay,  PayPal  と Yahoo!,  Google  (Gmail)  が  DKIM  を利用した

フィッシング対策を開始  •  eBayとPayPal,  フィッシング対策でGmailと協力  (2008.07.09,  日経BP  ITpro  News)  

–  初期のテスト結果は比較的良好  •  しかしながら認証が失敗するケースも多少あった  •  単一の認証技術だけでなく複数の認証技術を利用すことに  •  認証失敗の原因を究明できるよう  Feedback  が行えるような仕組みも

必要  –  さらに他の送受信事業者を含めてより広いグループに拡張  –  グループで初期ドラフトを作成し、2011年の  MAAWG  で提示、2012.01.30  DMARC.org  として発足  (dmarc-­‐discuss  ML)  

–  2012.11  85th  IETF  @  Atlanta  で dmarc  WG  を提案、その後  IETF  へ  (dmarc-­‐iet  ML)  

DMARC  (3)

•  送信側としての準備  –  DKIM  と  SPF  の導入  (and/or)  –  利用する識別子の整理  (Iden8fier  Alignment)  –  フィードバック受信の準備  (メールアドレスの用意)  –  DMARC  policy  (DMARC  record)  の宣言  

•  対象となるドメインの “_dmarc”  サブドメインの  TXT  RR  •  最初は  “p=none”  から  

–  送信ドメイン認証の結果確認と調整  (feedback  を利用)  –  DMARC  policy  の調整  (“pct=”  と  “p=“  による段階的な強化)  

•  次の段階として  “p=quaran8ne”  と  “pct=小さい値”    •  さらに次の段階として  “pct=100”  に  •  さらに  “p=reject”  と  “pct=小さい値”  •  段階的に  p  と pct  を引き上げて行く  

_dmarc.example.jp  TXT  "v=DMARC1;  p=none;  rua=mailto:dmarc-­‐feedback@example.jp"

DMARC  (4)

•  受信側の導入  –  ヘッダ From  (RFC5322.From)  からドメインを取り出す  

•  取り出すドメインは一つだけ  –  DMARC  policy  レコードを取り出す  

•  DMARC  TXT  レコードが存在しない場合  Organiza8onal  Domain  に問い合わせを行う  

–  DKIM  署名の検証と  SPF  認証を行う  •  認証が成功  (pass)  したドメインを利用する  

–  認証された識別子  (ドメイン)  と  Iden8fier  Alignment  をチェック  –  DMARC  方針  (policy)  を適用して処理する  –  DMARC  Feedback  

•  “rua=”:  集約レポート  (aggregate  reports),  XML  形式  •  “ruf=”:  失敗レポート  (failure  reports,  forensic  reports),  ARF  を利用  

送信ドメイン認証技術の利用

•  Sender  Authen8ca8on  &  DMARC  –  認証結果  none  のメールを柔軟に対応  (移行期)  –  正当なメールの送信元がほとんど対応していることを前提に  pass  以外は詐称と判断して

reject  (最終形)  •  Domain  Reputa8on  

–  認証された送信者情報  (詐称されていない)  を評価して受け取るべきメールだけを受け取る (Domain  White  List  の利用)  

•  Spam  Filter  –  ドメインレピュテーションで判定ができなかった送信元のメールを内容などを基に  spam  判定  

→  結果はレピュテーションへ  feedback

課題

•  メール配送形態による認証の失敗  (indirect  mail  flows)  –  メール転送による  SPF  の認証失敗  

•  転送元での  RFC5321.From  の書き換え  →  転送先で  SPF  は  pass  →  DMARC  では  RFC5322.From  と不一致  (fail)  

•  DKIM  の導入  or  転送先でのホワイトリスト  (転送者≒転送受信者なので)  で対応  

–  メーリングリスト機能  •  Mailman  などでは  RFC5321.From  はメーリングリスト管理アドレス  →  SPF  は  pass  →  DMARC  では  RFC5322.From  と不一致  (fail)  

•  Subject:  ヘッダの書き換え  (ex.  “[dmarc-­‐iet]”  の付与等)  →  DKIM  の認証失敗  →  コンテンツの改変を止める  

•  Mailman  の次バージョンでは  From:  ヘッダを書き換える機能が追加されるとの情報もあり  

•  日本におけるDKIMの普及  

普及に向けて

•  向かうべき方向性  –  SPF,  DKIM  双方の良いところをうまく活用  – メールの責任の所在を明確に  

 →  RFC5322.From  (ヘッダ  From)  を基軸に  – 認証がうまくいかないケースが見つけ出せる仕組み  (repor8ng)  &  対策の検討  →  feedback  の仕組みへと  

– 認証したドメインを評価するための仕組みとそれを利用した受信対策  →  Domain  Reputa8on  

↓  DMARC  

(Domain-­‐based  Message  Authen8ca8on,  Repor8ng  &  Conformance)

普及に向けて

RFC5322.From  (ヘッダFrom)

RFC5322.From  (ヘッダFrom) わかりやすさが重要