TechNet Magazine > Home > Todas as edições > 2007 > November >  Comunicações: Os servidores de Transp...
Comunicações
Os servidores de Transporte de Borda do Exchange na Microsoft: parte 2
Kay Unkroth
 
Visão geral:
  • Usando os logs e os rastreamentos de Transporte de Borda
  • Configuração de anti-spam com scripts
  • Testando cenários típicos de spam
Faça download do código deste artigo: Edge2007_11.exe (161KB)

Em face da enxurrada de spam e de outros conteúdos maliciosos presente na Internet, como você pode garantir um sistema de mensagens confiável e seguro para usuários de sua organização? Uma forma, que comecei a descrever o último mês, na primeira parte desta série é implantar
os servidores de Transporte de Borda do Exchange Server 2007 e o Forefront Security para Exchange Server em uma rede de perímetro entre a Internet e o ambiente de produção.
Nesta última edição da série, explicarei como analisar os agentes de Transporte de Borda em ação usando recursos padrão de log e de rastreamento de agentes do Exchange Server 2007. Também usarei um método personalizado para despejar todos os objetos de evento do pipeline de transporte nos arquivos baseados em XML. Em seguida, ilustrarei como aplicar configurações anti-spam em um laboratório de testes de Transporte de Borda de acordo com a configuração usada pela Microsoft em seu próprio ambiente de produção corporativo. Por fim, concluirei usando alguns cenários de teste realistas e interessantes para vermos como os agentes de Transporte de Borda respondem às várias situações de spam.
Para obter mais informações sobre a instalação do laboratório de testes de Transporte de Borda e sua arquitetura geral, consulte o primeiro artigo desta série, na edição de outubro de 2007 da TechNet Magazine, disponível em technetmagazine.com/issues/2007/10/Edge.
Eu utilizo muitos scripts e arquivos em lote para automatizar as tarefas de configuração mais importantes e você poderá encontrá-los no download de código que acompanha este artigo (visite technetmagazine.com/code07.aspx). Além disso, para obter informações mais detalhadas sobre a configuração de TI da Microsoft dos agentes de Transporte de Borda, recomendo o white paper técnico "Transporte de Borda do Microsoft® Exchange Server 2007 e proteção das mensagens", produzido pelo IT Showcase da Microsoft. Baixe este white paper do IT Showcase do site microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Registro em log e rastreamento
O Exchange Server 2007 inclui alguns recursos de registro em log e de rastreamento, incluindo o log de protocolo, de agente e o rastreamento de pipeline, que facilitam o diagnóstico e a solução de problemas de agente de transporte. Embora eu não esteja solucionando os problemas de agentes de transporte neste artigo, as informações dos logs e de rastreamento são úteis para o exame do funcionamento dos agentes de Transporte de Borda.
Se você quiser rastrear informações sobre as atividades de envio e recebimento de SMTP, deverá habilitar o log de protocolo para os conectores de envio e recebimento. Usando o ambiente de testes, configurei a primeira parte desta série (consulte a Figura 1) e habilitei o log de protocolo por meio da definição dos cmdlets New-SendConnector e New-ReceiveConnector a seguir:
Figura 1 O ambiente de teste 
–ProtocolLoggingLevel: Verbose
Por padrão, você pode localizar os arquivos de log de SMTP resultantes em %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.
O log de protocolo será útil caso você queira analisar conversas SMTP, embora os agentes anti-spam nem sempre interfiram na sessão SMTP. Por exemplo, o agente Filtro de Conteúdo pode carimbar somente as mensagens de entrada com o valor SCL (Nível de Confiança de Spam). Desde que a classificação do SCL esteja abaixo de um limite especificado (o padrão é 7), o agente Filtro de Conteúdo não faz com que o processo de Transporte de Borda rejeite a mensagem. Portanto, a conversa SMTP prossegue sem ser afetada.
Para analisar as ações que os agentes anti-spam (Filtro de Conexão, Filtro de Conteúdo, Regras de Borda, Filtro de Destinatários, Filtro de Remetente e ID do Remetente) executam em mensagens que passam pelo pipeline de transporte, você precisa verificar os logs de agente em vez dos logs de protocolo. Normalmente, os logs de agente são habilitados de acordo com o parâmetro AgentLogEnabled do arquivo EdgeTransport.exe.config. Por padrão, os logs de agente estão localizados na pasta %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. É possível abrir os logs no Bloco de Notas, embora o cmdlet Get-AgentLog exiba as informações de log de agente de forma mais intuitiva no Shell de Gerenciamento do Exchange.
Outro recurso útil é o rastreamento de pipeline, que permite a você capturar instantâneos de mensagens de um determinado remetente quando elas estiverem passando pelo pipeline de transporte. A idéia é relativamente simples; o processo Transporte de Borda cria um instantâneo de cada mensagem antes e depois de chamar os agentes de recebimento e de roteamento SMTP registrados para os eventos OnEndOfHeaders, OnEndofData, OnSubmittedMessage e OnRoutedMessage. Ao comparar os instantâneos de mensagens, você pode ver como os agentes individuais modificam cada mensagem. É claro que você deve habilitar esse valioso recurso no ambiente de teste.
O uso do cmdlet Set-TransportServer a seguir ativa o rastreamento de pipeline para um usuário de teste. O parâmetro PipelineTracingEnable definido como $true permite o rastreamento de pipeline, como poderíamos esperar. O email do usuário de teste é definido no parâmetro PipelineTracingSenderAddress:
Set-TransportServer –Identity EDGE01 
–PipelineTracingEnabled $true 
-PipelineTracingSenderAddress Contoso.User@contoso.com
Com o rastreamento de pipeline habilitado, você poderá localizar arquivos de instantâneo de mensagens para cada mensagem a partir do remetente especificado (neste caso, Contoso.User@contoso.com) na pasta %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Essa é a pasta padrão. Para cada mensagem, os arquivos de instantâneo estão localizados em um subdiretório nomeado de acordo com um GUID atribuído a ela. Observe que você pode localizar a mensagem original em um arquivo chamado Original.eml e suas cópias em arquivos .eml que iniciam com SmtpReceive ou Routing, de acordo com os eventos encontrados e com os agentes instalados. Para analisar o processamento de agentes anti-spam registrados para os eventos de recebimento SMTP OnEndofData e OnEndOfHeaders, consulte os arquivos SmtpReceive*.eml. Para analisar o processamento de antivírus e de outros agentes registrados para os eventos de roteamento OnSubmittedMessage e OnRoutedMessage, analise os arquivos Routing*.eml.

Despejo de pipeline personalizado
Os recursos padrão de registro em log e de rastreamento de agentes do Exchange Server 2007 atendem a todas as necessidades de solução de problemas, apesar de não abordarem todos os eventos de transporte. Por exemplo, o rastreamento de pipeline não pode capturar informações sobre OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand e eventos de transporte similares, já que o host remetente ainda não transferiu mensagens que poderiam ser gravadas na pasta %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Se você quiser capturar informações detalhadas sobre esses eventos, terá de implementar um agente personalizado que despeje os dados de evento em arquivos no sistema de arquivos.
Como discutido no meu artigo anterior, não é complicado criar agentes personalizados e, portanto, não resisti e criei um agente de recebimento SMTP e um agente de roteamento para despejar todos os objetos de evento do pipeline de transporte para arquivos XML. É possível localizar um projeto do Microsoft Visual Studio® 2005 correspondente, chamado PipelineXMLDump, no download disponível para este artigo. Os dois arquivos importantes são DumpAgents.cs, que implementa fábricas do agente e agentes, e XMLDump.cs, que implementa uma classe auxiliar para gravar os campos de origem do evento e objetos de argumento do evento por meio dos métodos System.Reflection em arquivos XML. Se você compilar o código-fonte e copiar o arquivo PipelineXMLDump.dll resultante para uma pasta chamada C:\PipelineXMLDump do servidor de teste de Transporte de Borda, poderá registrar e habilitar os agentes personalizados usando os scripts RegisterPipelineXMLDump.ps1 e EnableDumpAgents.ps1. Os scripts foram incluídos na pasta de projeto PipelineXMLDump do download. É claro que os meus agentes personalizados servem somente para fins ilustrativos, não foram suficientemente testados e não devem ser instalados em um servidor de produção. Use-os por sua conta e risco.
DumpAgents.cs mostra como implementar todos os manipuladores de evento de recebimento e de roteamento SMTP suportados pelo pipeline de transporte. Esse pode ser um ponto de partida caso você queira implementar seus próprios agentes personalizados. Meus agentes de despejo gravam arquivos XML em subpastas em %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump que correspondem ao identificador da sessão SMTP (agente de recebimento SMTP) ou ao identificador da mensagem (agente de roteamento). A Figura 2 mostra um exemplo das informações de argumento de evento passadas para o agente de recebimento SMTP no manipulador OnConnectEvent. O exemplo revela o ponto de extremidade IP local (endereço e porta IP) que aceitou uma solicitação de conexão de entrada.
Figura 2 Informações de argumento despejadas durante o evento OnConnect (Clique na imagem para aumentar a exibição)

Preparação da execução de testes
Chega de teoria sobre registro em log, rastreamento e despejo. Vamos nos preparar para a execução de alguns testes e mostrar os agentes anti-spam em ação. A seguir, apresentarei um rápido resumo que espelha o máximo possível a configuração de TI da Microsoft em seu ambiente de teste. Como mencionado anteriormente, as informações gerais estão disponíveis no white paper técnico "Transporte de Borda do Microsoft Exchange Server 2007 e proteção das mensagens".
Comece pela desativação dos agentes Entrada de Reconfiguração de Endereço, Filtro de Anexos e Saída de Reconfiguração de Endereço ao executar o script EDGE01_disable_agents.ps1 disponível no download que acompanha este artigo. Não é necessário reescrever os endereços porque os destinatários utilizam os mesmos emails tanto interna como externamente. Eu não utilizo o agente Filtro de Anexos porque existem recursos de filtragem de anexos substitutos no Forefront Security.
O ambiente de teste não está conectado à Internet. Isso dificulta o teste do agente Filtro de Conexão. Para corrigir esse problema, crie uma lista de bloqueios de IP no host da Internet executando o arquivo INTERNET01_create_IP_block_list.bat. Verifique se as Ferramentas de Suporte do Windows® estão instaladas, já que elas incluem a ferramenta de linha de comando DNS (dnscmd.exe). Caso contrário, você terá que passar algum tempo criando os registros DNS manualmente usando o console DNS.
Agora você pode configurar o agente Filtro de Conexão executando o script EDGE01_add_block_list_provider.ps1. Esse script adiciona um provedor de Lista de Bloqueios de IP para ip-bl.consolidatedmessenger.com. Essa é a Lista de Bloqueios de IP do Consolidated Messenger, já criado no ambiente de teste pela execução do arquivo INTERNET01_create_IP_block_list.bat no host da Internet, como mencionado anteriormente. O TI da Microsoft também utiliza a Lista de Bloqueios de IP local e a Lista de Permissões de IP, mas esses recursos não exigem configuração manual. É importante observar que o TI da Microsoft não utiliza provedores de Lista de Permissões de IP.
Em seguida, configure o agente Filtro de Destinatários executando o script EDGE01_recipient_filter.ps1 para bloquear mensagens para destinatários não existentes, além de mensagens enviadas para as caixas postais e listas de distribuição globais somente para uso interno ou de saída.
O agente Filtro de Remetente também precisa de uma atualização de configuração. O TI da Microsoft utiliza a filtragem de remetente como uma medida contra ataques de inundação de emails feitos por endereços de remetentes específicos e para bloquear determinados servidores de lista e fontes similares consideradas como não relevantes aos negócios. Além disso, o TI da Microsoft utiliza a filtragem de remetente para bloquear mensagens com informações inválidas ou sem remetente. Vamos aplicar essa configuração ao ambiente de teste executando o script EDGE01_sender_filter.ps1 no servidor de Transporte de Borda.
Também será preciso configurar registros SPF (Sender Policy Framework) no DNS caso você queira espelhar a configuração do TI da Microsoft. Para gerar um registro SPF que ateste a autoridade do seu servidor de Transporte de Borda para mensagens vindas do seu domínio, adventure-works.com, você pode usar o Microsoft Sender ID Framework SPF Record Wizard (Assistente de Registro SPF da estrutura de ID do Remetente da Microsoft), disponível em microsoft.com/mscorp/safety/content/technologies/senderid/wizard. Experimente-o e especifique um nome de domínio da Internet. No ambiente de teste, execute o arquivo INTERNET01_create_SPF_record.bat no host da Internet.
E isso é tudo! Não é preciso configurar outros parâmetros, já que a maioria dos agentes vem com definições padrão razoáveis. Para executar uma verificação rápida das definições padrão mais importantes para os agentes Regras de Borda, ID do Remetente, Análise de Protocolo e Filtro de Conteúdo, execute o script EDGE01_check_defaults.ps1 no servidor de Transporte de Borda.

Agentes de Transporte de Borda em ação
Agora vamos colocar os agentes de Transporte de Borda em ação em alguns cenários realistas de serviço de mensagens. Para enviar mensagens de teste para o servidor de Transporte de Borda, eu utilizo o serviço SMTP e POP3 incluído no Windows Server 2003 e o Outlook® Express como cliente de mensagens, usando as definições padrão na maior parte do tempo, mas verificando se o registro em log está habilitado.
Mas primeiro, um aviso: não siga qualquer uma das etapas ou execute os scripts descritos nesta seção se o seu ambiente de teste tiver conexões com um sistema de produção ou com a Internet. Você está realizando testes por sua conta e risco.
O primeiro agente que irei testar é o Filtro de Conexão. Ele merece ser testado primeiro porque é o agente mais trabalhoso do servidor de Transporte de Borda. Na Microsoft, o agente Filtro de Conexão bloqueia cerca de 88% de todos os envios de mensagens pela Internet. De 13 milhões de tentativas de envio em um dia comercial normal, somente cerca de 1,5 milhão são de remetentes legítimos.
Assim, vamos enviar um email como Fabrikam.User@Fabrikam.com para Administrator@adventure-works.com. Se tudo funcionar adequadamente, o administrador não deverá receber a mensagem. Em vez disso, Fabrikam.User receberá uma DSN (notificação de status de entrega) declarando a falha na entrega ao destinatário. Fabrikam.User verifica se o endereço de email está correto, envia a mesma mensagem novamente e outra vez recebe um DSN. Em seguida, Fabrikam.User chama o suporte e informa o problema. Ela não é a primeira. Na verdade, ninguém mais na Fabrikam consegue se comunicar com a Adventure Works. Algo aconteceu. O problema é urgente. Tentando resolvê-lo com rapidez, você verifica os logs de SMTP da pasta %systemroot%\system32\Logfiles\SMTPSVC1 em INTERNET01 e, como mostrado em vermelho na Figura 3, lá está ele!
... 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,

A resposta de erro 550 diz a você que o Consolidated Messenger colocou o endereço IP do host da Internet em uma Lista de Bloqueios de IP. Bastante justo. Você entra em contato com o Consolidated Messenger para ser removido da lista. Acontece que é mais fácil entrar na lista de bloqueios do Consolidated Messenger do que ser removido dela. Levará dias, ou semanas, para limpá-la.
Você precisa de uma ajuda mais rápida e, portanto, entra em contato com a Adventure Works por meio do endereço de email cmipbl@adventure-works.com. Você envia um e-mail como Fabrikam.Admin@Fabrikam.com descrevendo a situação e solicitando o desbloqueio do endereço IP de Internet do seu host (neste caso, 192.168.1.100). Depois de verificar a sua identidade, a Adventure Works desbloqueia o endereço usando o comando a seguir para conceder uma exceção temporária que expira em 30 dias:
Add-IPAllowListEntry -IPAddress 192.168.1.100 
-ExpirationTime (get-date).AddDays(30)
Trinta dias devem dar a você bastante tempo para arrumar tudo no Consolidated Messenger e a Adventure Works não precisará perder tempo mantendo a exceção manualmente. Ao conceder exceções com expiração automática, a Adventure Works mantém a sobrecarga administrativa associada às Listas de Permissões de IP no mínimo.

Remetente seguro
Em seguida, vamos testar a percepção que a filtragem de conteúdo tem do remetente seguro, que é um recurso novo e interessante que aumenta a precisão da filtragem de spam. O EdgeSync propaga informações sobre o remetente seguro a partir do ambiente interno em forma de hash e criptografada para os servidores de Transporte de Borda. O agente Filtro de Conteúdo utiliza essas informações durante o processo de filtragem para tomar decisões informadas. Você só precisa inserir as informações do remetente seguro (ou seja, a Lista de Remetentes Seguros, a Lista de Destinatários Seguros e os contatos externos) no Active Directory® usando o cmdlet Update-SafeList e replicando as informações para o servidor de Transporte de Borda usando o cmdlet Start-EdgeSynchronization. O TI da Microsoft executa o cmdlet Update-SafeList de forma programada em um horário fora do pico. Em nosso ambiente de teste, basta executar um script correspondente (HUB-MBX-01_update_safelist.ps1) manualmente.
Primeiro, limpe o ambiente de teste executando o script EDGE01_clean_up.ps1 no servidor de Transporte de Borda para remover a entrada da Lista de Permissões de IP criada anteriormente. Isso é necessário porque o agente Filtro de Conteúdo não age em mensagens de origens que constam nessa lista. Em seguida, remova a entrada 100.1.168.192.ip-bl.consolidatedmessenger.com da lista de bloqueios de IP do Consolidated Messenger executando o arquivo INTERNET01_create_IP_block_list.bat no host da Internet. Caso contrário, o host da Internet simulado não será capaz de enviar mensagens, como demonstrado anteriormente.
Por fim, envie uma mensagem que, com certeza, será considerada como spam pelo agente Filtro de Conteúdo. Isso é complicado, já que o agente Filtro de Conteúdo utiliza o limite de rejeição padrão do SCL para entregar a maioria das mensagens aos usuários e assim minimizar a ocorrência de falsos positivos. Ainda assim, após alguns testes, encontrei uma versão de mensagem que eleva a classificação do SCL para acima do nível de rejeição. Para enviar a mensagem como Contoso.User@Contoso.com, execute o script INTERNET01_contoso_msg.vbs no host da Internet.
O meu script utiliza uma conexão SMTP anônima para enviar a mensagem para o serviço SMTP em INTERNET01. Para que isso funcione, você precisa configurar o serviço SMTP para retransmitir mensagens para usuários anônimos. No Gerenciador do IIS, abra as propriedades do Servidor Virtual SMTP Padrão. Na guia Acesso, clique no botão Retransmissão e selecione Todos exceto a lista a seguir. Falarei sobre as implicações dessa configuração em instantes.
Quando você executa o script para enviar a mensagem, Contoso.User receberá uma DSN declarando a falha na entrega com: Código de Diagnóstico: smtp;550 5.7.1 Mensagem rejeitada devido a restrições de conteúdo. Você também pode ver essa resposta no log do SMTP no host da Internet e, se executar o comando Get-AgentLog | Select-Object -Last 1 no servidor de Transporte de Borda para exibir a última entrada do log do agente, verá que a mensagem foi rejeitada porque sua classificação do SCL foi 7, como mostrado na Figura 4.
Figura 4 Mensagem bloqueada devido a restrições de conteúdo (Clique na imagem para aumentar a exibição)
Só que Contoso.User não é remetente de spam. Infelizmente, sua mensagem não passou nesse caso, mas Contoso.User normalmente consegue se comunicar com os destinatários da Adventure Works. Dessa forma, Contoso.User informa ao administrador em outro email que sua mensagem original foi bloqueada por engano. O administrador conhece Contoso.User e, para garantir que os filtros de spam não bloqueiem mais suas mensagens, o adiciona à Lista de Remetentes Seguros. Para fazer isso no Office Outlook 2007, clique com o botão direito do mouse em uma mensagem recebida de Contoso.User, aponte para Lixo Eletrônico e clique em Adicionar Remetente à Lista de Remetentes Confiáveis.
No intervalo usual, o cmdlet Update-SafeList é executado para atualizar as informações da lista segura no Active Directory e, após a próxima Sincronização de Borda, Contoso.User será capaz de se comunicar com o administrador sem falsos positivos. Para simular esse procedimento, execute o script HUB-MBX-01_update_safelist.ps1.
Agora execute o script INTERNET01_contoso_msg.vbs para enviar a mensagem de Contoso.User novamente. Verifique o log de agente no servidor de Transporte de Borda usando o comando Get-AgentLog | Select-Object -Last 1 para poder ver, em ReasonData, que a filtragem de conteúdo foi ignorada. Chega de falsos positivos para Contoso.User!

Ataque de spam
Para concluir os testes, vamos além. Sem dúvida, você já notou que eu configurei o host da Internet durante o teste anterior como uma retransmissão aberta, o que abre a porta para remetentes de spam. Dessa forma, agora veremos o que acontece se Spam.Sender@cohovineyards.com nota essa configuração e tenta se aproveitar do host para enviar milhares de mensagens de spam para a Adventure Works. O script INTERNET01_spam_msg.vbs envia somente uma mensagem de spam, você pode editá-lo e alterar o valor max_loop para gerar mais.
Para simular um ataque de spam, enviei mil mensagens para que o meu host comprometido o retransmitisse para o servidor de Transporte de Borda. O serviço SMTP limita o número de mensagens por conexão de saída a 20 e, portanto, levou algum tempo para que um número suficiente de mensagens de spam fosse retransmitido antes que o agente Análise de Protocolo do servidor de Transporte de Borda entrar em cena.
O agente Análise de Protocolo ajuda o agente Filtro de Conexão ao fazer a manutenção automática das entradas da Lista de Bloqueios de IP com base na análise do protocolo SMTP e nas atualizações da reputação de IP feitas a partir do Microsoft Update. Neste caso, a análise do protocolo SMTP encontrou os emails de spam. O agente Análise de Protocolo controla a classificação SCL de cada mensagem para calcular um valor SCL médio, usado na determinação do SRL (nível de reputação do remetente). À medida que mais e mais mensagens ilegítimas chegam durante a minha campanha de spam simulada, o SRL do host da Internet aumentou até que excedeu o limite de bloqueio de SRL. Como resultado, o host foi parar na Lista de Bloqueios de IP por 24 horas. Esse host nunca mais mandará spam! Aconteceu automaticamente. Não foi necessária nenhuma intervenção do administrador.
A Figura 5 mostra a entrada da Lista de Bloqueios de IP resultante e as alterações correspondentes na manipulação das mensagens. Antes do bloqueio do host, o servidor de Transporte de Borda rejeitou todas as mensagens de spam durante o evento OnEndOfData porque foi o Filtro de Conteúdo quem agiu em cada mensagem com base no limite do SCL (para obter uma referência, consulte a Figura 4). A mensagem foi enviada, mas não obteve êxito. Depois de bloquear o meu host, a conexão foi rejeitada pelo agente Filtro de Conexão durante o evento OnMailCommand. As mensagens não são mais enviadas. Isso economiza largura de banda da rede e recursos de processamento na desconexão de remetentes de spam antes do envio da mensagem.
Figura 5 Interrompendo um host da Internet transgressor (Clique na imagem para aumentar a exibição)

Outros testes
É claro que existem muito mais recursos e cenários de agentes que você poderá testar. Por exemplo, você pode testar a filtragem de remetente ao enviar mensagens como Blocked.User@Contoso.com ou Blocked.User@Fabrikam.com. Pode testar a filtragem de destinatários ao enviar mensagens para Blocked.User@adventure-works.com. Também é possível usar o Telnet para simular ataques de coleta de diretório em intervalos variados de tarpitting. O TI da Microsoft utiliza o intervalo padrão de cinco segundos para respostas 5yz SMTP no conector de recebimento voltado para a Internet, tempo suficiente para impedir que os remetentes de spam pratiquem os ataques de coleta de diretório. Mas você pode aplicar valores diferentes usando o cmdlet Set-ReceiveConnector, como demonstrado no script EDGE01_tarpitting.ps1.
Você também pode ir mais fundo e verificar os arquivos de instantâneo que o rastreamento de pipeline cria para as mensagens de Contoso.User@Contoso.com. Examine os carimbos de antivírus, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, que o Forefront Security utiliza para marcar as mensagens como verificadas. Quando o ForeFront Security do servidor do Transporte de Hub localiza esse carimbo com informações de versão recentes, não precisa verificar a mensagem uma segunda vez. Se você tentar enganar o Forefront Security ao inserir carimbos de antivírus falsos em suas mensagens de teste, verá o firewall de cabeçalho em ação, removendo esses carimbos logo após o evento OnDataCommand, muito antes do disparo do evento OnSubmittedMessage para a chamada do Agente de Roteamento de FSE.
Quando estiver examinando os cabeçalhos de mensagens nos arquivos de instantâneo talvez você queira criar um registro de teste SPF para Contoso.com que identifique um endereço IP incorreto como o remetente legítimo. Uma forma de fazer isso é executando o arquivo INTERNET01_wrong_SPF_record.bat no host da Internet. Em seguida, envie uma mensagem de teste como Contoso.User@Contoso.com e examine o cabeçalho X-MS-Exchange-Organization-SenderIdResult e 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)

Conclusão
Como você viu neste e em meu artigo anterior, os servidores de Transporte de Borda do Exchange Server 2007 vêm com um amplo conjunto de agentes de transporte para a implementação de recursos anti-spam confiáveis e de alta precisão, incluindo a filtragem de conexão, a análise de protocolo e a filtragem de conteúdo.A arquitetura de transporte é extensível e oferece suporte à implementação de outros agentes para obtenção de funcionalidade adicional. O agente Roteamento de FSE é um bom exemplo de um agente adicional que integra o Forefront Security para Exchange Server à arquitetura de transporte.
Combinados a recursos adicionais, como tarpitting de conexão, firewall de cabeçalho, TLS e autenticação, os servidores de Transporte de Borda oferecem os meios necessários para a obtenção de um nível muito alto de proteção ao serviço de mensagens em vários níveis e sem pontos únicos de falha. Ao implantar os servidores de Transporte de Borda e o Forefront Security em uma rede de perímetro, estritamente separados da sua organização do Exchange Server interno, você pode manter a inundação de conteúdo ilegítimo e malicioso longe do seu ambiente de mensagens e entregar as mensagens legítimas aos seus usuários com taxas muito baixas de falsos positivos.

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, 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..
Page view tracker