何十億もの IP アドレスをドメインとして送信することを許可している場合、Sender Policy Framework はスパムやフィッシングを防止するのに役立ちません
XNUMX年前、 ポール・ビクシー に関するコメントのリクエストを公開しました MAIL FROMの拒否 これにより、インターネット コミュニティはスパムと戦う新しい方法を開発するようになりました。 送信者ポリシーフレームワーク (SPF). 当時の問題は、現在と同様に、 簡易メール転送プロトコル (SMTP) は、インターネット上で電子メールを送信するために使用され、偽造された送信者ドメインを検出する方法を提供しません。
ただし、SPF を使用する場合、ドメイン所有者は、ドメイン名を使用して電子メールを送信することを承認された IP アドレスを定義するドメイン ネーム システム (DNS) レコードを公開できます。 受信側で、電子メール サーバーは、 見かけ上 送信者ドメインを調べて、送信者の IP アドレスがそのドメインに代わって電子メールを送信する権限を持っているかどうかを確認します。
SMTP メールと SPF の概要
SMTP メッセージ送信メカニズムと SPF がメカニズムとどのように相互作用するかに精通している読者は、このセクションを飛ばした方がよいかもしれませんが、このセクションは非常に短いものです。
アリスが example.com ボブに電子メールメッセージを送信したい example.org. SPF がなければ、Alice と Bob の電子メール サーバーは次のような SMTP 会話を行います。これは、EHLO ではなく HELO を使用して単純化されていますが、基本的な構成を大幅に変更する方法ではありません。
インターネット(SMTP)メールの送受信はこんな感じ 初期の1980、しかし、少なくとも今日のインターネットの基準では、大きな問題があります。 上の図では、Chad at 例.net に簡単に接続できます example.org SMTP サーバーで、まったく同じ SMTP 会話に参加し、明らかに Alice からの電子メール メッセージを example.com でボブに配信 example.org. さらに悪いことに、診断メッセージ ヘッダー (ここには示されていません) のホスト名と一緒に記録された IP アドレスを除いて、Bob に欺瞞を示すものは何もありませんが、これらは専門家以外が確認するのは容易ではなく、電子メール クライアント アプリケーションによっては、 、アクセスすることさえ難しいことがよくあります。
電子メール スパムのごく初期には悪用されていませんでしたが、大規模なスパムがビジネス モデルとして確立されるにつれて、そのような電子メール偽造技術が広く採用され、スパム メッセージが読み取られ、さらには行動に移される可能性が高まりました。
架空のチャドに戻る 例.net そのメッセージを「アリスから」送信する…これには XNUMX つのレベルのなりすまし (または偽造) が含まれます。多くの人々は、そのような偽の電子メール メッセージを検出してブロックするために、自動化された技術的なチェックを行うことができる、または行う必要があると感じています。 XNUMX つ目は SMTP エンベロープ レベルで、XNUMX つ目はメッセージ ヘッダー レベルです。 SPF SMTP エンベロープ レベルでのチェックと、その後の偽造防止およびメッセージ認証プロトコルを提供します。 dkim 拡張子 & DMARC メッセージ ヘッダー レベルでチェックを提供します。
SPFは機能しますか？
ある人によると 研究 2022 年に公開された調査では、調査した 32 億のドメインの約 1.5% に SPF レコードがありました。 これらのうち、7.7% が無効な構文を使用しており、1% が非推奨の PTR レコードを使用していました。これは、IP アドレスをドメイン名にポイントします。 SPF の取り込みは遅く、実際に問題がありました。これは、別の疑問につながる可能性があります。過度に寛容な SPF レコードを持つドメインはいくつあるでしょうか?
最近の研究成果 オーストラリアだけでも 264 の組織が SPF レコードに悪用可能な IP アドレスを持っていたため、無意識のうちに大規模なスパムやフィッシング キャンペーンの準備を整えている可能性があります。 その調査結果とは関係ありませんが、私は最近、誤って構成された SPF レコードを悪用した、潜在的に危険な電子メールを自分で見つけました。
受信トレイのなりすましメール
最近、フランスの保険会社 Prudence Cr を名乗る電子メールを受け取りました。éole、しかしすべてを持っていた スパムの特徴 なりすまし:
電子メールの From: アドレス メッセージ ヘッダーを偽造するのは些細なことだとわかっていますが、完全な電子メール ヘッダーを調べて、SMTP エンベロープ MAIL FROM: アドレスのドメインが 返信@prudencecreole.com SPFチェックに合格しました：
だから私はドメインのSPFレコードを調べました prudencecreole.com:
これは、IPv4 アドレスの巨大なブロックです。 178.33.104.0/2 IPv25 アドレス空間の 4% を含みます。 128.0.0.0 〜へ 191.255.255.255. XNUMX 億を超える IP アドレスが、プルーデンス クレオールのドメイン名の承認された送信者であり、スパマーの楽園です。
冗談ではないことを確認するために、自宅にメール サーバーをセットアップし、インターネット サービス プロバイダーからランダムではあるが適切な IP アドレスを割り当てられ、なりすましメールを自分に送信しました。 prudencecreole.com: 
成功！
さらに、なりすましを行っていた別のスパム メールから受信したドメインの SPF レコードを確認しました。 wildvoyager.com:
見よ、見よ、 0.0.0.0/0 ブロックにより、4 億を超えるアドレスで構成される IPvXNUMX アドレス空間全体が、Wild Voyager のふりをしながら SPF チェックに合格できるようになります。
この実験の後、プルーデンス Cr に通知しました。éole と Wild Voyager に、誤って構成された SPF レコードについて報告します。 プルーデンス Créole は、この記事の公開前に SPF レコードを更新しました。
反省と教訓
ドメインの SPF レコードを作成することは、スパム送信者のなりすましの取り組みに対する致命的な打撃ではありません。 ただし、安全に構成されている場合、SPF を使用すると、受信トレイに届くような多くの試みを挫折させる可能性があります。 おそらく、SPF の即時の広範な使用とより厳密な適用を妨げている最も重大なハードルは、電子メールの配信可能性です。 SPF ゲームをプレイするには XNUMX つ必要です。これは、送信者と受信者の両方が、どちらかの側で採用されている過度に厳格なルールが原因でメールが配信されない場合に備えて、メール セキュリティ ポリシーを調整する必要があるためです。
ただし、スパマーがドメインをスプーフィングすることによる潜在的なリスクと損害を考慮して、次のアドバイスを適切に適用できます。
- SPF 検証者が RFC 7208 の推奨事項 これらを確認するには
- を使用することをお勧めします を とのメカニズム 「– or 「~ 修飾子ではなく 「? 修飾子、後者として 誰でもあなたのドメインを偽装することを効果的に許可します
- 「すべてをドロップする」ルールを設定します (v=spf1 -all) 所有する各ドメインおよびサブドメインに対して、(インターネット経由の) 電子メールを生成したり、HELO/EHLO または MAIL FROM: コマンドのドメイン名部分に表示したりしないでください。
- ガイドラインとして、SPF レコードが小さく、できれば 512 バイトまでであることを確認して、一部の SPF ベリファイアによって黙って無視されるのを防ぎます。
- SPF レコードで、限られた信頼できる IP アドレスのセットのみを承認するようにしてください。
電子メールの送信に SMTP が広く使用されるようになったことで、電子メールを安全かつプライバシーを保って転送することよりも、確実かつ効率的に転送することに重点を置く IT 文化が生まれました。 セキュリティ重視の文化に再適応するのは時間のかかるプロセスかもしれませんが、インターネットの荒廃の XNUMX つであるスパムに対して明確な利益を得るという観点から着手する必要があります。
