信頼できるドメインまたは共有送信サービスが、不正なメッセージ パスの一部になる可能性があります。有益な質問は、インフラストラクチャが一般的に信頼できるかどうかではありません。これは、この特定のメッセージが認証された ID の使用を許可されているかどうかです。認証とビジネス認可はさまざまな質問に答えます。
再利用される権限を定義する
侵害されたメールボックスは、通常の認証されたルートを通じて送信する可能性があります。ネットワーク認証が広すぎると、意図しない送信元が許可される可能性があります。リレーは、十分に具体化されていない許可ルールの下でメッセージを受け入れた後、メッセージに署名する可能性があります。これらのメカニズムにはさまざまな所有者と救済策があります。それらを、評判乗っ取りという説明のつかない主張にまとめてしまうのはやめてください。
元の BreakSPF 研究では、寛容性を調査しています。 SPF 構成と共有インフラストラクチャ。その脅威モデルでは、ソースネットワークへのアクセスが中心的な条件となります。これは展開の境界であり、攻撃者が任意の境界を偽造できるという証拠ではありません。 DKIM署名. BreakSPF 論文、セクション III。論文の測定結果は、脆弱なサービスの現在の目録ではなく、歴史的研究として扱ってください。
正確な脅威モデルを構築する
保護されたドメイン、認証された識別子、許可されたソース セット、攻撃者の能力、受信者の決定を個別に記述します。ここの制限付きシナリオでは、 brand.test はSPFとして192.0.2.0/24承認します。承認されたアプリケーションは192.0.2.10を使用しますが、仮想の意図しないテナントは192.0.2.99から発生する可能性があります。どちらのアドレスも公開範囲内にあります。このようなテナント アクセスが実際のサービスに存在するかどうかには、別の証拠が必要です。
SPF 、評価された ID のソース認証をチェックします。共有 IP の背後にある人間を特定することはありません。渡されたSPF ID が作成者のドメインとも一致する場合、そのパスは次の条件を満たすことができます。 DMARC それなし DKIM. RFC 7208 そして RFC 9989。したがって、評価が成功すると、受信者がパス ルールを無視したのではなく、過大な権限が付与されたことが判明する可能性があります。
3 つの書面による承認ケースを比較する
表示されているalerts@brand.test 、空ではないものと仮定します メール送信元 bounce@brand.test 、 DKIM署名なし、その他の場合は適格なDMARC評価。仮説を比較する SPFレコード v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- 承認されたソース192.0.2.10 : 両方のネットワーク プレフィックスに含まれます。 SPF合格し、brand.test と一致するため、例示的なメッセージはどちらの場合でもDMARCを通過します。
- 意図しないソース192.0.2.99 : /24 には含まれていますが、/32 には含まれていません。 SPF広範な記録の下でのみ合格します。 DKIM署名がない場合、規定されたDMARC結果は、/24 では合格、/32 では不合格となります。
- 外部ソース198.51.100.10 : どちらのプレフィックスにも含まれません。 -all指定すると、どちらの場合でもSPFが失敗します。 DKIM署名がない場合、規定されたDMARC結果は両方とも失敗になります。
これらはプレフィックスメンバーシップと書かれており、 アライメント 実行中のSPFパーサー、 DNS観察、または BreakSPF の再現ではなく、推定です。ソース管理は想定されていますが、実証されていません。外部メッセージやライブ サービスはテストされませんでした。この論文のクロスプロトコル技術は、この教育例の範囲外です。
単一のパッシングアライメントメカニズムは、メッセージのDMARC通過条件を満たすことができます。これでは SPF のみの展開が適切とは言えません。RFC9989 セクション 7.4 RFC9989 、ドメイン公開に有効なDKIM必要です。 p=reject、セクション 8 では完全参加について説明します。これらは個別の展開作業であり、メッセージごとの追加のパス ゲートではありません。
責任の境界線を修正する
実際のSPFレコードを絞り込む前に、すべての正当な送信者のインベントリを作成し、プロバイダーがサポートする構成に従います。専用ソースは、実際に排他的で保守されている場合にのみ役立ちます。送信サービスが顧客を許可された ID にバインドしていることを確認します。 DKIM構成を検証し、変更管理を通じて古い権限を削除します。
変更後のルート固有の障害を監視し、復旧計画を保存し、不明な送信者を文書化します。この例の推測された IP リストで広範なレコードを置き換えないでください。教訓は、デモンストレーションDNS運用環境にコピーすることではなく、承認と実際のサービスの所有権を調和させることです。