Boa ideia? Recusa os e-mails recebidos com nosso próprio domínio terminado? (porque eles devem ser falsos)

Question

Tenho uma pergunta sobre o nosso Exchange Server: Você acha que é uma boa idéia recusar e-mails externos que tenham nosso próprio domínio no final?

Como e-mail externo de [email protected] ?

Porque se fosse de um remetente real em nossa empresa, o e-mail nunca viria de fora?

Se sim, qual é a melhor maneira de fazer isso?

    

Answer 1

Sim, se você souber que o e-mail do seu domínio deve vir apenas do seu próprio servidor, bloqueie qualquer e-mail desse domínio originado em outro servidor. Mesmo que o cliente de e-mail do remetente esteja em outro host, ele deve estar efetuando login em seu servidor (ou qualquer servidor de e-mail que você use) para enviar e-mail.

Levando isso um passo adiante, você pode configurar seu servidor para verificar os registros SPF. É assim que muitos hosts impedem esse tipo de atividade de email. Os registros SPF são um registro DNS, um registro TXT, que fornece regras sobre quais servidores podem enviar e-mails para seu domínio. Como habilitar a verificação de registros SPF dependerá do seu serviço de e-mail e estará além do escopo do que abordar aqui. Felizmente, a maioria dos ambientes e software de hospedagem terá documentação para trabalhar com registros SPF. Você pode querer aprender mais sobre o SPF em geral. Veja o artigo da Wikipédia: link

    

Answer 2

Existe um padrão para fazer isso já. É chamado DMARC . Você o implementa com assinatura DKIM (o que é uma boa ideia implementar de qualquer forma).

A visão geral de alto nível é que você assina todos os e-mails que deixam seu domínio com um cabeçalho DKIM (o que é uma boa prática de qualquer maneira). Em seguida, você configura o DMARC para rejeitar todos os e-mails que chegam ao seu servidor de e-mail, de um domínio que você possui, que não esteja assinado com um cabeçalho DKIM válido.

Isso significa que você ainda pode ter serviços externos entregando e-mails para o seu domínio (como software de helpdesk hospedado, etc), mas pode bloquear tentativas de spear phishing.

A outra grande coisa sobre o DMARC é que você recebe relatórios de falhas, para que você possa gerenciar o tratamento de exceções conforme necessário.

O lado negativo é que você precisa ter certeza de que tudo foi resolvido de antemão ou pode começar a soltar e-mails legítimos.

    

Answer 3

Tal bloqueio provavelmente reduzirá o spam e tornará a engenharia social mais difícil, mas também pode bloquear o correio legítimo. Os exemplos incluem serviços de encaminhamento de e-mail, listas de discussão, usuários com clientes de e-mail configurados incorretamente, webapps que enviam e-mail diretamente do host da Web sem envolver seu servidor de e-mail principal e o serviço de conexão.

O Dkim pode atenuar isso de alguma forma, fornecendo uma maneira de identificar uma mensagem que foi enviada da sua rede, colocada em loop por uma lista de mala direta ou remetente e depois recebida em seu e-mail, mas não é uma cura perfeita. quebrar as assinaturas dkim e você ainda tem o problema de rastrear todos os pontos de originação de e-mail legítimos e certificar-se de que eles passam por um assinante dkim.

Oriente-se com cuidado, especialmente se estiver implementando isso em um domínio existente.

    

Answer 4

Talvez, mas há alguns casos que você precisa considerar antes de fazer essa alteração.

1) Alguém na sua empresa usa algum tipo de serviço externo (por exemplo, o Survey Monkey, o Constant Contact, etc.) para enviar e-mails que pareçam ser "de" seu domínio? Mesmo que eles não estejam fazendo isso hoje, eles podem fazer isso no futuro?

2) Há algum endereço externo encaminhado para seus usuários? Por exemplo, suponha que a conta do Gmail "[email protected]" envie para "[email protected]" e seu usuário "[email protected]" envie para "[email protected]". Nesse caso, a mensagem chegará de "fora", mas com um endereço "@ minhaempresa.com" De:

3) Algum dos seus usuários está inscrito em listas de distribuição externas que preservam o endereço "De:" original nas mensagens da lista? Por exemplo, se Bob inscrever-se em "[email protected]" e enviar uma mensagem, ele receberá uma mensagem de entrada parecida com:   De: [email protected]   Para: [email protected]   Remetente:

Se o seu servidor olhar ingenuamente para o cabeçalho "De:" (em vez de "Remetente:"), ele poderá rejeitar esta mensagem porque você a está recebendo de fora.

Por causa de todos os itens acima, ter uma política geral de "... de um remetente real em nossa empresa, o e-mail nunca viria de fora" nem sempre é viável.

    

Answer 5

Você pode fazer isso no PowerShell atualizando as permissões do Conector de Recebimento para excluir usuários anônimos do envio como um remetente do domínio autoritativo:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

No entanto, o problema surge quando você tem servidores de aplicativos remotos que precisam enviar e-mails de status para você, pois geralmente usam seu nome de domínio em seu endereço De. É possível criar um conector de recebimento adicional para seus endereços IP específicos, para que você não os exclua inadvertidamente.

    

Answer 6

O Gmail tem uma configuração onde permite enviar e-mails com um domínio que não seja do Gmail, desde que o endereço de e-mail seja verificado pela primeira vez. Sua decisão bloquearia esses emails.

Se você tem ou não usuários que possam usar esse recurso do Gmail e se faz sentido atender a eles depende muito do comportamento dentro de sua empresa.

    

Answer 7

O SPF não vai curar isso, pois o envelope pode ter uma passagem de SPF adequada (ou seja, spammers usando servidor comprometido) enquanto eles forjam o email dentro do envelope. O que você precisa é de um bloqueio em sua própria mensagem de e-mail de domínio que tenha um servidor de e-mail de origem no envelope não aceitável para você.