Bonne idée? Refuser les e-mails entrants avec la fin de votre propre domaine? (parce qu'ils doivent être faux)
J'ai une question sur notre serveur Exchange: pensez-vous que c'est une bonne idée de refuser les e-mails externes entrants qui ont notre propre domaine à la fin?
Comme un e-mail externe de [email protected]?
Parce que s'il provenait d'un véritable expéditeur dans notre entreprise, l'e-mail ne proviendrait jamais de l'extérieur?
Si oui, quelle est la meilleure façon de procéder?
Oui, si vous savez que les e-mails de votre domaine ne doivent provenir que de votre propre serveur, vous devez bloquer tous les e-mails 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, il doit se connecter à votre serveur (ou au serveur de messagerie que vous utilisez) pour envoyer des e-mails.
En allant plus loin, vous pouvez configurer votre serveur pour vérifier les enregistrements SPF. C'est le nombre d'hôtes qui empêchent 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 e-mails pour votre domaine. Comment activer la vérification des enregistrements SPF dépendra de votre service de messagerie et être au-delà de la portée de ce qui doit être couvert ici. Heureusement, la plupart des environnements d'hébergement et des logiciels auront une documentation pour travailler avec les enregistrements SPF. Vous voudrez peut-être en savoir plus sur SPF en général. Voici l'article Wikipedia: https: // en.wikipedia.org/wiki/Sender_Policy_Framework
Il existe déjà une norme pour ce faire. Ça s'appelle DMARC . Vous l'implémentez avec la signature DKIM (ce qui est quand même une bonne idée de l'implémenter).
La vue d'ensemble de haut niveau est que vous signez chaque e-mail qui quitte votre domaine avec un en-tête DKIM (ce qui est de toute façon une bonne pratique). Ensuite, vous configurez DMARC pour rejeter chaque e-mail qui frappe votre serveur de messagerie, à partir d'un domaine que vous possédez, qui n'est pas signé avec un en-tête DKIM valide.
Cela signifie que vous pouvez toujours demander à des services externes d'envoyer des e-mails à votre domaine (comme un logiciel d'assistance hébergé, etc.), mais que vous pouvez bloquer les tentatives de hameçonnage.
L'autre avantage de DMARC est que vous recevez des rapports de défaillance, vous pouvez donc gérer la gestion des exceptions si nécessaire.
L'inconvénient est que vous devez vous assurer d'avoir tout bien trié à l'avance ou vous pouvez commencer à supprimer des e-mails légitimes.
Un tel blocage est susceptible de réduire le spam et peut éventuellement rendre l'ingénierie sociale plus difficile, 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 du courrier directement à partir de l'hébergeur 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 qui a été envoyé à partir de votre réseau, en boucle via une liste de diffusion ou un redirecteur et a ensuite été reçu par votre courrier, mais ce n'est pas un remède parfait, certaines listes de diffusion briseront les signatures dkim et vous avez toujours le problème de retrouver tous les points d'origine du courrier légitime et de vous assurer qu'ils passent par un signataire dkim.
Faites preuve de prudence, surtout si vous l'implémentez sur un domaine existant.
Peut-être, mais il y a certains cas que vous devez considérer avant d'effectuer 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 e-mails qui semblent provenir de votre domaine? Même s'ils ne le font pas aujourd'hui, pourraient-ils le faire à l'avenir?
2) Existe-t-il des adresses externes à transmettre à vos utilisateurs? Par exemple, supposons que le compte gmail "[email protected]" transfère à "[email protected]" et que votre utilisateur "[email protected]" envoie à "[email protected]". Dans ce cas, le message arrivera de "l'extérieur", 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:" sur les messages de la liste? Par exemple, si Bob s'abonne à "[email protected]" et envoie un message, il recevra un message entrant ressemblant à: De: [email protected] À: [email protected]. com Expéditeur:
Si votre serveur regarde naïvement l'en-tête "From:" (au lieu de "Sender:"), il peut 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 possible d'avoir une politique générale de "... d'un véritable expéditeur dans notre entreprise, l'e-mail ne proviendrait jamais de l'extérieur".
Vous pouvez le faire dans PowerShell en mettant à jour vos autorisations de 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 e-mails d'état, car ceux-ci utilisent généralement votre nom de domaine dans leur adresse De. 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.
GMail a un paramètre qui vous permet d'envoyer des e-mails avec un domaine non-GMail à condition que l'adresse e-mail soit d'abord vérifiée. Votre décision bloquerait ces e-mails.
Que vous ayez ou non des utilisateurs susceptibles d'utiliser cette fonction GMail et qu'il soit judicieux de les satisfaire dépend en grande partie du comportement au sein de votre entreprise.