iPhone
Android
이메일 스푸핑은 악의적인 세력이 스팸/피싱 이메일이 정당하다고 믿게 만들기 위해 사용하는 기법 중 하나입니다. 간단히 말해, 이메일 스푸핑은 이러한 악성 행위자가 자신의 이메일이 은행, 좋아하는 제품, 또는 상사와 같은 신뢰할 수 있는 출처에서 온 것처럼 보이게 하기 위해 사용됩니다.
이메일 프로토콜은 정말 오랫동안 우리와 함께해왔습니다. 간단한 메일 전송 프로토콜 (SMTP)은 이메일 통신의 기본 프로토콜로 1981년에 만들어졌습니다. 인터넷은 많이 변화했지만, 불행히도 이메일은 그리 많이 변하지 않았습니다. 이메일이 만들어졌을 때는 오늘날 사용자 수의 일부에 불과했습니다. 그 당시에는 가짜 이메일을 보내는 것이 큰 해가 없었습니다. 이제 이메일은 우리가 생각할 수 있는 거의 모든 디지털 서비스에 사용되며, 기술은 천천히 따라잡고 있습니다.
모두가 같은 이해를 할 수 있도록 이메일이 어떻게 작동하는지 이야기해보겠습니다. 여기서 간단히 설명하자면, 누군가 이메일을 보낼 때의 과정은 대략 다음과 같습니다:
- Alice (hi@alice.com)가 Bob (hi@bob.com)에게 이메일을 씁니다.
- Alice는 이메일을 배달하기 위해 자신의 이메일 서버로 보냅니다.
- Alice의 이메일 서버는 Bob의 이메일 서버를 찾아 이메일을 전송합니다.
- Bob이 자신의 이메일 서버에 연결할 때마다 새로운 메시지를 요청하고, Bob의 받은 편지함에 새로운 이메일이 나타납니다.
간단하죠! 하지만 이메일을 보내는 과정에서 많은 일이 잘못될 수 있습니다. 이제 자세히 살펴보겠습니다!
발신자 정책 프레임워크 (SPF)
하지만 인터넷은 무서운 곳입니다. 악의적인 행위자, 즉 Chuck이 Bob을 속여 그의 Harvest 비밀번호를 보내게 하려 한다고 상상해보세요.
맞습니다, 일반 SMTP는 이메일을 보내는 사람이 자신이 주장하는 사람인지 알려주지 않습니다.
이런 종류의 공격으로부터 이메일을 보호하기 위해 발신자 정책 프레임워크 (SPF)를 사용할 수 있습니다. 이메일 서버가 새로운 이메일을 수신하면, 발신자 도메인에 그 발신자가 그들의 이름으로 이메일을 보낼 수 있는지 묻습니다. 이것이 SPF의 역할입니다; Bob의 이메일 서버가 alice.com에서 온 이메일을 수신하면, 먼저 alice.com에 진짜 발신자 chuck.com이 그들의 이름으로 무엇인가를 보낼 수 있는지 물어봅니다.
위 이미지에서 Bob의 서버가 DNS 요청을 수행하는 모습을 볼 수 있습니다. 이 기술과 이 블로그 포스트의 다른 모든 기술은 이 프로토콜을 기반으로 합니다. Bob의 이메일 서버가 alice.com에 정보를 요청하는 것은 특정 레코드를 찾기 위해 alice.com에 DNS 요청을 보내는 것을 의미합니다.
만약 alice.com이 chuck.com을 허용된 발신자 목록에 포함하지 않았다면, Bob의 이메일 서버는 스팸으로 태그할 수 있습니다. 맞습니다, 그럴 수도 있고 아닐 수도 있습니다. Bob의 서버가 항상 최종 결정을 내리며, 최종 결정을 내리기 전에 다른 검사를 수행해야 합니다.
도메인 키 식별 메일 (DKIM)
이제 이메일은 안전해야겠죠? 글쎄요... 완전히는 아닙니다. 우리는 Chuck이 자신의 서버에서 가짜 이메일을 보내는 것을 막았지만, 만약 그가 전송 중인 이메일을 가로채는 방법을 찾는다면 어떻게 될까요? 만약 그가 Alice의 메시지 내용을 변경할 수 있다면요? SPF는 발신자가 그녀의 이름으로 이메일을 보낼 수 있는지 확인할 뿐, 수신자에게 전달되는 과정에서 어떤 일이 발생하는지에 대해서는 아무것도 말하지 않습니다.
이것은 서명을 사용할 완벽한 시나리오입니다. 디지털 세계에서 서명은 전달되는 내용이 변경되지 않았음을 보장하고 확인하는 메커니즘입니다. Alice가 Bob에게 이메일을 보낼 때, 이제 Alice의 이메일 서버는 이메일 내용에 서명을 추가합니다. 만약 누군가 그 메시지의 단 하나의 비트라도 변경하면, Bob은 알게 됩니다. 게다가, Alice의 이메일 서버만이 이러한 서명을 생성하는 방법을 알고 있습니다. 다른 누구도 수신자가 알아차리지 않고는 이를 수행할 수 없습니다.
이것이 바로 도메인 키 식별 메일 (DKIM)의 역할입니다. 실제로 DKIM 구성은 Alice의 이메일 서버에서 시작됩니다:
- 보낸 이메일을 "인증 시작"하는 방법이 보통 있습니다. 이는 일반적으로 DKIM을 활성화하는 것을 의미합니다.
- 이메일 서버는 DNS에 몇 가지 암호화된 단어를 게시하도록 요청합니다; 그것이 바로 서명의 공개 키입니다. 쉽게 말해, 공개 키는 다른 사람들이 받은 서명이 유효하고 메시지가 전송 중에 수정되지 않았음을 확인할 수 있게 해줍니다. 서버는 개인 키를 보관하여 서명을 생성할 수 있는 유일한 존재가 됩니다.
- 공개 키가 게시되면 이메일 서버는 새로운 이메일마다 서명을 추가하기 시작합니다.
서명이 어떻게 유용할까요? Bob의 이메일 서버가 서명이 첨부된 이메일을 수신하면, 서명이 올바른지 검증할 수 있습니다. 이를 위해 서버는 공개 키와 이메일 내용을 검색해야 합니다. 이 두 가지 만으로도 서버는 원치 않는 수정이 있었는지 감지할 수 있습니다.
도메인 기반 메시지 인증 보고 및 준수 (DMARC)
이제 Bob은 이메일이 신뢰할 수 있는 출처에서 오고 있으며 변조되지 않았다는 것을 꽤 확신할 수 있겠죠? 그렇죠?... 그렇게 간단하면 좋겠네요... 우리의 악당 Chuck은 여전히 이메일의 내용을 수정하고 DKIM 서명을 없앨 수 있습니다. 어차피 누가 그게 필요하겠어요? 부정적인 검사를 받는 것보다 중립적인 검사를 받는 것이 더 낫습니다.
하지만 모든 것이 잃은 것은 아닙니다. 우리는 Bob의 이메일 서버에 어떤 보안 조치가 구성되었는지와 그 조치가 실패할 경우 어떻게 할지를 정의하는 정책을 알려줄 방법이 필요합니다. 마지막 약어를 살펴보겠습니다: 도메인 기반 메시지 인증, 보고 및 준수 (DMARC).
DMARC를 통해 Bob의 이메일 서버는 수신하는 이메일에 대해 무엇을 해야 하는지 정의하는 공개 정보 지점을 갖게 됩니다. 더 구체적으로, DMARC 레코드는 다음을 설명합니다:
- 수신 이메일에서 SPF 또는 DKIM이 시행되는지 여부
- 모니터링 목적을 위한 보고 이메일 주소
- 검사가 실패할 경우 어떻게 할지를 결정하는 정책. 세 가지 다른 정책이 있습니다:
- 정책 없음 - DMARC 검사 결과는 무시됩니다. 그러나 이메일 서버는 추가 분석을 위해 보고서를 보냅니다. 이는 DMARC를 구성하는 동안 예상대로 작동하는지 확인하기 위해 자주 사용됩니다.
- 격리 - DMARC 검사를 통과하지 못한 이메일은 수신자의 스팸 폴더로 전송됩니다.
- 거부 - DMARC 검사를 통과하지 못한 이메일은 수신자에게 도달하지 않습니다.
DMARC는 우리의 도구 상자에서 마지막 조각이며, 비준수 이메일을 폐기하라는 지시를 이메일 서버에 구체적으로 전달하는 유일한 것입니다. 그리고 어떤 상황에서 그렇게 되는지를 정의합니다.
결론
Harvest가 이러한 기술을 사용하여 이메일을 보호하고 있다는 사실을 기쁘게 생각합니다. 우리는 지금의 위치에 도달하기까지 몇 달 동안 학습하고 데이터를 수집했습니다. 우리는 다른 사람들이 우리를 사칭하고 Harvest의 명성을 훼손하는 것을 매우 어렵게 만들었습니다. 이는 고객에게 긍정적인 영향을 미칠 놀라운 성과입니다.
