Comunicações

Servidores de Transporte de Borda do Exchange na Microsoft

Kay Unkroth

Visão geral:

• A função de servidor Transporte de Borda do Exchange
• Configuração de laboratório de teste
• Agentes e eventos de transporte
• Internos do agente

Faça download do código deste artigo: ExchangeEdge2007_10.exe (354KB)

Em um dia útil, a Microsoft recebe aproximadamente 13 milhões de tentativas de envio de mensagens provenientes da Internet e bloqueia mais de 10,5 milhões delas por não serem legítimas. Em situações críticas

como, por exemplo, durante ataques de spam ou invasões de vírus na Internet, o volume pode ultrapassar os 90 milhões. É claro que essa constatação é específica da Microsoft, ainda que scamming, spam, phishing, vírus em emails, coletas de diretório, ataques DDoS (ataque de negação de serviço distribuído) e preocupações semelhantes não sejam exclusivas da Microsoft. Diante desses problemas, como você faz para garantir a entrega de todas as mensagens legítimas aos usuários e ao mesmo tempo afastar do ambiente de mensagens o fluxo de conteúdo mal-intencionado e ilegítimo?

Uma forma de obter uma proteção confiável para as mensagens é implantar os servidores de Transporte de Borda do Exchange Server 2007 e o Forefront Security for Exchange Server em uma rede de perímetro entre a Internet e o ambiente de produção. Isso coloca uma equipe organizada com mais de 10 agentes de Transporte de Borda no perímetro para ajudar a proteger os sistemas de produção e os usuários. É óbvia a importância de bloquear o conteúdo indesejado com a maior antecedência possível. O ideal é que isso ocorra antes mesmo que o conteúdo seja entregue aos servidores, considerando a carga que o ambiente de mensagens deveria ser capaz de sustentar em uma situação crítica. Além disso, há muito mais na proteção das mensagens do que simplesmente bloqueá-las.

Esta é a primeira parte das duas que abordam a arquitetura e os principais recursos dos agentes de anti-spam e de antivírus disponíveis no Exchange Server 2007 e no Forefront Security for Exchange Server. Para manter as explicações realistas e práticas, neste primeiro artigo, mostrarei a você como criar um laboratório de teste que espelhe o projeto de proteção das mensagens usado pela Microsoft em seu próprio ambiente de produção corporativo. Em seguida, abordarei a arquitetura do Transporte de Borda do Exchange Server 2007 mais detalhadamente.

Durante todo o artigo, usarei muitos scripts e arquivos em lotes para automatizar as tarefas de configuração mais importantes. Esses arquivos incluem comentários que explicam as etapas realizadas individualmente. É possível baixar os scripts com o download disponível no site da TechNet Magazine em technetmagazine.com/code07.aspx.

Topologia do Transporte de Borda

A Figura 1 ilustra o projeto do Transporte de Borda implementado pela TI da Microsoft no ambiente de produção corporativo. Há alguns recursos muito interessantes no projeto que eu gostaria de ressaltar antes de apresentar a você a arquitetura do Transporte de Borda. Caso você esteja interessado nos detalhes completos da implementação, consulte o white paper do IT Showcase mencionado na barra lateral "Recursos do Exchange".

Figura 1** Topologia do Transporte de Borda na Microsoft **(Clique na imagem para aumentar a exibição)

Ao analisar a Figura 1, observe que a topologia do Transporte de Borda na Microsoft é totalmente redundante. Não há nenhum ponto de falha em um local sequer. Para o balanceamento de carga, a TI da Microsoft usa rodízio externo de DNS e conectores de mensagens com várias pontes internas. Também vale a pena observar o fato de que todos os servidores de transporte (Transporte de Hub e Transporte de Borda) executam o Forefront Security for Exchange Server para a verificação de vírus. Isso permite que a TI da Microsoft examine todas as mensagens de entrada, de saída e internas assim que chegam a um servidor de transporte na topologia de roteamento das mensagens.

Outro recurso importante do projeto relacionado à segurança é que os servidores do Transporte de Borda não fazem parte do ambiente do Active Directory® corporativo. Na verdade, não é necessário implantar os servidores do Transporte de Borda em nenhuma floresta do Active Directory. No entanto, para manter uma estrutura de gerenciamento consistente, aplicar um conjunto de diretivas em comum e dar suporte a logon único, a TI da Microsoft implanta todos os servidores do Transporte de Borda em uma floresta externa, separada do ambiente de produção.

Por fim, é possível ver claramente que todas as mensagens provenientes da Internet chegam à Microsoft por meio de servidores do Transporte de Borda situados na América do Norte. Os servidores do Transporte de Borda em Dublin e em Cingapura só manipulam mensagens de saída. A vantagem de concentrar todo o tráfego de entrada nos servidores do Transporte de Borda da América do Norte é centralizar o controle de segurança e de anti-spam ao mesmo tempo em que se evita a transferência das mensagens de saída de grandes data centers regionais em todo o backbone das mensagens internas.

O engenheiro de sistemas da TI da Microsoft, Omesh Desai, projetou a topologia do Transporte de Borda da Microsoft. Quando perguntei a Omesh a respeito dos recursos mais importantes do projeto, ele disse: "Em nosso projeto do Transporte de Borda, nós aproveitamos os recursos de anti-spam e de antivírus nativos do Exchange para a proteção das mensagens em vários níveis no backbone das mensagens. A segurança do perímetro das mensagens é a maior prioridade, embora um modelo simples de gerenciamento e administração também seja importante para nós. Os servidores do Transporte de Borda nos ajudam a aumentar a segurança por meio de configurações de firewall mais rígidas, ao mesmo tempo em que aumentam a precisão da filtragem de spam por meio dos serviços de reputação de IP, das atualizações automáticas do filtro de conteúdo, da agregação de lista segura e da validação do carimbo postal de email. Por padrão, toda a comunicação interna entre os servidores é criptografada, e nós também criptografamos a comunicação com os destinos externos, se possível.

"Nós usamos dois processadores dual-core de 64 bits e oito gigabytes de memória em nossos servidores do Transporte de Borda. Com seis desses servidores, com balanceamento de carga em dois data centers, temos capacidade suficiente para suportar grandes picos de mensagens enviadas como, por exemplo, durante invasões de vírus na Internet."

Laboratório de teste do Transporte de Borda

Configuração do laboratório de teste

Por ser uma prática recomendada usar nomes de domínio não existentes e endereços IP particulares, eu uso AdventureWorks.com e intervalos de endereços IP 192.168.xxx.0 a 24. Não há sistemas redundantes ou matriz de firewalls porque não estou testando o balanceamento de carga ou a tolerância a falhas. (E, obviamente, os sistemas de firewall reais usados pela TI da Microsoft não podem ser abordados por motivos de segurança.) De qualquer forma, esses detalhes não são importantes para o ambiente de teste.

O meu ambiente de teste usa o ISA Server 2006 por se tratar de um dos sistemas de firewall mais comumente usados com o Exchange Server 2007. A execução do ISA Server 2006 nos firewalls externos e internos ajuda a manter a complexidade do ambiente de teste em um nível moderado, embora eu recomende, para ambientes de produção, o uso de vários sistemas de firewall externo e interno para aumentar a segurança. Eu não implantei as diretivas de protocolo IPSec (IP Security) ou preparei o ambiente para o protocolo TLS (Transport Layer Security) porque esses tópicos estão fora do escopo deste artigo.

No entanto, usei máquinas virtuais e um software de avaliação de 32 bits, que é possível baixar no site da Microsoft. A Microsoft não dá suporte à versão de 32 bits do Exchange Server 2007 em produção, embora isso não seja problema em um ambiente de teste.

Meu laboratório de teste usa as configurações padrão sempre que possível. Apenas a configuração de IP, os firewalls e as zonas DNS exigem atenção especial antes da execução da configuração do Exchange Server 2007 e da inscrição do servidor do Transporte de Borda no ambiente de produção. Para obter detalhes sobre a configuração de IP, consulte o arquivo Test Lab—IP Configuration.xls que você encontrará no download complementar. Caso use as mesmas atribuições de endereço IP, você pode configurar rapidamente o firewall externo, chamado ISA01, executando o script ISA01_Firewall_Policies.vbs diretamente no computador ISA01, e usar ISA02_Firewall_Policies.vbs para o firewall interno (ISA02). O download complementar também inclui arquivos em lotes para configurar os servidores DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat e AD02_DNS_Config.bat). Como esses arquivos em lotes usam a ferramenta de linha de comando DNS (dnscmd.exe), você precisa ter as Ferramentas de Suporte do Windows instaladas; do contrário, você deve criar manualmente os registros DNS usando o console DNS.

Para evitar qualquer interferência dos ambientes existentes, o meu laboratório de teste não está conectado à Internet. Esse isolamento é uma boa precaução. Isso faz com que haja falha em todos os downloads das atualizações de assinatura, da reputação de IP e das atualizações do filtro de conteúdo, mas isso não é crítico para fins de teste. Para evitar mensagens de erro, vá para Atualizações do Scanner no console do Forefront Server Security Administrator e defina a freqüência de atualizações de todos os mecanismos de verificação para uma vez e especifique uma data anterior.

Para explorar esses recursos em ação, criar um ambiente de teste é uma prática recomendada – o senso comum sugere jamais usar um sistema de produção para fins de teste. Ele usa, no mínimo, um servidor com o Exchange Server 2007 em execução para as funções de servidor Caixa de correio, Acesso de cliente e Transporte de Hub. Você precisará de um segundo servidor do Exchange para a função de servidor Transporte de Borda. Você poderia ignorar a instalação do servidor de Transporte de Borda se implantasse todos os agentes de transporte no servidor de várias funções executando o script Install-AntispamAgents.ps1 (é possível encontrá-lo em servidores do Transporte de Borda na pasta %ProgramFiles%\Microsoft\Exchange Server\Scripts). Mas essa abordagem pouco se assemelharia à implantação da TI da Microsoft. Para obter um laboratório de teste realista, você precisará incluir mais alguns servidores. A Figura 2 mostra o ambiente de teste que usei na pesquisa deste artigo. Há uma ilustração mais detalhada disponível no download complementar. Para obter mais informações sobre como configurar o laboratório, consulte a barra lateral "Configuração do laboratório de teste".

Figura 2** Ambiente de teste do Transporte de Borda **(Clique na imagem para aumentar a exibição)

Durante a inscrição do servidor do Transporte de Borda e a configuração dos conectores associados, a TI da Microsoft remove todos os conectores padrão e, em seguida, continua criando quatro conectores de envio para se comunicar de maneira eficiente com tipos diferentes de hosts de protocolo SMTP (Simple Mail Transfer Protocol) e servidores do Transporte de Borda internos. O primeiro conector de envio é um conector da Internet para todos os destinos que não correspondem a definições de espaço de endereçamento específicas.

O segundo conector de envio é um conector da Internet com definições de espaço de endereçamento detalhadas para destinos conhecidos que não dão suporte a SMTP estendido (domínios HELO). Configurando o parâmetro ForceHELO para esse conector como $true, a TI da Microsoft evita uma seqüência desnecessária de EHLO, Resposta de Falha 500, HELO durante o estabelecimento de conexões SMTP.

O terceiro conector de envio é um conector da Internet com definições de espaço de endereçamento detalhadas para parceiros e outros domínios remotos que dão suporte a TLS na comunicação segura por meio de conexões criptografadas (domínios TLS). Esse conector tem o parâmetro RequireTLS definido como $true.

O quarto conector de envio é um conector de entrada para transferir mensagens de Internet recebidas para servidores de Transporte de Hub no ambiente corporativo. Mais uma vez, para obter mais detalhes a respeito da configuração do servidor do Transporte de Borda, consulte o white paper do IT Showcase mencionado na barra lateral "Recursos do Exchange" ao final deste artigo.

Para aplicar uma topologia de conector ao estilo da TI da Microsoft ao laboratório de teste, eu usei um procedimento com base nos scripts criados por Omesh para uso interno da TI da Microsoft. Por motivos de segurança, eu alterei e reduzi drasticamente os comandos individuais, mas a topologia de conector resultante continua correspondendo à topologia da TI da Microsoft. Aqui estão as etapas:

1. No servidor do Exchange de várias funções (HUB-MBX-01) e no servidor do Transporte de Borda (EDGE01), remova os conectores padrão.
2. Em HUB-MBX-01, crie um novo conector de recebimento executando o script HUB-MBX-01_recv_connector.ps1 encontrado no download deste artigo.
3. Em EDGE01, crie dois novos conectores de recebimento para conectividade das mensagens internas e externas executando o script EDGE01_recv_connector.ps1.
4. Em EDGE01, crie um arquivo de inscrição executando este comando:

    New-EdgeSubscription -FileName 
    "c:\subscriptionfile.xml" 

Em seguida, copie o arquivo de inscrição resultante para a pasta raiz do servidor de Transporte de Hub (c:\subscriptionfile.xml).

5. Em HUB-MBX-01, verifique se o caminho para o arquivo de inscrição é c:\subscriptionfile.xml e execute o script HUB-MBX-01_complete_subscription.ps1. Esse script importa o arquivo de inscrição para Sincronização de Borda sem a criação automática do conector de envio, cria os conectores de envio para conectividade interna e da Internet e replica a configuração resultante para o servidor do Transporte de Borda por meio da Sincronização de Borda.

6. Verifique a configuração enviando mensagens de teste como Contoso.User@contoso.com e Fabrikam.User@fabrikam.com do host da Internet para Administrator@adventureworks.com e respondendo às mensagens recebidas para garantir o funcionamento da transferência das mensagens de entrada e de saída.

Eu sugiro que você abra os arquivos de script individuais no Bloco de notas e analise os cmdlets e os parâmetros usados pelos scripts para realizar a configuração. Há informações detalhadas sobre esses cmdlets e parâmetros disponíveis on-line na documentação do produto do Exchange Server 2007.

Arquitetura do Transporte de Borda

Agora vejamos os agentes do Transporte de Borda, que têm aguardado alguém dizer HELO ou EHLO desde o momento em que eu instalei a função de servidor Transporte de Borda. Caso execute o cmdlet Get-TransportAgent no servidor do Transporte de Borda, você deve ver as 11 entradas listadas na Figura 3. Por padrão, todos os agentes são habilitados para fornecer proteção às mensagens com as configurações apropriadas.

Figure 3 Agentes de transporte

O cmdlet Get-TransportAgent e a Figura 3 listam os agentes na ordem de prioridade, embora essa não seja a ordem na qual os agentes realizam o trabalho. A ordem dos trabalhos depende essencialmente da seqüência dos eventos de recebimento SMTP e dos eventos de roteamento nos quais os agentes estão registrados. Para ver como os agentes e os eventos se adaptam, observe o diagrama mostrado na Figura 4, que ilustra a forma como os agentes de transporte se integram à arquitetura do Transporte de Borda.

Figura 4** Agentes de transporte dentro da arquitetura do Transporte de Borda **(Clique na imagem para aumentar a exibição)

Os eventos de transporte ocorrem em vários estágios durante o processamento das mensagens para invocar um código adicional para filtragem anti-spam, verificação de vírus e outras tarefas. Nesse projeto flexível e extensível, o processo Transporte de Borda (EdgeTransport.exe) assume a função de origem do evento. Os manipuladores de eventos, em outras palavras, os agentes de transporte, são objetos delegados baseados no Microsoft® .NET Framework 2.0, registrados na origem do evento para receber notificações de retorno de chamada.

A Figura 5 mostra os registros de evento para todos os agentes instalados em um servidor do Transporte de Borda com o Forefront Security. Talvez seja um pouco difícil classificar esses registros por conta do grande número de registros de agente, mas não se desespere. Caso execute o comando Get-TransportPipeline | Format-List em um servidor do Transporte de Borda, você pode analisar os registros de cada evento de transporte individual com mais calma. Apenas verifique se o serviço Transporte do Microsoft Exchange (MSExchangeTransport.exe) está em execução e se você enviou pelo menos uma mensagem pelo servidor do Transporte de Borda desde a última reinicialização do serviço. Como a saída indica, vários agentes podem se registrar no mesmo tipo de evento e agentes individuais podem se registrar em vários eventos. Os registros de evento dependem apenas dos requisitos de processamento do agente correspondente.

Figura 5** Registros de evento para agentes de transporte **(Clique na imagem para aumentar a exibição)

Um dos eventos mais importantes é o evento de roteamento OnSubmittedMessage, disparado quando uma mensagem chega à fila de envio. Todas as mensagens devem passar por essa fila, independentemente de chegarem por meio do SMTP, do sistema de arquivos ou de qualquer outro mecanismo. O categorizador é um componente essencial da arquitetura de transporte do Exchange Server, responsável pela resolução do destinatário, da bifurcação e do roteamento da mensagem e da geração de DNS (notificação de status de entrega). Por isso, o evento OnSubmittedMessage é uma opção de registro perfeita para agentes que precisem processar todas as mensagens recebidas. O Agente de roteamento de FSE é um componente do Forefront Security registrado no evento OnSubmittedMessage para poder passar todas as mensagens recebidas aos mecanismos de verificação de vírus. Como o Agente de roteamento de FSE está registrado no evento OnSubmittedMessage, nenhuma mensagem pode ignorar a solução de antivírus.

E por que não basta registrar todos os agentes no evento OnSubmittedMessage e considerar o trabalho pronto? Porque você deseja bloquear as mensagens indesejadas com a maior antecedência possível, antes de que o servidor confirme o êxito na entrega. Do contrário, os servidores teriam que processar 90 milhões de mensagens indesejadas durante um spam ou ataque de vírus, precisando gerar possivelmente 90 milhões de NDRs (notificações de falha na entrega), o que, por sua vez, poderia oferecer uma ameaça grave a espectadores inocentes. Spam e ataques de vírus quase sempre usam informações falsificadas sobre o remetente. Enviar milhões de NDRs para destinatários que não criaram as mensagens originais não é apenas uma perda dos seus recursos e dos das organizações de destino, mas também uma oportunidade para que usuários mal-intencionados iniciem inundações de emails e ataques DDoS. É importante parar os acompanhamentos por parte de remetentes mal-intencionados para a sua própria proteção e para a proteção dos demais.

Para bloquear uma mensagem com eficiência, um agente de transporte deve interromper a conversa SMTP com o host remoto antes que o servidor confirme o recebimento dos dados com um código de status 250 OK. De acordo com o princípio armazenar e encaminhar SMTP, o servidor pode descartar com segurança qualquer dado recebido sem gerar NDRs caso a entrega da mensagem não tenha sido confirmada. Os agentes de recebimento SMTP são capazes disso. Eles interagem com a sessão SMTP porque o pipeline de transporte invoca esses agentes com base nos eventos SMTP de recebimento quando o host remoto se conecta ao servidor, estabelece uma sessão SMTP, transmite verbos SMTP, envia mensagens e encerra a conexão. (Os eventos de recebimento SMTP relacionados a cada etapa estão listados na Figura 6.) Por conta da capacidade de rejeitar mensagens antes da entrega e de desconectar hosts SMTP remotos, todos os agentes de anti-spam do Exchange Server 2007 são implementados como agentes de recebimento SMTP.

Figure 6 Eventos de sessão SMTP

É importante reconhecer a diferença entre os agentes de recebimento SMTP e os agentes de roteamento em relação ao contexto de processamento. Muito embora os agentes de roteamento tenham acesso total às propriedades da mensagem, os agentes de recebimento SMTP são mais contextuais porque interagem com a sessão SMTP. Por exemplo, não é possível para um filtro anti-spam atuar nas propriedades da mensagem até que o host remoto tenha realmente transferido a mensagem. Por isso, é importante registrar o agente no evento de recebimento SMTP correto. Consulte a barra lateral "Desenvolvimento do agente de transporte" para obter mais detalhes.

Recursos do Exchange

• Transporte de Borda do Microsoft Exchange Server 2007 e proteção das mensagens (white paper técnico do Microsoft IT Showcase)
• Script Center do Windows PowerShell
• TechCenter do Exchange Server 2007
• Blog da equipe do Microsoft Exchange "You Had Me From EHLO"

Fique ligado

Façamos um intervalo antes de nos aprofundarmos na arquitetura de transporte e nos cenários de teste. Eu abordei várias coisas, desde a implantação dos servidores do Transporte de Borda ao estilo da TI da Microsoft até eventos internos disparados no pipeline de transporte durante o processamento das mensagens. Na segunda e última parte desta série, continuarei analisando o comportamento dos agentes do Transporte de Borda em alguns cenários de teste interessantes.

Enquanto isso, recomendo o download da versão de avaliação válida por 90 dias do Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043), e siga as explicações de Steve para compilar e instalar agentes de exemplo no seu ambiente de teste. Mesmo que não seja um desenvolvedor, você verá que cumprir essas tarefas é algo bem simples. Não me surpreenderia ver um número cada vez maior de aplicativos de negócios usando agentes personalizados, dada sua praticidade no Exchange Server 2007 de desenvolver esses componentes com o Visual Studio 2005.

Kay Unkroth é empresário e já trabalhou como engenheiro de suporte, desenvolvedor de sistema, consultor, instrutor e autor especializado em tecnologias de servidor Microsoft por mais de 15 anos. Kay também é co-fundador e presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação gerenciada e de localização.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..