ICSS 2010-07	

電子メールにおける送信元認証技術	  の正しい利用と誤用の分析

ICSS	  2010年7月研究会	  NTTサービスインテグレーション基盤研究所	  森 達哉	  2010.7.1	

1

	  ある企業メールサーバの統計
受信メッセージ: 約1800万通/1ヶ月の内訳	
4%	  スパム	  ハム	 96%	  10TB	  のストレージ	 	  9.6TB	  が無駄!	  	 ICSS 2010-07	 2010.7.1	

2	

ある企業メールサーバの統計
メール送信ホスト: 約200万ホストの内訳	
1%	  スパマー	 

通常	 99%	   すべてのホストをフィルタ	 	  99%正解!!	 
ICSS 2010-07	 2010.7.1	

3	

大多数のスパムは送信元を詐称
 ドメインを詐称	   「良い」ドメイン発のメールに見せかける	   ホワイトリストにひっかける	   送信先のドメインを詐称	   ユーザアカウントを詐称	   送り先のドメイン上の適当なアカウント	   スパム送信先リストからランダムに抽出	  

ICSS 2010-07	 2010.7.1	

4	電子メール送信元認証技術• 送信元認証技術	  • 1997年~	  proposed	  by	  Paul	  Vixel	  • 2006年頃より本格的な普及開始 	  • いずれも	  DNS	  をインタフェースとして使う	  • 送信元ドメインを使う為	  • 	  代表的な電子メール送信元認証技術	  • SPF	  (Sender	  Policy	  Framework),	  Sender	  ID	  • DKIM	  (DomainKeys	  Identiﬁed	  Mail),	  DomainKeys	  ICSS 2010-07	 2010.7.1	

5	他の	  anti-­‐spam	  技術との関係

受信サーバ	 

受信前フィルタリング	  ドメイン認証	  IP	  reputa/on	  Greylis/ng	  Greet	  pause	  …	  フィルタリング
サーバ	 

受信後フィルタリング	  （コンテンツフィルタリング）	  pop	  server	 

パターンマッチング	  テクストマイニング	  画像処理	  (OCR)	  メディア処理	  一般にコストが高い処理を伴う	
ICSS 2010-07	 2010.7.1	

6	

SPF	  のメカニズム
DNS	 

txt docomo.ne.jp?	
sender	 v=spf1 +ip4:203.138.203.0/24 ~all	
MTA	  	 IP: 203.138.203.4
From: xxxxxx@docomo.ne.jp	

pass	

ICSS 2010-07	 2010.7.1	

7	

SPF	  のメカニズムDNS	 

v=spf1 +ip4:203.138.203.0/24 ~all	

txt docomo.ne.jp?	
sender	 

MTA	  	 IP: 129.60.5.14
From: yyyyyy@docomo.ne.jp	

SOFT FAIL	

ICSS 2010-07	 2010.7.1	

8	

ドメイン管理者が設定するポリシー	  (qualifiers) +:	  PASS	   ?:	  NEUTRAL	  (no	  policy).	  
 ~:	  SOFTFAIL	  (typically	  accepted	  but	  tagged)	   -­‐:	  FAIL	  (should	  be	  rejected)	   例:	  	  	  	  	  	  	  ibm.com	  	 v=spf1	  –all	  	  	  	  	  	  すべてのあらゆる送信元を	  REJECT	  してもOK	   xxxx@ibm.com	  はすべて	  invalid	  なアドレス	   xxxx@us.ibm.com	  などは	  valid	 
ICSS 2010-07	 2010.7.1	

9	

SPFの特徴 完全な分散アーキテクチャ	   CA	  やThird	  Trusted	  Party	  は存在しない	   Spammer	  も	  SPF	  を使うことが可能	   ポリシーの柔軟性・自由度の高さ	   ポリシーは	  sender	  (domain)	  が決める．	  

ただし	  receiver	  は設定されたポリシーをどのように解釈するかという受信側の立場としてのポリシーを決める必要がある	   受信者として妥当なポリシーを定めるには，他の送信元がどのようなことをしているかを把握することが必要不可欠	 
ICSS 2010-07	 2010.7.1	

10	

本研究の狙いと課題
 送信者（ドメイン管理者）あるいは受信者の立場でSPFを正しく運用するために必要な統計を得る．Best	  current	  practice	   SPFの普及と利用状況の理解（サンプル）	   SPFの正しい利用と誤用の把握	   SPFの問題点に関する定量的理解	  ICSS 2010-07	 2010.7.1	

11	

分析に用いるデータ
 ドメインリスト	   良性ドメイン・悪性ドメイン	   既存DB	  (Alexa	  top500,	  DBL)，マニュアル収集	   電子メール配送ログ	   SPF	  認証結果とメッセージスコアの相関（スパム	  or	  ハム）	   IPレピュテーションリスト	   良性IPアドレスリスト・悪性IPアドレスリスト	   DNSBL	  (spamhaus),	  DNSWL	 ICSS 2010-07	 2010.7.1	

12	

Alexa	  Top	  500	  sites	  (良性ドメイン)

ICSS 2010-07	 2010.7.1	

13	

SPAMHAUS	  DBL	  (悪性ドメイン)

ICSS 2010-07	 2010.7.1	

14	

Alexa	  Top	  500	  sites	  に対する
SPF普及率の分析

ICSS 2010-07	 2010.7.1	

15	

.jp	  における	  SPF	  普及率の分析

ICSS 2010-07	 2010.7.1	

16	

分析項目
 グローバルな視点	   SPFの詳細な普及状況	   良性、悪性別のカウント,	  sender	  ID,	  IPv6,	  parser	   SPFで登録されている	  preﬁx	  長	  
 /8	  以下の大きなアドレス空間を登録しているのは怪しいケースが多い→定量的に分析	   ローカルな受信側の視点	   SPFで認証されたメッセージの統計	   SPFで認証された送信者の統計	  ICSS 2010-07	 2010.7.1	

17	

SPF	  の普及状況
良性ドメイン 約50% の普及

悪性ドメイン 約30% の普及	ICSS 2010-07	 2010.7.1	

18	

SPFに登録された	  prefix	  長分布

良性ドメイン	

悪性ドメイン	ICSS 2010-07	 2010.7.1	

19	

SPFに登録された	  prefix	  長分布 Spammer	  は	  /0	  を使う	   任意のIPアドレスから送ってもOK	   dynamic	  IP	  を持つボットから送信できる	   SPF	  認証チェックは通過	   Spammer	  は	  /32	  も使う	   専用ホスティングサーバ	   良いIPと悪いIPを混ぜる	   Google	  の	  IP	  を数個混ぜるパターンなどもあり	 
ICSS 2010-07	 2010.7.1	

20	

SPF認証と実際に配送されたメッセージ

全スパムの大多数はSPFに非対応。10%はSPF に PASS
全ハムの5%がSOFTFAIL or FAIL	
ICSS 2010-07	 2010.7.1	

21	

送信元IPアドレスとSPF認証
良性IPアドレス	

悪性IPアドレス	

良性IPアドレスで SOFTFAIL/FAIL のものが存在（少数）悪性IPアドレスでPASSするものが存在（少数）アドレスの数としては少数であるが、これらは比較的多くのメッセージを送信している	
ICSS 2010-07	 2010.7.1	

22	

良性・悪性IPアドレス発メッセージとSPF認証結果#spam	#ham	

ICSS 2010-07	 2010.7.1	

23	

まとめ 半数の良性ドメインおよび約30%の悪性ドメイ

ンはSPFに対応	   SpammerがSPFを利用する目的	   認証をパスする(広いIPアドレス空間)，レピュテーションを上げる(良いIPを混ぜる)	   スパムの10%	  はSPF認証をパスしている	   5%のハムがSPFでSOFTFAIL	  か	  REJECTとなる	   転送の問題、ポータブルなメールアドレスの問題等	   問題となる送信者の数自体はそれほど多くないが、メッセージ数は無視できない	   このような送信者が存在することを考慮した上で後段のフィルタリングを実施する必要あり	   運用で解決できるケースもあり	  ICSS 2010-07	 2010.7.1	

24