Communications

Microsoft의 Exchange Edge 전송 서버: 2부

Kay Unkroth

한 눈에 보기:

• Edge 전송 로그 및 추적 사용
• 스크립트로 스팸 방지 구성
• 일반적인 스팸 시나리오 테스트

이 기사의 코드 다운로드: Edge2007_11.exe (161KB)

인터넷을 통해 스팸과 기타 악의적인 콘텐츠가 대량으로 침투할 경우 조직 내의 사용자에게 안정적이고 안전한 메시징을 보장하려면 어떻게 해야 할까요? 지난달에 시작한 이 연재 기사의 1부에서 설명한 한 가지 방법으로

인터넷과 조직의 프로덕션 환경 사이에 있는 경계 네트워크에 Exchange Server 2007 Edge 전송 서버와 Forefront Security for Exchange Server를 배포하는 방법이 있습니다.

이 연재 기사 2부에서는 Exchange Server 2007의 표준 에이전트 로깅 및 추적 기능을 사용하여 작동 중인 Edge 전송 에이전트를 분석하는 방법을 설명합니다. 또한 사용자 지정 메서드를 사용하여 전송 파이프라인에서 XML 기반 파일로 모든 이벤트 개체를 덤프한 다음, Microsoft의 사내 프로덕션 환경에서 사용하는 구성에 따라 스팸 방지 설정을 Edge 전송 테스트 환경에 적용하는 방법에 대해 알아보겠습니다. 마지막으로 Edge 전송 에이전트가 다양한 스팸 상황에 대응하는 방법을 보여 주는 실제적이고 흥미로운 테스트 시나리오로 결론을 짓겠습니다.

Edge 전송 테스트 환경 설치와 일반 Edge 전송 아키텍처에 대한 자세한 내용은 TechNet Magazine 2007년 10월호에서 본 연재물의 1부(technetmagazine.com/issues/2007/10/Edge)를 참조하십시오.

필자는 스크립트와 배치 파일을 많이 사용하여 가장 중요한 구성 작업을 자동화하는데, 이러한 스크립트는 본 기사와 함께 제공되는 코드 다운로드(technetmagazine.com/code07.aspx 참조)에서 확인할 수 있습니다. 또한 Microsoft IT의 Edge 전송 에이전트 구성에 대한 자세한 배경 정보는 Microsoft IT Showcase용으로 작성된 기술 백서 "Microsoft® Exchange Server 2007 Edge 전송 및 메시징 보호"를 참조하십시오. 이 IT Showcase 백서는 microsoft.com/technet/itshowcase/content/edgetransport.mspx에서 다운로드할 수 있습니다.

로깅 및 추적

Exchange Server 2007에는 프로토콜 로깅, 에이전트 로깅, 파이프라인 추적을 포함하여 전송 에이전트 문제의 진단과 문제 해결을 돕는 다양한 로깅 및 추적 기능이 포함되어 있습니다. 이 기사가 전송 에이전트 문제를 해결하기 위한 것은 아니지만 로깅 및 추적 정보는 Edge 전송 에이전트의 작동 방식을 조사할 때 유용합니다.

SMTP 송수신 작업에 대한 정보를 추적하려면 송신 커넥터와 수신 커넥터에 프로토콜 로깅을 사용해야 합니다. 본 연재물의 1부에서 설정한 테스트 환경(그림 1 참조)을 사용하여 필자는 New-SendConnector 및 New-ReceiveConnector cmdlet에서 다음 설정을 통해 프로토콜 로깅을 사용하도록 구성했습니다.

그림 1** 테스트 환경 **

–ProtocolLoggingLevel: Verbose

기본적으로 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog 아래의 하위 폴더에서 결과 SMTP 로그 파일을 찾을 수 있습니다.

프로토콜 로깅은 SMTP 대화를 분석하려는 경우에 유용하지만, 스팸 방지 에이전트가 항상 SMTP 세션을 방해하는 것은 아닙니다. 예를 들어 콘텐츠 필터 에이전트가 SCL(스팸 지수) 값으로 인바운드 메시지를 스탬프 처리만 할 수 있습니다. SCL 등급이 지정된 임계값(기본값: 7)보다 낮기만 하면 콘텐츠 필터 에이전트는 Edge 전송 프로세스가 메시지를 거부하도록 하지 않습니다. 따라서 SMTP 대화가 영향을 받지 않고 진행됩니다.

스팸 방지 에이전트(연결 필터, 콘텐츠 필터, Edge 규칙, 받는 사람 필터, 보낸 사람 필터, 보낸 사람 ID)가 전송 파이프라인을 통과하는 메시지에서 수행하는 작업을 분석하려면 프로토콜 로그 대신 에이전트 로그를 검사해야 합니다. 에이전트 로깅은 대개 EdgeTransport.exe.config 파일의 AgentLogEnabled 매개 변수에 따라 활성화됩니다. 기본적으로 에이전트 로그는 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog 폴더에 있습니다. 이 로그는 메모장에서 열 수 있지만 Get-AgentLog cmdlet을 사용하면 Exchange 관리 셸에 더욱 알기 쉽게 에이전트 로그 정보가 표시됩니다.

또 다른 유용한 기능인 파이프라인 추적을 사용하면 특정한 보낸 사람이 보낸 메시지가 전송 파이프라인을 통과할 때 해당 메시지의 스냅숏을 캡처할 수 있습니다. 개념은 비교적 간단합니다. 즉, Edge 전송 프로세스는 OnEndOfHeaders, OnEndofData, OnSubmittedMessage 및 OnRoutedMessage 이벤트에 대해 등록된 SMTP 수신 및 라우팅 에이전트를 호출하기 전과 후에 각 메시지의 스냅숏을 만듭니다. 메시지 스냅숏을 비교하면 개별 에이전트가 각 메시지를 어떻게 수정하는지 알 수 있습니다. 물론 테스트 환경에서 이 중요한 기능을 사용하도록 설정해야 합니다.

다음과 같이 Set-TransportServer cmdlet을 사용하면 테스트 사용자의 파이프라인 추적이 활성화됩니다. 예상할 수 있겠지만 PipelineTracingEnable 매개 변수를 $true로 설정하면 파이프라인 추적이 사용됩니다. 테스트 사용자의 전자 메일 주소는 PipelineTracingSenderAddress 매개 변수에서 설정됩니다.

Set-TransportServer –Identity EDGE01 
–PipelineTracingEnabled $true 
-PipelineTracingSenderAddress Contoso.User@contoso.com

파이프라인 추적을 사용할 경우 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots 폴더에서 지정된 보낸 사람(이 경우 Contoso.User@contoso.com)이 보낸 각 메시지의 메시지 스냅숏 파일을 찾을 수 있습니다. 이는 기본 폴더입니다. 각 메시지의 스냅숏 파일은 해당 메시지에 할당된 GUID에 따라 이름이 지정된 하위 디렉터리에 있습니다. 원본 메시지는 Original.eml이라는 파일에서 찾을 수 있고 메시지 복사본은 발생한 이벤트와 설치된 에이전트에 따라 SmtpReceive나 Routing으로 시작하는 .eml 파일에서 찾을 수 있습니다. SMTP 수신 이벤트 OnEndofData와 OnEndOfHeaders용으로 등록된 스팸 방지 에이전트의 처리를 분석하려면 SmtpReceive*.eml 파일을 검사합니다. 라우팅 이벤트 OnSubmittedMessage와 OnRoutedMessage용으로 등록된 바이러스 백신 및 기타 에이전트의 처리를 분석하려면 대신 Routing*.eml 파일을 분석합니다.

사용자 지정 파이프라인 덤프

Exchange Server 2007의 표준 에이전트 로깅 및 추적 기능이 모든 문제 해결 요구를 처리하지만 표준 기능이 모든 전송 이벤트를 다루지는 않습니다. 예를 들어 송신 호스트가 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing 폴더에 기록될 수 있는 메시지를 아직 전송하지 않았기 때문에 파이프라인 추적은 OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand 및 이와 유사한 전송 이벤트에 대한 정보를 캡처할 수 없습니다. 이러한 이벤트에 대한 자세한 정보를 캡처하려면 이벤트 데이터를 파일 시스템의 파일로 덤프하는 사용자 지정 에이전트를 구현해야 합니다.

1부에서 설명한 바와 같이 사용자 지정 에이전트를 만드는 것은 복잡하지 않으므로 전송 파이프라인에서 XML 파일로 모든 이벤트 개체를 덤프하는 SMTP 수신 에이전트와 라우팅 에이전트를 만들 수 있습니다. 이 기사에서 제공하는 다운로드 파일에서 PipelineXMLDump라는 해당 Microsoft Visual Studio® 2005 프로젝트를 확인할 수 있습니다. 이 프로젝트에서 중요한 두 개의 파일에는 에이전트 팩터리 및 에이전트를 구현하는 DumpAgents.cs와 System.Reflection 메서드를 통해 이벤트 원본 및 이벤트 인수 개체의 필드를 XML 파일에 기록하는 도우미 클래스를 구현하는 XMLDump.cs가 있습니다. 소스 코드를 컴파일하고 결과 PipelineXMLDump.dll 파일을 Edge 전송 테스트 서버의 C:\PipelineXMLDump라는 폴더에 복사하면 RegisterPipelineXMLDump.ps1 및 EnableDumpAgents.ps1 스크립트를 사용하여 사용자 지정 에이전트를 등록하고 사용할 수 있습니다. 스크립트는 다운로드 파일의 PipelineXMLDump 프로젝트 폴더에 포함되어 있습니다. 물론 필자의 사용자 지정 에이전트는 설명 용도로만 만들어졌고 충분히 테스트되지 않았으며 프로덕션 서버에 설치하면 안 됩니다. 이러한 에이전트 사용 결과에 대한 모든 책임은 해당 사용자에게 있습니다.

DumpAgents.cs는 전송 파이프라인에서 지원하는 모든 SMTP 수신 및 라우팅 이벤트 처리기를 구현하는 방법을 보여 줍니다. 이 스크립트는 사용자 지정 에이전트를 직접 구현하려는 경우에 좋은 출발점이 될 수 있습니다. 필자의 덤프 에이전트는 SMTP 세션 식별자(SMTP 수신 에이전트)나 메시지 식별자(라우팅 에이전트)에 해당하는 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump 아래의 하위 폴더에 XML 파일을 기록합니다. 그림 2에는 OnConnectEvent 처리기에서 SMTP 수신 에이전트에 전달된 이벤트 인수 정보를 보여 주는 예가 나와 있습니다. 이 예에서 받는 연결 요청을 수락한 로컬 IP 끝점(IP 주소 및 포트)을 알 수 있습니다.

그림 2** OnConnect 이벤트 중에 덤프된 인수 정보 **(더 크게 보려면 이미지를 클릭하십시오.)

테스트 실행 준비

로깅, 추적 및 덤프에 대한 이론을 충분히 살펴보았으므로 이제 스팸 방지 에이전트의 실제 작동을 보여 주는 몇 가지 테스트 실행을 준비해 보겠습니다. 다음은 Microsoft IT의 구성과 최대한 유사하게 사용자의 테스트 환경에서 구성하는 방법에 대한 간략한 설명입니다. 앞서 설명한 바와 같이 배경 정보는 기술 백서 "Microsoft Exchange Server 2007 Edge 전송 및 메시징 보호"에서 확인할 수 있습니다.

먼저, 함께 제공되는 다운로드 파일에서 EDGE01_disable_agents.ps1 스크립트를 실행하여 주소 다시 쓰기 인바운드 에이전트, 첨부 파일 필터 에이전트 및 주소 다시 쓰기 아웃바운드 에이전트를 비활성화합니다. 받는 사람이 내부와 외부에서 동일한 전자 메일 주소를 사용하기 때문에 주소 다시 쓰기는 필요 없습니다. Forefront Security에서 대체 첨부 파일 필터링 기능을 사용할 수 있으므로 필자는 첨부 파일 필터 에이전트를 사용하지 않습니다.

테스트 환경은 인터넷에 연결되어 있지 않으므로 연결 필터 에이전트를 테스트하기란 어렵습니다. 이 문제를 해결하기 위해 INTERNET01_create_IP_block_list.bat 파일을 실행하여 인터넷 호스트에 IP 차단 목록을 만들 수 있습니다. DNS 명령줄 도구(dnscmd.exe)가 포함된 Windows® 지원 도구를 설치해야 합니다. 그렇지 않으면 DNS 콘솔을 사용하여 수동으로 DNS 레코드를 만드느라 시간을 허비해야 합니다.

이제 EDGE01_add_block_list_provider.ps1 스크립트를 실행하여 연결 필터 에이전트를 구성할 수 있습니다. 이 스크립트는 ip-bl.consolidatedmessenger.com의 IP 차단 목록 공급자를 추가합니다. 이 목록은 앞서 언급한 바와 같이 인터넷 호스트에서 INTERNET01_create_IP_block_list.bat 파일을 실행하여 테스트 환경에 이미 만들어 놓은 통합 메신저의 IP 차단 목록입니다. Microsoft IT에서는 로컬 IP 차단 목록과 IP 허용 목록도 사용하지만 이들 기능에는 수동 구성이 필요하지 않습니다. Microsoft IT는 IP 허용 목록 공급자를 사용하지 않는다는 점을 알아야 합니다.

그런 다음 EDGE01_recipient_filter.ps1 스크립트를 실행하여 존재하지 않는 받는 사람에 대한 메시지 및 내부 또는 아웃바운드 전용 사서함과 전체 메일 그룹에 대한 메시지를 차단하도록 받는 사람 필터 에이전트를 구성합니다.

보낸 사람 필터 에이전트에도 구성 업데이트가 필요합니다. Microsoft IT에서는 보낸 사람 필터링을 특정 보낸 사람 주소에서 전송되는 메일 폭탄 공격에 대한 대응책으로 사용하고 업무와 관련이 없는 것으로 간주되는 특정 목록 서버와 유사 원본을 차단하는 용도로도 사용합니다. 또한 Microsoft IT에서는 보낸 사람 필터링을 사용하여 보낸 사람 정보가 잘못되었거나 누락된 메시지를 차단합니다. Edge 전송 서버에서 EDGE01_sender_filter.ps1 스크립트를 실행하여 이 구성을 테스트 환경에 적용해 보겠습니다.

Microsoft IT의 구성과 유사하게 구성하려는 경우에는 DNS에서 SPF(Sender Policy Framework) 레코드도 구성해야 합니다. adventure-works.com 도메인에서 보낸 메시지에 대해 Edge 전송 서버의 권한을 증명하는 SPF 레코드를 생성하기 위해 microsoft.com/mscorp/safety/content/technologies/senderid/wizard에서 제공하는 Microsoft Sender ID Framework SPF Record Wizard를 사용할 수 있습니다. 이 마법사를 사용하여 기존 인터넷 도메인 이름을 지정해 봅니다. 테스트 환경의 경우 인터넷 호스트에서 INTERNET01_create_SPF_record.bat 파일을 실행할 수 있습니다.

이제 다 되었습니다. 대부분의 에이전트가 적절한 기본값으로 설정되어 제공되기 때문에 추가로 구성해야 할 매개 변수는 없습니다. Edge 규칙, 보낸 사람 ID, 프로토콜 분석 및 콘텐츠 필터 에이전트의 가장 중요한 기본 설정을 빠르게 검사하려면 Edge 전송 서버에서 EDGE01_check_defaults.ps1 스크립트를 실행합니다.

Edge 전송 에이전트 실제 적용

이제 몇 가지 실제 메시징 시나리오에서 Edge 전송 에이전트를 실행해 보겠습니다. Edge 전송 서버에 테스트 메시지를 보내기 위해 필자는 Windows Server 2003에 포함된 SMTP 및 POP3 서비스를 사용했으며 Outlook® Express를 메시징 클라이언트로 사용했습니다. 이때 로깅을 사용하도록 설정한 것을 제외하고 다른 부분은 대부분 기본 설정을 사용합니다.

그러나 먼저 테스트 환경이 프로덕션 시스템이나 인터넷에 연결된 경우에는 이 섹션에 설명된 단계를 따르거나 이 섹션에 설명된 스크립트를 실행하지 마십시오. 테스트 결과에 대한 책임은 해당 사용자에게 있습니다.

가장 먼저 테스트할 에이전트는 연결 필터 에이전트입니다. 이 에이전트는 Edge 전송 서버에서 가장 많이 작동하는 에이전트이므로 맨 먼저 테스트할 가치가 있습니다. Microsoft에서 연결 필터 에이전트는 모든 인터넷 메시지 전송의 약 88%를 차단합니다. 업무일 기준으로 하루 1,300만 건의 전송 시도 중에서 합법적인 보낸 사람이 보낸 메시지는 약 150만 건입니다.

이제 Fabrikam.User@Fabrikam.com이라는 계정으로 Administrator@adventure-works.com에 전자 메일을 보내겠습니다. 제대로 작동할 경우 Administrator가 메시지를 수신하면 안 됩니다. 대신에 Fabrikam.User가 받는 사람에게 배달하지 못했다는 DSN(배달 상태 알림)을 수신해야 합니다. Fabrikam.User는 전자 메일 주소가 올바른지 확인하고 동일한 메시지를 다시 보내지만 이번에도 다시 DSN을 수신합니다. 그러자 Fabrikam.User는 지원 부서에 전화를 걸어 문제를 보고합니다. Fabrikam.User에게만 이 문제가 발생한 것은 아닙니다. 실제로 Fabrikam의 어떤 사용자도 Adventure Works와 더 이상 통신할 수 없습니다. 어떠한 문제가 발생한 것입니다. 긴급히 해결해야 할 문제입니다. 신속히 해결하기 위해 INTERNET01의 %systemroot%\system32\Logfiles\SMTPSVC1 폴더에서 SMTP 로그를 검사하면 그림 3에 빨간색 텍스트로 표시된 것처럼 문제를 확인할 수 있습니다.

Figure 3 문제를 보여 주는 SMTP 로그

... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu, 
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by 
ip-bl.consolidatedmessenger.com. Please visit 
http://www.consolidatedmessenger.com/ip-bl for more information. 
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,

550 오류 응답은 통합 메신저가 사용자의 인터넷 호스트 IP 주소를 IP 차단 목록에 넣었다는 것을 나타냅니다. 이것만 해결하면 되겠네요. 통합 메신저의 차단 목록에서 해당 IP 주소가 제거되도록 하면 됩니다. 알다시피 통합 메신저의 차단 목록에 넣는 것이 이 목록에서 제거하는 것보다 쉽습니다. 이것을 정리하려면 몇 주는 아니더라도 며칠 정도 걸릴 것입니다.

더욱 신속한 도움이 필요하므로 전자 메일 주소 cmipbl@adventure-works.com을 통해 Adventure Works에 연락합니다. Fabrikam.Admin@Fabrikam.com 계정을 사용하여 상황을 설명하고 호스트 인터넷 IP 주소(이 경우 192.168.1.100)에 대한 차단을 해제해 달라고 요청하는 전자 메일을 보냅니다. 그러면 Adventure Works는 ID를 확인한 후 다음 명령을 사용하여 30일 후 자동으로 만료되는 임시 예외를 부여하여 주소 차단을 해제합니다.

Add-IPAllowListEntry -IPAddress 192.168.1.100 
-ExpirationTime (get-date).AddDays(30)

30일이면 통합 메신저와의 설정을 정리하는 데 충분하므로 Adventure Works가 수동으로 예외를 유지 관리하느라 시간을 허비하지 않아도 됩니다. Adventure Works는 자동으로 만료되는 예외를 부여함으로써 IP 허용 목록을 유지 관리하는 것과 관련된 관리 오버헤드를 최소한으로 유지합니다.

수신 허용 - 보낸 사람

이제 스팸 필터링의 정확도를 높여 주는 흥미로운 새 기능인 콘텐츠 필터링의 수신 허용 - 보낸 사람 인식 기능을 테스트해 보겠습니다. EdgeSync는 해시되고 암호화된 형식으로 내부 환경에서 Edge 전송 서버로 수신 허용 - 보낸 사람 정보를 전달합니다. 콘텐츠 필터 에이전트는 필터링 과정에 이 정보를 사용하여 올바른 의사 결정을 내립니다. Update-SafeList cmdlet을 사용한 다음 Start-EdgeSynchronization cmdlet을 통해 정보를 Edge 전송 서버에 복제하여 수신 허용 - 보낸 사람 정보(즉, 수신 허용 - 보낸 사람 목록, 수신 허용 - 받는 사람 목록, 수신 거부 목록 및 외부 연락처)를 Active Directory®에 제공하기만 하면 됩니다. Microsoft IT에서는 사용량이 적은 시간에 정기적으로 Update-SafeList cmdlet을 실행합니다. 테스트 환경에서는 해당 스크립트(HUB-MBX-01_update_safelist.ps1)를 수동으로 실행하는 것으로 충분합니다.

먼저 Edge 전송 서버에서 EDGE01_clean_up.ps1 스크립트를 실행하여 앞서 만든 IP 허용 목록 항목을 제거하도록 테스트 환경을 정리합니다. 이 작업이 필요한 이유는 콘텐츠 필터 에이전트가 이 목록에 있는 원본에서 보낸 메시지에 대해 작동하지 않기 때문입니다. 그런 다음 인터넷 호스트에서 INTERNET01_clean_up.bat 파일을 실행하여 통합 메신저 차단 목록에서 100.1.168.192.ip-bl.consolidatedmessenger.com의 IP 차단 목록 항목을 제거합니다. 그렇지 않으면 앞서 설명한 바와 같이 시뮬레이션된 인터넷 호스트에서 메시지를 보낼 수 없게 됩니다.

마지막으로 콘텐츠 필터 에이전트가 스팸으로 간주할 가능성이 매우 높은 메시지를 보냅니다. 콘텐츠 필터 에이전트가 기본 SCL 거부 임계값을 통해 대부분의 메시지를 사용자에게 배달하여 가양성(False Positive)을 최소화하기 때문에 이렇게 하는 것은 쉽지 않습니다. 그러나 약간의 테스트를 수행한 후 필자는 SCL 등급을 거부 수준으로 올리는 메시지 버전을 하나 발견했습니다. Contoso.User@Contoso.com 계정을 사용하여 메시지를 보내려면 인터넷 호스트에서 INTERNET01_contoso_msg.vbs 스크립트를 실행합니다.

필자의 스크립트는 익명 SMTP 연결을 사용하여 메시지를 INTERNET01의 SMTP 서비스에 전송합니다. 이렇게 하려면 익명 사용자의 메시지를 릴레이하도록 SMTP 서비스를 구성해야 합니다. IIS 관리자에서 기본 SMTP 가상 서버의 속성을 엽니다. 액세스 탭에서 릴레이 단추를 클릭한 다음 아래 목록을 제외한 모든 항목을 선택합니다. 이 구성이 의미하는 것은 잠시 후 다루게 됩니다.

스크립트를 실행하여 이 메시지를 보내면 Contoso.User는 "Diagnostic-Code: smtp;550 5.7.1 Message rejected due to content restrictions(진단 코드: smtp;550 5.7.1 콘텐츠 제한으로 인해 메시지가 거부됨)"와 함께 배달하지 못했음을 알리는 DSN을 수신합니다. 인터넷 호스트의 SMTP 로그에서 이 응답을 볼 수도 있으며, Edge 전송 서버에서 Get-AgentLog | Select-Object -Last 1 명령을 실행하여 에이전트 로그의 마지막 항목을 표시하는 경우 그림 4와 같이 해당 SCL 등급이 7이기 때문에 메시지가 거부되었음을 알 수 있습니다.

그림 4** 콘텐츠 제한으로 인해 메시지가 거부됨 **(더 크게 보려면 이미지를 클릭하십시오.)

이제 Contoso.User는 스패머가 아닙니다. 아쉽게도 이 경우에는 Contoso.User의 메시지가 통과하지 않았지만 일반적으로 Contoso.User는 Adventure Works에 있는 받는 사람과 통신할 수 있습니다. 따라서 Contoso.User는 Administrator에게 자신의 원본 메시지가 실수로 차단되었다고 또 다른 전자 메일을 통해 알립니다. Administrator는 Contoso.User를 알고 있으며 스팸 필터가 향후 더 이상 Contoso.User의 메시지를 차단하지 않도록 하기 위해 Contoso.User를 수신 허용 - 보낸 사람 목록에 추가합니다. Office Outlook 2007에서 이 작업을 수행하려면 Contoso.User로부터 수신된 메시지를 마우스 오른쪽 단추로 클릭하고 정크 메일을 가리킨 다음 수신 허용 - 보낸 사람 목록에 보낸 사람 추가를 클릭합니다.

이제 평상시 간격에 따라 Update-SafeList cmdlet이 실행되어 Active Directory의 수신 허용 목록 정보를 새로 고치며, 다음 Edge 동기화 후 Contoso.User는 가양성 없이 Administrator와 통신할 수 있습니다. 이 과정을 시뮬레이션하려면 HUB-MBX-01_update_safelist.ps1 스크립트를 실행합니다.

이제 INTERNET01_contoso_msg.vbs 스크립트를 실행하여 Contoso.User의 메시지를 다시 보냅니다. 나중에 Get-AgentLog | Select-Object -Last 1 명령을 사용하여 Edge 전송 서버의 에이전트 로그를 검사하면 ReasonData 아래에서 콘텐츠 필터링이 무시되었음을 알 수 있습니다. Contoso.User의 경우 더 이상 가양성이 나타나지 않습니다.

스팸 공격

테스트 실행을 마무리하기 위해 해외로 나가 보겠습니다. 이미 살펴봤듯이 필자는 이전 테스트를 실행하는 동안 인터넷 호스트를 오픈 릴레이로 구성했습니다. 따라서 스패머에게 문이 열립니다. 이제 Spam.Sender@cohovineyards.com이 이러한 취약한 구성을 알아채고 호스트를 악용하여 수천 건의 스팸 메시지를 Adventure Works에 보내면 어떻게 되는지 알아보겠습니다. INTERNET01_spam_msg.vbs 스크립트는 하나의 스팸 메시지만 전송하지만 이 스크립트를 편집하여 max_loop 값을 변경하면 더 많은 스팸 메시지를 생성할 수 있습니다.

스팸 공격을 시뮬레이션하기 위해 필자는 Edge 전송 서버로의 릴레이를 위한 1,000건의 메시지를 손상된 호스트에 전송했습니다. SMTP 서비스가 아웃바운드 연결당 메시지 수를 20개로 제한하므로 Edge 전송 서버의 프로토콜 분석 에이전트가 투입되기 전에 충분한 개수의 스팸 메시지를 릴레이하려면 약간의 시간이 걸립니다.

프로토콜 분석 에이전트는 SMTP 프로토콜 분석과 Microsoft Update의 IP 신뢰도 업데이트를 기반으로 IP 차단 목록 항목을 자동으로 유지 관리하여 연결 필터 에이전트를 지원합니다. 이 경우 SMTP 프로토콜 분석이 스팸 전자 메일 메시지를 발견했습니다. 프로토콜 분석 에이전트는 각 메시지의 SCL 등급을 계속 추적하여 SRL(보낸 사람 신뢰도 수준) 결정에 사용할 평균 SCL 값을 계산합니다. 시뮬레이션된 스팸 활동 기간 동안 전송되는 불법적인 메시지의 수가 점차 늘면서 인터넷 호스트의 SRL도 증가하고 결국 SRL 차단 임계값을 초과하게 됩니다. 따라서 호스트는 IP 차단 목록에 24시간 동안 유지되었습니다. 더 이상은 이 호스트에서 스팸이 수신되지 않습니다. 이것은 자동으로 수행되었으며 관리자의 작업이 필요하지 않았습니다.

그림 5에서는 결과 IP 차단 목록 항목과 메시지 처리의 해당 변경 내용을 보여 줍니다. Edge 전송 서버는 SCL 임계값(그림 4 참조)을 기반으로 각 메시지에 대해 작동하는 콘텐츠 필터 에이전트이기 때문에 호스트를 차단하기 전에 OnEndOfData 이벤트 동안 각 스팸 메시지를 거부했습니다. 메시지는 실패하기는 했지만 전송되었습니다. 호스트를 차단한 후 OnMailCommand 이벤트 동안 연결 필터 에이전트가 연결을 거부했습니다. 메시지는 더 이상 전송되지 않았습니다. 스패머가 메시지를 전송하기 전에 해당 연결이 끊겨서 네트워크 대역폭과 처리 리소스가 절약됩니다.

그림 5** 공격하는 인터넷 호스트 중지 **(더 크게 보려면 이미지를 클릭하십시오.)

추가 테스트

물론 더 많은 에이전트 기능과 시나리오를 테스트할 수 있습니다. 예를 들어 Blocked.User@Contoso.com 또는 Blocked.User@Fabrikam.com 계정을 사용하여 메시지를 보내서 보낸 사람 필터링을 테스트할 수 있습니다. Blocked.User@adventure-works.com에게 메시지를 보내서 받는 사람 필터링을 테스트할 수 있습니다. 텔넷을 사용하여 타피팅 간격을 달리하면서 디렉터리 수집 공격을 시뮬레이션할 수도 있습니다. Microsoft IT에서는 5초의 기본 간격을 인터넷에 연결된 수신 커넥터의 SMTP 5yz 응답에 사용하는데, 이는 Microsoft IT가 스패머의 디렉터리 수집 공격을 무력화하기에 충분한 시간입니다. 그러나 EDGE01_tarpitting.ps1 스크립트에서 설명한 바와 같이 Set-ReceiveConnector cmdlet을 사용하여 다른 값을 적용할 수 있습니다.

더 자세히 들어가서 Contoso.User@Contoso.com에서 보낸 메시지에 대해 파이프라인 추적이 만드는 스냅숏 파일을 검사할 수도 있습니다. Forefront Security가 메시지를 검사한 것으로 표시하는 데 사용하는 바이러스 백신 스탬프인 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0을 살펴봅니다. 허브 전송 서버의 Forefront Security가 최신 버전 정보가 있는 이 스탬프를 찾는 경우 메시지를 다시 검사하지 않아도 됩니다. 가짜 바이러스 백신 스탬프를 테스트 메시지에 삽입하여 Forefront Security를 속이려고 하면 실행되고 있는 헤더 방화벽이 이를 검색합니다. 이 헤더 방화벽은 FSE 라우팅 에이전트를 호출하는 OnSubmittedMessage 이벤트가 트리거되기 훨씬 전인 OnDataCommand 이벤트 직후에 이 스탬프를 제거합니다.

스냅숏 파일에서 메시지 헤더를 확인하는 동안 아마도 Contoso.com에 대해 잘못된 IP 주소를 합법적인 보낸 사람으로 식별하는 SPF 테스트 레코드를 만들 수도 있습니다. 이렇게 하는 방법 중 하나는 인터넷 호스트에서 INTERNET01_wrong_SPF_record.bat 파일을 실행하는 것입니다. 그런 다음 Contoso.User@Contoso.com 계정을 사용하여 테스트 메시지를 보내고 X-MS-Exchange-Organization-SenderIdResult 및 Received-SPF 헤더를 살펴보아야 합니다.

X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

결론

본 연재물의 1부와 2부에서 살펴보았듯이 Exchange Server 2007 Edge 전송 서버는 연결 필터링, 프로토콜 분석 및 콘텐츠 필터링을 포함하여 안정적이고 정확도가 뛰어난 스팸 방지 기능을 구현하는 종합적인 전송 에이전트를 제공합니다. 전송 아키텍처는 확장이 가능하며 추가 기능을 위한 추가 에이전트 구현을 지원합니다. FSE 라우팅 에이전트는 Forefront Security for Exchange Server를 전송 아키텍처에 통합하는 추가 에이전트의 좋은 예가 됩니다.

연결 타피팅, 헤더 방화벽, TLS 및 인증과 같은 추가 기능을 사용하여 Edge 전송 서버는 여러 수준에서 단일 장애 지점 없이 매우 높은 수준으로 메시징을 보호하는 데 필요한 방법을 제공합니다. 내부 Exchange Server 조직과 엄격히 구분된 경계 네트워크에 Edge 전송 서버와 Forefront Security를 배포하여 악의적이고 합법적이지 않은 콘텐츠가 메시징 환경에 침투하지 못하게 하면서 합법적인 메시지는 매우 낮은 가양성 발생 비율로 사용자에게 전달할 수 있습니다.

Kay Unkroth는 15년 이상 Microsoft 서버 기술 분야에서 기술 지원 엔지니어, 시스템 개발자, 컨설턴트, 강사 및 저술가로 활동하고 있으며 문서화 및 지역화 관리 서비스를 전문적으로 제공하는 회사인 Biblioso Corporation의 공동 창업자이자 회장입니다.

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