[E-Mail Security] 2. 이메일 보안(SPF, DKIM, DMARC)

※ 블로그 운영자의 개인적인 의견입니다. 팩트와 글의 내용이 다를 수 있습니다.

서론

메일은 회사의 업무에서 없어서는 안될 소통 방법 중 하나가 되었다. 메일은 글로벌 소통 방법이며, 메시지를 쉽고 간편하게 전달할 수 있다. 이러한 점은 해커에게도 유리하게 작용한다. 해커는 마치 정상적인 사람인척 위장하여 악성URL과 악성코드를 쉽고 간편하게 전파할 수 있다. 이러한 해킹 기술이 고도화되어 해커는 신뢰받을 수 있는 기관으로 위장하여, 불특정다수에게 악성URL과 악성코드를 전파하고 있다. 최근에는 AI를 통해서 악성메일이 자동으로 생성 및 전파되고 있으며, 해킹의 약 93%는 악성메일로부터 시작된다고 할 정도이다.

메일 인프라의 가장 큰 취약점은 누구에게나 열려있다는 점이며, 개인을 쉽게 식별하기 어렵다는 점이다. 누가 메일의 계정을 외우우고 있겠는가? 우리는 메일의 발송지를 판단할때 도메인을 보고 판단한다. 'hong_gildong@naver.com' 로부터 메일이 발송되었다면 네이버에서 보낸 메일이라고 특정지을 수 있다. 내용을 종합하자면 google.com에서 메일을 발송하더라도 naver.com로 위장하여 메일을 발송할 수 있으며, 메일을 수신하는 사용자는 naver.com라는 도메인만 보고 네이버에서 온 메일로 착각하기 쉽다는 것이다.

지금부터 소개할 기술 SPF, DKIM, DMARC 3가지 기술은 발신자의 신원(도메인)을 확보하여 수신자로부터 메일의 안전성을 보장하는 기술이다.

Part 1. 요약

SPF, DKIM은 발신자의 도메인 신뢰성을 분석 및 검증하는 기술이며, DMARC는 SPF, DKIM의 분석 결과를 통해 메일이 발송되는 것을 차단할것인지 허용할 것인지, 정책을 실행시키는 기술이다.

구분	요약
SPF (Sender Policy Framework)	발신자의 도메인 신뢰성 검증
DKIM (Domainkeys Identified Mail)	이메일에 디지털 서명을 추가하여 메일 무결성 검증
DMARC (Domain-based Message Authentication, Reporting & Conformance)	SPF와 DKIM 결과를 통한 보안정책 설정 및 구현

Part 2. SPF (Sender Policy Framework)

메일에는 도메인이 포함되어 있다. 홍길동이라는 유저가 네이버를 통해서 메일을 보내게 된다면 메일 발송자는 홍길동@naver.com이 된다. 여기서 @ 뒤에 있는 부분을 도메인이라고 말한다. 이런 도메인은 얼마든지 위변조하여 메일을 발송할 수 있다. 다시 말해, 홍길동이라는 사용자는 네이버에서 메일을 발송하지 않아도, 도메인을 위변조하여 '홍길동@naver.com'로 다른 사람에게 메일을 발송할 수 있다는 것이다. 이런 도메인 위변조를 방어하기 위한 기술이 SPF이다.

SPF는 DNS TXT Record에 등록된 IP 또는 도메인에 대해서 발신을 허용하고 그 외는 차단한다. 정책은 DNS에서 설정가능하며, 정책 설정 방법은 아래와 같다.

¹v=spf1 ²ip4:10.10.10.10 ³ip4:20.20.20.20 ⁴include:domain.com ⁵include:domain2.com ⁶-all

① v=sfp1 - SFP version을 1로 사용
② ip4:10.10.10.10 - ip 10.10.10.10에서 보내는 메일은 허용 (성공 로그)
③ ip:20.20.20.20 - ip 20.20.20.20에서 보내는 메일은 허용 (성공 로그)
④ include:domain.com - 도메인 domain.com에서 보내는 메일은 허용 (성공 로그)
⑤ include:domain2.com - 도메인 domain2.com에서 보내는 메일은 허용 (성공 로그)
⑥ -all - 그 외 모두 차단 (실패 로그)

해당 정책을 통해 SPF 검증 성공/실패 여부를 확인하며, 실패가 된다고 하더라도 반드시 차단되는 것은 아니다. SPF 검증에서 실패한 이메일을 거부하지 않고 스팸 폴더로 분류하거나, 그냥 허용할 수도 있다. 이는 수신 서버의 설정에 따라 달라진다.

정책이 잘 설정되어 있는지는 CMD 명령어를 통해서 확인이 가능하다. 해당 값은 누구나 확인 가능하다. 예시로 naver.com 도메인을 확인해 보겠다. 해석은 직접 해보기 바란다.

nslookup
> set type=txt
> naver.com

Part 3. DKIM (Domainkeys Identified Mail)

DKIM(Domain Keys Identified Mail)은 이메일에 디지털 서명을 메일 헤더에 추가하여, 발신자의 도메인이 위변조 되었는지 검증하는 기술이다.

이미지 출처 : https://www.crinity.net/Newsletter/2019/06/Coffee_Break.html

메일이 발송 되면 메일서버는 발신자의 개인 키(Private Key)를 통해 고유 키 값을 생성하는데, 이를 DKIM-Signature라고 한다. DKIM-Signature은 메일 헤더에 추가되어 수신자 메일서버로 발송된다. 발신자의 메일서버는 사전에 DNS서버에게 DKIM-Signature를 복호화할 수 있는 공개 키(Public Key)를 전달한다. 메일을 받은 수신 측 메일서버는 발신 측 DNS서버에 공개 키 값을 질의하고 회신 받는다. 수신 측은 공개 키(Public Key)를 통해 DKIM-Signature를 확보하여, 실제 도메인 소유자로부터 메일이 발송되었는지 확인할 수 있다.

발신자에서 수신자로 메일이 넘어가는 과정 하나하나 DKIM 공식사이트인 dkim.org 예시를 통해 설명해보고자 한다.

1. 수신자는 메일을 발송하며, 메일을 발송할 때 구조는 아래와 같다.

Tag	Description	Example
From	발신자의 메일주소	Hong@naver.com
To	수신자의 메일주소	Park@google.com
Subject	메일 제목	this is title
Date	발송 일자	Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID	메일을 식별하기 위한 고유 ID	<20030712040037.46341.5F8J@football.example.com>
body	메일 내용	hello world

From: 홍길동 <Hong@naver.com>
To: 박혁거세 <Park@google.com>
Subject: this is title
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

hello world

2. 메일서버는 수신자의 개인키를 통해 DKIM-Signature를 생성 및 메일 헤더에 추가한다.

Tag	Description
v	Version
a	Signing Algorithm
d	Domain
s	Selector
c	Canonicalization algorithm for the header and body
q	Default query method
l	Length of the canonicalized part of the signed message body
t	Signature timestamp
x	Expiration time
h	List of signed header fields (repeated for fields that occur multiple times

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=naver.com; c=simple/simple; q=dns/txt; i=Hong@naver.com; h=Received : From : To : Subject : Date : Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=;

Received: from client1.naver.com [10.10.10.10] by submitserver.naver.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT)

From: 홍길동 <Hong@naver.com>
To: 박혁거세 <Park@google.com>
Subject: this is title
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

hello world

3. 수신자 메일서버는 발신측 DNS서버로부터 공개 키(Publick Key) 요구한다.

"v=DKIM1;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB"

DNS서버 DNS Zone에 설정되어 있는 DKIM이다.

4. 공개 키(Public Key)를 통해 DKIM-Signature를 검증한다.

X-Authentication-Results: google.com
header.from=Hong@naver.com; dkim=pass
Received: from mout23.naver.com (10.20.20.20)
by google.com with SMTP;

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=naver.com; c=simple/simple; q=dns/txt; i=Hong@naver.com; h=Received : From : To : Subject : Date : Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=;

Received: from client1.naver.com [10.10.10.10] by submitserver.naver.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT)

From: 홍길동 <Hong@naver.com>
To: 박혁거세 <Park@google.com>
Subject: this is title
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>

hello world

정상적인 도메인 확인 절차가 마무리되고, 메일이 수신자에게 전달된다.

Part 4. DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC를 평면적으로 번역하면, ' 도메인 기반 메시지 인증, 보고 및 적합성' 이다. 도메인의 메시지 인증을 통해 보고 및 적합성을 판단하고 결과에 따른 적절한 정책을 수행하는데, 도메인의 메시지 인증은 SPF와 DKIM 결과를 의미한다.

DMARC 설정 방법도 SPF & DKIM과 동일하게 DNS Zone에서 설정을 할 수 있다.

Tag	Value	Description
v	DMARC1	DMARC 프로토콜 버전. 현재로서는 DMARC1 이후의 새로운 버전이 존재하지 않음.
p	none	인증 실패 시 아무 조치도 취하지 않고 이메일을 그대로 전달. 이메일 인증 결과를 모니터링하며 DMARC 설정의 영향을 확인할 때 사용.
	quarantine	인증 실패 이메일을 스팸 폴더로 이동하거나 격리. DMARC 정책을 점진적으로 적용하여 이메일을 필터링하고 테스트할 때 사용.
	reject	인증 실패 이메일을 수신자에게 전달하지 않고 차단. DMARC 정책이 안정적으로 적용된 후, 스푸핑 공격을 완전히 차단할 때 사용.
rua	mailto:이메일	Aggregate Report(요약 보고서)를 받을 이메일 주소를 지정 *mailto: DMARC 설정에서 이메일 주소를 지정할 때 사용하는 표준 형식
ruf	mailto:이메일	Forensic Report(포렌식 보고서)를 받을 이메일 주소를 지정 *mailto: DMARC 설정에서 이메일 주소를 지정할 때 사용하는 표준 형식
pct	50	인증 실패 이메일 중 50%에만 정책 적용.
sp (Subdomain Policy)	none	서브도메인에 대해 인증 실패 시 아무 조치도 취하지 않음.
	quarantine	서브도메인에 대해 인증 실패한 이메일을 스팸 폴더로 이동.
	reject	서브도메인에 대해 인증 실패한 이메일을 차단.
adkim	r (relaxed)	DKIM 서명 도메인이 보낸 사람의 From 도메인과 서브도메인까지 허용되면 인증 성공으로 간주.
adkim	s (strict)	DKIM 서명 도메인이 보낸 사람의 From 도메인과 정확히 일치해야 인증 성공으로 간주.
aspf	r (relaxed)	SPF 도메인이 From 도메인과 서브도메인까지 허용되면 인증 성공으로 간주.
aspf	s (strict)	SPF 도메인이 From 도메인과 정확히 일치해야 인증 성공으로 간주.

DKIM 설정은 매우 간단하지만, 큰 조직에서 최초 도입하기에는 리스크가 크다. 그 이유는 메일이 사용자에게 전달되지 않아, 문의가 끊임없이 쏟아질 수 있기 때문이다. 사용자는 메일이 본인한테 온지도 모를 수도 있다. 따라서, By-pass를 통해 충분히 모니터링 이후 차단 정책을 구현해야 한다.

[모니터링 정책]

v=DMARC1; p=none; rua=mailto:reports@example.com; ruf=mailto:reports@example.com;

p=none;을 통해 검증에 실패하더라도 어떠한 조치도 하지 않고, rua와 ruf를 통해 보고서를 받을 수 있다. 보고서를 통해 adkim과 aspf의 성공/실패 사례를 분석하여 차단 정책을 구현해야 한다. (sp, adkim, aspf는 tag를 하지 않아도 기본 값으로 지정이 된다. sp는 p의 값을 따라가며, adkim과 apsf는 r로 기본 값이 설정된다.)

rua와 ruf의 차이는 전체적인 통계와 단일 통계이다.

tag	rua	ruf
보고서 종류	요약 보고서(전체적인 통계)이며, 전체적인 인증 실패 성공 분석	포렌식 보고서(개별 상세 정보)이며, 특정 이메일에 대한 실패 원인 분석
보고서 내용	인증된 이메일 수 SPF 및 DKIM 인증 상태 DMARC 정책 적용 결과 이메일 송신 IP 주소 및 발송량	인증 실패한 이메일의 세부 정보. 송신 IP 주소. 이메일 헤더 및 기타 인증 관련 데이터. 원본 이메일 내용 일부가 포함될 수 있음.
주기	하루에 한번	인증 실패 시 즉시 전송
형식	json, xml	eml

spf, dkim, dmarc에 대해서 알아보았다. 해당 기능들을 조직 내에서 구현한다면 보다 많은 문의가 올 것이다. 하지만 악성코드의 유입을 최소화할 수 있다. 일이 많아지더라도 랜섬웨어 한번보다 수백개의 문의가 건강에 좋을 것이다. 독자는 Anti-SPAM과 CDR을 통해 특정 점부파일에 대해서만 DKIM과 SPF를 적용할 방법이 있을지 고민하고 있다. 홈택스 등 정부기관 사칭메일이 너무 많이 사내로 발송되고 있기 때문이다.

스팸메일과 싸워서 다들 건승하길 바란다.

Reference

요약 정리

스팸메일을 대응하기 위해서 SPF, DKIM, DMARC 등의 보안 기능을 활성화해야 한다.
차단 정책을 구현하기 전 충분히 모니터링 후 적용이 필요하며, 안정화 기간이 필요하다.
문의는 많아지겠지만 스팸메일로부터 보안을 최적화하기를 바란다.

'Technology Study > 3. Application Security' 카테고리의 다른 글

[E-Mail Security] 1. 이메일 기본 구조 (0)	2024.11.02

Security Table

[E-Mail Security] 2. 이메일 보안(SPF, DKIM, DMARC)

서론

Part 1. 요약

Part 2. SPF (Sender Policy Framework)

Part 3. DKIM (Domainkeys Identified Mail)

Part 4. DMARC (Domain-based Message Authentication, Reporting & Conformance)

Reference

'Technology Study > 3. Application Security' 카테고리의 다른 글

티스토리툴바

[E-Mail Security] 2. 이메일 보안(SPF, DKIM, DMARC)

서론

Part 1. 요약

Part 2. SPF (Sender Policy Framework)

Part 3. DKIM (Domainkeys Identified Mail)

Part 4. DMARC (Domain-based Message Authentication, Reporting & Conformance)

Reference

'Technology Study > 3. Application Security' 카테고리의 다른 글

관련글

티스토리툴바