Bonne idée? Refuser les emails entrants avec la fin de notre propre domaine? (parce qu'ils doivent être faux)

33

J'ai une question à propos de notre serveur Exchange: Pensez-vous que ce soit une bonne idée de refuser les courriels externes entrants qui ont leur propre domaine à la fin?

Comme email externe de fake@example.com?

Parce que s’il s’agissait d’un véritable expéditeur de notre société, le courrier électronique ne viendrait jamais de l’extérieur?

Si oui, quel est le meilleur moyen de le faire?

security email-server exchange-2013

— Steffen Maier
source

3

Avez-vous une sorte de solution de filtrage anti-spam en place actuellement?

— ewwhite

14

Vous devriez vérifier que vous n'avez aucun fournisseur d'applications Web essayant d'envoyer depuis votre propre domaine. Par exemple, si vous avez un système de paie susceptible d'envoyer des courriers électroniques à votre personnel depuis "payroll@example.com". Vérifiez également si le marketing ou les ressources humaines peuvent utiliser un service de courrier externe en masse et qu'ils souhaitent que le personnel reçoive ces messages. Habituellement, ces messages ont une adresse d'expéditeur ou au moins une adresse de réponse d'un responsable du marketing ou des ressources humaines. Dans ces situations, vous pourrez généralement placer les serveurs de messagerie du service sur une liste d'autorisation tout en bloquant votre propre domaine entrant (c'est ce que nous faisons).

— Todd Wilcox

6

@NeilMcGuigan Qu'importerait-il? Le courrier doit toujours provenir d'un serveur de messagerie interne? Cela ne viendrait pas de l'extérieur du réseau simplement parce qu'il n'est pas physiquement présent.

— Matt

@ Matt Gotya, brainfart

— Neil McGuigan

1

Si vous avez automatisé des notifications par courrier électronique provenant de l'un de vos serveurs, par exemple, des notifications d'échec de tâches cron ou une tentative de violation par IDS ou un moniteur d'utilisation des ressources sont configurées de manière à ce que leur adresse de l'expéditeur corresponde à votre nom de domaine. Vous devez veiller à acheminer ces courriels via votre serveur de messagerie interne ou à les ajouter à la liste blanche en tant qu’expéditeurs autorisés.

— Lie Ryan

53

Oui, si vous savez que le courrier électronique de votre domaine ne doit provenir que de votre propre serveur, vous devez bloquer tout courrier électronique de ce domaine provenant d'un autre serveur. Même si le client de messagerie de l'expéditeur se trouve sur un autre hôte, celui-ci doit se connecter à votre serveur (ou à tout serveur de messagerie que vous utilisez) pour envoyer un courrier électronique.

Pour aller plus loin, vous pouvez configurer votre serveur pour vérifier les enregistrements SPF. C'est le nombre d'hôtes qui empêche ce type d'activité de messagerie. Les enregistrements SPF sont un enregistrement DNS, un enregistrement TXT, qui donne des règles sur les serveurs autorisés à envoyer des emails pour votre domaine. L'activation de la vérification des enregistrements SPF dépend de votre service de messagerie et dépasse le cadre de ce que vous devez couvrir ici. Heureusement, la plupart des environnements d'hébergement et des logiciels disposeront d'une documentation permettant de travailler avec les enregistrements SPF. Vous voudrez peut-être en savoir plus sur SPF en général. Voici l'article de Wikipedia: https://en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
source

3

@Kurtovic, un serveur de messagerie bien configuré doit renvoyer le courrier qu'il refuse, pour que l'expéditeur soit averti.

— Calimo

8

@Calimo Pas quand il rejette le courrier électronique en tant que spam. Cela permettrait simplement au spammeur de continuer à essayer jusqu'à ce qu'il ait appris ce que votre algorithme permet et ne permet pas.

— Jon Bentley

27

@Calimo - non. accepter-et-rebondir est la pire des choses à faire, vous contribuez à la diffusion de spam et vous vous retrouvez sur la liste noire très rapidement. rejetez simplement le courrier indésirable - le problème est celui de l' hôte d' envoi . Si vous ne pouvez pas le faire, acceptez, vérifiez et éliminez le spam ou les logiciels malveillants. ne jamais accepter et rebondir.

— cas

2

@cas: Il existe une troisième alternative: rejeter au moment de l'acceptation du protocole SMTP. Cela laisse le fardeau de produire une réponse d'erreur sur le serveur SMTP d'envoi, s'il le souhaite, et permet ainsi à de nombreux expéditeurs légitimes de voir si leur courrier a été rejeté, tout en garantissant que vous ne produirez jamais de spam par vous-même.

— R ..

2

@R .. Je pense que vous constaterez que ce n'est pas une troisième alternative, c'est une paraphrase de ce que j'ai dit: "rejetez simplement le courrier indésirable - le problème, c'est le problème de l'hôte d'envoi".

— cas

31

Il existe déjà une norme pour le faire. Cela s'appelle DMARC . Vous l'implémentez avec la signature DKIM (ce qui est une bonne idée à mettre en œuvre de toute façon).

La vue d'ensemble de haut niveau consiste à signer chaque e-mail qui quitte votre domaine avec un en-tête DKIM (ce qui est néanmoins une bonne pratique). Ensuite, vous configurez DMARC pour rejeter tous les courriers électroniques provenant de votre domaine appartenant à votre serveur de messagerie et non signés avec un en-tête DKIM valide.

Cela signifie que des services externes peuvent toujours envoyer des messages électroniques à votre domaine (comme un logiciel de support hébergé, etc.), mais que vous pouvez bloquer les tentatives de phishing.

L'autre atout de DMARC est que vous recevez des rapports d'échec, ce qui vous permet de gérer le traitement des exceptions selon vos besoins.

L'inconvénient est que vous devez vous assurer que tout est bien trié à l'avance ou que vous pourriez commencer à jeter des courriels légitimes.

— Mark Henderson
source

3

Il est fortement recommandé d'implémenter SPF ainsi que DKIM avant de tester DMARC.

— Todd Wilcox

Comment DMARC peut-il fonctionner avec des courriers électroniques provenant d’un serveur différent du vôtre, tel que des services externes, puisque ceux-ci ne seraient pas signés par votre serveur?

— Jpaugh

1

@jpaugh vous ajoutez la clé publique des autres serveurs à vos enregistrements DMARC dans votre DNS. Ils pourront vous donner le compte rendu à ajouter.

— Mark Henderson

Cette réponse a été attribuée à +1 parce que c'est techniquement correct - c'est exactement ce à quoi servent DMARC - mais DMARC est une très mauvaise idée si vous souhaitez interagir avec des éléments tels que les listes de diffusion, car il enfreint les RFC et se comporte généralement mal.

— MadHatter soutient Monica le

11

Un tel blocage est susceptible de réduire le spam et de rendre éventuellement plus difficile l'ingénierie sociale, mais il peut également bloquer le courrier légitime. Les exemples incluent les services de transfert de courrier, les listes de diffusion, les utilisateurs avec des clients de messagerie mal configurés, les applications Web qui envoient le courrier directement à partir de l'hébergeur Web sans impliquer votre serveur de messagerie principal, etc.

Dkim peut atténuer cela dans une certaine mesure en fournissant un moyen d'identifier un message envoyé depuis votre réseau, passé en boucle dans une liste de diffusion ou un redirecteur, puis reçu par votre courrier, mais ce n'est pas un remède parfait. Certaines listes de diffusion briseront les signatures de dkim et vous avez toujours le problème de localiser tous les points d’origine du courrier légitimes et de vous assurer qu’ils passent par un signataire dkim.

Faites attention, surtout si vous implémentez ceci sur un domaine existant.

— Peter Green
source

3

Peut-être, mais vous devez envisager certains cas avant de procéder à un tel changement.

1) Quelqu'un dans votre entreprise utilise-t-il un type de service externe (par exemple, Survey Monkey, Constant Contact, etc.) pour envoyer des courriels qui semblent appartenir à votre domaine? Même s'ils ne le font pas aujourd'hui, pourraient-ils le faire à l'avenir?

2) Y a-t-il des adresses extérieures qui transmettent à vos utilisateurs? Par exemple, supposons que le compte gmail "mycompany.sales@gmail.com" soit transféré à "sales@mycompany.com" et que votre utilisateur "bob@mycompany.com" soit envoyé à "mycompany.sales@gmail.com". Dans ce cas, le message arrivera de "dehors", mais avec une adresse "@ mycompany.com" De:.

3) Certains de vos utilisateurs sont-ils abonnés à des listes de distribution externes qui conservent l'adresse d'origine "De:" dans les messages de la liste? Par exemple, si Bob s'abonne à "foo-list@lists.apple.com" et envoie un message, il recevra un message entrant ressemblant à peu près à: De: bob@mycompany.com À: foo-list@lists.apple. com expéditeur:

Si votre serveur regarde naïvement l'en-tête "De:" (au lieu de "Sender:"), il risque de rejeter ce message car vous le recevez de l'extérieur.

En raison de tout ce qui précède, il n’est pas toujours faisable d’avoir une politique générale consistant à "... de la part d’un expéditeur réel de notre société, le courrier électronique ne viendrait jamais de l’extérieur".

— David Gelhar
source

2

Vous pouvez le faire dans PowerShell en mettant à jour vos autorisations du connecteur de réception pour exclure les utilisateurs anonymes de l'envoi en tant qu'expéditeur de domaine faisant autorité:

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

Cependant, le problème se pose lorsque vous avez des serveurs d'applications distants qui doivent vous envoyer des courriels d'état, car ils utilisent généralement votre nom de domaine dans leur adresse de départ. Il est possible de créer un connecteur de réception supplémentaire pour leurs adresses IP spécifiques afin de ne pas les exclure par inadvertance.

— Neil
source

1

GMail a un paramètre qui vous permet d’envoyer des courriers électroniques avec un domaine autre que GMail à condition que la première adresse e-mail soit vérifiée. Votre décision bloquerait ces courriels.

Que vous ayez ou non des utilisateurs qui pourraient utiliser cette fonctionnalité de Gmail et qu'il soit logique de les gérer dépend du comportement de votre entreprise.

— Christian
source

-1

Le SPF ne résoudra pas le problème, car l'enveloppe pourrait avoir un bon passeport (c.-à-d. Que les spammeurs utilisant un serveur compromis) falsifieraient le courrier électronique à l'intérieur de l'enveloppe. Ce dont vous avez besoin est un bloc sur votre propre courrier électronique de domaine qui possède un serveur de messagerie d'origine sur l'enveloppe que vous ne pouvez pas accepter.

— Jim
source

"Ce dont vous avez besoin, c'est d'un bloc sur votre courrier électronique de domaine qui possède un serveur de messagerie d'origine sur l'enveloppe que vous ne pouvez pas accepter" - c'est exactement ce que vous faites avec SPF: créez une liste de serveurs de messagerie d'origine légitimes pour votre domaine.

— GAThrawn