電子メールのセキュリティ技術　その2

メール送信元のなりすましを「SPF」で防ぐ

2012年05月15日 06時00分更新

文● 富安洋介／エフセキュア

　前回は、RBLとSURBLというメールの送信経路や本文の内容を評価するセキュリティ技術を紹介しました。今回は、メールのなりすましを防ぐ「SPF（Sender Policy Framework）」という技術を紹介したいと思います。

そのFromアドレスは本物？

　メールソフトで受信したメールを開くと、そこには差出人（From）と宛先（To）が表示されるはずです。ところが、この2つの情報がでたらめな可能性があることをご存じでしょうか。

　そもそもFromとToには

エンベロープのFrom
ヘッダーのFrom
エンベロープのTo
ヘッダーのTo

が存在します。メールソフト上で一般的に目にするのはヘッダーのFrom／Toですが、メールサーバーが実際にメール送信に使うのはエンベロープの方なのです。

　エンベロープのFrom／Toは、SMTPのコマンド上では"Mail From"、"RCPT To"として入力され、メールサーバーにメールの送信元と宛先を伝えるのに使われます。この情報はヘッダーに書かれるFromやToとはまったく関係がなく

"Mail From"とヘッダーのFromを一致させなければいけない
"RCPT To"とヘッダーのToを一致させなければいけない

などの決まりもありません（ヘッダーのFromやToがない場合に、メールサーバーが"Mail From"、"RCPT To"を使って補完する場合がありますが）。さらに、RCPT Toは正しくないと、その宛先にメールが届きませんが、Mail Fromは任意に設定できてしまいます。自分のメールアドレスでなくてもかまわないのです。標的型攻撃では、メールの送信元として実在のFromアドレスが使われてしましが、偽装するメールアドレスとそのアドレスを使っている人の氏名さえわかれば、技術的にはとても簡単なことです。

　そして今回紹介するのが、こうした事態への対策となる技術「SPF」です。

SPFの仕組み

　SPFは、送信元として書かれているメールアドレスのドメインで使われるIPアドレスをDNSに問い合わせ、送信元のIPアドレスがその情報と一致するかどうかを確認します。そのため、受信サーバー側でのSPF利用設定だけではなく、送信元もIPアドレスの情報をSPFレコードとしてDNSに登録する必要があります。

　つまり、SPFを最大限に活用するには、「SPFレコード未登録のメールサーバーからのメールは、すべて怪しいメールとして取り扱う」という運用ポリシーが必要です。昨今では、多くのISPやGmailのようなメールサービスでもSPFレコードが登録されるようになったものの、SPFに対応していないメールを受け付けないようにしてしまうと業務でのメールのやり取りに支障がでる可能性もあります。

　そこで、ひとまずはSPFの検査で失敗した場合も受け取るように設定を行なっておき、SPFのヘッダー情報からメールサーバーで振り分けを行なうのがお勧めです。ちなみに、SPFレコードは、nslookupコマンドを使うことによって確認が可能です。

f-secure.comのSPFレコード問い合わせ結果

　また、SPFを利用したシステムには、「Classic SPF」と「Sender ID」の2種類があります。Classic SPFでは送信元のアドレスとしてエンベロープの"Mail From"を使うのに対し、Sender IDでは「Purported Responsible Address（PRA）」と呼ばれる方法でヘッダーを解析し、送信元を特定するという違いがあります。

初出時、Sender IDの説明に誤りがありました。お詫びし、訂正させていただきます。（2011年5月30日）

SPFの弱点

　SPFは、その技術の特性上、SPFレコードに登録されているメールサーバーが踏み台にされると対応できません。たとえば、メールサーバーが第三者中継を許可している場合、攻撃者がそのメールサーバーに対応したメールアドレスを送信元に設定してメールを送ると、SPFによるチェックを潜り抜けてしまいます。そのため、RBLと組み合わせて使うなどすると、より効果的になると考えられます。また、ドメイン単位でのチェックになるために、ユーザー単位で区別をしてチェックすることは出来ません。

　こうした多少の弱点はあるものの、全体としてSPFは非常に有効なセキュリティ技術であると思います。自社では導入しない場合も、SPFレコードの登録は行なっておきましょう。