2020.01.13

파킹된 도메인의 "이메일 스푸핑"을 방지해야 하는 이유와 방법

J.M. Porup | CSO
이메일 스푸핑(email spoofing)을 차단하려면 생각할 것도 없이 도메인 기반의 메시지 인증, 보고 및 확인(Domain-based Message Authentication, Reporting and Conformance, DMARC)를 사용해야 한다(이메일 스푸핑이란 이메일 발송 시 발신자의 주소를 위조하는 것을 말한다. 편집자 주).  

피싱 공격이나 기업 이메일 침해(Business Email Compromise, BEC)로 이어지는 @yourdomain.com의 스푸핑된 이메일을 반기는 사람은 없다. 그런데, 소유는 하고 있지만 이메일을 보내거나 받지는 않는 도메인, 즉 파킹된 도메인(parked domains)에도 DMARC를 구현했는가?  

이런 경우를 생각해보자. acmecorp.com을 운영하면서 acnecorp.com도 함께 소유하고 있다. 여드름과 상관은 없지만 타이포스쿼팅(typosquatting)을 방지하기 위해 구입한 도메인이다. 또한 피싱이나 위장에 대비한 저렴한 보험도 된다. acmecorp.com에 DMARC를 구축하면 IAmTheCEO@acmecorp.com과 같은 스푸핑된 이메일은 바로 잡힌다. 그런데 acnecorp.com의 스푸핑된 이메일은 어떨까? 이제 뭐가 문제인지 보일 것이다.

이런 유형의 공격을 막기 위한 최선의 방법은 “이 도메인은 절대 이메일에 사용되지 않으므로 이 도메인에서 오는 이메일을 받는다면 가짜 이메일입니다”라는 의미의 DMARC 레코드를 게시하는 것이다.


파킹된 도메인의 이메일을 끄는 방법

언뜻 이해가 되지 않을 수도 있다. 발송되는 이메일에 암호화된 서명을 할 일이 없다면 DNS에 DKIM(DomainKeys Identified Mail) 레코드를 게시할 이유가 무엇인가? 

도메인에서 이메일을 보낼 일이 없는데 메일서버등록제(Sender Policy Framework, SPF) 레코드를 게시할 이유가 무엇인가? 이유는 해킹이다. 우리는 40년째 이메일 보안을 구축하기 위해 노력하는 중인데, 아직도 제대로 못하고 있다.

DMARC 레코드와 널(null) 메일 익스체인저(MX) 레코드의 조합은 사기꾼이 자사의 도메인을 사용해 스푸핑된 메일을 보내지 못하도록 차단하는 최선의 방책이다. 이보다 더 깊이 들어가고 싶다면? 안티스팸 워킹 그룹인 M3AAWG(Messaging Malware Mobile Anti-Abuse Working Group)이 2015년 12월에 발표한 “M3AAWG 사용중인 도메인 보호를 위한 최선의 방법(Protecting Parked Domains Best Common Practices)”이라는 제목의 문서에서 파킹된 도메인의 이메일을 보호하기 위한 충실한 가이드를 볼 수 있다. 

- 파킹된 도메인을 위한 SPF
SPF는 사기꾼이 소유하지 않은 도메인에서 이메일을 보내지 못하도록 차단한다. 도메인 관리자가 해당 도메인을 대신해 이메일을 보낼 수 있는 호스트를 공개하는 DNS TXT 레코드를 게시하기 때문이다. 이메일 서비스 제공업체는 이메일을 수신한 다음 DNS 항목을 보고 해당 호스트가 승인된 호스트인지 여부를 확인한다.

"이 도메인을 대신해 이메일을 보내도록 허용된 호스트는 절대 없다!"고 적힌 SPF 레코드를 게시하면 대부분의 이메일 서비스 제공업체는 그 이메일을 스팸으로 처리한다.

이메일 스푸핑을 차단하도록 파킹된 도메인의 SPF를 올바르게 구성하는 방법은 다음과 비슷하다.

```
example.com. TXT "v=spf1 -all"
```


이게 무슨 뜻일까? example.com 도메인에서 “-all”은 SPF를 엄격하게 적용한다. "include:example.com"이 없다는 것은 이 메일을 보낼 수 있는 합법적인 도메인이 없다는 의미다.

이 분야에서 권위있는 기관은 파킹된 도메인 SPF 레코드에서 다음과 같이 하위 도메인도 차단해 @spam.example.com과 @phishing.example.com의 이메일 스푸핑을 차단할 것을 권장한다.

```
*.example.com. TXT “v=spf1 -all”
```


- 파킹된 도메인의 DKIM
대부분의 이메일 제공업체는 DKIM을 활성화한다. DKIM에서 이메일 서버는 비공개 키를 사용해 발신 이메일을 암호화 서명하고, 이 비공개 키와 짝을 이루는 공개 키는 도메인의 도메인 네임 시스템(DNS)에 게시된다. DKIM은 수신 이메일 서버에서 수신되는 이메일의 출처가 이메일에 명시된 출처와 일치하며 메시지가 전송 과정에서 수정되지 않았음을 알 수 있게 해준다.

이것이 파킹된 도메인에서 원치 않는 스푸핑된 이메일을 방지하는 데 어떻게 도움이 될까? DKIM을 관장하는 RFC 6376은 공개 키에 대한 빈 값(“p=”)이 “이 공개 키는 폐지되었음”을 의미한다고 규정한다. 즉, 이 도메인에 대한 유효한 DKIM이 존재하지 않는다는 공개적인 선언이 된다. 수신 이메일 서버에서 실시하는 모든 DKIM 확인은 실패하게 된다.

```
*.example.com. TXT “v=DKIM1; p=”
```


두 개의 DNS 항목이 필요한 SPF와 달리 이 DKIM 레코드는 도메인과 하위 도메인 수준 이메일 호스트 모두에 이러한 도메인에서 발송된(스푸핑된) 모든 이메일은 가짜 이메일로 간주하라고 알린다.

- 파킹된 도메인에 대한 DMARC
초기에는 SPF와 DKIM이 사용됐지만, 이것으로 이메일 스푸핑을 차단하기에는 충분하지 않은 것으로 드러났다(이에 대해서는 너무 길고 복잡하기 때문에 이번 기사에서 다루기 어렵다). 이후 DMARC가 등장했고 많은 사람이 긍정적으로 평가했다.

DMARC는 두 가지 방법으로 SPF와 DKIM을 연결한다. 첫째, 도메인이 SPF와 DKIM 확인 두 가지 모두 통과하지 못한 이메일을 어떻게 처리해야 하는지를 명시하는 공개 선언으로 DMARC 레코드를 게시한다. 모니터링만 하거나("p=none") 스팸으로 격리하거나("p=quarantine") 아예 거부할 수 있다("p=reject").

그러나 파킹된 도메인에서 목표는 acnecorp.com에서 오는 모든 이메일이 가짜임을 공개적으로 알리고 수신 이메일 서버에 이러한 이메일을 단호하게 처리할 것을 요청하는 것이다. 그래서 SPF와 DKIM 레코드를 하나로 합쳐 “@example.com에서 합법적으로 발송되는 이메일은 없음을 공개적으로 선언하며, 그러한 이메일을 받는 경우 거부하고 그 사실을 우리에게 알려주십시오”라는 내용의 다음과 같은 DMARC 레코드를 게시한다.

```
_dmarc.example.com TXT "v=DMARC1; p=reject;
rua=mailto:rua@example.com; ruf=mailto:ruf@example.com”
```


acnecorp.com에서 이메일을 수신한 이메일 서버는 SPF와 DKIM을 확인하고 두 가지 모두 실패한 후 100% "p=reject" 정책인 DMARC 레코드를 확인한다. 이상적으로는 이러한 이메일은 튕겨 나가야 하지만, 현실에서 대부분의 이메일 서비스 제공업체는 “reject”를 “높은 스팸 점수를 붙여 격리하라”는 의미로 해석한다.

rua와 ruf 이메일 보고 주소는 어떻게 해야 할까? 해당 도메인 이외의 도메인으로 보고를 보내라고 요청하면 기본적으로 DMARC는 작동하지 않는다. 그러나 CNAME 레코드를 사용해서 다른 도메인의 DMARC rua 및 ruf 보고 주소를 사용한 보고를 지정할 수 있다.

```
_dmarc.example.com CNAME _dmarc.parked.example.net.
_dmarc.parked.example.net TXT "v=DMARC1; p=reject;
rua=mailto:rua@example.net; ruf=mailto:ruf@example.net”
*._report._dmarc.example.net TXT “v=DMARC1”
```


이제 파킹된 도메인에 대한 DMARC 보고는 실제 라이브 이메일 도메인에 나열된 보고 주소로 전송된다.

- 널 MX 레코드 게시
파킹된 도메인의 스푸핑된 이메일을 처단하기 위한 조치의 마지막 조각은 RFC 7505에 지정된 널 MX 레코드를 사용한 이중 안전 장치다.

```
example.com MX 0.
*.example.com MX 0.
```


첫 번째 줄은 도메인용 이메일 서비스가 없음을 공개적으로 알린다. 두 번째 줄은 모든 하위 도메인에 대한 이메일 서비스도 없음을 나타낸다. 단, 널 MX 레코드를 사용할 때는 주의가 필요하다. 2015년 하반기부터 M3AAWG는 아직 이 표준을 구현하지 않은 수신자와의 호환성을 최대화하기 위해 도메인에 A 또는 AAAA 레코드가 있는 경우에 한해서만 널 MX 레코드를 사용하도록 권고한다.

타이포스쿼팅 도메인 등록은 스푸핑된 이메일로 인한 피싱 공격과 회사 평판 손상에 대비한 저렴한 보험과 같다. 그러나 등록하는 데 그치지 말고 타이포스쿼팅 도메인에 대한 모든 이메일을 차단하는 과정까지 완료해야 비로소 제대로 움직인다. 적절한 SPF, DKIM, DMARC 설정은 이메일 스푸핑을 차단하는 데 있어 큰 효과를 발휘한다.

M3AAWG는 본지에 올해 권장 사항을 업데이트할 계획이지만 새로운 모범 사례는 없을 것이라고 전했다. 널 MX 레코드의 경우 “절대적인 수는 증가했지만 주목할 만한 정도는 아니고 도메인의 수에 비례하지도 않는다”고 말했다. editor@itworld.co.kr 


2020.01.13

파킹된 도메인의 "이메일 스푸핑"을 방지해야 하는 이유와 방법

J.M. Porup | CSO
이메일 스푸핑(email spoofing)을 차단하려면 생각할 것도 없이 도메인 기반의 메시지 인증, 보고 및 확인(Domain-based Message Authentication, Reporting and Conformance, DMARC)를 사용해야 한다(이메일 스푸핑이란 이메일 발송 시 발신자의 주소를 위조하는 것을 말한다. 편집자 주).  

피싱 공격이나 기업 이메일 침해(Business Email Compromise, BEC)로 이어지는 @yourdomain.com의 스푸핑된 이메일을 반기는 사람은 없다. 그런데, 소유는 하고 있지만 이메일을 보내거나 받지는 않는 도메인, 즉 파킹된 도메인(parked domains)에도 DMARC를 구현했는가?  

이런 경우를 생각해보자. acmecorp.com을 운영하면서 acnecorp.com도 함께 소유하고 있다. 여드름과 상관은 없지만 타이포스쿼팅(typosquatting)을 방지하기 위해 구입한 도메인이다. 또한 피싱이나 위장에 대비한 저렴한 보험도 된다. acmecorp.com에 DMARC를 구축하면 IAmTheCEO@acmecorp.com과 같은 스푸핑된 이메일은 바로 잡힌다. 그런데 acnecorp.com의 스푸핑된 이메일은 어떨까? 이제 뭐가 문제인지 보일 것이다.

이런 유형의 공격을 막기 위한 최선의 방법은 “이 도메인은 절대 이메일에 사용되지 않으므로 이 도메인에서 오는 이메일을 받는다면 가짜 이메일입니다”라는 의미의 DMARC 레코드를 게시하는 것이다.


파킹된 도메인의 이메일을 끄는 방법

언뜻 이해가 되지 않을 수도 있다. 발송되는 이메일에 암호화된 서명을 할 일이 없다면 DNS에 DKIM(DomainKeys Identified Mail) 레코드를 게시할 이유가 무엇인가? 

도메인에서 이메일을 보낼 일이 없는데 메일서버등록제(Sender Policy Framework, SPF) 레코드를 게시할 이유가 무엇인가? 이유는 해킹이다. 우리는 40년째 이메일 보안을 구축하기 위해 노력하는 중인데, 아직도 제대로 못하고 있다.

DMARC 레코드와 널(null) 메일 익스체인저(MX) 레코드의 조합은 사기꾼이 자사의 도메인을 사용해 스푸핑된 메일을 보내지 못하도록 차단하는 최선의 방책이다. 이보다 더 깊이 들어가고 싶다면? 안티스팸 워킹 그룹인 M3AAWG(Messaging Malware Mobile Anti-Abuse Working Group)이 2015년 12월에 발표한 “M3AAWG 사용중인 도메인 보호를 위한 최선의 방법(Protecting Parked Domains Best Common Practices)”이라는 제목의 문서에서 파킹된 도메인의 이메일을 보호하기 위한 충실한 가이드를 볼 수 있다. 

- 파킹된 도메인을 위한 SPF
SPF는 사기꾼이 소유하지 않은 도메인에서 이메일을 보내지 못하도록 차단한다. 도메인 관리자가 해당 도메인을 대신해 이메일을 보낼 수 있는 호스트를 공개하는 DNS TXT 레코드를 게시하기 때문이다. 이메일 서비스 제공업체는 이메일을 수신한 다음 DNS 항목을 보고 해당 호스트가 승인된 호스트인지 여부를 확인한다.

"이 도메인을 대신해 이메일을 보내도록 허용된 호스트는 절대 없다!"고 적힌 SPF 레코드를 게시하면 대부분의 이메일 서비스 제공업체는 그 이메일을 스팸으로 처리한다.

이메일 스푸핑을 차단하도록 파킹된 도메인의 SPF를 올바르게 구성하는 방법은 다음과 비슷하다.

```
example.com. TXT "v=spf1 -all"
```


이게 무슨 뜻일까? example.com 도메인에서 “-all”은 SPF를 엄격하게 적용한다. "include:example.com"이 없다는 것은 이 메일을 보낼 수 있는 합법적인 도메인이 없다는 의미다.

이 분야에서 권위있는 기관은 파킹된 도메인 SPF 레코드에서 다음과 같이 하위 도메인도 차단해 @spam.example.com과 @phishing.example.com의 이메일 스푸핑을 차단할 것을 권장한다.

```
*.example.com. TXT “v=spf1 -all”
```


- 파킹된 도메인의 DKIM
대부분의 이메일 제공업체는 DKIM을 활성화한다. DKIM에서 이메일 서버는 비공개 키를 사용해 발신 이메일을 암호화 서명하고, 이 비공개 키와 짝을 이루는 공개 키는 도메인의 도메인 네임 시스템(DNS)에 게시된다. DKIM은 수신 이메일 서버에서 수신되는 이메일의 출처가 이메일에 명시된 출처와 일치하며 메시지가 전송 과정에서 수정되지 않았음을 알 수 있게 해준다.

이것이 파킹된 도메인에서 원치 않는 스푸핑된 이메일을 방지하는 데 어떻게 도움이 될까? DKIM을 관장하는 RFC 6376은 공개 키에 대한 빈 값(“p=”)이 “이 공개 키는 폐지되었음”을 의미한다고 규정한다. 즉, 이 도메인에 대한 유효한 DKIM이 존재하지 않는다는 공개적인 선언이 된다. 수신 이메일 서버에서 실시하는 모든 DKIM 확인은 실패하게 된다.

```
*.example.com. TXT “v=DKIM1; p=”
```


두 개의 DNS 항목이 필요한 SPF와 달리 이 DKIM 레코드는 도메인과 하위 도메인 수준 이메일 호스트 모두에 이러한 도메인에서 발송된(스푸핑된) 모든 이메일은 가짜 이메일로 간주하라고 알린다.

- 파킹된 도메인에 대한 DMARC
초기에는 SPF와 DKIM이 사용됐지만, 이것으로 이메일 스푸핑을 차단하기에는 충분하지 않은 것으로 드러났다(이에 대해서는 너무 길고 복잡하기 때문에 이번 기사에서 다루기 어렵다). 이후 DMARC가 등장했고 많은 사람이 긍정적으로 평가했다.

DMARC는 두 가지 방법으로 SPF와 DKIM을 연결한다. 첫째, 도메인이 SPF와 DKIM 확인 두 가지 모두 통과하지 못한 이메일을 어떻게 처리해야 하는지를 명시하는 공개 선언으로 DMARC 레코드를 게시한다. 모니터링만 하거나("p=none") 스팸으로 격리하거나("p=quarantine") 아예 거부할 수 있다("p=reject").

그러나 파킹된 도메인에서 목표는 acnecorp.com에서 오는 모든 이메일이 가짜임을 공개적으로 알리고 수신 이메일 서버에 이러한 이메일을 단호하게 처리할 것을 요청하는 것이다. 그래서 SPF와 DKIM 레코드를 하나로 합쳐 “@example.com에서 합법적으로 발송되는 이메일은 없음을 공개적으로 선언하며, 그러한 이메일을 받는 경우 거부하고 그 사실을 우리에게 알려주십시오”라는 내용의 다음과 같은 DMARC 레코드를 게시한다.

```
_dmarc.example.com TXT "v=DMARC1; p=reject;
rua=mailto:rua@example.com; ruf=mailto:ruf@example.com”
```


acnecorp.com에서 이메일을 수신한 이메일 서버는 SPF와 DKIM을 확인하고 두 가지 모두 실패한 후 100% "p=reject" 정책인 DMARC 레코드를 확인한다. 이상적으로는 이러한 이메일은 튕겨 나가야 하지만, 현실에서 대부분의 이메일 서비스 제공업체는 “reject”를 “높은 스팸 점수를 붙여 격리하라”는 의미로 해석한다.

rua와 ruf 이메일 보고 주소는 어떻게 해야 할까? 해당 도메인 이외의 도메인으로 보고를 보내라고 요청하면 기본적으로 DMARC는 작동하지 않는다. 그러나 CNAME 레코드를 사용해서 다른 도메인의 DMARC rua 및 ruf 보고 주소를 사용한 보고를 지정할 수 있다.

```
_dmarc.example.com CNAME _dmarc.parked.example.net.
_dmarc.parked.example.net TXT "v=DMARC1; p=reject;
rua=mailto:rua@example.net; ruf=mailto:ruf@example.net”
*._report._dmarc.example.net TXT “v=DMARC1”
```


이제 파킹된 도메인에 대한 DMARC 보고는 실제 라이브 이메일 도메인에 나열된 보고 주소로 전송된다.

- 널 MX 레코드 게시
파킹된 도메인의 스푸핑된 이메일을 처단하기 위한 조치의 마지막 조각은 RFC 7505에 지정된 널 MX 레코드를 사용한 이중 안전 장치다.

```
example.com MX 0.
*.example.com MX 0.
```


첫 번째 줄은 도메인용 이메일 서비스가 없음을 공개적으로 알린다. 두 번째 줄은 모든 하위 도메인에 대한 이메일 서비스도 없음을 나타낸다. 단, 널 MX 레코드를 사용할 때는 주의가 필요하다. 2015년 하반기부터 M3AAWG는 아직 이 표준을 구현하지 않은 수신자와의 호환성을 최대화하기 위해 도메인에 A 또는 AAAA 레코드가 있는 경우에 한해서만 널 MX 레코드를 사용하도록 권고한다.

타이포스쿼팅 도메인 등록은 스푸핑된 이메일로 인한 피싱 공격과 회사 평판 손상에 대비한 저렴한 보험과 같다. 그러나 등록하는 데 그치지 말고 타이포스쿼팅 도메인에 대한 모든 이메일을 차단하는 과정까지 완료해야 비로소 제대로 움직인다. 적절한 SPF, DKIM, DMARC 설정은 이메일 스푸핑을 차단하는 데 있어 큰 효과를 발휘한다.

M3AAWG는 본지에 올해 권장 사항을 업데이트할 계획이지만 새로운 모범 사례는 없을 것이라고 전했다. 널 MX 레코드의 경우 “절대적인 수는 증가했지만 주목할 만한 정도는 아니고 도메인의 수에 비례하지도 않는다”고 말했다. editor@itworld.co.kr 


X