クライアントセキュリティ
電子メール
電子メールの仕組み
一般的な電子メールの流れ
- メール送信者は、メールソフト(MUA)によって作成したメールを、LAN上の社内メールサーバにSMTPで発信(投稿)する
- メールの送受信要求を受けたMSAは、メール送信者の識別・認証を行い、認証が成立すればMTAにメールの送信を依頼する
- 社内メールサーバのMTAは、設定に従い、送信するメールを社外向けメールサーバにSMTPで中継する
- 送信側ドメインの社外向けメールサーバは、受信側ドメインの社外向けメールサーバに、SMTPでメールを中継する
- メールを受信した受信側ドメインの社外向けメールサーバは、送信先の応じた社外メールサーバにSMTPでメールを中継する
- 社内メールサーバのMTAは、自身が管理するメールBox宛のメールであるためMDAにメールを引き渡す
- 社内メールサーバのMDA、受け取ったメールを宛先のメールBoxに格納する
- 社内メールサーバのMRAは、受信者からのメール要求を受けると、受信者の識別・認証を行い、認証が成立すればメールBoxからメールを取り出してMUAに送る
- メール受信者がMUAでメールを読む
| 名称 | 主な役割 | 製品・プログラム等の例 | |
|---|---|---|---|
| MUA | Mail User Agent | メールの発信(投稿)、受信 | Outlook Express、Eudra等 |
| MSA | Mail Submission Agent | メールの投稿受付、ユーザ認証 | sendmail、qmail、Posrfix、 Exchange Sever等 |
| MTA | Mail Transfer Agent | メールの中継(配送) | |
| MDA | Mail Delivery Agent | メールBoxへの格納 | mail.local、procmail、Qpopper等 |
| MRA | Mail Retrieval Agent | ユーザ認証、メールの取出し | Qpopper、uw-imap、Courier-IMAP等 |
メールヘッダ情報の概要
下の図のhostAからhostBあてにメールを送った場合、最終的にhostBが受信したメールのヘッダ情報は図A、図Bのようになる
図A：メールヘッダ情報のイメージ(主なヘッダ)
図B：メールヘッダ情報のイメージ(Receivedヘッダの各フィールド)
| 項目 | 概要 | |
|---|---|---|
| Retum-Path: | エラー等が発生した場合のメールの送り先アドレス Reply-Toと異なるのは、メールサーバが付加する点 「MAIL FROM」コマンド(SMTP)の内容を付加(エンベロープの差出人アドレス) (→送信者が任意の名称を指定可能) | |
| Received: | メールの受信・中継履歴、メールがサーバを経由するたびに追加される 最初にメールを受信・中継したサーバの情報がヘッダの一番下となり、ヘッダの一番上のReceivedが最後に経由したサーバが記録した情報となる | |
| from | "from"のすぐ右には、SMTPの「HELO」コマンドで通知された、メール発信者のホストドメイン名が入る(→送信者が任意の名称を指定可能) 右側の()内には、上記のホストのIPアドレスから逆引きされたホストドメイン名及びIPアドレスが入る(→詐称は不可) | |
| by | メールを受信したサーバのドメイン名、ホスト名等 | |
| for | 最終的なメール送信先アドレス SMTPの「RCPT TO」コマンドで通知された受信者のエンベロープアドレス | |
| From | メール発信者のMUAに設定された差出人アドレス(→送信者が任意の名称を指定可能) | |
| To | メール発信者のMUAに設定された宛先アドレス | |
SMTPの脆弱性
メールの投稿と中継の仕組みが同じ
パケットフィルタリングによる第三者中継の抑制が困難
SMTPを実装したMTAでは、MUAからのメール送信処理もメール転送処理もメール受信処理もすべて25番ポートで実施していた。標準設定では、これらの処理が同一の仕組みで行われてしまうため、オープンリレーサーバとしてスパムメールの踏み台とされていた。(旧バージョンメールサーバ)
メールの投稿にあたってユーザを認証する仕組みがない(別SMTPサーバの認証機構がない・クライアントの認証機構がない)
第三者中継が可能
標準MTAでは、認証機能がなく送信元の詐称が容易に行われていた。また認証機能がないので本来受け付ける必要のない組織外からのメールも送信、転送処理がおこなわれていた。(旧バージョンメールサーバ)
データが暗号化されない
メールの暗号化機能が標準装備されていないため、平文でネットワークを流れる
パケット盗聴によって内容が漏えいしたり、内容を改ざんされたりする
MTAの実装・設定によってユーザのメールアカウント情報が漏えいする可能性がある
VERY、EXPNコマンドを利用し、メールアカウントの有無、メールの実際の配送先情を確認可能
MTAの種類、バージョンによってBOF攻撃を受ける脆弱性がある
旧バージョンのMTAにはBOF攻撃を受ける脆弱性がある
SMTPの脆弱性への対策
MTAの設定による発信元メールアドレスの制限
発信元/あて先メールアドレスのいずれにも自分のサイトのドメイン名が含まれないメールを配信しない (→第三者中継を抑制)
SMTP-AUTHによるユーザ認証(サーバ-クライアント間の認証機構)
「CRAM-MD5」や「DIGEST-MD5」を使えば、チャレンジレスポンス方式の認証が可能。(パスワードが平文のままネットワークを流れない、リプレイアタックを防げる)
・SMTP自体に認証を追加するのでPOP Before SMTPの問題であった、「手間がかかる」や「IPアドレス共有」の問題を回避できる
・クライアントが対応している必要有り
| 種類 | RFC | 概要 |
|---|---|---|
| PLAIN | RFC2595 | 平文のままユーザIDとパスワードを送信する方式。Base64でエンコードする場合もあり、SSLなどによる暗号化の利用が前提になる |
| LOGIN | PLAIN同様に平文を用いた認証形式 | |
| CRAM-MD5 | RFC2195 | CRAM(Challenge-Response Authentication Mechanism)、接続先メールサーバから示された任意の文字列(Challenge)にクライアントがパスワードを含め、MD5のメッセージダイジェスト(一種のチェックサム値)を利用して認証する方式。この方法ではパスワード自身がネットワークに流れることがないので、安全性は高くなる |
| DIGEST-MD5 | RFC2831 | CRAM-MD5の欠点である辞書攻撃や総当たり攻撃に対する対処とともに、Realm（ログイン領域）やURLの指定（これらはHTTPなどへの応用を想定している）や、HMAC（keyed-Hashing for Message Authentication Code）による暗号化をサポートしている。 |
POP Before SMTP(サーバ-クライアント間の認証機構)
一定期間内にメールを受信したユーザ(のIPアドレス)にのみ、メール送信を許可する。(POP3には認証があるのでそっちを使う)
・クライアントに特殊な仕組みが不要で、クライアントを選ばない(POPでアクセスできればよい。)
・送信前に受信する手間がユーザにかかる
・プロキシを介した場合など、複数ユーザが同じIPを使う場合に正しくアクセス制御ができない
Outbound Port 25 Blocking
外向けの25番ポートのアクセスをブロックして、社内のPCから社外のメールサーバに直接接続しての不正送信を防ぐ防御手法
・社外のメールサーバが利用できなくなる、という問題がある
SMTPサーバ間の認証機構
●IPアドレスによる方式
SPF(Sender Policy Framework)
DNSで、特定のドメインのメールを送信可能なSMTPサーバのIPアドレスを管理し、それ以外から送られたメールを転送しない。ブラックリスト方式
・多くの企業やプロバイダが参加しなければ効果がない
・自前ドメインとDNSを用意すればチェックを回避できる。(ただし送信元の追跡は容易)
SenderID
DNSで、特定のドメインのメールを送信可能なSMTPサーバのIPアドレスを管理し、それ以外から送られたメールを転送しない。ブラックリスト方式
受信したメールのヘッダ情報(From：、Sender:など)のメールアドレスのドメインの正当性を検証する
・多くの企業やプロバイダが参加しなければ効果がない
・自前ドメインとDNSを用意すればチェックを回避できる。(ただし送信元の追跡は容易)
●デジタル署名による方式
DomainKeys
公開鍵暗号を利用したメール送信元認証の仕組み。送信するメールに電子署名を付け、受け取り先で検証することで、送信元を認証、改ざんチェックする
・メール転送サービス等で、転送途中でメールが改ざんされると困る。(なので、改ざんを検知したからといって破棄するのはまずい。)
・署名の追加等のためメールサーバに負荷がかかる
DomainKeys Identified Mail(DKIM)
DomainKeysとCisco Systemsが提案したIIM (Identified Internet Mail)という規格をあわせたもので大きな仕組みでは、ほぼ同じ
DomainKeysがサポートしていたのがドメイン単位での認証だったのに対して、 DKIMはIIMと同じく送信者アドレス単位での認証も可能
メールフィルタリング
メールの暗号化及びユーザ認証
SMTP over SSL、SMTP over TLS
メールの送信をTLS/SSLで暗号化した通信路上で行う。SMTPSとも呼ばれる
・SSLとTLSでは使用するポートが異なる
(SMTP over SSL：465/TCP、SMTP over TLS：25/TCP)
メールの暗号化
S/MIME、PGP(メール自体の暗号化、クライアント間の暗号化)
不要なコマンドの無効化
VRFY、EXPNなど、不要なコマンドを無効とするようMTAを設定する
MTA実装面での対策
- MTAのバージョンを最新化し、パッチを適用する
- ウイルス対策ソフトウェアを導入し、中継するメールに添付されたウイルスを駆除する
- インターネットのSMTPサーバと社内LAN上のSMTPサーバとの間で相互にメールの中継を行う中継専用サーバ(外向けSMTPサーバ)をDMZ上に設置する
- 社内LAN上にSMTPサーバ兼POP3サーバを設置し、クライアントからの送信要求を受け付けるとともに、外向けSMTPサーバから転送されてきた社内ユーザあてのメールを振り分けて保存する
- 外向けメールサーバと同じDMZセグメント上にゲートウェイ型ウイルス対策サーバを設置し、メールに添付された不正なコードを駆除する
S/MIME
公開鍵を使ってメールの暗号化とデジタル署名を行うための標準規格
・メールの暗号化
・発信者の否認防止
・改ざんの検知
をサポートする
PGP
S/MIMEと同じく公開鍵を使った暗号化とデジタル署名を行うための仕組み。信頼の輪と呼ばれる仕組みにより、ユーザが相互に署名しあう点が特徴(S/MIMEは信頼できる認証機関が認証する)。このため、秘密鍵の無効化が困難だったりする
POP3の脆弱性
認証情報が暗号化されない
パスワード漏洩による不正アクセス
データが暗号化されない
盗聴されたり、内容を改ざんされたりする可能性が…
POP3の脆弱性への対策
APOPを使う。(チャレンジレスポンス方式)
認証時にメッセージダイジェストによりパスワードを暗号化してメールサーバへ返すという認証方法で盗聴されても、解読できない方法にする。ただし、暗号化されるのは認証情報のみとなる。
「POP3 over SSL」、「POP3 over TLS」(いずれもポート995)を使用して、メールの暗号化をする。
暗号化されるのはPOP3サーバからMUAまでの間。これを使用する際には、受信側のファイアーウォールのポート995を許可する必要がある。
SSH（Secure SHell)を用いて暗号化する。
SSHは認証情報から受信するメールを一括暗号化する方式で、リモートコンピュータ（通信相手）と安全に通信する為のプロトコル。ただし、暗号化されるのはPOP3サーバからMUA間のみとなる。POP3だけでなく、暗号化されないアプリケーション通信の際にSSHが間に入って中継、暗号化するプロトコルである
メッセージダイジェスト
認証前に、サーバから送られる毎回変わるチャレンジワードを用いて、MUAが認証する際、そのチャレンジワードとパスワードを組み合わせて、認証する方式。（チャレンジレスポンス方式）
POP Over TLS
メールの受信をTLS/SSLで暗号化した通信路上で行う。POP3sとも呼ばれる。
