발신자 정책 프레임워크는 수십억 개의 IP 주소를 도메인으로 전송하도록 허용하는 경우 스팸 및 피싱을 방지하는 데 도움이 되지 않습니다.
XNUMX 년 전, 폴 빅시 에 대한 의견 요청 게시 MAIL FROM 거부 인터넷 커뮤니티가 스팸과 싸우는 새로운 방법을 개발하도록 자극했습니다. 보낸 사람 정책 프레임 워크 (SPF). 그때나 지금이나 문제는 간단한 메일 전송 프로토콜 (SMTP)는 인터넷에서 이메일을 보내는 데 사용되며 위조된 발신자 도메인을 탐지할 수 있는 방법을 제공하지 않습니다.
그러나 SPF를 사용하는 경우 도메인 소유자는 이메일 전송에 자신의 도메인 이름을 사용할 권한이 있는 IP 주소를 정의하는 DNS(도메인 이름 시스템) 레코드를 게시할 수 있습니다. 수신 측에서 이메일 서버는 SPF 레코드를 쿼리할 수 있습니다. 명백한 보낸 사람의 IP 주소가 해당 도메인을 대신하여 이메일을 보낼 권한이 있는지 확인합니다.
SMTP 이메일 및 SPF 개요
SMTP 메시지 전송 메커니즘과 SPF가 메커니즘과 상호 작용하는 방식에 익숙한 독자라면 이 섹션을 건너뛰어도 좋습니다.
앨리스가 example.com 에서 Bob에게 이메일 메시지를 보내려고 합니다. example.org. SPF가 없으면 Alice와 Bob의 이메일 서버는 다음과 같은 SMTP 대화에 참여합니다. EHLO가 아닌 HELO를 사용하여 간소화되지만 기본 구조를 크게 변경하지는 않습니다.
이것이 인터넷(SMTP) 이메일을 보내고 받는 방식입니다. 초기 1980, 그러나 적어도 오늘날의 인터넷 표준에 따르면 중요한 문제가 있습니다. 위의 다이어그램에서 Chad는 예.넷 에 쉽게 연결할 수 있습니다. example.org SMTP 서버, 정확히 동일한 SMTP 대화에 참여하고 다음 위치에 있는 Alice로부터 분명히 이메일 메시지를 받습니다. example.com 밥에게 배달 example.org. 설상가상으로, 진단 메시지 헤더(여기에 표시되지 않음)에 호스트 이름과 함께 기록된 IP 주소를 제외하고 Bob에게 속임수를 나타내는 것은 아무것도 없을 것입니다. , 종종 액세스조차 어렵습니다.
이메일 스팸의 초창기에는 남용되지 않았지만 대량 스팸이 자리를 잡으면서 멸시받아 마땅한 비즈니스 모델이 되었지만 이러한 이메일 위조 기술은 스팸 메시지를 읽고 조치를 취할 가능성을 개선하기 위해 널리 채택되었습니다.
가상의 차드로 돌아가서 예.넷 Alice "로부터" 그 메시지를 보내는 것… 그것은 두 가지 수준의 사칭(또는 위조)을 포함하는데, 많은 사람들은 이제 그러한 위조된 이메일 메시지를 탐지하고 차단하기 위해 자동화된 기술 검사가 수행될 수 있거나 수행되어야 한다고 생각합니다. 첫 번째는 SMTP 봉투 수준에 있고 두 번째는 메시지 헤더 수준에 있습니다. SPF SMTP Envelope 수준의 검사 및 이후의 위변조 방지 및 메시지 인증 프로토콜을 제공합니다. 디킴 와 DMARC 메시지 헤더 수준에서 검사를 제공합니다.
SPF가 작동합니까?
하나에 따르면 공부 2022년에 게시된 것으로 조사된 32억 개의 도메인 중 약 1.5%에 SPF 레코드가 있었습니다. 이 중 7.7%는 잘못된 구문을 가지고 있었고 1%는 IP 주소를 도메인 이름으로 가리키는 더 이상 사용되지 않는 PTR 레코드를 사용하고 있었습니다. SPF의 활용은 실제로 느리고 결함이 있어 또 다른 질문으로 이어질 수 있습니다. 지나치게 허용적인 SPF 레코드가 있는 도메인은 몇 개입니까?
최근 조사 결과 호주에서만 264개 조직이 SPF 레코드에 악용 가능한 IP 주소를 가지고 있어 본의 아니게 대규모 스팸 및 피싱 캠페인의 발판을 마련할 수 있습니다. 그 연구가 발견한 것과는 관련이 없지만, 나는 최근에 잘못 구성된 SPF 레코드를 이용하는 잠재적으로 위험한 이메일에 대한 나만의 브러시를 갖게 되었습니다.
내 받은 편지함에 스푸핑된 이메일
최근에 저는 프랑스 보험 회사인 Prudence Cr에서 보낸 이메일을 받았습니다.éole, 그러나 모든 것을 가지고 있었다 스팸의 특징 스푸핑:
이메일의 보낸 사람: 주소 메시지 헤더를 위조하는 것은 사소한 일이라는 것을 알고 있지만 전체 이메일 헤더를 검사하고 SMTP 봉투 MAIL FROM: 주소의 도메인을 발견했을 때 호기심이 생겼습니다. reply@prudencecreole.com SPF 검사를 통과했습니다.
그래서 도메인의 SPF 레코드를 조회했습니다. prudencecreole.com:
그것은 IPv4 주소의 거대한 블록입니다! 178.33.104.0/2 에 이르기까지 IPv25 주소 공간의 4%를 포함합니다. 128.0.0.0 에 191.255.255.255. XNUMX억 개 이상의 IP 주소가 스패머의 천국인 Prudence Creole의 도메인 이름에 대해 승인된 발신자입니다.
농담이 아니었는지 확인하기 위해 집에 이메일 서버를 설치하고 인터넷 서비스 제공업체로부터 임의의 적격한 IP 주소를 할당받았으며 나에게 스푸핑 이메일을 보냈습니다. prudencecreole.com: 
성공!
무엇보다도 받은편지함에서 스푸핑이 발생한 다른 스팸 이메일에서 도메인의 SPF 레코드를 확인했습니다. wildvoyager.com:
보라, 보라 0.0.0.0/0 블록을 사용하면 4억 개 이상의 주소로 구성된 전체 IPvXNUMX 주소 공간이 Wild Voyager로 가장하여 SPF 검사를 통과할 수 있습니다.
이 실험 후 Prudence Cr에 알렸습니다.éole과 Wild Voyager가 잘못 구성된 SPF 레코드에 대해 이야기합니다. 신중함 Créole은 이 기사를 게시하기 전에 SPF 레코드를 업데이트했습니다.
반성 및 교훈
도메인에 대한 SPF 레코드를 만드는 것은 스패머의 스푸핑 노력에 대한 필살기가 아닙니다. 그러나 안전하게 구성된 경우 SPF를 사용하면 받은 편지함에 도착하는 것과 같은 많은 시도를 좌절시킬 수 있습니다. SPF의 즉각적이고 광범위한 사용과 보다 엄격한 적용을 가로막는 가장 중요한 장애물은 아마도 이메일 전달 가능성일 것입니다. SPF 게임을 하려면 두 사람이 필요합니다. 양쪽에서 사용하는 지나치게 엄격한 규칙으로 인해 이메일이 배달되지 않는 경우 발신자와 수신자 모두 이메일 보안 정책을 조화시켜야 하기 때문입니다.
그러나 도메인을 스푸핑하는 스패머의 잠재적 위험과 피해를 고려하여 다음 조언을 적절하게 적용할 수 있습니다.
- SPF 검증자가 다음을 따르는 경우 모든 HELO/EHLO ID에 대한 SPF 레코드를 생성합니다. RFC 7208의 권장 사항 이것들을 확인하기 위해
- 사용하는 것이 좋습니다 모든 메커니즘 "-" or "~" 한정자보다는 "?" 한정자, 후자 효과적으로 누구든지 귀하의 도메인을 스푸핑할 수 있습니다.
- "모두 삭제" 규칙 설정(v=spf1 -모두) 이메일을 생성(인터넷 라우팅)하거나 HELO/EHLO 또는 MAIL FROM: 명령의 도메인 이름 부분에 나타나서는 안 되는 소유한 각 도메인 및 하위 도메인에 대해
- 지침에 따라 일부 SPF 확인 프로그램에서 자동으로 무시되는 것을 방지하려면 SPF 레코드가 최대 512바이트까지 작아야 합니다.
- SPF 레코드에서 제한되고 신뢰할 수 있는 IP 주소 세트만 승인해야 합니다.
전자 메일을 보내는 데 SMTP를 널리 사용하면서 전자 메일을 안전하고 개인 정보 보호가 아닌 안정적이고 효율적으로 전송하는 데 중점을 둔 IT 문화가 만들어졌습니다. 보안에 초점을 맞춘 문화로 재조정하는 것은 느린 과정일 수 있지만 인터넷의 폐해 중 하나인 스팸에 대한 명확한 배당금을 얻기 위해 수행해야 하는 과정입니다.
