Cloudflare는 오늘 이메일 스푸핑 및 피싱에 맞서면서 이메일의 전달성을 개선하기 위한 새로운 도구를 선보입니다. 사용자는 새로운 _Email Security DNS Wizard_를 통해 다른 사람이 자신의 이름으로 악의적 이메일을 보내지 못하도록 방지하는 DNS 레코드를 작성할 수 있게 됩니다. 또한 이러한 새로운 기능에는 도메인 상의 안전하지 않은 구성에 대해 경고하고 해결 방법을 제안하는 내용이 포함됩니다. 이 기능은 Free 요금제를 이용하는 사용자에게 처음 제공되며 향후 몇 주에 걸쳐 Pro, Business, Enterprise 고객에게도 제공될 것입니다.
이 마법사가 어떠한 마법을 부릴 수 있는지 자세히 알아보기 전에 먼저 한 걸음 물러서서 이메일 스푸핑과 피싱이라고 하는 문제가 무엇인지 알아보겠습니다.
이메일 스푸핑과 피싱이란?
스푸핑이란 불법적인 이익을 취하려고 다른 사람처럼 위장하는 과정을 말합니다. 한 가지 예로 도메인 스푸핑의 경우에는 누군가가 mycoolwebpaqe.xyz 같은 웹 사이트를 호스팅함으로써 mycoolwebpage.xyz의 사용자가 잘못된 웹 사이트에 도달한 것을 모르고 중요한 정보를 제공하게 만듭니다.
이메일 스푸핑도 있습니다. 이메일 스푸핑이 어떻게 작동하는지 이해를 돕기 위해 제가 개인 이메일 주소로 받은 Cloudflare 제품 업데이트 이메일을 살펴보겠습니다. 대부분의 이메일 공급자와 마찬가지로 이메일 전체 소스를 보면 다수의 헤더가 있고 이메일 본문이 있습니다.
위의 이메일에는 수신한 시각, 발신자, 답신을 받을 사람, 내 개인 이메일 주소 등 네 가지 헤더가 있습니다. From 헤더의 값은 내 이메일 프로그램에서 발신자를 표시하기 위해 이용됩니다.
Date: Thu, 23 Sep 2021 10:30:02 -0500 (CDT)
From: Cloudflare <[email protected]>
Reply-To: [email protected]
To: <my_personal_email_address>위와 같은 이메일을 받게 되면 저는 자동으로 이 이메일을 Cloudflare가 보냈다고 가정합니다. 하지만 누구라도 자기 메일 서버에서 From 헤더를 수정해서 이메일을 보낼 수 있습니다. 이 블로그 게시물의 뒤에서 살펴볼 적절한 검사를 이메일 공급자가 수행하지 않는다면 실제 발신자가 Cloudflare가 아닌데도 Cloudflare라고 믿게 될 수 있습니다.
이제 두 번째 공격 유형인 피싱을 살펴보겠습니다. 악의적인 행위자가 이메일 스푸핑을 성공적으로 이용해 귀사의 고객에게 귀사의 기업 서비스 이메일인 것처럼 보이는 이메일을 발송한다고 가정하겠습니다. 이 이메일의 내용은 귀사에서 보낸 것과 동일한 스타일 및 형식을 이용하여 합법적인 이메일처럼 보입니다. 이메일 내용은 계정 정보 일부를 변경하라는 긴급 메시지일 수 있으며 웹 포털이라고 주장하는 하이퍼링크가 포함되기도 합니다. 사용자의 메일 서버가 이러한 이메일에 스팸이나 안전하지 않은 이메일이라고 플래그를 붙이지 않는다면, 사용자는 링크를 클릭할 수 있으며 이를 통해 악의적인 소프트웨어가 실행되거나 중요한 정보를 요구하는 스푸핑된 도메인으로 연결될 수 있습니다.
FBI의 2020 인터넷 범죄 보고서에 따르면 피싱은 2020년에 가장 널리 쓰인 사이버 범죄로서 24만 명 이상이 피해를 입었으며 손실액은 5천만 달러 이상에 달했습니다. 2019년 이후 피해자는 두 배 이상으로 늘었고 2018년에 비해서는 거의 10배에 달했습니다.
대부분의 피싱 공격이 수행되는 방식을 이해하기 위해 2020 Verizon 데이터 유출 조사 보고서의 내용을 자세히 살펴보기로 하겠습니다. 이 보고서에서는 소셜 엔지니어링 공격의 다른 이름인 "소셜 활동"의 80% 이상이 피싱 공격으로 이러한 공격 중 가장 많이 사용된다고 합니다. 또한 이 보고서에 따르면 96%의 소셜 활동이 이메일을 통해 발송되며 웹 사이트는 3%, 전화 또는 문자는 1%에 불과했습니다.
따라서 이메일 피싱은 인터넷 사용자들을 괴롭히는 심각한 문제임을 알 수 있습니다. 그러면 악의적 행위자들이 이메일 피싱에 도메인을 남용하지 않도록 하기 위해 도메인 소유자들이 취할 수 있는 조치를 알아보기로 하겠습니다.
DNS로 이를 방지하는 방식
다행히 도메인 네임 시스템(DNS)에는 스푸핑을 방지하기 위한 메커니즘이 세 가지 구축되어 있습니다.
발신자 정책 프레임워크(SPF: Sender Policy Framework)
DKIM(DomainKeys Identified Mail)
도메인 기반 메시지 인증 보고 및 일치(DMARC: Domain-based Message Authentication Reporting and Conformance)
하지만 이를 적절히 구성하기는 쉽지 않습니다. 특히 경험이 부족한 경우에는 더욱 어렵습니다. 구성이 너무 엄격하다면 합법적인 이메일이 전달되지 않거나 스팸으로 표시될 것입니다. 구성이 너무 헐겁다면 해당 도메인이 이메일 스푸핑에 남용될 수 있습니다.
발신자 정책 프레임워크(SPF: Sender Policy Framework)
SPF는 해당 도메인에서 이메일을 보낼 수 있도록 승인된 IP 주소와 도메인의 목록을 지정합니다. SPF 정책은 도메인의 TXT 레코드로 발표되므로 누구나 DNS를 통해 액세스할 수 있습니다. cloudflare.com의 TXT 레코드를 살펴보겠습니다.
SPF TXT 레코드는 언제나 v=spf1로 시작해야 합니다. 여기에는 ip4 또는 ip6 메커니즘을 이용해 이메일을 발송하는 서버의 IP 주소 목록이 포함되는 경우가 많습니다. include 메커니즘은 다른 도메인에 있는 다른 SPF를 참조하기 위해 이용합니다. 이는 주로 귀사를 대신해 이메일을 보내야 하는 다른 공급자에 의존하는 경우에 이뤄집니다. 위의 cloudflare.com에 대한 SPF 레코드에서 몇 가지 예를 볼 수 있습니다. 여기에서는 Zendesk를 고객 지원 소프트웨어로, Mandrill을 마케팅 및 거래 이메일에 이용하고 있습니다.
cloudflare.com TXT "v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"마지막으로 catch-all 메커니즘인 -all은 지정되지 않은 모든 수신 이메일을 어떻게 처리해야 할지 지정합니다. catch-all 메커니즘 앞에는 +(Allow), ~(Softfail), -(Fail) 등의 한정자가 붙습니다. Allow 한정자는 SPF 레코드를 쓸모없게 만들고 모든 IP 주소와 도메인이 귀사를 대신해 이메일을 보낼 수 있으므로 사용하지 않는 것이 좋습니다. Softfail은 수신 메일 서버에 따라 다르게 해석되며 이메일을 스팸이나 안전하지 않은 것으로 분류합니다. Fail은 지정되지 않은 소스에서 온 이메일은 전혀 수락하지 말라고 말합니다.
위 그림에는 수신된 이메일이 SPF를 준수하는지 확인하는 절차가 표시되어 있습니다.
IP 주소 203.0.113.10에서 이메일을 보내는데, From 헤더 값은 [email protected]입니다.
수신자는 이메일을 받으면 해당 도메인의 SPF 정책을 얻기 위해 mycoolwebpage.xyz에 SPF 레코드를 쿼리합니다.
수신자는 보내는 IP 주소 203.0.113.10이 SPF 레코드에 포함되어 있는지 검사합니다. 포함되어 있다면 해당 이메일은 SPF 검사를 통과한 것입니다. 포함되어 있지 않다면 all 메커니즘의 한정자에 따라 결과가 결정됩니다.
전체 메커니즘의 목록과 SPF에 대한 자세한 내용은 RFC7208를 참조하시기 바랍니다.
DKIM (DomainKeys Identified Mail)
이제 SPF를 이용해 허가된 IP 주소 및 도메인만이 cloudflare.com을 대신해 이메일을 보낼 수 있도록 보장했습니다. 하지만 IP 중 하나의 소유자가 변경되었는데 Cloudflare가 알지 못하고 있거나 SPF 레코드가 업데이트되지 않았다면 어떻게 될까요? 또는 동일한 IP에서 Google의 이메일 서버도 이용하는 사람이 cloudflare.com에서 오는 이메일을 스푸핑하려고 한다면 어떻게 될까요?
여기에 DKIM의 역할이 있습니다. DKIM은 공개 키 암호화를 이용해 이메일의 특정 부분(대개는 본문 및 특정 헤더)에 암호로 서명하는 메커니즘을 제공합니다. 작동 방식을 자세히 살펴보기 전에 cloudflare.com에 사용되는 DKIM 레코드를 살펴보겠습니다.
DKIM 레코드의 구조는 ._domainkey.이며 여기에서 selector는 이메일 공급자가 제공합니다. DKIM TXT 레코드의 내용은 항상 v=DKIM1으로 시작하며 공개 키가 이어집니다. k 태그를 이용해 참조되는 공개 키 유형과 p 태그 뒤에 이어지는 공개 키 자체를 볼 수 있습니다.
google._domainkey.cloudflare.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMxbNxA2V84XMpZgzMgHHey3TQFvHkwlPF2a11Ex6PGD71Sp8elVMMCdZhPYqDlzbehg9aWVwPz0+n3oRD73o+JXoSswgUXPV82O8s8dGny/BAJklo0+y+Bh2Op4YPGhClT6mRO2i5Qiqo4vPCuc6GB34Fyx7yhreDNKY9BNMUtQIDAQAB"다음은 서명과 DKIM 검사가 작동하는 단계를 간략하게 설명한 것입니다.
발신하는 이메일 서버가 이메일 콘텐츠로부터 해시를 생성합니다.
발신 이메일 서버가 비공개 DKIM 키로 이 해시를 암호화합니다.
암호화된 해시가 포함된 이메일이 발송됩니다.
수신 이메일 서버가 이메일 도메인에 게시된 DKIM TXT 레코드에서 공개 키를 추출합니다.
수신 이메일 서버가 공개 DKIM 키를 이용해 해시를 해독합니다.
수신 이메일 서버가 이메일 콘텐츠로부터 해시를 생성합니다.
해독된 해시와 생성된 해시가 일치하면 이메일이 진짜임이 입증됩니다. 그렇지 않다면, DKIM 검사가 실패합니다.
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
t=1632416903; s=m1; d=cloudflare.com; [email protected];
h=Content-Type:MIME-Version:Subject:To:From:Date;
bh=uMixy0BsCqhbru4fqPZQdeZY5Pq865sNAnOAxNgUS0s=;
b=LiIvJeRyqMo0gngiCygwpiKphJjYezb5kXBKCNj8DqRVcCk7obK6OUg4o+EufEbB
tRYQfQhgIkx5m70IqA6dP+DBZUcsJyS9C+vm2xRK7qyHi2hUFpYS5pkeiNVoQk/Wk4w
ZG4tu/g+OA49mS7VX+64FXr79MPwOMRRmJ3lNwJU=DKIM 지정에 대한 전체적인 설명은 RFC4871과 RFC5672을 참조하시기 바랍니다.
도메인 기반 메시지 인증 보고 및 일치(DMARC: Domain-based Message Authentication Reporting and Conformance)
도메인 기반 메시지 인증 보고 및 일치라는 말은 길고 복잡합니다. 중요한 것은 _보고_와 _일치_이며 DMARC는 바로 이 기능을 제공합니다. 이메일 발신자는 정규 보고서를 통해 얼마나 많은 이메일이 일치하지 않아 스푸핑되었을 가능성이 있는지 알 수 있습니다. 일치는 이메일 수신자에게 일치하는 않는 이메일을 어떻게 처리해야 할지 명확한 신호를 제공합니다. 이메일 수신자는 DMARC 레코드가 없이도 SPF나 DKIM 검사를 통과하지 못한 이메일에 대해 자체적인 정책을 설정할 수 있습니다. 하지만 DMARC 레코드는 이메일 발신자가 보낸 명시적 지침이므로 일치하지 않는 이메일을 어떻게 처리할지에 대해 이메일 수신자의 확신 정도가 높아집니다.
다음은 cloudflare.com의 DMARC 레코드입니다.
DMARC TXT 레코드는 항상 이메일 도메인의 _dmarc 하위 도메인에서 설정되며 SPF 및 DKIM과 마찬가지로 내용은 v=DMARC1로 시작됩니다. 또한 세 가지 태그가 추가됩니다.
정책 태그(p)는 이메일 수신자가 SPF 또는 DKIM 검사를 통과하지 못한 이메일을 어떻게 처리해야 하는지 지시하며, none, reject, quarantine 중 하나의 값을 갖습니다. none 정책은 '모니터링만 시행'이라고도 하며 검사를 통과하지 못한 이메일도 수락합니다. quarantine을 지정하면 이메일 수신자는 SPF 또는 DKIM을 통과하지 못한 이메일을 스팸 폴더에 넣습니다. reject의 경우에는 SPF나 DKIM을 통과하지 못한 이메일을 누락시키며 전달하지 않습니다.
백분율 태그(pct)를 이용하면 지정된 정책을 수신 이메일의 부분 집합에만 적용합니다. 이는 DMARC 적용을 확대하면서 일부 부분 집합에 대해 테스트하여 적절히 구성되었는지 확인하고자 할 때 유용합니다.
_dmarc.cloudflare.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"위 레코드에서 볼 수 있는 마지막 태그는 보고 URI(rua)로서, 일치하지 않는 이메일에 대해 총합 보고서(대개는 일간)를 수신할 이메일 주소를 지정하는 것입니다.
위에 DMARC의 단계별 작동 방식이 표시되어 있습니다.
From 헤더에 [email protected]가 포함된 이메일이 발송됩니다.
수신자는 필요 정책과 DKIM 공개 키를 얻기 위해 mycoolwebpage.xyz 도메인에 SPF, DKIM, DMARC 레코드를 쿼리합니다.
수신자는 위에서 설명된 것처럼 SPF 및 DKIM 검사를 수행합니다. 두 검사 모두 통과하면 이메일을 수락하고 수신함으로 전달합니다. SPF와 DKIM 중 하나를 통과하지 못하면 DMARC 정책을 따라 해당 이메일을 그래도 수락할지, 수락하지 않을지, 스팸 폴더로 전달할지 결정합니다.
마지막으로 수신자는 총합 보고서를 돌려 보냅니다. 이 보고서의 rua 태그에 지정된 이메일에 따라 이 보고서는 해당 이메일 주소를 담당하는 다른 이메일 서버로도 발송될 수 있습니다.
옵션 사항인 다른 태그 및 DMARC에 대한 전체적인 설명은 RFC7489를 참조하시기 바랍니다.
채택에 대한 통계
이제 문제가 무엇이고 SPF, DKIM, DMARC로 이를 해결하는 방법도 알았으니 이들이 얼마나 널리 채택되고 있는지 알아보겠습니다.
Dmarc.org은 대표적인 데이터 세트에서 도메인들의 DMARC 레코드 채택 통계를 발표합니다. 결과를 보면 2020년 말 현재 아직 DMARC 레코드를 갖고 있는 도메인은 50%에 미치지 못합니다. 다시 말씀드리지만, DMARC 레코드가 없다면 SPF와 DKIM 검사를 강제화하지 못합니다. 또한 연구 결과에 따르면 DMARC 레코드를 갖고 있는 도메인 중 65%가 '모니터링만 시행'하는 정책(p=none)을 사용하고 있어 이 채택률을 높일 가능성이 큽니다. 연구에서는 이러한 도메인이 이메일을 발신하는지 수신하는지 언급하고 있지 않지만, 그렇지 않다고 해도 안전한 구성에는 DMARC 레코드가 포함되어야 합니다(여기에 대해서는 추후 다시 살펴보겠습니다).
2021년 8월 1일에 발표된 또 다른 보고서에서도 은행 부문의 조직에 속하는 도메인에 대해 유사한 결과를 제시합니다. 미국 내 2,881개의 은행 조직 중에 44%만이 도메인에 DMARC 레코드를 게시하고 있습니다. DMARC 레코드가 있는 조직 중에는 5개 중 2개가 DMARC 정책을 'None'으로 설정하고 있으며 이외의 8%는 '구성을 잘못'한 것으로 간주됩니다. 덴마크는 은행 부분의 DMARC 채택률이 94%에 이를 정도로 높은 반면, 일본의 경우는 도메인 중 13%만이 DMARC를 이용하고 있습니다. SPF 채택은 평균적으로 DMARC보다 현저하게 높으며 이는 SPF 표준이 2006년에 실험적 RFC로 처음 소개되었고 DMARC는 2015년에야 표준이 된 사실과 관계 있는 것으로 보입니다.
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:12px;overflow:hidden;padding:10px 10px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:12px;font-weight:normal;overflow:hidden;padding:10px 10px;word-break:normal;} .tg .tg-2bn0{font-size:22px;text-align:center;vertical-align:top} .tg .tg-auka{font-size:22px;text-align:left;vertical-align:top} .tg .tg-ozhh{font-size:22px;font-weight:bold;text-align:center;vertical-align:top}
국가
조직 수
| Country | Number of entities | SPF present | DMARC present |
|---|---|---|---|
| Denmark | 53 | 91% | 94% |
| UK | 83 | 88% | 76% |
| Canada | 24 | 96% | 67% |
| USA | 2,881 | 91% | 44% |
| Germany | 39 | 74% | 36% |
| Japan | 90 | 82% | 13% |
SPF 채택
DMARC 채택
덴마크
53
91%
94%
영국
83
88%
76%
example.com TXT "v=spf1 -all"
*._domainkey.example.com. TXT "v=DKIM1; p="
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;"캐나다
24
96%
67%
USA
2,881
91%
44%
독일
39
74%
36%
일본
90
82%
13%
따라서 개선의 여지가 꽤 있음을 알 수 있습니다.
새로 도입: Email Security DNS Wizard
그렇다면 SPF, DKIM, DMARC의 채택을 늘리고 이메일 스푸핑과 피싱에 맞서 싸우려면 무엇을 하고 있을까요? 새로운 Cloudflare _Email Security DNS Wizard_를 시작합니다.
오늘부터 Cloudflare Dashboard의 DNS 탭으로 이동하면 두 가지 새로운 기능이 표시될 것입니다.
Email Security이라는 새로운 섹션
안전하지 않은 구성에 대한 새로운 경고
_Email Security DNS Wizard_를 사용하기 시작하려면 경고의 링크를 직접 클릭하여 마법사의 해당 섹션으로 이동하거나 새로운 Email Security 섹션에서 구성을 클릭하면 됩니다. Email Security 섹션에는 다음의 옵션이 제시됩니다.
두 가지 시나리오가 있습니다. 즉 귀사의 도메인을 이용해 이메일을 보내거나 보내지 않는 것입니다. 이메일을 보내는 경우라면 간단한 몇 단계를 거쳐 SPF, DKIM, DMARC 레코드를 구성할 수 있습니다. 여기에서 SPF에 대한 절차를 볼 수 있습니다.
귀사의 도메인이 이메일을 보내지 않는 경우라면 한 번의 클릭으로 세 가지 레코드를 모두 구성하는 쉬운 방법이 있습니다.
제출을 클릭하면 모든 이메일이 검사를 통과하지 못하고 수신 이메일 서버에 의해 거부되도록 구성된 세 개의 레코드가 생성됩니다.
이메일 스푸핑 및 피싱에 맞서 싸우기 지원
귀사의 도메인이 이메일 스푸핑과 피싱으로부터 보호될 수 있도록 하시기 바랍니다. Cloudflare Dashboard의 DNS 탭으로 이동하면 되며, 아직 Cloudflare DNS를 이용하지 않고 있다면 cloudflare.com에서 바로 무료로 가입할 수 있습니다.
SPF, DKIM, DMARC에 대해 자세한 내용을 보고 싶으시면 이메일 관련 DNS 레코드에 대한 새로운 학습 페이지를 참고하시기 바랍니다.