Download presentation
Presentation is loading. Please wait.
1
メール転送に関わる最近の セキュリティ問題
2002/10/07 朝日大学 経営学部 情報管理学科 奥山 徹 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
2
今日のトピックス 電子メールの基礎 ウィルスと電子メール 電子メールシステム メールアドレスとメッセージ DNSとの関係
2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
3
電子メールシステム MUA(Mail User Agent) MTA(Mail Transfer Agent)
DNS(Domain Name System) DNS SMTP SMTP MUA MTA MTA MUA mailbox POP/IMAP/... MB 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
4
MUA(Mail User Agent) ユーザアプリケーション UNIX Windows メールを読む メールを書く
メールを保存／検索／削除する UNIX ucbmail, RMAIL, mush, mh, mew, … Windows OutLook, Netsape Mail, Eudora, PostPet,… 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
5
MTA(Mail Transfer Agent)
メールの受信 配信先の決定 メールの配信 リモートへ、ローカルへ、発信者へ（エラー） Store and Forward 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
6
MTA Programs sendmail http://www.sendmail.org/
qmail SMAIL(GNU) MMDF(Multi-channel Memo Distribution, CSNET) exim Vmail LSMTP PP(X.400) Postfix 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
7
インターネットでのメールの送受信 SMTP － Simple Mail Transfer Protocol TCPのポート25番
RFC821(S) TCPのポート25番 ほとんどのMTAはSMTPの実装を持つ DNSとの連係機能を持つ 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
8
SMTPの様子 ladoga% telnet vanessa.dsl.ics.tut.ac.jp 25（SMTPへの接続）
Trying 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 :02: （サーバからのコネクションメッセージ） HELO ladoga.dsl.ics.tut.ac.jp （サーバへのメッセージ） 250 vanessa.dsl.ics.tut.ac.jp Hello [ ], pleased to meet you MAIL 250 Sender ok 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
9
SMTPの様子(2) RCPT TO:okuyama@vanessa.dsl.ics.tut.ac.jp （受信者のアドレス）
250 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. 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
10
メールアドレス 発信者／受信者情報として利用 ユーザ名＠ドメイン名 その他の形式
その他の形式 %-Hack Route Address UUCP Addressing 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
11
%-Hack RFC1123(S) user%domain@relay sender→relay→domain
sender→relay1→relay2→domain 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
12
Route Address RFC822(S) @relay：user@domain sender→relay→domain
sender→relay1→relay2→domain 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
13
UUCP Addressing domain!user relay!domain!user host!user@domainの解釈
“host ! (Internet like) host ! (UUCP like) 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
14
コメント形式アドレス Full Name <user@domain> user@domain(Full Name)
user(User Name) ( )のコメントはどこに入ってもよい 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
15
メッセージの形式 メールヘッダ(header)と本文(body) 最初の空白行が区切り
RFC822(S):Standard for the format of arpa internet text messages 最初の空白行が区切り To: Subject: Question for ed.jp domains ← 空行（空白もなし） ed.jpドメインの取得に関する問い合わせ 発信者(Sender, 通常一人, 意味上の発信者)と受信者(Recipient, 一人または複数人) 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
16
ヘッダとエンベロープ 封書に似ている エンベロープ(envelope) RFC821(S)：SMTP→エンベロープはコマンドで指定
投函した人／届け先 封書の表書きの送り主／宛先：実際に事務作業を行った人 配送の際に書き換えられていく RFC821(S)：SMTP→エンベロープはコマンドで指定 UUCP→エンベロープはrmailのコマンドラインにて指定 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
17
ヘッダとエンベロープ(2) ヘッダ(header) ヘッダとエンベロープの送信者／受信者 本文を書いた人／読んで欲しい人
内封された書面の送り主／受信者 基本的に書き換えられない ヘッダとエンベロープの送信者／受信者 同じ場合： 個人宛て 異なる場合： メーリングリストなど 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
18
ヘッダとエンベロープ(3) エンベロープはいつ作られるか ヘッダから抽出される 送信するMUAが行う 最初に処理を行うMTAが行う
エンベロープは配信処理で書き換えられる 転送 メーリングリスト 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
19
返信に利用するアドレス 配信エラー通知の返送（自動） 内容の返信（人が介在） エンベロープの発信者
Errors-To: ヘッダ（エンベロープの概念がないシステム用） 内容の返信（人が介在） ヘッダの発信者 From:, Reply-To, (To:, Cc:) 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
20
メールボックスからMUAへ ローカルメールボックス：UNIXなど POP(Post Office Protocol)
IMAP(Internet Message Access Protocol) 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
21
メールを送ってもらうための設定とDNS インターネット メール配信時に参照されるDNSレコード Genericなメールアドレス
SMTPによる直接配信→DNSに配信先を定義 メール配信時に参照されるDNSレコード A RR→ホスト名からIPアドレスを取得 MX RR→メールアドレスから配信先ホスト名を取得 CNAME RR→ホストの別名を取得 Genericなメールアドレス ホスト名部分を持たない MX RRを利用する→メールはMXで指定されたホストに送られる 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
22
MXを使って障害に備える メール受信の代行 数字が小さいほど優先度が高い（コスト値） mail2はmail1が回復後にmail1に配送
foo.tut.ac.jp preference=10, mx=mail1.tut.ac.jp preference=50, mx=mail2.tut.ac.jp 数字が小さいほど優先度が高い（コスト値） 送り側は配信に成功するまで順にコストの大きなものへ配信を試みる mail2はmail1が回復後にmail1に配送 mail2のメールの保存期間に注意 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
23
送信されたメールの受理 届いたメールを自分宛てとして認識 自分宛てではないと判断した場合 受理するアドレスの設定 ローカルに配信（受理）
「送られてきた＝自分宛て」ではない 自分宛てではないと判断した場合 転送先をさがす 受理するアドレスの設定 sendmail(CF): ACCEPT＿ADDRSに定義 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
24
受信設定のまとめ 相手に送り先を教える 自分宛てだと解釈する 個別に設定が必要 MXレコードを定義 ローカルへの配信（受理）
2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
25
メールは配信の設定 配信方法のバリエーション DNSのMX参照による配信→MXを参照するMTAの準備 ホスト名のみによる配送
2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
26
DNSのMXを参照する場合 MXを参照するMTA MX参照用sendmail.cf(CF)
sendmail.mx : librisolv.aをリンク OS付属のものより、最新のソースからコンパイルしたほうが良い→sendmail-8.9.3 MX参照用sendmail.cf(CF) MX＿SENDMAIL=yes→アドレスの補完 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
27
固定ルールによる配信 sendmail.cfに固定ルールを書く
CF : STATIC＿ROUTE＿FILE ファイアウォールの中などで固定ルールを参照して配信したい場合は、これを設定する 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
28
配信の動作確認 アドレスの解釈が正しいか sendmail -bv あるいは sendmail -bt の /parse
MXが正常に検索できているか sendmail -bt で /mx コマンド 実際に送ることができるか sendmail -v 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
29
メールサーバの設定 メールサーバのアプリケーションプログラムである、sendmail は通常パッケージからインストールされるので、それを使えば良い 最新版は8.12.6である。もし、最新版でなければ、 ftp://ftp.sendmail.org/pub/sendmail/ から入手できる 他のアプリケーション(qmail, postfix, etc.)が利用したければそれをインストールする必要がある 最近では、sendmailよりpostfixを使う傾向にある 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
30
メールサーバの設定(2) 必要に応じて、POPやIMAPなどのMDAのサーバプログラムをインストールする
設定が終わったら、一通りテストしてみる 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
31
ウイルス今昔物語 昔のウイルス 今のウイルス FDなどの外部媒体を経由する場合が多く、自己伝染性にはそれほど高くなかった
時には破壊的なウイルスが蔓延することがあったが、多くは自己顕示的なものであった 今のウイルス 電子メールやWEBなど、利用可能な伝染媒体を駆使するワームタイプ（自己伝染性の強いもの）が主流となっている ファイルを実行すくことで伝染するものにとどまらず、スクリプトタイプのように、各種アプリケーションの問題点を突くような、複合型ウイルスとなっている（Nimdaなど） 破壊活動やDDoS攻撃など悪質なものが多くなってきている 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
32
ウイルス被害の届け出件数(2002) 13359件 (c) Tohru Okuyama, 1999, 2001, 2002
2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
33
ウイルス被害の届け出件数(1990～2002) 1990は4月～12月 2002は1月～ 7月
2002は1月～ 7月 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
34
2002年7月の状況 IPAの2002年7月の被害届け出状況による(http://www. ipa. go
被害届け出件数：1,781件（先月よりは少し減る） 感染実害率：9.7%（先月の6.4%より悪化） 届出ウイルスの種類：41種類 新種ウイルス：W32/Frethem亜種（日本語環境でも発症） Windows/DOS系：1,686、マクロウイルス及びスクリプト系：93、Mac系及びUNIX系：2 一番届出の多かったウイルスW32/Klez 感染経路：メールにより感染したケースが最も多い（届出件数の82.0％の割合を占める） 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
35
感染を防ぐには 1）最新のウイルス定義ファイルに更新し、ワクチンソフ トを活用すること
2）メールの添付ファイルは、開く前にウイルス検査を行 うこと 3）ダウンロードしたファイルは、使用する前にウイルス 検査を行うこと 4）アプリケーションのセキュリティ機能を活用すること 5）セキュリティパッチをあてること 6）ウイルス感染の兆候を見逃さないこと 7）ウイルス感染被害からの復旧のためデータのバック アップを行うこと 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
36
メールの添付ファイルに関する注意 1） 見知らぬ相手先から届いた添付ファイル付きのメールは厳重注意する
2） 添付ファイルの見た目に惑わされない 3） 知り合いから届いたどことなく変な添付ファイル付きのメールは疑ってかかる 4） メールの本文でまかなえるようなものをテキスト形式等のファイルで添付しない 5） 各メーラー特有の添付ファイルの取り扱いに注意する 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
37
メールの添付ファイルに関する注意（２） 1） 見知らぬ相手先から届いた添付ファイル付きのメールは厳重注意する
見知らぬ相手先から送信されたメールの添付ファイルについては、安全を確認することが難しく、また、ほとんどのケースが自分に必要ないものであるので、無条件に削除することが望ましい。 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
38
メールの添付ファイルに関する注意（３） 2） 添付ファイルの見た目に惑わされない
テキストファイル（拡張子「.txt」）や画像ファイル（拡張子 「.jpg」）などの、ウイルスに感染することのないファイルに見せかけた添付ファイルを送りつけるウイルスが発見されており、注意が必要である。 添付ファイルは、見た目に惑わされず、プロパティで拡張子を表示するなどによりファイル形式を確認し、ファイルを実行するアプリケーションを把握するとともに、自分に必要なものかどうかを判断したうえで使用するべきである。 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
39
メールの添付ファイルに関する注意（４） 3） 知り合いから届いたどことなく変な添付ファイル付きのメールは疑ってかかる
メールを送信するタイプのウイルスが激増しており、知り合いから送信された添付ファイル付きのメールは、送信者の知らない間にウイルスが送信している可能性が ある。巧妙に添付ファイルを開かせるような心理をついてくるので、このような知り合いからのメールこそウイルスの疑いを持って接する必要がある。 メールに付帯の情報（メール本文等）もウイルスが作成 している可能性があるため、これらの情報も信用せず、 例えば先方に問い合わせるなどにより安全を確認して から使用するべきである。 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
40
メールの添付ファイルに関する注意（５） 4） メールの本文でまかなえるようなものをテキス 形式等のファイルで添付しない
受信者にウイルス検査の作業負担を生じさせることに なり、また、検査を行ったとしても不安感を完全にぬぐいさることはできないので、添付ファイル付きのメール送信は避ける。 必要にせまられ添付ファイル付きでメールを送信する場合には、当該ファイルのウイルス検査を行ってから実 施するようにし、あわせてメールに付帯の情報（メール 本文等）以外で、添付ファイルを付けた旨とその内容を事前に先方に伝えるような配慮が望ましい。 一方、このようにして届けられたものでも、受信者はウイルス検査後使用するという用心深さが必要である。 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
41
メールの添付ファイルに関する注意（６） 5） 各メーラー特有の添付ファイルの取り扱いに注意する
メーラーの設定、メーラーの特殊性などの添付ファイルの取り扱いに関連する事項をよく把握して使用することが重要である。 例えば、一部のメーラーでは、受信時に添付ファイルをあらかじめ指定されたフォルダに自動的に展開しファイル保存する。このようなメーラーを使用している場合は、ウイルス検出などでメール本文ごと添付ファイルを削除した時に、保存されている複製も忘れずに削除されるような設定にする必要がある。 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
42
ファイルのダウンロードに関する注意 安易にプログラムをダウンロードして実行してしまうと、 次のようなトラブルを招くことがある
コンピュータウイルスに感染する ダイヤルQ2接続や国際電話をかけられ、後日法 外な請求書が届く ハードディスク内のデータが破壊される 外部の第三者にコンピュータを操られる ハードディスク上のファイルが盗まれる（読まれ る） 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
43
感染したら届出を IPAに届ける http://www.ipa.go.jp/security/ JPCERTに届ける
2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
44
検証：Nimdaに見る新世代ウイルスの類型
全方向ウイルス：これまでのウイルスが持っていた感染拡大機能を併せ持つ サーバ、メール両方を介しての自動侵入機能 IISのサーバのバグをつく IEのブラウザのばつをつく 当然Outlookを使ったメールを介しても媒介する 特定ブラウザを通じての感染機能 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
45
検証：Nimdaに見る新世代ウイルスの類型（具体的な内容）
このウイルスは、セキュリティホールを悪用したウイルスで、Windows95/98/ME/NT/ 2000で動作する。 マイクロソフト社の Internet Information Server (IIS) のセキュリティホールのあるシス テムに侵入するとホームページを改ざんする セキュリティホールのあるInternetExplorerで改ざんされたホームページを見るとウイル スに感染する クライアントが感染すると、Outlookのアドレス帳に登録されているアドレス等にウイルス を添付したメールを送信する 添付ファイル名はreadme.exeである そのウイルス付メールを受け取ると、Outlookではメールを開いただけ で、OutlookExpressではプレビューしただけでも感染することがある 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
46
まとめ メールは現在の必須情報交換網（インターネットと携帯電話を合わせると、普及率は実に7割以上と推定される） それだけに問題点も多い
ウィルス伝播 SPAMメール いやがらせメール 正しく使いましょう 2002/10/07 (c) Tohru Okuyama, 1999, 2001, 2002
Similar presentations
