Exchange Server 2007

A luta contra o spam e o phishing com o ID de Remetente

Craig Spiezle and Alexander Nikolayev

Visão geral:

• Noções básicas sobre ID de Remetente
• Configuração de ID de Remetente no Exchange Server
• Benefícios da autenticação

Muitas tecnologias de identificação e filtragem vêm sendo desenvolvidas em resposta à crescente ameaça do spam. Para serem eficazes, elas se apóiam em certas perguntas sobre cada mensagem de email,

como “quem a enviou”. Infelizmente, a pergunta fundamental sobre quem enviou a mensagem não é sempre fácil de ser respondida. Emails são, normalmente, enviados pela Internet sem nenhuma autenticação do remetente ou dos computadores que agem em nome dele. Na realidade, é fácil enviar um email fingindo ser uma outra pessoa, e não há métodos automatizados para a detecção de mensagens falsificadas.

O SMTP, que é usado para enviar e receber emails, não foi projetado para verificar o remetente de uma mensagem de email. Com essa brecha tecnológica, qualquer nome e endereço podem ser inseridos como remetente. Por conseqüência, a filtragem de conteúdo ou medidas anti-spam não podem confiar apenas nas informações do cabeçalho para assegurar que as mensagens realmente venham de onde dizem que vêm.

A autenticação de emails trata especificamente dessa brecha. Com a autenticação, os sistemas de envio e recebimento de emails fazem a validação das mensagens provenientes dos domínios de onde alegam vir. Isso facilita que as organizações filtrem o lixo eletrônico com eficácia, garantindo, dessa forma, que os emails legítimos cheguem a seus destinatários.

Hoje, existem duas abordagens livres de royalties para autenticação de email: SIDF (estrutura de ID de Remetente) e DKIM (correspondência identificada por chaves de domínio). O SIDF é uma solução baseada em protocolo de Internet (IP, Internet Protocol) criada a partir da fusão de SPF (estrutura de diretivas de remetente) e do ID do chamador para emails da Microsoft. Em abril de 2006, a IETF (força-tarefa de engenharia de Internet) publicou as especificações do ID de Remetente na forma das RFCs 4405-4408. Uma coligação de partes interessadas do setor, inclusive a Microsoft, recomenda a implantação do SIDF tendo por base fatores como valor técnico e comercial, estabilidade, maturidade, facilidade de implantação, impacto mínimo no desempenho de entrada ou saída e interoperabilidade com o ecossistema de emails para ISPs e ambientes empresariais.

O DKIM é a combinação das especificações DomainKeys da Yahoo! e de IIM (correspondência por Internet identificada) da Cisco Systems Inc. Em janeiro de 2006, a IETF aprovou a criação de um grupo de trabalho DKIM e a especificação está atualmente sob exame da IETF.

Embora não exista uma solução perfeita para conter o spam, o SIDF representa uma iniciativa significativa do mercado para conter domínios falsificados. Em decorrência disso, trata-se de um componente essencial para a redução de spam e de ataques de phishing e o aumento do crédito e da confiança online. Organizações em todo o mundo estão adotando o SIDF em grande escala. Hoje, mais de 5,5 milhões de empresas e detentores de domínios já publicaram registros SPF e mais de 600 milhões de usuários estão protegidos pelo SIDF. Atualmente, mais de um terço do volume diário de emails do mundo já é autenticado e compatível com SIDF.

O desenvolvimento e a adoção mundial do SIDF não seria possível sem a contribuição e o suporte de muitas organizações e empresas, dentre as quais AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, além de outras.

Noções básicas sobre o ID de Remetente

Alguns levantamentos da indústria indicam que mais de 95 por cento dos atos fraudulentos de phishing provêm de domínios falsificados e têm endereços de email de remetente falsificados. É aí que o SIDF faz uma enorme diferença no que diz respeito ao processamento anti-spam. Sozinho, o SIDF não resolverá o problema do spam, mas contribui muito para minimizar as conseqüências do spam e de ataques de phishing. O SIDF não impede que o lixo eletrônico seja enviado. Entretanto, ele torna muito mais fácil detectar o lixo eletrônico. A estrutura ajuda os remetentes de email a protegerem seus nomes de domínio, reputações e marcas. Ele proporciona uma base sólida para se tomar decisões de filtragem com base na reputação e no comportamento de email do remetente.

O ID de Remetente verifica se cada mensagem de email provém do domínio de Internet do qual alega ter sido enviada. Isso é feito através da comparação do endereço do servidor remetente do email com uma lista registrada dos servidores que o proprietário do domínio autorizou a enviar emails. A verificação é realizada automaticamente pelo ISP (provedor de serviços de Internet) ou pelo servidor de emails do destinatário antes de a mensagem ser entregue à caixa de entrada do usuário.

Observe que o ID de Remetente, ou qualquer outro mecanismo de autenticação, não substitui os sistemas de filtragem de conteúdo. Nem o SIDF, nem o DKIM examinam o conteúdo real da mensagem. Em vez disso, a autenticação notifica o sistema de entrada de emails se a mensagem pode ser validada como oriunda do remetente alegado. Como a maioria dos ataques de spam e phishing não partem, na realidade, do domínio declarado, esta abordagem pode ajudar a identificar automaticamente essas mensagens e separá-las do fluxo de entrada de emails.

Dentro do SIDF, o registro SPF fornece um registro de texto simples de todos os servidores de email de saída associados a um domínio, junto com os respectivos endereços IP. A organização deve publicar o registro SPF no arquivo de zona de servidor de seu DNS, para ser, posteriormente, verificado pelos servidores de email de destino. Configurar um registro SPF é rápido, fácil e grátis. O Assistente de Registro SPF da estrutura de ID de Remetente disponibiliza um processo passo a passo para fazer o levantamento dos servidores de email de um domínio e criar registros personalizados prontos para serem postados. (Os detalhes da publicação de um registro SPF estão disponíveis em microsoft.com/senderid. O assistente pode ser acessado diretamente em microsoft.com/senderid/wizard.)

O servidor de email SMTP de recebimento faz o ping do arquivo de zona do domínio no DNS em busca de um registro SPF existente. Uma vez encontrado, o endereço IP do servidor remetente é comparado com os endereços IP listados. Se houver correspondência, a mensagem será validada como autêntica. Se, por outro lado, o registro SPF no domínio do remetente não corresponder ao endereço IP da origem da mensagem, haverá uma falha que resultará em uma pontuação negativa e sua potencial colocação na pasta de lixo eletrônico. A Figura 1 mostra esse processo.

Figura 1** Verificação dos registros SPF para mensagens de entrada **(Clique na imagem para aumentar a exibição)

Com a mensagem marcada, o SIDF permite que o servidor de email destinatário a analise com base em comportamentos passados, na reputação do remetente, em seu conteúdo e em outros critérios que podem ser definidos conforme a necessidade. Esse recurso proporciona garantias extras. Por exemplo, os remetentes de spam podem registrar domínios de aparência enganadora e publicar registros SPF para ludibriar o usuário e a rede de recebimento de forma que pensem que o email provém de um remetente legítimo. E, ainda que a mensagem de email possa passar pela verificação de autenticação, a reputação do remetente como spam será suficiente para bloquear, por no lixo ou excluir a mensagem.

Opções de implantação de ID de Remetente

A autenticação de emails que saem via SIDF não requer nenhuma alteração de infra-estrutura ou atualização de software e não é específica de software de cliente ou servidor. Entretanto, as organizações que quiserem incorporar a autenticação de entrada para proteger as suas empresas e funcionários terão que atualizar seus sistemas de entrada e o MTA (agente de transferência de mensagem) e implantar software ou uma aplicação que aceite SIDF. A maioria dos MTAs de código-fonte aberto e fornecedores de anti-spams líderes do mercado, inclusive o Exchange Server e o Exchange Hosted Filtering da Microsoft®, oferece soluções integradas.

A Microsoft integrou o SIDF em todos os seus produtos de sistemas de mensagens, inclusive Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express e os clientes de colaboração e sistema de mensagens do Office Outlook.

No entanto, nem mesmo a Microsoft está isenta de receber spam. A média diária de tráfego de entrada na Microsoft é de, aproximadamente, 15 milhões de mensagens e, durante ataques recentes de spam, vimos esse volume aumentar de duas até quatro vezes. Em tal ambiente, a rota para a proteção com êxito contra spam reside na implementação vigilante das tecnologias disponíveis.

A Microsoft está executando uma solução anti-spam interna de Exchange Server baseada no filtro de ID de Remetente do Exchange Server 2003 e no agente de ID de Remetente do Exchange Server 2007. Em ambas as versões do Exchange Server, o status do ID de Remetente se baseia na avaliação do registro do ID de Remetente localizado nos servidores DNS correspondentes. O domínio real é determinado pelo exame dos cabeçalhos de mensagem RFC 2822, na seguinte prioridade:

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

O domínio do remetente (ou da última entidade responsável por injetar uma mensagem no fluxo de troca de mensagens, pois os sistemas de email podem, legitimamente, encaminhar correspondência em nome de outros servidores de email) é determinado pela localização da primeira definição dos cabeçalhos mencionados, na ordem estabelecida. Se nenhum desses cabeçalhos for encontrado, o SIDF usará o valor SMTP RFC 2821 MAIL FROM.

Configuração do ID de Remetente

No Exchange Server 2007, o agente de ID de Remetente pode ser habilitado nos servidores que possuem a função Transporte de Borda instalada. Se o agente de ID de Remetente estiver habilitado, ele filtrará as mensagens que chegam pelos conectores de recebimento — todo tráfego de entrada (de origem externa) não autenticado estará sujeito ao processamento de ID de Remetente. No Exchange Server 2003, o status do ID de Remetente permanece de servidor a servidor no blob EXCH50; no Exchange Server 2007 ele também foi adicionado aos metadados de mensagens. No destino final, ambos são convertidos em uma propriedade MAPI para futuro consumo pelo cliente.

A configuração da Filtragem de ID de Remetente no Exchange Server 2003, disponível em Message Delivery Properties, consiste apenas em especificar como o Exchange Server deve manipular validações reprovadas.

Para habilitar o ID de Remetente no Exchange Server 2007, basta abrir o Console de Gerenciamento do Exchange de um servidor com a função Transporte de Borda configurada, selecionar a guia Anti-spam, depois ID de Remetente e, no painel Ações, clicar em Habilitar ou Desabilitar para alternar o agente do ID de Remetente, como mostra a Figura 2. Adicionalmente, é possível usar o Shell de Gerenciamento do Exchange para habilitar ou desabilitar o ID de Remetente, como mostra a Figura 3.

Figura 2** Controles do console de gerenciamento do Exchange para o agente de ID de Remetente no Exchange Server 2007 **(Clique na imagem para aumentar a exibição)

Figura 3** Habilitação do ID de Remetente por meio do Shell de Gerenciamento do Exchange **(Clique na imagem para aumentar a exibição)

A caixa de diálogo Propriedades do ID de Remetente refletirá o status do agente, seja habilitado ou desabilitado. A guia Ação oferecerá opções muito similares àquelas disponíveis no Exchange Server 2003 (consulte a Figura 4).

Figura 4** Propriedades da ação do agente de ID de Remetente no Exchange Server 2007 **(Clique na imagem para aumentar a exibição)

Em termos de implementação e funcionalidade do ID de Remetente, não há grande diferença entre o Exchange Server 2003 e o Exchange Server 2007, sendo que o filtro de ID de Remetente (no Exchange Server 2003) e o agente de ID de Remetente (no Exchange Server 2007) usam, ambos, o mesmo algoritmo subjacente para extração e verificação. A gama de ações possíveis também é a mesma: Delete Message (exclusão silenciosa), Reject Message (resposta do protocolo SMTP de nível 500), Stamp the message with the Sender ID result e Continue processing. Esta última opção é a ação padrão em ambas as versões do Exchange Server.

No Exchange Server 2007, os códigos de status FAIL e TempError podem, ambos, disparar uma ação Reject Message (no Exchange Server 2003, somente o código de status FAIL pode disparar essa ação). O agente de ID de Remetente precisa estar explicitamente configurado para disparar a ação Reject Message em mensagens com código de status TempError, porque, por padrão, essas mensagens serão aceitas no sistema, carimbadas com o resultado do ID de Remetente e, em seguida, processadas.

A opção de configuração para tanto é não exposta na interface gráfica de usuário, de modo que você pode usar o Shell de Gerenciamento do Exchange para configurar ações de ID de Remetente para o código com status TempError. Por exemplo, para impor que o agente de ID de Remetente rejeite mensagens com código de status TempError, execute o seguinte cmdlet:

Set-SenderIDConfig -TempErrorAction Reject

A gama de resultados de status e ações possíveis de ID de Remetente no Exchange Server 2007 é similar à do filtro de ID de Remetente do Exchange Server 2003, como mostra a Figura 5.

Figure 5 Status e ações do ID de Remetente no Exchange Server 2007

O Exchange (se configurado para tal) excluirá somente as mensagens que forem reprovadas pela verificação de ID de Remetente. Nenhum outro resultado disparará a exclusão da mensagem. Mensagens de entrada que resultarem em atribuição dos status Neutral, None, SoftFail, TempError ou PermError serão adequadamente carimbadas e transmitidas para verificação anti-spam adicional. Em alguns casos, quando a mensagem se encontra irremediavelmente mal constituída e o endereço IP FROM está faltando, não é possível carimbar o status de ID de Remetente na mensagem. Nessa situação, a mensagem não é descartada ou rejeitada. Em vez disso, ela será transmitida para processamento adicional sem o status de ID de Remetente e um evento apropriado será registrado para dar ciência disso.

No Exchange Server 2007, é fácil definir domínios remetentes e destinatários de Exchange Server que devem ser excluídos da verificação de ID de Remetente. Mais uma vez, esta opção de configuração está disponível somente no Shell de Gerenciamento do Exchange. Por exemplo, para excluir o domínio contoso.com da filtragem de ID de Remetente, execute o seguinte comando:

Set-SenderIDConfig -BypassedSenderDomains contoso.com

De modo similar, para excluir da filtragem de ID de Remetente mensagens enviadas a destinatários especificados de Exchange Server, execute o seguinte comando:

Set-SenderIDConfig -BypassedRecipients user@contoso.com

No Exchange Server 2007, os valores de configuração de ID de Remetente definidos via cmdlets do Shell de Gerenciamento do Exchange, mas indisponíveis através da interface gráfica de usuário, podem ser facilmente obtidos por meio da execução do comando Get-SenderIDConfig no Shell de Gerenciamento do Exchange, como mostra a Figura 6.

Figura 6** Cmdlets de configuração de ID de Remetente **(Clique na imagem para aumentar a exibição)

O Shell de Gerenciamento do Exchange pode ser usado para verificação manual rápida do endereço IP e do nome de domínio correspondente. Para verificar o status de ID de Remetente, execute o seguinte comando:

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

Se o domínio não existir, um resultado semelhante ao da Figura 7 mostrada.

Figura 7** Verificação do status de ID de Remetente de um endereço **(Clique na imagem para aumentar a exibição)

Benefícios do ID de Remetente

Além de suas vantagens óbvias na autenticação de mensagens de email e na redução da quantidade de spam recebida pelos usuários, o SIDF, enquanto protocolo, oferece ainda outros benefícios. Durante seu desenvolvimento, a Microsoft se concentrou em várias metas fundamentais, inclusive desempenho, custo, implantação e escalabilidade e interoperabilidade.

O SIDF, primeiro, autentica o remetente do email e permite a aplicação da contagem de pontos da reputação do remetente. Por conseqüência, ele tem o potencial de reduzir significativamente mensagens de spam e emails falsificados, bem como melhorar a capacidade de entrega de emails legítimos, oriundos de remetentes conhecidos e confiáveis. Criar um registro SPF é grátis, de modo que é fácil para qualquer organização tornar-se compatível com SIDF. As organizações que desejarem atender às provisões de um novo padrão devem poder fazer isso. Com o SIDF, para tanto, basta publicar um registro SPF.

O SIDF foi desenvolvido para operar em softwares existentes sempre que possível. Ele pode ser usado com uma vasta gama de arquiteturas de email e software cliente e servidor. Para ser eficaz, todo o serviço de autenticação precisa atender às necessidades dos maiores ISPs de forma tão fácil quanto ao menor servidor de email doméstico. O SIDF pode dar suporte desde um até milhares de servidores de email, mais aqueles que terceirizam seus servidores de email para outras organizações.

Em 18 e 19 de abril de 2007, a Microsoft e um consórcio comercial de mais de 30 organizações e parceiros promoverão a Encontro de Autenticação e Identidade Online, em Boston, Massachussets/EUA. Esse programa de dois dias examinará estudos de caso e oferecerá uma revisão técnica do ID de Remetente, detalhando os valores comerciais da autenticação de emails. Para obter mais informações, visite aotalliance.org/summit2007. Além disso, para obter informações sobre ferramentas e recursos, visite microsoft.com/senderid e microsoft.com/exchange.

Craig Spiezle é diretor de estratégia e planejamento de tecnologia do Windows Live Safety na Microsoft. Como gerente de produtos para autenticação de email, Craig tem sido uma força motriz em trazer o ID de Remetente para o mercado. Começando na Microsoft em 1992, Craig ocupou várias posições de gerência, inclusive de marketing internacional, estratégias de suporte a produtos, OEM e desenvolvimento para mercados emergentes.

Alexander Nikolayev é o gerente de programas da Microsoft encarregado dos protocolos de servidor, núcleo de transporte e componentes anti-spam para Exchange Server e Windows Server. Ele possui título de MBA da Universidade de Mary. Leia as postagens de Alexander no blog da equipe do Exchange em blogs.technet.com/exchange.

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