Exchange Server 2007

보낸 사람 ID로 스팸 및 피싱 방지

Craig Spiezle and Alexander Nikolayev

한 눈에 보기:

• 보낸 사람 ID 기본 사항
• Exchange Server에서 보낸 사람 ID 구성
• 인증의 이점

스팸의 위협이 증가함에 따라 많은 식별 및 필터링 기술이 개발되었습니다. 이러한 기술은 효과적으로 활용되기 위해 보낸 사람과 같이 각 전자 메일 메시지에 대해 특정 질문을 묻는 것에

의존합니다. 불행히도 메시지를 보낸 사람에 대한 기본적인 질문에도 대답하는 것이 쉽지 않은 경우가 있습니다. 전자 메일은 대개 보낸 사람이나 보낸 사람을 대신하는 컴퓨터에 대한 인증 없이 인터넷을 통해 전송됩니다. 실제로 손쉽게 다른 사람으로 가장하여 전자 메일 메시지를 보낼 수 있으며 스푸핑된 메시지를 자동으로 감지할 수 있는 방법도 없습니다.

전자 메일을 보내거나 받는 데 사용되는 SMTP(Simple Mail Transfer Protocol)는 전자 메일 메시지의 보낸 사람을 확인하도록 고안되지 않았으므로 이 기술의 허점을 이용하여 원하는 이름과 주소를 보낸 사람으로 삽입할 수 있습니다. 따라서 콘텐츠 필터링 또는 스팸 방지 수단에서 메시지의 보낸 사람이 실제로 해당 메시지를 보냈는지 확인할 때 머리글 정보에만 의존할 수는 없습니다.

전자 메일 인증은 특히 이 허점을 해결합니다. 인증을 사용하면 보내는 전자 메일 시스템과 받는 전자 메일 시스템 모두 메시지를 보냈다고 주장하는 도메인에서 정말로 해당 메시지를 보냈는지 확인합니다. 따라서 조직에서는 정크 메일을 효과적으로 필터링하는 동시에 합법적인 전자 메일은 지정된 받는 사람에게 전달하기가 한결 수월해집니다.

오늘날 사용료 없이 전자 메일을 인증하는 방법에는 SIDF(Sender ID Framework)와 DKIM(DomainKeys Identified Mail)의 두 가지가 있습니다. SIDF는 SPF(Sender Policy Framework)와 Microsoft Caller ID for E-Mail이 합쳐져 생성된 IP(인터넷 프로토콜) 기반 솔루션입니다. 2006년 4월 IETF(Internet Engineering Task Force)에서 RFC 4405-4408을 통해 보낸 사람 ID 사양을 발표했습니다. Microsoft를 포함한 업계와 회사 주주 연합에서는 비즈니스 및 기술 가치, 안정성, 완성도, 배포 용이성, 아웃바운드 또는 인바운드 성능에 미치는 최소 영향, ISP 및 엔터프라이즈 환경에 대한 전자 메일 에코시스템과의 상호 운용성 등을 고려하여 SIDF를 배포할 것을 권장합니다.

DKIM은 Yahoo! DomainKeys와 Cisco Systems Inc.의 IIM(Identified Internet Mail) 사양이 합쳐진 사양입니다. 2006년 1월 IETF는 DKIM 작업 그룹 창설을 승인했으며 사양은 현재 IETF의 검토 과정을 거치고 있습니다.

스팸을 완벽하게 방지하는 솔루션은 없지만 SIDF는 스푸핑된 도메인을 차단하기 위한 업계의 중요한 이니셔티브를 대변합니다. 따라서 SIDF는 스팸과 피싱 공격은 줄이고 온라인을 통한 신뢰와 확실함은 높이는 핵심 구성 요소입니다. 전 세계 조직에서 매우 빠른 속도로 SIDF를 채택하고 있습니다. 오늘날 550만 개가 넘는 회사와 도메인 보유자가 SPF 레코드를 게시하고 있으며 6억 명이 넘는 사용자가 SIDF로 보호되고 있습니다. 현재 전 세계의 일일 전자 메일 볼륨 중 1/3 이상이 이미 인증되어 SIDF를 준수합니다.

AOL, AOTA(Authentication and Online Trust Alliance), Bell Canada, ESPC(E-Mail Senders Provider Coalition), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign 등 많은 조직과 회사의 수고와 지원이 없었다면 SIDF의 개발과 전 세계적인 채택이 불가능했을 것입니다.

보낸 사람 ID 이해

일부 업계 조사에 따르면 피싱 메일의 95% 이상이 스푸핑된 도메인에서 비롯되고 스푸핑된 보낸 사람 전자 메일 주소를 가집니다. 스팸 방지 처리와 관련해서 SIDF가 큰 차이를 보이는 것이 바로 이 부분입니다. SIDF 자체는 스팸 문제를 해결하지 않지만 스팸과 피싱 공격의 결과를 최소화하는 데 크게 기여합니다. 또한 SIDF는 정크 전자 메일을 보내지 못하게 방지하지는 않지만 SIDF를 통해 정크 전자 메일을 훨씬 쉽게 검색할 수 있습니다. 이 프레임워크는 전자 메일 보낸 사람이 자신의 도메인 이름, 평판 및 브랜드를 보호할 수 있도록 하고 보낸 사람의 평판과 전자 메일 동작을 토대로 필터링할지 여부를 결정할 수 있는 확고한 기준을 제공합니다.

보낸 사람 ID는 모든 전자 메일 메시지에 대해 발송처로 표시된 인터넷 도메인과 실제 발송된 인터넷 도메인이 일치하는지 확인을 시도합니다. 이 작업은 전자 메일을 보내는 서버의 주소를 도메인 소유자가 전자 메일을 보낼 권한이 있는 등록된 서버 목록과 대조하여 확인하는 방식으로 수행됩니다. 확인 작업은 메시지가 사용자의 받은 편지함에 배달되기 전에 ISP(인터넷 서비스 공급자)나 받는 사람의 메일 서버에서 자동으로 수행됩니다.

보낸 사람 ID를 비롯한 인증 메커니즘이 콘텐츠 필터링 시스템을 대신할 수는 없습니다. SIDF와 DKIM은 실제 메시지 콘텐츠를 검사하지 않습니다. 대신 인증에서 메시지를 보냈다고 주장하는 보낸 사람이 해당 메시지를 보냈음을 확인할 수 있는지 여부를 인바운드 메일 시스템에 알립니다. 스팸 및 피싱 메시지는 대부분 표시된 도메인이 아닌 다른 도메인에서 발송되므로 이 방법을 사용하면 이러한 메시지를 자동으로 식별하여 수신 메일 스트림에서 분리할 수 있습니다.

SIDF에서 SPF 레코드는 도메인과 연결된 모든 아웃바운드 메일 서버의 간단한 텍스트 레코드를 해당 IP 주소와 함께 제공합니다. 조직에서 DNS 서버 영역 파일에 SPF 레코드를 게시하면 받는 사람 메일 서버가 해당 레코드를 확인합니다. SPF 레코드 설정은 빠르고 간편하며 무료입니다. Sender ID Framework SPF Record Wizard에서 도메인의 메일 서버를 조사하고 게시할 준비가 된 사용자 지정 레코드를 만드는 프로세스를 단계별로 안내합니다. SPF 레코드 게시에 대한 자세한 내용은 microsoft.com/senderid(영문)를 참조하십시오. 이 마법사는 microsoft.com/senderid/wizard(영문)에서 직접 액세스할 수 있습니다.

받는 SMTP 메일 서버는 DNS에서 도메인의 영역 파일을 핑하여 SPF 레코드의 존재 여부를 검사합니다. SPF 레코드가 있으면 보내는 서버의 IP 주소가 나열된 IP 주소에 있는지 확인합니다. 보내는 서버의 IP 주소가 나열된 IP 주소에 있으면 메시지가 인증된 것으로 확인됩니다. 반면에 보낸 사람의 도메인에 대한 SPF 레코드가 메시지를 보낸 IP 주소와 일치하지 않으면 인증이 실패하여 음수 점수로 표시되고 메시지가 정크 메일 폴더에 잠재적으로 배치됩니다. 그림 1에서는 이러한 프로세스를 보여 줍니다.

그림 1** 들어오는 메시지에 대한 SPF 레코드 검사 **(더 크게 보려면 이미지를 클릭하십시오.)

메시지에 태그가 지정되어 있는 경우 SIDF를 사용하여 받는 사람 메일 서버가 이전 동작, 보낸 사람의 평판, 해당 콘텐츠, 필요에 따라 정의할 수 있는 다른 조건 등을 기반으로 메시지를 분석할 수 있습니다. 이 기능은 추가 보호 기능을 제공합니다. 예를 들어 스패머가 비슷한 도메인과 게시된 SPF 레코드를 등록하여 해당 메일의 발송처가 합법적인 보낸 사람인 것처럼 사용자 및 수신 네트워크를 속일 수 있습니다. 이런 식으로 전자 메일 메시지가 인증 검사를 통과하더라도 보낸 사람의 평판이 스패머로 지정되어 있으므로 충분히 메시지를 차단하거나 폐기 또는 삭제할 수 있습니다.

보낸 사람 ID 배포 옵션

SIDF를 통한 아웃바운드 전자 메일 인증은 인프라 변경이나 소프트웨어 업데이트를 필요로 하지 않으며 특정 클라이언트 또는 서버 소프트웨어에만 제한되지도 않습니다. 그러나 인바운드 인증을 통합하여 회사와 직원들을 보호하려는 조직에서는 인바운드 시스템과 MTA(메시지 전송 에이전트)를 업데이트하고 SIDF를 지원하는 소프트웨어나 기기를 배포해야 할 수 있습니다. Microsoft® Exchange Server와 Exchange Hosted Filtering을 포함한 업계 최고의 상용 및 소스 개방형 MTA와 스팸 방지 업체 중 대부분이 통합 솔루션을 제공합니다.

Microsoft에서는 Microsoft Exchange Server 2003 서비스 팩 2(SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express, Office Outlook 메시징 및 공동 작업 클라이언트 등의 모든 메시징 제품에 SIDF를 통합했습니다.

그러나 Microsoft조차도 스팸 공격으로부터 벗어날 수 없습니다. Microsoft에는 일일 평균 약 1,500만 개의 메시지가 들어오는데, 최근 스팸 공격 중에는 해당 양의 2~4배가 목격되었습니다. 이와 같은 환경에서 스팸 방지의 성패는 사용 가능한 기술을 얼마나 세심하게 구현하느냐에 달려 있습니다.

Microsoft는 Exchange Server 2003의 보낸 사람 ID 필터와 Exchange Server 2007의 보낸 사람 ID 에이전트를 기반으로 한 내부 Exchange Server 스팸 방지 솔루션을 실행하고 있습니다. 두 버전의 Exchange Server 모두에서 보낸 사람 ID 상태는 해당 DNS 서버에 있는 보낸 사람 ID 레코드의 평가를 기반으로 합니다. 실제 도메인은 다음 우선 순위에 따라 RFC 2822 메시지 머리글을 검사하여 결정됩니다.

1. Resent-Sender
2. Resent-From
3. Sender
4. From

보낸 사람의 도메인(또는 전자 메일 시스템이 다른 메일 서버를 대신하여 메일을 합법적으로 전달할 수 있기 때문에 가장 최근에 메시지를 메시징 스트림에 넣는 작업을 담당한 엔터티)은 정의된 순서에 따라 방금 언급한 머리글의 첫 번째 정의를 찾아서 결정됩니다. 이러한 머리글을 찾을 수 없으면 SMTP RFC 2821 MAIL FROM 값이 사용됩니다.

보낸 사람 ID 구성

Exchange Server 2007에서는 Edge 전송 역할이 설치된 서버에서 보낸 사람 ID 에이전트를 사용하도록 설정할 수 있습니다. 보낸 사람 ID 에이전트를 사용하면 받는 커넥터를 통과하는 메시지가 필터링되고 외부 원본에서 들어오는 인증되지 않은 트래픽이 모두 보낸 사람 ID 처리를 거치게 됩니다. Exchange Server 2003에서는 보낸 사람 ID 상태가 EXCH50 Blob의 서버 간에 유지되지만 Exchange Server 2007에서는 메시지 메타데이터에도 추가되었습니다. 최종 목적지에서는 나중의 클라이언트가 사용할 수 있도록 둘 다 MAPI 속성으로 변환됩니다.

Exchange Server 2003의 메시지 배달 속성에서 사용할 수 있는 보낸 사람 ID 필터링 구성에서는 Exchange Server가 실패한 검증을 처리하는 방법만 지정할 수 있습니다.

Exchange Server 2007에서 보낸 사람 ID를 사용하려면 Edge 전송 역할이 구성된 서버의 Exchange Management Console(Exchange 관리 콘솔)을 열고 Anti-spam(스팸 방지) 탭과 Sender ID(보낸 사람 ID)를 차례로 선택한 다음 Actions(동작) 창에서 Enable(사용) 또는 Disable(사용 안 함)을 클릭하여 그림 2와 같이 보낸 사람 ID 에이전트의 상태를 전환합니다. 또한 그림 3과 같이 Exchange 관리 셸을 통해 보낸 사람 ID를 사용하거나 사용하지 않도록 설정할 수도 있습니다.

그림 2** Exchange Server 2007의 보낸 사람 ID 에이전트에 대한 Exchange 관리 콘솔 제어 기능 **(더 크게 보려면 이미지를 클릭하십시오.)

그림 3** Exchange 관리 셸을 통해 보낸 사람 ID 사용 설정 **(더 크게 보려면 이미지를 클릭하십시오.)

Sender ID Properties(보낸 사람 ID 속성) 대화 상자에는 에이전트 상태(사용 또는 사용 안 함)가 반영됩니다. Action(동작) 탭에는 Exchange Server 2003에서 사용할 수 있는 것과 매우 비슷한 옵션이 있습니다(그림 4 참조).

그림 4** Exhange Server 2007의 보낸 사람 ID 에이전트 동작 속성 **(더 크게 보려면 이미지를 클릭하십시오.)

보낸 사람 ID 구현과 기능 측면에서 Exchange Server 2003과 Exchange Server 2007 간에는 큰 차이가 없으며 보낸 사람 ID 필터(Exchange Server 2003)와 보낸 사람 ID 에이전트(Exchange Server 2007) 모두 추출과 확인 작업에 같은 기본 알고리즘을 사용합니다. 가능한 동작 범위도 메시지 삭제(자동 삭제), 메시지 거부(500 수준 SMTP 프로토콜 응답), 보낸 사람 ID 결과로 메시지를 스탬프 처리하고 계속 진행 등으로 같습니다. 이 마지막 옵션은 Exchange Server 두 버전 모두에서 기본 동작입니다.

Exchange Server 2007에서는 FAIL 상태 코드와 TempError 상태 코드가 모두 메시지 거부 동작을 트리거할 수 있지만 Exchange Server 2003에서는 FAIL 상태 코드만 이 동작을 트리거할 수 있습니다. TempError 상태 코드를 가진 메시지에 대해 메시지 거부 동작을 트리거하도록 보낸 사람 ID 에이전트를 명시적으로 구성합니다. 이는 기본적으로 이러한 메시지가 시스템에 받아들여지고 보낸 사람 ID 결과로 스탬프 처리된 다음 처리되기 때문입니다.

이에 대한 구성 옵션은 그래픽 사용자 인터페이스를 통해 제공되지 않으므로 Exchange 관리 셸을 사용하여 TempError 상태 코드에 대한 보낸 사람 ID 동작을 구성해야 합니다. 예를 들어 보낸 사람 ID 에이전트가 TempError 상태 코드를 가진 메시지를 거부하도록 설정하려면 다음 보낸 사람 ID 에이전트 cmdlet을 실행해야 합니다.

Set-SenderIDConfig -TempErrorAction Reject

Exchange Server 2007의 보낸 사람 ID 상태 결과 범위 및 가능한 동작은 Exchange Server 2003 보낸 사람 ID 필터와 비슷하며 그림 5에 나와 있습니다.

Figure 5 Exchange Server 2007의 보낸 사람 ID 상태 및 동작

Exchange는 보낸 사람 ID 확인에 실패한 메시지만 삭제합니다(이렇게 하도록 구성된 경우). 다른 결과는 메시지 삭제를 트리거하지 않습니다. Neutral, None, SoftFail, TempError 또는 PermError 상태로 지정되는 들어오는 메시지는 적절한 스탬프로 처리되어 추가 스팸 방지 확인을 위해 전달됩니다. 메시지가 복구할 수 없을 정도로 잘못되었고 FROM IP 주소가 누락된 경우 메시지에 보낸 사람 ID 상태로 스탬프 처리할 수 없는 경우가 있습니다. 이 경우 메시지는 삭제되거나 거부되지 않고 보낸 사람 ID 상태를 설정하지 않은 채 이후 처리를 위해 전달되고 이러한 상황을 알 수 있도록 적합한 이벤트가 기록됩니다.

Exchange Server 2007에서는 보낸 사람 ID 확인에서 제외해야 할 보낸 사람 도메인과 Exchange Server 받는 사람을 쉽게 정의할 수 있습니다. 또한 이 구성 옵션은 Exchange 관리 셸을 통해서만 사용할 수 있습니다. 예를 들어 보낸 사람 ID 필터링에서 contoso.com 도메인을 제외하려면 다음 명령을 실행하면 됩니다.

Set-SenderIDConfig -BypassedSenderDomains contoso.com

마찬가지로 보낸 사람 ID 필터링에서 지정된 Exchange Server 받는 사람에게 보내는 메시지를 제외하려면 다음 명령을 실행합니다.

Set-SenderIDConfig -BypassedRecipients user@contoso.com

Exchange Server 2007에서 그래픽 사용자 인터페이스를 통해서는 설정할 수 없지만 Exchange 관리 셸 cmdlet을 통해 설정된 보낸 사람 ID 구성 값은 그림 6과 같이 Exchange 관리 셸에서 Get-SenderIDConfig 명령을 실행하여 쉽게 확인할 수 있습니다.

그림 6** 보낸 사람 ID 구성 cmdlet **(더 크게 보려면 이미지를 클릭하십시오.)

Exchange 관리 셸을 사용하여 IP 주소와 해당 도메인 이름을 수동으로 빨리 확인할 수 있습니다. 보낸 사람 ID 상태를 확인하려면 다음 명령을 실행합니다.

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

도메인이 없으면 그림 7과 같은 결과가 표시됩니다.

그림 7** 주소의 보낸 사람 ID 상태 확인 **(더 크게 보려면 이미지를 클릭하십시오.)

보낸 사람 ID의 이점

전자 메일 메시지를 인증하고 사용자가 받는 스팸의 양을 줄이는 분명한 이점 외에도 SIDF는 프로토콜로서의 다른 이점을 제공합니다. Microsoft는 성능, 비용, 배포 및 확장성, 상호 운용성 등의 여러 가지 주요 목표에 초점을 맞추어 SIDF를 개발했습니다.

SIDF는 먼저 전자 메일 보낸 사람을 인증하고 보낸 사람의 평판 점수를 적용할 수 있도록 합니다. 이를 통해 스팸과 스푸핑된 전자 메일 메시지를 상당히 줄이고 알려진 보낸 사람과 트러스트된 보낸 사람이 보내는 합법적인 전자 메일의 전달 가능성을 개선할 수 있습니다. SPF 레코드를 만드는 것이 무료이므로 SIDF를 준수해야 하는 조직에서 해당 목적을 손쉽게 달성할 수 있습니다. 새 표준 조항을 준수해야 하는 조직에서도 해당 작업을 수행할 수 있습니다. SIDF를 사용하면 SPF 레코드를 게시하는 것만큼이나 쉽게 규정을 준수할 수 있습니다.

SIDF는 가능한 경우 기존 소프트웨어 내에서 작동하도록 개발되었으며 다양한 전자 메일 아키텍처와 클라이언트 및 서버 소프트웨어에 사용할 수 있습니다. SIDF를 효과적으로 사용하려면 인증 서비스가 가장 작은 가정용 메일 서버만큼이나 쉽게 가장 큰 ISP의 요구를 충족할 수 있어야 합니다. SIDF는 한 대의 전자 메일 서버에서 수천 대의 전자 메일 서버까지 지원할 수 있으며 전자 메일 서버를 다른 조직에 아웃소싱하는 조직도 지원합니다.

2007년 4월 18-19일 Microsoft와 30개가 넘는 조직 및 파트너로 이루어진 업계 컨소시엄이 미국 매사추세츠주 보스톤에서 Authentication & Online Identity Summit을 개최할 예정입니다. 이틀 간에 걸쳐 진행되는 이 프로그램에서는 사례 연구를 검토하고 보낸 사람 ID에 대한 기술 검토를 제공하며 전자 메일 인증의 비즈니스 가치에 대해 자세히 논의하게 됩니다. 자세한 내용은 aotalliance.org/summit2007을 참조하십시오. 또한 도구와 리소스 등에 대한 내용은 microsoft.com/senderid(영문)와 microsoft.com/korea/exchange를 참조하십시오.

Craig Spiezle은 Microsoft의 Windows Live Safety의 기술 전략 및 계획 담당 이사입니다. Craig는 전자 메일 인증 관련 제품 관리자로서 보낸 사람 ID를 업계에 전도하는 역할을 해왔으며 1992년부터 Microsoft에서 국제 마케팅, 제품 지원 전략, OEM, 신흥 시장 개발 등의 다양한 관리 업무를 담당했습니다.

Alexander Nikolayev는 Microsoft에서 Exchange Server와 Windows Server의 서버 쪽 프로토콜, 전송 코어 및 스팸 방지 구성 요소를 담당하는 프로그램 관리자이며 University of Mary에서 MBA를 취득했습니다. Exchange 팀 블로그인 blogs.technet.com/exchange(영문)에서 Alexander가 게시한 기사를 참조하십시오.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..