Received ヘッダーを下から上に読むことは、メッセージのルートをたどる方法としてよく教えられます。この順序は年代順を説明できますが、最も古いエントリを認証するものではありません。送信者は、最初の信頼できる受信者がメッセージを処理する前に、メッセージ内に作成されたトレース フィールドを配置できます。まずは、実証できる受け入れ境界線を見つけることから始めましょう。
トレースがどのように追加されるかを理解する
SMTPシステムは、メッセージが通過するときに受信したトレース情報を先頭に付加します。したがって、通常、最新のエントリが先頭に最も近くなります。フィールドには、受信システム、要求された送信ホスト、接続情報、プロトコル、キュー識別子、および時間を記録できます。すべての実装に同じオプションの詳細が含まれているわけではありません。 RFC 5321セクション 4.4.
信頼できる受信者によって観察された接続 IP は、クライアントが提供した IP とは異なる証拠です。 EHLO/ HELO名またはホスト名が下部ヘッダーにコピーされます。すべての名前を検証済みの物理ホップとして表示するのではなく、これらの区別を保持します。プライベート アドレスまたは内部ホスト名は、公的に解決できなくても、正当な内部セグメントを記述することができます。
まず信頼できるセグメントを確立する
最終受信システムから始めて、動作とログがわかっているシステムを逆方向に処理します。メッセージが境界の外側から入ってきたポイントを特定します。信頼できるフィールドのキュー識別子、接続レコード、およびタイムスタンプをサーバー ログと関連付けます。ゲートウェイがサードパーティによって運用されている場合は、最後の受信者が受け入れたからチェーン全体が信頼できると仮定するのではなく、そのゲートウェイからの承認された証拠を使用してください。
境界より下の古いフィールドは、確証がない限りクレームのままです。後で有効になります DKIM その結果、以前のすべてのネットワーク ホップが自動的に確立されるわけではありません。また、信頼できないトレース ラインにあるよく知られたドメインは、メッセージがその組織を通過したことを証明するものではありません。
仮想の 3 エントリーチェーンを再構築する
先頭の Received フィールドが 10:05 UTC に内部リレーを識別し、次のフィールドが 10:03 UTC に境界ゲートウェイを識別し、最も古いフィールドが 09:58 UTC に銀行ホストを主張しているとします。承認されたログは、2 つの内部処理イベントと境界で観察されたピア アドレスを裏付けます。銀行の主張を裏付ける証拠はありません。
サポートされているルートは、境界の監視対象ピアに戻り、その後停止します。見慣れた銀行名が提供されたテキストのままになります。内部タイムスタンプ間の 2 分の違いも、クロックの精度とキューのレコードがチェックされるまでの見かけ上の間隔にすぎません。それ自体はサーバーに遅延を割り当てません。
これらはフィールドとログの仮定であり、測定されたルートや実行されたパーサーではありません。実際のインシデントでは、最下位の行を発信元の証明にするのではなく、各ホップをサポートする証拠を保存し、不足しているレコードについて関連する管理者に問い合わせます。
タイミングは慎重に使おう
オリジナルを保持しながら、タイムスタンプを一貫したタイムゾーンに変換します。時計が間違っている可能性があり、信頼できないフィールドのタイムスタンプがでっち上げられる可能性があります。負の間隔または長いギャップは調査の手がかりであり、改ざんの証拠や遅延の正確な場所ではありません。キュー ログにより、待ち時間とクロックの不一致を区別できます。
最後に、各ホップに観察済み、裏付け済み、または主張済みとしてラベルを付けたルート図または短い順序付きリストを作成します。信頼できる最後の境界、説明されていないタイミング、およびそれを解決する追加情報源を特定します。明らかに発信元の IP を個人の身元や地理的確実性に変えないでください。
境界付きルートレコードを作成する
- 実証できる最終的な受信者から始めます。
- 各信頼できるホップをキューおよび接続レコードと照合します。
- 送信者が主張する名前を、観測されたピア アドレスとは別にしておいてください。
- 元のタイムゾーン値を保持し、遅延を割り当てる前にクロックの違いを調査します。
- 確証のない境界で停止してください。続行するために必要なログ ソースを特定します。