grep

Security

Email 보안 강화 기능 소개(SPF)

NHN

2020년 6월 30일

원문에서 보기 ↗

머리말

NHN Cloud Email은 이메일 보안 강화를 위한 다양한 기능을 제공합니다. 총 두 번에 걸쳐 이메일 보안 강화 기능에 대해 살펴봅니다. 이번 글은 이메일 보안을 강화할 수 있는 방법 중 하나인 SPF (sender policy framework)에 대해 설명합니다. 다음 글은 도메인 보호 기능, DKIM (domainkeys identified mail), DMARC (domain-based message authentication, reporting and conformance)에 대해 알아봅니다.

사전 지식

SPF (sender policy framework) 기능을 살펴보기에 앞서 SPF에 대한 이해를 돕기 위해 관련된 내용을 설명합니다.

이메일 주소 구조

이메일 주소는 로컬 파트와 @(At), 도메인으로 구성되어 있습니다. 이 글에서 설명할 기능들은 도메인 부분을 많이 사용합니다. 이메일 주소의 예를 들면 아래와 같습니다.

이메일 주소: example@toast.com
로컬 파트: example
도메인: toast.com

SMTP (simple mail transfer protocol) 구조, 봉투와 편지

SMTP는 인터넷을 통해 이메일을 발송하고 수신하기 위한 프로토콜(Protocol)입니다. SMTP는 텍스트 기반의 프로토콜이고 구조가 간단하기 때문에 읽기 쉽습니다. 아래는 이메일 발송 SMTP 서버(이하 발송 서버)와 이메일 수신 SMTP 서버(이하 수신 서버) 간 SMTP 통신 예입니다. 아래 통신 예시에서 발송 서버는 'C', 수신 서버는 'S'입니다.

C: telnet www.example.com 25
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.com
S: 250 smtp.example.com, I am glad to meet you
C: MAIL FROM:<bob@example.com>              <-- (1)
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: DATA                                     <-- (2)
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob" <bob@example.com>    <-- (3)
C: To: Alice <alice@example.com>
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C: 
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT                                     <-- (4)
S: 221 Bye

여기서 이메일 보안 강화 기능을 위해 이해가 필요한 부분은 다음과 같습니다. SMTP에 대한 자세한 설명은 글 맨 아래 '참고' 부분을 확인 부탁드립니다.

이메일 스푸핑

스푸핑(Spoofing)

'속임'을 이용한 모든 공격을 의미합니다. 이메일 스푸핑은 피해자가 신뢰할 수 있는 인물, 웹사이트, IP, 이메일 주소 등으로 위장하는 것입니다.

C: telnet www.example.com 25
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.com
S: 250 smtp.example.com, I am glad to meet you
C: MAIL FROM:<bob@trust.com>    <-- 실제로는 'spoofing.com'이지만, 'trust.com'이라고해서 수신 서버를 속임
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob" <bob@trust.com>  <-- 같은 방법으로 수신자를 속임
C: To: Alice <alice@example.com>
...

이메일 발송 SMTP 서버 위조

MAIL FROM(5321.From)에 실제와 다른 신뢰할만한 발신자 주소를 입력해 이메일 수신 SMTP 서버를 속이는 공격 방법입니다. 수신 서버가 속아 스푸핑된 이메일을 수신자(Alice)에게 전달하면 수신자가 속아 피싱이나 파밍, 바이러스에 감염될 수 있습니다. 아래에서 설명할 SPF로 예방할 수 있지만 완벽하진 않습니다. 다음 글에서 설명할 DKIM과 DMARC까지 적용해야 안전합니다.

발신자 주소 위조

From(5322.From)에 실제와 다른 수신자(Alice)가 신뢰할만한 발신자 주소를 입력해 수신자를 속이는 공격 방법입니다. '이메일 발송 SMTP 서버 속이기'와 같이 수신자가 속는다면 피해를 입을 수 있습니다. SPF로 막을 수 없으며, DKIM과 DMARC까지 적용해야 안전합니다.

이메일 보안 강화 기능

SPF(sender policy framework)

SPF 레코드라고 부르는 이메일 발송 SMTP 서버(이하 발송 서버) 정보를 이메일 발송 도메인 DNS(domain name service)에 등록하고 이메일 수신 SMTP 서버(이하 수신 서버)가 DNS에 공개된 IP 정보에 실제 메일을 발송한 SMTP 서버의 IP가 속한지 확인하는 인증 기술입니다. SPF 레코드가 등록되어 있지 않으면 공격자는 스푸핑 공격을 할 수 있고 수신 서버는 발송 서버를 신뢰할 수 없기 때문에 발송한 메일이 스팸으로 처리될 가능성이 커집니다.

다음은 NHN Cloud Email을 통해 Gmail로 이메일을 발송한다고 했을 때 SPF 등록과 인증 흐름을 나타낸 시퀀스 다이어그램입니다. 1.png

SPF 레코드 구조

다음은 SPF 레코드 예입니다.

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spfblocka.toast.com -all"

SPF 레코드 구조는 버전(Version)과 하나 이상의 퀄리파이어(Qualifier)와 메커니즘(Mechanisms) 조합으로 구성되어 있습니다.

| 구분 | 값 | 설명 | | - | - | - | | 버전 | v=spf1 | SPF 레코드 버전입니다. 현재 하나만 존재합니다. | | 퀄리파이어 | +, ?, ~, - | 메커니즘과 같이 사용할 수 있으며, SPF 인증을 통과하거나 실패한 이메일을 어떻게 처리할지 정의합니다. | | 메커니즘 | all, a, ip4, ip6, mx, ptr, exists, include | 발송 서버 매칭 방식을 정의합니다. 메커니즘에 따라 값이 없거나 IP나 도메인을 가집니다. |

퀄리파이어에 대해 조금 더 자세하게 설명하면 다음과 같습니다.

| 퀄리파이어 | 설명 | | - | - | | + | 통과(PASS)입니다. 일반적으로 생략될 수 있습니다. 예로, +include와 include는 같습니다. | | ? | 중립(NEUTRAL)입니다. | | ~ | 가벼운 실패(SOFTFAIL)입니다. 실패지만 수신될 것을 원하며 수신 서버에서 의심스러운 메일로 처리될 수 있습니다. 예, ~all | | - | 실패(FAIL)입니다. 심각한 실패(HARDFAIL)라고도 합니다. SPF 레코드에 등록되지 않은 서버에서 발송된 모든 메일은 메일은 수신이 거부될 수 있습니다. 예, -all |

메커니즘에 대해 조금 더 자세하게 설명하면 다음과 같습니다.

| 메커니즘 | 설명 | | - | - | | all | 모든 경우가 해당됩니다. 일반적으로 제일 마지막에 위치하며 앞에서 통과되지 않은 경우를 처리하기 위해 사용됩니다. | | a | A나 AAAA 레코드에 발송 서버가 있는 경우 통과합니다. | | ip4 | 발송 서버가 IPv4 영역에 포함되면 통과합니다. | | ip6 | 발송 서버가 IPv6 영역에 포함되면 통과합니다. | | mx | MX 레코드에 발송 서버가 포함된 경우 통과합니다. | | ptr | PTR 레코드를 이용한 매칭 방법입니다. 사용을 권장하지 않습니다. | | exists | 값 부분의 도메인의 주소가 확인되면 통과합니다. 자주 사용되진 않습니다. | | include | 다른 도메인을 참조합니다. 참조된 도메인을 따라가 발송 서버를 인증합니다. |

퀄리파이어와 메커니즘, 값의 조합 예는 다음과 같습니다.

${퀄리파이어}${메커니즘}

${퀄리파이어}${메커니즘}:${값}

첫 부분의 SPF 레코드 예를 해석하면 다음과 같습니다.

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spfblocka.toast.com -all"

한 가지 예를 더 들어보겠습니다.

"v=spf1 include:_spfblocka.toast.com ~all"

SPF 레코드 작성 시 주의 사항

SPF 레코드를 직접 작성하시는 경우 다음 사항을 주의해야 합니다.

1. DNS 룩업(Lookups) 10회 초과 주의

도메인을 값으로 사용하는 메커니즘을 사용하게 되면 수신 서버는 추가적으로 DNS 룩업을 계속 진행합니다. 일반적으로 DNS 룩업이 10회 이상 반복될 경우 수신 서버에서 SPF 인증을 실패 처리할 가능성이 있습니다. SPF 레코드 작성 시 최대한 단순한 구조로 만들어 DNS 룩업 회수를 줄여야 합니다.

2. TXT 레코드 최대 길이 주의

DNS TXT 레코드 최대 길이는 255자입니다. SPF 레코드 작성 시 발송 서버 IP들을 IP 영역으로 묶거나 include를 이용해 길이를 줄일 수 있도록 해야 합니다.

3. 단일 SPF 레코드 등록

다음과 같이 여러 개의 SPF 레코드를 등록하는 경우 SPF 인증을 통과할 수 없습니다.

example.com  text = "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 ~all"
example.com  text = "v=spf1 include:example.com ~all"

다음과 같이 하나로 합쳐 단일 SPF 레코드로 등록해야 합니다.

example.com  text = "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:example.com ~all"

SPF 레코드 등록하기

발송 도메인 DNS에 SPF 레코드를 등록하는 방법을 설명합니다.

아래 값을 발송 도메인 DNS의 TXT 레코드에 등록합니다. 자세한 등록 방법은 발송 도메인 DNS 관리자나 관리 업체에 문의 부탁드립니다.

v=spf1 include:_spfblocka.toast.com ~all

SPF 등록 작업이 완료되더라도 DNS 변경의 완전한 전파는 최소 10분에서 최대 24시간까지 걸릴 수 있습니다. 안정적인 발송을 위해 SPF 등록 후 충분한 시간이 지난 다음 이메일을 발송하는 것이 좋습니다.

SPF 레코드 등록 확인하기

이메일 보안 검사 사이트를 이용하거나 리눅스(Linux), 윈도우(Windows) 환경에서 명령어로 확인이 가능합니다. 'nslookup', 'dig'는 DNS에 질의해 도메인 정보를 조회하는 명령어입니다.

이메일 보안 검사 사이트 이용

https://dmarcian.com/spf-survey/?domain=${발송_도메인}

리눅스

nslookup -q=TXT ${발송_도메인}

dig -t TXT ${발송_도메인}

윈도우

nslookup -q=TXT ${발송_도메인}

예시

nslookup -q=TXT toast.com

toast.com       text =

        "v=spf1 include:nhnent.com ~all"

결론

이메일 발송 SMTP 서버 스푸핑 예방

SPF 레코드를 등록하면 수신 서버가 발송 서버 스푸핑 공격을 막을 수 있습니다. 지메일(Gmail), 네이버(Naver) 등 대부분 이메일 서비스들은 메일 수신 시 SPF 레코드를 확인합니다. 따라서, 발송 도메인이 스푸핑 공격에 사용되는 것과 발송한 메일이 스팸으로 처리되는 것을 막기 위해 SPF 레코드를 등록하는 것이 좋습니다.

NHN Cloud Email은 SPF가 등록되지 않은 도메인의 프로젝트 멤버들에게 SPF 등록 안내 메일을 보내는 기능을 제공하고 있으며, SPF 레코드 등록을 권장하고 있습니다. image.png

SPF 인증의 한계

SPF를 이용해 발송 서버 스푸핑을 막을 수 있습니다. 하지만, 공격자가 SPF 레코드가 등록된 도메인으로 MAIL FROM을 변조하면 수신 서버는 SPF 레코드를 확인해 보고 발송 서버를 신뢰하게 됩니다.

C: telnet www.example.com 25
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.com
S: 250 smtp.example.com, I am glad to meet you
C: MAIL FROM:<bob@spoofing.com>    <-- SPF 레코드가 등록된 From과 다른 도메인을 사용
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@trust.com>  <-- 수신자는 MAIL FROM이 아닌 From을 보기때문에 속을 수 있음
C: To: Alice Example <alice@example.com>
...

이런 공격을 막기 위해서 추가적으로 MAIL FROM과 From을 비교하고 이메일 내용이 위조 되지 않았는지 확인하는 인증 방법이 필요합니다. 이런 인증 방법은 다음 글 주제인 DKIM(domainkeys identified mail)과 DMARC(domain-based message authentication, reporting and conformance)에서 다룹니다.

참고