이번에는 MEC의 Increasing mail flow security posture 섹션에 대한 Self-Study 포스팅입니다.
내용이 너무 길기 때문에 파트를 2개로 나눠서 진행 하겠습니다.
Deep Dive: Increasing Mail Flow Security Posture
[Bypassing 3rd-party antispam]
Exchange Online 을 사용하는 구조에서 가장 많이 사용하는 메일 수신 흐름은 아래와 같이 EOP 앞단에 3rd Party를 사용하는 구조입니다. MX 레코드를 3rd Party Antispam 으로 구성한 뒤, Relay 형태로 EOP에 전달합니다. MEC 세션에서는 이러한 구조가 악의적인 공격자의 타겟이 된다고 설명하고 있습니다.
기본적으로 여기서 일어난 일은 발신자에게 기대해야 하는 것은 EOP에 메시지를 보내고 그 다음 메시지와 MX 레코드를 보내는 것이기 때문입니다.
강의에서는 기업들이 일반적으로 구성하는 환경들에 취약점이 있다고 지적하고 있습니다.
만약 Custom Domain을 contoso.com 일 경우 EOP 주소는 contoso-com.mail.protection.outlook.com 으로 지정되는데, Bad Actor 들이 해당 주소로 직접 공격할 수 있다고 언급합니다.
물론 EOP 주소로 직접 메일을 발송한다고 해서, EOP가 검사를 안 하는 것은 아닙니다.
모든 메일이 스팸장비를 거친다고 생각한다면, 여러가지 시나리오에서 보안홀이 발생할 수 있습니다.
[EOP Lockdown]
여기서 예상되는 경로 이외의 나머지 경로를 차단하는 것을 Lockdown 이라고 표현하였습니다.
Lab 구성을 위해서 Inbound Partner Connector 생성에 대해서 안내하고 있습니다.
예시에서는 인증서, IP 기반을 나눠서 명령어로 설명하고 있습니다.
인증서 기반의 장점은 IP를 한정하지 않고 일치하는 인증서에 대해서는 수신하도록 하는 커넥터입니다. 릴레이 범위가 매우 넓고 일일이 IP를 추가하는 번거로움을 덜 수 있습니다.
IP 기반의 장점은 인증서를 지원하지 않는 시스템(TLS를 지원하지 않는 시스템)이나 스팸장비처럼 IP 변동이 없을 경우 적절합니다.
New-InboundConnector -Name "From 3rd-party AS" -ConnectorType Partner -RestrictDomainsToIPAddresses $true -SenderIPAddresses "218.50.XX.XX" -SenderDomains "*"
기술자료: New-InboundConnector (ExchangePowerShell) | Microsoft Learn
이미 제 테스트 환경은 Hybrid 구성이 되어 있으므로 아래와 같이 Inbound Connector가 2개인 것을 확인할 수 있습니다.
각 커넥터의 전체 속성에도 차이가 있습니다.
<Hybrid Connector>
<Partner Connector>
<ConnectorType>
The ConnectorType parameter specifies the category for the source domains that the connector accepts messages for. Valid values are:
|
EAC 페이지에서 커넥터 생성시 아래와 같은 차이가 있습니다.
<Partner>
<Onpremises> -> All Accepted domains 에 대한 옵션의 사용 여부가 중요한 것으로 보입니다.
커넥터를 생성할 때, Partner와 달리 Onpremises는 TlsCertificateName 이나 SenderIPAddresses 값을 지정해 줘야 합니다. 그 이외의 차이점은 아직 발견하지 못했습니다.
<ConnectorSource>
The ConnectorSource parameter specifies how the connector is created. Valid input for this parameter includes the following values:
|
ConnectorSource도 어떻게 만들어 졌느냐의 기록적인 의미로 보입니다. 물론 Header 상의 차이는 있겠지만, 기능적인 차이는 없는 것으로 보여집니다. Default는 EXO에서 직접생성시, HybridWizard는 온프레미스에서 마법사를 통해서 생성시 지정되는 값입니다.
<CloudServicesMailEnabled>
| Note: We recommend that you don't use this parameter unless you are directed to do so by Microsoft Customer Service and Support, or by specific product documentation. Instead, use the Hybrid Configuration wizard to configure mail flow between your on-premises and cloud organizations. For more information, see Hybrid Configuration wizard. The CloudServicesMailEnabled parameter specifies whether the connector is used for hybrid mail flow between an on-premises Exchange environment and Microsoft 365. Specifically, this parameter controls how certain internal X-MS-Exchange-Organization-* message headers are handled in messages that are sent between accepted domains in the on-premises and cloud organizations. These headers are collectively known as cross-premises headers. Valid values are:
|
CloudServicesMailEnabled 는 Hybrid 마법사로 설정되도록 하는 것을 권장한다고 나와있습니다. 수동으로 임의조작할 경우 Side Effect가 발생할 수 있기 때문입니다. $True로 설정될 경우 X-MS-Exchange-Organization 등 Header 값을 변경하여 내부 메일에 대한 구분이 이루어 진다고 설명하고 있습니다. 관련된 테스트는 뒤에서 좀 더 자세히 확인해 보도록 하겠습니다.
<RequireTls, TlsSenderCertificateName, RestrictDomainsToIPAddresses, SenderIPAddresses>
| TlsSenderCertificateName The TlsSenderCertificateName parameter specifies the TLS certificate that's used when the value of the RequireTls parameter is $true. A valid value is an SMTP domain. Wildcards are supported to indicate a domain and all subdomains (for example, *.contoso.com), but you can't embed the wildcard character (for example, domain.*.contoso.com is not valid). RequireTls The RequireTLS parameter specifies whether to require TLS transmission for all messages that are received by the connector. Valid values are:
The RestrictDomainsToIPAddresses parameter specifies whether to reject mail that comes from unknown source IP addresses. Valid values are:
The SenderIPAddresses parameter specifies the source IPV4 IP addresses that the connector accepts messages from. Valid values are:
|
RequireTls, TlsSenderCertificateName 세트라고 봐도 될 것 같습니다. Hybrid 마법사는 일반적으로 인증서 방식으로 커넥터가 생성됩니다. RequireTls가 True면 당연히 TlsSenderCertificateName이 지정되어야 합니다.
RestrictDomainsToIPAddresses, SenderIPAddresses 도 같은 맥락입니다. IP를 지정했다면, RestrictDomainsToIPAddresses 가 True가 되어야 합니다.
[Bypass leveraging]
3rd Party Antispam 이외에도 On-Premise 를 통하여 우회하는 취약점에 대해서도 강조하였습니다.
물론 아래의 그림상 전제는 EXO->On-Premise 로 전달할 때에는 3rd Party Antispam 장비가 없다는 전제인 것으로 보입니다.
저 설명을 이해하려면, Hybrid Configuration Wizard(HCW)가 어떻게 진행되는지 이해가 필요할 것 같습니다.
우선 HCW Log는 아래의 위치에서 확인할 수 있습니다.
Log 파일에서 ReceiveConnector 를 키워드로 찾아보면, 아래의 기록을 확인할 수 있습니다.
이 부분은 아래의 단계와 연관 있는 것으로 보입니다.
EXO -> On-Premise 로 메일을 전달 하는 흐름이라면 다음과 같습니다.
8번 구간에서 Outbound to <GUID> Connector -> Default Frontend <Servername> Connector로 전달하기 때문에 Default Frontend Connector의 설정을 변경하는 것입니다. 사실 직접 받는 것이 3rd Party 장비라면, Receive Connector 설정 변경은 큰 의미가 없을 것으로 보입니다.
| Set-ReceiveConnector -AuthMechanism 'Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer' -Bindings '[::]:25','0.0.0.0:25' -Fqdn 'EX19MBX1.contoso.kr' -PermissionGroups 'AnonymousUsers, ExchangeServers, ExchangeLegacyServers' -RemoteIPRanges '::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff','0.0.0.0-255.255.255.255' -RequireTLS: $false -TLSDomainCapabilities 'mail.protection.outlook.com:AcceptCloudServicesMail' -TLSCertificateName '<I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB<S>CN=mail.contoso.kr' -TransportRole FrontendTransport -Identity 'EX19MBX1\Default Frontend EX19MBX1' |
RemoteIPRanges 는 EOP IP만을 지정한 것이 아닌 모든 IP 주소 범위가 지정되어 있습니다. 모든 IP 범위는 Default Frontend Connector의 기본 값입니다.
그리고 TLSDomainCapabilities에 대해서는 기술자료에서는 다음과 같이 설명하고 있습니다.
| TlsDomainCapabilities The TlsDomainCapabilities parameter specifies the capabilities that the Receive connector makes available to specific hosts outside of the organization. Remote hosts are authenticated with TLS with certificate validation before these capabilities are offered. This parameter uses the following syntax: "Domain1:Capability1,Capability2,"...,"Domain2:Capability1,Capability2,...",... You can only use this parameter in Exchange hybrid deployments, and the valid Capability values are:
The available Domain values are an SMTP domain (for example, contoso.com), or the value NO-TLS for non-TLS encrypted inbound connections. For example, ."contoso.com:AcceptOorgProtocol","fabrikam.com:AcceptCloudServicesMail" 기계번역 TlsDomainCapabilities 매개 변수는 수신 커넥터가 조직 외부의 특정 호스트에서 사용할 수 있도록 하는 기능을 지정합니다. 원격 호스트는 이러한 기능이 제공되기 전에 인증서 유효성 검사를 통해 TLS로 인증됩니다. 이 매개변수는 다음 구문을 사용합니다. "Domain1:Capability1,Capability2,"...,"Domain2:Capability1,Capability2,...",... Exchange 하이브리드 배포에서만 이 매개변수를 사용할 수 있으며 유효한 기능 값은 다음과 같습니다.
사용 가능한 도메인 값은 SMTP 도메인(예: contoso.com)이거나 TLS로 암호화되지 않은 인바운드 연결의 경우 NO-TLS 값입니다. 예를 들어, "contoso.com:AcceptOorgProtocol","fabrikam.com:AcceptCloudServicesMail" Set-ReceiveConnector (ExchangePowerShell) | Microsoft Learn |
해당 값이 적용되었는지 유무는 프로토콜 로그를 통해서 확인할 수 있습니다.
프로토콜 로그를 통해서 알 수 있는 사실은 mail.protection.outlook.com 도메인이 일치하면, TlsDomainCapabilities 가 적용된다는 점입니다. 그렇다는 것은 다른 테넌트에서 발송시에도 동일하게 판정될 것입니다.
Fabrikam.kr 이 등록된 다른 테넌트에서 Outbound Connector를 동일하게 설정한 뒤, 동일한 로그가 기록되는지 확인해 보았습니다.
다음과 같이 동일하게 기록되는 것을 확인할 수 있습니다. 특히 XOORG도 동일하게 기록됩니다.
강의상에서는 이 부분이 악용될 소지가 있다고 설명하고 있습니다. 하이브리드 구성의 특성상 커넥터나 IP 허용목록 설정으로 인하여 SCL Level이 -1로 기록될 가능성이 존재하기 때문입니다.
방화벽단에서 막을 수 없는 이유로는 Contoso.kr과 Fabrikam.kr 테넌트는 동일한 EOP를 사용하기 때문에 구분하는 것은 불가능합니다.
또한 protection.outlook.com 주소를 기반으로 하기때문에 URL 기반으로도 구분이 불가능합니다. 이 세션에서 궁극적으로 전달하고자 하는 메시지는 3rd Party Antispam, Exchange Server 등과 같이 "Hybrid 환경은 추가적인 설정이 필요하다." 입니다.
[Demo1]
Demo1에서는 Bad Actor 모델의 테넌트에서 Outbound Connector 를 생성 -> 공격 대상의 On-Premise에 직접 발송 -> Relay를 이용하여 대상테넌트로 수신하게 하는 테스트가 목표입니다.
Step1. Outbound Connector 생성
Fabrikam.kr 테넌트에서 아래와 같이 Outbound Connector를 생성
User01@fabrikam.kr -> Cloud1@contoso.kr 메일 발송하면,
아래와 같은 순서로 전달됩니다.
Frontend Receive Protocol Log를 보면 아래와 같이 수신 기록을 확인할 수 있습니다. 위 그림상 1번 흐름에 해당합니다.
Transport (hub) Send Protocol Log를 보면 아래와 같이 송신 기록을 확인할 수 있습니다. 위 그림상 2번 흐름에 해당합니다.
Exchange Online에서 Message Trace의 상세 항목으로 내보내기를 진행하면,
Transport Service 단인 Default <Server Name> Connector 에서 수신하고, 최초 수신은 mail.onmicrosoft.com 받는 것을 알 수 있습니다. 이후 이 주소를 Primary Address로 Rewrite 합니다. 어떻게 보면 Hybrid 구조의 당연한 수순입니다.
그리고 Custom_data 항목에서 생성한 커넥터를 통해서 수신된 것을 확인할 수 있습니다.
그리고 아래와 같이 수신된 것을 확인할 수 있습니다.
영상에서는 Header 분석기에서 IP Filter Verdict 의 CAL 을 언급하였습니다.
CAL을 클릭하면 아래의 기술자료로 이동합니다.
Anti-spam message headers - Office 365 | Microsoft Learn
-> IP Allow List에서 허용하면, 지금과 같이 피싱메일이 수신될 수 있는 시나리오가 있다 라고 설명하고 있습니다.
그리고 Get-HostedConnectionFilterPolicy 를 확인시켜줍니다.
[X-OriginatorORG]
Lock down을 진행하기전에 먼저 X-OriginatorOrg라는 중요한 헤더에 대해 알아야 합니다.
해당 내용에서 한글로 입력한 부분은 강연 내용을 번역한 내용입니다. 우선 대응 되는 개념을 비교해서 두서 없이 작성해보았습니다. 이후 시
나리오 1,2 를 보면 이해하기 쉬울 것으로 생각됩니다.
When email is sent from or relayed through your own tenant, Exchange Online will send XOORG SMTP command extension with the "MAIL FROM" Command.
자체 테넌트에서 전자 메일을 보내거나 릴레이하면 Exchange Online에서 "MAIL FROM" 명령과 함께 XOORG SMTP 명령 확장을 보냅니다.
XOORG = Sender's P2 or P1 domain if it's a tenant's accepted domain
XOORG = The default accpted domain where the sender is external (like forward scenario)
보낸 사람의 주소가 테넌트의 허용 도메인과 같다면, XOORG는 보낸 사람의 P1 or P2 도메인과 동일합니다.
Relay or Forwarding 시나리오에서는 XXORG가 테넌트의 기본 허용 도메인이 됩니다.
Frontend Protocol log 상에서 다음과 같이 확인됩니다.
The following two conditions are checked on the on-premises Server:
If the Receive connector TlsDomainCapabilities is set to AcceptCloudServicesMail or AcceptOorgProtocol and
If the XOORG Domain matches any on-premises Accepted Domain
이제 테넌트에서 Hybrid On-premises server로 메일이 전송되면 On-premises server는 두 가지를 확인합니다.
먼저 수신된 커넥터 TlsDomainCapabilities가 AcceptCloudServicesMail 또는 AcceptOorgProtocol로 설정되어 있는지 확인합니다.
두 번째는 mail from 명령으로 언급된 XOORG 도메인이 서버의 허용 도메인 중 하나와 일치하는 경우입니다.
Set-ReceiveConnector (ExchangePowerShell) | Microsoft Learn
On-premises server will treat the connection as Authenticated and will promote cross premises headers to org headers. Also, this will make sure that all emails directly sent from or relayed through EOP have the "X-OriginatorOrg" header set to your Verified Domain in EXO.
온-프레미스 서버는 연결을 인증됨으로 처리하고 크로스-프레미스 헤더를 조직 헤더로 승격합니다. 또한 EOP에서 직접 보내거나 EOP를 통해 릴레이되는 모든 이메일에 "X-OriginatorOrg" 헤더가 EXO의 확인된 도메인으로 설정되어 있는지 확인합니다.
해더 상에서 아래의 요소들을 설명하는 것으로 보입니다.
This is automatically setup for you by the hybrid Configuration Wizard, and in hybrid scenario, XOORG SMTP command is how we keep thins secure.
이들은 하이브리드 구성 마법사에 의해 자동으로 설정되며 하이브리드 시나리오에서 XOORG SMTP 명령은 보안을 유지하는 방법입니다.
[Blue Team: Scenario 1]
아래의 시나리오는 조직의 테넌트가 아닌 다른 테넌트(fabrikam.kr)에서 우회하여 On-Premise 로 발송하는 것을 X-OriginatorORG Header 값을 기준으로 차단하는 시나리오입니다.
Exchange On-Premise 상에서 규칙을 생성합니다.
Powershell 로 진행한다면, 다음과 같이 입력합니다.
New-TransportRule -Name "Lockdown Exchange On-Prem" -FromScope NotInOrganization -RejectMessageReasonText 'You are not allowed to send email directly, use MX!' -ExceptIfHeaderContainsMessageHeader 'X-OriginatorOrg' -ExceptIfHeaderContainsWords 'contoso.kr'
ECP 상에서는 다음과 같이 생성합니다.
실제로 아래와 같이 우회하도록 설정하고 발송 시도시,
아래와 같이 NDR을 수신되는 것으로 확인됩니다.
Header 상의 X-OriginatorOrg 를 기준으로 차단한 것을 확인할 수 있습니다.
[Blue Teams: Scenario 2]
두번째 시나리오는 MX 레코드가 3rd Party Email Filter 일 때, 3rd Party를 거쳐서 들어오는 메일과 거치지 않는 메일을 구분하여 차단하는 시나리오입니다.
우선 기존 mail.contoso.kr 로 Direct 전달하는 커넥터를 Disable 하고 아래와 같이 MX 레코드를 통해서 수신하도록 한 뒤, 메일 발송을 진행해 보았습니다.
아래와 같이 메일 발송
Onpremise 사서함에서 수신
Header상에서 Edge를 거쳐서 수신됨 확인
X-OriginatorORG 헤더는 없는 것으로 확인됩니다.
Protocol Log를 보면 Edge에서 수신할 때에는 TlsDomainCapabilities='None',Domain='' 으로 체크되기 때문에 MAIL FROM 명령어 단계에서 XOORG 기록이 없는 것을 알 수 있습니다.
다시 한번 기존의 Protocol Log를 비교해 보면 XOORG 및 XOrginatorORG 개념을 쉽게 이해할 수 있을 것입니다.
그래서 아래의 구조에서는 X-OriginatorORG의 Header 값이 존재하는지 여부를 가지고 규칙 생성을 안내하고 있습니다.
Exchange Management Shell 기준으로는 다음 명령어로 생성합니다.
New-TransportRule -Name "Lockdown Exchange On-Prem 2" -HeaderMatchesMessageHeader 'X-OriginatorOrg' -HeaderMatchesPatterns '$' -ExceptIfHeaderContainsMessageHeader 'X-OriginatorOrg' -ExceptIfHeaderContainsWords 'contoso.kr' -RejectMessageReasonText 'You are not allowed to send email directly, use MX!'
ECP 상에서는 다음과 같이 생성합니다.
이 규칙은 Header 상에 X-originatorOrg 값이 존재하고, 그 값이 contoso.kr이 아니면 Block 한다는 의미입니다.
아래와 같이 테스트 메일 발송
아래와 같이 NDR이 수신되는 것을 확인할 수 있습니다.
한번에 해당 세션을 전부 다루고 싶지만.. 너무 작성기간이 길어 질 것 같아서 나눠서 다룹니다.
난이도가 있는 부분이기 때문에 2번째 파트는 한동안 업데이트가 없을 수도 있습니다....
'Exchange' 카테고리의 다른 글
| Exchange Server. Password Expiration Notification (0) | 2023.01.31 |
|---|---|
| Exchange Online. Enhanced Filtering for Connectors (0) | 2022.12.27 |
| Exchange Online. MTA-STS (0) | 2022.10.02 |
| Exchange Server. AutoReseed (0) | 2022.08.13 |
| Exchange Server 2019. Folder Empty (EWS API) (4) | 2022.07.28 |