DNS制御を電子メールの信頼の一部として扱う
DNSハイジャックは、クライアントが信頼する情報または解決パスに対する不正な変更です。電子メール チームにとって重要な問題は、単にドメインの Web サイトが移転したかどうかだけではありません。どの権限、アカウント、またはリゾルバーが影響を受けたのか、どのメール関連の名前が変更されたのか、影響を受けた期間中に受信者が何を観察したのかを特定します。現在の明確な答えは、以前の配信決定で同じデータが使用されたことを証明するものではありません。
権限テイクオーバーをキャッシュ ポイズニングやローカル リゾルバー リダイレクトから切り離してください。同様の症状が発生する可能性がありますが、異なる回復所有者が必要です。レジストラ アカウントは委任に影響を与える可能性があります。権限のあるホスティング アカウントはゾーンのコンテンツを変更できます。侵害されたエンドポイントは予期しないリゾルバーを使用する可能性があります。 NISTの DNS導入ガイド 権威サービス、再帰サービス、およびスタブ サービスに対する脅威を区別します。この区別が、有用なインシデント マップの出発点となります。
移動した信頼境界を特定する
既知の登録および委任のベースラインを現在の権威サービスと比較します。レジストラ、 DNSホスティング、署名インフラストラクチャ、回復連絡先を管理する人を記録します。悪意があると判断する前に、変更が承認されているかどうかを確認してください。計画された移行、委任されたサブドメイン、分割ビューによって正当な差異が生じる可能性があります。記録やアカウントのログが利用できない場合でも、不確実性を保ちます。
以前のプロバイダーからの信頼できるように見えるゾーンのエクスポートでは、もはや公的代表団を説明していない可能性があるため、権限のある階層が重要になります。 RFC 1034セクション 4.2 ゾーン境界と委任について説明します。インシデントの証拠は、単に回答テキストを再現するだけでなく、各観察に使用されたサーバーとパスを特定する必要があります。クエリ名、レコードタイプ、タイムスタンプのないスクリーンショットは、何が変更されたのかを示す弱い証拠となります。
確立されたインシデント手順を使用して、影響を受けるアカウントを保護し、関連するログを保存し、復元を調整します。これらのアクションには組織の承認が必要です。この記事は、実際のサービスに対する変更を指示するものではありません。インシデント所有者が影響を受ける状態を把握する前に、アカウントを削除したり、すべてのレコードを置き換えたり、すべてのキャッシュをクリアしたりして、有用な証拠を破壊することを避けてください。
受信メールと送信メールのさまざまな結果を追跡する
不正なMX変更により、受信メールの配信試行がリダイレクトされる可能性があります。特定の送信者が実際に配信するかどうかは、選択されたルート、トランスポート保護、および結果として生じる接続によって異なります。メールボックスの内容がMX違いだけから読み取られたと推測しないでください。影響を受ける間隔を確立し、暴露の主張を行う前に配達の証拠を検査してください。
アウトバウンド ID チェックにはさまざまな依存関係があります。 SPF 以下のDNSポリシーを使用して、接続アドレスが評価されたドメインに対して承認されているかどうかを評価します。 RFC 7208。敵対者がそのポリシーを制御している場合、 SPFパスは正当なビジネス承認ではなく、無許可のポリシーを反映する可能性があります。を交換する DKIM 公開キーは検証に影響を与える可能性がありますが、キーを公開しても古いメッセージ署名が変更されたり、以前の秘密キーが明らかになったりすることはありません。キーの検索と検証のプロセスについては、「 RFC 6376セクション 3.6 および 6.1.2.
DMARC 作成者ドメインと一致する認証された識別子に依存します。これは、承認された従業員またはベンダーの独立した登録簿ではありません。ハイジャックされたドメインの認証マテリアルは、合格結果の背後にある前提を損なう可能性があります。ドメイン ポリシーは、次で説明されているように、普遍的な結果を保証するのではなく、受信者の処理についても通知します。 RFC 9989セクション 4.4 および 5.4.
どの保護がどのリスクに対処するかを理解する
DNSSEC 検証に使用可能な信頼チェーンがある場合、発信元の認証とDNSデータの整合性を提供します。認可された署名システムを通じて行われた変更が所有者の意図を反映していることを保証するものではありません。侵害された権限のある管理パスによって受け入れられ、署名された悪意のある編集は引き続き検証される可能性があります。 RFC 4033セクション 3 DNSSEC提供するサービスを規定します。アカウント保護と承認制御は別のレイヤーに対応します。
交通政策にも独自の分析が必要です。既存の MTA-STS ポリシーは、送信者を実装するために許可されるMXホストとTLS検証を制限できますが、初期検出とポリシー キャッシュには制限があります。 DANE SMTP DNSSEC 認証情報と適切な情報に依存します。 TLSA 記録。どちらのメカニズムも、管理ドメインの乗っ取りに対する万能の解毒剤として説明されるべきではありません。相談する RFC 8461セクション 10 そして RFC 7672セクション 2 独自の信頼モデルのため。
係争中のMX変更の架空の実際に実行された例
架空の組織 Example Workshops では、 example.comに別のMXターゲットがあることがアラートによって報告されます。メール管理者の古いDNSパネルには、依然として期待値が表示されます。提案されている調査では、委員会が単に権威を失っているかどうかを判断する前に、委任、現在の権威ある回答、レジストラの変更記録を比較する予定だ。
その後、インシデント記録によって権限のない委任変更が証明されたとします。応答所有者は、承認された権限の復元を調整し、送信者のログとトランスポート ポリシーの証拠に照らして時間枠を評価します。無関係なアウトバウンドメッセージに対する認証パスでは、インバウンドの暴露の問題は解決されません。このシナリオは作成されたものであり、観察されたインシデント、プロバイダー アカウントへのアクセス、テストされた復元は含まれていません。
1 つの答えを復元する以上の回復を定義する
承認されたレコードの差分、依存関係マップを保持し、マテリアルを復元してから、復元された信頼できるパスと選択された再帰ビューを確認します。すべての秘密が漏洩したとは想定せずに、実際の侵害に関係するキー、資格情報、またはポリシー エンドポイントを確認します。再発および未解決の暴露問題を監視するための所有権を割り当てます。
インシデントは、管理が制御され、意図した記録が提供され、依存するサービスが検証され、証拠の間隔が理解されるという明示的な基準に基づいてのみクローズされます。キャッシュされた回答とキューに入れられたメールは、目に見える修復が行われるまで存続する可能性があります。ここでは、元の承認と変更後の検索の証拠が欠落しているため、この教育的な説明は完全なハイジャック評価やドメインが安全であるという宣言ではありません。