도메인 기반 메시지 인증
올해 초, CIS(인터넷 보안 센터) 20 중요 보안 제어 (새 탭에서 열림)를 준수하기 위한 전사적 노력의 일환으로 Tanium은 회사 이메일에 대해 DMARC(도메인 기반 메시지 인증, 보고 및 적합성)를 사용하여 보다 제한적인 구성을 구현했습니다. 예상대로 스팸 및 피싱 이메일의 수를 크게 줄였습니다. 그러나 배포하는 동안 예상치 못한 몇 가지 문제도 발생했습니다. DMARC를 구성하지 않기로 선택한 다른 회사의 수를 고려할 때, DMARC 개요, 구현과 관련된 일반적인 문제 및 그 과정에서 학습한 몇 가지 유용한 제안을 제공하여 경험을 공유하는 것이 도움이 될 수 있다고 생각했습니다.
DMARC는 두 가지 기술, 즉 SPF(Sender Policy Framework)와 DKIM(DomainKeys Identified Mail)을 사용하여 이메일 이 스푸핑되었는지 (즉, 조직에서 온 것처럼 보이도록 위조되었는지) 또는 귀사에서 합법적으로 전송되었는지를 확인합니다. SPF와 DKIM 모두 어디서나 참조할 수 있는 공개 DNS 레코드로 게시됩니다. 이러한 제어를 통해 수신 SMTP 서버는 수신 헤더를 검사하고 소스 및 무결성 키를 조직에서 게시한 것과 비교한 다음 메시지 격리와 같은 작업을 제공할지 또는 수행할지 여부를 결정할 수 있습니다. 그런 다음 이 정보는 개별 이메일 주소로 다시 보고되며, 이 이메일 주소는 이상 또는 문제에 대해 파싱하고 정렬할 수 있습니다.
SPF는 회사가 승인된 SMTP 보낸 사람으로 지정한 FQDN(정규화된 도메인 이름) 또는 IP 주소 목록입니다. 수신 SMTP 서버는 수신 메시지의 헤더를 구문 분석하여 발신 SMTP 서버를 결정할 수 있습니다. DKIM은 비대칭 암호화에 의존하는 훨씬 더 세분화된 제어입니다. Tanium은 DNS를 통해 공개 키를 게시하고 해당 미공개 개인 키를 안전하게 유지합니다. 회사를 대신하여 이메일을 보내려는 제3자도 공개/개인 키 쌍을 생성하고 DNS에 공개 키도 포함해야 합니다.
이메일이 도착하면 수신 서버는 메시지 헤더에서 첨부된 DKIM 키를 가져와 원본 서버에 쿼리하여 그 합법성을 확인합니다. 제공된 DKIM 키가 원래 서버의 개인 키와 일치하지 않으면 메시지가 스푸핑됩니다. 일치하는 항목이 있는 경우 원격 서버는 보낸 사람으로부터 전자 메일이 발송되었으며 안전하게 배달될 수 있음을 알고 있습니다.
구현 과제
SPF와 DKIM 모두 구현이 상당히 간단하지만 다른 조직이 참여하여 DNS 레코드를 올바르게 구성해야 합니다. 귀하를 대신하여 이메일을 전송할 제3자 소프트웨어를 고려할 때, SPF와 DKIM이 벤더에 의해 완전히 지원되는지 고려해야 합니다. 벤더가 SPF 및 DKIM을 적절히 구현하지 못하면 완전한 시행이 어렵거나 불가능해질 수 있습니다.
즉, 다른 조직이 SPF 및 DKIM을 올바르게 구성하더라도 추가 문제를 인식해야 합니다.
SPF 확장성
SPF는 여러 가지 다른 레코드 유형(A, MX, PTR, EXISTS, INCLUDE 및 REDIRECT 레코드 포함)으로 제한된 10개의 DNS 쿼리만 수행할 수 있습니다. 이 제한은 무한 레코드 검색을 방지하지만 SPF의 확장성도 제한합니다. 여러 조회가 필요한 리디렉션 및 기타 DNS 메커니즘은 제한을 신속하게 소진시킬 수 있으며 문제 해결에 혼란을 야기할 수 있습니다. 따라서 DNS 레코드를 사용하여 SPF를 구현하는 방법을 신중하게 고려하는 것이 매우 중요합니다. IP 주소/범위는 이 제한에 포함되지 않지만, FQDN을 사용하는 것과 비교할 때 변경된 IP 주소를 따라잡는 것은 리소스 집약적일 수 있습니다.
하위 도메인이 포함되지 않음
SPF는 레코드에 지정된 정확한 도메인 이름만 평가합니다. 하위 도메인은 포함되지 않습니다 . 예를 들어, @company.com SPF 레코드 IP 주소를 지정하고 해당 IP가 @_subdomain.company.com에서 전송하는 경우 _SPF 확인이 실패합니다. 각 하위 도메인에는 고유한 SPF 레코드가 있어야 합니다.
다른 도메인의 DKIM 키 사용
DKIM 키를 사용하면 다른 조직이 도메인에 대해 완전히 인증될 수 있습니다(따라서 사용자를 대신하여 확인된 이메일을 전송할 수 있음). 적절하게 구성된 제3자는 선택기 키를 제공할 수 있습니다(이 키는 기본적으로 개인 키를 제어하는 동안 공개 키를 대여 하는 것입니다). 개인 키를 소유하지 않더라도 DNS에서 선택기 키를 올바르게 구성하면 암호 해독 요청을 다시 제3자에게 전달하고 검증을 완료할 수 있습니다.
조직은 다음 옵션을 사용하여 SPF 또는 DKIM의 실패를 얼마나 엄격하게 제어할지 지정할 수 있습니다.
-없음: 메시지는 검토를 위해 소화되고 기록되지만, 여전히 불쾌한 메시지를 전달할 수 있음
-격리: 각 메일 제공자가 이 작업이 무엇인지 결정하지만, 대부분의 경우 사용자 거부
: SPF 또는 DKIM을 통해 정렬되지 않으면 메시지가 완전히 거부됩니다.
참고: DMARC 출력은 읽기 쉽지 않습니다. 결과는 XML 파일로 전달되며 메시지를 수신하는 모든 SMTP 서버에서 DMARC 정책에 지정된 전자 메일로 전송됩니다. 이메일 트래픽의 양에 따라 하루에 수천 개의 메시지가 전송되어 잠재적인 문제를 식별하고 해결하는 데 어려움을 겪을 수 있습니다.
환경을 제대로 이해하기 위해 DMARC/SPF/DKIM 레코드 자체에서 문제를 식별하고 SMTP 서버가 메시지가 정책을 위반한 것으로 판단했을 때 다시 전송되는 DMARC XML 보고서에 숨겨진 문제를 식별하는 데 도움이 되는 여러 도구가 있습니다. Tanium은 Dmarcian (새 탭에서 열림) 이라는 서비스를 사용하여 설정을 파싱하고 결과를 집계합니다.
완벽하지는 않지만, DMARC의 구현은 조직이 도메인 이름을 사용하여 이메일을 보내는 대상을 파악하고 제어할 수 있도록 하는 데 큰 도움이 됩니다. 이러한 도구를 효과적으로 활용함으로써 조직은 조직에 도달하는 악성 이메일의 양을 크게 줄이고 악성 사용자가 도메인을 스푸핑하는 것을 방지할 수 있습니다. DMARC는 조직에게 SMTP 서버를 수신하는 것이 “@yourdomain.com”에서 온 것으로 추정되는 합법적이고 불법적인 이메일에 대해 검증하고 조치를 취할 수 있는 방법을 제어합니다.
Tanium은 적절한 DMARC 구현을 구성함으로써 3 개의 서로 다른 CIS 영역에서 지원 제어 범위를 추가할 수 있었습니다.
- CSC 7: 이메일 및 웹 브라우저 보호
- CSC 8: 악성코드 방어
- CSC 9: 네트워크 포트, 프로토콜 및 서비스의 제한 및 제어
결론
이메일을 제공하는 도메인을 관리하는 경우 DMARC 구현을 적극 고려해야 합니다. 이는 각 개별 회사의 최선의 이익일 뿐만 아니라, 효과적으로 스푸핑할 수 있는 도메인의 수가 점점 줄어들기 때문에 이메일 에코시스템 전체가 혜택을 받을 것입니다. 도메인을 스푸핑할 가능성을 낮추면 사용자가 악용될 가능성이 줄어들고 사고에 대응하거나 다른 책임 문제를 처리하는 데 비용을 지출할 가능성이 줄어듭니다. 이는 CIS Top 20 컨트롤과 같은 사전 예방적 보안 조치를 완전히 구현하는 데 있어 작지만 중요한 부분이며, ISO 27002와 같은 표준 준수 프레임워크에 대한 인증 획득 요건을 충족하는 데 도움이 됩니다. 모든 규모의 기업의 건강과 복지에 적합합니다.
저자 소개: Eric Fisher는 노스캐롤라이나주 롤리에 있는 Tanium의 정보 보안 분석가 겸 엔터프라이즈 운영 설계 전문가입니다. Eric은 정보 보안 및 포렌식 석사 학위를 보유하고 있으며, 이전에 여러 포춘 500 대 은행, 소매업체 및 기술 회사에서 SOC 및 사고 대응 프로그램을 수립하는 보안 컨설턴트로 일했습니다. 또한 펜실베이니아 주 응용 연구 연구소와 Raytheon의 직원으로서 여러 정부 기관과 군대를 위한 대규모 컴퓨팅 아키텍처와 네트워크를 설계하고 보호했습니다.
