DMARC 레코드를 올바르게 구성하면 여러 가지 이점을 얻을 수 있습니다. 도메인 소유자에게 이메일 전송 소스 및 성능에 대한 풍부한 정보를 제공하는 이메일 보안의 새로운 영역입니다. DMARC 취약점은 사용자가 프로토콜을 구현하거나 적용하는 과정에서 발생하는 매우 일반적인 오류를 말합니다.
이메일 인증 시스템의 취약점은 잘못된 구문과 같은 단순한 오류부터 더 복잡한 오류까지 다양합니다. 어느 쪽이든 이러한 문제를 해결하고 프로토콜을 올바르게 설정하지 않으면 이메일 보안 노력이 무효화될 수 있습니다.
이메일 인증 과정에서 발생할 수 있는 취약점을 분석하기 전에 몇 가지 기본 개념을 간단히 살펴보겠습니다. 맞습니다:
- 이메일 인증이란 무엇인가요?
- DMARC는 이메일을 어떻게 인증하나요?
- DMARC 취약점이 메시지 전달 가능성에 미치는 영향
이메일 인증이란 무엇인가요?
사이버 범죄자는 이메일 통신을 가로채거나 사회 공학을 사용하여 의심하지 않는 피해자를 속여 금전적 이득을 취할 수 있습니다.
이메일 인증은 도메인 소유자가 도메인에서 보낸 이메일의 적법성을 확인하기 위해 구성할 수 있는 특정 확인 시스템을 말합니다. 이는 메시지 본문에 디지털 서명, 반환 경로 주소 확인 및/또는 식별자 정렬을 통해 수행할 수 있습니다.
인증 확인을 통해 메시지의 적법성이 확인되면 이메일이 수신자의 받은 편지함으로 전송됩니다.
DMARC는 이메일을 어떻게 인증하나요?
회사에서 사용자에게 메시지를 보내면 이메일은 발신 서버에서 수신 서버로 이동하여 전달 여정을 완료합니다. 이 이메일에는 보낸 사람 : 헤더 (이메일이 전송된 이메일 주소를 표시하는 표시 헤더)와 반환 경로 헤더( 반환 경로 주소를 포함하는 숨겨진 헤더입니다.
공격자는 회사 도메인을 스푸핑하여 동일한 도메인 이름으로 이메일을 보낼 수 있지만, 반환 경로 주소를 마스킹하는 것은 훨씬 더 어렵습니다.
이 의심스러운 이메일을 살펴보겠습니다:
메시지와 연결된 이메일 주소는 dereksmith@company.com 에서 온 것처럼 보이지만, 반송 경로 주소를 검사하면 반송 주소가 회사 주소인 company.com 과 전혀 관련이 없으며 알 수 없는 도메인에서 전송된 것임을 빠르게 확인할 수 있습니다.
이 반송 주소(일명 리턴 경로 주소)는 이메일 수신 서버에서 발신자의 SPF 레코드를 조회하는 데 사용됩니다. 발신자의 DNS에 전송된 이메일의 IP와 일치하는 IP 주소가 포함되어 있으면 SPF 및 후속 DMARC가 통과하고, 그렇지 않으면 실패합니다. 이제 보내는 도메인에서 구성한 DMARC 정책에 따라 메시지가 거부, 격리 또는 배달될 수 있습니다.
또는 DMARC는 다음을 확인할 수도 있습니다. DKIM 식별자 정렬을 확인하여 이메일의 진위 여부를 확인할 수도 있습니다.
DMARC 취약점이 메시지 전달 가능성에 미치는 영향
메시지가 고객에게 전달될 확률은 프로토콜을 얼마나 정확하게 구성했는지에 따라 크게 달라집니다. 조직의 이메일 보안 태세에 기존 취약점이 있으면 메시지가 전달될 가능성이 약해질 수 있습니다.
DMARC 인증 시스템에 허점이 있다는 확실한 징후는 다음과 같습니다:
- 이메일 전송률 문제
- 정상적인 메시지가 스팸으로 표시되는 경우
- 온라인 도구 사용 중 DMARC 오류 프롬프트
DMARC 취약점의 유형
DMARC 취약점 #1: DNS 레코드의 구문 오류
DMARC 레코드는 세미콜론으로 구분된 메커니즘이 있는 TXT 레코드로, 이메일 수신 MTA에 대한 특정 지침을 지정합니다. 아래는 그 예시입니다:
v=DMARC1; p=reject; rua=mailto:reports@domain.com; pct=100;
메커니즘 구분 기호(;)와 같은 작은 세부 사항은 기록이 유효한지 여부를 결정하는 데 중요한 역할을 하므로 간과해서는 안 됩니다. 그렇기 때문에 추측을 하지 않으려면 무료로 제공되는 DMARC 레코드 생성기 도구를 사용하여 도메인에 대한 정확한 TXT 레코드를 생성하는 것이 좋습니다.
DMARC 취약점 #2: DMARC 레코드가 발견되지 않음 / DMARC 레코드 누락 취약점
도메인 소유자는 온라인 도구를 사용하는 동안 도메인에 DMARC 레코드가 누락되었다는 메시지를 자주 접할 수 있습니다. DNS에 유효한 레코드가 게시되어 있지 않은 경우 이 메시지가 표시될 수 있습니다.
DMARC는 피싱 및 직접 도메인 스푸핑을 비롯한 다양한 공격으로부터 도메인과 조직을 보호하는 데 도움이 됩니다. 모든 단계에서 이메일 통신을 가로채려는 위협 행위자가 있는 디지털 세상에 살고 있는 우리는 이러한 공격을 막기 위해 주의를 기울이고 예방 조치를 구현해야 합니다. DMARC는 이러한 과정을 지원하여 보다 안전한 이메일 환경을 조성합니다.
이 문제를 해결하는 방법에 대한 자세한 내용은 DMARC 레코드가 발견되지 않음 취약점을 수정하는 방법에 대한 자세한 기사를 다루었습니다.
DMARC 취약점 #3: 정책 없음: 모니터링만
사용자들이 흔히 오해하는 것은 DMARC 정책을 p=none으로 설정해도 공격으로부터 도메인을 보호할 수 있다고 생각하는 것입니다. 실제로는 강제적인 거부/격리 정책만이 스푸핑에 대한 방어 체계를 구축하는 데 도움이 될 수 있습니다.
그러나 보호 기능을 적용하지 않고 이메일 채널만 모니터링하려는 경우에는 느슨한 정책을 사용하는 것이 효과적일 수 있습니다. 그러나 확신이 들면 p=거부로 빠르게 전환하는 것이 좋습니다.
대부분의 사용자가 공격으로부터 더 높은 수준의 보호를 받기 위해 DMARC를 구현한다는 기준에 따라 이 취약점을 DMARC 취약점 범주에 포함시켰습니다. 따라서 적용이 전혀 없는 정책은 아무런 가치가 없을 수 있습니다.
DMARC 취약점 #4: DMARC 정책이 활성화되지 않음
이전 취약점과 마찬가지로 이 오류 메시지는 종종 DMARC에 대한 정책이 적용되지 않았기 때문에 발생할 수 있습니다. 도메인을 없음 정책으로 설정하여 피싱 공격에 취약한 경우 가능한 한 빨리 p=거부/검역으로 전환하는 것이 좋습니다. 이렇게 하려면 기존 DNS 레코드를 약간만 조정하여 정책 모드를 수정하고 업그레이드하면 됩니다.
이 문제를 해결하는 방법에 대한 자세한 문서가 있습니다. DMARC 정책을 사용할 수 없습니다. 링크를 클릭하여 확인할 수 있습니다.
실시간으로 DMARC 취약점 문제 해결
이러한 문제를 해결하려면 조직에서 다음 단계를 구현하는 것을 고려할 수 있습니다:
- 모든 승인된 이메일 전송 소스의 목록을 작성하고 매일 또는 수시로 추적하도록 DMARC 모니터링 도구를 구성하세요.
- 이메일 공급업체와 논의하여 이메일 인증 관행을 지원하는지 여부를 입증하세요.
- 다음 단계로 넘어가기 전에 SPF, DKIM 및 DMARC에 대해 자세히 알아보세요.
- SPF 기록에 다음이 없는지 확인하세요. SPF Permerror 가 없는지 확인합니다.
- 무료 DMARC 분석기에 등록하여 DMARC 전문가의 전문적인 인사이트와 가이드를 통해 프로토콜 구현 프로세스를 원활하게 진행하세요. 무료 DMARC 분석기. 실시간 취약성 및 공격 탐지를 통해 안전하게 p=거부로 전환하는 데 도움이 될 수 있습니다.
도메인을 보호하는 것은 평판을 유지하고 신뢰성을 유지하기 위한 기본 단계 중 하나입니다. 지금 바로 이메일 보안을 보안 태세의 일부로 삼으세요!
- SPF 허용 오류 수정: SPF 너무 많은 DNS 조회 제한 극복하기 - 2024년 4월 26일
- DMARC 레코드를 3단계로 게시하는 방법은 무엇인가요? - 2024년 4월 2일
- DMARC가 실패하는 이유는 무엇인가요? 2024년 DMARC 장애 수정하기 - 2024년 4월 2일