문구 DMARC 우회는 매우 다른 이벤트를 설명할 수 있습니다. 과도하게 승인된 소스에서 유효한 패스, 실패한 결과에도 불구하고 전달 및 구현 오류는 동일한 실패가 아닙니다. 위조 가능한 주장으로 시작하십시오. 어떤 신원이 주장되었는지, 어떤 증거가 신뢰되었는지, 어떤 결정이 예상된 규칙과 달랐습니까?
관찰된 결정을 재구성
작성자 도메인, 봉투 도메인, 서명 도메인, 신뢰할 수 있는 인증 결과 및 수신자 배치를 보존합니다. 정책과 관찰 시간을 기록합니다. 전달되는 메시지 자체는 DMARC 통과를 증명하지 않습니다. 수신자 처리에는 로컬 정책이 포함되며 도메인 소유자가 요청한 처리는 보편적인 배달 보장이 아닙니다. RFC 9989.
마찬가지로 복사된 Authentication-Results 문자열은 수신 시스템의 결정을 증명하지 않습니다. 신뢰할 수 있는 인증 서비스 및 관련 홉을 설정합니다. RFC 8601. 유일한 증거가 합격을 알리는 스크린샷인 경우 기본 ID와 신뢰 컨텍스트를 사용할 수 있을 때까지 클레임을 해결되지 않은 상태로 유지하세요.
과도한 권한 부여와 규칙 회피를 분리하세요.
BreakSPF는 얼마나 허용적인지 연구합니다. SPF 공유 인프라에 대한 승인 및 접근이 허용될 수 있습니다. 스푸핑. 위협 모델은 공격자에게 적합한 소스 경로를 제공합니다. 그런 다음 수신자는 게시된 승인을 서면으로 평가할 수 있습니다. BreakSPF, 섹션 III.A 및 그림 3.
공격자가 제어하는 소스가 승인된 범위 내에 있고 정렬된 봉투 ID를 사용하는 경우 일반 통과 규칙이 성공할 수 있습니다. 약점은 DMARC 의 새로운 정의보다는 부여된 권한이나 서비스 경계에 있습니다. 반대로, 관련되지 않은 ID만 인증하고 작성자 도메인이 정렬되지 않은 경우 청구된 패스에 다른 설명이 필요합니다.
세 가지 가상 결과를 분류합니다.
하나의 가시적 From alerts@brand.test 와 적격한 DMARC 평가가 있다고 가정합니다. 이는 관찰된 사건이 아니라 서면 가설입니다.
- 승인 사례: 소스 192.0.2.99 는 규정된 SPF ip4:192.0.2.0/24 범위 내에 있습니다. 메일 보낸 사람 bounce@brand.test SPF 통과합니다. 아니요 DKIM 서명. 정렬된 SPF 경로는 메시지 수준 DMARC 패스를 생성합니다. 해당 소스가 의도하지 않은 발신자에 의해 실제로 제어 가능한지 여부와 해당 소스에 권한을 부여한 소유자가 누구인지 물어보세요.
- 처리 사례: MAIL FROM bounce@other.test 가 SPF 통과하고 DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed 조정 결과.
- 증거 사례: 복사된 헤더에 통과가 표시되지만 신뢰할 수 있는 수신자 원본, 평가된 ID 및 적용된 정책을 알 수 없습니다. 프로토콜 위반도, 신뢰할 수 있는 패스도 설정되지 않습니다. 원본 및 수신자측 기록을 요청합니다.
승인된 긍정적인 발신자 192.0.2.10 과 외부 소스 198.51.100.10 첫 번째 사례를 조사할 때 제안된 제어 기능을 제공할 수 있습니다. 가상의 ip4:192.0.2.10/32 -all 레코드는 전자만 허용합니다. 이 접두사 산술로 인해 실제 생산 변화가 발생하지 않습니다. 여기에는 실행된 파서, 서명 확인 또는 악용이 없습니다.
RFC9989 섹션 7.4에는 도메인 게시를 위한 유효한 DKIM 필요합니다. p=reject. 통과 정렬된 SPF 메커니즘은 특정 메시지의 통과 조건에 충분하지만 SPF 전용 적용에는 권장되지 않습니다.
결과를 실행 가능하게 만들기
재현된 상태와 아직 누락된 증거의 이름을 지정하세요. 유용한 조사 결과에 따르면 지정된 출처가 지정된 인증에 의해 허용되고 책임 있는 소유자를 식별합니다. 모든 DMARC 보호가 실패했다고 말하는 것은 아닙니다. 실제 서비스가 테넌트 ID를 제한하는지, 소스가 실제로 제어 가능한지, 수신자가 청구된 결과를 적용했는지 확인하세요.
제안된 완화를 테스트할 때 무해하고 승인된 양성 대조군을 보존하십시오. 범위를 좁히거나 커넥터를 변경하면 합법적인 발신자가 차단될 수 있습니다. 경로별 변경 승인 및 변경 후 확인을 요구하고, 랩에서 테스트되지 않은 공급자 동작을 명시적으로 해결되지 않은 상태로 유지합니다. 이는 교육 모델을 프로덕션 취약점으로 과장하지 않고 정확한 수정을 지원합니다.