실제 시험 문제 22

이 글에서 익힐 것

• SMTP envelope와 message header를 구분한다.

• SPF가 검사하는 IP·domain 관계를 설명한다.

• authorized server에서 발생한 동일 domain 발신자 위조가 왜 SPF를 통과할 수 있는지 이해한다.

• SPF, DKIM, DMARC의 역할을 구분한다.

• domain 인증과 개인 mailbox 인증을 혼동하지 않는다.

개념부터 차근차근

• TCP 연결 source IP

  수신 mail server가 실제로 연결을 받은 발송 mail server의 IP. SPF가 핵심적으로 비교하는 값이다.

• SMTP MAIL FROM / Return-Path

  배달 실패 반송에 쓰이는 envelope sender. SPF가 이 domain을 기준으로 DNS policy를 조회한다.

• Header From:

  사용자의 mail client 화면에 주로 표시되는 작성자 주소. SMTP message content 일부이며 SPF 단독 검사의 직접 대상이 아니다.

• 로그인 계정

  attacker@example.com이 발송 서버에 인증한 계정. SPF는 이 서버 내부 권한 정책을 알지 못한다.

How spf works

• example.com domain owner가 DNS TXT record에 메일 발송을 허용할 IP/서버를 게시한다.

• 수신 서버는 실제 연결 source IP를 확인한다.

• SMTP envelope sender 또는 HELO domain에 해당하는 SPF policy를 DNS에서 가져온다.

• 연결 IP가 정책에 포함되면 SPF pass, 아니면 정책에 따라 fail/softfail 등이 된다.

• 검사 질문은 '이 IP가 이 domain의 mail을 보낼 수 있는가?'이지 '이 로그인 사용자가 이 local-part를 사용할 수 있는가?'가 아니다.

단계별로 따라가기

1. Eve는 정상 계정 attacker@example.com으로 example.com의 공식 outgoing mail server에 로그인한다.

2. 그 서버는 SPF record에 허가된 IP이므로 example.com envelope sender를 사용한 메일은 SPF pass할 수 있다.

3. 서버가 Header From을 계정과 강제로 일치시키지 않는 취약한 정책이라면 Eve가 From: ceo@example.com을 넣을 수 있다.

4. 수신 서버는 허가된 example.com mail server에서 연결을 받았으므로 SPF만으로는 Eve와 CEO 중 누가 실제 작성자인지 알 수 없다.

5. 따라서 SPF가 spoofing을 반드시 erkennt한다는 문장은 거짓이다. 근본적으로 발송 서버가 인증 계정별 From 권한을 강제해야 한다.

Spf dkim dmarc

• Mechanism

  SPF

  Checks

  sending IP가 envelope domain에 허가됐는지

  Does not prove

  특정 사람이 Header From mailbox를 사용할 권한

• Mechanism

  DKIM

  Checks

  domain private key로 선택된 header/body가 서명됐고 변조되지 않았는지

  Does not prove

  서명 domain 내부의 특정 작성자가 정직한지

• Mechanism

  DMARC

  Checks

  사용자에게 보이는 Header From domain이 SPF-authenticated domain 또는 DKIM signing domain과 alignment되는지 및 처리 정책

  Does not prove

  같은 domain 안에서 ceo와 attacker라는 local-part 권한을 자동 구분

Important same domain nuance

• 문제의 attacker@example.com과 ceo@example.com은 둘 다 Header From domain이 example.com이다.

• 공식 example.com 서버가 envelope sender example.com으로 보내면 SPF domain alignment도 성립할 수 있다.

• 따라서 DMARC까지 있어도 서버가 내부 사용자의 From local-part를 제한하지 않으면 동일 domain 내부 impersonation을 자동으로 막지 못할 수 있다.

• 메일 인증 프로토콜은 주로 domain 단위 인증이고, 조직 내부의 개별 mailbox authorization은 발송 서버 정책·계정 보안이 담당한다.

When spf would help

• Eve가 example.com과 무관한 외부 VPS에서 envelope sender ceo@example.com으로 직접 발송한다.

• example.com SPF policy가 그 VPS IP를 허용하지 않았다면 수신 서버가 SPF fail을 낼 수 있다.

• 그러나 SPF fail도 수신 정책에 따라 격리·거부·표시 여부가 다르며, SPF record가 약하게 설정되면 효과가 제한된다.

문장을 하나씩 판별하기

• 문장은 SPF가 spoofed Absender를 보장되게 탐지한다고 주장한다.

• 그러나 Eve는 example.com의 authorized sending infrastructure를 사용하며 표시 Header From만 ceo로 만들 수 있다.

• SPF는 IP와 envelope domain을 검사하므로 개별 local-part impersonation을 판별하지 못한다.

• 따라서 Falsch다.

문제를 푸는 순서

1. 1단계: 보이는 From과 envelope sender를 분리한다.

2. 2단계: SPF의 입력을 source IP + envelope domain으로 적는다.

3. 3단계: 공식 example.com 서버는 SPF에 authorized일 수 있다고 본다.

4. 4단계: SPF는 attacker 계정이 ceo local-part를 사용할 권한은 검사하지 않는다고 설명한다.

5. 5단계: Falsch로 판정한다.

스스로 확인하기

• SPF가 비교하는 대표 두 값은?

  실제 sending IP와 envelope sender/HELO domain의 SPF policy.

• 메일 앱에 보이는 작성자 주소는 주로 어떤 필드인가?

  Header From:.

• authorized example.com 서버에서 ceo local-part를 위조하면 SPF가 통과할 수 있는가?

  그렇다. SPF는 개별 mailbox 사용 권한을 검사하지 않는다.

• 조직 내부에서 이 공격을 직접 막아야 할 곳은?

  발송 mail server가 인증 계정과 허용된 From 주소를 강제하는 authorization 정책.

설명의 근거

• Gedächtnisprotokoll Computersystemsicherheit WS2025_26.md, Networking / Multiple Choice, 4-(f).

• Vorlesung 08 Domain Name System — email authentication/SPF 관련 강의 범위.

• 복기 시나리오의 동일 domain 계정·표시 발신자 차이를 보존해 조건부로 설명.

이 문제가 어려운 이유

짧은 문제 문장 ‘attacker@example.com 계정으로 ceo@example.com spoofed sender mail을 보내면, receiving server가 SPF(Sender Policy Framework)를 사용할 때 spoofed sender임을 인식한다. Wahr/Falsch?’ 안에 정의, 조건, 처리 순서가 압축되어 있습니다. 아래 예시에서는 이를 한 단계씩 펼쳐 확인합니다.