Joerg Habermeier - stock.adobe.c
Sécurité de la messagerie : de l’importance des enregistrements DNS
Certaines organisations laissent un enregistrement MX pointant directement vers leurs serveurs et non pas vers ceux de leur solution de filtrage des messages entrants. Une pratique risquée.
Mi-octobre, les opérateurs du ransomware Egregor revendiquaient une attaque réussie sur Cerfrance. Le Conseil national du réseau n’a en fait pas été affecté : c’est uniquement la section Poitou-Charentes qui a été touchée. Emotet pourrait avoir servi de vecteur d’attaque : les données du service HaveibeenEmotet indiquent en effet que des e-mails piégés ont été envoyés à partir des serveurs de messagerie de celle-ci.
Mais l’examen des enregistrements DNS du sous-domaine révélait une surprise : la section Poitou-Charentes de Cerfrance est cliente de Vade Secure. Mais tous les enregistrements MX ne pointaient pas alors sur les serveurs du Français : l’un d’entre eux envoyait directement vers le système de messagerie de la section.
La pratique peut trouver une explication pratique : il peut s’agir de s’assurer que les e-mails entrants continueront d’arriver même en cas de défaillance des systèmes du tiers chargé du filtrage. À moins qu’il ne faille y voir la crainte que ceux-ci ne soient trop zélés. Mais avec des menaces diffusées par la messagerie électronique comme Emotet ou Trickbot, ce n’est peut-être pas la meilleure des idées. Aujourd’hui, les enregistrements DNS de la section Poitou-Charentes de Cerfrance ont en tout cas été corrigés.
Régis Bénard, consultant technique chez Vade Secure, revient sur ces pratiques et souligne qu’il « arrive trop souvent que, suite à une migration, il subsiste d’anciens enregistrements MX, souvent laissés en priorité basse, “par sécurité” ». Las, comme il l’explique, « le problème est que ces relais secondaires sont fréquemment oubliés, alors qu’ils représentent une porte dérobée au niveau de la messagerie. Un attaquant qui scanne les entrées MX verra inévitablement ces entrées secondaires, et tentera de les utiliser. C’est un moyen très simple de contourner la protection mise en place, car souvent les anciens enregistrements MX ne sont pas protégés ». Mais ce n’est pas tout.
Régis Bénard poursuit en rappelant de ne « pas négliger les entrées de type SPF, très utiles pour limiter les possibilités d’usurpation du domaine. Plus les informations au niveau SPF sont exhaustives et strictes, plus le domaine est protégé. Pour compléter cette protection, l’utilisation de techniques avancées par vérification DKIM ou DMARC est un plus indéniable, mais nécessite un paramétrage qui peut paraître complexe et qui décourage la plupart des administrateurs de messagerie ».
Régis BénardConsultant technique, Vade Secure
Pour ajouter une couche supplémentaire de sécurité, Régis Bénard suggère de « rendre les serveurs non déclarés comme MX inaccessibles en SMTP depuis l’extérieur ». Pour lui, « verrouiller les entrées MX en réception SMTP est une des principales mesures de protection pour limiter la surface d’attaque ». Car ainsi, « une restriction conforme à ces recommandations garantit que tous les emails venant de l’extérieur seront bien passés par la solution de sécurité ».
Mais pour les organisations utilisatrices de services cloud, à l’instar de Microsoft 365 ou Google Workspace, « il existe un moyen d’éviter les oublis au niveau DNS, consécutifs à une migration » et même « de ne pas avoir à se soucier des restrictions sur-mesure au niveau du pare-feu, dépendantes de la solution de sécurité de messagerie ».
Régis Bénard relève ainsi que « les meilleures solutions de sécurisation de la messagerie profitent désormais des possibilités d’intégration via API », ce qui « réduit considérablement les possibilités de contournement des protections ». Sans compter un effet leurre certain, car une solution intégrée par API « n’apparaît pas au niveau DNS. Ainsi l’attaquant pense être confronté à une protection Microsoft connue, mais en réalité il aura affaire à bien plus sans le savoir ». Du coup, pour lui, « si une intégration de la solution de sécurité par API est possible, elle est clairement à privilégier. Elle garantit la plus faible exposition aux menaces par email comme Emotet ».