迷惑メールの低減に向けて - jpnicユーザ認証...
TRANSCRIPT
内容 迷惑メールあれこれ ゾンビ対策 メールを追跡可能に
携帯電話と迷惑メール
インターネットと迷惑メール 携帯電話への迷惑メールは減少傾向にある レート制御 迷惑メール配送事業者の特定が容易 迷惑メール追放支援プロジェクト 総務省 ＋ 経済産業相 オトリを用意し、迷惑メールと判定 約款の行使を後押し
インターネットの迷惑メールは急増加 昨年の夏に 10 倍になった メールサーバを圧迫
問題点 迷惑メール配送事業者の特定が困難 ゾンビによる大量のメール配信 メールアドレスの詐称によるフィッシング
ゾンビ 乗っ取られた PC を「ゾンビ」と呼ぶ あるいは「Bot」 迷惑メール配送業者は、世界最大の分散コンピューティング 環境を持っている
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
サーバASP C
フィッシング・メール (1)
フィッシング・サイト (1)
フィッシング・メール (2)
フィッシング・サイト(2)
フィッシング 110 番 フィッシングの相談窓口 http://www.npa.go.jp/cyber/policy/phishing/phishing110.htm
すぐに警察が動ける 業務妨害罪 著作権法違反
特定電子メール送信適正化法では？ 警告メールの送信 → 措置命令の発出 措置命令の発出は、3年間で 3 件 2005年5月 問題点を改訂 SMTP のみ → SMS も含む 未承諾広告のみ → 空メールも含む 個人宛のみ → 業務用 ML も含む 措置命令 → 送信者を偽造した場合の直罰 2005年6月 初の業務停止命令 (2件)
コンテンツ・フィルタ メールの内容から迷惑メールか判断 単語の統計を取る アダルト関連の用語 強壮剤関連の用語 サイトへのリンク
Subject: 白姫女子校保健室からのおしらせ From: 県立白姫女子校保険室
この前の妊娠検査について 県立白姫女子高校保健室からのお知らせです。
間違って受け取った方は、 お手数ですが、破棄してください。 お詫び致します。
該当する人は 下記リンクより入ってお知らせを確認して下さい。
http://just-feed.net/shirahime/?m9xDi8OM2U18v6troZOMN8xluEhWd4BwN7
法律 日本国憲法 (21条2項) 検閲は これをしてはならない 通信の秘密は、これを侵してはならない
電気通信事業法 3条：電気通信事業者の取扱中に係る通信は、 検閲してはならない 4条：電気通信事業者の取扱中に係る通信の秘密は、 侵してはならない
フィルタリングは検閲 ISP にとって、標準でフィルタリング・サービスを 提供するのは違反 ユーザの同意が必要
コンテンツ・フィルタの限界 出会い系サイトへの誘導 Subject: あのぉ・・・ From: 黒川京子
黒川ですけど、 何も書いてないメールくださいましたよね？ 念のために返信しますが、どちらさまでしょうか？ 知人のいたずらですか？
Subject: あの～ From: 井上知美
メールくれましたよね？ 最初は迷惑メールかと思ってたんだけど よく見たらそんな変なアドレスじゃないので メール返してみたんですが、 以前どちらかのチャットか何かでお話したかたですか？？
コンテンツ・フィルタは対症療法
メールを追跡可能に 配送と投稿の分離 ゾンビからの配送の禁止 投稿に対するユーザ認証 配送に対するドメイン認証
サーバ サーバ配送投稿
ユーザ認証 ドメイン認証
example.jpalice
メールアドレスを詐称できない世界 迷惑メールを受け取ったら、そのドメインの管理者へ 文句を言えばよい
注意 ISP/ASP のメール管理者の「共通理解」 内容はあくまで理想論 すべての ISP/ASP が、すべてを実現できる訳ではない 政治的な理由 技術的な理由 経済的な理由
インターネットのあるべき姿は？ ユーザに自由を与えるが、責任も課す？ ユーザの自由を制限するが、安全なサービスを提供する?
問題点
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
配送25
25配送
配送サーバ
ASP C
25
ゾンビ(bot)による迷惑メールの大量送信 メールアドレスの詐称 メールの追跡が困難 フィッシング
投稿ポートの提供
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
配送
配送
配送サーバ
ASP C
25587
25587
25587
配送 ドメイン間の通信 (ポート 25 番) 投稿 ユーザとそのドメイン間の通信 (ポート 587 番、RFC 2476) プロトコル自体は SMTP
投稿ポートへの移行
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
サーバASP C
25587
25587
25587
配送
投稿 587
25
25
25
25
25
ユーザ認証投稿 587
ユーザ認証
投稿ポートにはユーザ認証が必須 POP before SMTP では不十分 理想的には、ポート 25 番への投稿を禁止する 現実的には、ドメイン内からのポート 25 番への配送も許可 ドメイン外からは、ポート 587 番のみ投稿を許可
25番ポートのブロック
ブロック
ブロック
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
サーバASP C
25587
25587
25587
配送
投稿 587
25
25
25
25
25
ユーザ認証
投稿 587
ユーザ認証
ポート 25 番をブロックする 追跡しにくい動的 IP からのみ 固定 IP は受信側でブラックリストを作成できる 独自にメールサーバを運用したい人は、固定 IP へ
25番ポートのブロックの導入実績 アメリカ AT&T、Bell CA、Bell South、Comcast Earthlink、MSN、Verizon 詳しくは http://www.postcastserver.com/help/Port_25_Blocking.aspx
日本 ぷららネットワークス http://www.plala.or.jp/access/living/releases/nr05_jan/0050127.html 携帯事業社向け WAKWAK(NTT-ME) http://www.wakwak.com/info/news/2005/port25blocking0107.html 全面 SANNET http://www.sannet.ne.jp/news/20050331-1.html 全面
予想される新しい攻撃
ブロック
ブロック
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
サーバASP C
25587
25587
25587
配送
投稿 587
25
25
25
25
25
ユーザ認証
投稿 587
ユーザ認証
パスワードを盗むゾンビが出現？ 堂々と迷惑メールを投稿する配送業者
レート制御
ブロック
ブロック
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
サーバASP C
25587
25587
25587
配送
投稿 587
25
25
25
25
25
投稿 587
レート制御
レート制御
投稿にレート制御をかける 短時間にたくさんの迷惑メールを送られることを禁止
ドメイン認証
ブロック
ブロック
サーバ
サーバゾンビ
ゾンビ
ISP A ISP B
サーバASP C
25587
25587
25587
配送
投稿 587
25
25
25
25
25
ユーザ認証
投稿 587
ユーザ認証ドメイン認証
レート制御
レート制御
配送にはドメイン認証を必須にする 本当にそのドメインの送信サーバから送られているか検査
ドメイン認証の候補 IP アドレス型 SPF、Sender ID (MFROM) 封筒の送り主 (SMTP MAIL FROM)
Sender ID (PRA) 便箋の送り主 (メールのヘッダ)
電子署名型 DKIM 便箋の署名 DomainKeys と IIM は統合された
これらは共存できる ヘッダを保護できればフィッシング対策となる Sender ID (PRA) DKIM
普及のストーリー
検証(前)フィルタリング
(前)結果をヘッダへ
(後)受信拒否 メールリーダ
移行前期 受信サーバは認証結果をメールのヘッダへ Authentication-Results: mx.example.jp [email protected]; sender-id=pass; spf=pass
メールリーダは認証結果を元にフィルタリング
移行後期 受信サーバは認証に失敗したら受信拒否
IPアドレス型
サーバ サーバ
example.jpDNS
192.0.2.1
example.jp=192.0.2.1
受信側 1) SMTP コネクションから相手の IP アドレスを得る 2) 保護対象となるドメイン名を取り出す SMTP MAIL FROM メールのヘッダ 3) そのドメイン名で DNS を索き、 送信サーバの IP アドレスを得る 4) 1. と 3. の IP アドレスを比較
SPF (Sender Policy Framework) POBOX が提唱 送信サーバの宣言 exmaple.com IN TXT "v=spf1 +a +mx -all" A RR か MX RR の IP アドレスのみ送信可能 "+" → pass "?" → neutral "~" → softfail "-" → fail
保護対象となるドメイン名は、SMTP MAIL FROM
Sender ID IETF で SPF と Caller ID を統合 送信サーバの宣言は SPF と同様 example.com IN SPF "spf2.0/mfrom,pra +a +mx -all" "v=spf1" は "spf2.0/mfrom,pra" と読み替える
保護対象となるドメイン名は SMTP MAIL FROM (MFROM) メールのヘッダ (PRA) 受信者が選択する
PRA =「責任があるとされるアドレス」 PRA(Purported Responsible Address) と呼ぶ Resent-Sender:, Resent-From:, Sender:, From:
エラーメール
MAIL FROM:<[email protected]>RCPT TO:<[email protected]>
example.jp
example.comMAIL FROM:<[email protected]>RCPT TO:<[email protected]>
MAIL FROM:<>RCPT TO:<[email protected]>
MAIL FROM:<[email protected]>RCPT TO:<[email protected]>
SPF とエラーメール ISP はハーベスティング攻撃を防ぐため、 すべてのメールを受け取る 内側で多段の検査 SPF の検査をし、検証失敗ならメールを捨てる
example.jp
example.comMAIL FROM:<[email protected]>RCPT TO:<[email protected]>
MAIL FROM:<>RCPT TO:<[email protected]>
SPF
エラーメールの測定 Mew.org に SPF RR を書いた 2005年4月20日 v=spf1 +mx -all
電子署名型
サーバ サーバ
example.jpDNS
example.jp
署名 検証
公開鍵
秘密鍵
送信側 秘密鍵を使って署名
受信側 保護対象となるドメイン名を取り出す そのドメイン名で DNS を索き、公開鍵を得る 公開鍵を使って署名を検証
署名の検証が失敗する原因 DomainKeys の署名はヘッダと本文が対象 これまでに見つけた原因 Content-Transfer-Encoding: を変換する MTA → 変換しないように設定 Subject: を変更する ML サーバ 通し番号を入れるため → 署名対象から除外 Received: を削除する ML サーバ ホップ数を稼ぐため → 署名対象から除外 フィールドの順番を変える ML サーバ
対症療法 Subject: と Received: を署名の対象から外す ほとんどの場合、うまくいく
普及率の測定 JPRS と WIDE プロジェクトの共同研究 2005年5月 http://jpinfo.jp/stats/
問題点と解決案 SPF 転送に弱い メーリングリストに強い DKIM 転送に強い メーリングリストに弱い
両者を組み合わせる どちらか一方の検証が成功すれば、レピュテーションへ どちらとも失敗なら、コンテンツ・フィルタへ
メールが追跡可能になった後 迷惑メール配送業者は、独自のドメインを取り、 ドメイン認証に対応して、迷惑メールを送る ドメインを評価するシステムが必要 レピュテーション (reputation) と呼ばれる (例) cloudmark.com % dig iij.ad.jp.rating.cloudmark.com txt iij.ad.jp.rating.cloudmark.com. 1M IN TXT "Status: Good" iij.ad.jp.rating.cloudmark.com. 1M IN TXT "Rating: 100"
ISP/ASP の将来像 追跡可能なメールシステム レピュテーション コンテンツ・フィルタ