View
6
Download
0
Category
Preview:
Citation preview
迷惑メールの現状とこれまでの対策 第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) わかりやすさが重要
Recommended