DNSとメールサービス

2005年度
情報システム構成論
第10回 メイルシステム
西尾 信彦
[email protected]
立命館大学
情報理工学部 情報システム学科
ユビキタス環境研究室
MTAとMUA
Mail Transfer Agent
Mail Server
Mail User Agent
Mail Client
メイルBox
• サーバ上のメイルを貯めておく場所
• 構築するシステムに沿ったものにする必要がある
(特にNFSを利用する場合は注意が必要)
• 古くからさまざまな種類がある
• 古株(というより絶滅危惧種)
– MMDF
• おそらく一番単純なメイルBox形式
• 現存しているかどうか不明・子孫がSCO システムで使われている?
– BABYL
• MIT の昔のメイルシステムが起源
• Emacs のメイルリーダモードで使われている場合があります
(Emacsの仕様変更によっては使われていないかも)
MH形式
•
•
•
•
•
•
古くからあるメイルBox形式
MH系ソフトが利用している
メイルが一つ一つ別々のファイルに保管される
ファイル名は連番で記述される
管理用のファイルを編集する必要がある
管理用ファイル編集を同時に行うなどするとメイ
ルが正しく管理されなくなる場合がある
• NFSの場合、正常に書き込まれない場合がある
mbox形式
•
•
•
•
比較的古くからあるメイルBox形式
UnixのメイルBox形式としては一般的
全メイルがひとつのファイルに凝縮
メイルとメイルの基本的な区切りはFromで始まる
行があるかどうかで判断する
(メイルの途中でFromから始まる行があると>が
頭に付く)
• 未対応のメイルソフトが少ないので導入が比較
的楽
mbox形式(問題点)
• 配送途中で(つまりファイル編集中に)サーバが
落ちる、他のソフトが同時に書き込む、NFSのマ
ウントが切れるなどするとメイル消失の危険性が
ある。
• ファイル中でFrom行が消失すると、複数のメイル
がひとつに融合してしまう可能性がある
• さまざまな亜種が存在するが、その亜種間での
互換性は保障されていない
• NFSを利用している場合、ファイルロックを別々
のホストで実行すると無意味
Maildir形式
•
•
•
•
別名, qmail-maildir形式
比較的新しいメイルBox形式
メイルが一つ一つ別々のファイルに保管される
NFSを意識してNFS上で利用した場合にも、正常
に処理されるようにしている
• 中央制御ファイルを置かないためファイルロック
を行う必要がなく、複数のプロセスで利用した場
合においても安全
Maildir形式が安全な理由
•
下記のアルゴリズムを利用しているため
1. maildir ディレクトリに 移動する
2. 名前 tmp/time.pid.host の存在をチェック
•
•
•
time は GMT で1970年の開始からの秒数
pid はプログラムのプロセスID
host はMTAのホスト名
3. すでに同名ファイルがあった場合は、数秒待ち再試
行する、これを、回数の上限まで繰り返す
4. tmp/time.pid.host を生成
5. ファイルを NFS 書き込み(NFS-writing)する
6. ファイルを new/time.pid.host に linkする
この瞬間、メッセージは正常に配送される
Maildir形式が安全な理由(2)
•
NFS 書き込み(NFS-writing) とは
1. いつものように、各 write() コールから返されたバイ
ト数をチェックする
2. fsync() を呼び出し、戻り値をチェックする
3. close() を呼び出し、戻り値をチェックする
•
•
などを意味します。
標準的な NFS の実装では、fsync() を誤って処
理するが、 close() して書き込みを強要している
(qmail実装)
実際のアルゴリズムは実装による
受信用プロトコル
• POP3
– サーバ上のメイルBoxから受信
– サーバ上のメイルBoxからメイルを削除する
– サーバ上からメイルを削除するため、メイルBoxの容量が
少ない場合などに有効
– 単一のマシンでしか同一のメイルを扱うことができない
APOP(Authenticated POP)
• POPはパスワードを暗号化せずに流すため安全
ではない
• APOPはPOPのパスワードを暗号化して通信する
• 多くのメイルクライアントが対応済み
– Outlook, Outlook Express, Becky!, Sylpheed,
Wanderust, etc
• 問題
– 多くの場合, サーバ上のアカウントとは別にパスワー
ドを保存するため, 別途パスワードが必要になる
– パスワードのみ暗号化できるが、メイル本文は暗号化
しないため、通信内容は丸見えである(SSL利用に)
受信用プロトコル
• IMAP4
– サーバ上のメイルBoxを閲覧
– サーバ上のメイルBoxからメイルを削除せず、
手元にはキャッシュのみを残す
• 携帯電話・Webメイルなどで利用されている
• 複数のマシンで同一のメイルを扱うことができる
IMAPのユーザ認証
• IMAP標準のユーザ認証は暗号化したパ
スワードを利用しない
• 暗号化したパスワードを利用する方法とし
て、CRAM-MD5などが用意されている
• APOPと同様に、暗号化したパスワードを
利用する場合はアカウント用パスワードと
は別にパスワードが必要になる場合が多
い
メイル配送
• SMTPプロトコル
• DNSのMXレコードを参照して、リレー形式
であて先まで配送する
MXレコード
•A宛はAまで
•B宛はBまで
•C宛はCまで
•D宛はBまで
B
A
C
D
MTAとMUA
Mail Transfer Agent
Mail Server
Mail User Agent
Mail Client
SMTPが抱える問題点
• 古くに作られたプロトコルであり, 性善説にのっ
とって作られたプロトコル
• 送り元の判定をしていない
– どのSMTPサーバにメイル送信を頼んでも, 目的地に
届く
– この特性をSPAMなどに利用され、踏み台にされてい
るサーバが多数存在する
• 暗号化されていないため、内容は丸見えである
ユーザ認証機構を付加した
SMTP
• POP before SMTP
– SMTP送信を行う前にPOPにて認証を行う
– SMTPサーバはPOP認証を行ったホストに対し
て認証後、規定時間以内のメイル送信を許可
する
POP認証
規定時間以内にメイルを送信
POP認証をしていない
(正規の権限がない)ホスト)
POP before SMTPの問題点
• 毎回POP認証を行うため、ネットワークトラフィック
の増加と、スループットの低下を招く
• 送信元を偽ってメイルを出すことによって、誰かが
行ったPOP認証にまぎれて、メイルを飛ばすことが
可能である
POP認証
ホストA
規定時間以内にメイルを送信
送信元偽装メイルは送信可能
私はA
ホストB
ユーザ認証機構を付加した
SMTP
• SMTP Authentication(SMTP AUTH)
– 文字通り、SMTP接続時に認証機構を組み込
んだもの
– SMTP接続時に認証を実行する
(暗号化 or plain)
認証 + メイル送信
認証されない限り、
メイル送信は不可能
ホストA
ホストB
SMTP Authの問題点
• パスワード認証を提供するが、パスワードが暗号
化されて利用されるとは限らない
• 暗号化する場合はチャレンジ-レスポンス認証で
CRAM-MD5を利用することになる
• 暗号化したパスワードを利用する場合、アカウン
ト用パスワードとは別にパスワードが必要になる
• たとえ、暗号化したパスワードを利用したとしても、
通信内容は暗号化されず、内容は丸見えである
チャレンジ-レスポンス認証
• APOPやSMTP/IMAPの暗号化パスワード利用時に使
われる認証方法(CRAM-MD5)
• パスワードを直接暗号化したものは利用しない
• パスワードを特定方法で符号化(MD5などと同様)し、
符号化後のものと符号化の鍵を送信する
• サーバ側では、クライアント側と同様に保存してある生
のパスワードを送られてきた符号化の鍵を使って符号
化し、値を比較して成否を判定する
• APOP/SMTP/IMAPなどで暗号化パスワードを利用する
場合に別途パスワードが必要になるのはこのためであ
る
チャレンジ-レスポンス認証図解
生パスワード
②不可逆変換
生パスワード
③不可逆変換
ランダム鍵
④比較して成
否判定
①乱数発生
チャレンジ-レスポンス認証
利点・欠点
• 利点
– パスワードそのものを暗号化して送らないため、途中で盗聴さ
れたとしても、復号してパスワードを取得することはできない
– 鍵をランダムに決めることにより毎回異なる文字列が生成で
きる
• 欠点
– 双方が生のパスワードを保管しておく必要がある
– 保管されているパスワードの管理に注意が必要
– サーバ側がクラックされた場合は、すべてのパスワードが流
出する
– サーバ・クライアント双方であらかじめ利用する符号化方式を
あわせておく必要がある
SSL/TLSの利用
• 通信経路すべてを暗号化する
• 暗号化された通信経路内で、生のパスワードを
利用しても問題ない
• 通信経路すべてが暗号化されるため、パス
ワードのみではなくメイルの内容自体も暗号化
することができる
• SSL/TLS証明書により接続先の安全性を検証
することができる
SSL/TLSとは
• SSL (Secure Sockets Layer)
– Netscape Communications社が開発した通信経路暗号化
プロトコル
– はじめに公開鍵暗号化方式で共有鍵を交換し高速な暗
号化経路を実現している
– 第三者認証機関が発行した開鍵(電子証明書)を利用
することで、サーバ・クライアントが公的に正規のもので
あることを証明することができる
• TLS (Transport Layer Security)
– SSL3.0に若干の拡張と改良を加えたもの
– RFC 2246としてIETFで標準化されている
暗号化非対応クライアントとの共存
• SMTPにSSLのみを組み込むと、SSL未対応の
SMTPサーバからのメイルを受け取ることができ
ない
• SSL未対応クライアントが利用できない
• はじめにSSLを利用するか(できるか)を選択す
ることを可能にする
– SSL対応SMTPサーバ間の通信はセキュアに、SSL
未対応のSMTPサーバからの通信は今までどおり行
うことができる
– SSL対応・SSL未対応クライアント双方を同一サーバ
で利用することができる
メイルまとめ
• メイルBoxの信頼性確保のためにシステムに
あったメイルBox形式を選ぶ
• POPはサーバ容量が少なくても利用可能
• IMAPは複数のマシンで同一メイルが利用可能
だが、多くのサーバ容量が必要
• SMTPメイルのスパム対策は必須
• パスワードなどセキュリティ項目の検討
(利用者のクライアントソフト・ネットワーク構成
上利用できない場合など)
2005年度
情報システム構成論
第11回バックアップと多重化
西尾 信彦
[email protected]
立命館大学
情報理工学部 情報システム学科
ユビキタス環境研究室
バックアップ(頻度・メディア)
• 要求の種類から必要頻度・メディア種類を選択する
– 研究などで一週間前のスナップショットが必要になることが
ある
⇒ 一週間に一回
– HDDなどの故障対策で即時復旧が必要
⇒ 再構築に時間がかかるテープなどは不要
⇒ ランダムアクセス可能なメディアを選択する
– メールデータなど、現在の状態をリアルタイムにミラーリング
する必要がある
⇒ ミラーリングシステム、RAIDなどを利用する
⇒ 全利用者の合意のものとであれば、一日一回程度とし
その間のデータ損失は許容するという方法もある
バックアップ(時期・必要事項)
• 誰(何)も利用していないときに実行する
–
–
–
–
深夜・休日・事前に告知した時刻に実施する
可能ならばネットワークを切断して実施する
背後で動いているソフトは可能な限り終了する
可能であれば、singleモード起動が理想的
• 所有者・権限などをそのまま保存する
– 保存先メディアがufsを利用できない場合(一部テープメディ
アなど)、権限・所有者情報などを別途保存しておく必要が
ある
– 各種バックアップコマンドのオプションを適切に設定するs
バックアップの利点・欠点
• 利点
– 常時(適時)の情報コピー(スナップショット)を保持で
きる
– コピーからオリジナルを復旧可能
• 欠点
– 故障時に断続利用が可能なわけではない
– 故障時に即座に復旧を開始できるわけではない
– 一時的にであれ、ネットワーク切断・利用停止などが
必要になる
• 多重化することにより、上記の欠点を克服可能
メイルサーバの多重化
• メイルサーバはリアルタイムで情報が届く
ため、一度稼動させると停止させることが
難しい
– メンテナンスや故障時など
• 二重化し、一方が停止している場合、バッ
クアップ用のサーバが稼動するように設計
することが必要になる
メイルサーバの多重化
• MXレコードを利用して転送先を制御する
– MXレコードは複数設定可能
– 優先順位により、転送先が自動的に変更される
• 実際のMXレコードの例
(***.ubi.is.ritsumei.ac.jp宛のメイル配送先)
ubi.is.ritsumei.ac.jp
IN
IN
MX 50 mail1.ubi.is.ritsumei.ac.jp.
MX 90 mail2.ubi.is.ritsumei.ac.jp.
メイルサーバ多重化時の注意点
• メイルサーバごとにメイルBoxが異なると障害
時やメンテナンス時にメイルが分散する
– NFSを利用して同一のメイルBoxを利用する
– NFSを利用するため、メイルBox形式はMaildirが望
ましい
• 双方で同一アカウントを利用する必要がある
– NIS/LDAPなどで同一アカウントが存在する状態に
しておく
• 導入してあるソフトを同一のものにしておく必要
がある
メイルサーバ多重化時の構成例
①メイル配送
上流
メイル
サーバ
メイル
サーバ
②共通のメイル
ボックスに追加
①’メイル配送
メイルサーバダウン時
メイル
サーバ
バックアップ
NFS
NIS
ファイルシステムの多重化
• ファイルシステムがクラッシュすると全データが消滅
する可能性がある
• 定期的にバックアップを取ることである程度防ぐこと
が可能
– ロールバックはどうしても発生する
• ファイルシステムを多重化する利点
– ひとつが壊れた場合でも、正常にサービスを提供し続ける
ことができる
– サービスを提供しながら、壊れているものを途中で取り替え
るなどして、再度多重化状態を構築することができる
RAID
(Redundant Arrays of Independent Disks)
• 高速かつ大容量・高信頼性ディスクを構築する方法
• 1987年にカリフォルニア州バークレー大学で発表された
「A Case for Redundant Arrays of Inexpensive Disks」
という論文が基礎となっている
• 上記のように、もともとは安価(Inexpensive)なディスクを
利用することを前提にしていたものであるが、現在は個別
(Independent)のディスクを用いてという意味になっている
• 専用ハードウェアを利用する方法
– 効果、高速、高信頼性
• ソフト上でエミュレートする方法
– 安価、オーバーヘッドが大きい、信頼性はソフトと実行環境依存
RAID0
• 2台以上のディスクをひとつのディスクとして扱う
• 書き込み、読み込み時は複数のディスクにひとつ
のファイルを分散し、並列アクセスすることにより
高速アクセスを可能にする (striping)
• 理論上、おおよそ接続台数倍のアクセス速度向
上が見込まれる
• 分散して書き込むため、ひとつのディスクが壊れ
た時点で全ファイルが読み出せなくなる
– 信頼性という面では期待できず、信頼性は接続台数
が多いほど低下する
RAID1
• 2台以上のディスクをひとつのディスクとして扱
う
• ミラーリングを行い、複数のディスクに同一の
情報を書き込む
• 最悪一台のディスクが生き残っていれば、処理
を続行することができる
• 信頼性は接続台数を増やすほど向上する
• ディスク利用効率は接続台数に反比例する
– 2台同時に利用すれば1/2、3台同時に利用すれば
1/3となる
RAID5
• データに対してパリティを作成する
• 作成したパリティとデータを分散して配置する
– ディスクが壊れた場合でも、他のディスク上のパリティか
ら壊れたデータを復旧することが可能
• 専用機器の場合、ディスク故障を自動検出し、自動
的に修復するものもある
• 書き込み速度はパリティ計算のため多少低下する
• 読み込み速度は並列アクセス可能なため向上する
• ディスク利用効率は、ディスク一台分がパリティで
利用されるが、 ストライピングされるためほぼ接続
台数に比例する
その他のRAID
• RAID2,3,4が存在するがほとんど使われていない
• RAID0+1
– ミラーリングし、それをさらにストライピングしたもの
– 最低4台以上での構成となる
• RAID6
– RAID5に独立パリティを追加し、複数台異常のディスクが同
時に壊れた場合で、修復可能にしたもの
クラスタリングシステム
• 複数のマシンを相互に接続し、ひとつのマシンの
ように見せる
• ひとつのサービスに対してサーバを複数用意す
ることにより、一部のマシンが故障しても、全体と
してはパフォーマンスが落ちたように見える
(サービスそのものは停止しない)
• パフォーマンスや信頼性の向上は単に接続台数
を増やすことによって実現できる
• ネットワークトラフィックには注意が必要
クラスタリングシステム図解
一つのシステムと
して利用
一部ホストが故
障中でも全サー
ビスが利用可能