1 / 46

メール転送に関わる最近の セキュリティ問題

メール転送に関わる最近の セキュリティ問題. 2002/10/07 朝日大学 経営学部　情報管理学科 奥山　徹 okuyama@alice.asahi-u.ac.jp http://okuyama.dsl.gr.jp/. 今日のトピックス. 電子メールの基礎 電子メールシステム メールアドレスとメッセージ DNS との関係 ウィルスと電子メール. 電子メールシステム. MUA(Mail User Agent) MTA(Mail Transfer Agent) DNS(Domain Name System). DNS. SMTP. SMTP. MUA.

lamya
Download Presentation

メール転送に関わる最近の セキュリティ問題

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. メール転送に関わる最近のセキュリティ問題 2002/10/07 朝日大学 経営学部　情報管理学科 奥山　徹 okuyama@alice.asahi-u.ac.jp http://okuyama.dsl.gr.jp/ (c) Tohru Okuyama, 1999, 2001, 2002

  2. 今日のトピックス • 電子メールの基礎 • 電子メールシステム • メールアドレスとメッセージ • DNSとの関係 • ウィルスと電子メール (c) Tohru Okuyama, 1999, 2001, 2002

  3. 電子メールシステム • MUA(MailUserAgent) • MTA(MailTransferAgent) • DNS(DomainNameSystem) DNS SMTP SMTP MUA MTA MTA MUA mailbox POP/IMAP/... MB (c) Tohru Okuyama, 1999, 2001, 2002

  4. MUA(MailUserAgent) • ユーザアプリケーション メールを読む メールを書く メールを保存／検索／削除する • UNIX ucbmail, RMAIL, mush, mh, mew, … • Windows OutLook, Netsape Mail, Eudora, PostPet,… (c) Tohru Okuyama, 1999, 2001, 2002

  5. MTA(MailTransfer Agent) • メールの受信 • 配信先の決定 • メールの配信 リモートへ、ローカルへ、発信者へ（エラー） • Store and Forward (c) Tohru Okuyama, 1999, 2001, 2002

  6. MTA Programs • sendmail http://www.sendmail.org/ • qmail http://www.qmail.org/ • SMAIL(GNU) • MMDF(Multi-channel Memo Distribution, CSNET) • exim http://www.exim.org/ • Vmail http://wzv.win.tue.nl/vmail/ • LSMTP http://www.lsoft.com/LSMTP.html • PP(X.400) • Postfix http://www.postfix.org/ (c) Tohru Okuyama, 1999, 2001, 2002

  7. インターネットでのメールの送受信 • SMTP　－　SimpleMailTransferProtocol RFC821(S) • TCPのポート25番 • ほとんどのMTAはSMTPの実装を持つ DNSとの連係機能を持つ (c) Tohru Okuyama, 1999, 2001, 2002

  8. SMTPの様子 • ladoga% telnet vanessa.dsl.ics.tut.ac.jp 25（SMTPへの接続） • Trying 133.15.144.8... • Connected to vanessa.dsl.ics.tut.ac.jp. • Escape character is '^]'. • 220 vanessa.dsl.ics.tut.ac.jp ESMTP Sendmail 8.9.3/3.7W; Tue, 14 Sep 1999 15:02:04 +0900（サーバからのコネクションメッセージ） • HELO ladoga.dsl.ics.tut.ac.jp（サーバへのメッセージ） • 250 vanessa.dsl.ics.tut.ac.jp Hello IDENT:okuyama@ladoga.dsl.tutics.tut.ac.jp [133.15.144.7], pleased to meet you • MAIL FROM:okuyama@ladoga.dsl.ics.tut.ac.jp（発信者のアドレス） • 250 okuyama@ladoga.dsl.ics.tut.ac.jp... Sender ok (c) Tohru Okuyama, 1999, 2001, 2002

  9. SMTPの様子(2) • RCPT TO:okuyama@vanessa.dsl.ics.tut.ac.jp　（受信者のアドレス） • 250 okuyama@vanessa.dsl.ics.tut.ac.jp... Recipient ok • DATA • 354 Enter mail, end with "." on a line by itself • This is a test mail.（メール本文） • .　（データの終わりを示す） • 250 PAA01454 Message accepted for delivery • QUIT • 221 vanessa.dsl.ics.tut.ac.jp closing connection • Connection closed by foreign host. (c) Tohru Okuyama, 1999, 2001, 2002

  10. メールアドレス • 発信者／受信者情報として利用 • ユーザ名＠ドメイン名 okuyama@ladoga.dsl.ics.tut.ac.jp • その他の形式 • %-Hack • Route Address • UUCP Addressing (c) Tohru Okuyama, 1999, 2001, 2002

  11. %-Hack • RFC1123(S) user%domain@relay sender→relay→domain relayに届いた時点でuser@domainに書き換え user%domain%relay2@relay1 sender→relay1→relay2→domain (c) Tohru Okuyama, 1999, 2001, 2002

  12. RouteAddress • RFC822(S) @relay：user@domain sender→relay→domain relayに届いた時点でuser@domainに書き換え @relay1,@relay2:user@domain sender→relay1→relay2→domain (c) Tohru Okuyama, 1999, 2001, 2002

  13. UUCPAddressing domain!user relay!domain!user host!user@domainの解釈 “host ! user”@domain (Internet like) host ! “user@domain” (UUCP like) (c) Tohru Okuyama, 1999, 2001, 2002

  14. コメント形式アドレス • Full Name <user@domain> • user@domain(Full Name) • user(User Name)@domain(Univ. Name) ( )のコメントはどこに入ってもよい (c) Tohru Okuyama, 1999, 2001, 2002

  15. メッセージの形式 • メールヘッダ(header)と本文(body) RFC822(S):Standard for the format of arpa internet text messages • 最初の空白行が区切り From:okuyama@dsl.ics.tut.ac.jp To: query@domain.nic.ad.jp Subject: Question for ed.jp domains ←　空行（空白もなし） ed.jpドメインの取得に関する問い合わせ • 発信者(Sender, 通常一人, 意味上の発信者)と受信者(Recipient, 一人または複数人) (c) Tohru Okuyama, 1999, 2001, 2002

  16. ヘッダとエンベロープ • 封書に似ている • エンベロープ(envelope) 投函した人／届け先 封書の表書きの送り主／宛先：実際に事務作業を行った人 配送の際に書き換えられていく • RFC821(S)：SMTP→エンベロープはコマンドで指定 • UUCP→エンベロープはrmailのコマンドラインにて指定 (c) Tohru Okuyama, 1999, 2001, 2002

  17. ヘッダとエンベロープ(2) • ヘッダ(header) 本文を書いた人／読んで欲しい人 内封された書面の送り主／受信者 基本的に書き換えられない • ヘッダとエンベロープの送信者／受信者 同じ場合： 個人宛て 異なる場合： メーリングリストなど (c) Tohru Okuyama, 1999, 2001, 2002

  18. ヘッダとエンベロープ(3) • エンベロープはいつ作られるか • ヘッダから抽出される 送信するMUAが行う 最初に処理を行うMTAが行う • エンベロープは配信処理で書き換えられる 転送 メーリングリスト (c) Tohru Okuyama, 1999, 2001, 2002

  19. 返信に利用するアドレス • 配信エラー通知の返送（自動） エンベロープの発信者 Errors-To: ヘッダ（エンベロープの概念がないシステム用） • 内容の返信（人が介在） ヘッダの発信者 From:, Reply-To, (To:, Cc:) (c) Tohru Okuyama, 1999, 2001, 2002

  20. メールボックスからMUAへ • ローカルメールボックス：UNIXなど • POP(Post Office Protocol) • IMAP(Internet Message Access Protocol) (c) Tohru Okuyama, 1999, 2001, 2002

  21. メールを送ってもらうための設定とDNS • インターネット • SMTPによる直接配信→DNSに配信先を定義 • メール配信時に参照されるDNSレコード • ARR→ホスト名からIPアドレスを取得 • MXRR→メールアドレスから配信先ホスト名を取得 • CNAMERR→ホストの別名を取得 • Genericなメールアドレス • ホスト名部分を持たない • MXRRを利用する→メールはMXで指定されたホストに送られる (c) Tohru Okuyama, 1999, 2001, 2002

  22. MXを使って障害に備える • メール受信の代行 foo.tut.ac.jp preference=10, mx=mail1.tut.ac.jp preference=50, mx=mail2.tut.ac.jp • 数字が小さいほど優先度が高い（コスト値） 送り側は配信に成功するまで順にコストの大きなものへ配信を試みる • mail2はmail1が回復後にmail1に配送 mail2のメールの保存期間に注意 (c) Tohru Okuyama, 1999, 2001, 2002

  23. 送信されたメールの受理 • 届いたメールを自分宛てとして認識 ローカルに配信（受理） 「送られてきた＝自分宛て」ではない • 自分宛てではないと判断した場合 転送先をさがす • 受理するアドレスの設定 sendmail(CF): ACCEPT＿ADDRSに定義 (c) Tohru Okuyama, 1999, 2001, 2002

  24. 受信設定のまとめ • 相手に送り先を教える MXレコードを定義 • 自分宛てだと解釈する ローカルへの配信（受理） • 個別に設定が必要 (c) Tohru Okuyama, 1999, 2001, 2002

  25. メールは配信の設定 • 配信方法のバリエーション • DNSのMX参照による配信→MXを参照するMTAの準備 • ホスト名のみによる配送 • 固定ルールによる配信→DNSを参照する必要性の検討 (c) Tohru Okuyama, 1999, 2001, 2002

  26. DNSのMXを参照する場合 • MXを参照するMTA • sendmail.mx : librisolv.aをリンク • OS付属のものより、最新のソースからコンパイルしたほうが良い→sendmail-8.9.3 • MX参照用sendmail.cf(CF) • MX＿SENDMAIL=yes→アドレスの補完 (c) Tohru Okuyama, 1999, 2001, 2002

  27. 固定ルールによる配信 • sendmail.cfに固定ルールを書く • CF : STATIC＿ROUTE＿FILE • ファイアウォールの中などで固定ルールを参照して配信したい場合は、これを設定する (c) Tohru Okuyama, 1999, 2001, 2002

  28. 配信の動作確認 • アドレスの解釈が正しいか • sendmail -bv あるいは sendmail -bt の /parse • MXが正常に検索できているか • sendmail -bt で /mx コマンド • 実際に送ることができるか • sendmail -v (c) Tohru Okuyama, 1999, 2001, 2002

  29. メールサーバの設定 • メールサーバのアプリケーションプログラムである、sendmail は通常パッケージからインストールされるので、それを使えば良い • 最新版は8.12.6である。もし、最新版でなければ、 ftp://ftp.sendmail.org/pub/sendmail/ から入手できる • 他のアプリケーション(qmail, postfix, etc.)が利用したければそれをインストールする必要がある • 最近では、sendmailよりpostfixを使う傾向にある (c) Tohru Okuyama, 1999, 2001, 2002

  30. メールサーバの設定(2) • 必要に応じて、POPやIMAPなどのMDAのサーバプログラムをインストールする • 設定が終わったら、一通りテストしてみる (c) Tohru Okuyama, 1999, 2001, 2002

  31. ウイルス今昔物語 • 昔のウイルス • FDなどの外部媒体を経由する場合が多く、自己伝染性にはそれほど高くなかった • 時には破壊的なウイルスが蔓延することがあったが、多くは自己顕示的なものであった • 今のウイルス • 電子メールやWEBなど、利用可能な伝染媒体を駆使するワームタイプ（自己伝染性の強いもの）が主流となっている • ファイルを実行すくことで伝染するものにとどまらず、スクリプトタイプのように、各種アプリケーションの問題点を突くような、複合型ウイルスとなっている（Nimdaなど） • 破壊活動やDDoS攻撃など悪質なものが多くなってきている (c) Tohru Okuyama, 1999, 2001, 2002

  32. ウイルス被害の届け出件数(2002) 13359件 (c) Tohru Okuyama, 1999, 2001, 2002

  33. ウイルス被害の届け出件数(1990～2002) 1990は4月～12月 2002は1月～ 7月 (c) Tohru Okuyama, 1999, 2001, 2002

  34. 2002年7月の状況IPAの2002年7月の被害届け出状況による(http://www.ipa.go.jp/security/txt/2002_08.html)2002年7月の状況IPAの2002年7月の被害届け出状況による(http://www.ipa.go.jp/security/txt/2002_08.html) • 被害届け出件数：1,781件（先月よりは少し減る） • 感染実害率：9.7%（先月の6.4%より悪化） • 届出ウイルスの種類：41種類 • 新種ウイルス：W32/Frethem亜種（日本語環境でも発症） • Windows/DOS系：1,686、マクロウイルス及びスクリプト系：93、Mac系及びUNIX系：2 • 一番届出の多かったウイルスW32/Klez • 感染経路：メールにより感染したケースが最も多い（届出件数の82.0％の割合を占める） (c) Tohru Okuyama, 1999, 2001, 2002

  35. 感染を防ぐには 1）最新のウイルス定義ファイルに更新し、ワクチンソフ トを活用すること 2）メールの添付ファイルは、開く前にウイルス検査を行 うこと 3）ダウンロードしたファイルは、使用する前にウイルス 検査を行うこと 4）アプリケーションのセキュリティ機能を活用すること 5）セキュリティパッチをあてること 6）ウイルス感染の兆候を見逃さないこと 7）ウイルス感染被害からの復旧のためデータのバック アップを行うこと (c) Tohru Okuyama, 1999, 2001, 2002

  36. メールの添付ファイルに関する注意 1） 見知らぬ相手先から届いた添付ファイル付きのメールは厳重注意する 2） 添付ファイルの見た目に惑わされない 3） 知り合いから届いたどことなく変な添付ファイル付きのメールは疑ってかかる 4） メールの本文でまかなえるようなものをテキスト形式等のファイルで添付しない 5） 各メーラー特有の添付ファイルの取り扱いに注意する (c) Tohru Okuyama, 1999, 2001, 2002

  37. メールの添付ファイルに関する注意（２） 1） 見知らぬ相手先から届いた添付ファイル付きのメールは厳重注意する 見知らぬ相手先から送信されたメールの添付ファイルについては、安全を確認することが難しく、また、ほとんどのケースが自分に必要ないものであるので、無条件に削除することが望ましい。 (c) Tohru Okuyama, 1999, 2001, 2002

  38. メールの添付ファイルに関する注意（３） 2） 添付ファイルの見た目に惑わされない 　テキストファイル（拡張子「.txt」）や画像ファイル（拡張子 「.jpg」）などの、ウイルスに感染することのないファイルに見せかけた添付ファイルを送りつけるウイルスが発見されており、注意が必要である。 　添付ファイルは、見た目に惑わされず、プロパティで拡張子を表示するなどによりファイル形式を確認し、ファイルを実行するアプリケーションを把握するとともに、自分に必要なものかどうかを判断したうえで使用するべきである。 (c) Tohru Okuyama, 1999, 2001, 2002

  39. メールの添付ファイルに関する注意（４） 3） 知り合いから届いたどことなく変な添付ファイル付きのメールは疑ってかかる 　メールを送信するタイプのウイルスが激増しており、知り合いから送信された添付ファイル付きのメールは、送信者の知らない間にウイルスが送信している可能性が ある。巧妙に添付ファイルを開かせるような心理をついてくるので、このような知り合いからのメールこそウイルスの疑いを持って接する必要がある。 　メールに付帯の情報（メール本文等）もウイルスが作成 している可能性があるため、これらの情報も信用せず、 例えば先方に問い合わせるなどにより安全を確認して から使用するべきである。 (c) Tohru Okuyama, 1999, 2001, 2002

  40. メールの添付ファイルに関する注意（５） 4） メールの本文でまかなえるようなものをテキス 形式等のファイルで添付しない 　　受信者にウイルス検査の作業負担を生じさせることに なり、また、検査を行ったとしても不安感を完全にぬぐいさることはできないので、添付ファイル付きのメール送信は避ける。 　必要にせまられ添付ファイル付きでメールを送信する場合には、当該ファイルのウイルス検査を行ってから実 施するようにし、あわせてメールに付帯の情報（メール 本文等）以外で、添付ファイルを付けた旨とその内容を事前に先方に伝えるような配慮が望ましい。 　一方、このようにして届けられたものでも、受信者はウイルス検査後使用するという用心深さが必要である。 (c) Tohru Okuyama, 1999, 2001, 2002

  41. メールの添付ファイルに関する注意（６） 5） 各メーラー特有の添付ファイルの取り扱いに注意する 　メーラーの設定、メーラーの特殊性などの添付ファイルの取り扱いに関連する事項をよく把握して使用することが重要である。 　例えば、一部のメーラーでは、受信時に添付ファイルをあらかじめ指定されたフォルダに自動的に展開しファイル保存する。このようなメーラーを使用している場合は、ウイルス検出などでメール本文ごと添付ファイルを削除した時に、保存されている複製も忘れずに削除されるような設定にする必要がある。 (c) Tohru Okuyama, 1999, 2001, 2002

  42. ファイルのダウンロードに関する注意 • 安易にプログラムをダウンロードして実行してしまうと、 次のようなトラブルを招くことがある • コンピュータウイルスに感染する • ダイヤルQ2接続や国際電話をかけられ、後日法 外な請求書が届く • ハードディスク内のデータが破壊される • 外部の第三者にコンピュータを操られる • ハードディスク上のファイルが盗まれる（読まれ る） (c) Tohru Okuyama, 1999, 2001, 2002

  43. 感染したら届出を • IPAに届ける http://www.ipa.go.jp/security/ • JPCERTに届ける http://www.jpcert.or.jp/ (c) Tohru Okuyama, 1999, 2001, 2002

  44. 検証：Nimdaに見る新世代ウイルスの類型 • Nimda • 全方向ウイルス：これまでのウイルスが持っていた感染拡大機能を併せ持つ • サーバ、メール両方を介しての自動侵入機能 • IISのサーバのバグをつく • IEのブラウザのばつをつく • 当然Outlookを使ったメールを介しても媒介する • 特定ブラウザを通じての感染機能 (c) Tohru Okuyama, 1999, 2001, 2002

  45. 検証：Nimdaに見る新世代ウイルスの類型（具体的な内容）検証：Nimdaに見る新世代ウイルスの類型（具体的な内容） このウイルスは、セキュリティホールを悪用したウイルスで、Windows95/98/ME/NT/ 2000で動作する。 • マイクロソフト社の Internet Information Server (IIS) のセキュリティホールのあるシス テムに侵入するとホームページを改ざんする • セキュリティホールのあるInternetExplorerで改ざんされたホームページを見るとウイル スに感染する • クライアントが感染すると、Outlookのアドレス帳に登録されているアドレス等にウイルス を添付したメールを送信する • 添付ファイル名はreadme.exeである • そのウイルス付メールを受け取ると、Outlookではメールを開いただけ で、OutlookExpressではプレビューしただけでも感染することがある (c) Tohru Okuyama, 1999, 2001, 2002

  46. まとめ • メールは現在の必須情報交換網（インターネットと携帯電話を合わせると、普及率は実に7割以上と推定される） • それだけに問題点も多い • ウィルス伝播 • SPAMメール • いやがらせメール • 正しく使いましょう (c) Tohru Okuyama, 1999, 2001, 2002

More Related