Email 보안 (with NHN Meetup)

이우길·2022년 5월 4일

SMTP

Reference

NHN Meetup을 보면서 정리한 글입니다.

GOAL

사내 SMTP(발신)서버를 구성하면서 필요한 Email보안에 대한 개념을 이해하기.

이메일 주소 구조

이메일 주소는 로컬파트와 @(At), 도메인으로 구성되어 있다.

이메일 주소 : foobar@gmail.com

로컬 파트 : foobar

도메인 : gmail.com

SMTP

SMTP는 인터넷을 통해 이메일을 발송하고 수신하기 위한 프로토콜(Protocol)이다. SMTP는 텍스트 기반의 프로토콜이기 때문에 구조가 간단하며 읽기 쉽다.

아래 통신예시에서 발송 서버는 'C', 수신 서버는 'S'이다.

// NHN의 설명 글에서 가져왔습니다. (https://meetup.toast.com/posts/244)
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에도 편지와 봉투로 구성된다. (편지: Letter, 봉투: Envelope)

위의 통신에서 (1)에서 (2)까지 봉투, (3)에서 (4)까지가 편지 부분이라 볼 수 있다.
봉투는 메일을 읽는 수신자에게 전달되지 않는다. 따라서 수신자는 봉투의 내용을 확인할 수 없다.
위에서 발신자 주소는 두번등장한다. MAIL FROM, FROM 두 발신자 주소는 수신 서버에서 각기 다르게 사용된다.
- MAIL FROM는 SPF 인증에서 사용된다. 일반적으로 편지의 헤더인 Return-Path 주소로 추가되어 반송 메일을 수신하는 주소로 사용된다.
- FROM은 수신자가 메일을 읽을 때 볼 수 있는 주소이다. DKIM 인증에서 사용된다.
MAIL FROM, FROM는 일치하지 않아도 된다. 예를 들면, 실제 발신자 주소와 다른 반송 메일만 수신하는 이메일 주소를 MAIL FROM에 설정해 모든 반송 메일을 하나의 이메일로 수집하고 처리할 수 있다.
편지(Letter)에 적혀있는 To와 봉투(Envelope)에 적혀있는 To는 다를 수 있다. 예를 들어 cc 혹은 bcc인 사람에게 메일을 보내야 할 때 편지의 To는 모두 동일하지만 봉투에 적혀 있는 To는 cc혹은 bcc의 메일 주소가 적혀있을 수 있다는 것이다.

이메일 스푸핑

이메일 스푸핑은 피해자가 신뢰할 수 있는 인물, 웹 사이트, IP, 이메일 주소 등으로 위장하는 것이다.

// NHN의 설명 글에서 가져왔습니다. (https://meetup.toast.com/posts/244)
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에 실제와 다른 신뢰할만한 발신자 주소를 입력해 이메일 수신 SMTP 서버를 속이는 공격이다.

수신 서버가 속아 스푸핑 된 이메일을 수신자에게 전달하면, 수신자는 속아 피싱이나 파밍, 바이러스에 감염될 수 있다. SPF로 예방을 할 수 있지만 완벽하지 않아 DKIM, DMARC까지 적용해야 안전하다.

발신자 주소 위조

FROM에 실제와 다른 수신자가 신뢰할만한 발신자 주소를 입력해 수신자를 속이는 공격방법이다. SPF로 막을 수 없으며, DKIM과 DMARC까지 적용해야 안전하다.

SPF (Sender Policy Framework)

SPF 레코드라고 부르는 이메일 발송 SMTP서버 정보를 이메일 발송 도메인 DNS(Domain Name Server)에 등록하고 이메일 수신 SMTP서버가 DNS에 공개된 IP정보에 실제 메일을 발송한 SMTP 서버의 IP가 속한지 확인하는 인증 기술이다.

즉 메일을 실제로 보내는 발송서버의 IP와 DNS에 등록되어 있는 해당 도메인의 공개 IP와 비교하여 검증하는 인증방법이다.

SMTP 송신 서버에서 수신서버로 보낼 때 흐름은 아래와 같다.

먼저 발신 서버의 SPF 레코드를 DNS에 등록을 합니다.
발신 서버에서 메일을 수신서버로 전송을 합니다.
수신서버는 MAIL FROM의 SPF 레코드를 DNS서버를 통해 조회 합니다.
조회된 결과와 발신 서버의 IP와 비교하여 이 후 처리를 하게 됩니다.

SPF의 한계

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

// NHN의 설명 글에서 가져왔습니다. (https://meetup.toast.com/posts/244)
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 및 DMARC이다.

DKIM

DKIM은 이메일 인증 방법 중 하나로 수신 서버에서 수신된 이메일이 위변조 되지 않았는지 디지털 서명을 이용해 검증하는 기술이다.

발신 서버는 이메일 발송 시 이메일 발송자, 수신자, 제목, 내용 등을 비밀 키로 서명한 후 이 서명 값을 DKIM-Signature 헤더에 추가한다.

수신 서버는 DKIM-Signature헤더 내 도메인 (d=) DNS에 공개된 공개 키와 서명 알고리즘 정보 등이 담긴 DKIM 레코드를 조회한 후 이 값들을 이용해 수신된 이메일 DKIM-Signature 헤더의 디지털 서명을 검증한다.

발신서버에서 메일을 보낼 때 발신자, 수신자, 제목, 내용 등을 비밀 키로 서명을 한다.
서명 값을 DKIM-Signature 헤더에 추가하여 메일을 발송
수신 서버는 DKIM-Signature 헤더 안에 있는 도메인을 가지고 DNS서버에 공개된 공개 키와 서명 알고리즘을 통해 DKIM 레코드를 조회하고 이 값들을 이용하여 DKIM-Signature 서명을 검증.

DKIM의 인증 한계

DKIM 인증 시 DKIM-Signature의 도메인을 사용하기 때문에 여전히 From를 위조한 이메일 스프핑 공격을 막기에는 부족하다.

DKIM은 이메일 내용의 위변조 여부를 인증할 뿐 DKIM-Signature 도메인과 MAIL FROM의 관계는 검증하지 않는다.

DKIM의 인증 한계에 대한 예제이다.

// NHN의 설명 글에서 가져왔습니다. (https://meetup.toast.com/posts/244)
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: DKIM-Signature: v=1; a=rsa-sha256; d=spoofing.com; s=brisbane; <-- 공격자 도메인과 지정자
      c=simple; q=dns/txt; i=@eng.example.net;
      t=1117574938; x=1118006938;
      h=from:to:subject:date;
      bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
      b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
C: From: "Bob Example" <bob@trust.com>  <-- 수신자는 MAIL FROM이 아닌 From을 보기때문에 속을 수 있음
C: To: Alice Example <alice@example.com>
...