Boa ideia? Recusar e-mails recebidos com o nosso próprio domínio finalizado? (porque eles devem ser falsos)

33

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

Como e-mail externo de fake@example.com?

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

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

security email-server exchange-2013

— Steffen Maier
fonte

3

Você tem algum tipo de solução de filtragem de spam agora?

— ewwhite

14

Você deve verificar se não possui fornecedores de aplicativos da Web tentando enviar de seu próprio domínio. Por exemplo, se você possui um sistema de folha de pagamento que pode enviar e-mails para sua equipe em "folha de pagamento@exemplo.com". Verifique também se o marketing ou o RH podem usar um serviço de correio em massa externo e desejam que a equipe receba essas mensagens. Geralmente essas mensagens têm um remetente ou, pelo menos, um endereço de resposta de alguém em marketing ou RH. Nessas situações, você poderá colocar os servidores de email do serviço em uma lista de permissões e ainda bloquear o recebimento de seu próprio domínio (é isso que fazemos).

— Todd Wilcox

6

@NeilMcGuigan O que isso importa? O email ainda deve se originar de um servidor de email interno? Não viria de fora da rede apenas porque ele não está fisicamente presente.

— Matt

@Matt gotya, brainfart

— Neil McGuigan

1

Se você tiver notificações automáticas por email provenientes de um de seus servidores, por exemplo, falhas nas notificações de tarefas cron, ou tentativa de violação do IDS ou monitor de uso de recursos, e elas estiverem configuradas para que o endereço De esteja com seu nome de domínio. Você precisará ter o cuidado de encaminhar esses e-mails através do servidor de correio interno ou colocar na lista branca esses servidores como remetentes permitidos.

— Lie Ryan

53

Sim, se você souber que o email do seu domínio deve vir apenas de seu próprio servidor, deverá bloquear qualquer email desse domínio originário de um servidor diferente. Mesmo se o cliente de e-mail do remetente estiver em outro host, ele deverá estar conectado ao seu servidor (ou a qualquer servidor de e-mail que você use) para enviar e-mail.

Dando um passo adiante, você pode configurar seu servidor para verificar os registros SPF. Este é o número de hosts que impedem esse tipo de atividade de email. Os registros SPF são um registro DNS, um registro TXT, que fornece regras sobre quais servidores têm permissão para enviar email para o seu domínio. Como habilitar a verificação de registros SPF dependeria do seu serviço de e-mail e estaria além do escopo do que abordar aqui. Felizmente, a maioria dos ambientes e softwares de hospedagem possui documentação para trabalhar com registros SPF. Você pode querer aprender mais sobre o SPF em geral. Aqui está o artigo da Wikipedia: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
fonte

3

@Kurtovic um servidor de email bem configurado deve devolver o email que ele rejeita, para que o remetente seja notificado.

— Calimo 06/07/19

8

@Calimo Não quando ele rejeita o email por ser spam. Fazer isso apenas permitiria ao remetente de spam continuar tentando até que ele aprendesse o que seu algoritmo permite e não permite.

— Jon Bentley

27

@Calimo - não. aceitar e devolver é a pior coisa possível, você está contribuindo para o spam de dispersão inversa e SERÁ colocado na lista negra muito rapidamente. apenas rejeite as mensagens indesejadas - lidar com esse é o problema do host de envio . Se você não puder fazer isso, aceite, verifique e descarte se há spam ou malware. nunca aceite e salte.

— 6286

2

@cas: Existe uma terceira alternativa: rejeitar no momento da aceitação do SMTP. Isso deixa o ônus de produzir uma resposta de erro no servidor SMTP de envio, se ele desejar, e assim permitir que muitos remetentes legítimos vejam se seus emails foram rejeitados, garantindo que você nunca produza spam.

— R ..

2

@R .. acho que você descobrirá que essa não é uma terceira alternativa, é uma paráfrase do que eu disse "apenas rejeite as mensagens indesejadas - lidar com isso é o problema do host de envio".

— 7286

31

Já existe um padrão para fazer isso. Chama-se DMARC . Você o implementa com assinatura DKIM (que é uma boa idéia para implementar de qualquer maneira).

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

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

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

O lado negativo é que você precisa ter certeza de que tudo está resolvido com antecedência, ou pode começar a soltar e-mails legítimos.

— Mark Henderson
fonte

3

É altamente recomendável implementar SPF e DKIM antes de testar o DMARC.

— Todd Wilcox

Como o DMARC pode trabalhar com e-mails provenientes de um servidor diferente do seu, como em serviços externos, pois esses não seriam assinados pelo seu servidor?

— jpaugh

1

@jpaugh você adiciona a chave pública de outros servidores aos seus registros DMARC no seu DNS. Eles poderão fornecer o registro a ser adicionado.

— Mark Henderson

Marquei esta resposta com +1 porque é tecnicamente correta - é exatamente para isso que serve o DMARC e o que faz -, mas o DMARC é uma péssima idéia se você deseja interoperar com coisas como listas de discussão, pois viola as RFCs e geralmente se comporta mal.

— MadHatter suporta Monica

11

Esse bloqueio provavelmente reduzirá o spam e possivelmente tornará a engenharia social mais difícil, mas também poderá bloquear emails legítimos. Exemplos incluem serviços de encaminhamento de email, listas de email, usuários com clientes de email configurados incorretamente, aplicativos da Web que enviam email diretamente do host da Web sem envolver o servidor de email principal e assim por diante.

O Dkim pode atenuar isso, até certo ponto, fornecendo uma maneira de identificar uma mensagem que foi enviada da sua rede, em loop por meio de uma lista de endereços ou encaminhador e, em seguida, foi recebida pelo seu correio, mas não é uma solução perfeita, algumas listas de endereços quebram as assinaturas do dkim e você ainda tem o problema de rastrear todos os pontos de origem legítimos de email e garantir que eles passem por um assinante dkim.

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

— Peter Green
fonte

3

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, Survey Monkey, Constant Contact etc.) para enviar e-mails que parecem ser "do" seu domínio? Mesmo que não o façam hoje, poderão fazê-lo no futuro?

2) Existem endereços externos encaminhados aos seus usuários? Por exemplo, suponha que a conta do gmail "minhaempresa.sales@gmail.com" encaminhe para "vendas@minhaempresa.com" e seu usuário "bob@minhaempresa.com" envie para "minhaempresa.sales@gmail.com". Nesse caso, a mensagem chegará de "fora", mas com um endereço "@ mycompany.com" De:.

3) Algum de 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 se inscrever em "foo-list@lists.apple.com" e enviar uma mensagem, ele receberá uma mensagem de entrada parecida com: De: bob@mycompany.com Para: foo-list@lists.apple. Remetente:

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

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

— David Gelhar
fonte

2

Você pode fazer isso no PowerShell, atualizando as permissões do conector de recebimento para excluir usuários anônimos do envio como remetente de 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ê possui servidores de aplicativos remotos que precisam enviar e-mails de status para você, pois eles geralmente usam seu nome de domínio no 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.

— Neil
fonte

1

O GMail possui uma configuração na qual permite enviar emails com um domínio que não seja do GMail, desde que o endereço de email seja verificado pela primeira vez. Sua decisão bloquearia esses e-mails.

Se você tem ou não usuários que podem usar esse recurso do GMail e se faz sentido atender a eles, depende muito do comportamento da sua empresa.

— cristão
fonte

-1

O SPF não resolverá isso, pois o envelope pode ter um passe SPF adequado (por exemplo, remetentes de spam usando um servidor comprometido) enquanto forja o email dentro do envelope. O que você precisa é de um bloqueio na sua mensagem de email de domínio que tenha um servidor de email de origem no envelope não aceitável para você.

— Jim
fonte

"O que você precisa é de um bloqueio em sua própria mensagem de email de domínio que tenha um servidor de email de origem no envelope não aceitável para você" - é exatamente isso que você faz com o SPF, crie uma lista de servidores de email de origem legítimos para o seu domínio.

— precisa