220,000 200,000 180,000 160,000 140,000 120,000 100,000 80,000 (x 10k messages / day) 迷惑メールの現状 spam 率の推移 (1) 80.00% 70.00% 60.00% 50.00% 40.00% 30.00% 60,000 40,000 20,000 legi8mate mail spam mail spam rate (right side scale) 0 01 04 07 10 01 04 07 10 01 04 07 10 01 04 07 10 01 04 07 10 01 04 2009 2010 2011 2012 2013 2014 20.00% 10.00% 0.00% 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 年上 平成 25 年下 1,254 件 18 億 5,200 万円 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 ( 効果 ) Number of ISPs 100 90 OP25B Spam Rank Japan Spam Ranking 1 80 70 Target date of OP25B deployment in the JEAG Recommenda;on 13 60 50 MIC clarified the legality of OP25B 25 40 30 JEAG published Recommenda;on 37 20 10 49 0 Spam Rank: Based on Sophos s Dirty Dozen report MIC: Ministry of Internal Affairs and Communica8on JEAG: Japan Email An8- Abuse Group
Outbound Port 25 Blocking ( 現在の状況 ) 160 1 140 11 120 100 21 80 31 60 41 40 20 51 0 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 61 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 を利用することにより外部の認証機関が不要 メール送信側 送信元ドメインの SPF レコードを確認 (SPF) 受信メールの DNS サーバから公開鍵情報取得 (DKIM) DNS サーバ メールヘッダ 本文を署名し DKIM- Signature を付与 (DKIM) 送信者 送信用サーバ (SMTP) メール受信側 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 ) 100% 90% 80% 70% 60% 50% 40% pass hardfail so`fail neutral permerror temperror none 30% 20% 10% 0% Jul- 11 Aug- 11 Sep- 11 Oct- 11 Nov- 11 Dec- 11 Jan- 12 Feb- 12 Mar- 12 Apr- 12 May- 12 Jun- 12 Jul- 12 Aug- 12 Sep- 12 Oct- 12 Nov- 12 Dec- 12 Jan- 13 Feb- 13 Mar- 13 Apr- 13 May- 13 Jun- 13 Jul- 13 Aug- 13 Sep- 13 Oct- 13 Nov- 13 Dec- 13 Jan- 14 Feb- 14 Mar- 14 Apr- 14 May- 14 Jun- 14 Source: MIC survey (cooperate with 7 ISPs)
SPF の動向 (2) SPF 認証結果割合の推移 期間 : 2009.08 2014.03 74.59% 認証可能メールの割合 (2014.03) 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% temperror permerror neutral so`fail hardfail pass none 0% Source: IIJ IIR (Internet Infrastructure Review)
DKIM の動向 (1) DKIM の導入状況 総務省のとりまとめ ( 電気通信事業社 4 社の協力 ) 39.84% 認証可能メールの割合 (2014.06) 36.73% 認証結果が pass の割合 (2014.06) 92.19% ( 認証可能メールの pass の割合 ) 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% pass fail neutral permerror temperror none 0% Jul- 11 Aug- 11 Sep- 11 Oct- 11 Nov- 11 Dec- 11 Jan- 12 Feb- 12 Mar- 12 Apr- 12 May- 12 Jun- 12 Jul- 12 Aug- 12 Sep- 12 Oct- 12 Nov- 12 Dec- 12 Jan- 13 Feb- 13 Mar- 13 Apr- 13 May- 13 Jun- 13 Jul- 13 Aug- 13 Sep- 13 Oct- 13 Nov- 13 Dec- 13 Jan- 14 Feb- 14 Mar- 14 Apr- 14 May- 14 Jun- 14 Source: MIC survey (cooperate with 4 ISPs)
DKIM の動向 (2) DKIM 認証結果割合の推移 期間 : 2009.08 2014.03 11.72% 認証可能メールの割合 (2014.03) 100 95 90 85 80 75 70 65 60 temperror neutral fail pass none 55 50 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 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 85 th 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 から _dmarc.example.jp TXT "v=dmarc1; p=none; rua=mailto:dmarc- feedback@example.jp" 送信ドメイン認証の結果確認と調整 (feedback を利用 ) DMARC policy の調整 ( pct= と p= による段階的な強化 ) 次の段階として p=quaran8ne と pct= 小さい値 さらに次の段階として pct=100 に さらに p=reject と pct= 小さい値 段階的に p と pct を引き上げて行く
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)