LoginSignup
1
1
@nao_hanpen

絶対にフィッシングに耐える方法！！？（１）　～SPF・DKIMで送信元を確認するには～

Posted at

以前から問題となっていたフィッシング（欺いて認証情報を窃取すること）ですが、已然として事件が相次ぎ、その内容もさほど変わっていません。信頼されているメディアが報じている対策のなかにも、根本的でなかったり、「誤解を生じさせかねないのではないか」と思われるものがあったりします。
この記事では、電子メール（Eメール）を使用したフィッシングを、一般的なユーザー（特に重大なセキュリティ上の脅威にさらされているわけではない人）が受信したことを想定して、予防的・根本的な対策を考えたいと思います。

注）正しい情報を提供できるよう心掛けていますが、セキュリティのスペシャリストではありません。内容をよく検証のうえ、ご活用ください。

送信元の確認（根本的対策）

仕組み

現在のネットワークでは、複数の技術が組み合わせて使われています。

ネットワーク
当たり前のことですが、電子メールはサーバーからネットワークを通じて送信されます。受信するサーバーが侵害されていなければ、受信時の接続元が確認できる送信元となります。ドメインに紐づけて公開される DNS 情報から、信頼できる送信元サーバーかどうかを検証する仕組みがあります。

署名・暗号技術
メール送信を別の事業者に委託するなど、別のネットワークから送信したい場合も考えられます。その場合でも、公開鍵暗号による署名を行うことで送信元を検証できます。ウェブサイト上に公開鍵を配信している場合や、ドメインに紐づけて公開される DNS で公開鍵が公開されている場合があります。

検証する方法

一般的な検証プロトコル（規格）として、SPF（Sender Policy Framework）や DKIM（DomainKeys Identified Mail）などがあります。ここでは、この２つの方法を使用します。

1. メールヘッダーを確認する

ネットワーク上でやり取りされるデータの多くは、ヘッダー(Header)とボディ(Body)に分かれています。メールヘッダーには件名やメッセージIDなどの情報が記載されています。（ RFC 5322 といくつかの規格で標準化されています。）

page1_確認方法.png

送信元アドレス

Return-Path フィールドが送信元アドレスです。
FQDN（ホスト＋ドメイン名）を後で使います。下の例では、example.com の部分です。

Return-Path: <sender@example.com>
送信元サーバー

送信元サーバーは from が入っている最初の Received フィールドに送信元サーバーのホストと IP アドレスが載っています。(FQDN [IPアドレス]) が送信元です。IP アドレスを後で使用します。
下の例では、192.0.2.1（ evil-server.example.com ）が safety-server.example.com と設定して送信してます。

例
Received: from safety-server.example.com (evil-server.example.com [192.0.2.1])
        by receiver-server.example.com
DKIM 署名（あれば）

DKIM-Signature フィールドが存在すれば、DKIM 署名が設定されていることを意味します。このデータは、後で使用します。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=dkim; t=XXXXXXXXXX; x=XXXXXXXXXX;
        h=to:from:subject:message-id:date:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=XXXXXXXXXXXXX;
        b=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

2. DNS を引く

信頼できる DNS サーバーを使用する必要があり、それを確認するために DNSSEC という仕組みがありますが、ここではその詳細は割愛します。

SPF を検証する

まず、SPF レコードを確認するために、先ほど確認した送信元（例では example.com）の TXT レコードを検索します。v=spf1 から始まるレコードが SPF 用のレコードです。存在しない場合もあります。

example.com の TXT レコードの例
v=spf1 include:_spf.example.com ~all

SPF レコードの見方は、こちらの記事で説明しています。が、SendGrid「送信ドメインを認証するためのSPFレコードに詳しくなろう」がとても分かりやすいです。

例えば、ip4 や ip6 に指定された IP アドレスが送信元サーバーと一致していれば、検証クリアです。
一致する IP アドレスがなければ、検証失敗です。失敗した場合、all が存在すればそれに従います。

DKIM を検証する

DKIM は SPF ほど単純なプロセスでは解決できません。
RFC 6376 として詳細な仕様が規定されています。

メールヘッダーの DKIM-Signature フィールドの内容を使用します。
= の前の文字を「タグ」といいます。d タグが送信者が指定したドメインで、s タグが DNS レコードを検索するために使う文字（セレクタ）、h タグは署名済みのフィールド、bh タグはメール本文のハッシュ値、a タグはハッシュアルゴリズム、b タグは署名済みデータです。

言葉にするのが難しすぎたので、画像でご覧ください。なお、一部省略しています。

page2_dkim.png

Gmail や Yahoo メールなどのメーラーは、DKIM に対応しています。

3. 総合的に判断する

DNS の SPF / DKIM 用レコードで設定されている処理ポリシーや、メールの内容に応じて送信元が正しいと判断するかを決定します。
「疑わしい」まま次のステップに移ったり、送信元に別の手段で確認したりすることもできます。

また、送信元のメールアドレスがメールに記載されているブランドのものかを確認する必要があります。例えば、google.example.com と google.com は別のドメインです。
いわゆる SMTP over SSL といったような TLS を利用してメールを受信する場合、認証機関が実在する組織であることを証する EV（Extended Validation）証明書を利用していれば送信元の組織を確認できます。

文面の文法（予防的対策）

フィッシングメールには不自然な文面がよく使用されます。（根拠が見つかりませんでした）
言うまでもないと思うので、ここは気が向いたら書き足します。

自動的なフィッシングサイトの検出（予防的対策）

フィッシング攻撃ツールの普及によって、フィッシングサイトの特徴を検出しやすくなりつつあります。ここは気が向いたら書き足します。

DKIM を調べるのに疲れてしまいました。真面目な書き出しのわりに緩～い終わり方で失礼します💦

参考資料（順不同）

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1