평판이 좋은 도메인이나 공유 전송 서비스는 악성 메시지 경로의 일부가 될 수 있습니다. 유용한 질문은 인프라가 일반적으로 신뢰할 수 있는지 여부가 아닙니다. 이는 이 특정 메시지가 인증된 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. 따라서 성공적인 평가는 수신자가 통과 규칙을 무시하는 것이 아니라 너무 많은 권한이 부여되었음을 드러낼 수 있습니다.
세 가지 서면 승인 사례 비교
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에는 도메인 게시를 위해 유효한 DKIM 필요합니다. p=reject, 섹션 8은 완전한 참여를 다루고 있습니다. 이는 추가 메시지별 통과 게이트가 아닌 별도의 배포 임무입니다.
책임 경계를 고쳐라
실제 SPF 레코드 범위를 좁히기 전에 모든 합법적인 발신자를 조사하고 공급자가 지원하는 구성을 따르십시오. 전용 소스는 실제로 독점적이고 유지 관리되는 경우에만 유용합니다. 전송 서비스가 고객을 허용된 ID에 바인딩하는지 확인합니다. DKIM 구성을 확인하고 변경 제어를 통해 사용되지 않는 권한을 제거합니다.
변경 후 경로별 오류를 모니터링하고 복구 계획을 보존하며 알 수 없는 발신자를 문서화합니다. 이 예에서 광범위한 기록을 추측된 IP 목록으로 바꾸지 마십시오. 교훈은 데모 DNS 프로덕션에 복사하는 것이 아니라 실제 서비스 소유권과 승인을 조정하는 것입니다.