개요

  • 메일 서버 보안에 대한 전반적인 내용을 정리한다.
  • 메일보안은 아주 중요한데 대부분의 사이버 공격이 이메일로부터 시작되기 때문이다.
  • 여기를 보면 2023년에는 75%이상의 사이버 공격이 이메일로부터 시작되었다고 적혀있다.
  • 또한 전 세계 전자메일의 80%는 스팸 메일이라는 보고도 있다. (여기에는 스푸핑이나 피싱메일도 포함된 것으로 보여진다.)
  • 따라서 메일 서버 보안은 보안엔지니어로서 잘 알아두면 좋다.

전자 메일 기초

전자메일 구성요소

  1. MUA (Mail User Agent)
    • 메일 발신, 투고, 수신 등을 수행한다.
    • Outlook Express 와 같은 SW가 MUA이다.
    • 유저 단말(PC)에 존재한다.
  2. MSA (Mail Submission Agent)
    • 메일 투고 접수 및 유저 인증을 수행한다.
    • 우체국의 접수처와 같은 것이다.
    • sendmail, qmail, Postfix, Exchange Server등이다.
    • 메일서버 내에 존재한다.
  3. MTA (Mail Transfer Agent)
    • 메일을 중계 및 배송하는 역할을 담당한다.
    • 우체국의 우편 배송차량같은 것이다.
    • sendmail, qmail, Postfix, Exchange Server등이다.
    • 메일서버 내에 존재한다.
  4. MDA (Mail Delivery Agent)
    • 메일을 각 사용자의 메일 박스에 수납하는 역할을 담당한다.
    • mail.local, procmail, Qpopper등의 SW다.
    • 메일서버 내에 존재한다.
  5. MRA (Mail Retrieval Agent)
    • 유저 인증, 메일 박스에서 메일 꺼내기 등을 담당한다.
    • Qpopper, uw0imap, Courier-IMAP등이다.
    • 메일서버 내에 존재한다.

전자메일 흐름

어떤 조직의 사용자로부터 다른 조직의 사용자에게 메일이 보내지는 과정을 정리한다.

  1. 메일 송신자가 메일SW(MUA)에 의해 작성된 메일을 LAN상의 사내 메일서버에 SMTP로 발신(투고)한다.

  2. 메일 송신 요구를 받은 MSA는, 메일 송신자를 식별,인증을 수행하고, 인증이 통과되면 MTA에게 메일송신(중계)를 의뢰한다.

  3. 사내 메일 서버의 MTA는 설정에 따라, 송신할 메일을 사외의 메일서버(SMTP 게이트웨어 서버: 인터넷과의 경계에 설치된 MTA)에게 SMTP로 중계한다.
    • 일반적인 기업의 환경에서는 SMTP 게이트웨어 서버 이외에 바이러스 검사용 서버, 스팸 검사용서버, 샌드박스 등 메일 보안을 높이기 위한 서버를 경유하는 경우가 많다. (메일 송신시와 수신시의 경로가 다른 경우도 많다.)
  4. 송신측 도메인의 사외용 메일서버(MTA)는 수신측 도메인의 사외용 메일서버(MTA)에게 SMTP로 메일을 중계한다.
    • 수신측 도메인의 MTA정보 (호스트/도메인 명, IP주소)는 수신측 도메인의 DNS서버의 MX레코드, A레코드에 등록되어 있다.)

  5. 메일을 수신한 수신측 도메인의 사외용 메일서버(MTA)는, 사내 메일서버에게 SMTP로 메일을 중계한다.

  6. 사내 메일 서버의 MTA는 자신이 관리하는 메일 박스로 들어가야 하는 메일인 것을 확인하고 MDA에게 메일을 전달한다.

  7. 사내 메일 서버의 MDA는 받은 메일을 수신자의 메일 박스에 넣는다.

  8. 사내 메일서버의 MRA는, 수신자(MUA)로부터 메일 수신 요구를 받으면, 수신자를 식별, 인증하고, 인증을 통과하면 메일박스로부터 메일을 꺼내서 MUA에게 보낸다.

  9. 메일 수신자가 MUA를 사용해서 메일을 읽는다.

전자 메일 취약점과대책

SMTP 취약점

오래된 메일 SW의 사양에 의한 아래의 1, 2번 취약점 때문에 스팸 메일이 횡행하고 있음.

1. 메일 투고와 중계가 같은 구조로 이루어짐

2. 메일 투고시에 사용자를 인증하는 절차가 없음

  • 제 3자 중계 (= 오픈 릴레이) : 필요한 조직 외에서 온 메일도 중계해버리는 것.
  • 오픈 릴레이 서버는 RBL.jp (Realtime Blackhole List Japan)등에 등록됨

3. 표준 메일 암호화 기능이 없기때문에, 평문으로 네트워크 상을 흘러다님

4. MTA의 구현/설정 문제로 유저 정보가 노출될 가능성이 있음

VRFY, EXPN 등의 명령으로 유저 정보 존재 여부 등 확인

5. MTA의 종류/버전 문제로 BOF 공격을 받을 가능성이 있음 (구 버전 소프트웨어 등)

※ 여기서, 투고는 클라이언트에서 SMTP서버로 메일을 전송하는 것을 말함.

STMP 취약점 대책

1. MTA에 발신자 메일 주소제한 설정걸기

  • 송신자 주소가 자신의 도메인인 경우만 송신 허용
  • 수신자 주소가 자신의 도메인인 경우만 수신 허용

2. SMTP Authentication (SMTP-AUTH)로 사용자를 인증

  • MTA, MUA 양쪽이 이 인증방식을 적용해야 사용 가능
  • 인증메커니즘으로 SASL(Simple Authentication and Security Layer)를 사용
  • SASL은 유저명과 패스워드를 안전히 전송하는 수단으로서 Kerberos, GSSAPI, S/Key를 규정하고 있음.

3. POP before SMTP 로 사용자 인증

  • 메일 송신전에 POP3에의한 유저 인증을 실시하고, 성공하면 일정기간 동안 메일 송신을 허가하는 방식
  • SMTP서버는 POP서버가 보증해준 클라이언트 IP를 보고 허가

4. Outbound Port25 Blocking 으로 메일 투고 제한을 걸기

  • 오픈 릴레이가 안통하게 되자 클라이언트를 감염시킨 후 직접 외부 메일서버와 송신을 시도하는 경우가 생김
  • ISP의 메일서버를 경유하지 않고, 직접 인터넷으로 나가려고하는 25번 포트(SMTP)로의 패킷을 차단 하는 방식
  • 정상적인 경우는 메일투고시 submission 전용포트(587)을 사용함 (MSA가 접수를 담당)
  • MSA는 SMTP-AUTH로 유저인증을 실시

5. IP주소, 디지털 서명으로 도메인 인증하기

송신 도메인이 정당한지 인증하는 방식임

IP 주소를 사용하는 방식

  1. Sender Policy Framework (SPF)
    • 수신측에서 발신측 SMTP서버가 정당한 서버인지를 확인하기 위한 구조
    • 수신측 메일 서버는 해당 도메인의 DNS서버에게 메일 서버의 정보를 문의함. 문의결과 정당성이 확인되면 메일을 수신.
    • 미리 발신자 DNS 서버에 정당한 메일 서버 IP주소 (SPF 레코드)를 등록해 두는 것으로 메일 서버를 인증한다.

SPF 레코드 예

  • spf1은 SPF의 버전을 의미한다.
  • -all의 왼쪽에 일치하는 IP주소가 아니면 그 메일은 거부한다는 뜻. 아래 설정은 기록된 두 IP이외로부터의 송신만 허용한다는 의미이다. 의미한다.
example.co.jp IN TXT "v=spf1 ip4:192.168.1.5 ip4:192.168.1.12 -all"
  1. Sender ID Framework (Sender ID)
    • SPF의 기능에 더해서 수신한 메일 헤더의 송신측 메일 주소 도메인의 정당성을 검증하는 기능이다.
    • 장점 : 도입이 용이하다, 수신측 메일 서버 부담 적음, 송신측 메일서버는 아무것도 하지 않아도 됨.
    • 단점 : 발신자 주소를 위조하지 않은 스팸은 제거 불가능. DNS 서버에 등록되지 않은 메일서버로부터의 메일은 정당하더라도 수신 불가능, 복수의 메일서버를 경유한 메일을 검증하기 어려움.

디지털 서명을 사용하는 방식

  1. DomainKeys
    • 미리 발신자 DNS 서버에 정당한 메일 서버의 공개키를 등록해둔다.
    • 발신자 메일 서버는 자신의 비밀키를 사용해 메일에 서명한다.
    • 메일을 수신한 메일서버는 발신용 DNS 서버에 문의해 발신자 메일 서버의 공개키를 획득해서 서명의 정당성 확인하는 구조
  2. DKIM(DomainKeys Identified Mail)
    • DomainKeys방식에 IIM방식을 결합한 IETF 표준.
    • 공개키를 메일헤더에 삽입한다.
  • 장점 : 발신자 정보의 위조를 송신경로 상에서 탐지 가능, 복수의 메일 서버를 경유해도 검증 가능.
  • 단점 : 송신측, 수신측이 모두 이 방식을 지원해야 함. 양측 메일 서버의 부담이 커짐, 메일링 리스트나 광고등이 삽입되는 메일등 송신경로 상에서 내용이 변경되는 경우 검증이 어려움.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

  • SPF나 DKIM의 인증이 실패했을 경우의 대응책을 정한 것이다.
  • 발신자는 수신자 인증 실패시 권장 조치를 DNS에 “DMARC 정책”으로 선언하고 수신자는 인증 실패시 이 DMARC 정책을 참조하여 수신 메일을 처리하는 방법을 결정한다.
  • 예를 들어 DMARC 정책에
    • “거부”(reject)로 정의된 경우 수신 메일을 거부한다.
    • “검역하기”(quarantine)로 정의되어 있으면 격리하고
    • “아무것도하지 않음”(none)으로 정의되면 일단 수신하고 엔드포인트에서 판단하는 작업을 수행한다. 이렇게 하면 SPF나 DKIM 인증 결과만으로는 판단할 수 없었던 스푸핑 메일을 배제할 수 있다.

  • https://ent.iij.ad.jp/articles/172/ 참고

  • 최근동향: 2024년 4월, gmail에서 DMARC대응을 안하면 송신안한다고 강제했다. 그 후 각 회사가 서둘러서 대응하고 있다. 일본 proofpoint의 발표에 의하면, 일본에서는 감시만 하는 none설정이 63%, reject는 7%뿐이다. 한편, 미국은 46%가 reject, 32%가 none이라고 한다. (미국이 더 적극적으로 거부하는 것을 알 수 있다.)

  • 궁금증: 1) 어떤 메일 서버가 DMARC대응을 했는지 안했는지는 어떻게 알 수 있는가? 2) 클라이언트쪽에서 DMARC대응 설정을 하는 방법이 있는가?

ARC (Authenticated Received Chain, 인증받은 체인)

  • 메일링 리스트나 전달 서비스와 같은 중간 메일 서버가 이메일의 원래 인증 결과에 서명할 수 있도록 설계된 메일 인증 시스템
  • DMARC와 별도로 동작하는 기능이다. 따라서 DMARC와 ARC양쪽 다 사용가능하다.
  • 2019년 7월에 게시된 RFC 8617에 “실험적”으로 정의되어 있다.
  • 엄격한 DMARC 정책은 메일링 리스트나 전달자를 통해 전송된 적법한 이메일을 차단할 수 있다. 제목 태그나 바닥글을 추가하는 등 메시지가 수정되면 DKIM 서명이 무효화되거나 메일이 복수의 메일서버를 경우한 경우 SPF 확인이 실패하기 때문이다.
  • ARC는 중간 서버에 원본 메시지의 유효성 검사 결과에 서명할 수 있는 방법을 제공하여 이 문제를 해결하기 위해 고안되었다.

참고

  • https://en.wikipedia.org/wiki/Authenticated_Received_Chain
  • https://powerdmarc.com/ko/what-is-arc/
  • https://www.naritai.jp/technology_arc.html

6. 메일 필터링

  • 메일 필터링 소프트웨어를 사용
  • IP나 포함된 문자열등으로 필터링. 문자열 패턴이 조금 바뀌면 필터링이 안되는 문제가 있음.
  • 이 문제를 해결하기 위해 베이지안 필터링이 있음.
  • 스팸 메일의 특성을 자기학습해서 통계에 기반해서 필터링 하는 것.

7. SMTP over TLS 로 메일 암호화 및 사용자 인증하기

  • TLS를 이용해서 SMTP 통신을 암호화
  • 암호화되는 구간은 MUA부터 해당 도메인의 SMTP 서버까지. 인터넷상에서는 평문으로 통신.

8. S/MIME, PGP 등으로 메일 암호화하기

  • 모든 통신 경로상에서 메일을 암호화 할 수 있음.

9. MTA에서 불필요한 커맨드 무효화하기

10. 기타 MTA 구현 상의 대책

  • MTA 버전 최신화
  • 안티 바이러스 SW로 메일에 첨부된 바이러스 탐지
  • 인터넷과 내부 네트워크 사이 DMZ에 메일 중계 서버를 설치
  • 사내 랜에 POP3겸SMTP설치
  • DMZ에 게이트웨이형 안티바이러스 서버 설치

POP3 취약점

  1. 인증정보가 평문으로 네트워크를 흘러다님
  2. 수신 데이터(메일)가 평문으로 네트워크를 흘러다님

POP3 취약점 대책

  1. APOP 로 유저 인증정보 숨기기
    • Authenticated Post Office Protocol
    • 챌린지-리스폰스 방식의 유저 인증(일회성 인증)
    • 서버로부터 받은 문자열(챌린지)를 패스워드와 결합해 MD5로 메세지 다이제스트를 생성, 그 것을 서버로 전송
    • 패스워드 자체가 네트워크에서 흘러다닐 일은 없게 된다.
  2. POP3 over TLS로 인증정보 및 메일 암호화
    • TLS를 이용해서 POP3 통신을 암호화
    • 암호화되는 구간은 MUA와 POP3서버만이다.
    • 995번 포트를 사용
  3. SSH의 포트포워딩 기능으로 인증정보 및 메일 암호화
    • 암호화되는 구간은 MUA와 POP3서버만이다.
    • 암호화 기능이 없는 통신 구간에 SSH가 개입해서 통신을 중계함으로서 암호화 기능을 구현하는 것.
    • 이 경우는 통신 포트가 22번이 된다.